Bluetooth Core Specification

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:

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.

Figure 1.1: L2CAP architectural blocks

The protocol is designed based on the following assumptions:

The following features are outside the scope of L2CAP’s responsibilities:

The following formal definitions apply:

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 never 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. At a minimum, the L2CAP Signaling channel (fixed channel 0x0001) or the L2CAP LE Signaling channel (fixed channel 0x0005) shall be supported. If fixed channel 0x0005 is supported, then fixed channels 0x0004 and 0x0006 shall be supported (see Table 2.3). Other fixed channels may be supported. 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.

Figure 2.1: Dynamically allocated CID assignments

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:

The CID name space for APB-U logical links is as follows:

The CID name space for LE-U logical links is as follows:

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.

Figure 2.2: Channels between 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.

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.

Figure 2.3: L2CAP transaction model

L2CAP channels may operate in one of several different modes as selected for each L2CAP channel.

The modes are:

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.

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.

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".

Figure 3.1: L2CAP PDU format in Basic L2CAP mode on connection-oriented channels (field sizes in bits)

The fields shown are:

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".

Figure 3.2: L2CAP PDU format on the connectionless channel

The fields shown are:

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.

Figure 3.3: L2CAP PDU formats in Flow Control and Retransmission modes

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).

Figure 3.4: I-frame Standard Control Field format

Figure 3.5: I-frame Enhanced Control Field format

Figure 3.6: I-frame Extended Control Field format

Figure 3.7: S-frame Standard Control Field format

Figure 3.8: S-frame Enhanced Control Field format

Figure 3.9: S-frame Extended Control Field format

• 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 format
  
  
  

• Supervisory 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-frame
  
  
  

• Poll - 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.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) = D¹⁶ + D¹⁵ + D² + 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.

Figure 3.10: The LFSR circuit generating the FCS

Figure 3.11: Initial state of the FCS generating circuit

Examples of FCS calculation, g(D) = D¹⁶ + D¹⁵ + D² + 1:

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)

2. 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)

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.

Figure 3.12: L2CAP PDU format in LE Credit Based Flow Control and Enhanced Credit Based Flow Control modes

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 (MTU_sig) 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.

Figure 4.3: L2CAP_COMMAND_REJECT_RSP packet

The data fields are:

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.

Figure 4.4: L2CAP_CONNECTION_REQ packet

The data fields are:

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.

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).

Figure 4.5: L2CAP_CONNECTION_RSP packet

The data fields are:

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.

Figure 4.6: L2CAP_CONFIGURATION_REQ packet

The data fields are:

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".

Figure 4.8: L2CAP_CONFIGURATION_RSP packet

The data fields are:

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.

Figure 4.10: L2CAP_DISCONNECTION_REQ packet

The data fields are:

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.

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.

Figure 4.11: L2CAP_DISCONNECTION_RSP packet

The data fields are:

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.

Figure 4.12: L2CAP_ECHO_REQ packet

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.

Figure 4.13: L2CAP_ECHO_RSP packet

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.

Figure 4.14: L2CAP_INFORMATION_REQ packet

The data field is:

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.

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.

Figure 4.15: L2CAP_INFORMATION_RSP packet

The data fields are:

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.

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.

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.

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.

Figure 4.16: L2CAP_CONNECTION_PARAMETER_UPDATE_REQ packet

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.

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.

Figure 4.17: L2CAP_CONNECTION_PARAMETER_UPDATE_RSP packet

The data field is:

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.

Figure 4.18: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ packet

The data fields are:

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.

Figure 4.19: L2CAP_LE_CREDIT_BASED_CONNECTION_RSP packet

The data fields are:

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.

Figure 4.20: L2CAP_FLOW_CONTROL_CREDIT_IND packet

The data fields are:

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.

Figure 4.21: L2CAP_CREDIT_BASED_CONNECTION_REQ packet

The data fields are:

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.

Figure 4.22: L2CAP_CREDIT_BASED_CONNECTION_RSP packet

The data fields are:

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.

Figure 4.23: L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet

The data fields are:

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.

Figure 4.24: L2CAP_CREDIT_BASED_RECONFIGURE_RSP

The data fields are:

The Result field contains information about the success of the request.

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.

The following rules shall be used when responding to an L2CAP_CONFIGURATION_REQ packet specifying the MTU for a channel:

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.

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.

Figure 5.2: MTU option format

The option data field is:

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).

Figure 5.3: Flush Timeout option format

The option data field is:

This option specifies a flow specification similar to RFC 1363^[2]. 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 both Best Effort and Guaranteed Service.

Figure 5.4: Quality of Service (QoS) option format containing Flow Specification

