The Version Exchange procedure lets either the Master or the Slave share basic identification information about its Bluetooth implementation after entering the Connection state. This information is useful for diagnostics, logging, and compatibility checks between devices from different manufacturers.

The three pieces of information exchanged in a single LL_VERSION_IND PDU:

Reciprocal rule: When a device receives LL_VERSION_IND from the peer, it responds with its own LL_VERSION_IND — but only if it has not already sent its own version information in this connection. This prevents endless loops and means version information is only exchanged once per connection.

/* Reading version info from a connected BLE device via BlueZ */
/* hcitool cmd 0x04 0x001D 0x40 0x00 */
/* OGF=0x04 (Link Policy), OCF=0x001D = Read Remote Version */
/* Parameter: connection handle (2 bytes, little-endian)      */

/* Response event (HCI Read Remote Version Complete):         */
/* - status   : 1 byte  (0x00 = success)                     */
/* - handle   : 2 bytes (connection handle)                   */
/* - version  : 1 byte  (6=BT4.0, 7=BT4.1, 8=BT4.2, 9=BT5) */
/* - manufacturer: 2 bytes (company ID from Bluetooth SIG)   */
/* - subversion  : 2 bytes (firmware/silicon sub-version)    */

/* Or use bluetoothctl and check device info:                 */
/* [AA:BB:CC:DD:EE:FF]# info                                  */
/* Device AA:BB:CC:DD:EE:FF                                   */
/*   ...                                                      */
/*   Connected: yes                                           */

The Termination procedure is how a BLE connection is closed cleanly. Either the Master or the Slave can send LL_TERMINATE_IND at any time — this is the one LLCP procedure that does not have to wait for any other procedure to complete first.

The PDU carries an error code that explains why the connection is being terminated. Common error codes include: remote user terminated (0x13), connection timeout (0x08), pairing not allowed (0x18), and so on. The receiving side acknowledges the termination at the Link Layer level (an ACK at the LL level, not a separate PDU), closes the connection, and notifies its host.

/* Disconnecting a BLE connection using BlueZ */

/* Command line: */
/* bluetoothctl disconnect AA:BB:CC:DD:EE:FF */

/* Via hcitool (sends HCI Disconnect command to controller): */
/* hcitool dc AA:BB:CC:DD:EE:FF */

/* Programmatic — HCI Disconnect command: */
/* OGF=0x01 (Link Control), OCF=0x0006    */
typedef struct {
    uint16_t handle; /* connection handle             */
    uint8_t  reason; /* 0x13 = remote user terminated */
} __attribute__((packed)) disconnect_cp;

/* The controller sends LL_TERMINATE_IND to the peer */
/* and reports Disconnection Complete event to host  */

In BLE 4.0, only the Master could change connection parameters (via the Connection Update procedure in Section 8.12.1). The Slave had no way to request a change — it had to accept whatever the Master decided. This was a problem in practice: a sensor device (Slave) running low on battery had no way to ask for a longer connection interval to save power.

BLE 4.1 added the Connection Parameters Request procedure to fix this. Now either the Master or the Slave can request a parameter update using LL_CONNECTION_PARAM_REQ. The remote device either accepts with LL_CONNECTION_PARAM_RSP or rejects with LL_REJECT_IND_EXT.

The parameters that can be requested:

Why the Master still has the final word: Even with the 4.1 Connection Parameters Request, the Master ultimately controls when the parameters change. If the Master accepts the Slave’s request, it still schedules the change at a future connection event boundary (using LL_CONNECTION_UPDATE_REQ) rather than applying it immediately. This preserves the Master’s role as the timing authority for the connection.

/* Connection parameter update from Peripheral (Slave) in BlueZ */
/* Peripherals request updates via the L2CAP Connection Parameter */
/* Update Request (for older hosts) or via GATT on newer setups   */

/* Using bluetoothctl to update params as Central (Master):       */
/* hcitool lecup --handle 0x0040                                  */
/*              --min 0x0190 --max 0x0190                         */
/*              --latency 4 --timeout 0x01F4                       */
/* --min/max 0x0190 = 400 × 1.25ms = 500ms interval (power save) */
/* --latency 4      = Slave may skip 4 events                     */
/* --timeout 0x01F4 = 500 × 10ms = 5000ms supervision timeout    */

/* Checking connection params of a live connection:               */
/* hcitool lecc --list  (shows current connection parameters)     */