Introduction to Bluetooth (6): Bluetooth Low Energy Information Interaction


The Bluetooth protocol stack and the Bluetooth chip all use unified data to interact, which is stipulated by SIG (note: some chips have HCI vendor commands). Generally, there are the following types of interactions (note: if there is no special statement, all data)

  • Command: host to controller issues command
  • Event: controller to host reports events
  • ACL: Interaction data based on L2CAP connection. Connectionless asynchronous connection (mainly used for packet data transmission)
  • SCO: Connection-oriented synchronous connection (mainly used for voice transmission)
  • ISO: BLE Audio data (Core 5.2 Vol 4 Part E, Section 5.4), isochronous broadcast/isochronous connection, can be used for one-to-many/many-to-many low-latency communication.


This section describes the three-way UART transport layer (between host and controller). HCI commands, events, and data packets flow through this layer, but this layer does not decode them. For knowledge about UART, please refer to BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4 Part A, UART Transport Layer.

Packet construction is done in two steps. First, it adds a packet header in front of each HCI packet, which describes the payload. Second, it uses the SLIP protocol to frame the packets. Finally, it sends the packet over the UART interface.

The SLIP layer converts the unreliable octet stream into an unreliable packet stream. The SLIP layer places starting and ending octets around the packet. It then changes all occurrences of the frame start or end octet in the packet to escaped versions.

The packet header describes the contents of the packet and is a way to uniquely identify the packet, allowing retransmission of erroneous packets if the packet needs to be transmitted reliably.

Each packet sent over the Three-wire UART (H5) protocol support has a packet header. It also has an optional data integrity check at the end of the payload.

The transport layer does not support packet fragmentation and reassembly. Each transport packet contains at most one higher-layer packet.

A packet consists of a 4-octet header, a payload of 0 to 4095 octets, and an optional 2-octet data integrity check, see Figure 4.1.

The header consists of a 3-bit sequence number, a 3-bit confirmation number, a data integrity check presence bit, a reliable packet bit, a 4-bit packet type, a 12-bit payload length, and an 8-bit header checksum.

  • SEQUENCE NUMBER: For unreliable packets, this field will be set to 0 when sending and will be ignored when receiving.

    Each new reliable packet will be assigned a sequence number equal to the sequence number of the previous reliable packet plus a number that modulo-eights. The packet will use the same sequence number each time it is retransmitted.
  • ACKNOWLEDGE NUMBER: The acknowledgment number must be set to the sequence number of the next reliable packet that the device expects to receive. See<BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part D> Section 6.4.
  • DATA INTEGRITY CHECK PRESENT: This bit should be set to 1 if a 16-bit CCITT-CRC data integrity check is appended to the end of the payload.
  • RELIABLE PACKET: If this bit is set to 1, the packet is reliable. This means that the sequence number field is valid and the receiving end must acknowledge its receipt. If this bit is set to 0, this packet is unreliable.
  • PACKET TYPE: There are five types of HCI data packets that can be sent through the three-wire UART transport layer; HCI data packet encoding does not provide the ability to distinguish the four HCI data packet types, therefore, the Packet Type field is used to distinguish different data packets.

HCI Command packets, HCI ACL Data packets, HCI Event packets, and HCI
ISO Data packets are always sent as reliable packets. HCI Synchronous Flow Control packets are sent as unreliable packets unless HCI Synchronous Flow Control is enabled, in which case they are sent as reliable packets.

In addition to the four HCI packet types, other packet types are defined. One packet type is defined for pure acknowledgment packets, and the other packet type supports link control.

Providers can use a packet type for their own use. All other three-wire UART packet types are reserved for future use.

  • PAYLOAD LENGTH: The payload length is the number of octets in the payload data. This does not include the length of the packet header, or the length of optional data integrity checks.
  • PACKET HEADER CHECKSUM: Packet header check is used to verify that the content of the packet header is not damaged. This is calculated by setting the header checksum to a value such that the 2’s complement sum of the four octets of the header (including the header checksum) is 256 modulo 0xFF.