The option data fields are:

This option specifies whether retransmission and flow control is used. If the feature is used both incoming and outgoing parameters are specified by this option. The Retransmission and Flow Control option contains both negotiable parameters and non-negotiable parameters. The mode parameter controls both incoming and outgoing data flow (i.e. both directions have to agree) and is negotiable. The other parameters control incoming data flow and are non-negotiable. Figure 5.5 specifies the format of this option.

Figure 5.5: Retransmission and Flow Control option format

The option data fields are:

When using Retransmission mode and Flow Control mode the settings are configured separately for the two directions of an L2CAP connection. For example, in operating with an L2CAP entity implementing a lower version of the specification, an L2CAP connection can be configured as Flow Control mode in one direction and Retransmission mode in the other direction. If Basic L2CAP mode is configured in one direction and Retransmission mode or Flow control mode is configured in the other direction on the same L2CAP channel then the channel shall not be used.

When using Enhanced Retransmission mode or Streaming mode, both directions of the L2CAP connection shall be configured to the same mode. A precedence algorithm shall be used by both devices so a mode conflict can be resolved in a quick and deterministic manner.

There are two operating states:

In state 1, Basic L2CAP mode has the highest precedence and shall take precedence over Enhanced Retransmission mode and Streaming mode. Enhanced Retransmission mode has the second highest precedence and shall take precedence over all other modes except Basic L2CAP mode. Streaming mode shall have the next level of precedence after Enhanced Retransmission mode.

In state 2, a layer above L2CAP requires Enhanced Retransmission mode or Streaming mode. In this case, the required mode takes precedence over all other modes.

A device does not know in which state the remote device is operating so the state 1 precedence algorithm assumes that the remote device may be a state 2 device. If the mode proposed by the remote device has a higher precedence (according to the state 1 precedence) then the algorithm will operate such that creation of a channel using the remote device's mode has higher priority than disconnecting the channel.

The algorithm for state 1 devices is divided into two parts. Part one covers the case where the remote device proposes a mode with a higher precedence than the state 1 local device. Part two covers the case where the remote device proposes a mode with a lower precedence than the state 1 local device. Part one of the algorithm is as follows:

Part two of the algorithm is as follows:

An example of the algorithm for state 1 devices is as follows:

The algorithm for state 2 devices is as follows:

For Enhanced Retransmission mode and Streaming mode the Retransmission timeout and Monitor Timeout parameters of the Retransmission and Flow Control option parameters may be changed but all other parameters shall not be changed in a subsequent reconfiguration after the channel has reached the OPEN state.

This option is used to specify the type of Frame Check Sequence (FCS) that will be included on S/I-frames that are sent. It is non-negotiable. The FCS option shall only be used when the mode is configured to, or in an L2CAP_CONFIGURATION_REQ packet that contains an option configuring it to, Enhanced Retransmission mode or Streaming mode. This option shall only be used if the peer L2CAP entity has indicated support for the FCS Option in the Extended Features Mask (see Section 4.12).

Figure 5.6 specifies the format of this option. The Option Type is 0x05. "No FCS" shall only be used if both L2CAP entities send the FCS Option with value 0x00 (No FCS) in an L2CAP_CONFIGURATION_REQ packet. If one L2CAP entity sends the FCS Option with "No FCS" in an L2CAP_CONFIGURATION_REQ packet and the other L2CAP sends the FCS Option with a value other than "No FCS" then the default shall be used. If one or both L2CAP entities do not send the FCS option in an L2CAP_CONFIGURATION_REQ packet then the default shall be used.

Figure 5.6: FCS option format

The FCS types are shown in Table 5.3

Value of 0x00 is set when the sender wishes to omit the FCS from S/I-frames.

This option specifies a flow specification for requesting a desired Quality of Service (QoS) on a channel. It is non-negotiable. Extended Flow Specification may be supported on channels created over ACL-U logical links (see Section 7.10). If both devices show support for Extended Flow Specification for BR/EDR in the Extended Feature mask (see Table 4.12) then all channels created between the two devices shall use an Extended Flow Specification. The Quality of Service option and Flush Timeout option shall not be used if the Extended Flow Specification is used.

The parameters in the Extended Flow Specification option specify the traffic stream in the outgoing direction (transmitted traffic). The Option Type is 0x06. Figure 5.7 specifies the format of this option.

Figure 5.7: Extended Flow Specification option format

If no Extended Flow Specification is provided by the upper layer, an Extended Flow Specification with following default values shall be used:

For a Best Effort channel no latency, air-time or bandwidth guarantees shall be assumed.

The parameters of the Extended Flow Specification are shown in Table 5.5:

