Logical Link Control and Adaptation Layer Protocol (L2CAP)
The L2CAP layer sits on top of the HCI layer on the host side and
transfers data between the upper layers of the host (GAP, GATT,
application) and the lower layer protocol stack. This layer is
responsible for protocol multiplexing capability, segmentation, and
reassembly operation for data exchanged between the host and the
protocol stack. L2CAP permits higher-level protocols and
applications to transmit and receive upper layer data packets (L2CAP
service data units, SDU) up to 64KB long. See Figure 64. for more
The actual size is limited by the amount of memory available on the
specific device being implemented. L2CAP also permits per-channel
flow control and retransmission.
Figure 64. L2CAP Architectural blocks.
General L2CAP Terminology
Table 12. General L2CAP Terminology
||The logical connection between two endpoints in peer devices,
characterized by their Channel Identifiers (CIDs)
|SDU or L2CAP SDU
||Service Data Unit: a packet of data that L2CAP exchanges with
the upper layer and transports transparently over an L2CAP
channel using the procedures specified in this document
|PDU or L2CAP PDU
||Protocol Data Unit: a packet of data containing L2CAP protocol
information fields, control information, and/or upper layer
|Maximum Transmission Unit (MTU)
||The maximum size of payload data, in octets, that the upper
layer entity can accept (that is, the MTU corresponds to the
maximum SDU size).
|Maximum PDU Payload Size (MPS)
||The maximum size of payload data in octets that the L2CAP
layer entity can accept (that is, the MPS corresponds to the
maximum PDU payload size).
Maximum Transmission Unit (MTU)
The Bluetooth low energy stack supports fragmentation and
recombination of L2CAP PDUs at the link layer. This fragmentation
support allows L2CAP and higher-level protocols built on top of
L2CAP, such as the attribute protocol (ATT), to use larger payload
sizes, and reduce the overhead associated with larger data
transactions. When fragmentation is used, larger packets are split
into multiple link layer packets and reassembled by the link layer
of the peer device. Figure 65. shows this relationship.
Figure 65. L2CAP Packet Fragmentation.
The size of the L2CAP PDU also defines the size of the Attribute
Protocol Maximum Transmission Unit (
ATT_MTU). By default, LE
devices assume the size of the L2CAP PDU is 27 bytes, which
corresponds to the maximum size of the LE packet that can transmit
in a single connection event packet. In this case, the L2CAP
protocol header is 4 bytes, resulting in a default size for
Configuring for Larger MTU Values
A client device can request a larger
ATT_MTU during a connection by
using the GATT_ExchangeMTU() command.
During this procedure, the client informs the server of its maximum
supported receive MTU size and the server responds with its maximum supported
receive MTU size. Only the client can initiate this procedure. When
the messages are exchanged, the
ATT_MTU for the duration of the
connection is the minimum of the client MTU and server MTU values.
If the client indicates it can support an MTU of 200 bytes and the
server responds with a maximum size of 150 bytes, the
is 150 for that connection.
For more information, see the MTU
Exchange section of the Bluetooth Core Specification Version 4.2.
Take the following steps to configure the stack to support larger
- Set the
MAX_PDU_SIZE preprocessor symbol in the application project
to the desired value to the maximum desired
size of the L2CAP PDU size. The maximum
ATT_MTU size is always 4
bytes less than the value of the
- Call GATT_ExchangeMTU() after a connection is formed (GATT client
only). The MTU parameter passed into this function must be less
than or equal to the definition from step 1.
- Receive the
ATT_MTU_UPDATED_EVENT in the calling task to verify
that the MTU was successfully updated. This update requires the
calling task to have registered for GATT messages. See Registering to Receive Additional GATT Events in the Application for more information.
Though the stack can be configured to support a
MAX_PDU_SIZE up to
255 bytes, each Bluetooth low energy connection initially uses the
default 27 bytes (
ATT_MTU = 23 bytes) value until the exchange MTU
procedure results in a larger MTU size. The exchange MTU procedure
must be performed on each Bluetooth low energy connection and must
be initiated by the client.
If the Secure Connections BLE 4.2 Feature is enabled,
the default MTU size will be 69 upon connection.
ble_user_config.h for details.
Increasing the size of the
ATT_MTU increases the amount of data
that can be sent in a single ATT packet. The longest attribute that
can be sent in a single packet is (
ATT_MTU-1) bytes. Procedures,
such as notifications, have additional length restrictions. If an
attribute value has a length of 100 bytes, a read of this entire
attribute requires a read request to obtain the first (
bytes, followed by multiple read blob request to obtain the
ATT_MTU-1) bytes. To transfer the entire 100 bytes of
payload data with the default
ATT_MTU = 23 bytes, five request or
response procedures are required, each returning 22 bytes. If the
exchange MTU procedure was performed and an
ATT_MTU was configured
to 101 bytes (or greater), the entire 100 bytes could be read in a
single read request or response procedure.
Due to memory and processing limitations, not all
Bluetooth low energy systems support larger MTU sizes. Know the
capabilities of expected peer devices when defining the behavior of
the system. If the capability of peer devices is unknown, design the
system to work with the default 27-byte L2CAP PDU/23-byte
size. For example, sending notifications with a length greater than
20 bytes (
ATT_MTU-3) bytes results in truncation of data on devices
that do not support larger MTU sizes.
L2CAP is based around channels. Each endpoint of an L2CAP channel is
referred to by a channel identifier (CID). See the Channel Identifiers section
([Vol 3], Part A, Section 2.1) of the Bluetooth Core Specification Version 4.2 for more details on L2CAP Channel
Identifiers. Channels can be divided into fixed and dynamic
channels. For example, data exchanged over the GATT protocol uses
channel 0x0004. A dynamically allocated CID is allocated to identify
the logical link and the local endpoint. The local endpoint must be
in the range from 0x0040 to 0xFFFF. This endpoint is used in the
connection-orientated L2CAP channels described in the following
L2CAP Connection-Oriented Channel (CoC) Example
The Bluetooth low energy stack SDK provides APIs to create L2CAP CoC
channels to transfer bidirectional data between two Bluetooth low
energy devices supporting this feature. This feature is enabled by
default in the protocol stack. Figure 66.
shows a sample connection and data exchange process between master
and slave device using a L2CAP connection-oriented channel in LE
Credit Based Flow Control Mode.
Figure 66. Sample Connection and Data Exchange Between a Master and Slave Device Using a L2CAP.
Connection-Oriented Channel in LE Credit Based Flow Control Mode
Credit Based Flow Control mode is used by the L2CAP layer for Connection-Oriented Channels.
For more information on these L2CAP APIs, refer to BLE Stack API Reference.