23 octets (LE)
48 octets (BR/EDR)
Optional interface
BR/EDR L2CAP
10.1 — Introduction
The Logical Link Control and Adaptation Protocol (L2CAP) sits between the upper layer protocols and the lower layers in the BLE stack. Its job is to act as a bridge — taking data from ATT and the Security Manager above it, and sending it down to the Link Layer below, and vice versa in the other direction.
L2CAP for BLE is a simplified version of the L2CAP used in classic BR/EDR Bluetooth. Many features needed for BR/EDR (complex flow control modes, multiple dynamic channels, connection-oriented services for arbitrary protocols) are not needed for BLE. They were deliberately removed to keep the BLE L2CAP small, simple, and power-efficient.
Where L2CAP Sits in the BLE Stack
L2CAP is in the middle of the host side of the stack — everything above it uses L2CAP’s services to send data, and L2CAP uses HCI (or the Link Layer directly) to actually transmit those packets over the radio.
The HCI is optional — this is an important point. In a single-chip implementation where the host and controller run on the same processor (no physical separation between them), there is no HCI bus. The L2CAP layer calls the Link Layer directly through some internal API. In a two-chip system (host on one processor, controller chip separate) the HCI is present and L2CAP sends data by wrapping it in HCI ACL Data packets.
10.2 — PDU and SDU — Two Very Similar Terms
These two terms come up constantly in networking protocols and it is easy to confuse them. In L2CAP they have a specific meaning:
A packet of data that the upper layer (for example the Attribute Protocol) hands to L2CAP and says “please deliver this to the same upper layer on the other device.” L2CAP treats the SDU as opaque data — it does not look inside it or change it. Its job is to get it from one device to the other intact.
A packet that L2CAP creates itself when it wraps the SDU. The PDU contains the L2CAP header (protocol information that the peer L2CAP layer needs) plus the SDU payload. The header says things like “this data is for ATT” (CID = 0x0004) and “this payload is N bytes long.”
2 oct
2 oct
over link
One SDU can be split across multiple PDUs if it is larger than what fits in a single packet. L2CAP handles this fragmentation on the sending side and reassembly on the receiving side, transparently to the upper layer protocol. The upper layer just sends an SDU and gets an SDU — it never needs to think about fragmentation.
10.3 — Basic Assumptions L2CAP Makes About the Controller
L2CAP does not operate in isolation — it relies on the Link Layer below it providing certain guarantees. These four assumptions are the contract between L2CAP and the controller. If any of them are violated, L2CAP cannot function correctly.
Whatever order the host on the transmitter side sends packets to L2CAP, they will arrive at the host on the receiver side in the same order. If packet A is sent first and packet B second, packet A will arrive first and packet B will arrive second. The Link Layer’s SN/NESN acknowledgment mechanism (covered in Chapter 8) provides this guarantee.
There is only one LE-U logical link between any two connected BLE devices. This means L2CAP does not need to handle multiple logical links — it can assume all data for all CIDs travels over this single link. This is a major simplification compared to BR/EDR where multiple logical links can coexist.
The Link Layer includes error detection (the 24-bit CRC) and retransmission (via SN/NESN). L2CAP does not need to implement its own error detection or retry logic — it can trust that the controller will either deliver a packet correctly or retransmit until it succeeds (subject to the supervision timeout).
The controller uses flow control at the link layer level (slave latency, connection events) to manage data rate over the air. The HCI layer uses the Number_Of_Completed_Packets_Event flow control (Chapter 9) to manage the rate at which the host sends data into the controller. L2CAP can rely on both of these — data will not be silently lost because a buffer overflowed somewhere.
10.4 — Maximum Transmission Unit (MTU)
The MTU is the maximum size of an SDU that a device is willing to receive from its peer. When two L2CAP entities connect, they tell each other their MTU. The sender must never send an SDU larger than the receiver’s advertised MTU.
The minimum MTU for LE is 23 octets. This means every LE device is guaranteed to be able to receive an SDU of at least 23 bytes. A device may support a larger MTU (and can advertise this during ATT MTU exchange), but 23 is the floor — if a device says nothing about its MTU, you can assume 23 bytes is safe.
Why does a smaller MTU save power? Smaller packets mean less air time per packet, which means the radio is active for shorter bursts. Smaller packets also require less memory to buffer on both devices. Together this reduces both transmit power consumption and the silicon cost of the controller chip.
What happens if the sender exceeds the receiver’s MTU? The receiver sends back a Command_Reject PDU on the L2CAP signaling channel (CID 0x0005) indicating it cannot accept the oversized packet. The sender must then either reduce its packet size or close the connection.
/* MTU negotiation in BLE is handled by the ATT protocol */
/* The ATT Exchange MTU Request/Response bumps the L2CAP MTU */
/* Default LE L2CAP MTU after connection: 23 bytes */
/* To request a larger MTU, the ATT layer sends: */
/* ATT_EXCHANGE_MTU_REQ with client_rx_mtu = desired size */
/* Using BlueZ gatttool to check/set MTU: */
/* gatttool -b AA:BB:CC:DD:EE:FF --mtu=512 -I */
/* [AA:BB:CC:DD:EE:FF] connect */
/* [AA:BB:CC:DD:EE:FF] exchange-mtu 512 */
/* The ATT layer then uses the negotiated MTU for all */
/* subsequent ATT operations on this connection *Next — MTU Continued, Fixed CIDs & Channel Multiplexing
You now understand the role of L2CAP, the PDU/SDU relationship, the four controller assumptions, and the 23-byte MTU floor. PDF 1920 continues with the full L2CAP feature set.