If “Guaranteed” is selected the QoS parameters can be used to identify different types of Guaranteed traffic.

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.

A channel shall not be configured as “Best Effort” in one direction and “Guaranteed” in the other direction. If a channel is configured in this way it shall be disconnected. A channel may be configured as “No Traffic” in one direction and “Best Effort” in the other direction. The “No Traffic” refers to the application traffic not the Enhanced Retransmission mode supervisory traffic. A channel configured in this way is considered to have a service type of Best Effort. A channel may be configured as “No Traffic” in one direction and “Guaranteed” in the other direction. A channel configure in this way is considered to have a service type of Guaranteed.

Once configured the service type of a channel shall not be changed during reconfiguration.

This option is used to negotiate the maximum extended window size. The Option Type is 0x07 and the option is non-negotiable. Figure 5.8 specifies the format of this option.

Figure 5.8: Extended Window Size option format

The allowable values for the Maximum Extended Window Size are:

This option shall only be sent if the peer L2CAP entity has indicated support for the Extended Window size feature in the Extended Features Mask (see Section 4.12).

This option shall be ignored if the channel is configured to use Basic L2CAP Mode (see Section 5.4).

For Enhanced Retransmission mode, this option has the same directional semantics as the Retransmission and Flow Control option (see Section 5.4). The sender of an L2CAP_CONFIGURATION_REQ packet containing this option is suggesting the maximum window size (possibly based on its own internal L2CAP receive buffer resources) that the peer L2CAP entity should use when sending data.

For Streaming mode, this option is used to enable use of the Extended Control Field and if sent, shall have a value of 0.

If this option is successfully configured then the Maximum Window Size negotiated using the Retransmission and Flow Control option (see Section 5.4) shall be ignored.

If this option is successfully configured in either direction then both L2CAP entities shall use the Extended Control Fields in all S/I-frames (see Section 3.3.2).

If the option is only configured in one direction then the maximum window size for the opposite direction shall be taken from the maximum window size value in the existing Retransmission and Flow Control option. In this configuration both L2CAP entities shall use the extended control fields in all S/I-frames.

It is implementation specific, and outside the scope of the specification, how the transmissions are triggered.

“Ignore” means that the signal can be silently discarded.

The following states have been defined to clarify the protocol; the actual number of states and naming in a given implementation is outside the scope of the specification:

In the following state tables and descriptions, the L2CAP_Data message corresponds to one of the PDU formats used on connection-oriented data channels as described in Section 3, including PDUs containing B-frames, I-frames, or S-frames.

Some state transitions and actions are triggered only by internal events effecting one of the L2CAP entity implementations, not by preceding L2CAP signaling messages. It is implementation-specific and out of the scope of the specification, how these internal events are realized; just for the clarity of specifying the state machine, the following abstract internal events are used in the state event tables, as far as needed:

There is a single state machine for each L2CAP connection-oriented channel that is active. A state machine is created for each new L2CAP_ConnectReq received. The state machine always starts in the CLOSED state.

To simplify the state event tables, the RTX and ERTX timers, as well as the handling of request retransmissions are described in Section 6.2 and not included in the state tables.

L2CAP messages not bound to a specific data channel and thus not impacting a channel state (e.g. L2CAP_InformationReq, L2CAP_EchoReq) are not covered in this section.

The following states and transitions are illustrated in Figure 6.1.

Configuration consists of two processes, the Standard process and the Lockstep process. The Lockstep process shall be used if both L2CAP entities support the Extended Flow Specification option otherwise the Standard process shall be used.

For both processes, configuring the channel parameters shall be done independently for both directions. Both configurations may be done in parallel.

Each configuration parameter is one-directional. The configuration parameters describe the non default parameters the device sending an L2CAP_CONFIGURATION_REQ packet will accept. The configuration request cannot request a change in the parameters the device receiving the request will accept.

If a device needs to establish the value of a configuration parameter the remote device will accept, then it must wait for an L2CAP_CONFIGURATION_REQ packet containing that configuration parameter to be sent from the remote device.

The Lockstep process is used when the channel parameters include an Extended Flow Specification option. The Lockstep process can be divided into two phases. In the first phase, each L2CAP entity shall receive an Extended Flow Specification option along with all non-default parameters from its peer L2CAP entity and then present the pair of Extended Flow specifications (local and remote) to its local Controller. In the second phase, each L2CAP entity shall report the result from its local Controller to the peer L2CAP entity. The Lockstep process is described in Section 7.1.3. The Standard process is described in Section 7.1.4.

