In-depth understanding of the Bluetooth Low Energy (BLE) protocol stack

Why is the BLE protocol stack layered? How to understand Bluetooth "connection"? What happens if the bluetooth protocol has only ATT and no GATT?

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 premise of implementing the BLE protocol stack. Before diving into the various components of the BLE protocol stack, let's take a look at the overall architecture of the BLE protocol stack.

As shown in the figure above, to implement a BLE application, you first need a chip that supports BLE radio frequency, and then you need to provide a BLE protocol stack supporting this chip, and finally develop your own application on the protocol stack. It can be seen that the BLE protocol stack is a bridge connecting chips and applications, and is the key to realizing the entire BLE application. What functions does the BLE protocol stack contain? In short, 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, that is, to wrap the application data in a series of headers and frames. in the tail. Specifically, the BLE protocol stack is mainly composed of the following parts:

PHY layer (Physical layer physical layer). The PHY layer is used to specify the wireless frequency band, modulation and demodulation methods and methods used by BLE. Whether the PHY layer is done well or not directly determines the RF indicators such as power consumption, sensitivity, and selectivity of the entire BLE chip.
LL layer (Link Layer link layer). The LL layer is the core of the entire BLE protocol stack, as well as the difficulty and focus of the BLE protocol stack. The BLE protocol stack like Nordic can support 20 links (connections) at the same time, which is the credit of the LL layer. The LL layer has a lot of things to do, such as which radio frequency channel to choose for communication, how to identify air data packets, when to send the data packets out, how to ensure data integrity, how to receive ACK, and how to retransmit , and how to manage and control the link, etc. The LL layer is only responsible for sending or withdrawing the data, and how to parse the data is handed over to the above GAP or ATT.
HCI (Host controller interface). HCI is optional (for details, please refer to the article: Three Bluetooth Architecture Implementation Schemes (Bluetooth Protocol Stack Schemes)), HCI is mainly used in the case where two chips implement the BLE protocol stack, and is used to standardize the communication protocol and communication commands, etc.
GAP layer (Generic access profile). GAP is one of two ways of how the LL layer payload (valid data packet) is parsed, and it is the simplest one. GAP simply specifies and defines some LL payloads, so the functions that GAP can achieve are extremely limited. GAP is currently mainly used for broadcasting, scanning and initiating connections.
L2CAP layer (Logic link control and adaptation protocol). L2CAP performs a simple encapsulation on LL. LL only cares about the transmitted data itself. L2CAP needs to distinguish whether it is an encrypted channel or a normal channel, and also manage the connection interval.
SMP (Secure manager protocol). SMP is used to manage the encryption and security of the BLE connection, and how to ensure the security of the connection without affecting the user's experience, these are the work that SMP needs to consider.
ATT (Attribute protocol). In simple terms, the ATT layer is used to define user commands and data for command operations, such as reading a certain data or writing a certain data. In the BLE protocol stack, the developer has the most contact with ATT. BLE introduces the concept of attribute to describe one piece of data. In addition to defining data, Attribute also defines the ATT commands that the data can use, so this layer is called the ATT layer.
GATT (Generic attribute profile). GATT is used to standardize the data content in attributes, and uses the concept of group (grouping) to classify and manage attributes. Without GATT, the BLE protocol stack can also run, but there will be problems with interconnection. It is precisely because of GATT and various application profiles that BLE gets rid of the compatibility dilemma of wireless protocols such as ZigBee and becomes a shipment. The largest 2.4G wireless communication product.

I believe that many people have read the above introduction, but still do not understand the working principle of the BLE protocol stack, as well as what each layer does, and why it is so layered. Next, I will take how to send a data packet as an example to explain how the layers of the BLE protocol stack work closely together to complete the sending task.

How to send a packet over the air

Assuming that there are device A and device B, device A wants to send 83% of its current power status (0x53 in hexadecimal) to device B. What should I do? As a developer, he hopes the simpler the better. For him, he hopes to call a simple API to accomplish this, such as send(0x53). In fact, our BLE protocol stack is designed in this way. The user only needs to call send(0x53) to send the data, and the BLE protocol stack will do the rest for you. Many people will wonder whether the BLE protocol stack sends 0x53 directly at the physical layer, as shown in the following figure:

This method looks beautiful at first glance, but because many details are not considered, it is not practical. First of all, it does not consider which radio frequency channel is used for transmission. Without changing the API, we can only layer the protocol stack. To this end, the LL layer is introduced. The developer still calls send(0x53), send(0x53 ) and then call send_LL(0x53, 2402M) (Note: 2402M is the channel frequency). There is another question here. How does device B know whether the data packet is sent to itself or to others. For this reason, BLE introduces the concept of access address to indicate the identity of the receiver. Among them, the access address of 0x8E89BED6 is special, which means that it needs to Send it to all surrounding devices, that is, broadcast. If you want to communicate one-to-one (the BLE protocol calls it a connection ), that is, the data packets of device A can only be received by device B, and the data packets of device B can only be received by device A, then you must generate a unique A random access address to identify the connection between device A and device B.

broadcast method

