1. Background
Last time, the Bluetooth discussion was quite rushed. This time, I am determined to clarify the fundamental knowledge and applications of Bluetooth.
1.1 Reference Materials
Overview of Bluetooth Version Development http://blog.sina.com.cn/s/blog_d2db96110102xnj6.html
In-depth Understanding of Low Energy Bluetooth (BLE) Protocol Stack https://blog.csdn.net/shunfa888/article/details/80140475
BLE Protocol Series (1) Introduction to Bluetooth https://blog.csdn.net/zwc1725/article/details/80703326
2. Basic Knowledge of Bluetooth
The Bluetooth protocol is also a type of communication protocol, aimed at simplifying complex issues. Any communication protocol has a hierarchical structure, characterized by:
1. Layered from bottom to top, encapsulating at each layer, where each layer only needs to focus on specific, independent functions, making it easy to implement and maintain.
2. Within the communication entity, the lower layer provides services to the upper layer, while the upper layer is the user of the lower layer.
3. Between communication entities, the protocol only applies to each layer. Communication between entities is similar to communication between each layer, which facilitates communication, understanding, and standardization.
The current Bluetooth protocols include three technologies: BR/EDR (Basic Rate/Enhanced Data Rate), AMP (Alternate MAC/PHYs), and LE (Low Energy).
2.1 Current Bluetooth Technology Features – A Look at Bluetooth Protocol Versions
Without delving into the history of Bluetooth, let’s start from version V4.0. Bluetooth version 4.0 includes three sub-specifications: traditional Bluetooth technology, high-speed Bluetooth, and low-energy Bluetooth technology.
Currently, most Bluetooth applicable on mobile devices is V4.0 or higher. Classic V4.0 is an upgrade from traditional Bluetooth 3.0, maintaining downward compatibility. BLE 4.0 is a new branch that does not maintain downward compatibility. Classic Bluetooth modules are generally used for high-volume transmissions: such as voice, music, and other high data volume transmissions. Classic Bluetooth modules can be subdivided into traditional Bluetooth modules and high-speed Bluetooth modules. Low Energy Bluetooth modules refer to modules that support Bluetooth protocol 4.0 or higher, characterized by reduced cost and power consumption, used in products with high real-time requirements.
Bluetooth 4.0 features include low cost, cross-vendor interoperability, 3 ms low latency, ultra-long distance over 100 meters, AES-128 encryption, and improved effective transmission distance.
Bluetooth 4.0 focuses on energy savings, while Bluetooth V4.1 emphasizes IoT (Internet of Things).
Bluetooth V4.1 targets the Internet of Things with software upgrades to V4.0, enhancing connectivity (hardware for V4.0 requires no modifications to use V4.1).
Manifestations include: 1. Under the V4.1 standard, Bluetooth devices can simultaneously act as transmitters (BT Smart, as marked on V4.0) and receivers (BT Smart Ready), and can connect to multiple devices (master-slave integration, e.g., a smart wristband connects as a master to an anti-lost device while also connecting as a slave to a smartphone).
2. Automatic wake-up function under long-term sleep (disconnects when leaving, reconnects upon return); 3. Establishing network connections through IPV6?????—–i.e., Bluetooth chip devices can obtain a unique identifier on the Internet and communicate with other connected devices. Once Bluetooth V4.1 connects to a device that can access the Internet, it can directly use IPV6 to connect to the network, achieving the same functionality as a Wi-Fi module, though compatibility is still being improved. Keep it up, young man.
Bluetooth V4.2 improves data transmission speed and privacy protection, allowing devices to directly connect to the Internet via IPv6 and 6LoWPAN. Speed increases by 2.5 times, and packet capacity is tenfold compared to before. Low energy consumption increases from 260 kbps to 650 kbps, while full power remains at 2.1 Mbps. The new standard supports firmware upgrades.
Both V4.1 and V4.2 have added wireless coexistence testing in specifications to ensure coexistence with 4G.
The current Bluetooth protocols include BR/EDR, AMP, and LE technologies.
2.2 Classification Standards for Bluetooth Modules
1. By supported Bluetooth protocol:
Single-mode Bluetooth modules: modules supporting a specific Bluetooth protocol;
Dual-mode Bluetooth modules: modules supporting both classic Bluetooth (BT) and low-energy Bluetooth (BLE) protocols.
2. By application:
Bluetooth data modules: generally use BLE low-energy Bluetooth modules.
Bluetooth audio modules: audio requires high data throughput, more suitable for using BT classic Bluetooth modules.
Low-energy Bluetooth and traditional Bluetooth are actually quite different. Low-energy Bluetooth developed from Nokia’s Wibree standard. In terms of power consumption, traditional Bluetooth has three levels: class 1, class 2, and class 3, supporting transmission distances of 100m, 10m, and 1m, respectively; low-energy Bluetooth has no power consumption levels, generally with a transmission power of 7 dBm.
3. Low Energy Bluetooth Protocol Stack
3.1 Protocol Stack Architecture
BLE operates in the unlicensed 2.4G ISM RF band, designed from the start as a high-low power wireless technology.
BLE protocol can be divided into two major parts: BLE Application and BLE Core; the Bluetooth core includes BLE Controller and BLE Host.
BLE Core includes the L2CAP layer from Controller to Host and related core profiles.
Bluetooth Application includes various profiles (specifications), such as HOGP, A2DP, HFP, OOP, etc.
The above diagram shows the overall architecture of the BLE protocol stack (application + core). To implement a BLE application, a chip that supports BLE RF is needed, along with a compatible BLE protocol stack, and finally, developing one’s own application on top of the protocol stack. Therefore, the BLE protocol stack is the bridge connecting the chip and the application, and is key to implementing the entire BLE application.
The Bluetooth Core and Bluetooth Application Host Controller in the diagram refer to “logical entities”. The so-called “logical entities” should be distinguished from “physical entities” in daily life. For example, a Bluetooth chip and a main control CPU refer to physical entities. However, the “logical entities” described by the Bluetooth protocol do not necessarily correspond one-to-one with physical entities. In practical applications, the host and Bluetooth Application may reside in the same physical entity (main control CPU), while the Controller is located in a separate physical entity (Bluetooth chip).
The Bluetooth protocol specifies two levels of protocols: the Bluetooth core protocol and the Bluetooth application layer protocol. The Bluetooth core protocol focuses on the description and specification of Bluetooth core technologies, providing basic mechanisms without concerning how to use these mechanisms; the application layer protocol, based on the Bluetooth core protocol, defines various strategies based on specific application needs, such as FTP, file transfer, and local area networks.
The Controller defines specifications related to RF, Baseband, etc., and abstracts the logical link for communication; the Host, based on the logical link, provides a more user-friendly encapsulation, thus masking the technical details of Bluetooth, making it easier for Bluetooth Application to use.
In a system, there is only one Host, but the Controller can be one or more. For example: a separate LE Controller, a separate BR/EDR Controller, or a combined LE+BR/EDR Controller; additional one or more AMP Controllers can be added based on a separate BR/EDR Controller or LE+BR/EDR Controller.
3.2 Analysis of Each Layer in the Communication Entity from Bottom to Top
3.2.1 Physical Layer PHY
In any communication system, the first step is to determine the communication medium (communication channel, Physical Channel).
Physical Layer (PHY) – The PHY layer specifies the wireless frequency band, modulation, and demodulation methods used by BLE.
Specific description: Since BLE is a wireless communication technology, its communication medium is the frequency band resources within a certain frequency range (Frequency Band); BLE’s market positioning is for individuals and civilian use, thus using the free ISM band (frequency range 2.400~2.4835GHz); to support multiple devices simultaneously, the entire band is divided into 40 parts, each with a bandwidth of 2MHz, referred to as RF Channel.——–The physical channel of BLE has frequency points of f=2402+K*2 MHz, k=0~39, with a bandwidth of 2MHz across 40 RF Channels.
In addition to the physical channel, the Physical Layer also needs to define some other characteristics related to RF transceivers:
RF transmission-related characteristics (Transmitter Characteristics), including transmission power (Transmission power), modulation method (Modulation), Gaussian Frequency Shift Keying (GFSK), Spurious Emissions, Radio Frequency Tolerance, etc. (not affecting the subsequent discussions in this article, no need to delve into);
RF reception-related characteristics (Receiver Characteristics), including reception sensitivity, etc.
3.2.2 Link Layer
Main function: Reliable transmission and reception of data on the Physical Channel (i.e., 40 RF Channels). It needs to control RF transmission parameters and resolve the sharing issue of the Physical Channel, while also establishing a dedicated transmission channel (i.e., logical Link) for two communication entities. Additionally, since the Physical Channel is unreliable, the Link Layer must provide mechanisms for verification, retransmission, etc., to ensure the reliability of data transmission.
Problem 1: Sharing issue of the Physical Channel
1. Scenarios with small data volumes, infrequent transmission, and not very sensitive to delays:
—-The Link Layer uses broadcast communication, selecting 3 out of the 40 RF Channels as broadcast channels (advertising channel); all participants share the same logical transmission channel (broadcast channel).
2. Scenarios with large data volumes, high transmission frequency, and sensitive to delays:
—–From the remaining 37 RF Channels of the Link Layer, one channel is selected to establish an independent channel (data channel) for communication between the two parties in this scenario——this is the connection process.
—-Note that to enhance interference resistance against 4G (2.4G frequency band), frequency hopping technology (Hopping) is used. This means randomly yet systematically switching between multiple channels.
Problem 2: How to establish a dedicated logical link—-state and role definition
The BLE protocol abstracts 5 states in the Link Layer:
Standby State, Advertising State, Scanning State, Initiating State, Connection State. A device can only be in one state at any given time.
Note the bidirectional and unidirectional arrows.
Link Layer state machine transition diagram
1. The Standby state is the initial state, meaning no data is sent or received. Based on commands from the upper entity (such as GAP in the Host software), it can transition to any other state except Connection state.
2. The Advertising state allows data to be sent via the broadcast channel and can transition from the Standby state. Data broadcasted by the Advertiser can be received by entities in Scanning or Initiating states. The upper entity can command a transition from Advertising state back to Standby state. Once a connection is successful, it can switch to Connection state.
3. The Scanning state allows data to be received via the broadcast channel and transitions from the Standby state. The upper entity can command a transition from Scanning state back to Standby state.
4. The Initiating state is similar to the Scanning state but is a special receiving state, transitioning from the Standby state, and can only accept connectable data broadcasted by the Advertiser, sending a connection request upon receiving data to establish a connection with the Advertiser. Upon successful connection, both the Initiator and corresponding Advertiser will switch to Connection state.
5. The Connection state indicates a dedicated channel established with a certain entity, transitioning automatically from Initiating or Advertising once the channel is established. After the channel disconnects, it returns to Standby state.
Once the channel is established, the parties in Connection state have two roles: Master and Slave.
The Initiator is referred to as the Master; the Advertiser is referred to as the Slave. Master and Slave roles.
Problem 3: Reliability—Point-to-point communication protocol over the air
1. The data exchange mechanism between states corresponding to other entities in a certain state; 2. Based on commands from the upper entity and current circumstances, responsible for state transitions.———Handled by the Air Interface Protocol.
Two types of Physical Channels (advertising channel and data channel) use a unified packet format.
Preamble (1 octet) Access Address (4 octets) PDU (2~257 octets) CRC (3 octets) octets 8-bit bytes
Data packet format special notes:
Note 1:
Access Address: Used to distinguish whether the packet is a data packet or a broadcast packet.
PDU, the maximum length of BLE in the Link Layer is 257 octets.
The total length of the Link Layer is between 9~264 bytes (1+8 ~257+8)?????
Note 2:
The Link Layer has 5 states, each with different transmission functions, thus defining various PDU types.
A data filtering mechanism for the Link Layer is defined in the form of a whitelist (White List)——-targeting the broadcast channel.
Link Layer Control Protocol is used to manage and control the connection established between two Link Layer entities. Its main functions include:
1. Updating connection-related parameters
2. Updating the frequency spectrum used for the link (i.e., which Physical Channels are used)
3. Executing processes related to link encryption (Encryption).
3.2.3 HCI
Defines the communication protocol between the Host and Controller (usually two ICs, ESP32 can be on one) and can be based on UART, USB, and software emulation.
3.2.4 L2CAP Protocol
3.2.5 ATT Protocol
The original intention of BLE is for the Internet of Things, where the most important and widespread application is information collection. Based on the need for information collection, BLE abstracts a protocol: Attribute protocol. This protocol abstracts information in the form of “Attribute” and provides methods for remote devices to read and modify these attribute values (Attribute Value).
ATT (Attribute Protocol) is the foundation of GATT and GAP, defining the data structure and organization method at the upper layer of the BLE protocol stack.
The concept of attributes is central to the ATT layer, defining the content of attributes and specifying how to access them and the permissions involved.—-Similar to data structures in programming.
Attributes include three types: services, characteristics, and descriptors. There exists a hierarchical containment relationship among them, where services contain one or more characteristics, characteristics contain one or more descriptors, and multiple services are organized together to form an Attribute Profile.
For commonly used attribute profiles, such as weight scales and heart rate monitors, the BLE protocol has specific definitions.
As long as both BLE master and slave devices adhere to a certain Profile for design, they can communicate elegantly.
The GATT Profile uses the ATT protocol to transmit commands, requests, responses, indications, notifications, and confirmation messages between devices. This data is stored in Attribute Protocol PDUs.
Opcode: Operation code—specific operation codes for commands, requests, responses, indications, notifications, confirmations, and flags for authentication.
Attribute Parameter: Data for specific commands or requests, or data for responses, notifications, and indications.
Authentication signature: Optional.
On the server device: Attribute protocol commands and requests are stored as attributes.
Attributes consist of four parts: attribute handle, attribute type, attribute value, and attribute permissions.
2.3.2.4.1 Attribute Data Structure
The attribute data structure includes: handle, type, attribute value, and permissions. The following diagram represents logical attributes.
The attribute handle (Attribute Handle) is an index corresponding to a specific attribute. It is a 2-byte hexadecimal code starting at 0x0001, incrementing during system initialization (but not necessarily by one), and cannot exceed 0xFFFF. It is similar to the concept of a handle in programming, serving as the query address for an attribute value.
The attribute type (Attribute Type) is a UUID used to specify the type of the attribute value, distinguishing whether the current attribute is a service or a characteristic, etc.
The attribute value (Attribute Value): Data (described by Attribute Type, indexed by Attribute Handle).
The attribute permissions (Attribute permissions): Determined by the server, deciding whether a given attribute allows read or write access. Confirmed by GATT.
3.2.6 GATT
~1 Role
GATT has two roles: GATT server and GATT client. The device providing data is called the GATT server, while the device accessing the GATT server to obtain data is called the GATT client.
~2 Profile Architecture
The GATT Profile specifies the data structure for profile data exchange. This structure defines basic elements (such as services and characteristics). All elements are represented using Attributes.
The above diagram shows the architecture of the GATT Profile. A profile consists of one or more services. A service includes multiple characteristics or applications of other services (include). Each characteristic includes values and additional optional information about values. In the server device, services and characteristics and the composition of characteristics (values and descriptors) are stored as Attributes.
~2.1 Characteristic
A characteristic definition must include at least two attributes: one for declaring the characteristic (characteristic declaration) and another for storing the characteristic’s value (characteristic value declaration). Additionally, there may be characteristic descriptors (characteristic descriptor declaration). The three declarations mentioned above are all contained within independent Attributes. The characteristic declaration is immediately followed by the characteristic value declaration. The order of optional characteristic descriptor declarations following the characteristic value declaration is not critical.
Multiple characteristic value declarations can be aggregated into a composite Characteristic.
~2.1.1 Characteristic Declaration
The Characteristic declaration is an attribute.
Its Attribute Type is 0x2803—– UUID for <
Its Attribute Value includes Characteristic Properties, the handle for the Characteristic Value Attribute, and the Characteristic UUID.
Its Attribute Permissions must be readable and not require authentication or authorization.
Note: The Attribute Value of the characteristic declaration cannot be altered once a trust relationship is established between the server and client.
A service may have multiple characteristic declarations with the same Characteristic UUID.
It is necessary to examine the three attribute values of the characteristic declaration in detail.
Characteristic Properties———Determine how the characteristic value is used and how the characteristic descriptor can be accessed. As listed in Table 3.5, if the corresponding bit is set, the description in the table will be allowed. Bitwise OR operation.
~2.1.2 Characteristic Value Declaration
The characteristic value is an attribute that includes the value of the characteristic.
Its Attribute Type: 16-bit Bluetooth UUID or 128-bit Characteristic UUID.
Its Attribute Value: Value of the characteristic.
Attribute Permissions: Determined by the service; if not specified, it is implemented specifically.
~2.1.3 Characteristic Descriptor Declaration
This content is quite extensive.
~2.1 Service
Service definitions include service descriptions (service declaration), and may also include definitions and characteristic definitions.
Service definitions on the server device are arranged in order of Attribute Handle.
Service description is an Attribute.
Attribute Type: Set to 0x2800——《Primary Service》 or 0x2801——《Secondary Service》.
Attribute Value: 16-bit Bluetooth UUID or 128-bit service UUID.——-Referred to as service UUID. The client must support both 16-bit and 128-bit UUIDs. A client may ignore any service definitions with unknown service UUIDs. An unknown service UUID is a service that is not supported.
Attribute Permission: Must be readable and not require authentication or authorization.
When multiple services exist, service definitions with 16-bit Bluetooth UUIDs are grouped together, while those with 128-bit UUIDs are grouped separately.
2.3.2.7 GAP-Generic Access Profile
This Profile ensures that different Bluetooth products can discover each other and establish connections.
GAP defines how Bluetooth devices discover and establish secure/insecure connections with other devices. It addresses general tasks (such as inquiries, naming, and searching) and some security issues (such as guarantees) while also handling connection-related tasks (such as link establishment, channels, and connection establishment).
GAP specifies some general operational tasks. Therefore, it is mandatory and serves as the foundation for all other Bluetooth application specifications.