ESP32学习笔记_Bluetooth(2)——Bluetooth Stack、GAP

摘要：这篇博文介绍了 ESP32 蓝牙协议栈的相关内容，主要包括 ESP-IDF 支持的两种蓝牙协议栈（Bluedroid 和 Apache NimBLE），它们各自的特点和适用场景；以及蓝牙系统的整体结构，分为控制器和主机两部分，以及它们的功能模块；最后描述了通用访问配置文件（GAP）的目的、配置文件角色、可发现模式和程序、连接模式和程序、安全模式和程序，以及设备连接建立过程

---

参考资料：《Bluetooth Core Specification v 5.0》

《Supplement to the Bluetooth Core Specification》

《Assigned Numbers》

ESP32蓝牙教程 Michael_ee

《蓝牙 API - ESP32 - — ESP-IDF 编程指南 latest 文档》

---

---

Bluetooth Stack

ESP-IDF 目前支持两个主机堆栈（蓝牙协议栈），基于 Bluedroid 的堆栈（默认）支持传统蓝牙和低功耗蓝牙 (Bluetooth® LE)，而基于 Apache NimBLE 的堆栈仅支持低功耗蓝牙

• 对于同时涉及传统蓝牙和低功耗蓝牙的用例，应该选用 Bluedroid
• 对于仅涉及低功耗蓝牙的用例，建议选用 NimBLE，在代码占用和运行时，NimBLE 对内存的要求较低，因此适用于此类场景

Bluedroid 是 Android 平台和 ESP32 上常用的蓝牙协议栈。它提供了完整的蓝牙主机和控制器功能，支持蓝牙经典（BR/EDR）和蓝牙低功耗（BLE）；Bluedroid 已被广泛应用于 Android 设备和 ESP32 系统，能够通过提供标准的 HCI 接口与硬件控制器通信；Bluedroid 是一个稳定的协议栈，但由于它具有较大的代码库和相对较高的资源需求，可能不适合资源有限的嵌入式设备

Apache MyNewt NimBLE 是一个轻量级、灵活、高度可配置且符合 Bluetooth® SIG 认证的蓝牙低功耗 (Bluetooth LE) 协议栈，提供主机和控制器功能，专注于低功耗蓝牙设备的高效能实现，与 Bluedroid 不同，NimBLE 更加简化，旨在提供更好的性能和更少的内存占用，适用于嵌入式应用和低功耗设备

ESP-IDF 支持专为 ESP32 平台和 FreeRTOS 移植的 NimBLE 主机栈，底层控制器与 Bluedroid 中使用的相同，提供 VHCI 接口

ESP-IDF 支持大多数 NimBLE 特性，包括蓝牙低功耗网状网络 (Bluetooth Low Energy Mesh)，通过保留 NimBLE 所有现有 API 并提供一个统一的 ESP-NimBLE API 用于初始化，移植层变得更简洁，从而简化了应用开发者的工作

图源：NimBLE-based Host APIs - ESP32 - — ESP-IDF 编程指南 latest 文档
BLE User Guide — Apache Mynewt latest documentation

‍

从整体结构上，蓝牙可分为控制器 (Controller) 和主机 (Host) 两大部分：

• 控制器包括了以下模块：PHY、Baseband、Link Controller、Link Manager、Device Manager、HCI 等，这些模块用于硬件接口管理、链路管理等功能
• 主机则包括了以下模块：L2CAP、SMP、SDP、ATT、GATT、GAP，这些模块构建了向应用层提供接口的基础，方便应用层对蓝牙系统的访问

主机可以与控制器运行在同一个宿主上，也可以分布在不同的宿主上
​

​

图源：esp32_bluetooth_architecture_cn
通过软硬件分层的设计，底层不变，可以方便的切换上层程序（应用层软件）

场景一（ESP-IDF 默认）
在 ESP32 的系统上，选择 Bluedroid 为蓝牙主机，并通过 VHCI（软件实现的虚拟 HCI 接口）接口，访问控制器。此场景下，Bluedroid 和控制器都运行在同一宿主上（即 ESP32 芯片），不需要额外连接运行蓝牙主机的 PC 或其它主机设备

场景二
在 ESP32 上运行控制器（此时设备将单纯作为蓝牙控制器使用），外接一个运行蓝牙主机的设备（如运行 BlueZ 的 Linux PC、运行 Bluedroid 的 Android 等）

此场景下，控制器和主机运行在不同宿主上，与手机、PAD、PC 的使用方式比较类似

场景三
此场景与场景二类似，特别之处在于，在 BQB（或其它认证）的控制器测试下，可以将 ESP32 作为 DUT（Device Under Test），用 UART 作为 IO 接口，接上认证测试的 PC 机，即可完成认证

​

IDF 中的 host、controller 目录，其中存放有不同芯片型号相应的库文件及接口等