The link establishment process must be performed before any packets other than link control packets can be sent. This ensures that the serial number is initialized correctly, also ensures that both ends are using the same baud rate, allows peer resets to be detected, and allows the device to be configured.

Link establishment is defined by a state machine with three states: Uninitialized, Initialized and Active.

When the transfer is first started, the link is in an uninitialized state.

Four messages are defined: SYNC, SYNC RESPONSE, CONFIG, and CONFIG RESPONSE.

All four link establishment messages shall be sent with the data integrity present flag set to 0.

UnInitialized STATE

In the uninitialized state, the device sends SYNC messages periodically. If a SYNC message is received, the device shall respond with a SYNC RESPONSE message. If a SYNC RESPONSE message is received, the device will enter the initialization state.

In the uninitialized state, only SYNC and SYNC RESPONSE messages are valid, all other received messages must be discarded. If an invalid packet is received, the device should respond with a SYNC message.

The device should not send any acknowledgment packets in the uninitialized state. In the uninitialized state, the controller may wait until it receives a SYNC message before sending its first SYNC message. This allows the host to control when the controller starts sending data.

Initialized STATE

In the initialization state, the device periodically sends CONFIG messages. If a SYNC message is received, the device shall respond with a SYNC RESPONSE message. If a CONFIG message is received, the device shall respond with a CONFIG RESPONSE message.

If a CONFIG RESPONSE message is received, the device will enter the Active state. All other messages received will be ignored.

Active STATE

In the active state, the device can transmit higher-layer packets through the transport.

  • If a CONFIG message is received, the device shall respond with a CONFIG RESPONSE message.
  • If a CONFIG RESONSE message is received, the device SHOULD discard the message.
  • If a SYNC message is received while active, the peer device is assumed to have reset.

Therefore, the local device should perform a complete reset of the upper stack and initiate link establishment again in an uninitialized state. After entering the Active state, the first packet sent should have its SEQ and ACK numbers set to zero


After the device is active, either side of the transmission link may wish to enter a low-power state. Since you can recover from sync loss, you can stop listening for incoming packets at any time.

To make the system more responsive after a device enters a low-power state, a messaging system is implemented to allow either party to notify the other party that they are entering a low-power state and wake the device from that state. These messages are sent as link control packets. It is optional for the device to support Sleep messages, and Wakeup and Woken messages are mandatory.

  • WAKEUP MESSAGE: A wakeup message should be the first message sent whenever the device thinks the other party is asleep. The device will then send Wakeup messages repeatedly until a Woken message is received.

    There must be at least one character interval between the sending of each wake-up message to allow UART resynchronization. The Wakeup message is an unreliable message, the Packet Type is 15, and the Payload Length is 2. The payload consists of octet pattern 0x05 0xFA. The wake message should be used after the device sends the sleep message.The device must respond to wake messages.
  • WOKEN MESSAGE: A Woken message should be sent whenever a Wakeup message is received, even if the receiver is not currently asleep. After receiving the wake-up message, the device can determine that the other device is not in a low-power state and can send and receive data.

    The Woken message is an unreliable message with packet type 15 and payload length 2. The payload consists of octet pattern 0x06 0xF9
  • SLEEP MESSAGE: After the link is established, sleep messages can be sent at any time. It notifies the other party that this device will enter a low power state and it may also go to sleep. If a device sends/receives a SLEEP MESSAGE, it should use the Wakeup/Woken message sequence before sending any data.

    The Sleep message is an unreliable message with a Packet Type of 15 and a Payload Length of 2. The payload consists of octet pattern 0x07 0x78. Sending this message is optional. The recipient of this message does not need to go to sleep, but the collaborating device may be able to schedule sleep more efficiently with this message.


For most HCI commands, the Controller generates the HCI_Command_Complete event when the command completes. This event contains the return parameters of the completed HCI command.

In order for the Host to detect errors on the HCI transport layer, a timeout is required between the transmission of the Host command and the receipt of the Controller response (such as the HCI_Command_Complete or HCI_Command_Status event). Since the maximum response timeout strongly depends on the HCI transport layer used,Therefore it is recommended to use the default value of 1 second for this timer. This amount of time also depends on the number of outstanding commands in the command queue.