Both the Lockstep and Standard processes can be abstracted into the initial Request configuration path and a Response configuration path, followed by the reverse direction phase. Reconfiguration follows a similar two-phase process by requiring configuration in both directions.

During a reconfiguration session, all data traffic on the channel should be suspended pending the outcome of the configuration. If an L2CAP entity receives an L2CAP_CONFIGURATION_REQ packet while it is waiting for a response it shall not block sending the L2CAP_CONFIGURATION_RSP packet, otherwise the configuration process may deadlock.

Fragmentation is the breaking down of PDUs into smaller pieces for delivery from L2CAP to the lower layer. Recombination is the process of reassembling a PDU from fragments delivered up from the lower layer. Fragmentation and Recombination may be applied to any L2CAP PDUs.

7.2.1. Fragmentation of L2CAP PDUs

An L2CAP implementation may fragment any L2CAP PDU for delivery to the lower layers, whether directly to the Controller or over HCI. All fragments associated with a specific L2CAP PDU shall be sent to the Controller, in the same order as their contents occur in the PDU, before any other fragment associated with the same logical link. Fragments associated with different logical links may be interleaved. (See [Vol 2] Part B, Section 5.3 and [Vol 6] Part B, Section 4.5.17 for related requirements on the Controller.)

For example, in the BR/EDR Controller the two LLID bits defined in the first octet of Baseband payload (also called the frame header) are used to signal the start and continuation of L2CAP PDUs. LLID shall be 0b10 for the first segment in an L2CAP PDU and 0b01 for a continuation segment. An illustration of fragmentation for a BR/EDR Controller is shown in Figure 7.1. An example of how fragmentation might be used in a device with HCI is shown in Figure 7.2.

Figure 7.1: L2CAP fragmentation in a BR/EDR Controller

Note

Note: The BR/EDR Link Controller is able to impose a different fragmentation on the PDU by using “start” and “continuation” indications as fragments are translated into Baseband packets. Thus, both L2CAP and the BR/EDR Link Controller use the same mechanism to control the size of fragments.

Figure 7.2: Example of fragmentation processes in a device with a BR/EDR Controller and USB HCI transport

All SDUs are encapsulated into one or more L2CAP PDUs.

In Basic L2CAP mode, an SDU shall be encapsulated with a minimum of L2CAP protocol elements, resulting in a type of L2CAP PDU called a Basic Information Frame (B-frame).

Segmentation and Reassembly operations are only used in Enhanced Retransmission mode, Streaming mode, Retransmission mode, and Flow Control mode. SDUs may be segmented into a number of smaller packets called SDU segments. Each segment shall be encapsulated with L2CAP protocol elements resulting in an L2CAP PDU called an Information Frame (I-frame).

The maximum size of an SDU segment shall be given by the Maximum PDU Payload Size (MPS). The MPS parameter may be exported using an implementation specific interface to the upper layer.

The specification does not describe a service interface with the upper layer, nor does it assume any specific buffer management scheme of a Host implementation. Consequently, a reassembly buffer may be part of the upper layer entity. It is assumed that SDU boundaries are preserved between peer upper layer entities.

7.3.1. Segmentation of L2CAP SDUs

In Flow Control, Streaming, or Retransmission modes, incoming SDUs may be broken down into segments, which shall then be individually encapsulated with L2CAP protocol elements (header and checksum fields) to form I-frames. I-frames are subject to flow control and may be subject to retransmission procedures. The header carries a 2 bit SAR field that is used to identify whether the I-frame is a 'start', 'end' or 'continuation' packet or whether it carries a complete, unsegmented SDU. Figure 7.3 illustrates segmentation and fragmentation.

Figure 7.3: Segmentation and fragmentation of an SDU in a BR/EDR Controller

7.3.3. Segmentation and fragmentation

Figure 7.4 illustrates the use of segmentation and fragmentation operations to transmit a single SDU. While SDUs and L2CAP PDUs are transported in peer-to-peer fashion, the fragment size used by the Fragmentation and Recombination routines is implementation specific and may be different in the sender and the receiver. The over-the-air sequence of packet fragments as created by the sender is common to both devices.

Figure 7.4: Example of segmentation and fragment processes in a device with a BR/EDR Controller and USB HCI Transport^[3]

Some applications may require corrupted or incomplete L2CAP SDUs to be delivered to the upper layer. If delivery of erroneous L2CAP SDUs is enabled, the receiving side will pass information to the upper layer on which parts of the L2CAP SDU (i.e., which L2CAP frames) have been lost, failed the error check, or passed the error check. If delivery of erroneous L2CAP SDUs is disabled, the receiver shall discard any L2CAP SDU segment with any missing frames or any frames failing the error checks. L2CAP SDUs whose SDU Length field (if provided) does not equal the sum of the segment payload sizes shall also be discarded.

