Part A. Logical Link Control and Adaptation Protocol Specification
vAtlanta r00
The Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) supports higher level protocol multiplexing, packet segmentation and reassembly, and the conveying of quality of service information. The protocol state machine, packet format, and composition are described in this Part of the specification.
1. Introduction
This section of the Bluetooth Specification defines the Logical Link Control and Adaptation Layer Protocol, referred to as L2CAP. L2CAP provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability and segmentation and reassembly operation. L2CAP permits higher level protocols and applications to transmit and receive upper layer data packets (L2CAP Service Data Units, SDU) up to 64 kilobytes in length. L2CAP also permits per-channel flow control and retransmission.
The L2CAP layer provides logical channels, named L2CAP channels, which are multiplexed over one or more logical links.
1.1. L2CAP features
The functional requirements for L2CAP include protocol/channel multiplexing, segmentation and reassembly (SAR), per-channel flow control, and error control. L2CAP sits above a lower layer composed of one of the following:
BR/EDR Controller
BR/EDR/LE Controller (supporting BR/EDR and LE)
LE Controller (supporting LE only)
L2CAP interfaces with upper layer protocols.
Figure 1.1 breaks down L2CAP into its architectural components. The Channel Manager provides the control plane functionality and is responsible for all internal signaling, L2CAP peer-to-peer signaling and signaling with higher and lower layers. It performs the state machine functionality described in Section 6 and uses message formats described in Section 4, and Section 5. The Retransmission and Flow Control block provides per-channel flow control and error recovery using packet retransmission. The Resource Manager is responsible for providing a frame relay service to the Channel Manager, the Retransmission and Flow Control block and those application data streams that do not require Retransmission and Flow Control services. It is responsible for coordinating the transmission and reception of packets related to multiple L2CAP channels over the facilities offered at the lower layer interface.
Protocol/channel multiplexing
L2CAP supports multiplexing over individual Controllers. An L2CAP channel shall operate over one Controller. An L2CAP channel cannot move between Controllers.
During channel setup, protocol multiplexing capability is used to route the connection to the correct upper layer protocol.
For data transfer, logical channel multiplexing is needed to distinguish between multiple upper layer entities. There may be more than one upper layer entity using the same protocol.
Segmentation and reassembly
With the frame relay service offered by the Resource Manager, the length of transport frames is controlled by the individual applications running over L2CAP. Many multiplexed applications are better served if L2CAP has control over the PDU length. This provides the following benefits:
Segmentation will allow the interleaving of application data units in order to satisfy latency requirements.
Memory and buffer management is easier when L2CAP controls the packet size.
Error correction by retransmission can be made more efficient.
The amount of data that is destroyed when an L2CAP PDU is corrupted or lost can be made smaller than the application's data unit.
The application is decoupled from the segmentation required to map the application packets into the lower layer packets.
Flow control per L2CAP channel
Controllers provide error and flow control for data going over the air and HCI flow control exists for data going over an HCI transport. When several data streams run over the same Controller using separate L2CAP channels, each channel requires individual flow control. A window based flow control scheme is provided.
Error control and retransmissions
Some applications require a residual error rate much smaller than some Controllers can deliver. L2CAP provides error checks and retransmissions of L2CAP PDUs. The error checking in L2CAP protects against errors due to Controllers falsely accepting packets that contain errors but pass Controller-based integrity checks. L2CAP error checking and retransmission also protect against loss of packets due to flushing by the Controller. The error control works in conjunction with flow control in the sense that the flow control mechanism will throttle retransmissions as well as first transmissions.
Support for Streaming
Streaming applications such as audio set up an L2CAP channel with an agreed-upon data rate and do not want flow control mechanisms, including those in the Controller, to alter the flow of data. A flush timeout is used to keep data flowing on the transmit side. Streaming mode is used to stop HCI and Controller based flow control from being applied on the receiving side.
Fragmentation and Recombination
Some Controllers may have limited transmission capabilities and may require fragment sizes different from those created by L2CAP segmentation. Therefore layers below L2CAP may further fragment and recombine L2CAP PDUs to create fragments which fit each layer’s capabilities. During transmission of an L2CAP PDU, many different levels of fragmentation and recombination may occur in both peer devices.
The HCI driver or Controller may fragment L2CAP PDUs to honor packet size constraints of a Host Controller Interface transport scheme. This results in HCI ACL Data packet payloads carrying start and continuation fragments of the L2CAP PDU. Similarly the Controller may fragment L2CAP PDUs to map them into Controller packets. This may result in Controller packet payloads carrying start and continuation fragments of the L2CAP PDU.
Each layer of the protocol stack may pass on different sized fragments of L2CAP PDUs, and the size of fragments created by a layer may be different in each peer device. However the PDU is fragmented within the stack, the receiving L2CAP entity still recombines the fragments to obtain the original L2CAP PDU.
Quality of Service
The L2CAP connection establishment process allows the exchange of information regarding the quality of service (QoS) expected between two Bluetooth devices. Each L2CAP implementation monitors the resources used by the protocol and ensures that QoS contracts are honored.
For a BR/EDR or BR/EDR/LE Controller, L2CAP may support both isochronous (Guaranteed) and asynchronous (Best Effort) data flows over the same ACL logical link by marking packets as automatically-flushable or non-automatically-flushable by setting the appropriate value for the Packet_Boundary_Flag in the HCI ACL Data packet (see [Vol 4] Part E, Section 5.4.2). Automatically-flushable L2CAP packets are flushed according to the automatic flush timeout set for the ACL logical link on which the L2CAP channels are mapped (see [Vol 4] Part E, Section 6.19). Non-automatically-flushable L2CAP packets are not affected by the automatic flush timeout and will not be flushed. All L2CAP packets can be flushed by using the HCI_Flush command (see [Vol 4] Part E, Section 7.3.4).
Note
Note: The terms "Guaranteed" and "Best Effort" are used as a shorthand to indicate that the implementation will or will not attempt to provide some level of quality of service. They do not make any statement as to what actual quality is provided; in particular, "Guaranteed" does not mean that successful delivery of data is guaranteed. Similarly, a "guarantee" is a set of resources (such as bandwidth and buffer space) allocated to a "Guaranteed" connection and does not mean that a specific data rate and latency will be provided under all possible circumstances.
1.2. Assumptions
The protocol is designed based on the following assumptions:
Controllers provide orderly delivery of data packets, although there might be individual packet corruption and duplicates. For devices with a BR/EDR or BR/EDR/LE Controller, no more than one ACL-U logical link exists between any two devices. For devices with a BR/EDR/LE or LE Controller, no more than one LE-U logical link exists between any two devices.
Controllers always provide the impression of full-duplex communication channels. This does not imply that all L2CAP communications are bi-directional. Unidirectional traffic does not require duplex channels.
The L2CAP layer provides a channel with a degree of reliability based on the mechanisms available in Controllers and with additional packet segmentation, error detection, and retransmission that can be enabled in the enhanced L2CAP layer. Some Controllers perform data integrity checks and resend data until it has been successfully acknowledged or a timeout occurs. Other Controllers will resend data up to a certain number of times whereupon the data is flushed. Because acknowledgments may be lost, timeouts may occur even after the data has been successfully sent.
Note
Note: The use of Baseband Broadcast packets in a BR/EDR or BR/EDR/LE Controller is unreliable and all broadcasts start the first segment of an L2CAP packet with the same sequence bit.
Controllers provide error and flow control for data going over the air and HCI flow control exists for data going over an HCI transport but some applications will want better error control than some Controllers provide. The Flow and Error Control block provides four modes. Enhanced Retransmission mode and Retransmission mode offer segmentation, flow control and L2CAP PDU retransmissions. Flow control mode offers just the segmentation and flow control functions. Streaming mode offers segmentation and receiver side packet flushing.
1.3. Scope
The following features are outside the scope of L2CAP’s responsibilities:
L2CAP does not transport synchronous data designated for SCO or eSCO logical transports.
L2CAP does not support a reliable broadcast channel. See Section 3.2.
1.4. Terminology
The following formal definitions apply:
Term | Description |
|---|---|
Upper layer | The system layer above the L2CAP layer, which exchanges data with L2CAP in the form of SDUs. The upper layer may be represented by an application or higher protocol entity known as the Service Level Protocol. The interface of the L2CAP layer with the upper layer is not specified. |
Lower layer | The system layer below the L2CAP layer, which exchanges data with the L2CAP layer in the form of PDUs, or fragments of PDUs. The lower layer is mainly represented within the Controller, however a Host Controller interface (HCI) may be involved, such that an HCI Host driver could also be seen as the lower layer. Except for the HCI functional specification (in case HCI is involved) the interface between L2CAP and the lower layer is not specified. |
L2CAP channel | The logical connection between two endpoints in peer devices, characterized by their Channel Identifiers (CID), which is multiplexed over one Controller based logical link. |
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 here. The term SDU is associated with data originating from upper layer entities only, i.e. does not include any protocol information generated by L2CAP procedures. |
Segment, or SDU segment | A part of an SDU, as resulting from the Segmentation procedure. An SDU may be split into one or more segments. Note: This term is relevant only to Enhanced Retransmission mode, Streaming mode, Retransmission mode, Flow Control mode, LE Credit Based Flow Control mode, and Enhanced Credit Based Flow Control mode, not to the Basic L2CAP mode. |
Segmentation | A procedure used in the L2CAP Retransmission and Flow Control modes, resulting in an SDU being split into one or more smaller units, called Segments, as appropriate for the transport over an L2CAP channel. Note: This term is relevant only to the Enhanced Retransmission mode, Streaming mode, Retransmission mode, Flow Control mode, LE Credit Based Flow Control mode, and Enhanced Credit Based Flow Control mode, not to the Basic L2CAP mode. |
Reassembly | The reverse procedure corresponding to Segmentation, resulting in an SDU being re-established from the segments received over an L2CAP channel, for use by the upper layer. The interface between the L2CAP and the upper layer is not specified; therefore, reassembly may actually occur within an upper layer entity although it is conceptually part of the L2CAP layer. Note: This term is relevant only to Enhanced Retransmission mode, Streaming mode, Retransmission mode, Flow Control mode, LE Credit Based Flow Control mode, and Enhanced Credit Based Flow Control mode, not to the Basic L2CAP mode. |
PDU, or L2CAP PDU | Protocol Data Unit: a packet of data containing L2CAP protocol information fields, control information, and/or upper layer information data. A PDU is always started by a Basic L2CAP header. Types of PDUs are: B-frames, I-frames, S-frames, C-frames, G-frames, and K-frames. |
Basic L2CAP header | Minimum L2CAP protocol information that is present in the beginning of each PDU: a PDU length field and a field containing the Channel Identifier (CID). |
Basic information frame (B‑frame) | A B-frame is a PDU used in the Basic L2CAP mode for L2CAP data packets. It contains a complete SDU as its payload, encapsulated by a Basic L2CAP header. |
Information frame (I‑frame) | An I-frame is a PDU used in Enhanced Retransmission mode, Streaming mode, Retransmission mode, and Flow Control mode. It contains an SDU segment and additional protocol information, encapsulated by a Basic L2CAP header. |
Supervisory frame (S‑frame) | An S-frame is a PDU used in Enhanced Retransmission mode, Retransmission mode, and Flow Control mode. It contains protocol information only, encapsulated by a Basic L2CAP header, and no SDU data. |
Control frame (C‑frame) | A C-frame is a PDU that contains L2CAP signaling messages exchanged between the peer L2CAP entities. C-frames are exclusively used on the L2CAP signaling channels. |
Group frame (G‑frame) | A G-frame is a PDU exclusively used on the Connectionless L2CAP channel. It is encapsulated by a Basic L2CAP header and contains the PSM followed by the completed SDU. G-frames may be used to broadcast data to active Peripherals via Active Peripheral Broadcast or to send unicast data to a single remote device. |
Credit-based frame (K‑frame) | A K-frame is a PDU used in LE Credit Based Flow Control mode and Enhanced Credit Based Flow Control mode. It contains an SDU segment and additional protocol information, encapsulated by a Basic L2CAP header. |
Fragment | A part of a PDU, as resulting from a fragmentation operation. Fragments are used only in the delivery of data to and from the lower layer. They are not used for peer-to-peer transportation. A fragment may be a Start or Continuation Fragment with respect to the L2CAP PDU. A fragment does not contain any protocol information beyond the PDU; the distinction of start and continuation fragments is transported by lower layer protocol provisions. Note: Start Fragments always either begin with the first octet of the Basic L2CAP header of a PDU or they have a length of zero (see [Vol 2] Part B, Section 6.6.2). |
Fragmentation | A procedure used to split L2CAP PDUs to smaller parts, named fragments, appropriate for delivery to the lower layer transport. Although described within the L2CAP layer, fragmentation may actually occur in an HCI Host driver, and/or in a Controller, to accommodate the L2CAP PDU transport to HCI ACL Data packet or Controller packet sizes. Fragmentation of PDUs may be applied in all L2CAP modes. |
Recombination | The reverse procedure corresponding to fragmentation, resulting in an L2CAP PDU re-established from fragments. In the receive path, full or partial recombination operations may occur in the Controller and/or the Host, and the location of recombination does not necessarily correspond to where fragmentations occurs on the transmit side. |
Maximum Transmission Unit (MTU) | The maximum size of an SDU, in octets, that the upper layer entity is capable of accepting. |
Payload Size | The amount of SDU data in a single PDU, in octets; equivalently, the number of octets in the Information Payload field of a PDU. |
Maximum PDU payload Size (MPS) | The maximum payload size in octets that the L2CAP layer entity is capable of accepting. In the absence of segmentation, or in the Basic L2CAP mode, the Maximum Transmission Unit is the same as the Maximum PDU payload Size and the two configuration parameters shall be set to the same value. |
Signaling MTU (MTUsig) | The maximum size of command information that the L2CAP layer entity is capable of accepting. The MTUsig, refers to the signaling channel only and corresponds to the maximum size of a C-frame, excluding the Basic L2CAP header. The MTUsig value of a peer is discovered when a C-frame that is too large is rejected by the peer. |
Connectionless MTU (MTUcnl) | The maximum size of the connection packet information that the L2CAP layer entity is capable of accepting. The MTUcnl refers to the connectionless channel only and corresponds to the maximum G-frame, excluding the Basic L2CAP header and the PSM which immediately follows it. The MTUcnl of a peer can be discovered by sending an L2CAP_INFORMATION_REQ packet. |
MaxTransmit | In Enhanced Retransmission mode and Retransmission mode, MaxTransmit controls the number of transmissions of a PDU that L2CAP is allowed to try before assuming that the PDU (and the link) is lost. The minimum value is 1 (only 1 transmission permitted). In Enhanced Retransmission mode a value 0 means infinite transmissions. Note: Setting MaxTransmit to 1 prohibits PDU retransmissions. Failure of a single PDU will cause the link to drop. By comparison, in Flow Control mode, failure of a single PDU will not necessarily cause the link to drop. |
2. General operation
L2CAP is based around the concept of ’channels’. Each one of the endpoints of an L2CAP channel is referred to by a channel identifier (CID).
2.1. Channel identifiers
A channel identifier (CID) is the local name representing a logical channel endpoint on the device. The scope of CIDs is related to the logical link as shown in Figure 2.1. The null identifier (0x0000) shall not be used as a destination endpoint. Identifiers from 0x0001 to 0x003F are reserved for specific L2CAP functions. These channels are referred to as fixed channels. An implementation of L2CAP shall support the fixed channel 0x0001 (see Table 2.1) on all ACL‑U logical links and the fixed channels 0x0004, 0x0005, and 0x0006 (see Table 2.3) on all LE‑U logical links. Other fixed channels may be supported on each logical link. The L2CAP_INFORMATION_REQ / L2CAP_INFORMATION_RSP mechanism (described in Section 4.10 and Section 4.11) shall be used to determine which fixed channels a remote device supports over the ACL-U logical link. Each fixed channel has the same CID at each end of the logical link carrying the channel.
The characteristics of each fixed channel are defined on a per channel basis. Fixed channel characteristics include configuration parameters (e.g., reliability, MTU size, QoS), security, and the ability to change parameters using the L2CAP configuration mechanism. Table 2.1 lists the defined fixed channels, provides a reference to where the associated channel characteristics are defined and specifies the logical link over which the channel may operate. Fixed channels are available as soon as the ACL-U or LE-U logical link is set up. All initialization that is normally performed when a channel is created shall be performed for each of the supported fixed channels when the ACL-U or LE-U logical link is set up. Fixed channels shall only run over ACL-U, APB-U, or LE-U logical links.
Implementations are free to manage the remaining CIDs in a manner best suited for that particular implementation, with the provision that two simultaneously active L2CAP channels on the same logical link (i.e., to the same peer device using the same transport) shall not share the same CID. A different CID name space exists for each ACL-U, APB-U, and LE-U logical link. Table 2.1 to Table 2.3 summarize the definition and partitioning of the CID name space for each type of logical link.
Assignment of dynamically allocated CIDs is relative to a particular logical link and a device can assign CIDs independently from other devices. Thus, even if the same CID value has been assigned to (remote) channel endpoints by several remote devices connected to a single local device, the local device can still uniquely associate each remote CID with a different device. Further, even if the same CID value has been assigned to (remote) channel endpoints by the same remote device, these can be distinguished because they will be bound to a different logical link.
The CID name space for ACL-U logical links is as follows:
CID | Description | Channel Characteristics |
|---|---|---|
0x0000 | Null identifier | Not allowed |
0x0001 | L2CAP Signaling channel | See Section 4 |
0x0002 | Connectionless channel | See Section 7.6 |
0x0003 | Previously used | Not applicable |
0x0007 | BR/EDR Security Manager | See [Vol 3] Part H |
0x003F | Previously used | Not applicable |
0x0040 to 0xFFFF | Dynamically allocated | Communicated using L2CAP configuration mechanism (see Section 7.1) or the L2CAP credit based create connection mechanism (see Section 4.25) |
All other values | Reserved for future use | Not applicable |
The CID name space for APB-U logical links is as follows:
CID | Description | Channel Characteristics |
|---|---|---|
0x0000 | Null identifier | Not allowed |
0x0002 | Connectionless channel | See Section 7.6 |
All other values | Reserved for future use | Not applicable |
The CID name space for LE-U logical links is as follows:
CID | Description | Channel Characteristics |
|---|---|---|
0x0000 | Null identifier | Not Allowed |
0x0004 | Attribute Protocol | See [Vol 3] Part F |
0x0005 | L2CAP LE Signaling channel | See Section 4 |
0x0006 | Security Manager protocol | See [Vol 3] Part H |
0x0020 to 0x003E | ||
0x0040 to 0x007F | Dynamically allocated | Communicated using the L2CAP LE credit based create connection mechanism (see Section 4.22) or the L2CAP credit based create connection mechanism (see Section 4.25) |
All other values | Reserved for future use | Not applicable |
2.2. Operation between devices
Figure 2.2 illustrates the use of CIDs in a communication between corresponding peer L2CAP entities in separate devices. The connection-oriented data channels represent a connection between two devices, where a CID, combined with the logical link, identifies each endpoint of the channel. When used for broadcast transmissions, the connectionless channel restricts data flow to a single direction. The connectionless channel may be used to transmit data to all active Peripherals, using Active Peripheral Broadcast. When used for unicast transmissions the connectionless channel may be used in either direction between a Central and a Peripheral.
There are also a number of CIDs reserved for special purposes. The L2CAP signaling channels are examples of reserved channels. Fixed channel 0x0001 is used to create and establish connection-oriented data channels and to negotiate changes in the characteristics of connection-oriented channels and to discover characteristics of the connectionless channel operating over the ACL-U logical link.
The L2CAP Signaling channel (0x0001) and all supported fixed channels are available immediately when the ACL-U logical link is established between two devices. Another CID (0x0002) is reserved for all incoming and outgoing connectionless data traffic, whether broadcast or unicast. Connectionless data traffic may flow immediately once the ACL-U logical link is established between two devices and once the transmitting device has determined that the remote device supports connectionless traffic.
The L2CAP LE Signaling channel (0x0005) and all supported fixed channels are available immediately when the LE-U logical link is established between two devices.
Table 2.4 describes the various channel types and their source and destination identifiers. A dynamically allocated CID is allocated to identify, along with the logical link, the local endpoint and shall be in the range 0x0040 to 0xFFFF for ACL-U, 0x0040 to 0x007F for LE-U. Section 6 describes the state machine associated with each connection-oriented channel with a dynamically allocated CID. Section 3.1 and Section 3.3 describe the packet format associated with connection-oriented channels. Section 3.2 describes the packet format associated with the connectionless channel.
Channel Type | Local CID (sending) | Remote CID (receiving) |
|---|---|---|
Connection-oriented | Dynamically allocated and fixed | Dynamically allocated and fixed |
Connectionless data | 0x0002 (fixed) | 0x0002 (fixed) |
L2CAP Signaling | 0x0001 and 0x0005 (fixed) | 0x0001 and 0x0005 (fixed) |
2.3. Operation between layers
L2CAP implementations should follow the general architecture described below. L2CAP implementations transfer data between upper layer protocols and the lower layer protocol. This document lists a number of services that should be exported by any L2CAP implementation. Each implementation shall also support a set of signaling commands for use between L2CAP implementations. L2CAP implementations should also be prepared to accept certain types of events from lower layers and generate events to upper layers. How these events are passed between layers is implementation specific.
2.4. Modes of operation
L2CAP channels may operate in one of several different modes as selected for each L2CAP channel.
The modes are:
Basic L2CAP mode (BR/EDR and some LE fixed channels only)
Flow Control mode (BR/EDR only)
Retransmission mode (BR/EDR only)
Enhanced Retransmission mode (BR/EDR only)
Streaming mode (BR/EDR only)
LE Credit Based Flow Control mode (LE only)
Enhanced Credit Based Flow Control mode (BR/EDR and LE)
The modes are enabled using the configuration procedure described in Section 7.1. The Basic L2CAP mode shall be the default mode, which is used when no other mode is agreed. Enhanced Retransmission mode shall be used for ACL-U logical links operating as described in Section 7.10. Enhanced Retransmission mode should be enabled for reliable channels created over ACL-U logical links not operating as described in Section 7.10. Streaming mode shall be used for ACL-U logical links operating as described in Section 7.10. Streaming mode should be enabled for streaming applications created over ACL-U logical links not operating as described in Section 7.10. Enhanced Retransmission mode, Enhanced Credit Based Flow Control mode, or Streaming mode should be enabled when supported by both L2CAP entities. Flow Control mode and Retransmission mode shall only be enabled when communicating with L2CAP entities that do not support Enhanced Retransmission mode, Enhanced Credit Based Flow Control mode, or Streaming mode.
In Flow Control mode, Retransmission mode, and Enhanced Retransmission mode, PDUs exchanged with a peer entity are numbered and acknowledged. The sequence numbers in the PDUs are used to control buffering, and a TxWindow size is used to limit the required buffer space and/or provide a method for flow control.
In Flow Control mode no retransmissions take place, but missing PDUs are detected and can be reported as lost.
In Retransmission mode a timer is used to ensure that all PDUs are delivered to the peer, by retransmitting PDUs as needed. A go-back-n repeat mechanism is used to simplify the protocol and limit the buffering requirements.
Enhanced Retransmission mode is similar to Retransmission mode. It adds the ability to set a POLL bit to solicit a response from a remote L2CAP entity, adds the SREJ S-frame to improve the efficiency of error recovery and adds an RNR S-frame to replace the R-bit for reporting a local busy condition.
Streaming mode is for real-time isochronous traffic. PDUs are numbered but are not acknowledged. A finite flush timeout is set on the sending side to flush packets that are not sent in a timely manner. On the receiving side if the receive buffers are full when a new PDU is received then a previously received PDU is overwritten by the newly received PDU. Missing PDUs can be detected and reported as lost. TxWindow size is not used in Streaming mode.
LE Credit Based Flow Control mode is used for LE L2CAP connection-oriented channels for flow control using a credit based scheme for L2CAP data (i.e. not signaling packets).
Enhanced Credit Based Flow Control mode is used for L2CAP connection-oriented channels on both LE and BR/EDR for flow control using a credit-based scheme for L2CAP data (i.e. not signaling packets). A BR/EDR/LE device that implements Enhanced Credit Based Flow Control mode may support it on BR/EDR only, on LE only, or on both.
Enhanced Retransmission mode should be used instead of Enhanced Credit Based Flow Control mode for data being transmitted over BR/EDR.
Care should be taken in selecting the parameters used for Enhanced Retransmission mode and Streaming mode when they are used beneath legacy profile implementations to ensure that performance is not negatively impacted relative to the performance achieved when using the same profile with Basic mode on an ACL-U logical link. It may be preferable to configure Basic mode to minimize the risk of negative performance impacts.
2.5. Mapping channels to logical links
L2CAP maps channels to Controller logical links, which in turn run over Controller physical links. All logical links going between a local Controller and remote Controller run over a single physical link. There is one ACL-U logical link per BR/EDR physical link and one LE-U logical link per LE physical link.
All Best Effort and Guaranteed channels going over a BR/EDR physical link between two devices shall be mapped to a single ACL-U logical link. All channels going over an LE physical link between two devices shall be treated as best effort and mapped to a single LE-U logical link.
When a Guaranteed channel is created, a corresponding Guaranteed logical link shall be created to carry the channel traffic. Creation of a Guaranteed logical link involves admission control. Admission control is verifying that the guarantee can be achieved without compromising existing guarantees. For a BR/EDR Controller, admission control (creation of a Guaranteed logical link) shall be performed by the L2CAP layer.
3. Data packet format
L2CAP is packet-based but follows a communication model based on channels. A channel represents a data flow between L2CAP entities in remote devices. Channels may be connection-oriented or connectionless. All channels other than the L2CAP connectionless channel (CID 0x0002) and the two L2CAP signaling channels (CIDs 0x0001 and 0x0005) are connection-oriented. All L2CAP layer packet fields shall use little-endian byte order with the exception of the information payload field. The endianness of higher layer protocols encapsulated within L2CAP information payload is protocol-specific.
If a PDU is received on a CID that is not assigned or is reserved for future use on the logical link type, the recipient shall ignore that PDU.
In all L2CAP PDUs, the PDU Length field indicates the size of the entire L2CAP PDU in octets, excluding the 4 octets of the Basic L2CAP header. Therefore a PDU cannot be more than 65539 octets long.
In PDUs that contain an Information Payload field, the number of octets in that field (the payload size) shall not be greater than the peer device's MPS for the channel.
3.1. Connection-oriented channels in Basic L2CAP mode
Figure 3.1 illustrates the format of the L2CAP PDU used on connection-oriented channels. In basic L2CAP mode, the L2CAP PDU on a connection-oriented channel is also referred to as a "B-frame".
The fields shown are:
PDU Length: 2 octets (16 bits)
For B-frames, the PDU Length equals the payload size and can be up to 65535 octets. The PDU Length field is used for recombination and serves as a simple integrity check of the recombined L2CAP packet on the receiving end.
Channel ID: 2 octets
The channel ID (CID) identifies the destination channel endpoint of the packet.
Information payload: 0 to 65535 octets
This contains the payload received from the upper layer protocol (outgoing packet), or delivered to the upper layer protocol (incoming packet). The payload size shall not be greater than the peer device's MTU for the channel. The MTU for channels with dynamically allocated CIDs is determined during channel configuration (see Section 5.1). The minimum supported MTU values for the signaling PDUs are shown in Table 4.1.
3.2. Connectionless data channel in Basic L2CAP mode
Figure 3.2 illustrates the L2CAP PDU format within a connectionless data channel. Here, the L2CAP PDU is also referred to as a "G-frame".
The fields shown are:
PDU Length: 2 octets
For G-frames, the PDU Length equals the payload size plus the number of octets in the PSM.
Channel ID: 2 octets
Channel ID (0x0002) reserved for connectionless traffic.
Protocol/Service Multiplexer (PSM): 2 octets (minimum)
For information on the PSM field see Section 4.2.
Information payload: 0 to 65533 octets
This parameter contains the payload information to be distributed to all Peripherals in the piconet for broadcast connectionless traffic, or to a specific remote device for data sent via the L2CAP connectionless channel. The payload size shall not be greater than the peer device's MTU for the channel. Implementations shall support a connectionless MTU (MTUcnl) of 48 octets on the connectionless channel. Devices may also explicitly change to a larger or smaller connectionless MTU (MTUcnl).
Note
Note: The maximum size of the Information payload field decreases accordingly if the PSM field is extended beyond the two octet minimum.
3.3. Connection-oriented channel in Retransmission/Flow Control/Streaming modes
To support flow control, retransmissions, and streaming, L2CAP PDU types with protocol elements in addition to the Basic L2CAP header are defined. The information frames (I-frames) are used for information transfer between L2CAP entities. The supervisory frames (S-frames) are used to acknowledge I-frames and request retransmission of I-frames. Figure 3.3 illustrates these frames.
3.3.1. L2CAP header fields
PDU Length: 2 octets
For I-frames and S-frames, the PDU Length equals the sum of the octet lengths of the Control, L2CAP SDU Length (when present), Information Payload, and frame check sequence (FCS) (when present) fields. The PDU Length field of an S-frame therefore equals 2, 4, or 6.
The maximum number of Information octets (the payload size) in one I-frame is based on which fields are present and the type of the Control Field. The maximum number of Information octets in an I-frame with a Standard Control field is as follows:
L2CAP SDU Length present and FCS present
65529 octets
L2CAP SDU Length present and FCS not present
65531 octets
L2CAP SDU Length not present and FCS present
65531 octets
L2CAP SDU Length not present and FCS not present
65533 octets
The maximum number of Information octets in an I-frame with an Extended Control field is as follows:
L2CAP SDU Length present and FCS present
65527 octets
L2CAP SDU Length present and FCS not present
65529 octets
L2CAP SDU Length not present and FCS present
65529 octets
L2CAP SDU Length not present and FCS not present
65531 octets
Channel ID: 2 octets
This field contains the Channel Identification (CID).
3.3.2. Control field
The Control Field identifies whether the frame is an S-frame or I-frame and contains various information about the frame. There are three different Control Field formats: the Standard Control Field, the Enhanced Control Field, and the Extended Control Field. Which format is used is determined by the mode and is not indicated within the frame. The Standard Control Field shall be used for Retransmission mode and Flow Control mode. The Enhanced and Extended Control Fields shall be used for Enhanced Retransmission mode and Streaming mode. The Enhanced Control Fields shall be used until the first successful use of the Extended Window Size option (see Section 5.7) and Extended Control Fields thereafter. The Control Field will contain sequence numbers where applicable. Its coding is shown in Figure 3.4 to Figure 3.9. There are two different frame types, Information frame types and Supervisory frame types. Information and Supervisory frames types are distinguished by the least significant bit in the Control Field.
Information frame format (I-frame)
The I-frames are used to transfer information between L2CAP entities. Each I-frame has a TxSeq(Send sequence number), ReqSeq(Receive sequence number) which can acknowledge additional I-frames received by the data Link Layer entity. Each I-frame with a Standard Control field has a retransmission bit (R bit) that affects whether I-frames are retransmitted. Each I-frame with an Enhanced Control Field or an Extended Control Field has an F-bit that is used in Poll/Final bit functions.
The SAR field in the I-frame is used for segmentation and reassembly control. The L2CAP SDU Length field specifies the length of an SDU, including the aggregate length across all segments if segmented.
Supervisory frame format (S-frame)
S-frames are used to acknowledge I-frames and request retransmission of I-frames. Each S-frame has an ReqSeq sequence number which may acknowledge additional I-frames received by the data Link Layer entity. Each S-frame with a Standard Control Field has a retransmission bit (R bit) that affects whether I-frames are retransmitted. Each S-frame with an Enhanced Control field or an Extended Control Field has a Poll bit (P-bit) and a Final bit (F-bit) and does not have an R-bit.
Defined types of S-frames are RR (Receiver Ready), REJ (Reject), RNR (Receiver Not Ready) and SREJ (Selective Reject).
Type
The type bit shall be 0 for an I-frame and 1 for an S-frame.
Send Sequence Number - TxSeq
The send sequence number is used to number each I-frame, to enable sequencing and retransmission.
Receive Sequence Number - ReqSeq
The receive sequence number is used by the receiver side to acknowledge I-frames, and in the REJ and SREJ frames to request the retransmission of an I-frame with a specific send sequence number.
Retransmission Disable Bit - R
The Retransmission Disable bit is used to implement Flow Control. The receiver sets the bit when its internal receive buffer is full, this happens when one or more I-frames have been received but the SDU reassembly function has not yet pulled all the frames received. When the sender receives a frame with the Retransmission Disable bit set it shall disable the RetransmissionTimer, this causes the sender to stop retransmitting I-frames.
R=0: Normal operation. Sender uses the RetransmissionTimer to control retransmission of I-frames. Sender does not use the MonitorTimer.
R=1: Receiver side requests sender to postpone retransmission of I-frames. Sender monitors signaling with the MonitorTimer. Sender does not use the RetransmissionTimer.
The functions of ReqSeq and R are independent.
Segmentation and Reassembly - SAR
The SAR bits define whether an L2CAP SDU is segmented. For segmented SDUs, the SAR bits also define which part of an SDU is in this I-frame, thus allowing one L2CAP SDU to span several I-frames.
An I-frame with SAR=”Start of L2CAP SDU” also contains an L2CAP SDU Length field, specifying the number of information octets in the total L2CAP SDU. The encoding of the SAR bits is shown in Table 3.1.
0b00
Unsegmented L2CAP SDU
0b01
Start of L2CAP SDU
0b10
End of L2CAP SDU
0b11
Continuation of L2CAP SDU
Table 3.1: SAR control element formatSupervisory function - S
The S-bits mark the type of S-frame. There are four types defined: RR (Receiver Ready), REJ (Reject), RNR (Receiver Not Ready) and SREJ (Selective Reject). The encoding is shown in Table 3.2.
0b00
RR - Receiver Ready
0b01
REJ - Reject
0b10
RNR - Receiver Not Ready
0b11
SREJ - Select Reject
Table 3.2: S control element format: type of S-framePoll - P
The P-bit is set to 1 to solicit a response from the receiver. The receiver shall respond immediately with a frame with the F-bit set to 1.
Final - F
The F-bit is set to 1 in response to an S-frame with the P bit set to 1.
3.3.3. L2CAP SDU Length field (2 octets)
When an SDU spans more than one I-frame, the first I-frame in the sequence shall be identified by SAR=0b01=”Start of L2CAP SDU”. The L2CAP SDU Length field shall specify the total number of octets in the SDU and shall not be greater than the peer device's MTU for the channel. The L2CAP SDU Length field shall be present in I-frames with SAR=0b01 (Start of L2CAP SDU) and shall not be used in any other I-frames. When the SDU is unsegmented (SAR=0b00), the L2CAP SDU Length field is not needed and shall not be present.
3.3.4. Information Payload field
The information payload field consists of an integer number of octets. The maximum number of octets in this field is the same as the negotiated value of the MPS configuration parameter. The maximum number of octets in this field also depends on which other fields are present (see Section 3.3.1). If SAR=0b00 (Unsegmented L2CAP SDU) then the payload size shall not be greater than the peer device's MTU for the channel.
3.3.5. Frame Check Sequence (2 octets)
The Frame Check Sequence (FCS) is 2 octets. This field is mandatory in Retransmission and Flow Control modes. Whether it is present or absent in Enhanced Retransmission and Streaming modes is configurable (see Section 5.5).
The FCS is constructed using the generator polynomial g(D) = D16 + D15 + D2 + 1 (see Figure 3.10). The 16 bit LFSR is initially loaded with the value 0x0000, as depicted in Figure 3.11. The switch S is set in position 1 while data is shifted in, LSB first for each octet. After the last bit has entered the LFSR, the switch is set in position 2, and the register contents are transmitted from right to left (i.e. starting with position 15, then position 14, etc.). The FCS covers the Basic L2CAP header, Control, L2CAP SDU Length, and Information Payload fields, if present, as shown in Figure 3.3.
Examples of FCS calculation, g(D) = D16 + D15 + D2 + 1:
I Frame
PDU Length = 14 Channel ID = 0x0040 Control = 0x0002 (SAR=0b00, ReqSeq=0b000000, R=0, TxSeq=0b000001) Information Payload = 00 01 02 03 04 05 06 07 08 09 (10 octets, hexadecimal notation) ==> FCS = 0x6138 ==> Data to Send = 0E 00 40 00 02 00 00 01 02 03 04 05 06 07 08 09 38 61 (hexadecimal notation)
RR Frame
PDU Length = 4 Channel ID = 0x0040 Control = 0x0101 (ReqSeq=0b000001, R=0, S=0b00) ==> FCS = 0x14D4 ==> Data to Send = 04 00 40 00 01 01 D4 14 (hexadecimal notation)
3.3.6. Invalid Frame Detection (Retransmission and Flow Control modes)
For Retransmission mode and Flow Control mode, a received PDU shall be regarded as invalid if one of the following conditions occurs:
Contains an unknown CID.
Contains an FCS error.
I-frame with a payload size greater than the maximum PDU payload size (MPS).
I-frame that has fewer than 8 octets (i.e., PDU Length less than 4).
I-frame with SAR=0b01 (Start of L2CAP SDU) that has fewer than 10 octets (i.e., PDU Length less than 6).
I-frame with SAR bits that do not correspond to a normal sequence of either unsegmented or start, continuation, end for the given CID.
S-frame where the PDU Length field is not equal to 4.
These error conditions may be used for error reporting.
3.3.7. Invalid Frame Detection algorithm
For Enhanced Retransmission mode and Streaming mode the following algorithm shall be used for received PDUs. It may be used for Retransmission mode and Flow Control mode:
Check the CID. If the PDU contains an unknown CID then it shall be ignored.
Check the FCS. If the PDU contains an FCS error then it shall be ignored. If the channel is configured to use "No FCS" then the PDU is considered to have a good FCS (no FCS error).
Check the following conditions. If one of the conditions occurs the channel shall be closed or in the case of fixed channels the ACL shall be disconnected.
I-frame with a payload size greater than the maximum PDU payload size (MPS).
I-frame that has fewer than the required number of octets. If the channel is configured to use a Standard or Enhanced Control Field then the required number of octets is 6 if "No FCS" is configured; otherwise, it is 8. If the channel is configured to use the Extended Control Field then the required number of octets is 8 if "No FCS" is configured; otherwise, it is 10.
S-frame where the PDU Length field is invalid. If the channel is configured to use a Standard or Enhanced Control Field then the PDU Length field shall be 2 if "No FCS" is configured; otherwise, the PDU Length field shall be 4. If the channel is configured to use the Extended Control Field then the PDU Length field shall be 4 if "No FCS" is configured; otherwise, the PDU Length field shall be 6.
Check the SAR bits. The SAR check is performed after the frame has been successfully received in the correct sequence. The PDU is invalid if one of the following conditions occurs:
I-frame with SAR=0b01 (Start of L2CAP SDU) that has fewer than the required number of octets. If the channel is configured to use a Standard or Enhanced Control field then the required number of octets is 8 if "No FCS" is configured; otherwise, the required number of octets is 10. If the channel is configured to use an Extended Control field then the required number of octets is 10 if "No FCS" is configured; otherwise, the required number of octets is 12.
I-frame with SAR bits that do not correspond to a normal sequence of either unsegmented or start, continuation, end for the given CID.
I-frame with SAR= 0b01 (Start of L2CAP SDU) where the value in the L2CAP SDU Length field exceeds the configured MTU.
If the I-frame has been received in the correct sequence and is invalid as described in 4 then the channel shall be closed or in the case of fixed channels the ACL shall be disconnected. For Streaming mode and Flow Control mode if one or more I-frames are missing from a sequence of I-frames using SAR bits of start, continuation and end then received I-frames in the sequence may be ignored. For Flow Control mode and Streaming mode I-frames received out of sequence with SAR bits of unsegmented may be accepted.
If the algorithm is used for Retransmission mode or Flow control mode then it shall be used instead of Invalid Frame detection described in Section 3.3.6.
These error conditions may be used for error reporting.
3.4. Connection-oriented channels in LE Credit Based Flow Control mode and Enhanced Credit Based Flow Control mode
To support LE Credit Based Flow Control mode and Enhanced Credit Based Flow Control mode, an L2CAP PDU type with protocol elements in addition to the Basic L2CAP header is defined. In LE Credit Based Flow Control mode and Enhanced Credit Based Flow Control mode, the L2CAP PDU on a connection-oriented channel is a Credit-based frame (K-frame) as illustrated in Figure 3.12.
3.4.1. L2CAP Header fields
PDU Length: 2 octets
For K-frames, the PDU Length field equals the payload size plus the octet length of the L2CAP SDU Length (when present).
Channel ID: 2 octets
The channel ID (CID) identifies the destination channel endpoint of the packet.
3.4.2. L2CAP SDU Length field (2 octets)
The first K-frame of the SDU shall contain the L2CAP SDU Length field that shall specify the total number of octets in the SDU. The value shall not be greater than the peer device's MTU for the channel. All subsequent K-frames that are part of the same SDU shall not contain the L2CAP SDU Length field.
3.4.3. Information Payload field
The information payload field consists of an integer number of octets.
The number of octets contained in the first K-frame information payload of the SDU is equal to the PDU Length minus 2 octets. All subsequent K-frames of the same SDU contain the number of octets in the information payload equal to the PDU Length.
If the SDU length field value exceeds the receiver's MTU, the receiver shall disconnect the channel. If the payload size of any K-frame exceeds the receiver's MPS, the receiver shall disconnect the channel. If the sum of the payload sizes for the K-frames exceeds the specified SDU length, the receiver shall disconnect the channel.
4. Signaling packet formats
This section describes the signaling commands passed between two L2CAP entities on peer devices. All signaling commands are sent over a signaling channel. The signaling channel for managing channels over ACL-U logical links shall use CID 0x0001 and the signaling channel for managing channels over LE-U logical links shall use CID 0x0005. Signaling channels are available as soon as the lower layer logical transport is set up and L2CAP traffic is enabled. Figure 4.1 illustrates the general format of L2CAP PDUs containing signaling commands (C-frames). Multiple commands may be sent in a single C-frame over fixed channel CID 0x0001 while only one command per C-frame shall be sent over fixed channel CID 0x0005. Commands take the form of requests, responses, and indications. All L2CAP implementations shall support the reception of C-frames with a payload size that does not exceed the signaling MTU. The minimum supported payload size for the C-frame (MTUsig) is defined in Table 4.1. L2CAP implementations should not use C-frames that exceed the MTUsig of the peer device. If a device receives a C-frame that exceeds its MTUsig then it shall send an L2CAP_COMMAND_REJECT_RSP packet containing the supported MTUsig. Implementations shall be able to handle the reception of multiple commands in an L2CAP packet sent over fixed channel CID 0x0001.
Note
Note: The name of a signalling packet has a suffix indicating its type: _REQ for requests, _RSP for responses, and _IND for indications.
A signaling packet that is not correctly formed is invalid behavior (see [Vol 1] Part E, Section 2.7). Examples of signaling packets that are not correctly formed include:
The packet is less than 4 octets long.
The Data Length field is not correct for the type of packet, such as an L2CAP_CONNECTION_REQ packet with a Data Length other than 4 or an L2CAP_INFORMATION_RSP with InfoType = 0x0003, Result = 0x0000, and Data Length not equal to 12.
The PDU Length of the C-frame does not equal the sum of the sizes of the contained packets.
The Reason or Status field has an unknown value.
A C-frame on fixed channel 0x0005 contains more than one signaling packet.
Logical Link | Minimum Supported Payload Size for the C-frame (MTUsig) |
|---|---|
ACL-U not supporting Extended Flow Specification | 48 octets |
ACL-U supporting the Extended Flow Specification feature | 672 octets |
LE-U | 23 octets |
For C-frames, the PDU Length equals the payload size.
Figure 4.2 displays the general format of all signaling commands.
The fields shown are:
Code (1 octet)
The Code field is one octet long and identifies the type of command. When a packet is received with a Code field that is unknown or disallowed on the signaling channel it is received on, an L2CAP_COMMAND_REJECT_RSP packet (defined in Section 4.1) is sent in response.
Table 4.2 lists the codes defined by this document. All codes are specified with the most significant bit in the left-most position.
Code | Description | CIDs on which Code is Allowed |
|---|---|---|
0x01 | L2CAP_COMMAND_REJECT_RSP | 0x0001 and 0x0005 |
0x02 | L2CAP_CONNECTION_REQ | 0x0001 |
0x03 | L2CAP_CONNECTION_RSP | 0x0001 |
0x04 | L2CAP_CONFIGURATION_REQ | 0x0001 |
0x05 | L2CAP_CONFIGURATION_RSP | 0x0001 |
0x06 | L2CAP_DISCONNECTION_REQ | 0x0001 and 0x0005 |
0x07 | L2CAP_DISCONNECTION_RSP | 0x0001 and 0x0005 |
0x08 | L2CAP_ECHO_REQ | 0x0001 |
0x09 | L2CAP_ECHO_RSP | 0x0001 |
0x0A | L2CAP_INFORMATION_REQ | 0x0001 |
0x0B | L2CAP_INFORMATION_RSP | 0x0001 |
0x0C to 0x11 | Previously used | None |
0x12 | L2CAP_CONNECTION_PARAMETER_UPDATE_REQ | 0x0005 |
0x13 | L2CAP_CONNECTION_PARAMETER_UPDATE_RSP | 0x0005 |
0x14 | L2CAP_LE_CREDIT_BASED_CONNECTION_REQ | 0x0005 |
0x15 | L2CAP_LE_CREDIT_BASED_CONNECTION_RSP | 0x0005 |
0x16 | L2CAP_FLOW_CONTROL_CREDIT_IND | 0x0001 and 0x0005 |
0x17 | L2CAP_CREDIT_BASED_CONNECTION_REQ | 0x0001 and 0x0005 |
0x18 | L2CAP_CREDIT_BASED_CONNECTION_RSP | 0x0001 and 0x0005 |
0x19 | L2CAP_CREDIT_BASED_RECONFIGURE_REQ | 0x0001 and 0x0005 |
0x1A | L2CAP_CREDIT_BASED_RECONFIGURE_RSP | 0x0001 and 0x0005 |
Other | Reserved for future use | Any |
Identifier (1 octet)
The Identifier field is one octet long and matches responses with requests. The requesting device sets this field and the responding device uses the same value in its response. Within each signaling channel a different Identifier shall be used for each successive command. Following the original transmission of an Identifier in a command, the Identifier may be recycled if all other Identifiers have subsequently been used.
RTX and ERTX timers are used to determine when the remote end point is not responding to signaling requests. On the expiration of a RTX or ERTX timer, the same identifier shall be used if a duplicate request is re-sent as stated in Section 6.2.
A device receiving a duplicate request on a particular signaling channel should reply with a duplicate response on the same signaling channel. A command response with an invalid identifier is silently discarded. Signaling identifier 0x00 is an invalid identifier and shall never be used in any command.
Data Length (2 octets)
The Data Length field is two octets long and indicates the size in octets of the data field of the command only, i.e., it does not cover the Code, Identifier, and Data Length fields.
Data (0 or more octets)
The Data field is variable in length. The Code field determines the format of the Data field. The Data Length field specifies the length of the Data field.
4.1. L2CAP_COMMAND_REJECT_RSP (code 0x01)
An L2CAP_COMMAND_REJECT_RSP packet shall be sent in response to a command packet with an unknown command code or when sending the corresponding response is inappropriate. Figure 4.3 defines the format of the packet. The identifier shall match the identifier of the command packet being rejected. Implementations shall always send these packets in response to unidentified signaling packets. L2CAP_COMMAND_REJECT_RSP packets should not be sent in response to an identified response packet.
When multiple commands are included in an L2CAP packet and the packet exceeds the signaling MTU (MTUsig) of the receiver, a single L2CAP_COMMAND_REJECT_RSP packet shall be sent in response. The identifier shall match the first request command in the L2CAP packet. If only responses are recognized, the packet shall be silently discarded.
The data fields are:
Reason (2 octets)
The Reason field describes why the request packet was rejected, and is set to one of the Reason codes in Table 4.3.
Reason value
Description
0x0000
Command not understood
0x0001
Signaling MTU exceeded
0x0002
Invalid CID in request
Other
Reserved for future use
Table 4.3: Reason code descriptionsReason Data (0 or more octets)
The length and content of the Reason Data field depends on the Reason code. If the Reason code is 0x0000, “Command not understood”, no Reason Data field is used. If the Reason code is 0x0001, “Signaling MTU Exceeded”, the 2-octet Reason Data field represents the maximum signaling MTU the sender of this packet can accept.
If a command refers to an invalid channel then the Reason code 0x0002 will be returned. Typically a channel is invalid because it does not exist. The Reason Data field shall be 4 octets containing the local (first) and remote (second) channel endpoints (relative to the sender of the L2CAP_COMMAND_REJECT_RSP packet) of the disputed channel. The remote endpoint is the source CID from the rejected command. The local endpoint is the destination CID from the rejected command. If the rejected command contains only one of the channel endpoints, the other one shall be replaced by the null CID 0x0000.
Reason value
Reason Data length
Reason Data value
0x0000
0 octets
0x0001
2 octets
Actual MTUsig
0x0002
4 octets
Requested CIDs
Table 4.4: Reason data values
4.2. L2CAP_CONNECTION_REQ (code 0x02)
L2CAP_CONNECTION_REQ packets are sent to create an L2CAP channel between two devices. The L2CAP channel shall be established before configuration begins. Figure 4.4 defines the format of the packet.
The data fields are:
Protocol/Service Multiplexer - PSM (2 octets (minimum))
The PSM field is at least two octets in length. All PSM values shall have the least significant bit of the most significant octet equal to 0 and the least significant bit of all other octets equal to 1.
Note
Note: This means that all PSMs are odd numbers and that the end of a PSM can be easily found by searching for the first even octet.
PSM values are separated into two ranges. Valid values in the first range are assigned by the Bluetooth SIG and indicate protocols. The second range of values are dynamically allocated and used in conjunction with the Service Discovery protocol (SDP). The dynamically assigned values may be used to support multiple implementations of a particular protocol.
PSM values in the first range are defined in Assigned Numbers.
Range
Type
Server Usage
Client Usage
0x0001 to 0x0EFF
(Note 1)
Fixed, SIG assigned
PSM is fixed for all implementations.
PSM may be obtained via SDP or may be assumed for a fixed service. Protocol used is indicated by the PSM.
>0x1000
Dynamic
PSM may be fixed for a given implementation or may be assigned at the time the service is registered in SDP.
PSM shall be obtained via SDP upon every reconnection. PSM for one direction will typically be different from the other direction.
1Since PSMs are odd and the least significant bit of the most significant byte is zero, the following ranges do not contain valid PSMs: 0x0100-0x01FF, 0x0300-0x03FF, 0x0500-0x05FF, 0x0700-0x07FF, 0x0900-0x09FF, 0x0B00-0x0BFF, 0x0D00-0x0DFF. All even values are also not valid as PSMs.
Table 4.5: PSM ranges and usageSource CID - SCID (2 octets)
The source CID is two octets in length and represents a channel endpoint on the device sending the request. Once the channel has been configured, data packets flowing to the sender of the request shall be sent to this CID. Thus, the Source CID represents the channel endpoint on the device sending the request and receiving the response. The value of the Source CID shall be from the dynamically allocated range as defined in Table 2.1 and shall not be already allocated to a different channel on the same logical link on the device sending the request.
4.3. L2CAP_CONNECTION_RSP (code 0x03)
When a device receives an L2CAP_CONNECTION_REQ packet, it shall send an L2CAP_CONNECTION_RSP packet. Figure 4.5 defines the format of the packet.
Note
Note: Implementations conforming to a version of the specification lower than version 4.2 may respond with an L2CAP_COMMAND_REJECT_RSP (Reason 0x0002 – Invalid CID In Request) packet under conditions now covered by result codes of 0x0006 and 0x0007.
If the device sends an L2CAP_CONNECTION_RSP packet with result code "pending", then it shall subsequently send another L2CAP_CONNECTION_RSP (see also [Vol 3] Part C, Section 5.2.2.2).
The data fields are:
Destination Channel Identifier - DCID (2 octets)
This field contains the channel endpoint on the device sending this response packet. Thus, the Destination CID represents the channel endpoint on the device receiving the request and sending the response. The value of the Destination CID shall be from the dynamically allocated range as defined in Table 2.1 and shall not be already allocated to a different channel on the same logical link on the device sending the response.
Source Channel Identifier - SCID (2 octets)
This field contains the channel endpoint on the device receiving this response packet. This is copied from the SCID field of the L2CAP_CONNECTION_REQ packet.
Result (2 octets)
The result field indicates the outcome of the connection request. The result value of 0x0000 indicates success while a non-zero value indicates the connection request failed or is pending. A logical channel is established on the receipt of a successful result unless the DCID field is outside of the dynamically allocated range (see Table 2.1) or is already allocated on the device sending the response. Table 4.6 defines values for this field. If the result field does not indicate the connection was successful, the DCID and SCID fields may be invalid and shall be ignored.
Value
Description
0x0000
Connection successful
0x0001
Connection pending
0x0002
Connection refused – PSM not supported
0x0003
Connection refused – security block
0x0004
Connection refused – no resources available
0x0006
Connection refused – invalid Source CID
0x0007
Connection refused – Source CID already allocated
Other
Reserved for future use
Table 4.6: Result values for the L2CAP_CONNECTION_RSP packetStatus (2 octets)
Only defined for Result = Pending. Indicates the status of the connection. The status is set to one of the values shown in Table 4.7.
Value
Description
0x0000
No further information available
0x0001
Authentication pending
0x0002
Authorization pending
Other
Reserved for future use
Table 4.7: Status values for the L2CAP_CONNECTION_RSP packet
4.4. L2CAP_CONFIGURATION_REQ (code 0x04)
L2CAP_CONFIGURATION_REQ packets are sent to establish an initial logical link transmission contract between two L2CAP entities and also to re-negotiate this contract whenever appropriate. The contract consists of a set of configuration parameter options defined in Section 5. All parameter options have default values and can have previously agreed values which are values that were accepted in a previous configuration process or in a previous step in the current configuration process. The only parameters that should be included in the L2CAP_CONFIGURATION_REQ packet are those that require different values than the default or previously agreed values.
If no parameters need to be negotiated or specified then no options shall be inserted and the continuation flag (C) shall be set to zero. Any missing configuration parameters are assumed to have their most recently explicitly or implicitly accepted values. Even if all default values are acceptable, an L2CAP_CONFIGURATION_REQ packet with no options shall be sent. Implicitly accepted values are default values for the configuration parameters that have not been explicitly negotiated for the specific channel under configuration.
See Section 7.1 for details of the configuration procedure.
Figure 4.6 defines the format of the packet.
The data fields are:
Destination CID - DCID (2 octets)
This field contains the channel endpoint on the device receiving this request packet.
Flags (2 octets)
Figure 4.7 shows the two-octet Flags field. Note the most significant bit is shown on the left.
Figure 4.7: L2CAP_CONFIGURATION_REQ Flags field formatOnly one flag is defined, the Continuation flag (C).
When both L2CAP entities support the Extended Flow Specification option, the Continuation flag shall not be used and shall be set to zero in all L2CAP_CONFIGURATION_REQ and L2CAP_CONFIGURATION_RSP packets.
When all configuration options cannot fit into an L2CAP_CONFIGURATION_REQ packet with a payload size that does not exceed the receiver's MTUsig, the options shall be passed in multiple L2CAP_CONFIGURATION_REQ packets. If all options fit into the receiver's MTUsig, then they shall be sent in a single L2CAP_CONFIGURATION_REQ packet with the continuation flag set to zero. Each L2CAP_CONFIGURATION_REQ packet shall only contain complete options - partially formed options shall not be sent in a packet. Each L2CAP_CONFIGURATION_REQ packet shall be tagged with a different Identifier and shall be matched with an L2CAP_CONFIGURATION_RSP packet with the same Identifier.
When used in the L2CAP_CONFIGURATION_REQ packet, the continuation flag indicates the responder should expect to receive multiple request packets. The responder shall reply to each L2CAP_CONFIGURATION_REQ packet. The responder may reply to each L2CAP_CONFIGURATION_REQ packet with an L2CAP_CONFIGURATION_RSP packet containing the same option(s) present in the request (except for those error conditions more appropriate for an L2CAP_COMMAND_REJECT_RSP packet), or the responder may reply with a "Success" L2CAP_CONFIGURATION_RSP packet containing no options, delaying those options until the full request has been received. The L2CAP_CONFIGURATION_REQ packet with the continuation flag cleared shall be treated as the L2CAP_CONFIGURATION_REQ event in the channel state machine.
When used in the L2CAP_CONFIGURATION_RSP packet, the continuation flag shall be set to one if the flag is set to one in the request. If the continuation flag is set to one in the response when the matching request has the flag set to zero, it indicates the responder has additional options to send to the requestor. In this situation, the requestor shall send null-option L2CAP_CONFIGURATION_REQ packets (with continuation flag set to zero) to the responder until the responder replies with an L2CAP_CONFIGURATION_RSP packet where the continuation flag is set to zero. The L2CAP_CONFIGURATION_RSP packet with the continuation flag set to zero shall be treated as the L2CAP_CONFIGURATION_RSP event in the channel state machine.
The result of the configuration transaction is success if all the individual result values are success, and is failure otherwise.
Other flags are reserved for future use.
Configuration Options
A list of the parameters and their values to be negotiated shall be provided in the Configuration Options field. These are defined in Section 5; in addition, as described in that section, an implementation shall be prepared to receive any number of unknown options. An L2CAP_CONFIGURATION_REQ packet may contain no options (referred to as an empty or null configuration request) and can be used to request a response. For an empty configuration request the Data Length field is set to 0x0004.
4.5. L2CAP_CONFIGURATION_RSP (code 0x05)
L2CAP_CONFIGURATION_RSP packets shall be sent in reply to L2CAP_CONFIGURATION_REQ packets except when the error condition is covered by an L2CAP_COMMAND_REJECT_RSP packet response. Each configuration parameter value (if any is present) in an L2CAP_CONFIGURATION_RSP packet reflects an ‘adjustment’ to a configuration parameter value that has been sent (or, in case of default values, implied) in the corresponding L2CAP_CONFIGURATION_REQ packet. For example, if an L2CAP_CONFIGURATION_REQ packet relates to traffic flowing from device A to device B, the sender of the L2CAP_CONFIGURATION_RSP packet may adjust this value for the same traffic flowing from device A to device B, but the response cannot adjust the value in the reverse direction.
The options sent in the L2CAP_CONFIGURATION_RSP packet depend on the value in the Result field. Figure 4.8 defines the format of the packet. See also Section 7.1 for details of the configuration process, including use of the result code "pending".
The data fields are:
Source CID - SCID (2 octets)
This field contains the channel endpoint on the device receiving this response packet. The device receiving the L2CAP_CONFIGURATION_RSP packet shall check that the Identifier field matches the same field in the corresponding L2CAP_CONFIGURATION_REQ packet and the SCID matches its local CID paired with the original DCID.
Flags (2 octets)
Figure 4.9 displays the two-octet Flags field. Note the most significant bit is shown on the left.
Figure 4.9: L2CAP_CONFIGURATION_RSP Flags field formatOnly one flag is defined, the Continuation flag (C).
When both L2CAP entities support the Extended Flow Specification option, the Continuation flag shall not be used and shall be set to zero in all L2CAP_CONFIGURATION_REQ and L2CAP_CONFIGURATION_RSP packets.
More L2CAP_CONFIGURATION_RSP packets will follow when C is set to one. This flag indicates that the parameters included in the response are a partial subset of parameters being sent by the device sending the L2CAP_CONFIGURATION_RSP packet.
The other flag bits are reserved for future use.
Result (2 octets)
The Result field indicates whether or not the request was acceptable. See Table 4.8 for possible result codes.
Result
Description
0x0000
Success
0x0001
Failure – unacceptable parameters
0x0002
Failure – rejected (no reason provided)
0x0003
Failure – unknown options
0x0004
Pending
0x0005
Failure - flow spec rejected
Other
Reserved for future use
Table 4.8: L2CAP_CONFIGURATION_RSP result codesConfiguration options
This field contains the list of parameters being configured. These are defined in Section 5. On a successful result (Result=0x0000) and pending result (Result=0x0004), these parameters contain the return values for any wild card parameter values (see Section 5.3) and “adjustments” to non-negotiated configuration parameter values contained in the request. A response with a successful result is also referred to as a positive response.
On an unacceptable parameters failure (Result=0x0001) the rejected parameters shall be sent in the response with the values that would have been accepted if sent in the original request. Any missing configuration parameters in the L2CAP_CONFIGURATION_REQ packet are assumed to have their default value or previously agreed value and they too shall be included in the L2CAP_CONFIGURATION_RSP packet if they need to be changed. A response with an unacceptable parameters failure is also referred to as a negative response.
On an unknown option failure (Result=0x0003), the option(s) that contain an option type field that is not understood by the recipient of the L2CAP_CONFIGURATION_REQ packet shall be included in the L2CAP_CONFIGURATION_RSP packet unless they are hints. Hints are those options in the L2CAP_CONFIGURATION_REQ packet that are skipped if not understood (see Section 5). Hints shall not be included in the L2CAP_CONFIGURATION_RSP packet and shall not be the sole cause for rejecting the L2CAP_CONFIGURATION_REQ packet.
On a flow spec rejected failure (Result=0x0005), an Extended Flow Spec option may be included to reflect the QoS level that would be acceptable (see Section 7.1.3).
The decision on the amount of time (or messages) spent arbitrating the channel parameters before terminating the negotiation is implementation specific.
4.6. L2CAP_DISCONNECTION_REQ (code 0x06)
Terminating an L2CAP channel requires that an L2CAP_DISCONNECTION_REQ packet be sent and acknowledged by an L2CAP_DISCONNECTION_RSP packet. Figure 4.10 defines the format of the packet. The receiver shall not initiate a disconnection if the source or destination CIDs do not match.
Once an L2CAP_DISCONNECTION_REQ packet is issued, all incoming data in transit on this L2CAP channel shall be discarded and any new additional outgoing data shall be discarded. Once an L2CAP_DISCONNECTION_REQ packet for a channel has been received, all data queued to be sent out on that channel shall be discarded.
The data fields are:
Destination CID - DCID (2 octets)
This field specifies the endpoint of the channel to be disconnected on the device receiving this request.
Source CID - SCID (2 octets)
This field specifies the endpoint of the channel to be disconnected on the device sending this request.
The SCID and DCID are relative to the sender of this request and shall match those of the channel to be disconnected. If the DCID is not recognized by the receiver of this message, an L2CAP_COMMAND_REJECT_RSP packet with ‘invalid CID’ result code shall be sent in response. If the receiver finds a DCID match but the SCID fails to find the same match, the request should be silently discarded.
4.7. L2CAP_DISCONNECTION_RSP (code 0x07)
L2CAP_DISCONNECTION_RSP packets shall be sent in response to each valid L2CAP_DISCONNECTION_REQ packet. Figure 4.11 defines the format of the packet.
The data fields are:
Destination CID - DCID (2 octets)
This field identifies the channel endpoint on the device sending the L2CAP_DISCONNECTION_RSP packet.
Source CID - SCID (2 octets)
This field identifies the channel endpoint on the device receiving the L2CAP_DISCONNECTION_RSP packet.
The DCID and the SCID (which are relative to the sender of the L2CAP_DISCONNECTION_REQ packet), and the Identifier fields shall match those of the corresponding L2CAP_DISCONNECTION_REQ packet. If the CIDs do not match, the L2CAP_DISCONNECTION_RSP packet should be silently discarded at the receiver.
4.8. L2CAP_ECHO_REQ (code 0x08)
L2CAP_ECHO_REQ packets are used to request a response from a remote L2CAP entity. Figure 4.12 defines the format of the packet. These requests may be used for testing the link or for passing vendor specific information using the optional data field. L2CAP entities shall respond to a valid L2CAP_ECHO_REQ packet with an L2CAP_ECHO_RSP packet. The Echo Data field is optional and implementation specific. L2CAP entities should ignore the contents of this field if present.
4.9. L2CAP_ECHO_RSP (code 0x09)
An L2CAP_ECHO_RSP packet shall be sent upon receiving a valid L2CAP_ECHO_REQ packet. Figure 4.13 defines the format of the packet. The identifier in the L2CAP_ECHO_RSP packet shall match the identifier sent in the L2CAP_ECHO_REQ packet. The Echo Data field is optional and implementation specific. It may contain the contents of the Echo Data field in the L2CAP_ECHO_REQ packet, different data, or no data at all. L2CAP entities should ignore the contents of this field if present.
4.10. L2CAP_INFORMATION_REQ (code 0x0A)
L2CAP_INFORMATION_REQ packets are used to request implementation specific information from a remote L2CAP entity. Figure 4.14 defines the format of the packet. L2CAP implementations shall respond to a valid L2CAP_INFORMATION_REQ packet with an L2CAP_INFORMATION_RSP packet. It is optional to send L2CAP_INFORMATION_REQ packets.
An L2CAP implementation shall only use optional features or attribute ranges for which the remote L2CAP entity has indicated support through an L2CAP_INFORMATION_RSP packet. Until an L2CAP_INFORMATION_RSP packet which indicates support for optional features or ranges has been received only mandatory features and ranges shall be used.
The data field is:
InfoType (2 octets)
The InfoType defines the type of implementation specific information being requested. See Section 4.11 for details on the type of information requested.
Value
Description
0x0001
Connectionless MTU
0x0002
Extended features supported
0x0003
Fixed channels supported over BR/EDR
Other
Reserved for future use
Table 4.9: InfoType definitions
L2CAP entities shall not send an L2CAP_INFORMATION_REQ packet with InfoType 0x0003 over fixed channel CID 0x0001 until first verifying that the Fixed Channels bit is set in the Extended feature mask of the remote device. Support for fixed channels is mandatory for devices with BR/EDR/LE or LE Controllers. L2CAP_INFORMATION_REQ and L2CAP_INFORMATION_RSP packets shall not be used over fixed channel CID 0x0005.
4.11. L2CAP_INFORMATION_RSP (code 0x0B)
An L2CAP_INFORMATION_RSP packet shall be sent upon receiving a valid L2CAP_INFORMATION_REQ packet. Figure 4.15 defines the format of the packet. The identifier in the L2CAP_INFORMATION_RSP packet shall match the identifier sent in the L2CAP_INFORMATION_REQ packet. The Info field shall contain the value associated with the InfoType field sent in the L2CAP_INFORMATION_REQ packet, or shall be empty if the InfoType is not supported.
The data fields are:
InfoType (2 octets)
The InfoType defines the type of implementation specific information that was requested. This value shall be copied from the InfoType field in the L2CAP_INFORMATION_REQ packet.
Result (2 octets)
The Result contains information about the success of the request. If result is "Success," the data field contains the information as specified in Table 4.11. If result is "Not supported," no data shall be returned.
Value
Description
0x0000
Success
0x0001
Not supported
Other
Reserved for future use
Table 4.10: Result values for the L2CAP_INFORMATION_RSP packetInfo (0 or more octets)
The contents of the Info field depends on the InfoType.
For InfoType = 0x0001, the field contains the remote entity’s 2-octet acceptable connectionless MTU. The default value is defined in Section 3.2.
For InfoType = 0x0002, the Info field contains the 4 octet L2CAP extended feature mask. The feature mask refers to the extended features that the L2CAP entity sending the L2CAP_INFORMATION_RSP packet supports. The feature bits contained in the L2CAP feature mask are specified in Section 4.12.
For InfoType = 0x0003, the Info field contains an 8 octet bit map that indicates which Fixed L2CAP Channels (i.e., the L2CAP channels that use a CID from 0x0000 to 0x003F) are supported over BR/EDR. A list of available fixed channels is provided in Table 2.1 in Section 2.1. A detailed description of this Info field is given in Section 4.13.
Note
Note: Implementations conforming to a version lower than 1.2, receiving an L2CAP_INFORMATION_REQ packet with InfoType = 0x0002 for an L2CAP feature discovery, return an L2CAP_INFORMATION_RSP packet with result code "Not supported." Implementations conforming to versions 1.2, 2.0 + EDR, or 2.1 + EDR that have an all zero extended features mask may return an L2CAP_INFORMATION_RSP packet with result code "Not supported."
InfoType
Info
Info length
(octets)
0x0001
Connectionless MTU
2
0x0002
Extended feature mask
4
0x0003
Fixed channels supported over BR/EDR
8
Table 4.11: L2CAP_INFORMATION_RSP Info fields
4.12. Extended Feature Mask
The features are represented as a bit mask in the L2CAP_INFORMATION_RSP packet’s Info field (see Section 4.11). For each feature a single bit is specified which shall be set to 1 if the feature is supported and set to 0 otherwise. All unknown or unassigned feature bits are reserved for future use.
The feature mask shown in Table 4.12 consists of 4 octets (numbered octet 0 to 3), with bit numbers 0 to 7 each.
No. | Supported feature | Octet | Bit | ||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Flow control mode | 0 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||
1 | Retransmission mode | 0 | 1 | ||||||||||||||||||||||||||||||||||||||||||||||
2 | Bi-directional QoS1 | 0 | 2 | ||||||||||||||||||||||||||||||||||||||||||||||
3 | Enhanced Retransmission mode | 0 | 3 | ||||||||||||||||||||||||||||||||||||||||||||||
4 | Streaming mode | 0 | 4 | ||||||||||||||||||||||||||||||||||||||||||||||
5 | FCS Option2 | 0 | 5 | ||||||||||||||||||||||||||||||||||||||||||||||
6 | Extended Flow Specification for BR/EDR | 0 | 6 | ||||||||||||||||||||||||||||||||||||||||||||||
7 | Fixed Channels supported over BR/EDR | 0 | 7 | ||||||||||||||||||||||||||||||||||||||||||||||
8 | Extended Window Size | 1 | 0 | ||||||||||||||||||||||||||||||||||||||||||||||
9 | Unicast Connectionless Data Reception | 1 | 1 | ||||||||||||||||||||||||||||||||||||||||||||||
10 | Enhanced Credit Based Flow Control mode over BR/EDR | 1 | 2 | ||||||||||||||||||||||||||||||||||||||||||||||
31 | Reserved for feature mask extension | 3 | 7 | ||||||||||||||||||||||||||||||||||||||||||||||
All others | Reserved for future use | All others | |||||||||||||||||||||||||||||||||||||||||||||||
1Peer side supports upper layer control of the Link Manager's Bi-directional QoS, see Section 5.3 for more details. 2Peer side supports negotiating omitting FCS; see Section 5.5 for more details and the required behavior if this bit is not set. | |||||||||||||||||||||||||||||||||||||||||||||||||
4.13. Fixed Channels Supported over BR/EDR
Each fixed channel supported over BR/EDR is represented by a single bit in an 8 octet bit mask. The bit associated with a channel shall be set to 1 if the L2CAP entity supports that channel. The L2CAP Signaling channel is mandatory and therefore the bit associated with that channel shall be set to 1. Table 4.13 shows the format of the bit mask.
CID | Fixed Channel | Value | Octet | Bit |
|---|---|---|---|---|
0x0000 | Null identifier | Shall be set to 0 | 0 | 0 |
0x0001 | L2CAP Signaling channel | Shall be set to 1 | 0 | 1 |
0x0002 | Connectionless reception | 0 – if not supported 1 – if supported | 0 | 2 |
0x0003 | Previously used | 0 | 3 | |
0x0004 to 0x0006 | Reserved for future use | 0 | 4-6 | |
0x0007 | BR/EDR Security Manager | 0 – if not supported 1 – if supported | 0 | 7 |
0x0008 to 0x003E | Reserved for future use | 1-6 7 | 0-7 0-6 | |
0x003F | Previously used | 7 | 7 | |
Other | Reserved for future use | Other | ||
An L2CAP entity shall not transmit on any fixed channel (with the exception of the L2CAP Signaling channel) until it has received a Fixed Channels Supported InfoType from the peer L2CAP entity indicating support for that channel, or has received a valid packet from the remote device on that fixed channel. All packets received on a non-supported fixed channel shall be ignored.
4.14. [This section is no longer used]
4.15. [This section is no longer used]
4.16. [This section is no longer used]
4.17. [This section is no longer used]
4.18. [This section is no longer used]
4.19. [This section is no longer used]
4.20. L2CAP_CONNECTION_PARAMETER_UPDATE_REQ (code 0x12)
This command shall only be sent from the Peripheral to the Central and only if one or more of the Peripheral’s Controller, the Central’s Controller, the Peripheral’s Host and the Central’s Host do not support the Connection Parameters Request Link Layer Control procedure ([Vol 6] Part B, Section 5.1.7). If a Peripheral’s Host receives an L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet it shall respond with an L2CAP_COMMAND_REJECT_RSP packet with reason 0x0000 (Command not understood). Figure 4.16 defines the format of the packet.
The L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet allows the Peripheral’s Host to request a set of new connection parameters. When the Central’s Host receives an L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet, depending on the parameters of other connections, the Central’s Host may accept the requested parameters and deliver the requested parameters to its Controller or reject the request. In devices supporting HCI, the Central’s Host delivers the requested parameters to its Controller using the HCI_LE_Connection_Update command (see [Vol 4] Part E, Section 7.8.18). If the Central’s Host accepts the requested parameters it shall send the L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet with result 0x0000 (Parameters accepted) otherwise it shall set the result to 0x0001 (request rejected).
The Peripheral’s Host will receive an indication from the Peripheral’s Controller when the connection parameters have been updated. In devices supporting HCI, this notification will be in the form of an HCI_LE_Connection_Update_Complete event (see [Vol 4] Part E, Section 7.7.65.3). If the Central’s Controller rejects the updated connection parameters no indication from the Peripheral’s Controller will be sent to the Peripheral’s Host.
The data fields shall have the same meanings and requirements as the fields of the LL_CONNECTION_PARAM_REQ PDU (see [Vol 6] Part B, Section 2.4.2.16) with the same names.
4.21. L2CAP_CONNECTION_PARAMETER_UPDATE_RSP (code 0x13)
This response shall only be sent from the Central to the Peripheral.
The L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet shall be sent by the Central’s Host when it receives an L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet. Figure 4.17 defines the format of the packet. If the Central’s Host accepts the request it shall send the connection parameter update to its Controller.
The data field is:
Result (2 octets)
The result field indicates the response to the request. The result value of 0x0000 indicates that the Central’s Host has accepted the connection parameters while 0x0001 indicates that the Central’s Host has rejected the connection parameters.
Result
Description
0x0000
Connection Parameters accepted
0x0001
Connection Parameters rejected
Other
Reserved for future use
Table 4.14: Result values for the L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet
4.22. L2CAP_LE_CREDIT_BASED_CONNECTION_REQ (code 0x14)
L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packets are sent to create and configure an L2CAP channel between two devices using LE Credit Based Flow Control mode. Figure 4.18 defines the format of the packet.
The data fields are:
Simplified Protocol/Service Multiplexer – SPSM1(2 octets)
The SPSM field is two octets in length. SPSM values are separated into two ranges. Values in the first range are assigned by the Bluetooth SIG and indicate protocols. Values in the second range are dynamically allocated and used in conjunction with services defined in the GATT Server. The dynamically assigned values may be used to support multiple implementations of a particular protocol.
Note
Note: Unlike a normal PSM (see Section 4.2), the length of an SPSM is not variable and each octet may be either odd or even.
SPSM values are defined in Table 4.15.
Range
Type
Server Usage
Client Usage
0x0001 to 0x007F
Fixed, SIG
assigned
SPSM is fixed for all implementations
SPSM may be assumed for fixed service. Protocol used is indicated by the SPSM as defined in Assigned Numbers.
0x0080 to 0x00FF
Dynamic
SPSM may be fixed for a given implementation or may be assigned at the time the service is registered in GATT
SPSM shall be obtained from the service in GATT upon every reconnection. SPSM for one direction will typically be different from the other direction.
Other
RFU
Not applicable
Not applicable
Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM rangesSource CID – SCID (2 octets)
The source CID is two octets in length and represents a channel endpoint on the device sending the request. Once the channel has been created, data packets flowing to the sender of the request shall be sent to this CID. Thus, the Source CID represents the channel endpoint on the device sending the request and receiving the response. The value of the Source CID shall be from the dynamically allocated range as defined in Table 2.3 and shall not be already allocated to a different channel on the same logical link on the device sending the request.
Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet can receive on this channel. L2CAP implementations shall support a minimum MTU size of 23 octets.
Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet is capable of receiving on this channel. L2CAP implementations shall support a minimum MPS of 23 octets and may support an MPS up to 65533 octets.
Initial Credits – (2 octets)
The initial credit value indicates the number of K-frames that the peer device can send to the L2CAP layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet. The initial credit value shall be in the range 0 to 65535.
4.23. L2CAP_LE_CREDIT_BASED_CONNECTION_RSP (code 0x15)
When a device receives an L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet, it shall send an L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. Figure 4.19 defines the format of the packet.
The data fields are:
Destination CID – DCID (2 octets)
The destination CID is two octets in length and represents a channel endpoint on the device sending the response. Once the channel has been created, data packets flowing to the sender of the response shall be sent to this CID. Thus, the destination CID represents the channel endpoint on the device receiving the request and sending the response. The value of the Destination CID shall be from the dynamically allocated range as defined in Table 2.3 and shall not be already allocated to a different channel on the same logical link on the device sending the response.
Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet can receive on this channel. L2CAP implementations shall support a minimum MTU size of 23 octets.
Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet is capable of receiving on this channel. L2CAP implementations shall support a minimum MPS of 23 octets and may support an MPS up to 65533 octets.
Initial Credits – (2 octets)
The initial credit value indicates the number of K‑frames that the peer device can send to the L2CAP layer entity sending the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet. The initial credit value shall be in the range 0 to 65535.
Result – (2 octets)
The result field indicates the outcome of the connection request. A result value of 0x0000 indicates success while a non-zero value indicates the connection request was refused. A logical channel is established on the receipt of a successful result. Table 4.16 defines values for this field. The DCID, MTU, MPS and Initial Credits fields shall be ignored when the result field indicates the connection was refused.
Value
Description
0x0000
Connection successful
0x0002
Connection refused – SPSM not supported
0x0004
Connection refused – no resources available
0x0005
Connection refused – insufficient authentication
0x0006
Connection refused – insufficient authorization
0x0007
Connection refused – encryption key size too short1
0x0008
Connection refused – insufficient encryption
0x0009
Connection refused – invalid Source CID
0x000A
Connection refused – Source CID already allocated
0x000B
Connection refused – unacceptable parameters
Other
Reserved for future use
1This was previously "Connection refused - insufficient encryption key size".
Table 4.16: Result values for the L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet
4.24. L2CAP_FLOW_CONTROL_CREDIT_IND (code 0x16)
A device shall send an L2CAP_FLOW_CONTROL_CREDIT_IND packet when it is capable of receiving additional K-frames (for example after it has processed one or more K-frames) in LE Credit Based Flow Control mode and Enhanced Credit Based Flow Control mode. Figure 4.20 defines the format of the packet.
The data fields are:
CID – (2 octets)
The CID is two octets in length and represents the source channel endpoint of the device sending the L2CAP_FLOW_CONTROL_CREDIT_IND packet. For example, a received L2CAP_FLOW_CONTROL_CREDIT_IND packet with a given CID (0x0042) would provide credits for the receiving device’s destination CID (0x0042).
Credits – (2 octets)
The credit value field represents number of credits the receiving device can increment, corresponding to the number of K-frames that can be sent to the peer device sending the L2CAP_FLOW_CONTROL_CREDIT_IND packet. The credit value field shall be a number between 1 and 65535.
4.25. L2CAP_CREDIT_BASED_CONNECTION_REQ (code 0x17)
L2CAP_CREDIT_BASED_CONNECTION_REQ packets are sent to create and configure up to five L2CAP channels between two devices. Figure 4.21 defines the format of the packet.
 |
