Bluetooth Core-l2cap__ bluetooth

Summary:Logical link Control and adaptation Protocol (L2CAP), which supports high level protocol multiplexing, data segmentation and reorganization, and supports the delivery of quality of service information. This paper is mainly about the protocol state automata, packet format and composition related content description. L2cap Hierarchy (l2cap architectural blocks):

The baseband specification defines two types of links: synchronous oriented to connection links (SCO) and asynchronous connectionless links (ACLs). SCO links use reserved bandwidth to support real-time voice communications. ACL links support Optimal communication. The L2CAP specification defines ACL links only and does not support SCO links.
Here are some of the major features of L2cap: 1. Protocol multiplexingL2cap should support protocol reuse because the baseband protocol does not support any ' type ' domains, which are used to identify higher-level protocols to be reused. L2cap must be able to differentiate between high-level protocols, such as service search protocols, RFCOMM, and phone controls.
2. Fragmentation and ReorganizationGroupings defined by the baseband protocol are limited in size compared to other wired physical media. The Maximum Transmission Unit (MTU) associated with the maximum base-band payload (341 bytes in the DH5 packet) limits the efficient use of higher-layer protocol bandwidth, while higher-level protocols use larger groupings. Large l2cap groupings must be segmented into several small baseband groupings before the wireless transmission. Similarly, a large, single l2cap grouping can be reassembled after receiving multiple subgroups of small bands. When you use the Biki band to group larger packet protocols, you must use the staging and Reorganization (SAR) feature.
3. Quality of serviceThe L2CAP connection establishment process allows you to exchange information about the quality of service between two Bluetooth units. Each L2CAP device must monitor the resources used by the Protocol and ensure a complete implementation of quality of service (QoS).
4. GroupMany protocols include the concept of address groups. The baseband protocol supports a Pico network, which is a set of devices capable of synchronizing with 1:. L2CAP Group concept can be implemented on the Pico Network of Effective protocol mapping. Without a group concept, a high-level protocol must deal directly with the baseband protocol and the link manager as an effective management group.

the basis of the protocol design:

1. Use the Link Manager protocol to establish an ACL link between two units. Baseband provides sequential transmission of data packets, but may also have individual groupings damaged or duplicated. There will only be one ACL link between any two devices.

2. The baseband usually provides a full-duplex channel. But this is not to say that all L2CAP communications are two-way. Multicast and one-way communications (for example, video) do not require a duplex channel.

3. By using the mechanism provided by the baseband layer, L2CAP provides a reliable channel. When the request and postback data is received, the baseband typically performs a data integrity check until the data is successfully validated or timed out. Because a confirmation message may be lost, a time-out can occur even after the data has been successfully sent. The baseband protocol uses a 1-bit serial number, which is used to delete a repeatedly sent packet. Because the first segment of all broadcast L2CAP data is grouped with the same sequence bit, the use of baseband broadcast grouping should be prohibited if reliable transmission is required. l2cap Scope of application: 1.l2cap does not transmit audio data specified by the SCO link. 2.l2cap cannot transmit reliably or guarantee data integrity, i.e., L2CAP will not be sent back or data checksum. 3.l2cap does not support a reliable broadcast channel. 4.l2cap does not support the concept of a global group name.
Link Main operation

Logical link Control and adaptation Protocol (L2CAP) are based on the concept of channel. The endpoint of each L2CAP channel is referenced through the channel identifier. 1. Channel identifier

The channel identifier (CIDS) is the name of the local-port device representing the logical channel. Identifiers from 0x0001 to 0x003f are reserved for specific l2cap functions. The empty identifier (0x0000) is defined as an illegal identifier and must not be used on the target side. The rest of the CID can be freely managed in the right way, depending on the purpose and circumstances of the application. However, in the case where multiple concurrent l2cap channels exist for a local device and multiple remote devices, the same CID must not be used as the local L2CAP channel end.
The above diagram is a summary of the definition and division of the CID namespace. The CID designation is related to a particular device, and a device can designate CID independently of other devices (if it does not use the retained CID listed in the table below). In this way, even if the same CID value is assigned to the (remote) channel side by multiple remote devices connected to a local device, the local device can still connect the remote CID to each of the different remote devices.
2. Operation between devices (OPERATION BETWEEN DEVICES)
The above illustration illustrates the use of CID in the communication between different device peers l2cap entities. A connection-oriented data channel provides a connection between two devices, while CID identifies each end of the channel. A connectionless channel restricts the flow of data to a single direction. These channels are used to support a channel "group" in which the sending-side CID is used to represent one or more remote devices. Some CID is therefore reserved for future special use. The signal channel is an example of a reserved channel, fixed cid=0x0001. The channel is used to create and establish connection-oriented data channels, and to negotiate the characteristics of these channels. L2CAP entities must support signal channels. The other CID retains connectionless data communication for incoming calls, and no connected receiving channel CID=0X0002.

Channel identification type diagram:

3. Inter-layer operation (OPERATION BETWEEN LAYERS)
The implementation of L2CAP should follow the overall architecture of the above diagram and transmit data between high-level protocols and low-level protocols. This article lists some of the services that L2CAP applications must implement. Each application must support a set of signaling instructions for communication between L2CAP applications. L2cap applications should also be prepared to accept certain types of events from the lower levels and generate events to the high-level. How events are passed between tiers depends on the actual application.

4.MODES of OPERATION L2CAP channels may operate in one of the five different modes as selected for each l2cap. The Modes are: basic L2cap Mode (equivalent to L2CAP specification in Bluetooth v1.1) 1 flow control mode Retransmis Sion mode enhanced retransmission mode streaming mode le credit Based flow control Mode
5.MAPPING channels to LOGICAL LINKS

L2cap maps a logical link to the controller that runs on top of the controller physical link. All logical links run on top of a single physical link between the local controller and the remote controller. Each BR/EDR physical link has a acl-u logical link, each le-u physical link has a le logical link, but the amp physical link may have multiple amp-u logical links.

Channels running on physical links to two BR/EDR devices should be mapped to a single acl-u logical link. Channels on physical links running on two amp devices should be mapped to a single amp-u logical link, whereas each channel between the two controllers must be in his own one by one corresponding amp-u logical link. The channel on the physical link running on two Le devices should be mapped to a single le-u logical link.

For the BR/EDR controller, the L2CAP implements permissions control (create and authorize logical links). For the amp controller, L2CAP notifies the controller to create and authorize logical links, which are ultimately created and authorized by the Controller.
Packet format 1. Link-oriented channel 1.1BASIC l2cap MODE
1.2 Retransmission/flow control/streaming MODES 1.3 LE Credit BASED flow control MODE 9> 2. Channel not connected 1.1 BASIC l2cap MODE 3. Signal Packet Format (signaling PACKET FORMATS)
Command load Format:

Code specifically see "BLUETOOTH Specification Version 4.1 [Vol. 3] page 668"
SDP requests linked packets:

00000010 00110010 00000000 00001100 00000000 00001000 00000000 00000001 00000000 0000001000000001 00000100-0000 0000 00000001 00000000 01000001 00000000

Each color corresponds to the following fields: