Bluetooth protocol analysis (5)_Technical analysis related to BLE broadcast communication

Aguilera

Bluetooth protocol analysis (5)_Technical analysis related to BLE broadcast communication [Copy link]

1. Introduction

As we all know, the biggest breakthrough of Bluetooth Low Energy (BLE) compared to traditional Bluetooth is the increased support and utilization of advertising. Regarding advertising, we have gained a general understanding through the introduction of the two articles "Playing with BLE (1)_Eddystone beacon" and "Playing with BLE (2)_Using bluepy to scan BLE advertising data". Based on this, this article will analyze and understand the definition and implementation of advertising in the BLE protocol from a technical perspective.

Note 1: Previous articles on Bluetooth protocol analysis (such as "Bluetooth Protocol Analysis (3)_Introduction to Bluetooth Low Energy (BLE) Protocol Stack") tend to introduce the Bluetooth protocol from a horizontal and comprehensive perspective, so that everyone can have an overall understanding. Starting from this article, we will converge on each function point, take the function as the starting point, and walk through the various levels of the Bluetooth protocol from a vertical perspective to deepen the understanding of the Bluetooth protocol and achieve the goal of mastering it.

2. Overview

2.1 Usage scenarios

In the BLE protocol, broadcast communication has two main usage scenarios:

1) Unidirectional, connectionless data communication, where the data sender broadcasts data on the broadcast channel and the data receiver scans and receives the data.

2) Establishment of connection.

Subsequent analysis will focus on these two usage scenarios.

2.2 Protocol Layer

In the BLE protocol, the protocol layer related to broadcast communication is relatively simple, mainly including:

GAP-------->HCI-------->LL

LL (Link Layer) is located at the bottom layer and is responsible for the definition and implementation of broadcast communication related functions, including the selection of physical channels, the definition of related link states, the definition of PDUs, the implementation of device filtering mechanisms, etc.

HCI is responsible for abstracting all functions provided by LL in the form of Command/Event for use by Host.

GAP is responsible for abstracting and encapsulating the functions provided by LL from the perspective of the application, so that the application can perform broadcast communication in a relatively fool-proof way. Of course, this is not necessary, that is, we can perform broadcast communication without the participation of GAP.

3. Link Layer

3.1 State Definition

At a certain moment, a BLE device participating in broadcast communication can be in one of the following three states from the LL perspective:

Advertising, the data sender, periodically sends broadcast data;

Scanning, data receiver, scans and receives broadcast data;

Initiating, the connection initiator, scans for broadcast data with the "connectable" mark, and once found, initiates a connection request (all done automatically by the Link Layer, without the need for Host software participation).

3.2 PDU Definition

Depending on the application scenario, BLE devices in different states can send different types of PDUs (Packet Data Units), as follows.

3.2.1 PDU format

In broadcast communication, the transmitted PDU has the following format:

Header(16bits)

Payload (length is determined by the "Length" field in the Header)

The format of the header is as follows:

PDU Type (4 bits)

RFU(2 bits)

TxAdd(1 bit)

RxAdd(1 bit)

Length(6 bits)

RFU(2 bits)

PDU Type, indicates the type of PDU. For details, please refer to the following introduction.

RFU, reserved for future use.

The meaning of TxAdd and RxAdd is determined by the specific PDU Type.

Length: PDU length, 6 bits, valid range is 6~37 octets.

3.2.2 PDU Type

state	PDU Type	PDU Format	illustrate
Advertising	ADV_IND	AdvA(6 octets) AdvData(0~31 octets)	Connectable undirected advertising event, used for regular broadcasting, can carry no more than 31 bytes of broadcasting data, can be connected and scanned: AdvA, 6-byte broadcaster address, and the address type is determined by the TxAdd bit of the PDU Header (0 public, 1 random); AdvData, broadcasting data.
	ADV_DIRECT_IND	AdvA(6 octets) InitA(6 octets)	Connectable directed advertising event, specifically used for point-to-point connection, and the Bluetooth addresses of both parties are known, cannot carry broadcast data, can be connected by specified devices, and cannot be scanned: AdvA, 6-byte broadcaster address, and the address type is determined by the TxAdd bit of the PDU Header (0 public, 1 random); InitA, 6-byte receiver (also the connection initiator) address, and the address type is determined by the RxAdd bit of the PDU Header (0 public, 1 random).
	ADV_NONCONN_IND	AdvA(6 octets) AdvData(0~31 octets)	Similar to ADV_IND, but cannot be connected or scanned.
	ADV_SCAN_IND	AdvA(6 octets) AdvData(0~31 octets)	Similar to ADV_IND, but cannot be connected and can be scanned.
Scanning	SCAN_REQ	ScanA(6 octets) AdvA(6 octets)	When receiving ADV_IND or ADV_SCAN_IND type broadcast data, the PDU can be used to request the broadcaster to broadcast more information: ScanA, 6-byte local address, and the address type is determined by the TxAdd bit of the PDU Header (0 public, 1 random); AdvA, 6-byte broadcaster address, and the address type is determined by the RxAdd bit of the PDU Header (0 public, 1 random).
	SCAN_RSP	AdvA(6 octets) ScanRspData(0~31 octets)	After receiving the SCAN_REQ request, the broadcaster responds with the PDU and sends more data to the receiver. AdvA, 6-byte broadcaster address, and the address type is determined by the TxAdd bit of the PDU Header (0 public, 1 random); ScanRspData, scan response data.
Initiating	CONNECT_REQ	InitA (6 octets) AdvA (6 octets) LLData (22 octets)	When receiving ADV_IND or ADV_DIRECT_IND type broadcast data, you can use this PDU to request to establish a connection with the other party: InitA, 6-byte local address, and the address type is determined by the TxAdd bit of the PDU Header (0 public, 1 random); AdvA, 6-byte broadcaster address, and the address type is determined by the RxAdd bit of the PDU Header (0 public, 1 random); LLData, BLE connection-related parameter information, please refer to the introduction of subsequent articles for details.

3.2.3 Summary

The PDU types for broadcast communication are summarized as follows:

1) If you only need to transmit some simple data (such as the temperature information of a certain temperature node) at a fixed time, and do not need to establish a connection later, you can use ADV_NONCONN_IND. The broadcaster only needs to broadcast this type of PDU periodically, and the receiver scans and receives according to its own strategy. The two do not need any additional data interaction.

2) If there is some additional data to be transmitted in addition to the broadcast data, for various reasons, such as the length limit of the broadcast data, privacy requirements, etc., ADV_SCAN_IND can be used. The broadcaster will listen for SCAN_REQ requests while broadcasting periodically. After receiving the broadcast data, the receiver can request more data through SCAN_REQ PDU.

3) If a point-to-point connection needs to be established later, ADV_IND can be used. The broadcaster will listen for CONNECT_REQ requests while broadcasting periodically. After receiving the broadcast data, the receiver can request to establish a connection through CONNECT_REQ PDU.

4) It takes a long time to establish a connection through the combination of ADV_IND/CONNECT_REQ. If both parties do not care about the broadcast data and just want to quickly establish a connection, and if the connection initiator knows the Bluetooth address of the other party (broadcaster) (such as by scanning a code), ADV_DIRECT_IND/CONNECT_REQ can be used.

3.3 Advertising Status

3.3.1 Selection of Advertising Channel

We mentioned in "Bluetooth Protocol Analysis (3)_Introduction to Bluetooth Low Energy (BLE) Protocol Stack" that BLE can use 3 of the 40 Physical Channels as physical channels for broadcast communication. Considering various factors (anti-interference, etc.), we finally selected the following three:

RF Channel	RF Center Frequency	Advertising Channel Index
0	2402MHz	37
12	2426MHz	38
39	2480MHz	39

At the same time, the Link Layer allows the Host to select any one or more of the three physical channels for broadcasting. The Link Layer sends the same broadcast data once in each selected Channel.

3.3.2 Definition of Advertising Event

From the previous description, we can know that in the process of BLE broadcasting, various types of PDUs will be sent (or received) on each physical channel used, depending on the usage scenario. Based on this, the BLE protocol proposes the concept of "Advertising Event", namely:

An Advertising Event is a combination of Advertising PDUs sent on all used physical channels.

If you think this is a bit confusing, let us explain it in plain language:

The purpose of a BLE device in the Advertising state is to broadcast data. And, depending on the application scenario, 4 types of data can be broadcast.

In addition, a BLE device can broadcast data on up to 3 physical channels. In other words, the same data (one of the 4 types) needs to be broadcasted on multiple channels in sequence. Therefore, the process of broadcasting on multiple channels in sequence is called an Advertising Event.

At the same time, after some broadcasts (such as connectable and scannable) are sent out, the receiver is allowed to respond to some requests (such as connection requests and scan requests) on the corresponding Channel. And after the broadcaster receives the scan request, it needs to respond on the same Channel. These processes are also calculated in an Advertising Event.

For the above information, please refer to the relevant diagrams in Chapter 4.4.2 of "BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]", which will not be introduced in detail in this article.

3.3.3 Advertising Event Type

Depending on the application scenario (basically corresponding to the four scenarios summarized in Section 3.2.3), the BLE protocol also specifies different types of Advertising Events, including:

Connectable Undirected Event;

Connectable Directed Event (including Low Duty Cycle and High Duty Cycle);

Scannable Undirected Event;

Non-connectable Undirected Event.

Different Advertising Events have different corresponding Advertising parameters (such as period, etc.). Please refer to the following description for details.

3.3.4 Setting the Advertising Cycle

For BLE broadcast communication, the Advertising cycle is a relatively important parameter because it is related to the system power consumption and communication efficiency. Therefore, it needs to be carefully set according to the usage scenario.

For other Advertising Events except High Duty Cycle Connectable Directed Event, the Advertising cycle is mainly determined by the two parameters advInterval and advDelay, as shown in the following figure:

Image 1 Advertising cycle

Among them, advInterval is a parameter that can be set by the Host: for Scannable Undirected and Non-connectable Undirected Advertising Events, this value cannot be less than 100ms (from the perspective of power consumption, it also determines the rate of broadcast data); for Connectable Undirected and Low Duty Cycle Connectable Directed Advertising Events, this value cannot be less than 20ms (to establish a connection quickly).

advDelay is a pseudo-random number between 0 and 10 ms.

High Duty Cycle Connectable Directed Event is a more aggressive one. Its Advertising cycle is not controlled by the above parameters and can be as short as 3.75ms. However, the BLE protocol also stipulates that the Link Layer must exit this aggressive state within 1.28s. It is truly a sprint champion!

Note 2: We can infer from the above time information that the BLE protocol has very clear expectations for broadcast communication - it does not care about the rate, but only cares about power consumption. The maximum rate of general broadcast communication (not for the purpose of connection) is 31byte / 100ms = 2.48kbps. If the scannable data is included, it is double, 4.96kbps.

Note 3: For the connection, if the device address of the connection initiator is not known in advance, the fastest connection speed may be 20ms. If the address is known in advance, using High Duty Cycle Connectable Directed Event, the connection may be established within 3.75ms. It can be seen that the connection establishment time of BLE is much shorter than that of traditional Bluetooth, which is why BLE devices do not need to maintain connection.

3.4 Scanning Status

3.4.1 scanWindow and scanInterval

Scanning state is the state of scanning and receiving broadcast data. The scanning behavior of this state is determined by two parameters: scanWindow and scanInterval. ScanWindow indicates the time of a scan (which can be understood as the time when RF RX is turned on), and scanInterval indicates the interval between two scans. If the values of these two parameters are the same, it means continuous scanning.

The BLE protocol stipulates that the maximum scanWindow and scanInterval cannot exceed 10.24s, and scanWindow cannot be greater than scanInterval.

3.4.2 Passive Scanning and Active Scanning

Passive Scanning is called Passive because in this scanning mode, the BLE device only listens but does not ask. That is, it only receives PDUs of types such as ADV_DIRECT_IND, ADV_IND, ADV_SCAN_IND, and ADV_NONCONN_IND, and does not send SCAN_REQ.

Active Scanning means not only listening carefully, but also asking questions (SCAN_REQ) and receiving subsequent SCAN_RSP.

The final result of these two types of scanning is to feed back the received data (including Advertiser address, Advertiser data, etc.) to the Host.

3.5 Initiating state

The Initiating state is similar to the Scanning state, except that it focuses on different things: it does not care about broadcast data, but only about two types of messages, ADV_DIRECT_IND and ADV_IND. When conditions are met, it sends a CONNECT_REQ request to establish a connection.