The data fields are:
Simplified Protocol/Service Multiplexer – SPSM (2 octets)
The SPSM is defined in Section 4.22.
Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_REQ packet can receive on each of the Source CID channels. L2CAP implementations shall support a minimum MTU size of 64 octets for these channels.
Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_REQ packet is capable of receiving on each of the Source CID channels. L2CAP implementations shall support a minimum MPS of 64 octets and may support an MPS up to 65533 octets for these channels.
Initial Credits – (2 octets)
The Initial Credit field value indicates the number of K-frames that the peer device can send to the L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_REQ packet on each of the Source CID channels. The initial credit value shall be in the range of 1 to 65535.
Source CID – (2 to 10 octets)
The Source CID is an array of up to 5 two-octet values and represents the channel endpoints on the device sending the request. Once a channel has been created, data packets flowing to the sender of the request shall be sent to these CIDs. Each entry in the array shall be non-zero and represents a request for a channel. The value of each Source CID shall be from the dynamically allocated range as defined in Table 2.1 or Table 2.3 (depending on the transport in use) and shall not be already allocated to a different channel on the same logical link on the device sending the request.
4.26. L2CAP_CREDIT_BASED_CONNECTION_RSP (code 0x18)
When a device receives an L2CAP_CREDIT_BASED_CONNECTION_REQ packet, it shall send an L2CAP_CREDIT_BASED_CONNECTION_RSP packet. If the device sends an L2CAP_CREDIT_BASED_CONNECTION_RSP packet with a result code "pending", then it shall subsequently send another L2CAP_CREDIT_BASED_CONNECTION_RSP (see also [Vol 3] Part C, Section 5.2.2.2). Figure 4.22 defines the format of the packet.
 |