In the L2CAP configuration using either the Flush Timeout option or the Extended Flow Specification option, the Flush timeout may be set separately per L2CAP channel, but in the BR/EDR Baseband, the flush mechanisms operate per ACL logical transport.

When there is more than one L2CAP channel mapped to the same ACL logical transport, the automatic flush timeout does not discriminate between L2CAP channels. The automatic flush timeout also applies to unicast data sent via the L2CAP connectionless channel. The exception is packets marked as non-automatically-flushable via the Packet_Boundary_Flag in the HCI ACL Data packet (see Section 1.1). The automatic flush timeout flushes a specific automatically-flushable L2CAP PDU. The HCI_Flush command flushes all outstanding L2CAP PDUs for the ACL logical transport including L2CAP PDUs marked as non-automatically-flushable. Therefore, care has to be taken when using the Automatic Flush Timeout and the HCI_Flush command. The HCI_Enhanced_Flush command should be used instead.

All packets associated with a reliable connection shall be marked as non-automatically-flushable (if it is mapped to an ACL logical transport with a finite automatic flush timeout) or L2CAP Enhanced Retransmission mode or Retransmission mode shall be used. In Enhanced Retransmission mode or Retransmission mode, loss of flushed L2CAP PDUs on the channel is detected by the L2CAP ARQ mechanism and they are retransmitted. L2CAP Enhanced Retransmission mode or Retransmission mode can be used for other purposes such as the need for a residual error rate that is much smaller than the Baseband can deliver. In this situation L2CAP Enhanced Retransmission mode or Retransmission mode and the Non-Flushable Packet Boundary Flag feature can be used at the same time.

If it is desired to send unicast data via the L2CAP connectionless channel which is not subject to automatic flushing, then the data should be marked as non-automatically flushable if it is mapped to an ACL logical transport with a finite automatic flush timeout. Unicast data sent via the L2CAP connectionless channel may be marked flushable.

There is only one automatic flush timeout setting per ACL logical transport. Therefore, all time bounded L2CAP channels on an ACL logical transport with an automatic flush timeout setting should configure the same flush timeout value at the L2CAP level. The flush timeout setting for the ACL logical transport also applies to unicast data sent via the L2CAP connectionless channel which are marked flushable.

If Automatic Flush Timeout is used, then it should be taken into account that it only flushes one L2CAP PDU. If one PDU has timed out and needs flushing, then other automatically-flushable packets on the same logical transport are also likely to need flushing. Therefore, flushing can be handled by the HCI_Enhanced_Flush command so that all outstanding automatically-flushable L2CAP PDUs are flushed.

When both reliable and isochronous data is to be sent over the same ACL logical transport, an infinite Automatic Flush Timeout can be used. In this case the isochronous data is flushed using the HCI_Enhanced_Flush command with Packet_Type set to “Automatically-Flushable Only,” thus preserving the reliable data.

In addition to connection-oriented channels, L2CAP also provides a connectionless channel. Data sent on the connectionless channel shall only be sent over the BR/EDR radio. The connectionless channel allows broadcast transmissions from the Central to all members of the piconet or unicast transmissions from either a Central or Peripheral to a single remote device. Data sent through the connectionless channel is sent in a best-effort manner. The connectionless channel provided by L2CAP has no quality of service.

While L2CAP itself does not provide retransmission for data sent via the connectionless channel, the Baseband does provide an ARQ scheme for unicast data (see [Vol 2] Part B, Section 7.6). If a higher degree of reliability is desired for unicast data sent via the connectionless L2CAP channel than is provided by the Baseband ARQ scheme then an ARQ scheme should be implemented at a higher layer.

No acknowledgment is provided by the Baseband for broadcast transmissions and hence broadcast transmissions sent via the connectionless L2CAP channel are unreliable and hence might or might not reach each member of the piconet.

The receiving L2CAP entity may silently discard data received via the connectionless L2CAP channel if the data packet is addressed to a PSM and no application is registered to receive data on that PSM.

L2CAP does not provide flow control for either connection-oriented L2CAP channels operating in Basic mode or for traffic on the connectionless L2CAP channel. Hence if data received by L2CAP is not accepted by the target applications in a timely manner, congestion can occur in a receiving L2CAP implementation. For connection-oriented channels, the receiving L2CAP entity may elect to close a channel if the target application for that channel does not accept the data in a timely manner. Since this option is not available for unicast data received via the connectionless L2CAP channel, the receiving L2CAP entity may instead elect to de-register the application receiving the data or to disconnect the underlying physical link. An application shall be notified if it is de-registered. If the underlying physical link is disconnected then all applications utilizing that physical link shall be notified.