Let's first look at a simple broadcast situation. In this case, we call device A an advertiser (broadcaster) and device B as a 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 is from device A. For this reason, 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 the transmission process. 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) will be added to the front of each data packet, and the preamble is generally 0x55 or 0xAA. In this way, the entire air packet becomes (Note: the air packet is represented in little endian mode! ):

The above packet also has the following problems:

Without classifying and organizing the data packets, device B cannot find the data 0x53 it wants. To do this we need to add two fields after the access address: the LL header and the length byte. 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
When does device B open the RF window to receive air packets? As shown in case 1 of the above figure, when the data packet of device A is transmitted in the air, device B closes the receiving window, and the communication will fail at this time; also for case 2, when device A does not send data packets in the air, device B Open the receive window, and the communication will also fail at this time. Only in the case of case 3, the communication can be successful, that is, when the data packet of device A is transmitted in the air, the device B just opens the radio frequency receiving window, and the communication can be successful at this time. In other words, the LL layer must also define the communication timing .
When device B gets the data 0x53, how to parse this data? Does it mean humidity, electricity, or something else? This is what the GAP layer does. 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 packet must contain this field ), 05-value. Since the broadcast packet can only be up to 31 bytes, the data type it can define is extremely limited. Like the power mentioned here, GAP is not defined. Therefore, to send the power data through broadcast, you can only use the supplier to customize 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 (mandatory field in the custom data), and 0x53 is our data (the two parties agreed that 0x53 represents the power , not otherwise).

The final over-the-air packet will become:

AAD6BE898E600E3B75AB2A02E102010504FF5900538EC7B2
- AA - preamble frame
- D6BE898E – access address
- 60 – LL header field (LL header)
- 0E – payload length
- 3B75AB2A02E1 – advertiser address
- 02010504FF5900 53 – Broadcast data
- 8EC7B2 – CRC24 value

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

One-to-one communication is not possible (broadcasting is one-to-many and one-way communication)
Unable to transfer large data as grouping and unpacking are not supported
Communication is unreliable. There should not be too many broadcast channels, otherwise it will lead to inefficiency of the scanning side. For this reason, BLE only uses 37(2402MHz) /38(2426MHz) /39(2480MHz) three channels for broadcasting and scanning, so broadcasting does not support frequency hopping. Since broadcast is one-to-many, broadcast also cannot support ACK. These all make broadcast communication unreliable.
The power consumption of the scanning end is high. Since the scanning end does not know when the device end broadcasts, nor which channel the device end chooses to broadcast, the scanning end can only lengthen the scanning window time, and scan the three channels 37/38/39 at the same time, so that the power consumption is reduced. will be higher.

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

Connection method

What exactly is a connection? Like wired UART, it is easy to understand, that is, connecting device A and device B with lines (Rx and Tx, etc.), that is, connection. Connecting two devices with a "line" actually allows the two devices to have a common communication medium and synchronize their clocks. What is the truth of Bluetooth connection ? The so-called Bluetooth connection between device A and device B means that device A and device B are "synchronized" successfully , which specifically includes the following aspects:

Device A and Device B agree on which physical channel to use next
Device A and Device B establish a time anchor, that is, change the time origin of both parties to the same point
The clocks of device A and device B are successfully synchronized, 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 as Slave or Peripheral ), device A will periodically use CI (connection interval) Send data packets to device B for intervals, and device B also periodically opens a radio frequency receiving window at CI intervals to receive data packets from device A. At the same time, according to the requirements of the Bluetooth spec, after device B receives the data packet of device A for 150us , 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 RF transmit and receive windows of device A and device B are periodically opened and closed in a planned manner, and the opening time is very short, thereby greatly reducing system power consumption and greatly improving system efficiency.

Now let's see how the data 0x53 is sent out in the connected state, from which you can appreciate the beauty of the layering of the Bluetooth protocol stack.

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 packs 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 that the data packet becomes: 1B130053
L2CAP is used to specify the connection interval (connection interval), such as synchronization every 10ms (CI is not reflected in the data packet), at the same time specify the logical channel number 0004 (representing the ATT command), and finally add the ATT data length 0x0004 to the packet 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 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, and finally the CRC24 field is added to ensure the entire The data integrity of the packet, so the packet finally becomes:
- AAAB5D65501E08040004001B130053D550F6
  - AA - preamble frame
  - 0x50655DAB – access address
  - 1E – LL header field (LL header)
  - 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 calls send(0x53), due to the layer-by-layer packaging of the low-power Bluetooth protocol stack, the actual data transmitted in the air will become as shown in the figure below, which not only satisfies the requirements of low-power Bluetooth communication demand, and make the user API simple, it can be said to kill two birds with one stone!

The above is just a brief overview of the implementation principle of the BLE protocol stack. Even so, because it is all about the bottom layer of the BLE protocol stack, many developers still find it boring and obscure, and for many developers, they do not. Concerned about how the BLE protocol stack is implemented, they are more concerned with the use of the BLE protocol stack, that is, how to develop a BLE application. The BLE application is a real thing. It cannot be discussed in general terms like the protocol stack described above. It must be explained in conjunction with the specific Bluetooth chip and Bluetooth protocol stack. For this reason, the Nordic chip and protocol stack will be used as an example to explain how to develop BLE. application, and how to understand some concepts and terms defined in the BLE protocol through code.