Data and parameter formats

Unless otherwise stated, all values ​​are in binary and hexadecimal little-endian format.

  • Additionally, all parameters that can be negative should use 2’s complement when specifying their values.
  • Unless otherwise noted, the order of parameters in an HCI command package or HCI event package is the order in which the parameters are listed in the command or event.
  • Array parameters are specified using the following notation: ParameterA[i]. If more than one set of array parameters is specified (for example, ParameterA[i], ParameterB[i]), then, unless otherwise specified, the parameter order is as follows: ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[ 1], ParameterA[2], ParameterB[2], … ParameterA[n], ParameterB[n].
  • Unless otherwise noted, all parameter values ​​are sent and received in littleendian format (that is, for multi-octet parameters, the rightmost (least significant octet) is transmitted first).
  • Most unordered command and event parameters and all elements in arranged parameters have a fixed size (an integer number of octets). If a parameter or elements of an array parameter have variable length, this will be noted in the specific command; the length will then be specified in another parameter. Specifies, for each command or event, the parameters and size of each unarrayed argument (or each element in an array argument) contained in the command or event. The number of elements in the array parameter is not fixed.
  • If a command or event has one or more array parameters, specifying a maximum value for the parameter that determines the array size might cause the array to be too large to fit into the HCI command or event packet. When this occurs, the effective maximum value for the parameter will be less than the specified maximum value and may depend on the size or value of other parameters.
  • Where bit strings are specified, the right-hand bit is the low-order bit, for example, 0 is the low-order bit in 0b10.
  • If a parameter value is described as “0xXX” or “N = 0xXX” (with the appropriate number of “X”s), then that description applies to all possible values ​​except any value for which a separate description is given. Where a description specifies a range, values ​​outside that range (if any) are reserved for future use.
  • Parameter values ​​or opcodes that the implementation does not know how to interpret should be ignored, and the operation being attempted should be completed with correct signaling. The Host or Controller should not stop running due to receiving a reserved value.
  • Unless otherwise stated, such as in a “forced scope” declaration or because a value relates to unsupported optional functionality, the controller shall support all valid values ​​for all parameters (values ​​reserved for future use have no effect).

ID and Handle

There are two types of identifiers used in HCI commands and events. Host assignedIDis an identifier used between two peer devices and is included in the PDUSent over the air. There is a separate number space for each different type of ID.

Assigned by the Host in a command or by the Controller in an eventHandleIt is used between Host and Controllerbut not sent over the airidentifier. Some Handles share the same number space, while others have separate number spaces. Three types of handles are used to identify logical channels between hosts and controllers:

  • Connection_Handles
  • Logical Link Handles
  • Physical Link Handles

Exchange of HCI-specific information

The Host-Controller transport layer provides transparent exchange of HCI-specific information.

These transport mechanisms provide the Host with the ability to send HCI commands, ACL data and synchronization data to the BR/EDR Controller, and to send HCI commands and ACL data to the LE Controller or AMP Controller.

These transport mechanisms also provide the host with the ability to receive HCI events, ACL data, and synchronization data from the BR/EDR controller, and HCI events and ACL data from the LE controller or AMP controller.

Because the host controller transport layer provides transparent exchange of HCI-specific information, the HCI specification specifies the format for the exchange of commands, events, and data between the host and controller.

The next section specifies the HCI packet format.

HCI Command packet

HCI command package The HCI command package is used fromHost sends commands to controller (without transmitting via air interface channel). The format of the HCI command package is shown in Figure 5.1, and the definition of each field is explained below. The controller shall be able to accept HCI command packets of up to 255 bytes of data, excluding the HCI command packet header.

The HCI command header is the first 3 octets of the packet. Each command is assigned a 2-byte Opcode, which is used to uniquely identify different types of commands. Opcode parameters are divided into two fields called OpCode Group Field (OGF) and OpCode Command Field (OCF). OGF occupies the upper 6 bits of the opcode, and OCF occupies the remaining 10 bits. Any opcodes not mentioned in this section are reserved for future use.

