Every advertising channel PDU begins with a 2-byte (16-bit) header followed by a variable-length payload. The header packs several fields into those 16 bits. Understanding each field is essential for reading sniffer captures and for writing BLE advertising code.

/* BlueZ advertising PDU header structure (from net/bluetooth/hci.h) */

struct le_adv_pdu_hdr {
    uint8_t pdu_type:4; /* PDU type: ADV_IND=0x0, ADV_DIRECT=0x1,  */
                        /*  ADV_NONCONN=0x2, SCAN_REQ=0x3,          */
                        /*  SCAN_RSP=0x4, CONNECT_REQ=0x5,          */
                        /*  ADV_SCAN=0x6                             */
    uint8_t rfu1:2;     /* reserved, ignore on rx, set 0 on tx      */
    uint8_t tx_add:1;   /* 0 = public address, 1 = random address   */
    uint8_t rx_add:1;   /* 0 = public address, 1 = random address   */
    uint8_t length:6;   /* payload length in octets (valid: 6–37)   */
    uint8_t rfu2:2;     /* reserved                                  */
} __attribute__((packed));

/* Reading TxAdd/RxAdd when parsing a received advertising report */
void parse_adv_header(const struct le_adv_pdu_hdr *hdr)
{
    printf("PDU type   : 0x%01X\n", hdr->pdu_type);
    printf("TX address : %s\n",
           hdr->tx_add ? "random" : "public");
    printf("RX address : %s\n",
           hdr->rx_add ? "random" : "public");
    printf("Payload len: %d bytes\n", hdr->length);
}

Advertising PDUs are sent by a device in the Advertising state and received by devices in either the Scanning or Initiating state. There are four variants, each suited to a different advertising scenario:

/* Setting advertising type in BlueZ HCI */
/* le_set_advertising_parameters_cp.advtype field values */

#define LE_ADV_IND          0x00  /* connectable undirected   */
#define LE_ADV_DIRECT_IND   0x01  /* connectable directed     */
#define LE_ADV_NONCONN_IND  0x02  /* non-connectable          */
#define LE_ADV_SCAN_IND     0x06  /* scannable undirected     */

/* Example: set up non-connectable advertising (beacon mode) */
le_set_advertising_parameters_cp params;
memset(&params, 0, sizeof(params));
params.min_interval = htobs(0x0320); /* 500ms */
params.max_interval = htobs(0x0320);
params.advtype      = LE_ADV_NONCONN_IND; /* beacon, no connections */
params.chan_map     = 0x07;               /* all 3 adv channels     */
hci_send_cmd(sock, OGF_LE_CTL,
             OCF_LE_SET_ADVERTISING_PARAMETERS,
             LE_SET_ADVERTISING_PARAMETERS_CP_SIZE, &params);

Scanning PDUs are exchanged between a Scanner and an Advertiser when the Scanner wants more information than what the initial advertising packet contained. This is a two-packet handshake that happens within the same advertising event on the same channel.

Referring back to the sniffer capture from the previous section: Frame #427 was ADV_IND from the Advertiser, Frame #428 was SCAN_REQ from the Scanner, and Frame #429 was SCAN_RSP from the Advertiser — all three on channel 37, all forming a single advertising event.

There is exactly one initiating PDU: CONNECT_REQ. It is sent by the Initiator in response to an ADV_IND or ADV_DIRECT_IND from an Advertiser that the Initiator wants to connect to.

/* Monitoring for CONNECT_REQ with btmon to see connection params */
/* Run: sudo btmon | grep -A 30 "LE Enhanced Connection" */

/* When a connection is made, btmon shows: */
/* > HCI Event: LE Meta Event (0x3e)                              */
/*   LE Connection Complete (0x01)                                */
/*   Status: Success (0x00)                                       */
/*   Handle: 0x0040                                               */
/*   Role: Master (0x00)   ← we sent CONNECT_REQ = we are Master  */
/*   Address type: Public (0x00)                                  */
/*   Address: AA:BB:CC:DD:EE:FF (Polar H7)                        */
/*   Connection interval: 50.00 ms (0x0028)                       */
/*   Connection latency: 0 (0x0000)                               */
/*   Supervision timeout: 2000 ms (0x00c8)                        */
/*   Master clock accuracy: 500 ppm                               */

Once a BLE connection is established, all data flows through data channel PDUs. The header is again 2 bytes, but with a completely different set of fields from the advertising channel PDU header. Each bit serves a specific function in managing the flow of packets between Master and Slave.

The SN (Sequence Number) and NESN (Next Expected Sequence Number) fields together implement a lightweight but robust stop-and-wait acknowledgment protocol. Using just two bits of state, BLE achieves reliable in-order packet delivery with automatic retransmission of lost or corrupted packets.

Each device maintains two 1-bit counters in its Link Layer:

Both Master and Slave start in the Connection state with tSN=0 and nESN=0. The diagrams below trace exactly what happens, including both the success path and the retransmission path when a packet has an error.

The two key rules summarised:

Why only 1-bit sequence numbers? This is a stop-and-wait protocol — only one unacknowledged packet is in flight at any time. With only one outstanding packet, you only need to distinguish between two states: “same packet as before” (not acknowledged, retry it) or “next packet” (previous one was acknowledged, send new one). One bit is exactly enough to represent these two states.

/* BLE SN/NESN logic — simplified from BlueZ LL implementation */
/* Based on Bluetooth Core Spec 4.0, Section 4.5.9             */

struct ll_conn_tx_state {
    uint8_t tSN;    /* transmitSeqNum  — 1-bit, so only 0 or 1 */
    uint8_t nESN;   /* nextExpectedSeqNum — 1-bit, only 0 or 1  */
};

/*
 * Called when we receive a data channel PDU from the peer.
 * Returns 1 if this is a new packet (not a duplicate).
 */
int process_received_pdu(struct ll_conn_tx_state *state,
                          uint8_t rx_sn,  /* SN from received header */
                          uint8_t rx_nesn,/* NESN from received header */
                          int     crc_ok) /* 1 if CRC matched */
{
    /* Step 1: check if peer acknowledged our last transmission */
    if (rx_nesn != state->nESN) {
        /*
         * NESN changed → our last packet was acknowledged.
         * Advance our transmit sequence number and allow
         * sending the next new packet.
         */
        state->tSN = (state->tSN + 1) & 0x01;  /* toggle 0↔1 */
    }
    /* else: NESN unchanged → our last packet needs retransmission */

    /* Step 2: if CRC is good, check if this is a new inbound packet */
    if (crc_ok && (rx_sn == state->nESN)) {
        /*
         * SN matches what we expected → this is a new packet.
         * Acknowledge it by incrementing our nESN.
         */
        state->nESN = (state->nESN + 1) & 0x01;  /* toggle 0↔1 */
        return 1;  /* caller should pass payload to L2CAP */
    }

    /*
     * Either CRC failed or SN != nESN (duplicate / out-of-order).
     * Drop this PDU. nESN unchanged = implicit retransmit request.
     */
    return 0;
}