The sniffer capture in Figure 10.8 shows L2CAP PDUs being exchanged between two connected BLE devices. Looking at the Channel ID column, two things stand out immediately:

/* Capturing L2CAP traffic with btmon on Linux               */
/* sudo btmon                                                 */

/* You will see output like:                                  */
/* @ device hci0 opened
/* > HCI Event: LE Meta Event — Connection Complete           */
/* < HCI Command: LE Set Event Mask                           */

/* ATT traffic (CID 0x0004):                                  */
/* > ACL Data RX: handle 64 flags 0x02 dlen 11               */
/*     ATT: Exchange MTU Request (0x02) len 3                */
/*       Client RX MTU: 512                                   */

/* SMP traffic (CID 0x0006):                                  */
/* > ACL Data RX: handle 64 flags 0x02 dlen 7                */
/*     SMP: Pairing Request (0x01) len 6                      */
/*       IO capability: NoInputNoOutput                       */

Figure 10.9 shows the LE Credit-Based Connection Request from the source device. The key fields visible in the capture:

The Initial Credits = 10 in the request means the source device is granting the destination device permission to send up to 10 LE-frames once the channel is open. Until the source issues more credits, the destination cannot send more than 10 frames on this channel.

The destination device replies with an LE Credit-Based Connection Response. The response includes its own Initial Credits field — this grants the source device permission to send LE-frames to the destination.

After this two-PDU handshake the channel is fully established. The state is:

Figure 10.11 shows an LE Flow Control Credit packet sent after the initial channel setup. The capture shows that one additional credit is being sent to the peer device. This is the mechanism by which a device says “I have finished processing one more LE-frame and have buffer space again — you may send one additional frame.”

After the peer device receives this packet, it adds 1 to its current credit count for CID 0x0040. If it had 0 credits before and was blocked from sending, it can now send exactly 1 LE-frame. If it had 3 credits remaining, it now has 4.

Figure 10.12 from the textbook shows the complete credit-based flow control picture in one view. Combining what we saw in Figures 10.9, 10.10, and 10.11, here is the full credit lifecycle:

This pattern repeats for as long as data needs to be transferred. The destination device controls the pacing — it only issues credits when it has actually processed frames and freed buffer space. This prevents the source from ever overflowing the destination’s buffers regardless of how fast it can produce data.

The L2CAP layer provides data delivery services to the two upper-layer protocols that sit above it: the Security Manager Protocol (SMP) and the Attribute Protocol (ATT). Both of these use L2CAP’s channels to send their PDUs to the corresponding protocol on the remote device.

Because there are only two protocols using L2CAP in BLE (compared to many in BR/EDR), the LE L2CAP is significantly simplified. The fixed CID approach means there is never a need to negotiate or allocate channel numbers dynamically. Both ATT (CID 0x0004) and SMP (CID 0x0006) are always available the moment a connection is established.

Even the signaling commands are minimal — just three for the basic LE case: Command Reject, Connection Parameter Update Request, and Connection Parameter Update Response. None of these need to be exchanged before data can start flowing. As soon as the Link Layer reports a connection established, the upper layers can hand data to L2CAP and it will be sent immediately.