Bluetooth Low Energy (BLE)

蓝牙大版本号的发布时间如表 1 所示。

蓝牙系统框架如图 1 所示（摘自 BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 1, Part A）。

从图 1 中可知， 蓝牙的系统结构可以分为 Controller 层和 Host 层， 这两层之间是 HCI（Host Controller Interface）。

低功耗蓝牙（LE）和经典蓝牙（BR/EDR）相差很大，可以认为是两套独立系统，它们之间是不互通的。 这两套系统在图 1 中分别对应两个不同的 Controller，不过，蓝牙系统并不需要都集成这两个 Controller，图 2（摘自 BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 1, Part A）描述的是 Host 和 Controller 常见的搭配组合。

Profile 是蓝牙对应于每一个具体的应用场景的无线接口规范。Bluetooth 的一个很重要特性，就是 Bluetooth 产品无须实现全部的 Bluetooth 规范。蓝牙设备可以选择支持某一些 Profile。 比如用于文件传输的 File Transfer Profile，用于音频输出的 Advenced Audio Distribution Profile，还有一些常用的蓝牙 Profile 可参考：https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles

调制（Modulation）就是对信号源的信息进行处理加到载波上，使其变为适合于信道传输的形式的过程。按调制信号的形式可分为模拟调制和数字调制，BLE 采用了数字调制。常用的数字调制信号主要包括幅度键控（ASK）、频移键控（FSK）、相移键控（PSK）和正交幅度调制（QAM）信号。BLE 采用了频移键控（FSK），也就是通过改变载波的频率，来表征比特信息：如果调制波的频率高于载波频率，则表示比特 1，如果低于，则表示比特 0。

BLE 5.0 中定义两种调制方式：1 Msym/s 调制和 2 Msym/s 调制。

在 1 Msym/s 调制方式支持两种 PHY：
(1) LE 1M PHY，信息数据不编码，传输速率为 1 Mb/s。
(2) LE Coded PHY，信息数据编码方式，传输速率为 125 kb/s 或者 500 kb/s。

在 2 Msym/s 调制方式下支持单一 PHY：
(1) LE 2M PHY，信息数据不编码，传输速率就为 2 Mb/s。

所以，一共有 3 种物理层，如表 3 所示。

BLE 有 40 个物理信道，编号为 0-39。分为两类：

1. 0-36 信道是 General Purpose Channel（Data Channel）。
   
2. 37/38/39 信道是 Primary Advertising Channel，它的主要作用是 Discovering Devices, Initiating a Connection, and Broadcasting Data。
   

注：Primary Advertising Channel（即 BLE 的 37/38/39 信道）的选择特意避开了 Wi-Fi 常用的 1/16/11 通道，如图 4（摘自：https://www.accton.com/Technology-Brief/ble-beacons-and-location-based-services/ ）所示。

两个 BLE 设备建立连接（即处于 Connection 状态，后文会介绍）后，在同一时刻只会使用一个物理信道。BLE 使用 Hopping 算法（参考节 4.1.1）来决定使用哪个信道。

信道总数才 40 个，当空间内有大量的设备时，很可能会出现信道冲突。如何缓解这个问题呢？解决办法是每个链路层的数据包中都有一个“Access Address”字段，“Access Address”是信道的一个标识。每建立一次连接时，会重新生成一次 Access Addres。

链路层的操作可以使用状态机来描述，在链路层抽象出了 7 种状态：

• Standby State
  
• Advertising State
  
• Scanning State
  
• Initiating State
  
• Connection State
  
• Synchronization State（注：这是 Bluetooth 5.1 中新加入的）
  
• Isochronous Broadcasting State（注：这是 Bluetooth 5.2 中新加入的）
  

在状态机中，同一时刻只有一个状态被激活。链路层至少有一个状态机实例，链路层可以有多个状态机实例。

状态机的状态转移如图 6 所示。

下面是前 5 个状态的说明：

1. Standby 状态是初始状态，即不发送数据，也不接收数据。根据上层实体的命令（如位于 Host 软件中 GAP），可由其它任何一种状态进入，也可以切换到除 Connection 状态外的任意一种状态。
   
2. Advertising 状态是可以通过广播通道发送数据的状态，由 Standby 状态进入。它广播的数据可以由处于 Scanning 或者 Initiating 状态的实体接收。上层实体可通过命令将 Advertising 状态切换回 Standby 状态。另外，连接成功后，也可切换为 Connection 状态。
   