The data fields are:
Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_RSP packet can receive on each of the Destination CID channels. L2CAP implementations shall support a minimum MTU size of 64 octets.
Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_RSP packet is capable of receiving on each of the Destination CID channels. L2CAP implementations shall support a minimum MPS of 64 octets and may support an MPS up to 65533 octets.
Initial Credits – (2 octets)
The Initial Credit field value indicates the number of K-frames that the peer device can send to the L2CAP layer entity sending the L2CAP_CREDIT_BASED_CONNECTION_RSP packet on each of the Destination CID channels. The initial credit value shall be in the range of 1 to 65535.
Result – (2 octets)
The Result field indicates the outcome of the connection request. Table 4.17 defines values for this field. The Destination CID, MTU, MPS and Initial Credits fields shall be ignored when the Result field indicates that all connections were refused or all connections are pending.
Value
Description
0x0000
All connections successful
0x0002
All connections refused – SPSM not supported
0x0004
Some connections refused – insufficient resources available
0x0005
All connections refused – insufficient authentication
0x0006
All connections refused – insufficient authorization
0x0007
All connections refused – encryption key size too short1
0x0008
All connections refused – insufficient encryption
0x0009
Some connections refused – invalid Source CID
0x000A
Some connections refused – Source CID already allocated
0x000B
All connections refused – unacceptable parameters
0x000C
All connections refused – invalid parameters
0x000D
All connections pending – no further information available
0x000E
All connections pending – authentication pending
0x000F
All connections pending – authorization pending
Other
Reserved for future use
1This was previously "All connections refused - insufficient encryption key size".
Table 4.17: Result values for the L2CAP_CREDIT_BASED_CONNECTION_RSP packetDestination CID – (2 to 10 octets)
The Destination CID is an array of up to 5 two-octet values and represents the channel endpoints on the device sending the L2CAP_CREDIT_BASED_CONNECTION_RSP packet. The value of the Destination CID shall be from the dynamically allocated range as defined in Table 2.1 or Table 2.3 (depending on the transport in use) and shall not be already allocated to a different channel on the same logical link on the device sending the response. Once a channel has been created, data packets flowing to the sender of the response shall be sent to these CIDs. The order of the Destination CIDs shall correspond to the order of the Source IDs in the corresponding L2CAP_CREDIT_BASED_CONNECTION_REQ packet. If a Destination CID is non-zero, the channel was established. If a Destination CID is 0x0000, the channel was not established. If a device receives an L2CAP_CREDIT_BASED_CONNECTION_RSP packet with an already-assigned Destination CID, then both the original channel and the new channel shall not be used.
4.27. L2CAP_CREDIT_BASED_RECONFIGURE_REQ (code 0x19)
A device shall send an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet when its receive MTU or MPS values have changed compared to when the channel was created or last reconfigured. Figure 4.23 defines the format of the packet.
Note
Note: The current MTU and MPS values of the channels may be different before this packet is sent.
 |
