Learn to understand the Bluetooth low energy protocol stack

Learning purpose : Why does the BLE protocol stack need to be layered? How to understand BLE "connection"? What is ATT used for? What about GATT? What will happen if the BLE protocol only has an ATT layer and no GATT layer?

1.Protocol stack framework

Generally speaking, we call the implementation code of a certain protocol a protocol stack. The BLE protocol stack is the code that implements the Bluetooth Low Energy protocol. Understanding and mastering the BLE protocol is the prerequisite for implementing the BLE protocol stack. Before going deep into the various components of the BLE protocol stack, let's first take a look at the overall architecture of the BLE protocol stack. The

BLE protocol stack is mainly used to package your application data layer by layer to generate an air data packet that satisfies the BLE protocol. In other words, Wrap application data in a series of headers and tails. Specifically, the BLE protocol stack mainly consists of the following parts:

1. PHY layer : The PHY layer is used to specify the wireless frequency band used by BLE, modulation and demodulation methods, etc.
   - LL layer: The LL layer is the core of the entire BLE protocol stack, and is also the difficulty and focus of the BLE protocol stack. The LL layer is only responsible for transmitting data Whether it is sent out or received back, how to analyze the data is left to the GAP or GATT above.
2. HCI layer: HCI is mainly used when two chips implement the BLE protocol stack to standardize the communication protocol and communication commands between the two.
3. L2CAP layer: L2CAP must distinguish whether it is an encrypted channel or a normal channel, and it must also manage the connection interval.
4. SMP layer: SMP is used to manage the encryption and security of BLE connections.
5. ATT layer: The ATT layer is used to define user commands and command operation data, such as reading certain data or writing certain data. In the BLE protocol stack, developers have the most exposure to ATT. BLE introduces the attribute concept to describe data one by one . In addition to defining data, Attribute also defines the ATT commands that can be used by the data.
6. GATT layer: GATT is used to standardize the data content in attributes and use the concept of group to classify and manage attributes.
7. GAP layer: GAP describes the basic operations of two Bluetooth links, including device discovery, link establishment, configuration and security settings.
   Note: When writing the application layer, ATT and GATT layers are often used.

2. How to send data packets

Suppose there is device A and device B. Device A wants to send 83% of its current power status (0x53 in hexadecimal notation) to device B. How should this be done? As a developer, he hopes that the simpler the better. For him, he hopes to call a simple API to complete the task, such as send(0x53). In fact, our BLE protocol stack is designed in this way. Development The user only needs to call send(0x53) to send the data, and the BLE protocol stack will handle the rest for you. So what does BLE handle? There are two main methods introduced here:

broadcast mode

Let's first look at a simple broadcast situation. In this case, we call device A the advertiser (broadcaster), and device B called the scanner or observer (scanner). In the broadcast state, the LL layer API of device A will become send_LL(0x53,2402M, 0x8E89BED6). Since device B can receive broadcasts from many devices at the same time, the data packet must also contain the device address of device A (0xE1022AAB753B) to confirm that the broadcast packet comes from device A. For this purpose, the send_LL parameter needs to become (0x53,2402M, 0x8E89BED6, 0xE1022AAB753B ). The LL layer also checks the integrity of the data, that is, whether the data has been tampered with during transmission. For this reason, CRC24 is introduced to check the data packet (assumed to be 0xB2C78E). At the same time, in order to make the modulation and demodulation circuit work more efficiently, a 1-byte preamble (preamble frame) is added to the front of each data packet. The preamble is generally 0x55 or 0xAA. In this way, the entire air package becomes (Note: the air package is expressed in little-endian mode!)

But! In fact, there is something wrong with the above data packet:

1. No classification and organization of data packets, device B cannot find the data it wants 0x53. For this we need to add two fields after the access address: LL header and length bytes. The LL header is used to indicate the LL type of the data packet, and the length byte is used to indicate the length of the payload.
2. When does device B open the RF window to receive over-the-air packets? As shown in case 1 above, when device A's data packet is transmitted over the air, device B closes the receiving window, and the communication will fail at this time; similarly for case 2, when device A does not send data packets over the air, device B Open the receiving window, and the communication will also fail at this time. Only in case 3 can communication be successful, that is, when device A's data packet is transmitted in the air, device B happens to open the radio frequency receiving window, and communication can be successful at this time. In other words, the LL layer must also define the communication timing.
3. When device B gets the data 0x53, how should it parse this data? Does it mean humidity, electricity, or something else? This is what the GAP layer has to do. The GAP layer introduces the LTV (Length-Type-Value) structure to define data, such as 020105, 02-length, 01-type (mandatory field, indicating broadcast flag, broadcast packets must contain this field ), 05-value. Since the broadcast packet can only be a maximum of 31 bytes, the data types it can define are extremely limited. For example, the power mentioned here is not defined by GAP. Therefore, to send the power data through broadcast, the only way is to use supplier customization. The data type is 0xFF, that is, 04FF590053, where 04 represents the length, FF represents the data type (custom data), 0x0059 is the supplier ID (a mandatory field in custom data), and 0x53 is our data (both parties agree that 0x53 represents the power , rather than any other meaning).