3.6 Device Filtering Mechanism

From the previous description, we can see that the BLE broadcast function is quite good except for the low speed. But there is a problem that needs our attention:

If there are many BLE devices broadcasting around, the Scanner's Controller will scan a lot of broadcast data. If all this data is reported to the Host (or even the user), the Host (or user) will probably go crazy. In other words, there are too many junk messages, and I only want to see and hear what I am interested in? What should I do?

It doesn’t matter, there is a way. A device filtering mechanism based on the white list mechanism is now available.

3.6.1 White List

Each BLE controller can save a device list, through which the device filtering function can be implemented. This list is called a white list, which saves some BLE device addresses.

The size of the whitelist is determined by the Controller and is empty when reset. It can be configured by the Host through the HCI interface later. Based on the whitelist, the Link Layer can implement a variety of device filtering strategies, including:

Advertising Filter Policy;

Scanner Filter Policy;

Initiator Filter Policy.

Please refer to the following description for details.

3.6.2 Advertising Filter Policy

Advertising Filter Policy defines how the Link Layer of the Advertiser (in Advertising state) handles SCAN_REQ (scan request) and CONNECT_REQ (connection request), including the following policies (the Host can configure it according to the actual situation, and only one can be configured at a time):

Link Layer only accepts scan and connection requests from devices in the whitelist (most stringent);

Link Layer can accept scan and connection requests from any device (least strict, default state after Controller reset);

Link Layer can accept scan requests from any device, but only accepts connection requests from devices in the whitelist;

Link Layer can accept connection requests from any device, but only accepts scan requests from devices in the whitelist.

3.6.3 Scanner Filter Policy

Scanner Filter Policy determines how a Scanner (in Scanning state) Link Layer handles broadcast data, including the following policies:

The Link Layer only processes the broadcast data of the devices in the whitelist and ignores the connectable directed advertising packets that do not include their own addresses;

The Link Layer processes the advertising data of all devices and ignores the connectable directed advertising packets that do not include their own addresses (the default state after the Controller is reset).

In addition, if the device supports the "Extended Scanner Filter" policy, it can also support the following policies:

The Link Layer only processes the broadcast data of the devices in the whitelist and cannot ignore the connectable directed advertising packet whose InitA address is "resolvable private address";

The Link Layer processes the advertising data of all devices and cannot ignore the connectable directed advertising packet whose InitA address is "resolvable private address".

Note 4: We will introduce resolvable private address in other articles.

3.6.4 Initiator Filter Policy

The Initiator Filter Policy determines how the Link Layer of an Initiator (in the Initiating state) handles connectable broadcast data, including the following policies:

The Link Layer only processes connectable broadcast packets sent by devices in the whitelist and initiates a connection request when it is received.

Ignoring the whitelist, the Link Layer processes connectable broadcast packets sent by the device specified by the Host and initiates a connection request when received.

4. HCI

After introducing the broadcast communication related functions in the Link Layer, the HCI layer is simple because it only encapsulates the functions provided by the Link Layer into specific commands and events without any logic.

Before we begin, let's recall the hcitool example given in "Playing with BLE (1)_Eddystone beacon":

# enable BLE advertising
hcitool -i hci0 cmd 0x08 0x000A 01

# set advertising data to Eddystone UUID
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00

Finally we can reveal their true colors!

4.1 HCI Command/Event Format

First, let's briefly introduce the format of HCI Command and Event (for details, please refer to "BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E]" Chapter 5.4).

The format of HCI Command is as follows:

OCF(10bit) +OGF(6bit)

Parameter Total Length

Parameter1

Parameter2

…

OCF and OGF together form a 16-bit operation code (OpCode);

OGF is the abbreviation of OpCode Group Field, which is 6 bits long and indicates the group to which the HCI command belongs, corresponding to 0x08 in the above HCI command.

OCF is the abbreviation of OpCode Command Field, a code-specific HCI command, corresponding to 0x000A/0x0008 in the above HCI command;

Parameter Total Length, indicating the length of all parameters of the Command;

Parameter1, Parameter2, etc., 16 bits of parameters, determined by the specific Command.

