Starting from BLE 4.1, additional channel numbers were defined beyond the original three fixed CIDs. These support the new credit-based flow control mechanism introduced in 4.1:

BR/EDR L2CAP supports five different operating modes, each designed for a different use case:

The reason LE needs only Basic Mode is that the Link Layer already provides reliability (via SN/NESN retransmission) and flow control (via slave latency and HCI flow control). Adding L2CAP-level retransmission on top would be redundant complexity that wastes both code space and power. Removing these modes makes the LE L2CAP implementation much simpler.

In Basic Mode, every data PDU is called a B-Frame (Basic Frame). It has a simple three-field structure with no extra headers or sequence numbers beyond what the Link Layer already provides.

The simplicity of the B-Frame is intentional. There are no sequence numbers, no acknowledgment bits, and no window size fields. All of that is handled at the Link Layer. The B-Frame is just “here is the data, it is for this CID, it is N bytes long.”

BLE 4.1 added LE credit-based flow control mode — this introduced a new PDU type for connection-oriented channels (the LE-frame or L-Frame). It uses a credit-based scheme where the receiver grants permission to send packets by giving credits. This mode is used by the IPSP (Internet Protocol Support Profile) to let BLE devices connect to the internet via IPv6 gateways. This will be covered later in Chapter 15.

Both the ATT channel (CID 0x0004) and the SMP channel (CID 0x0006) use the same set of fixed L2CAP parameters. These do not need to be negotiated — they are defined by the specification and cannot be changed.

L2CAP uses CID 0x0005 as its own control channel. This is where L2CAP sends commands to the peer L2CAP entity — things like requesting a connection parameter update, setting up a credit-based channel, or rejecting an unknown command.

The LE signaling channel is simpler than the BR/EDR equivalent in one important way: only one command can be sent per PDU. In BR/EDR, multiple commands can be packed into one PDU. The LE restriction means the parsing logic on the receiving side only ever needs to handle one command at a time — no loop needed, no risk of partial command parsing.

The PDUs that carry signaling messages are called C-Frames (Control Frames).

Notice how much shorter this list is compared to BR/EDR, which has over 20 signaling commands. LE L2CAP only needs 6 because it eliminated all the dynamic channel setup negotiation (CONNECT, CONFIGURE, DISCONNECT PDUs) and kept only what is genuinely needed.

If a device receives a signaling command it does not understand (wrong Code value) or a command that has an incorrect length, it sends back a Command Reject (Code 0x01). The rejection PDU includes a reason field that explains why the command was rejected. There are three possible reasons:

This is the most commonly used signaling command. A BLE Slave (Peripheral) sends this to the Master (Central) to request a change to the connection parameters. This is the L2CAP-level mechanism — remember that in BLE 4.0, the Slave cannot initiate a direct Link Layer connection update, so it uses this L2CAP signaling message instead.

The command travels over CID 0x0005 (the L2CAP signaling channel) and carries four parameters:

Direction: This command goes only from Slave to Master. If the Master needs to change connection parameters, it can do so directly using the HCI_LE_Connection_Update HCI command — it does not need to ask the Slave via L2CAP. If the Master accepts the Slave’s request, it sends a Connection Parameter Update Response (Code 0x13) and then initiates the actual parameter change using the Link Layer procedure.

/* Sending Connection Parameter Update Request from Peripheral */
/* This is done automatically by BlueZ when a Peripheral calls */
/* the connection update function                              */

/* In BlueZ, Peripheral (Slave) requests new params via:      */
/* The host can use HCI_LE_Remote_Connection_Parameter_Request */
/* or via L2CAP socket with setsockopt:                       */

struct bt_le_conn_param param = {
    .min_interval = 80,   /* 80 × 1.25ms = 100ms min interval */
    .max_interval = 100,  /* 100 × 1.25ms = 125ms max interval */
    .latency      = 0,    /* no slave latency                  */
    .supervision_timeout = 2000, /* 2000 × 10ms = 20s timeout */
};

/* BlueZ kernel sends L2CAP Connection Parameter Update Request */
/* automatically when the application requests it              */

/* Monitor with btmon: look for                                */
/* "LE L2CAP Signaling: Connection Parameter Update Request"   */