Unicast data shall only be sent via the connectionless L2CAP channel to a remote device if the remote device indicates support for Unicast Connectionless Data Reception in the L2CAP Extended Features Mask.^[4]

The L2CAP Extended Features Mask should be retrieved using the L2CAP_INFORMATION_REQ packet to determine if Unicast Connectionless Data Reception is supported. Optionally, support for Unicast Connectionless Data Reception can be inferred from information obtained via a SDP or EIR. For example, if a service is found via SDP or EIR that is known to mandate the support of UCD, then it may be assumed that the device indicating support for the service supports Unicast Connectionless Data Reception.

Unicast data sent via the L2CAP connectionless channel are subject to automatic flushing and hence the packet boundary flags should be set appropriately if the Controller supports the Packet Boundary Flag feature. See Section 7.5 for further details. Since the receiving L2CAP entity has no mechanism to enable it to know whether received packets were originally marked as flushable or non-flushable on the transmitting device, the receiving L2CAP entity should treat all unicast packets received via the connectionless L2CAP packet as non-flushable.

If encryption is required for a given profile, then the profile or application shall ensure that authentication is performed and encryption is enabled prior to sending any unicast data on the connectionless L2CAP channel by utilizing Security Mode 4 as defined in GAP ([Vol 3] Part C, Section 5.2.2). There is no mechanism provided in the specification to prevent reception of unencrypted data on the connectionless L2CAP channel. An application which requires received data to be encrypted should ignore any unencrypted data it may receive over the connectionless channel.

Broadcast transmissions to the connectionless channel are sent with the broadcast LT_ADDR and hence may be received by any of the Peripherals in the piconet. If it is desirable to restrict the reception of the transmitted data to only a subset of the Peripherals in the piconet, then higher level encryption may be used to support private communication.

The Central will not receive transmissions broadcast on the connectionless channel. Therefore, higher layer protocols must loopback any broadcast data traffic being sent to the Central if required.

The connectionless data channel shall not be used with Enhanced Retransmission mode, Retransmission Mode or Flow Control Mode.

When two devices request the same operation by sending a request packet with the same code, a collision can occur. Some operations require collision resolution. The description of each operation in Section 4 will indicate if collision resolution is required. Both devices must know which request will be rejected. The following algorithm shall be used by both devices to determine which request to reject.

In order for Guaranteed channels to meet their guarantees, L2CAP should prioritize traffic over the HCI transport in devices that support HCI. Packets for Guaranteed channels should receive higher priority than packets for Best Effort channels.

If both the local L2CAP entity and the remote L2CAP entity indicate support for Extended Flow Specification for BR/EDR in the Extended Feature Mask then all channels created between the two devices shall send an Extended Flow Specification option and shall use the Lockstep configuration procedure. In addition all channels shall use Enhanced Retransmission mode or Streaming mode. If one or both L2CAP entities do not indicate support for Extended Flow Specification for BR/EDR in the Extended Feature Mask then the Lockstep configuration procedure shall not be used and the Extended Flow Specification option shall not be sent for channels created over the ACL-U logical link between the two devices.

The L2CAP entity shall perform admission control for Guaranteed channels during the Lockstep configuration procedure (see Section 7.1.3). Admission control is performed to determine if the requested Guaranteed QoS can be achieved by the BR/EDR or BR/EDR/LE Controller over an ACL-U logical link without compromising existing Guaranteed channels running on the Controller. If HCI is used then the L2CAP entity shall also verify that the QoS can be achieved over the HCI transport.

In performing admission control the L2CAP layer shall reject a Guaranteed QoS request that causes at least one of the following rules to be violated.

The data rate of a Guaranteed channel is calculated by dividing the Maximum SDU size in an Extended Flow Specification by the SDU Inter-arrival time. Total guaranteed data rate in both directions is calculated by taking the sum of the data rates in both directions for all existing Guaranteed channels plus the data rate in both directions of the requested Guaranteed channel (i.e. data rates from the both outgoing and incoming Extended Flow Specifications). Total guaranteed data rate for one direction is calculated by taking the sum of the data rates in one direction for all existing Guaranteed channels plus the data rate in the same direction of the requested Guaranteed channel.

An L2CAP entity should use additional information for admission control that may result in a Guaranteed QoS request being rejected even if none of the rules are violated. This allows the L2CAP entity to account for things such as CQDDR, SCO/eSCO channels, LMP traffic, page scanning, etc.

In order to meet the access latency and/or data rate required by a Guaranteed channel, the L2CAP entity should:

When a channel is reconfigured the Lockstep configuration process is only used when an Extended Flow Specification option is present in the L2CAP_CONFIGURATION_­REQ packet as described in Section 7.1.3.

In Enhanced Credit Based Flow Control Mode, each individual channel has its own MTU and MPS; both of these values can be reconfigured independently.

To perform reconfiguration, a device shall send an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet to the peer device with the new proposed MTU and MPS values and a set of channels to be reconfigured. The request shall not decrease the MTU of any channel and shall not decrease the MPS of a channel if more than one channel is specified.

When an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet is received and all the parameters are valid, the recipient shall complete sending all existing PDUs that require an MPS larger than the new MPS value for the channel in the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet and then send the L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet, with a zero Result field, to the peer device.

After the L2CAP_CREDIT_BASED_RECONFIGURE_RSP packet is sent, the MTU and MPS values of the channels included in the L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet shall be set to the MTU and MPS fields from that packet, and new SDUs shall be sent using the new MTU and MPS values.

When an L2CAP_CREDIT_BASED_RECONFIGURE_REQ packet is received with invalid parameters, the recipient shall send an L2CAP_CREDIT_BASED_RECONFIGURE_RSP PDU with a non-zero Result field and not change any MTU and MPS values.

Before attempting to configure Enhanced Retransmission mode, Streaming mode, Flow Control mode, or Retransmission mode on a channel, support for the suggested mode shall be verified by performing an information retrieval for the “Extended features supported” information type (0x0002). If the information retrieval is not successful or the “Extended features mask” bit is not set for the wanted mode, the mode shall not be suggested in a configuration request.

Two frame formats are defined for Enhanced Retransmission mode, Streaming Mode, Flow Control Mode, and Retransmission mode (see Section 3.3). The I-frame is used to transport user information instead of the B-frame. The S-frame is used for supervision.

The sending peer uses the following variables and sequence numbers:

The receiving peer uses the following variables and sequence numbers:

All variables have the range 0 to 63. Arithmetic operations on state variables (NextTXSeq, ExpectedTxSeq, ExpectedAckSeq, BufferSeq) and sequence numbers (TxSeq, ReqSeq) contained in this document shall be taken mod 64.

8.3.1. Sending peer

8.3.1.1. Send sequence number TxSeq

I-frames contain TxSeq, the send sequence number of the I-frame. When an I-frame is first transmitted, TxSeq is set to the value of the send state variable NextTXSeq. TxSeq is not changed if the I-frame is retransmitted.

8.3.1.2. Send state variable NextTXSeq

The CID sent in the information frame is the destination CID and identifies the remote endpoint of the channel. A send state variable NextTxSeq shall be maintained for each remote endpoint. NextTxSeq is the sequence number of the next in-sequence I-frame to be transmitted to that remote endpoint. When the link is created NextTXSeq shall be initialized to 0.

The value of NextTxSeq shall be incremented by 1 after each in-sequence I-frame transmission, and shall not exceed ExpectedAckSeq by more than the maximum number of outstanding I-frames (TxWindow). The value of TxWindow shall be in the range 1 to 32 for Retransmission mode and Flow Control mode. The value of TxWindow shall be in the range 1 to 63 for Enhanced Retransmission mode.

8.3.1.3. Acknowledge state variable ExpectedAckSeq

The CID sent in the information frame is the destination CID and identifies the remote endpoint of the channel. An acknowledge state variable ExpectedAckSeq shall be maintained for each remote endpoint. ExpectedAckSeq is the sequence number of the next in-sequence I-frame that the remote receiving peer is expected to acknowledge. (ExpectedAckSeq – 1 equals the TxSeq of the last acknowledged I-frame). When the link is created ExpectedAckSeq shall be initialized to 0.

Note

Note: If the next acknowledgment acknowledges a single I-frame then its ReqSeq will be expectedAckSeq + 1.

If a valid ReqSeq is received from the peer then ExpectedAckSeq is set to ReqSeq. A valid ReqSeq value is one that is in the range ExpectedAckSeq ≤ ReqSeq ≤ NextTxSeq.

Note

Note: The comparison with NextTXSeq must be ≤ in order to handle the situations where there are no outstanding I-frames.

These inequalities shall be interpreted in the following way: ReqSeq is valid, if and only if (ReqSeq-ExpectedAckSeq) mod 64 ≤ (NextTXSeq-ExpectedAckSeq) mod 64. Furthermore, from the description of NextTXSeq, it can be seen that (NextTXSeq-ExpectedAckSeq) mod 64 ≤ TxWindow.

Figure 8.1: Example of the transmitter side