3. Scanning 状态是可以通过广播通道接收数据的状态，由 Standby 状态进入。根据 Advertiser 所广播的数据的类型，有些 Scanner 还可以主动向 Advertiser 请求一些额外数据。上层实体可通过命令将 Scanning 状态切换回 Standby 状态。
   
4. Initiating 状态和 Scanning 状态类似，不过是一种特殊的接收状态，由 Standby 状态进入，只能接收 Advertiser 广播的 connectable 的数据，并在接收到数据后，发送连接请求，以便和 Advertiser 建立连接。当连接成功后，Initiater 和对应的 Advertiser 都会切换到 Connection 状态。
   
5. Connection 状态是和某个实体建立了单独通道的状态，在通道建立之后，由 Initiating 或者 Advertising 自动切换而来。通道断开后，会重新回到 Standby 状态。
   

通道建立后（通常说“已连接”），处于 Connection 状态的双方，分别有两种角色 Master 和 Slave。其中， Initiater 方称作 Master，而 Advertiser 方称作 Slave。

参考：http://www.wowotech.net/bluetooth/ble_stack_overview.html

在 3.1 中介绍了 BLE 有 3 种物理层：LE 1M PHY/LE 2M PHY/LE Coded PHY。

BLE 链路层的数据包有两种格式：

1. Packet Format for the LE Uncoded PHYS，这种数据包适应于物理层 LE 1M PHY/LE 2M PHY。
   
2. Packet Format for the LE Coded PHY，这种数据包适应于物理层 LE Coded PHY。
   

L2CAP 有好几种数据包格式，这里只介绍面向连接的 B-frame，如图 11 所示，其中 Channel ID 字段就是图 10 中定义的字段，如 0x0004 表示上层是 ATT 协议，0x0006 表示上层是 SMP 协议。

图 12 中 Pairing_Request/Pairing_Response Packet 格式如 图 13 所示。

第 1 个域 Code 的含义如表 4 所示。

第 2 个域 IO Cap 的含义如表 5 所示。

DisplayYesNo 是表示设备可以显示 Yes 和 No 两个按钮供用户交互。

第 3 个域 OOB DF（即 Out-of-Band Data Flag）的含义如表 6 所示。

MITM 是“Man-In-The-Middle”的缩写，这个域占一个 bit，如果为 1 ，则表示设备请求 MITM 保护。SC 是“Secure Connection”的缩写，这个域占一个 bit，如果为 1，则表示设备请求“Secure Connection pairing”。MITM 和 SC 的值会影响到 Phase 2 中到底选择哪一种 Pairing 方式。

一共有 4 种 Pairing 方式：

1. Just Works（明文传输，没有认证保护）
   
2. Passkey（一个设备显示 6 位数字，要求另一个设备输入；如果两个设备都只有键盘，可能是两个设备都输入）
   
3. Out-of-Band
   
4. Numeric Comparison（两个设备都显示 6 位数字，用户确认它们是否相同，这种方式是在 Bluetooth 4.2 中引入的）
   

有 4 种方式，到底使用哪种方式呢？这是由 Phase 1: Pairing Feature Exchange 传递的 Packet 中的字段来决定的，具体流程如下：
Step 1. 检查 SC 字段是否都为 1；如果都为 1，则进入 Step 2，否则进入 Step 3。
Step 2. 使用图 14 的规则。

图中：

• “Use OOB” means Out-of-Band is selected.
  
• “Check MITM” means ignore “OOB Data Flag” and check MITM flag, “Man-In-The-Middle” flag.
  
• “Use IO Capabilities,” go to step 4 to select the key generation method depending on IO Capabilities of both devices.
  

Step 3. 使用图 15 的规则。

图中：

• “Use OOB” means Out-of-Band is selected.
  
• “Check MITM” means ignore “OOB Data Flag” and check the MITM flag, “Man-In-The-Middle” flag.
  
• “Use IO Capabilities”, go to step 4 to select the key generation method depending on IO Capabilities of both device.
  

Step 4. 使用图 16 的规则。

参考：
https://www.bluetooth.com/blog/bluetooth-pairing-part-1-pairing-feature-exchange/
https://www.bluetooth.com/blog/bluetooth-pairing-part-2-key-generation-methods/
https://www.bluetooth.com/blog/bluetooth-pairing-passkey-entry/
https://www.bluetooth.com/blog/bluetooth-pairing-part-4/