路径：idf 安装路径\v5.3.1\esp-idf\components\bt​

---

---

GAP

关于 GAP 在蓝牙协议栈中的作用，见ESP32学习笔记_Bluetooth(1)——蓝牙技术与 BLE 通信机制简介中的 Core Architecture 部分

这部分的原文，详见： 《Bluetooth Core Specification v 5.0》 Vol3 PartC
通用访问配置文件（Generic Access Profile，GAP）的目的如下：

1. 引入与运输和应用配置文件使用的模式和访问程序相关的定义、建议和通用要求
2. 描述设备在待机和连接状态下的行为，以保证蓝牙设备之间始终能够建立连接和通道，并且支持多配置文件操作。特别关注设备发现、链路建立和安全程序
3. 规定用户界面方面的要求，主要是编码方案和过程与参数的命名，以确保用户体验

该配置文件的目的是描述：

• 配置文件角色
• 可发现模式和程序
• 连接模式和程序
• 安全模式和程序

GAP 与蓝牙底层架构的关系

图源：Bluetooth Core Specification v5.0

‍

Roles when Operating over BR/EDR Physical Transport

BR/EDR 是 Bluetooth Radio/Enhanced Data Rate 的缩写，指的是蓝牙技术中的两种主要通信模式：

• BR (Basic Rate)​基本速率，是蓝牙 1.x 版本中使用的传输速率，最高为 1 Mbps​
• EDR (Enhanced Data Rate)​增强数据传输速率，是蓝牙 2.x 版本及更高版本中引入的，提供更高的传输速率，最高为 3 Mbps

BR/EDR 是蓝牙经典（Bluetooth Classic）模式的一部分，适用于需要较高数据传输速率的应用，如音频传输（例如蓝牙耳机）和文件传输

‍
在 GAP 协议中，为了描述发生在 BR/EDR GAP 角色的两个设备之间的蓝牙通信，使用以下两个通用符号描述设备：

• A-party A 方​链路建立时的分页设备（发起连接请求的设备）
• B-party B 方​接收连接请求的设备

在蓝牙的 GAP 协议中，“分页设备”（paging device）是指在进行蓝牙设备配对或连接时，发起连接请求的设备。分页设备通过广播其存在来寻找其他设备，并尝试建立一个连接

具体而言，“分页”（paging）指的是一种低功耗的搜索过程，设备会扫描特定的信道，并等待另一方设备响应以建立连接

该配置文件涵盖了由一个设备（A）发起，针对另一个设备（B）的程序，后者可能已经建立了蓝牙连接，也可能没有

图源：《Bluetooth Core Specification v5.0》

发起者和接受者通常根据此配置文件或引用此配置文件的其他配置文件执行通用程序；如果接受者同时根据多个配置文件操作，则此配置文件提供了处理这种情况的通用机制

Roles when Operating over an LE Physical Transport

LE 指的是 Bluetooth Low Energy（蓝牙低功耗）技术

在 LE 通信中，有四种 GAP 角色定义：

• 广播者
  • 在广播者角色下运行的设备是发送广告事件的设备，必须具有发射器，并且可以具有接收器
• 观察者
  • 在观察者角色下运行的设备是接收广告事件的设备，必须具有接收器，并且可以具有发射器
• 外设
  • 任何接受连接建立程序建立 LE 活动物理链路的设备被称为处于外设角色，运行在外设角色的设备将在链路层连接状态中处于从属角色，运行在外设角色的设备被称为外设，必须具有发射器和接收器
• 中央设备
  • 支持中央角色的设备发起 LE 活动物理链路的建立，运行在中央角色的设备被称为中央设备。中央设备必须具有发射器和接收器

‍
同时在多个 GAP 角色下运行
如果控制器支持，设备可以同时在多个GAP角色下运行，主机应在使用任何程序或模式之前，先读取控制器支持的链路层状态和状态组合

Defines compliance requirements

在 LE 物理传输上操作时，每个 GAP 角色的物理层和链路层功能的 GAP 遵从性要求

图源：Bluetooth Core Specification v5.0

符号释义

• M​强制支持的功能
• O​可选支持的功能
• C​条件支持的功能
• E​在配置文件角色中排除的功能
• N/A​不适用的功能
• C1​如果支持被动扫描，则主动扫描是可选的，否则主动扫描是强制的
• C2​如果支持连接参数请求过程，则必选，否则可选

‍

Device Connection Establishment Process

1. 设备 A、B 进入空闲状态
2. 在上层软件控制下，A 进入广播状态，向外界进入广播状态，B 进入扫描状态
3. 当 B 扫描到数据后，进入初始化状态，发送请求连接的数据给 A
4. 设备 A 返回数据给 B，进入连接状态
5. B 收到返回的数据后，进入连接状态
6. 两个设备相互交换数据

对于部分设备，可能不需要连接（如 BLE Beacon、BLE Sniffer）