Every time an element inside a mesh node sends a message, it stamps that message with a Sequence Number (SEQ) — a simple 24-bit integer stored in the SEQ field of the Network PDU. The rule is strict: each new outgoing message must use a number that is higher than the last one.

Why strictly increasing?

When a receiving node gets a message, it checks the SEQ against the last SEQ it saw from that source address. If the new SEQ is equal to or lower than the stored one, the message is dropped immediately — it is either a duplicate or a replayed packet.

How large is the counter space?

A 24-bit number can reach a maximum of 16,777,216. If an element sends one message every 5 seconds (a fairly busy device), it takes about 2.6 years to exhaust the counter. Before that happens, the node must run the IV Update procedure to reset the counter safely.

BlueZ: reading the sequence number

BlueZ stores the current sequence number per element in /var/lib/bluetooth/<adapter>/mesh/<node-token>/config. You can also watch it in meshctl debug output:

# Start meshctl with debug logging
sudo meshctl --dbus-debug

# Inside meshctl, send a message and watch the log
[meshctl]# send 0100 0a

# BlueZ debug output will show:
# mesh_net.c: Network SEQ sent: 0x00002A
# mesh_net.c: Nonce built with SEQ=0x00002A IV=0x00000001

The source code in BlueZ that manages the sequence number lives in mesh/net.c:

/* mesh/net.c (simplified) */

/* get next sequence number for an element */
static uint32_t get_next_seq(struct mesh_net *net, uint16_t src)
{
    uint32_t seq = net->seq_num;
    net->seq_num++;   /* strictly incrementing */

    /* flush to storage so it survives a reboot */
    storage_save_sequence(net, src, net->seq_num);

    return seq;
}

The IV Index is like a “chapter number” for the whole mesh network. While the SEQ is a “page number” within a chapter, the IV Index says which chapter we are in. All nodes in the same mesh network share the exact same IV Index value at any given time.

Starting value and increment rule

The IV Index starts at 0x00000000. It is incremented by 1 every time any node’s sequence number gets close to its maximum (0xFFFFFF). This is called the IV Update procedure. Because IV Index is 32 bits wide, the entire mesh network can run for approximately 5 trillion years before the IV Index wraps — effectively forever.

How is the IV Index shared?

Every node broadcasts Secure Network Beacons periodically. These beacons carry the current IV Index value (and a 1-bit flag showing whether an IV Update is in progress). Any node that has been powered off for a while can listen for these beacons and catch up immediately.

Subnet rule for IV Index propagation

A node connected to the primary subnet that receives an IV update on the primary subnet must propagate it to all other subnets it belongs to. However, if that same node receives an IV update on a secondary subnet, it must ignore it — only primary-subnet updates are authoritative.

BlueZ: reading the IV Index

# BlueZ stores IV Index in the node config JSON
cat /var/lib/bluetooth/<BD_ADDR>/mesh/<token>/config | python3 -m json.tool | grep -i iv

# Expected output:
#   "IVindex": 1,
#   "IVupdate": 0

/* mesh/net.c — IV Index access (simplified) */

uint32_t mesh_net_get_iv_index(struct mesh_net *net)
{
    return net->iv_index;
}

/* called when a Secure Network Beacon arrives with a higher IV */
static void process_iv_update(struct mesh_net *net, uint32_t new_iv)
{
    if (new_iv > net->iv_index) {
        net->iv_index = new_iv;
        net->seq_num  = 0;  /* SEQ resets after IV increment */
        storage_save_iv(net);
    }
}

The word nonce literally means “number used once”. In Bluetooth Mesh, the nonce is a 13-byte value fed into the AES-CCM encryption engine alongside the actual message payload and a key. If the nonce is ever the same for two different messages encrypted with the same key, the encryption is broken — an attacker can recover the plaintext. The entire SEQ + IV Index design exists purely to guarantee the nonce is always unique.

The four nonce types at a glance

Notice the key design decisions baked into the table above: the TTL (Time To Live) is inside the Network nonce but not inside the Application or Device nonce. This is intentional — when a relay decrements the TTL, the network-layer nonce changes (so the relay re-authenticates the TTL), but the application-layer nonce stays the same (the app doesn’t care how many hops the message took). Similarly, the DST (destination address) is encrypted at the network layer — it goes into the application/device nonce but not the network nonce.

