Why is the BLE protocol stack layered? How to understand BLE “connection”? What would happen if the BLE protocol only had the ATT layer without the GATT layer?
PHY Layer (Physical Layer).The PHY layer specifies the radio frequency band used by BLE, modulation and demodulation methods, etc. The quality of the PHY layer directly determines the power consumption, sensitivity, and selectivity of the entire BLE chip.
LL Layer (Link Layer).The LL layer is the core of the entire BLE protocol stack, and also the difficulty and focus of the BLE protocol stack. For example, Nordic’s BLE protocol stack can support 20 links simultaneously, thanks to the LL layer. The LL layer has many responsibilities, such as selecting which radio frequency channel to communicate on, how to identify air data packets, when to send packets, how to ensure data integrity, how to receive ACKs, how to retransmit, and how to manage and control the link, etc. The LL layer is only responsible for sending or receiving data; how to parse the data is left to the GAP or GATT layers above it.
HCI (Host Controller Interface).The HCI is optional (please refer to the article: Three Bluetooth Architecture Implementation Solutions), and is mainly used in scenarios where two chips implement the BLE protocol stack, to standardize the communication protocol and commands between them.
GAP Layer (Generic Access Profile). The GAP is one of the two ways to parse the LL layer payload (effective data packet), and it is the simplest one. GAP simply standardizes and defines the LL payload, so the functions that GAP can achieve are extremely limited. Currently, GAP is mainly used for broadcasting, scanning, and initiating connections.
L2CAP Layer (Logical Link Control and Adaptation Protocol).The L2CAP provides a simple encapsulation for the LL layer. The LL layer only cares about the data being transmitted, while L2CAP distinguishes between encrypted channels and ordinary channels, and also manages the connection interval.
SMP (Secure Manager Protocol). The SMP manages the encryption and security of BLE connections, ensuring connection security while not affecting user experience; these are the tasks that SMP must consider.
ATT (Attribute Protocol).Simply put, the ATT layer is used to define user commands and the data for command operations, such as reading or writing certain data. In the BLE protocol stack, the ATT is the layer that developers interact with the most. BLE introduces the concept of attributes to describe individual pieces of data. Attributes not only define data but also the ATT commands that can be used with that data, which is why this layer is called the ATT layer.
GATT (Generic Attribute Profile).The GATT standardizes the data content within attributes and uses the concept of groups to classify and manage attributes. Without GATT, the BLE protocol stack would still function, but interoperability would be problematic. It is precisely because of GATT and various application profiles that BLE has overcome the compatibility issues of wireless protocols like ZigBee, becoming the most widely shipped 2.4G wireless communication product.
This method seems appealing at first glance, but due to many overlooked details, it is actually impractical. First, it does not consider which radio frequency channel to use for transmission. Without changing the API, we can only layer the protocol stack, which introduces the LL layer. The developer still calls send(0x53), which then calls send_LL(0x53,2402M) (note: 2402M is the channel frequency). There is another problem: how does device B know whether this data packet is intended for itself or someone else? To address this, BLE introduces the concept of access address to indicate the recipient’s identity. Among them, the access address 0x8E89BED6 is special; it indicates that the data is to be sent to all nearby devices, i.e., broadcasting. If you want to communicate one-to-one (which BLE refers to as a connection), meaning device A’s data packet should only be received by device B, and vice versa, then a unique random access address must be generated to identify the connection between device A and device B.
2.1 Broadcasting
Let’s first look at a simple broadcasting scenario, where device A is called the advertiser, and device B is called the scanner or observer. In the broadcasting state, the LL layer API of device A will change to send_LL(0x53,2402M, 0x8E89BED6). Since device B can receive broadcasts from many devices simultaneously, the data packet must also include device A’s device address (0xE1022AAB753B) to confirm that this broadcast packet comes from device A. Therefore, the send_LL parameters need to be changed to (0x53,2402M, 0x8E89BED6, 0xE1022AAB753B). The LL layer also needs to check the integrity of the data, i.e., whether the data has been tampered with during transmission; for this, CRC24 is introduced to verify the data packet (assumed to be 0xB2C78E). Additionally, to make the modulation and demodulation circuit work more efficiently, a 1-byte preamble is added to the front of each data packet, which is typically 0x55 or 0xAA. Thus, the entire air packet becomes: (Note: the air packet is represented in little-endian format!)
The above data packet also has the following issues:
It does not classify and organize the data packet, so device B cannot find the desired data 0x53. Therefore, we need to add two fields after the access address: LL header and length byte. The LL header indicates the type of the LL data packet, while the length byte specifies the length of the payload.
When should device B open its radio frequency window to receive the air data packet? As shown in the figure above, in case 1, when device A’s data packet is being transmitted, device B’s receiving window is closed, resulting in a failed communication; similarly, in case 2, when device A is not sending any data packets, device B opens its receiving window, which also leads to a failed communication. Only in case 3, when device A’s data packet is being transmitted while device B’s radio frequency receiving window is open, can the communication succeed. In other words, the LL layer must also define the timing of communication.
When device B receives the data 0x53, how does it parse this data? Does it represent humidity, battery level, or something else? This is the job of the GAP layer. The GAP layer introduces the LTV (Length-Type-Value) structure to define data, for example, 020105, where 02 is the length, 01 is the type (mandatory field indicating the broadcast flag, which must be included in the broadcast packet), and 05 is the value. Since the maximum size of a broadcast packet is 31 bytes, the data types it can define are extremely limited. For the battery level mentioned here, the GAP has not defined it, so to send battery data via broadcasting, we can only use the vendor-defined data type 0xFF, which is 04FF590053, where 04 indicates the length, FF indicates the data type (vendor-defined data), 0x0059 is the vendor ID (mandatory field in the vendor-defined data), and 0x53 is our data (the two parties agree that 0x53 represents battery level, and not something else).
The final air transmission data packet will become:
AAD6BE898E600E3B75AB2A02E102010504FF5900538EC7B2
AA – Preamble
D6BE898E – Access Address
60 – LL Frame Header Field
0E – Payload Length
3B75AB2A02E1 – Advertiser Device Address
02010504FF590053 – Broadcast Data
8EC7B2 – CRC24 Value
Further details on the third part of the header will be introduced later.
With the PHY, LL, and GAP layers, we can send broadcast packets, but the information carried by broadcast packets is extremely limited, and there are several major limitations:
One-to-one two-way communication is not possible (broadcasting is one-to-many communication and is unidirectional).
Since packaging and unpacking are not supported, large data cannot be transmitted.
Communication is unreliable and inefficient. The broadcast channel cannot be too many, or it will lead to low efficiency at the scanning end. Therefore, BLE only uses three channels for broadcasting and scanning: 37 (2402MHz), 38 (2426MHz), and 39 (2480MHz), and broadcasting does not support frequency hopping. Since broadcasting is one-to-many, it also cannot support ACK. These factors make broadcast communication unreliable.
The power consumption at the scanning end is high. Since the scanning end does not know when the device side broadcasts or which channel it uses for broadcasting, the scanning end can only extend the scanning window time and scan all three channels (37/38/39) simultaneously, resulting in higher power consumption.
However, connections can solve these problems well. Next, let’s see how to send 0x53 through a connection.
2.2 Connection Method
What exactly is a connection? Like wired UART, it is easy to understand; it means connecting device A and device B with wires (Rx, Tx, etc.), which constitutes a connection. Connecting two devices with “wires” actually means that the two devices have a common communication medium and synchronize their clocks. The Bluetooth connection follows the same principle; establishing a Bluetooth connection between device A and device B means that the two devices successfully synchronize one-to-one, which specifically includes the following aspects:
• Device A and device B agree on the physical channel to be used next.
• Device A and device B establish a common time anchor, meaning they set their time origins to the same point.
• Device A and device B successfully synchronize their clocks, so both parties know when to send and receive data packets.
Once the connection is successful, the communication flow between device A and device B is as follows:
As shown in the figure, once device A and device B successfully connect (in this case, device A is referred to as the Master or Central, and device B as the Slave or Peripheral), device A will periodically send data packets to device B at intervals of CI (connection interval), while device B will also periodically open its radio frequency receiving window to receive data packets from device A at the same CI interval. According to the Bluetooth specification requirements, 150us after receiving a data packet from device A, device B switches to sending mode to send its data to device A; device A then switches to receiving mode to receive the data sent by device B. Thus, it can be seen that during the connection state, the sending and receiving windows of devices A and B are both periodically opened and closed in a planned manner, and the open time is very short, which greatly reduces system power consumption and significantly improves system efficiency.
Now let’s see how to send the data 0x53 in the connection state, from which everyone can appreciate the cleverness of the layered BLE protocol stack.
For developers, it is very simple; they only need to call send(0x53).
The GATT layer defines the type and grouping of the data; for convenience, we use 0x0013 to represent the battery level data type, so the GATT layer packages the data into 130053 (little-endian format!).
The ATT layer is used to select specific communication commands, such as read/write/notify/indicate, etc. Here we choose the notify command 0x1B, so the data packet becomes: 1B130053.
The L2CAP specifies the connection interval (CI), for example, synchronizing every 10ms (CI is not reflected in the data packet), and also specifies the logical channel number 0004 (indicating the ATT command), finally adding the ATT data length 0x0004 to the header, so the data becomes: 040004001B130053.
The LL layer has many responsibilities; first, the LL layer needs to specify which physical channel to use for transmission (the physical channel is not reflected in the data packet), then assign an Access Address (0x50655DAB) to this connection to indicate that this connection is only for direct communication between device A and device B, and then add the LL header and payload length fields. The LL header indicates that this packet is a data packet, not a control packet, etc., while the payload length indicates the total length of the L2CAP field, and finally add the CRC24 field to ensure the integrity of the entire packet.
Thus, the final data packet becomes:
AAAB5D65501E08040004001B130053D550F6
AA – Preamble
0x50655DAB – Access Address
1E – LL Frame Header Field
08 – Payload Length
04000400 – ATT Data Length, and L2CAP Channel Number
1B – Notify Command
0x0013 – Battery Data Handle
0x53 – The actual battery data to be sent
0xF650D5 – CRC24 Value
Although the developer only called send(0x53), due to the layered packaging of the low energy Bluetooth protocol stack, the actual data transmitted in the air will look like the diagram below, which both meets the requirements of low energy Bluetooth communication and simplifies the user API, achieving a dual purpose!
Further details on the third part of the header will be introduced later.
This is just a simple overview of the implementation principles of the BLE protocol stack. Even so, as it involves the low-level aspects of the BLE protocol stack, many developers may find it quite dull and obscure. Moreover, for many developers, they are not concerned with how the BLE protocol stack is implemented; they are more interested in how to use the BLE protocol stack, i.e., how to develop a BLE application. BLE applications are tangible things that cannot be discussed vaguely like the protocol stack above; they must be explained in conjunction with specific Bluetooth chips and Bluetooth protocol stacks. Therefore, the following sections will use Nordic chips and protocol stacks as examples to specifically explain how to develop BLE applications and how to understand some concepts and terms defined in the BLE protocol through code.
Tags: ATT, GAP, Link Layer, GATT, L2CAP, BLE Stack, Broadcasting, Connection, BLE Protocol Stack, Link Layer
3.1 Basic Concepts
(1) Link Layer State Machine
There are five states:
Ready State: Central state, any state can transition to it;
Broadcast State: Using broadcast messages
Scanning State: Using broadcast messages, cannot connect
Initiating State: Using broadcast messages, randomly initiating connection
Connection State: Using data messages;
(2) Protocol Stack
Please refer to the article: Understanding Bluetooth Advertising Packets for the content of the protocol stack.
Chinese version: http://blog.csdn.net/ooakk/article/details/7302425
(3) Communication Channels
BLE operates in the ISM band, defining two frequency bands, 2.4GHz and 896/915MHz. In IEEE802.15.4, a total of 27 channels are specified:
In the 2.4GHz band, there are 16 channels, with a communication rate of 250kbps:
In the 915MHz band, there are 10 channels, with a communication rate of 40kbps:
In the 868MHz band, there is 1 channel, with a communication rate of 20kbps.
BLE operates in the 2.4GHz band, using only 3 broadcast channels, applicable to all Bluetooth specification versions with adaptive frequency hopping technology.
Bluetooth has 79 radio frequency channels, numbered 0-78, starting at 2402 MHz, spaced 1 MHz apart.
BTLE has 40 channels (also called channels), starting with 37, followed by 0-36, and then channel 39.
Due to space limitations, the specific implementation of the protocol stack will be explained in subsequent content.
Original source: FreeBuf