The data fields are:
Maximum Transmission Unit – MTU (2 octets)
The MTU field specifies the maximum SDU size (in octets) that the L2CAP layer entity sending the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet can receive on each of the Destination CID channels. The MTU field shall be greater than or equal to the greatest current MTU size of these channels.
Maximum PDU Payload Size – MPS (2 octets)
The MPS field specifies the maximum PDU payload size (in octets) that the L2CAP layer entity sending the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet is capable of receiving on each of the Destination CID channels. If more than one channel is being configured, the MPS field shall be greater than or equal to the current MPS size of each of these channels. If only one channel is being configured, the MPS field may be less than the current MPS of that channel.
Destination CID – (2 to 10 octets)
The Destination CID is an array of up to 5 two-octet values which shall be non-zero and represent the channel endpoints on the device sending the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet.
4.28. L2CAP_CREDIT_BASED_RECONFIGURE_RSP (code 0x1A)
When a device receives an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet, it shall send an L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet. Figure 4.24 defines the format of the packet.
 |
The data fields are:
Result (2 octets)
The Result field contains information about the success of the request.
Value | Description |
|---|---|
0x0000 | Reconfiguration successful |
0x0001 | Reconfiguration failed - reduction in size of MTU not allowed |
0x0002 | Reconfiguration failed - reduction in size of MPS not allowed for more than one channel at a time |
0x0003 | Reconfiguration failed - one or more Destination CIDs invalid |
0x0004 | Reconfiguration failed - other unacceptable parameters |
All other values | Reserved for future use |
5. Configuration parameter options
Options are a mechanism to extend the configuration parameters. Options shall be transmitted as information elements containing an option type, an option length, and one or more option data fields. Figure 5.1 illustrates the format of an option.
The configuration option fields are:
Option Type (1 octet)
The Option Type field defines the parameters being configured. If the option is not recognized (e.g. because the option is defined in a higher version of the specification than the version the implementation conforms to) then:
If the most significant bit of the type is 0 (i.e. types 0x00 to 0x7F), the recipient shall refuse the entire configuration request.
If the most significant bit of the type is 1 (i.e. types 0x80 to 0xFF), the recipient shall ignore the option and continue processing with the next option (if any).
Option Length (1 octet)
The Option Length field defines the number of octets in the option data. Thus an option type without option data has a length of 0.
Option data
The contents of this field are dependent on the option type.
5.1. Maximum Transmission Unit (MTU)
This option specifies the maximum SDU size the sender of this option is capable of accepting for a channel. The Option Type is 0x01, and the Option Length is 2 octets, carrying the two-octet MTU size value as the only information element (see Figure 5.2).
MTU is not a negotiated value, it is an informational parameter that each device can specify independently. It indicates to the remote device that the local device can receive, in this channel, an MTU larger than the minimum required. All L2CAP implementations shall support a minimum MTU of 48 octets over the ACL-U logical link and 23 octets over the LE-U logical link; however, some protocols and profiles explicitly require support for a larger MTU. The minimum MTU for a channel is the larger of the L2CAP minimum 48 octet MTU and any MTU explicitly required by the protocols and profiles using that channel.
Note
Note: The MTU is only affected by the profile directly using the channel. For example, if a service discovery transaction is initiated by a non service discovery profile, that profile does not affect the MTU of the L2CAP channel used for service discovery.
The following rules shall be used when responding to an L2CAP_CONFIGURATION_REQ packet specifying the MTU for a channel:
A request specifying any MTU greater than or equal to the minimum MTU for the channel shall be accepted.
A request specifying an MTU smaller than the minimum MTU for the channel may be rejected.
The signaling described in Section 4.5 may be used to reject an MTU smaller than the minimum MTU for a channel. The "failure-unacceptable parameters" result sent to reject the MTU shall include the proposed value of MTU that the remote device intends to transmit. It is implementation specific whether the local device continues the configuration process or disconnects the channel.
If the remote device sends a positive L2CAP_CONFIGURATION_RSP packet it should include the actual MTU to be used on this channel for traffic flowing into the local device. Following the above rules, the actual MTU cannot be less than 48 bytes.This is the minimum of the MTU in the L2CAP_CONFIGURATION_REQ packet and the outgoing MTU capability of the device sending the L2CAP_CONFIGURATION_RSP packet. The new agreed value (the default value in a future re-configuration) is the value specified in the response.
Note
Note: For backwards compatibility reception of the MTU option in a negative L2CAP_CONFIGURATION_RSP packet where the MTU option is not in error should be interpreted in the same way as it is in a positive L2CAP_CONFIGURATION_RSP packet (e.g. the case where another configuration option value is unacceptable but the negative L2CAP_CONFIGURATION_RSP packet contains the MTU option in addition to the unacceptable option).
The MTU to be used on this channel for the traffic flowing in the opposite direction will be established when the remote device sends its own L2CAP_CONFIGURATION_REQ packet as explained in Section 4.4.
If the configured mode is Enhanced Retransmission mode or Streaming mode then MTU shall not be reconfigured to a smaller size.
The option data field is:
Maximum Transmission Unit - MTU (2 octets)
The MTU field is the maximum SDU size, in octets, that the originator of the request can accept for this channel. The MTU is asymmetric and the sender of the request shall specify the MTU it can receive on this channel if it differs from the default value. L2CAP implementations shall support a minimum MTU size of 48 octets. The default value is 672 octets.
5.2. Flush Timeout option
This option is used to inform the recipient of the Flush Timeout the sender is going to use. This option shall not be used if the Extended Flow Specification is used. The Flush Timeout is defined in the BR/EDR Baseband specification [Vol 2] Part B, Section 3.3. The Option Type is 0x02 and the Option Length is 2 octets (see Figure 5.3). The Flush Timeout option is negotiable.
If the remote device returns a negative response to this option and the local device cannot honor the proposed value, then it shall either continue the configuration process by sending a new request with the original value, or disconnect the channel. The flush timeout applies to all channels on the same ACL logical transport but may be overridden on a packet by packet basis by marking individual L2CAP packets as non-automatically-flushable via the Packet_Boundary_Flag in the HCI ACL Data packet (see Section 1.1).
The option data field is:
Flush Timeout
This value is the Flush Timeout in milliseconds. This is an asymmetric value and the sender of the request shall specify its flush timeout value if it differs from the default value of 0xFFFF.
Possible values are:
0x0001 - no retransmissions at the Baseband level should be performed since the minimum polling interval is 1.25 ms.
0x0002 to 0xFFFE - Flush Timeout used by the Baseband.
0xFFFF - an infinite amount of retransmissions. This is also referred to as a ’reliable channel’. In this case, the Baseband shall continue retransmissions until physical link loss is declared by link manager timeouts.
5.3. Quality of Service (QoS) option
This option specifies a flow specification similar to RFC 13632. Although the RFC flow specification addresses only the transmit characteristics, the Bluetooth QoS interface can handle the two directions (Tx and Rx) in the negotiation as described below.
If no QoS configuration parameter is negotiated the link shall assume the default parameters. The Option Type is 0x03. This option shall not be used if the Extended Flow Specification option is used. The QoS option is negotiable. Figure 5.4 specifies the format of this option.
In an L2CAP_CONFIGURATION_REQ packet, this option describes the outgoing traffic flow from the device sending the request. In a positive L2CAP_CONFIGURATION_RSP packet, this option describes the incoming traffic flow agreement to the device sending the response. In a negative L2CAP_CONFIGURATION_RSP packet, this option describes the preferred incoming traffic flow to the device sending the response.
L2CAP implementations are only required to support ’Best Effort’ service, support for any other service type is optional. Best Effort does not require any guarantees. If no QoS option is placed in the request, Best Effort shall be assumed. If any QoS guarantees are required then a QoS configuration request shall be sent.
The remote device’s L2CAP_CONFIGURATION_RSP packet contains information that depends on the value of the result field (see Section 4.5). If the request was for Guaranteed Service, the response shall include specific values for any wild card parameters (see Token Rate and Token Bucket Size descriptions) contained in the request. If the result is “Failure – unacceptable parameters”, the response shall include a list of outgoing flow specification parameters and parameter values that would make a new L2CAP_CONNECTION_REQ packet from the local device acceptable by the remote device. Both explicitly referenced in an L2CAP_CONFIGURATION_REQ packet or implied configuration parameters can be included in an L2CAP_CONFIGURATION_RSP packet. Recall that any missing configuration parameters from an L2CAP_CONFIGURATION_REQ packet are assumed to have their most recently accepted values.
If an L2CAP_CONFIGURATION_REQ packet contains any QoS option parameters set to “do not care” then the L2CAP_CONFIGURATION_RSP packet shall set the same parameters to “do not care”. This rule applies for Best Effort and, if the parameter is allowed to be set to the "do not care" value, for Guaranteed Service.
The option data fields are:
Flags (1 octet)
Reserved for future use.
Service Type (1 octet)
This field indicates the level of service required. Table 5.1 defines the different services available. The default value is ‘Best effort’.
If ‘Best effort’ is selected, the remaining parameters should be treated as optional by the remote device. The remote device may choose to ignore the fields, try to satisfy the parameters but provide no response (QoS option omitted in the response message), or respond with the settings it will try to meet.
If ‘No traffic’ is selected, the remainder of the fields shall be ignored because there is no data being sent across the channel in the outgoing direction.
Value
Description
0x00
No traffic
0x01
Best effort (Default)
0x02
Guaranteed
Other
Reserved for future use
Table 5.1: Service type definitionsToken Rate (4 octets)
The value of this field represents the average data rate with which the application transmits data. The application may send data at this rate continuously. On a short time scale the application may send data in excess of the average data rate, dependent on the specified Token Bucket Size and Peak Bandwidth (see below). The Token Bucket Size and Peak Bandwidth allow the application to transmit data in a 'bursty' fashion.
The Token Rate signaled between two L2CAP peers is the data transmitted by the application and shall exclude the L2CAP protocol overhead. The Token Rate signaled over the interface between L2CAP and the Link Manager shall include the L2CAP protocol overhead. Furthermore the Token Rate value signaled over this interface may also include the aggregation of multiple L2CAP channels onto the same ACL logical transport.
The Token Rate is the rate with which traffic credits are provided. Credits can be accumulated up to the Token Bucket Size. Traffic credits are consumed when data is transmitted by the application. When traffic is transmitted, and there are insufficient credits available, the traffic is non-conformant. The Quality of Service guarantees are only provided for conformant traffic. For non-conformant traffic there may be insufficient resources such as bandwidth and buffer space. Furthermore non-conformant traffic may violate the QoS guarantees of other traffic flows.
The Token Rate is specified in octets per second. The value 0x00000000 indicates no token rate is specified. This is the default value and means “do not care”. When the Guaranteed service is selected, the default value shall not be used. The value 0xFFFFFFFF is a wild card matching the maximum token rate available. The meaning of this value depends on the service type. For best effort, the value is a hint that the application wants as much bandwidth as possible. For Guaranteed service the value represents the maximum bandwidth available at the time of the request.
Token Bucket Size (4 octets)
The Token Bucket Size specifies a limit on the 'burstiness' with which the application may transmit data. The application may offer a burst of data equal to the Token Bucket Size instantaneously, limited by the Peak Bandwidth (see below). The Token Bucket Size is specified in octets.
The Token Bucket Size signaled between two L2CAP peers is the data transmitted by the application and shall exclude the L2CAP protocol overhead. The Token Bucket Size signaled over the interface between L2CAP and Link Manager shall include the L2CAP protocol overhead. Furthermore the Token Bucket Size value over this interface may include the aggregation of multiple L2CAP channels onto the same ACL logical transport.
The value of 0x00000000 means that no token bucket is needed; this is the default value. When the Guaranteed service is selected, the default value shall not be used. The value 0xFFFFFFFF is a wild card matching the maximum token bucket available. The meaning of this value depends on the service type. For best effort, the value indicates the application wants a bucket as big as possible. For Guara