Note 5: For the command format described here, we only need to pay attention to OGF, OCF and Parameter, because we will mainly use the "hcitool cmd" command for demonstration later, and hcitool has already encapsulated it for us.

The format of HCI Event is as follows:

Event code (8 bits)

Parameter Total Length

Parameter1

Parameter2

…

The specific meaning will not be described in detail.

4.2 Introduction to HCI Commands Related to Broadcast Communication

This section briefly introduces HCI Command related to broadcast communication. For more detailed information, refer to Section 7.8 of "BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E]".

Note 6: The OGF of all BLE-related HCI Commands is 0x08.

4.2.1 Advertising status related commands

1) HCI_LE_Set_Advertising_Parameters

Set the broadcast parameters, including Advertising Interval, Advertising Type, the local address type, the peer device address type and address, the physical channel map used, Advertising Filter Policy, etc.

2) HCI_LE_Set_Advertising_Data

Set the broadcast data, OCF is 0x0008, and the format of the Command parameter is as follows:

Advertising Data Length (8 bits), Advertising Data

Taking the above example, hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00

Different colors represent OGF, OCF, Advertising Data Length, and Advertising Data respectively.

3) HCI_LE_Set_Scan_Response_Data

Set the response data for Scan request. OCF is 0x0009. The format is exactly the same as HCI_LE_Set_Advertising_Data.

4) HCI_LE_Set_Advertise_Enable

Controls whether Advertising is enabled or not. The ICF is 0x000a. The command parameter includes an 8-bit "Advertising Enable" as follows:

hcitool -i hci0 cmd 0x08 0x000A 01

4.2.2 Scanning status related commands

1) HCI_LE_Set_Scan_Parameters

Set scan parameters, including Scan Type, Scan Interval, Scan Window, local address type, Scanning Filter Policy, etc.

2) HCI_LE_Set_Scan_Enable

The switch of the Scan action has the same data format as HCI_LE_Set_Advertise_Enable.

4.2.3 Initiating state related commands

1) HCI_LE_Create_Connection

To establish a connection, you can specify Initiating-related parameters such as Sca Interval, Scan Window, Initiator Filter Policy, Peer Address Type, Peer Address, Own Address Type, etc. You can also specify connection-related parameters (not explained here).

2) HCI_LE_Create_Connection_Cancel

Cancel the connection.

4.2.4 White List Related Commands

include:

HCI_LE_Read_White_List_Size, get the whitelist size of BLE Controller;

HCI_LE_Clear_White_List, clear the white list;

HCI_LE_Add_Device_To_White_List, add the device to the whitelist;

HCI_LE_Remove_Device_From_White_List, remove the device from the whitelist;

5. GAP

For broadcast communications, GAP mainly accomplishes two things:

1) Convert the "protocol language" of Link Layer, such as Advertising, Scannin, Initiating, etc., into a more intuitive "human language" (of course, some encapsulation is required).

2) Define some unified and standardized formats for broadcast data and scan response data to achieve the purpose of interconnection and interoperability.

The following will introduce these two things separately.

5.1 GAP Mode Definition

When introducing Link Layer above, I believe you may be a little confused by the terms, but fortunately, after returning to the Host, the familiar Bluetooth terms are back. GAP maps the various states of Link Layer from the perspective of user functions and abstracts the following four modes (only two are related to broadcast communication, which we will focus on):

1)Broadcast mode and observation procedure

Broadcast mode and the corresponding parsing process. A device in broadcast mode can send two types of advertising events: non-connectable undirected or scannable undirected. Of course, devices with corresponding parsing capabilities can receive these two types of events.

At the same time, GAP defines two roles (GAP role) for devices in this mode: Broadcaster and Observer. Broadcaster must have the "Broadcast mode" capability, and Observer must have the "observation procedure" capability.

Note 7: You may find these terms confusing. To understand them, you need to grasp one point: GAP is a profile. The primary purpose of a profile is interoperability, so it is best at defining roles (roles, broadcasters and observers) and capabilities (broadcast mode and observation procedures). Any device that supports GAP must declare which roles it supports, and the profile must specify which roles must have which capabilities. The understanding of other modes later also follows this principle.

2) Discovery modes and procedures

The discovery mode and the corresponding discovery process are used to discover devices (consistent with traditional Bluetooth).

