Beyond connSlaveLatency = 0 (covered previously), the sniffer capture also showed these values:

After a BLE connection is established, the connection parameters are not frozen forever. The environment changes, security needs may change, and both sides may need to update what they agreed on during the CONNECT_REQ exchange. The Link Layer Control Protocol (LLCP) provides the mechanism to negotiate and update these parameters without dropping the connection.

LLCP PDUs travel inside data channel PDUs. When a link layer control PDU is sent, the LLID field in the data channel PDU header is set to 0b11 (as opposed to 0b10 for regular L2CAP data). The receiver recognises this and passes the payload to its own link layer for processing rather than up to L2CAP.

Sequential rule: Only one LLCP procedure can be active at any time. A new procedure cannot be started until the previous one either completes successfully or times out. The only exception is the Termination procedure, which can be sent at any moment regardless of whether another procedure is in progress.

After a connection is established the Master can change three of the connection timing parameters at any time without dropping the connection. This is important because the best parameters at connection setup may not be the best parameters during later phases of use. For example, a device may connect with a short interval to quickly exchange initial data, then switch to a longer interval to save battery during an idle period.

The three parameters the Master can update:

Who can start it: Only the Master. The Slave cannot initiate this procedure in BLE 4.0. In BLE 4.1, the Slave gains the ability to request parameter changes using the Connection Parameters Request procedure (LL_CONNECTION_PARAM_REQ).

/* Updating connection parameters from a Central (Master) with BlueZ */
/* The host stack sends HCI LE Connection Update to the controller    */

/* Using hcitool to update connection interval:                       */
/* hcitool lecup --handle 0x0040 --min 0x0028 --max 0x0028           */
/*               --latency 0 --timeout 0x00C8                         */
/* --min/max 0x0028 = 40 × 1.25ms = 50ms connection interval         */
/* --latency 0      = Slave must respond every event                  */
/* --timeout 0xC8   = 200 × 10ms  = 2000ms supervision timeout       */

In a real deployment, the radio environment around a BLE device changes over time. A Wi-Fi router nearby may switch channels. A microwave oven may start causing interference. Some data channels that were clean at connection setup may develop persistent noise later.

The Channel Map Update procedure allows the Master to tell the Slave which channels are now considered good and which should be avoided. The Master continuously monitors signal quality on the data channels and updates the bitmap whenever it detects that a channel has become unreliable. This is the foundation of BLE’s Adaptive Frequency Hopping (AFH) capability.

Two parameters are included in the update:

By disabling channels with interference, the Master reduces the number of retransmissions — which directly saves power and increases throughput for the same energy budget.

A BLE connection can start unencrypted (for example, to exchange non-sensitive discovery data) and then switch to encrypted mode when sensitive data needs to be transferred. The Encryption Start procedure handles this transition.

It is initiated by the host of the Master side. The Master’s host sends an HCI command down to its link layer that includes the Long_Term_Key (LTK) — a 128-bit key that was established during the pairing process. The link layer uses the LTK to derive a session key that will encrypt all subsequent link layer PDUs for this connection.

The three-way handshake (LL_START_ENC_REQ → LL_START_ENC_RSP → LL_START_ENC_RSP) confirms that both sides have computed the same session key from the LTK. Only after both sides have confirmed can encrypted packets flow. If the Slave does not support encryption, it responds with LL_REJECT_IND instead.

/* Initiating encryption on a BLE connection with BlueZ  */
/* After pairing, the host sends LE Start Encryption HCI */

/* Using bluetoothctl: */
/* [bluetooth]# pair AA:BB:CC:DD:EE:FF  */
/* Pairing successful                   */
/* [AA:BB:CC:DD:EE:FF]# trust           */
/* Trust successful                     */
/* The link is now encrypted            */

/* Programmatic — BlueZ HCI LE Start Encryption command: */
/* OGF=0x08, OCF=0x0019                                  */
/* Parameters: handle, random, EDIV, LTK (16 bytes)      */
typedef struct {
    uint16_t handle;
    uint64_t random;
    uint16_t ediv;
    uint8_t  ltk[16]; /* 128-bit Long Term Key */
} __attribute__((packed)) le_start_enc_cp;