Overview
Logical Link Control and Adaptation Protocol (L2CAP) is the core protocol of Bluetooth and is responsible for adapting the upper layer protocol in the baseband. It works in parallel with the link manager to provide connection-directed and connectionless data services to upper-layer protocols. L2CAP has splitting and reassembly capabilities, enabling higher-level protocols and applications to send and receive packets up to 64KB in length. It is also capable of handling the multiplexing of protocols to provide multiple connections and multiple connection types while providing quality of service support and group communications. The structure and location of L2CAP in the protocol stack are as follows:
SDU: Service Data Unit, which is a data packet exchanged between L2CAP and the upper layer protocol. It can be divided into several segments for L2CAP flow control (the segmentation function of L2CAP, Reassembling segments into complete SDUs is the reassembly function). L2CAP uses CID to identify the upper layer protocol from which the SDU originates.
Components of L2CAP
As shown in Figure 1, L2CAP includes two components: Channel Manager and Resource Manager, which are introduced as follows: The
L2CAP Resource Manager is responsible for managing the Protocol Data Unit (Protocol Data Unit) sent to the baseband. PDU) fragment submission order and related scheduling between channels to ensure that L2CAP channel access to the physical channel is denied due to Bluetooth controller resource exhaustion (Bluetooth controller buffering is limited, HCI bandwidth is limited). The L2CAP resource manager can also perform traffic compliance policing functions to ensure that applications submit L2CAP Service Data Units (SDUs) within the limits of their negotiated QoS settings.
The L2CAP channel manager is responsible for creating, managing, and ending L2CAP channels used for service protocol and application data flow transmission. The channel manager L2CAP interacts with the channel manager on the remote (peer) device to create these L2CAP channels and connect their endpoints to the corresponding entities (Entities, as shown below). The channel manager interacts with the local link manager to create new logical links and configure these links to provide the Quality of Service (QoS) required by the type of data being transmitted.
Channel ID: Channel identifier (CID), which is equivalent to the Port in TCP and specifies the logical connection endpoint between devices. In Figure 2, in a connection-oriented channel, the CID identifies the two endpoints of the channel, while a connectionless-oriented channel is single-directional and the CID represents the target endpoint.
. L2CAP uses CID to implement multi-channel ACL data transmission on the logical link of a controller.
Figure 2 above also illustrates that there are three types of L2CAP channels:
A. Connection-oriented channel: Connection-OrientedCO, used for data communication between two devices.
B. Connection-less channel: Connection-LessCL, used to broadcast data to a group of devices. CID is a fixed value: 0x0002.
C. Signaling Channel: Signaling Channel, a channel used to send signaling. For ACL-U logical links, the CID is 0x0001, and for LE-U, use 0x0005.
The following is the definition of CID, ACL-U and LE-U are slightly different. 0x0001 0x003F is a fixed CID, and 0x40 0xFFFF is a dynamically allocated CID.
The CID of LE is slightly different (especially note that 0x0004 is the ATT protocol):
L2CAP functions
The functions of L2CAP include three components: protocol/channel multiplexing, segmentation and reassembly (SAR), and quality of service.
- Protocol/channel multiplexing: L2CAP should support protocol multiplexing. Because there is no field in the baseband protocol and message format to identify the "type" of higher-level protocols, L2CAP must be able to distinguish higher-level protocols, such as GAP, RFCOMM, etc.
- Segmentation and reassembly: The baseband protocol is based on hardware (physical) media, and the effective data load in its messages is limited by the maximum output unit (MTU, up to 64KB). Messages of higher-layer protocols may require larger data payloads. For this reason, SDUs from higher-layer protocols may be segmented by L2CAP into multiple PDUs that meet the baseband transmission size before transmission, and then sent out. Similarly, when the baseband receives multiple PDUs, they will be reassembled into SDUs and then submitted to the upper layer protocol for processing.
- Quality of Service: L2CAP connection establishment process that allows the exchange of information about the quality of service between two Bluetooth devices. Each L2CAP client must monitor the resources used by the protocol and ensure complete implementation of quality of service.
Equipment room operations
operating mode
The L2CAP channel has 5 working modes:
- Basic L2CAP mode (equivalent to the L2CAP specification in Bluetooth v1.1)
- flow control mode
- retransmission mode
- Enhanced retransmission mode
- streaming mode
- LE flow control mode (LE-specific)
L2CAP connection type
L2CAP has 4 connection types as follows:
- Connection-oriented Channels in Basic L2CAP mode (Connection-oriented Channels in Basic L2CAP mode).
- No connection, using Basic L2CAP mode (Connectionless Data Channels in Basic L2CAP mode).
- Connection-oriented Channels in Retransmission/Flow Control/Streaming Mode.
- Connection-oriented Channels in LE Credit Based Flow Control Mode.
A connection-oriented data channel provides the connection between two devices, and the CID of the bound logical link (ACL-U and LE-U) is used to identify each end of the channel. For connectionless data channels, CID limits the direction of transmission when used for broadcast transmission; but there is no restriction when used for unicast transmission.
L2CAP data packets and signal packets
L2CAP has two formats: data packet and signal packet.
L2CAP packet format.
L2CAP's 4 connection types have different corresponding packet formats:
-
Data packet for the connection channel in basic L2CAP mode (also called B-frame)
Length: 2 bytes, the length of the payload, excluding the CID length.
Channel ID: 2 bytes, destination channel;
Information payload: 0~65535 bytes (64KB). -
Data packet (G-frame) for connectionless data communication in basic L2CAP mode.
Length: 2 bytes, the length of PSM+payload.
Channel ID: 2 bytes, use fixed value 0x0002 for connectionless data transmission;
PSM: >=2 bytes, Protocol/Service Multiplexer -
Enhanced retransmission mode/flow control mode/streaming mode for connection channel-oriented data packets (S-Frame/I-Frame)
I-Frame is used to transmit information between L2CAP entities, and S-Frame is used to confirm I -Retransmission requests for Frame and I-Frame.
Length: 2 bytes, the total number of bytes except Basic L2CAP header.
Channel ID: 2 bytes, destination channel of the opposite end;
L2CAP SDU Length: 2 bytes, only appears in Start I-Frame (SAR=0x01), indicating the total SDU length.
FCS: 2 bytes, Frame Check Sequence.
Control Field has 3 modes:
a. Standard Control Field: used for flow control/retransmission mode (Retransmission Mode and Flow Control Mode).
b. Enhanced Control Field: used to enhance retransmission mode and streaming mode (Enhanced Retransmission Mode and Streaming Mode).
c. Extended Control Field: used to enhance retransmission mode and streaming mode (Enhanced Retransmission Mode and Streaming Mode).
The format of Standard Control Field is as follows:
The format of Enhanced Control Field is as follows
. The format of Extended Control Field is as follows: The meaning
of each field of Control Field is as follows:
SAR: (2 bits), Segmentation and Reassembly, 指明该L2CAP是否是分段过
TxSeq: (6/14 bits), Send Sequence Number, 对发送的I-Frame计数, 用于分段和重组
ReqSeq: (6/14 bits), Receive Sequence Number, 接收方用于应答I-Frame和请求重传
R: (1 bits), Retransmission Disable Bit, 用来实现Flow Control
S: (2 bits), Supervisory function, 表示S-Frame的type
P: (1 bits), Poll, 置1表示从接收方征求相应
F: (1 bits), Final, 相应P置1的S-Frame
- Connection channel-oriented data packets based on LE flow control mode
L2CAP signal packet format
Signaling Packet Format: The signaling commands (Signaling Commands) transmitted between two L2CAP entities on the peer device. These signaling commands are transmitted through the signaling channel (Signaling Channel). For ACL-U logical links, they should Use CID 0x0001, while for LE-U you should use CID 0x0005. The format of the signal packet is as follows: For
detailed information on each signaling, please refer to: Vol 3->Part A->4. Here is an example:
As shown in the figure above, CID=0x0001 indicates that this is a signal packet, and the signaling value=0x02. Vol 3->Part A->4.2 has a detailed introduction. This signaling is Connection Request, which sends a connection request packet between two devices. Create an L2CAP channel between them. Only then can the L2CAP channel be configured. For example:
The signaling packet format of Connection Request is as follows:
PSM: Protocol/Service Multiplexer Protocol/Service Multiplexer. Among them, Bluetooth SIG has reserved PSM values for some high-level protocols. Please refer to the "Logical Link Control" link in https://www.bluetooth.com/specifications/assigned-numbers/ . In this example, PSM=0x19, which represents the AVDTP protocol.
Source CID: Indicates the channel endpoint number (CID) requested to be created. This CID is dynamically allocated, that is, it should be between 0x0040~0xFFFF. In this example, CID=0x0044. After the channel is successfully created, the next data communication related to the AVDTP protocol will be carried out in this channel.