Logical Link Control and Adaptation Protocol

   The Logical Link Control and Adaptation Layer Protocol (L2CAP) is layered over the Baseband Protocol and resides in the data link layer. L2CAP provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstractions. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length.

    Two link types are supported for the Baseband layer : Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links. SCO links support real-time voice traffic using reserved bandwidth. ACL links support best effort traffic. The L2CAP Specification is defined for only ACL links and no support for SCO links is planned.

For more details : Download the L2CAP Specification from the SIG website, or visit the Documents Page

Table Of Contents

5.1  L2CAP Functional Requirements

    L2CAP supports several important protocol requirements:

5.1.1  Protocol Multiplexing

    L2CAP must support protocol multiplexing because the Baseband Protocol does not support any ’type?field identifying the higher layer protocol being multiplexed above it. L2CAP must be able to distinguish between upper layer protocols such as the Service Discovery Protocol , RFCOMM , and Telephony Control .

5.1.2  Segmentation & Reassembly

    Compared to other wired physical media, the data packets defined by the Baseband Protocol  are limited in size. Exporting a maximum transmission unit (MTU) associated with the largest Baseband payload (341 bytes for DH5 packets) limits the efficient use of bandwidth for higher layer protocols that are designed to use larger packets. Large L2CAP packets must be segmented into multiple smaller Baseband packets prior to their transmission over the air. Similarly, multiple received Baseband packets may be reassembled into a single larger L2CAP packet following a simple integrity check. The Segmentation and Reassembly (SAR) functionality is absolutely necessary to support protocols using packets larger than those supported by the Baseband.

5.1.3  Quality of Service

    The L2CAP connection establishment process allows the exchange of information regarding the quality of service (QoS) expected between two Bluetooth units. Each L2CAP implementation must monitor the resources used by the protocol and ensure that QoS contracts are honoured.

5.1.4  Groups

    Many protocols include the concept of a group of addresses. The Baseband Protocol supports the concept of a piconet, a group of devices synchronously hopping together using the same clock. The L2CAP group abstraction permits implementations to efficiently map protocol groups on to piconets. Without a group abstraction, higher level protocols would need to be exposed to the Baseband Protocol and Link Manager functionality in order to manage groups efficiently.

5.2  L2CAP General Operation

    The L2CAP layer is based around the concept of ’channels? Each one of the end-points of an L2CAP channel is referred to by a channel identifier.

5.2.1  Channel Identifiers

    Channel identifiers (CIDs) are local names representing a logical channel end-point on the device. Implementations are free to manage the CIDs in a manner best suited for that particular implementation, with the provision that the same CID is not reused as a local L2CAP channel endpoint for multiple simultaneous L2CAP channels between a local device and some remote device.

     CID assignment is relative to a particular device and a device can assign CIDs independently from other devices (with the exception of certain reserved CIDs , such as the signalling channel). 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.

5.2.2  Operation between Devices

    The connection-oriented data channels represent a connection between two devices, where a CID identifies each endpoint of the channel. The connectionless channels restrict data flow to a single direction. These channels are used to support a channel ’group?where the CID on the source represents one or more remote devices. There are also a number of CIDs reserved for special purposes. The signalling channel is one example of a reserved channel. This channel is used to create and establish connection-oriented data channels and to negotiate changes in the characteristics of these channels. Support for a signalling channel within an L2CAP entity is mandatory. Another CID is reserved for all incoming connectionless data traffic.

5.2.3  Operation between Layers

    L2CAP implementations follow the general architecture described here:

• L2CAP implementations must transfer data between higher layer protocols and the lower layer protocol.
• Each implementation must also support a set of signalling 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 an implementation-dependent process.

5.2.4  Segmentation & Reassembly

    Segmentation and reassembly (SAR) operations are used to improve efficiency by supporting a maximum transmission unit (MTU) size larger than the largest Baseband packet. This reduces overhead by spreading the network and transport packets used by higher layer protocols over several Baseband packets. All L2CAP packets may be segmented for transfer over Baseband packets. The protocol does not perform any segmentation and reassembly operations but the packet format supports adaptation to smaller physical frame sizes.

    An L2CAP implementation exposes the outgoing (i.e., the remote host’s receiving) MTU and segments higher layer packets into ?strong>chunks?that can be passed to the Link Manager via the Host Controller Interface (HCI), whenever one exists. On the receiving side, an L2CAP implementation receives ?strong>chunks?from the HCI and reassembles those chunks into L2CAP packets using information provided through the HCI and from the packet header.

5.3  L2CAP State Machine

    This section describes the L2CAP connection-oriented channel state machine. The section defines the states, the events causing state transitions, and the actions to be performed in response to events. This state machine is only pertinent to bi-directional CIDs and is not representative of the signalling channel or the uni-directional channel.

*Diagram Source: Courtesy of Bluetooth SIG, L2CAP Specs, Fig 3.1 , p 258

    The figure* above illustrates the events and actions performed by an implementation of the L2CAP layer. Client and Server simply represent the initiator of the request and the acceptor of the request respectively. An application-level Client would both initiate and accept requests. The naming convention is as follows.

• The interface between two layers (vertical interface) uses the prefix of the lower layer offering the service to the higher layer, e.g., L2CA.
• The interface between two entities of the same layer (horizontal interface) uses the prefix of the protocol (adding a P to the layer identification), e.g., L2CAP.
• Events coming from above (starting above) are called Requests (Req) and the corresponding replies are called Confirms (Cfm).
• Events coming from below (starting below) are called Indications (Ind) and the corresponding replies are called Responses (Rsp).
• Responses requiring further processing are called Pending (Pnd). The notation for Confirms and Responses assumes positive replies. Negative replies are denoted by a ’Neg?suffix such as L2CAP_ConnectCfmNeg.

5.4  Other L2CAP Features

5.4.1  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 packet fields use Little Endian byte order.

5.4.2  Signalling

    Various signalling commands can be passed between two L2CAP entities on remote devices. All signalling commands are sent to CID 0x0001 (the signalling channel). The L2CAP implementation must be able to determine the Bluetooth address (BD_ADDR) of the device that sent the commands. Multiple commands may be sent in a single (L2CAP) packet and packets are sent to CID 0x0001. MTU Commands take the form of Requests and Responses. For a complete list see the L2CAP specs.

5.4.3  Configuration Parameter Options

   Options are a mechanism to extend the ability to negotiate different connection requirements. Options are transmitted in the form of information elements comprised an option type, an option length, and one or more option data fields.

5.4.4  Service Primitives

    Several services are offered by L2CAP in terms of service primitives and parameters. The service interface is required for testing. They include primitives to :

• Connection: setup , configure , disconnect
• Data:  read  , write
• Group: create, close, add member, remove member , get membership
• Information: ping, get info, request a call-back at the occurrence of an event
• Connection-less Traffic: enable, disable

Note , the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.