GAP 定义了 4 种 Roles：

1. Broadcaster（广播员）。适应于周期性地往外发布数据，没有连接状态。表示设备正在发送 Advertising Events。
   
2. Observer（观察者）。适应于周期性地从 Broadcaster 获得数据，没有连接状态。表示设备正在接收 Advertising Events。
   
3. Central（中心设备）。智能手机等 CPU 强大的设备往是 Central，Central 可以连接多个 Peripheral，并从 Peripheral 读取数据。对应于 Link Layer 的 Master Role。
   
4. Peripheral（外围设备）。使用 Advertising Packet，允许 Central 找到它，并连接上它。对应于 Link Layer 的 Slave Role。
   

图 17（‘M’ 表示 mandatory to support，‘O’ 表示 optional to support，‘E’ for excluded within profile role）定义了 GAP 4 个 Roles 对物理层和链路层的要求。

GATT 定义了 2 种 Roles：

1. Client. It sends requests to a server and receives responses (and server-initiated updates) from it. The GATT client does not know anything in advance about the server’s attributes, so it must first inquire about the presence and nature of those attributes by performing service discovery. After completing service discovery, it can then start reading and writing attributes found in the server, as well as receiving server-initiated updates.
   
2. Server. It receives requests from a client and sends responses back. It also sends server-initiated updates when configured to do so, and it is the role responsible for storing and making the user data available to the client, organized in attributes.
   

总结：提供数据的设备称为 GATT Server，访问 GATT Server 而获得数据的设备称为 GATT Client。

所有通过 GATT 传输的数据必须映射成一系列的 Characteristics。 一个 Service 包含一个或多个 Characteristics，每个 Characteristic 可以看作是一个键值对，键是为 Characteristic 所指定的 UUID，值是 Characteristic 本身的 Value。 比如，某传感器中，可以定义温度为一个 Characteristic，而湿度为另一个 Characteristic。 一个 Characteristic 可以包含 0 个或多个 Descriptor，每个 Descriptor 都是对该 Characteristic 的 Value 的描述说明，比如 Value 的单位，描述等等。Descriptor 中存储数据的解析由工程师决定，并无规范，双发按照约定进行开发。

有一些 UUID 是预先分配好的，如 0x1805 表示 GATT Service：Current Time，0x2A19 表示 GATT Characteristic：Battery Level。

其它预先分配好的 UUID 可参考：
https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf
https://www.bluetooth.com/specifications/assigned-numbers/

Client/Server 是 GATT 中定义的 Roles；而 Central/Peripheral 是 GAP 中定义的 Roles；它们之前没有必然关系。也就是说 Central 可以是 GATT Server 或 GATT Client；而 Peripheral 也可以是 GATT Server 或 GATT Client；而且一个设备可以同时是 GATT Server 和 GATT Client。 如图 19 所示（改编自：https://embedded.fm/blog/ble-roles ）。

不过，最常见的情况还是 Peripheral 作为 GATT Server，而 Central 作为 GATT Client，如图 20 所示（摘自：https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothOverview/CoreBluetoothOverview.html ）。

在 Bluetooth 4.0 中，对 characteristics 进入写入操作时，最多 20 字节，这个限制的由来参见图 21 。

参考：
https://stackoverflow.com/questions/38913743/maximum-packet-length-for-bluetooth-le
https://punchthrough.com/maximizing-ble-throughput-part-2-use-larger-att-mtu-2/

RSSI (Received Signal Strength Indication) 这个值越小说明信号越差，反之这个值越大表示信号越好。单位为“分贝毫瓦”，记为 dBm。对于 BLE，它往往为负值，例如，大于 -50 dBm 时表明 BLE 设备之间信号很好；小于 -90 dBm 时，表示 BLE 设备信号很差，几乎无法连接上。

下面是 dBm 和信号强弱的大概关系：

-60 dBm ~ 0 dBm        # BLE 信号很好
-70 dBm ~ -60 dBm      # BLE信号一般
-80 dBm ~ -70 dBm      # BLE 信号差
<-80 dBm               # BLE 信号很差

苹果公司提供了工具 PacketLogger，可以方便调试蓝牙，其使用可参考：https://www.bluetooth.com/blog/a-new-way-to-debug-iosbluetooth-applications/