Figure 8.1 shows TxWindow=5, and three frames awaiting transmission. The frame with number F7 may be transmitted when the frame with F2 is acknowledged. When the frame with F7 is transmitted, TxSeq is set to the value of NextTXSeq. After TxSeq has been set, NextTxSeq is incremented.

The sending peer expects to receive valid ReqSeq values, which are in the range ExpectedAckSeq to NextTxSeq. Upon receipt of a ReqSeq value equal to the current NextTxSeq all outstanding I-frames have been acknowledged by the receiver.

8.3.2. Receiving peer

8.3.2.1. Receive sequence number ReqSeq

All I-frames and S-frames contain ReqSeq, the send sequence number (TxSeq) that the receiving peer requests in the next I-frame.

When an I-frame or an S-frame is transmitted, the value of ReqSeq shall be set to the current value of the receive state variable ExpectedTxSeq or the buffer state variable BufferSeq. The value of ReqSeq shall indicate that the data Link Layer entity transmitting the ReqSeq has correctly received all I-frames numbered up to and including ReqSeq – 1.

Note

Note: The option to set ReqSeq to BufferSeq instead of ExpectedTxSeq allows the receiver to impose flow control for buffer management or other purposes. In this situation, if BufferSeq<>ExpectedTxSeq, the receiver should also set the retransmission disable bit to 1 to prevent unnecessary retransmissions.

8.3.2.2. Receive state variable ExpectedTxSeq

Each channel shall have a receive state variable (ExpectedTxSeq). The receive state variable is the sequence number (TxSeq) of the next in-sequence I-frame expected.

The value of the receive state variable shall be the last in-sequence, valid I-frame received.

8.3.2.3. Buffer state variable BufferSeq

Each channel may have an associated BufferSeq. BufferSeq is used to delay acknowledgment of frames until they have been pulled by the upper layers, thus preventing buffer overflow. BufferSeq and ExpectedTxSeq are equal when there is no extra segmentation performed and frames are pushed to the upper layer immediately on reception. When buffer space is scarce, for example when frames reside in the buffer for a period, the receiver may choose to set ReqSeq to BufferSeq instead of ExpectedTxSeq, incrementing BufferSeq as buffer space is released. The windowing mechanism will ensure that transmission is halted when ExpectedTxSeq - BufferSeq is equal to TxWindow.

Note

Note: Owing to the variable size of I-frames, updates of BufferSeq may be based on changes in available buffer space instead of delivery of I-frame contents.

I-frames shall have sequence numbers in the range ExpectedTxSeq ≤ TxSeq < (BufferSeq + TxWindow).

On receipt of an I-frame with TxSeq equal to ExpectedTxSeq, ExpectedTxSeq shall be incremented by 1 regardless of how many I-frames with TxSeq greater than ExpectedTxSeq were previously received.

Figure 8.2: Example of the receiver side

Figure 8.2 shows TxWindow=5. F1 is successfully received and pulled by the upper layer. BufferSeq shows that F2 is the next I-frame to be pulled, and ExpectedTxSeq points to the next I-frame expected from the peer. An I-frame with TxSeq equal to 5 has been received thus triggering an SREJ or REJ exception. The star indicates I-frames received but discarded owing to the SREJ or REJ exception. They will be resent as part of the error recovery procedure.

In Figure 8.2 there are several I-frames in a buffer awaiting the SDU reassembly function to pull them and the TxWindow is full. The receiver would usually disable retransmission in Retransmission mode or Flow Control mode by setting the Retransmission Disable Bit to 1 and send an RR back to the sending side. This tells the transmitting peer that there is no point in performing retransmissions. Both sides will send S-frames to make sure the peer entity knows the current value of the Retransmission Disable Bit.

When a link is configured to work in flow control mode, the flow control operation is similar to the procedures in retransmission mode, but all operations dealing with CRC errors in received packets are not used. Therefore

The behavior of flow control mode is specified in this section.

Assuming that the TxWindow size is equal to the buffer space available in the receiver (counted in number of I-frames), in flow control mode the number of unacknowledged frames in the transmitter window is always less than or equal to the number of frames for which space is available in the receiver.

Figure 8.3: Overview of the receiver side when operating in Flow Control mode

Enhanced Retransmission mode operates as an HDLC balanced data link operational mode. Either L2CAP entity may send frames at any time without receiving explicit permission from the other L2CAP entity. A transmission may contain single or multiple frames and shall be used for I-frame transfer and/or to indicate status change.

8.6.4. State diagram

The state diagram in Figure 8.4 shows the states and the main transitions. Not all events are shown on the state diagram.

Figure 8.4: Receiver state machine