GAP defines two roles for devices in this mode: Peripheral and Central. Peripheral is a device that is discovered, and Central is a device that actively discovers others. At the same time, GAP defines 6 capabilities related to discovery (devices with different roles can choose which capabilities they have according to the provisions of the protocol):

Non-Discoverable mode: the device cannot be discovered and will not broadcast any data.

Limited Discoverable mode, discoverable (limited), the device can send three types of advertising events: non-connectable, scannable undirected, or connectable undirected. "Limited" means that the device will only broadcast data within a limited period of time;

General Discoverable mode, which is similar to the above mode, but can broadcast for a long time;

Limited Discovery procedure, which can perform limited discovery operations and discover devices in "Limited Discoverable mode";

General Discovery procedure, which can perform general discovery operations and discover devices in "Limited Discoverable mode" and "General Discoverable mode";

Name Discovery procedure can be used to perform Name discovery operations. If the name of the broadcasting device is not obtained through Scanning operations (including Passive and Active), this procedure can be used to obtain the name of the other party after the connection is established.

3) Connection modes and procedures

Connection mode, with corresponding connection process, is used to connect devices (consistent with traditional Bluetooth).

Devices in all four roles, Peripheral, Central, Broadcaster, and Observer, may be involved in connection-related modes. For details, please refer to the relevant definitions in the Bluetooth spec.

Connection-related modes include:

Non-connectable mode: In non-connectable mode, the device can send two types of advertising events: non-connectable undirected or scannable undirected;

Directed connectable mode: can be connected by a specified device, and the device only sends Connectable Directed advertising events;

Undirected connectable mode, can be connected (no device is specified), the device only sends Connectable undirected advertising events;

Auto connection establishment procedure can automatically connect devices in directed connectable mode or undirected connectable mode. Automatic means that the Controller is automatic, and the Host only needs to issue commands;

General connection establishment procedure, general connection process, Host needs to participate.

Selective connection establishment procedure, when establishing a connection, the host can specify some connection parameters, which will be analyzed in detail in subsequent articles;

Direct connection establishment procedure, combined with device filtering mechanism, connects only specific devices;

Connection parameter update procedure, update of connection parameters, to be analyzed later;

Terminate connection procedure, the process of disconnecting the connection.

5.2 Broadcast Data Format

For the purpose of interoperability, the BLE protocol defines a detailed format for 31 bytes of broadcast data and scan response data, as follows:

Figure 2: Format of advertising data and scan response data

First, the broadcast data (or scan response data) consists of one AD Structure. For other data less than 31 bytes, it is filled with 0.

Each AD Structure consists of two parts: 1 byte of length information (the length of the data), and the remaining data information;

The data information consists of two parts: AD Type (variable length) indicating the type of the AD Structure, and the specific AD Data.

If it were just these, it would not show the strength of the Bluetooth organization. The most critical thing is AD Type. The BLE protocol defines various AD types and corresponding data formats according to actual application scenarios, such as

Service UUID, indicating which profiles this device supports;

Local Name, indicating the name of this device;

Flags, indicating the device's ability to support Limited Discoverable Mode/General Discoverable Mode, as well as BLE, BR/EDR support;

etc;

Note 8: For the definition of AD Type, please refer to "https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile".

Note 9: For the definition of AD Data format, please refer to the "CSS (Core Specification Supplement) " document.

Finally, let’s deepen our understanding by combining the above hcitool cmd example:

02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00

02 01 06 is an AD Structure: Data length is 02; Data is 01 06; AD Type is 01 (Flags); AD Data is 06, indicating that General Discoverable Mode is supported and BR/EDR is not supported.

03 03 aa fe is an AD Structure: the length of Data is 03; Data is 03 aa fe; AD Type is 03 (16 bits Service UUID); AD Data is aa fe, which is the Service UUID of the Eddystone profile.

17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00, which is an AD Structure: the length of Data is 17 (23 bytes); Data is 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00; AD Type is 16 (Service Data); AD Data is aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00, which is the specific Service of Eddystone profile Data (please refer to the relevant introduction in "https://github.com/google/eddystone/blob/master/protocol-specification.md").

6. Conclusion

I have written down so much, I am afraid it may not be easy for you to understand. Just treat it as your study notes. If you encounter related problems in the future, you should be able to check this article.