Ti_ble Software Developer Guide 6--l2cap (Notes) __ Reading notes

Texas Instruments CC2540/41
Bluetooth®low Energy
Software Developer ' s Guide
v1.3.2
Document number:swru271f

"Low power consumption Bluetooth Development Authority Guide"
Robin Heydon, Chen Zanfeng, Sheila translation
Machinery Industry Press
2014.6 ti_ble Software development notes 6-l2cap

Ti_ble Software Development Notes 6-L2CAP background L2CAP channel L2CAP packet Structure low power signaling Channel 1 command rejects 2 connection parameter update requests and responses

Logical Link control and adaptation PROTOCOL,L2CAP is a reusable layer that allows BLE to reuse three different channels. It also supports the segmentation and reorganization of data so that larger messages can be transmitted in the underlying radio. 1 Background

Unlike classic Bluetooth, a basic concept of low power Bluetooth is the connectionless mode. Users only establish connections when they need to send data, and other times the device can be disconnected for a long time. In order to implement this feature, connectionless mode must be extended to the L2CAP layer, and only a fixed channel can be used. This is because the fixed channel does not need to configure any parameters and once the underlying link is established, the fixed channel can be immediately put into use, eliminating the extra time spent establishing the channel.
In classical Bluetooth, there are two types of channels: fixed channel and connection-oriented channel. The fixed channel already exists as long as two devices are connected. The fixed channel is mainly used as signaling channel. The connection-oriented channel can be established at any time, only need to send some l2cap signaling to the end. 2 L2cap Channel

A channel is a sequence of packets that connects a pair of services on two devices. Allows multiple channels to be enabled simultaneously between two devices.
BLE only supports fixed channels. The fixed-letter Dow is a channel in which two devices already exist without any configuration parameters when a connection is established. Thanks to the flexibility of future expansion, you can add a connection-oriented channel to your needs later.
The L2CAP channel identifier looks like this:

Channel identifier	usage
0x0000	Reserved: cannot use
0x0001	Classic Bluetooth Signaling Channel
0x0002	No connection Channel
0x0003	AMP Management Protocol
0x0004	Property protocol
0x0005	Low Power signaling Channel
0x0006	Security Management Protocol
0x0007 ~ 0x003e	Reservation: Possible future use
0x003f	AMP Test Protocol
0x0040 ~ 0xFFFF	Connection-oriented channel

The channel identifier 0x0003 is used for the alternate mac/phy protocol that is used when data is required for transmission at a high rate. The channel identifier 0x003f is used to test the alternate mac/phy controller.
BLE uses 3 channels: 0x0004 for property protocols, 0x0005 for Low-power Bluetooth signaling channels, and 0x0006 for security management. 3 L2CAP Packet Structure

The net charge front end of each L2CAP packet contains a 32-bit bit header. If you use Split and reassembly, the packet length information must be included in the header to determine the end of the packet. The segmentation and reorganization mechanisms are used to mark each packet through the HCI interface, divided into start packets or continuation packets.
The L2CAP packet structure looks like this:

The Length field represents the number of information payload bytes after the header. On all BLE channels, the information payload starts at 23 bytes of the Maximum transmission Unit (Maximum transmission UNIT,MTU). The MTU represents the maximum number of bytes of information payload in a L2CAP channel. This means that all BLE devices must support the transfer of 27-byte packets in space--4-byte headers + 23-byte information payload. 4 Low power signaling channel

Low-power signalling channels are used for signaling at the host level. The L2CAP command packet looks like this:

Each low power signaling channel packet contains an opcode, followed by various parameters. Low power signalling channel supported command opcode as follows: Command reject connection parameter update request connection parameter Update response

Whenever a signaling command is sent, its information payload always contains an identifier. This identifier is only 1 bytes long and is used to match requests and responses. For example, if the requested identifier is 0x35, the packet that should be requested must also use 0x35 as an identifier. As a result, multiple requests can be sent at the same time, as long as each request has a different identifier. Because reuse is not allowed until all identifiers are used, the implementation typically takes an incremental action to ensure that the rule is met, with one exception: No, um, you can use identifier 0x00.
In Ble, the logic of identifiers is relatively simple because only one type of request command is defined and the request command is used only for situations where no other request is sent. 4.1 Order Refusal

Command reject is used to reject unsupported packets received by the device. Contains a reason code and related information. The reason code can be either "command not understood" or "signaling MTU overflow." The "Signaling MTU Overflow" Reason code can be used when the received command is greater than 23 bytes. 4.2 Connection parameter update request and response

The connection parameter Update Request command lets you update the link layer connection parameters from the device , including the connection event interval, the delay from the device, and the monitoring timeout, as follows:

    Participant main device
    participant from device
    -> main device: L2cap connection parameter update request
    main device-> from device: L2cap connection parameter update response
    from device-> main device: Link Layer Connection update request (instantaneous)
    note left main device: Instantaneous over
    main device, from device: Enable new connection parameters

In a connection, you can use this command if you want to modify the current connection parameter from a device. The connection parameter update request command is only used to send from the device to the main device, because the main device can start the link layer Connection parameter Update control procedure at any time. If the command has a primary device to send, the device treats it as an error and returns the command reject command with the "command not understood" reason code.
From the device can be sent to the command at any time. If the primary device that receives this information can modify the connection parameters, the connection parameter update response is returned, and the resulting code is set to receive, and then the main device initiates the link layer Connection parameter update control procedure. If the primary device does not agree to request parameters from the device, you can send the result code to the "Deny" Connection parameter Update Response command to reject the request. At this point, there are two choices from the device, either accepting the connection parameters that the primary device expects to use or terminating the connection.