Logical Link And Adaptation
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 packets up to 64 Kilobytes in length.
L2CAP only supports ACL links. L2CAP uses the concept of channels to
establish different pathways between different applications on
Bluetooth devices. These channels are identified by Channel
IDentifiers (CIDs) which represent a logical end point of a
connection for each application on a device. CIDs are 16 bit numbers
of which 0x0001 to 0x003F are reserved for specific L2CAP functions
(0x0001 is a signalling channel, 0x0002 is a connectionless
reception channel and rest are reserved or prohibited).
Connection Identifiers (CIDs)
The idea behind L2CAP is to provide an interface similar to
TCP/IP function calls. In NSBLUE, the L2CAP connections and data are
sent in the following manner:
cid =
l2cap->openL2CAPConnection(ui->getContext());
l2cap->send(cid,data,len);
l2cap->recv(cid,data,len);
where `cid' is the channel identifier, `data' is the pointer to
``char'' and `len' is the length of the data. `getContext()' returns
the local context like `Walmart', `JFK Airport' etc. CID is assigned
from a pool of free CIDs (pool can be assigned in blocks to save
memory). See `CONNECTION ESTABLISHMENT IN BLUETOOTH' for more
information.
Protocol Multiplexing
L2CAP also does protocol multiplexing by using PSM field in the
L2CAP Connection Request command. L2CAP can multiplex connection
requests to upper layer protocols like Service Discovery Protocol
(PSM = 0x0001), RFCOMM (PSM = 0x0003) and Telephony Control (PSM =
0x0005).
Segmentation and 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 the overhead
by spreading the network and transport packets used by higher layer
protocols over several baseband packets. L2CAP segments higher layer
packets into `chunks' that can be passed to the Link Manager for
transmission and reassembles those chunks into L2CAP packets using
information provided through HCI and from packet header. SAR is
implemented using very little overhead in Baseband packets. The two
L_CH bits defined in the first byte of Baseband payload (also called
the frame header) are used to signal the start and continuation of
L2CAP packets (L_CH shall be `10' for the first segment and `01' for
a continuation segment. To avoid any reassembly problems due to out
of order packets, all L2CAP segments associated with an L2CAP packet
must be passed through to the Baseband before any other L2CAP packet
destined to the same unit may be sent. Also `Stop and Wait' protocol
used by Baseband makes sure that a packet is received correctly by
the other unit before the next packet is sent. This avoids most of
the out of the order packets, as received in wireline TCP/IP
connections because of `window' based transmissions.
L2CAP Events and Actions
L2CAP operates using events and commands which it receives or
transmits from/to upper or lower layers. These events can be, for
instance, a connection request from the upper layer, a data write
request or may be a disconnection request. The lower layers can tell
L2CAP about incoming connection, disconnection or other requests. If
L2CAP of this unit needs to talk to the L2CAP on the other unit,
then it uses some special commands which are called signalling
commands. These commands are generally used to establish
connection-oriented channels after a link level connection is
created or present. L2CAP has seven operational states: CLOSED,
W4_L2CA_CONNECT_RSP, W4_L2CAP_CONNECT_RSP, CONFIG, OPEN,
W4_L2CAP_DISCONNECT_RSP, and W4_L2CA_DISCONNECT_RSP. These states
further make L2CAP connections look similar to TCP connections.
Signalling command codes
| Code |
Description |
| 0x00 |
RESERVED |
| 0x01 |
Command reject |
| 0x02 |
Connection request |
| 0x03 |
Connection response |
| 0x04 |
Configure request |
| 0x05 |
Configure response |
| 0x06 |
Disconnection request |
| 0x07 |
Disconnection response |
| 0x08 |
Echo request |
| 0x09 |
Echo response |
| 0x0a |
Information request |
| 0x0b |
Information
response | |