The final data packet transmitted over the air will become:
AAD6BE898E600E3B75AB2A02E102010504FF5900538EC7B2
AA – preamble
D6BE898E – access address
60 – LL header field (LL header)
0E – effective data packet length (payload length)
3B75AB2A02E1 – broadcaster Device address (advertiser address)
02010504FF590053 – Broadcast data
8EC7B2 – CRC24 value

With PHY, LL and GAP, advertising packets can be sent, but the information carried by the broadcast packet is extremely limited, and there are several major limitations:

1. One-to-one two-way communication is not possible (broadcast is one-to-many communication, and it is one-way communication)
2. Large data cannot be transferred as packing and unpacking is not supported
3. Communications are unreliable and inefficient. There cannot be too many broadcast channels, otherwise the efficiency of the scanning end will be low. For this reason, BLE only uses three channels: 37 (2402MHz) / 38 (2426MHz) / 39 (2480MHz) for broadcast and scanning, so broadcast does not support frequency hopping. Since broadcast is one-to-many, broadcast cannot support ACK. These make broadcast communications unreliable.
4. The power consumption of the scanning end is high. Since the scanner does not know when the device broadcasts, nor does it know which channel the device chooses to broadcast, the scanner can only extend the scanning window time and scan the three channels 37/38/39 at the same time, so the power consumption is reduced. will be relatively high.

The connection can solve the above problems very well. Let's take a look at how the connection sends 0x53.

connection mode

What exactly is a connection? Like wired UART, it is easy to understand that it is connected to device A and device B using wires (Rx and Tx, etc.). Using a "line" to connect two devices actually allows the two devices to have a common communication medium and synchronize their clocks. Isn't this true for Bluetooth connections? The so-called establishment of a Bluetooth connection between device A and device B means that device A and device B are successfully "synchronized" one-to-one, which specifically includes the following aspects:

• Device A and Device B agree on the physical channel to use next

• Both device A and device B establish a common time anchor point, that is, change the time origin of both parties to the same point.

• The clocks of device A and device B are synchronized successfully, that is, both parties know when the other party sends and receives data packets.

• After the connection is successful, the communication process between device A and device B is as follows:

As shown in the figure above, once device A and device B are successfully connected (in this case, we call device A Master or Central, and device B is called Slave or Peripheral), device A will periodically use CI (connection interval) Data packets are sent to device B at CI intervals, and device B also periodically opens the radio frequency reception window at CI intervals to receive data packets from device A. At the same time, according to the Bluetooth spec requirements, 150us after device B receives the data packet from device A, device B switches to the sending state and sends its own data to device A; device A switches to the receiving state and receives the data sent by device B. It can be seen that in the connected state, the radio frequency sending and receiving windows of device A and device B are periodically turned on and off in a planned manner, and the on time is very short, thus greatly reducing system power consumption and greatly improving system efficiency.

Now let's take a look at how data 0x53 is sent out in the connected state, from which everyone can appreciate the beauty of the Bluetooth protocol stack layering.

• For the developer, it is very simple, he only needs to call send(0x53)
• The GATT layer defines the type and grouping of data. For convenience, we use 0x0013 to represent the data type of electricity, so that the GATT layer packages the data into 130053 (little endian mode!)
• The ATT layer is used to select specific communication commands, such as read/write/notify/indicate, etc. Here, the notify command 0x1B is selected, so the data packet becomes: 1B130053
• L2CAP is used to specify the connection interval (connection interval), for example, synchronize every 10ms (CI is not reflected in the data packet), and specify the logical channel number 0004 (indicating the ATT command). Finally, add the ATT data length 0x0004 to the header, so that the data It becomes: 040004001B130053
• The LL layer has a lot of work to do. First, the LL layer needs to specify which physical channel to use for transmission (the physical channel is not reflected in the data packet), and then assign an Access address (0x50655DAB) to this connection to identify that this connection is only for device A. Directly connect the service to device B, and then add the LL header and payload length fields. The LL header identifies this packet as a data packet, not a control packet, etc. The payload length is the length of the entire L2CAP field. Finally, add the CRC24 field to ensure that the entire The data integrity of the packet, so the data packet finally becomes:
• AAAB5D65501E08040004001B130053D550F6
• AA – preamble
• 0x50655DAB – access address
• 1E – LL header field (LL header)
• 08 – Payload length
• 04000400 – ATT data length, and L2CAP channel number
• 1B – notify command
• 0x0013 – Power data handle
• 0x53 – The actual power data to be sent
• 0xF650D5 – CRC24 value
  Although the developer only called send(0x53), due to the layer-by-layer packaging of the low-power Bluetooth protocol stack, the final data actually transmitted in the air will become as shown in the figure below, which meets the requirements of low-power The need for Bluetooth communication makes the user API simple.
  
  Reference:
  [1]: https://www.cnblogs.com/iini/p/8969828.html
  [2]: https://www.cnblogs.com/iini/p/8834970.html
  [3]: https: //www.cnblogs.com/iini/p/12334646.html
  [4]: ​​http://adrai.github.io/flowchart.js/