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
For more details : Download the L2CAP
Specification from the SIG website, or visit the
L2CAP supports several important
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 .
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.
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
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.
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
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
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.
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
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
’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 ’chunks’ from the HCI and
reassembles those chunks into L2CAP packets using information provided
through the HCI and from the packet header.
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,
- 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.
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.
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.
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.
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
- 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