In active scanning the Advertiser sends a SCAN_RSP after receiving a SCAN_REQ. Its payload carries two fields:

In the Initiating state the link layer listens on advertising channels 37, 38, and 39 — exactly like the Scanning state. The critical difference is intent: the Initiator is not just collecting information. It has a specific target device in mind and is waiting for that device’s advertising packet so it can send a CONNECT_REQ.

The Initiator cannot connect to just any Advertiser. There is a strict permission rule: a CONNECT_REQ may only be sent in response to two specific advertising PDU types:

The Connection state is entered the moment the CONNECT_REQ is sent. Who enters it and how they entered determines the role each device takes for the duration of that connection:

Entering the Connection state does not mean data can flow immediately. There are two stages:

When the CONNECT_REQ is sent both devices share the same timing, access address, and channel map — so they are synchronised. But neither has yet proven that radio packets are actually reaching the other side in both directions. When the first data channel PDU successfully arrives from the peer device, that proves the link is working. At that point the connection moves from created to established.

One LE link per pair: There can only be one LE connection between any two devices at any time. The stack will reject or reuse an existing connection if a duplicate is attempted.

The CONNECT_REQ is the most information-dense packet in BLE. Its payload sets up the entire connection before a single data packet is exchanged.

The SCA field tells the Slave how much timing drift to expect from the Master while the radio is sleeping between connection events. A higher SCA code (worse clock accuracy) means the Slave must open a wider listening window to catch the Master’s packet, which uses more power. Better hardware oscillators give lower SCA codes and narrower windows.

These are the actual parameter values decoded from a real CONNECT_REQ capture:

/* Parsing CONNECT_REQ LLData with BlueZ */
/* Maps directly to the 22 bytes of LLData in the PDU */

typedef struct {
    uint32_t  aa;          /* Access Address — 4 bytes        */
    uint8_t   crc_init[3]; /* CRC seed — 3 bytes              */
    uint8_t   win_size;    /* WinSize in units of 1.25ms      */
    uint16_t  win_offset;  /* WinOffset in units of 1.25ms    */
    uint16_t  interval;    /* connInterval in units of 1.25ms */
    uint16_t  latency;     /* connSlaveLatency (event count)  */
    uint16_t  timeout;     /* supervision timeout ×10ms       */
    uint8_t   chm[5];      /* 37-bit channel map bitmap       */
    uint8_t   hop_sca;     /* hop[4:0] | sca[7:5]            */
} __attribute__((packed)) le_lldata_t;

/* Extract hop increment and SCA from the packed byte */
uint8_t hop = lldata.hop_sca & 0x1F;         /* bits 4:0 */
uint8_t sca = (lldata.hop_sca >> 5) & 0x07;  /* bits 7:5 */

/* Using btmon to watch connection events live:          */
/* sudo btmon | grep -A 20 "LE Connection Complete"      */