The Network nonce is exactly 13 bytes wide. Let’s walk through each field:

What is the CTL|TTL byte?

Octet 1 packs two fields into one byte: the most-significant bit is CTL (0 = access message, 1 = control message) and the remaining 7 bits hold the TTL (Time To Live, 0–127). This combined byte is included in the nonce so that relays cannot silently change the TTL without breaking authentication.

BlueZ: building the Network nonce

/* mesh/crypto.c — network nonce construction (simplified) */

void mesh_crypto_network_nonce(uint8_t  ctl,
                               uint8_t  ttl,
                               uint32_t seq,
                               uint16_t src,
                               uint32_t iv_index,
                               uint8_t  nonce[13])
{
    nonce[0]  = 0x00;                     /* Nonce Type: Network */
    nonce[1]  = (ctl << 7) | (ttl & 0x7F);  /* CTL | TTL */
    nonce[2]  = (seq >> 16) & 0xFF;      /* SEQ MSB  */
    nonce[3]  = (seq >>  8) & 0xFF;
    nonce[4]  =  seq        & 0xFF;      /* SEQ LSB  */
    nonce[5]  = (src >>  8) & 0xFF;      /* SRC hi   */
    nonce[6]  =  src        & 0xFF;      /* SRC lo   */
    nonce[7]  = 0x00;                     /* Pad      */
    nonce[8]  = 0x00;                     /* Pad      */
    nonce[9]  = (iv_index >> 24) & 0xFF; /* IV MSB   */
    nonce[10] = (iv_index >> 16) & 0xFF;
    nonce[11] = (iv_index >>  8) & 0xFF;
    nonce[12] =  iv_index        & 0xFF; /* IV LSB   */
}

/* Example call: element 0x0101, seq=0x2A, iv=1, TTL=5, access msg */
uint8_t nonce[13];
mesh_crypto_network_nonce(0, 5, 0x2A, 0x0101, 1, nonce);
/* nonce = { 00, 05, 00, 00, 2A, 01, 01, 00, 00, 00, 00, 00, 01 } */

The Application nonce and Device nonce share an almost identical structure. The key difference from the Network nonce is that they include the destination address (DST) and drop the TTL. They are used one layer higher — at the upper transport layer — with the Application Key or Device Key respectively.

What is ASZMIC?

ASZMIC stands for Access Segmented Message Integrity Check. It occupies bit 7 of octet 1. For a segmented access message (one that had to be split into multiple PDUs), ASZMIC mirrors the SZMIC flag which controls whether the MIC is 4 bytes or 8 bytes long. For all unsegmented messages it is always 0.

BlueZ: building the Application nonce

/* mesh/crypto.c — application nonce construction (simplified) */

void mesh_crypto_application_nonce(uint8_t  aszmic,
                                   uint32_t seq,
                                   uint16_t src,
                                   uint16_t dst,
                                   uint32_t iv_index,
                                   uint8_t  nonce[13])
{
    nonce[0]  = 0x01;                         /* Nonce Type: Application */
    nonce[1]  = (aszmic & 0x01) << 7;         /* ASZMIC | Pad            */
    nonce[2]  = (seq >> 16) & 0xFF;
    nonce[3]  = (seq >>  8) & 0xFF;
    nonce[4]  =  seq        & 0xFF;
    nonce[5]  = (src >>  8) & 0xFF;
    nonce[6]  =  src        & 0xFF;
    nonce[7]  = (dst >>  8) & 0xFF;           /* DST hi — not in net nonce */
    nonce[8]  =  dst        & 0xFF;           /* DST lo                    */
    nonce[9]  = (iv_index >> 24) & 0xFF;
    nonce[10] = (iv_index >> 16) & 0xFF;
    nonce[11] = (iv_index >>  8) & 0xFF;
    nonce[12] =  iv_index        & 0xFF;
}

/* Device nonce is exactly the same but nonce[0] = 0x02 */

Bluetooth Mesh uses two independent layers of encryption on every access message. Understanding which nonce is used at each layer is the key to understanding the whole security model.

Quick summary: which fields change at each hop?