OGF 0x3F is reserved for vendor-specific debug commands. The organization of the opcode allows additional information to be inferred without fully decoding the entire opcode.NOTE: OGF consisting of all ‘1’s is reserved for vendor specific debug commands.

These commands are vendor specific and used during manufacturing for possible methods of updating firmware and debugging. After receiving a vendor-specific debug command, the Controller should respond:

  1. An HCI_Command_Status event. If the status indicates success (Section 7.7.15), this event shall be followed by an HCI event with an event code field of 0xFF (Section 5.4.4).
  2. An HCI_Command_Complete event specifying the corresponding vendor-specific debug command opcode.

The Host can pretend to send the HCI_Vendor_Specific_Debug command to test HCI command credit.

  • For the Link Control commands, the OGF is defined as 0x01.
  • For the Link Policy commands, the OGF is defined as 0x02. The following OCFs with this OGF were previously used: 0x0005, 0x0006
  • For the HCI Control and Baseband commands, the OGF is defined as 0x03. The following OCF with this OGF was previously used: 0x000B.
  • For Informational Parameters commands, the OGF is defined as 0x04.
  • For the status parameters commands, the OGF is defined as 0x05.
  • For the Testing commands, the OGF is defined as 0x06.

HCI ACL Data packets

HCI ACL packets are used inExchange data between Host and Controller

There are two types of HCI ACL packets:

  • Automatically-Flushable
  • Non-Automatically-Flushable

Automatically-Flushable HCI packets are flushed according to the setting of the automatic flush timer (see Read Automatically Flush Timeout Command BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E 7.3.29). NonAutomatically-Flushable HCI packets are not subject to automatic flush timeout and should not be automatically flushed. The format of the HCI ACL packet is shown in Figure 5.2.

Hosts and Controllers shall be able to accept HCI ACL packets of up to 27 bytes of data, excluding the HCI ACL packet header on Connection_Handles associated with the LE-U logical link. The HCI ACL packet header is the first 4 octets of the packet.

Note: HCI ACL packets with a Connection_Handle associated with a LEU logical link will not be affected by the auto-refresh timer because only non-refreshable packet boundary flags are allowed. All packets on the AMP logical link are subject to the auto-refresh timer.

HCI Synchronous Data packets

HCI synchronization (SCO and eSCO) data packets (used for bidirectional communication of audio data from the protocol stack to the Bluetooth chip)Used between Host and ControllerExchange sync data.

The format of the synchronization packet is shown in Figure 5.3. The HCI SCO packet header is the first 3 octets of the packet.

HCI Event packet

The Controller uses the HCI Event packet to notify the Host when an event occurs.. If the Controller sends an HCI event packet containing an event code or LE subevent code that the Host does not mask and does not support, the Host SHOULD ignore the packet. Any event codes or LE sub-event codes not mentioned in this section are reserved for future use.

The Host shall be able to accept HCI event packets of up to 255 octets of data,Excludes HCI Event packet header. The format of the HCI Event message is shown in Figure 5.4, and the definitions of each field are explained below.

HCI ISO Data packets

HCI ISO packets are used to exchange synchronization data between Host and Controller. HCI ISO packets contain an SDU or a portion of an SDU and cannot contain more data than the buffer size supported by the controller. If the length of the SDU is greater than the controller’s buffer size, the Host may need to fragment the SDU. SDU fragments generated by HCI are independent of SDU fragments generated by ISOAL.

The ISO_Data_Load field should contain Header and isochronous data, and may contain a Time_Stamp field. The format of the ISO_Data_Load field is shown in Figure 5.6.


Related Posts

Hongmeng OS2.0 device development Hi3861-basic function summary

OpenHarmony standard equipment application development (3) – distributed data management

[001] [ESP32 Development Notes] IDF project creation and CMake configuration

My NBIOT learning – BC35-G uses AT commands to connect to Huawei Cloud through CoAP protocol

STM32+ESP8266+MQTT connects to Alibaba Cloud server (3. AT command connects to Alibaba Cloud platform)

LeetCode Greedy Algorithm 1005. Maximized array sum after K times inversion

Robomaster wheel motion calculation

Embedded linux/Hongmeng development board (IMX6ULL) development (19) I2C application programming

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>