ESP32_Bluetooth_Architecture__CN

Transcription

1 ESP32 蓝 牙架构 版本 1.0 版权 2017

2 关于本 手册 本 手册为 ESP32 的蓝 牙架构简介, 主要分三个章节介绍了了蓝 牙 经典蓝 牙和蓝 牙低功耗 方 面的整体架构 注意, 本 手册仅针对 ESP-IDF V2.1 及以下版本 章 标题 内容 第 1 章 蓝 牙简介 本章节介绍了了 ESP32 的蓝 牙概况 第 2 章 经典蓝 牙 本章节介绍了了 ESP32 的经典蓝 牙概况 主要协议及规范 第 3 章 蓝 牙低功耗 本章节介绍了了 ESP32 的蓝 牙低功耗概况 GATT GAP 及 SMP 发布说明 日期版本发布说明 V1.0 首次发布 文档变更更通知 用户可通过乐鑫官 网订阅技术 文档变更更的电 子邮件通知

3 目录 1. 蓝 牙 概述 蓝 牙应 用结构 HCI 接 口选择 蓝 牙运 行行环境 框架 控制器器 BLUEDROID 主机架构 OS 相关适配 蓝 牙 目录 经典蓝 牙 概述 协议和规范 L2CAP SDP GAP A2DP 和 AVRCP 蓝 牙低功耗 GAP 概述 BLE 设备 角 色转换状态图 BLE 广播流程 使 用 public 地址进 行行 广播 使 用可解析地址进 行行 广播 使 用静态随机地址进 行行 广播 BLE 广播类型介绍... 19

4 可连接可扫描 非定向 广播 高占空 比定向 广播和可连接低占空 比定向 广播 可扫描 非定向 广播 不不可连接 非定向 广播 BLE 广播过滤策略略介绍 BLE 扫描流程 BLE GAP 实现机制 GATT ATT 属性协议 GATT 规范 基于 ESP32 IDF 建 立 GATT 服务 (GATT 服务器器 ) 基于 ESP32 IDF 发现对 方设备的服务信息 (GATT 客户端 ) SMP 概述 BLE 安全管理理控制器器 BLE 加密流程 BLE 绑定流程 BLE 安全管理理实现机制... 30

5 1. 蓝 牙 1. 蓝 牙 本章节介绍了了 ESP32 的基本蓝 牙架构 1.1. 概述 蓝 牙应 用结构蓝 牙是 一种短距通信系统, 其关键特性包括鲁棒性 低功耗 低成本等 蓝 牙系统分为两种不不同的技术 : 经典蓝 牙 (Classic Bluetooth) 和蓝 牙低功耗 (Bluetooth Low Energy) ESP32 支持双模蓝 牙, 即同时 支持经典蓝 牙和蓝 牙低功耗 从整体结构上, 蓝 牙可分为控制器器 (Controller) 和主机 (Host) 两 大部分 : 控制器器包括了了 PHY Baseband Link Controller Link Manager Device Manager HCI 等模块, 用于硬件接 口管理理 链路路管理理等等 ; 主机则包括了了 L2CAP SMP SDP ATT GATT GAP 以及各种规范, 构建了了向应 用层提供接 口的基础, 方便便应 用层对蓝 牙系统的访问 主机可以与控制器器运 行行在同 一个宿主上, 也可以分布在不不同的宿主上 ESP32 可以 支持上述两种 方式, 下图罗列列了了 几种典型应 用结构 : ESP32 PC Bluedroid VHCI UART/SDIO Linux/Android PC Bluetooth Controller UART 图 1-1. ESP32 蓝 牙主机与控制器器的关系结构图 Test Tool(BQB) 场景 一 (ESP-IDF 默认 ): 在 ESP32 的系统上, 选择 BLUEDROID 为蓝 牙主机, 并通过 VHCI( 软件实现的虚拟 HCI 接 口 ) 接 口, 访问控制器器 此场景下, BLUEDROID 和控制器器都运 行行在同 一宿主上 ( 即 ESP32 芯 片 ), 不不需要额外连接运 行行蓝 牙主机的 PC 或其它主机设备 Espressif 1/31

6 1. 蓝 牙 场景 二 : 在 ESP32 上运 行行控制器器 ( 此时设备将单纯作为蓝 牙控制器器使 用 ), 外接 一个运 行行蓝 牙主机的设备 ( 如运 行行 BlueZ 的 Linux PC 运 行行 BLUEDROID 的 Android 等 ) 此场景下, 控制器器和主机运 行行在不不同宿主上, 与 手机 PAD PC 的使 用 方式 比较类似 场景三 : 此场景与场景 二类似, 特别之处在于, 在 BQB( 或其它认证 ) 的控制器器测试下, 可以将 ESP32 作为 DUT, 用 UART 作为 IO 接 口, 接上认证测试的 PC 机, 即可完成认证 HCI 接 口选择 ESP32 上,HCI 只能同时使 用 一个 IO 接 口, 即如使 用 UART, 则放弃 VHCI SDIO 等其他 IO 接 口 在 ESP-IDF(V2.1 以后 ) 中, 可以在 menuconfig 中将蓝 牙的 HCI IO 接 口 方式配置为 VHCI 或 UART, 如下图 : 图 1-2. HCI IO 接 口 方式配置若选中 Bluedroid Bluetooth stack enabled, 则表示使 用 VHCI 作为 IO 方式, 那么 HCI use UART as IO (NEW) 选项会消失 ; 若选中 HCI use UART as IO (NEW), 则表示使 用 UART 作为 IO 方式 ; 目前,ESP-IDF 暂时不不 支持其他 IO, 如需使 用其他 方式 ( 如 SPI 等 ), 则需开发 SPI-VHCI 的 bridge 模块 选项 一 : 进 入 Bluedroid Bluetooth stack enabled 选项时, 可以看到如下配置 图 1-3. VHCI 配置 Espressif 2/31

7 1. 蓝 牙 如上图所示, 用户可在此界 面配置 : Bluetooth event (callback to application) task stack size(btc Task 大 小 ); Bluedroid memory debug(bluedroid 内存调试 ); Classic Bluetooth( 使能经典蓝 牙 ); Release DRAM from Classic BT Controller( 从经典蓝 牙控制器器中释放 DRAM); Include GATT server module (GATTS)( 包括 GATTS 模块 ); Include GATT client module (GATTC)( 包括 GATTC 模块 ); Include BLE security module (SMP)( 包括 SMP 模块 ); Close the bluedroid bt stack log print( 关闭 BLUEDROID 打印 ); BT/BLE MAX ACL CONNECTIONS (1~7)( 最 大 ACL 连接数 ) 等 选项 二 : 进 入 HCI use UART as IO 选项时, 可以看到如下配置 图 1-4. UART 配置 用户可在此界 面配置 UART Number for HCI (NEW)(UART 端 口号 ), 以及 UART Baudrate for HCI (NEW)(UART 端 口的波特率 ) 其中,UART 模式必须 支持硬件流控 (CTS/RTS) 蓝 牙运 行行环境 ESP-IDF 的默认运 行行环境为双核 FreeRTOS,ESP32 的蓝 牙可按照功能分为多个任务 (task) 运 行行, 不不同任务的优先级也有不不同, 其中优先级最 高的为运 行行控制器器的任务 控制器器任务对实时性的要求较 高, 在 FreeRTOS 系统中的优先级仅次于 IPC 任务 (IPC 任务 用于双核 CPU 的进程间通信 ) BLUEDROID(ESP-IDF 默认蓝 牙主机 ) 共包含 4 个任务, 分别运 行行 BTC BTU HCI UPWARD, 及 HCI DOWNWARD Espressif 3/31

8 1. 蓝 牙 1.2. 框架 控制器器 ESP32 的控制器器同时 支持 Classic BT 和 BLE, 支持的蓝 牙版本为 4.2 控制器器中主要集成了了 H4 协议 HCI Link Manager Link Controller Device Manager HW Interface 等功能 这些功能都以库的形式提供给开发者, 并做了了 一些 API 用来访问控制器器, 具体请 见 readthedocs 图 1-5. Classic BT & BLE 控制器器架构 ( 摘 自 SIG BT CORE4.2) BLUEDROID 主机架构在 ESP-IDF 中, 使 用经过 大量量修改后的 BLUEDROID 作为蓝 牙主机 (Classic BT + BLE) BLUEDROID 拥有较为完善的功能, 支持常 用的规范和架构设计, 同时也较为复杂 经过 大量量修改后,BLUEDROID 保留留了了 大多数 BTA 层以下的代码, 几乎完全删去了了 BTIF 层的代码, 使 用了了较为精简的 BTC 层作为内置规范及 Misc 控制层 修改后的 BLUEDROID 及其与控制器器之间的关系如下图 : Espressif 4/31

9 1. 蓝 牙 Espressif Bluedroid Coarse Architecture V1.1 USER TASK USER APP PROCEDURE ESP_API GATT GAP SDP BLE PROFILES BT PROFILES BTC TASK BLE PROFILE BLE PROFILE BT PROFILE BAT TER Y BLE HID SPP LIK E BLU FI 6 Low Pan L2C AP D- Chan A2D P SPP BTA_API GAP GAP SDP BLE PROFILES BT PROFILES BTU TASK BLE & BT STACK 6LowPan BLE LOW-LAYER PROFILE L2CAP Dynamic CHANNEL BT LOW-LAYER PROFILE A2DP RFCOMM GATT/ATT L2ACAP SDP SMP GAP H4 HCI TRANSPORT LAYER (Include HCI Task) VHCI_API VHCI Contr oller TASK Controller H4 HCI LM/LC HW Interface 图 1-6. ESP32 BLUEDROID 层次关系图 说明 : 此架构图主要描述架构层次, 部分细节 ( 如 HCI TASK) 已舍去 下 文会较为具体地介绍各层次的内容 Espressif 5/31

10 1. 蓝 牙 从上图可以看到,BLUEDROID 内部 大致分为 2 层 :BTU 层和 BTC 层 ( 除去 HCI ), 每个层都有对应的任务来处理理 BTU 层主要负责蓝 牙主机底层协议栈的处理理, 包括 L2CAP GATT/ATT SMP GAP 以及部分规范等, 并向上提供以 bta 为前缀的接 口 ; BTC 层主要负责向应 用层提供接 口 支持 处理理基于 GATT 的规范 处理理杂项等, 并向应 用层提供以 esp 为前缀的接 口 所有的 API 都在 ESP_API 层, 开发者应当使 用 esp 为前缀的蓝 牙 API( 特殊的除外 ) 上图并未详细描述 HCI 部分, 而事实上,HCI 具有 2 个任务 ( 至少在 ESP-IDF V2.1 以前 ), 分别处理理 Downward 和 Upward 的数据 此框架的其中 一条设计思路路是尽量量将蓝 牙相关的任务交给 BTC 来处理理, 从 而避免和降低 用户任务 (User Task) 的负载, 也使结构上更更加简洁 由于历史原因和实际需求, 经典蓝 牙的部分规范, 如 RFCOMM A2DP 等, 中层次偏协议偏底层的部分运 行行在 BTU 层, 偏控制流程的以及需要提供 ESP-API 的运 行行在 BTC 层 蓝 牙低功耗的部分规范或偏底层的功能, 如 6LowPan 或 Dynamic L2CAP Channel 的功能, 将运 行行在 BTU 层, 再通过 BTC 向应 用层提供 ESP-API OS 相关适配 BLUEDROID 中有部分与系统相关的接 口需要进 行行 OSI 适配, 涉及到的功能包括 Timer (Alarm) Task (Thread) Future Await/Ready (Semphore) Allocator/GKI (malloc/free) 等 BLUEDROID 中将 FreeRTOS 的 Timer 封装成 Alarm, 用于启动定时器器, 触发某些特定任务 BLUEDROID 将原先的 Linux 下的 Thread 部分重新替换成 FreeRTOS 的任务, 并使 用 FreeRTOS 的 Queue 来触发任务的运 行行 ( 唤醒 ) BLUEDROID 使 用 Future Await/Ready 功能来实现阻塞,Future Lock 将 FreeRTOS 的 xsemphoretake 包装成 future_await 函数, 并将 xsemphoregive 包装成 future_ready 函数 值得注意的是,future_await 和 future_ready 不不能在同 一任务中调 用 BLUEDROID 将标准库中的 malloc/free 封装成 Allocator 的申请 / 释放内存的函数,GKI 功能也同样使 用 malloc/free 来作为 GKI_getbuf/GKI_freebuf 的核 心函数 蓝 牙 目录进 入 ESP-IDF 的 component/bt 目录, 可以看到有如下 子 目录和 子 文件 : Espressif 6/31

11 1. 蓝 牙 各级 目录的具体说明 见下表 : 图 1-7. ESP-IDF 的 component/bt 目录 表 1-1. ESP-IDF 的 component/bt 目录说明 目录 说明 备注 Kconfig 实 用 工具函数 bluedroid BLUEDROID 主 目录 api API 目录, 所有的 API( 除 Controller 相关 ) 都在此 目录下 bta 蓝 牙适配层, 适配 一些主机底层协议的接 口 btc 蓝 牙控制层, 控制主机上层协议 ( 包括规范 ) 以及杂项的 处理理 btcore 一些原始的 feature/bdaddr 转换函数欲废弃 btif 一些 BTA 使 用 call out 函数欲废弃 device external 与控制器器设备控制相关的, 如控制器器基本设置的 HCI CMD 流程等与蓝 牙 自身 无关, 但 又要使 用的代码, 如 SBC codec 软件程序等 gki BLUEDROID 内存常 用的 buffer queue 等管理理代码 Espressif 7/31

12 1. 蓝 牙 目录 说明 备注 hci HCI 层协议 include BLUEDROID 顶层的 文件 目录 main 主程序 目录 ( 主要为启动 关闭流程 ) osi OS 接 口相关 ( 包括 semphore/timer/thread 等 ) stack 主机底层协议栈 (GAP/ATT/GATT/SDP/SMP 等 ) utils 实 用 工具函数 bt.c 控制器器相关处理理 文件 component.mk makefile include 控制器器相关头 文件 目录 bt.h 包含控制器器相关 API 的头 文件 lib 控制器器库 目录 LICENSE License README.rst 帮助 文件 libbtdm_app.a 控制器器库 Espressif 8/31

13 2. 经典蓝 牙 2. 经典蓝 牙 本章介绍了了 ESP-IDF 中的经典蓝 牙 2.1. 概述 ESP-IDF 中的蓝 牙主机协议栈源于 BLUEDROID, 后经过改良以配合嵌 入式系统的应 用 在底层中, 蓝 牙主机协议栈通过虚拟 HCI 接 口, 与蓝 牙双模控制器器进 行行通信 ; 在上层中, 蓝 牙主机协议栈将为 用户应 用程序提供 用于协议栈管理理和规范的 API 协议 (Protocol) 定义了了完成特定功能的消息格式和过程, 例例如数据传输 链路路控制 安全服务和服务信息交换等 另 一 方 面, 蓝 牙规范 (Profile) 则定义了了蓝 牙系统中从 PHY 到 L2CAP 及核 心规范外的其他协议所需的功能和特性 目前, 主机协议栈 支持的经典蓝 牙规范和协议如下 规范 :GAP A2DP (SNK) AVRCP (CT) 协议 :L2CAP SDP AVDTP AVCTP 协议模型如图 2-1 所示 图 2-1. 蓝 牙规范关系图 如图 2-1 所示,L2CAP 和 SDP 是经典蓝 牙最 小主机协议栈的必备组成部分,AVDTP AV/ C 和 AVCTP 并不不属于核 心规范, 仅 用于特定规范 Espressif 9/31

14 2. 经典蓝 牙 2.2. 协议和规范 L2CAP 蓝 牙逻辑链路路控制和适配协议 (L2CAP) 是 OSI 2 层协议, 支持上层的协议复 用 分段和重组及服务质量量信息的传递 L2CAP 可以让不不同的应 用程序共享 一条 ACL-U 逻辑链路路 应 用程序和服务协议可通过 一个 面向信道的接 口, 与 L2CAP 进 行行交互, 从 而与其他设备上的等效实体进 行行连接 L2CAP 信道共 支持 6 种模式, 可通过 L2CAP 信道配置过程进 行行选择, 不不同模式的应 用场合不不同, 主要差别在于可提供的 QoS 不不同 这些模式分别是 : 基本 L2CAP 模式 流量量控制模式 重传模式 加强重传模式 流模式 基于 LE Credit 的流量量控制模式其中,ACL-U 逻辑链路路 支持的操作模式包括基本 L2CAP 模式 加强重传模式和流模式 L2CAP 信道为 支持的固定信道, 也 支持 帧校验序列列 (FCS) SDP 服务发现协议 (SDP) 允许应 用程序发现其他对等蓝 牙设备提供的服务, 并确定可 用服务的特征 SDP 包含 SDP 服务器器和 SDP 客户端之间的通信 服务器器维护 一个描述服务特性的服务记录表 客户端可通过发出 SDP 请求, 从服务器器维护的服务记录表中进 行行信息检索 SDP 客户端和服务器器都部署在主机协议栈中, 该模块仅供 A2DP 和 AVRCP 等规范使 用, 目前并不不为 用户应 用程序提供 API GAP 通 用访问规范 (GAP) 可提供有关设备可发现性 可连接性和安全性的模式和过程描述 目前, 经典蓝 牙主机协议栈仅提供少数 几个 GAP API 应 用程序可以将这些 API 用作 被动 设备, 被对等蓝 牙设备发现并连接 然 而, 目前暂不不向客户 ( 用户应 用程序 ) 提供 用于发起问询 (Inquiry) 的 API Espressif 10/31

15 2. 经典蓝 牙 在安全 方 面,IO 功能已经在代码中固定为 无输 入, 无输出, 因此只 支持 蓝 牙安全简单配对 (Secure Simple Pairing) 中的 Just Works 关联模型 链路路密钥的存储将由主机 自动完成 未来, 经典蓝 牙将推出更更多 GAP API, 并提供功能更更强 大且可 支持其他关联模型的安全 API, 以及 用于设备发现和链接策略略设置的 API A2DP 和 AVRCP 高级 音频分发规范 (Advanced Audio Distribution Profile, A2DP) 定义了了在 ACL 信道上, 实现 高质量量单声道或 立体声 音频内容传输的协议和过程 A2DP 负责处理理 音频流, 通常与 音频 / 视频远程控制规范 (AVRCP) ( 包括 音频 / 视频控制功能 ) 一起使 用 图 2-2 描述了了这些规范的结构和关系图 [1]: 注意 : [1]: 高级 音频分发规范 ( 修订版 1.3.1) 图 2-2. 规范关系图如图 2-2 所示,A2DP 的 工作基于 GAP 以及 通 用 音频 / 视频分发规范 (GAVDP), 定义了了建 立 音频 / 视频流的过程 A2DP 中共定义了了两个 角 色 :Source (SRC) 和 Sink (SNK) SRC 代表数字 音频流的源端, SNK 代表数字 音频流的接收端 Espressif 11/31

16 2. 经典蓝 牙 AVRCP 中共定义了了两个 角 色 : 控制器器 (CT) 和 目标 (TG) 控制器器可通过向 目标发送 命令帧, 发起事务 控制器器的常 见例例 子包括个 人电脑 PDA 和移动电话等 目标可接收控制器器发送的 命令帧, 并 生成相应的 响应帧 目标的常 见例例 子包括 音频播放器器或 耳机 目前,A2DP (SRC) 和 AVRCP (CT) 已经得到 支持, 设备可以作为扬声器器, 向 音频源发送遥控信息 在 目前的 A2DP 解决 方案中,SBC 是唯 一 支持的 音频编解码器器,SBC 在 A2DP 规范中是必须的编解码格式 目前 方案中实现的规范 协议版本是 A2DP V1.2 和 AVDTP V1.2 AVDTP 协议定义了了蓝 牙设备之间在 L2CAP 协议层上建 立和传输媒体流的 二进制业务 作为 A2DP 的基本传输协议,AVDTP 建 立在 L2CAP 层协议之上, 由 一个协商媒体流参数的信令传输实体 和 一个传输媒体流的实体 组成 在 AVDTP 传输功能中, 基本服务是 A2DP 规范中所强制要求的 根据当前的服务能 力力配置, 基本服务中可提供 媒体传输 和 媒体编解码器器 功能 AVRCP 定义了了 支持 音频 / 视频遥控的应 用场景的各项需求 AVRCP 中的命令主要分为三个 大组 : AV / C 数字接 口命令集, 其特定命令 子集被采 用, 且通过 AVCTP 协议传输 ; 浏览命令, 可通过 AVCTP 浏览信道, 提供浏览功能 ; 封 面艺术命令, 用于传输与媒体项 目有关的图像, 通过基于 OBEX 协议的 蓝 牙基本图像规范 (BIP) 实现 AVRCP 使 用了了其中的两套 AV/C 命令 : 其 一包括 AV/C 规范中定义的 PASS THROUGH UNIT INFO 和 SUBUNIT INFO 命令 ; 其 二是 AVRCP 专 用 AV/C 命令, 作为对 Bluetooth SIG Vendor Dependent 的扩展 AV/C 命令通过 AVCTP 控制信道发送 PASS THROUGH 命令可通过控制器器上的按钮, 向 面板 子单元传送 用户操作, 并提供 一个简单的通 用机制来控制 目标 例例如,PASS THROUGH 中的操作 ID 包括播放 暂停 停 止 调 高 音量量和调低 音量量等常 用指令 为了了保证互操作性,AVRCP 将 A/V 功能分为四类 : 播放机 / 录像机 监控器器 / 放 大器器 调 音器器 菜单 目前的 方案提供了了 AVRCP V1.3 和 AVCTP V1.4 AVRCP 支持功能的默认配置属于第 二类, 即监视器器 / 放 大器器 此外, 方案还提供了了 用于发送 PASS THROUGH 命令的 API A2DP 和 AVRCP 经常 一起使 用 在 目前的解决 方案中, 下层主机堆栈实现了了 AVDTP 和 AVCTP 逻辑, 并独 立为 A2DP 和 AVRCP 提供接 口 然 而, 在堆栈上层中, 两个规范组合 Espressif 12/31

17 2. 经典蓝 牙 匹配成为 AV 模块 例例如,BTA 层提供 一个统 一的 AV 接 口, 而在 BTC 层中, 状态机将 处理理两种规范的事务 然 而,A2DP 和 AVRCP 的 API 是分别提供的 Espressif 13/31

18 3. 蓝 牙低功耗 3. 蓝 牙低功耗 3.1. GAP 本章节介绍了了 ESP32 的蓝 牙低功耗功能 概述本章节主要介绍了了 ESP32 BLE 通 用访问规范 (GAP) 接 口 API 的实现和使 用流程,GAP 协议层定义了了 BLE 设备的发现流程, 设备管理理和设备连接的建 立 BLE GAP 协议层采 用 API 调 用和事件 (Event) 返回的设计模式, 通过事件返回来获取 API 在协议栈的处理理结果 当对端设备主动发起请求时, 也是通过事件返回获取对端设备的状态 BLE 设备定义了了四类 GAP 角 色 : 广播者 (Broadcaster): 处于这种 角 色的设备通过发送 广播 (Advertising) 让接收者发现 自 己 这种 角 色只能发 广播, 不不能被连接 观察者 (Observer): 处于这种 角 色的设备通过接收 广播事件并发送扫描 (Scan) 请求 这种 角 色只能发送扫描请求, 不不能被连接 外围设备 (Peripheral): 当 广播者接受了了观察者发来的连接请求后就会进 入这种 角 色 当设备进 入了了这种 角 色之后, 将会作为从设备 (Slave) 在链路路中进 行行通信 中央设备 (Central): 当观察者主动进 行行初始化, 并建 立 一个物理理链路路时就会进 入这种 角 色 这种 角 色在链路路中同样被称为主设备 (Master) Espressif 14/31

19 3. 蓝 牙低功耗 BLE 设备 角 色转换状态图 Scanning Advertising Standby Initiating Connection 图 3-1. BLE 设备 角 色转换状态图 Espressif 15/31

20 3. 蓝 牙低功耗 BLE 广播流程 使 用 public 地址进 行行 广播使 用 public 地址进 行行 广播时, 需要将 esp_ble_adv_params_t 成员 own_addr_type 设置为 BLE_ADDR_TYPE_PUBLIC, 广播流程图如下 : Advertiser Scanner esp_ble_gap_set_device_ name esp_ble_gap_config_adv_ data API LLM LLM API 发送 config adv data HCI command 给 LL 层 ESP_GAP_BLE_ADV_DATA _SET_COMPLETE_EVT 返回 set adv data event 调用 Esp_ble_gap_start_advertising API 开始发送广播, 并将 own_addr_type 设置成 BLE_ADDR_TYPE_PUBLIC 发送 start adv HCI command 给 LL 层 返回 start adv event ESP_GAP_BLE_ADV_ST ART_COMPLETE_EVT Advertising event Advertising event ESP_GAP_BLE_SCA N_RESULT_EVT 图 3-2. 广播流程图 使 用 public 地址 Espressif 16/31

21 3. 蓝 牙低功耗 使 用可解析地址进 行行 广播使 用可解析地址进 行行 广播时, 底层协议栈会 15 分钟更更新 一次 广播地址, 需要将 esp_ble_adv_params_t 成员 own_addr_type 设置为 BLE_ADDR_TYPE_RANDOM, 广播流程图如下 : Advertiser Scanner esp_ble_gap_set_device_ name API LLM LLM API 调用 esp_ble_gap_config_local_ privacy esp_ble_gap_config_adv_ data 发送 config adv data HCI command 给 LL 层 返回 set adv data event ESP_GAP_BLE_ADV_DA TA_SET_COMPLETE_EV T 调用 Esp_ble_gap_start_advertisin g API 开始发送广播, 并将 own_addr_type 设置成 BLE_ADDR_TYPE_RANDO M 发送 start adv HCI command 给 LL 层 返回 start adv event ESP_GAP_BLE_ADV_ST ART_COMPLETE_EVT Advertising event Advertising event ESP_GAP_BLE_SCA N_RESULT_EVT 图 3-3. 广播流程图 使 用可解析地址 注意 : 当使 用可解析地址进 行行 广播时, 需要等待 esp_ble_gap_config_local_privacy 事件返回后, 才能开始 广播, 并且需要将 广播参数 里里的 own_addr_type 类型设置为 BLE_ADDR_TYPE_RANDOM Espressif 17/31

22 3. 蓝 牙低功耗 使 用静态随机地址进 行行 广播与使 用可解析地址进 行行 广播 一样, 使 用静态随机地址进 行行 广播也需要将 esp_ble_adv_params_t 成员 own_addr_type 设置为 BLE_ADDR_TYPE_RANDOM, 广播流程图如下 : Advertiser Scanner esp_ble_gap_set_device_ name API LLM LLM API 调用 esp_ble_gap_set_rand_addr 发送 set rand address HCI command 给 LL 层 ESP_GAP_BLE_SET_ST ATIC_RAND_ADDR_EVT 返回 set random address event esp_ble_gap_config_adv_ data 发送 config adv data HCI command 给 LL 层 ESP_GAP_BLE_ADV_DAT A_SET_COMPLETE_EVT 返回 set adv data event 调用 Esp_ble_gap_start_advertisin g API 开始发送广播, 并将 own_addr_type 设置成 BLE_ADDR_TYPE_RANDO M 发送 start adv HCI command 给 LL 层 Advertising event ESP_GAP_BLE_ADV_ST ART_COMPLETE_EVT 返回 start adv event Advertising event ESP_GAP_BLE_SCA N_RESULT_EVT 图 3-4. 广播流程图 使 用静态随机地址 Espressif 18/31

23 3. 蓝 牙低功耗 BLE 广播类型介绍 BLE 广播主要有 5 种类型, 分别为 : 可连接可扫描 非定向 广播 (Connectable scannable undirected event type) 高占空 比定向 广播 (High duty cycle directed event type) 可扫描 非定向 广播 (Scannable undirected event type) 不不可连接 非定向 广播 (Non-connectable undirected event type) 可连接低占空 比定向 广播 (Connectable low duty cycle directed event type) 可连接可扫描 非定向 广播 Payload 表 3-1. 数据包结构 AdvA (6 octets) AdvData (0~31 octets) 可连接可扫描 非定向 广播是指可被任何设备发现并可连接 可扫描是指当对端设备发送扫描请求 (Scan Request) 时, 本端设备需要回复扫描应答 (Scan Response) 如上表所示, 可连接可扫描 非定向 广播数据包主要包括 6 个字节的 广播地址和 0~31 个字节的 广播数据包内容 其中, 当 广播地址类型设置为 静态随机地址 时, 应 用需要调 用 esp_ble_gap_set_rand_addr 设置指定的地址进 行行 广播 ; 当 广播地址类型设置为 public 或 可解析地址 时, 则由协议栈 自动 生成 高占空 比定向 广播和可连接低占空 比定向 广播 Payload 表 3-2. 数据包结构 AdvA (6 octets) InitA (6 octets) 定向 广播只能被指定设备所发现和连接 如上表所示, 高占空 比定向 广播数据包主要包括 6 个字节的固定 广播设备接收地址和 6 个字节的指定 广播设备接收地址 在本 广播类型下, 广播参数中的 adv_int_min 和 adv_int_max 将被忽略略 在可连接低占空 比定向 广播类型下, 广播参数中的 adv_int_min 和 adv_int_max 必须 大于 100 ms (0xA0) 说明 : 定向 广播不不携带 广播数据 (Adv Data) Espressif 19/31

24 3. 蓝 牙低功耗 可扫描 非定向 广播 可扫描 非定向 广播是指可被任何设备发现但是不不能被连接 Payload 表 3-3. 数据包结构 AdvA (6 octets) AdvData (0~31 octets) 如上表所示, 与可连接可扫描 非定向 广播数据包 一样, 可扫描 非定向 广播数据包也包括 6 个字节的 广播地址和 0~31 个字节的 广播数据包内容, 但是只能被设备扫描 而不不能被设备连接 不不可连接 非定向 广播不不可连接 非定向 广播是指可被任何设备发现, 但是既不不可扫描也不不可连接 不不可扫描是指当对端设备发送扫描请求时不不会回应扫描应答, 不不可连接是指不不能被任何设备连接 Payload 表 3-4. 数据包结构 AdvA (6 octets) AdvData (0~31 octets) 如上图所示, 不不可连接 非定向 广播数据包也包括 6 个字节的 广播地址和 0~31 个字节的 广播数据包内容, 但是只能被设备发现不不能被设备扫描也不不能被连接 BLE 广播过滤策略略介绍在 ESP32 的 BLE 中, 通过设置 adv_filter_policy 枚举类型来实现 广播过滤策略略, 此枚举类型中有以下 4 个值 : ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY ADV_FILTER_ALLOW_SCAN_WLST_CON_ANY ADV_FILTER_ALLOW_SCAN_ANY_CON_WLST ADV_FILTER_ALLOW_SCAN_WLST_CON_WLST 这 4 个值分别对应 4 种情况, 分别为 : 可被任何设备扫描和连接 ( 不不使 用 白名单 ) 处理理所有连接请求和只处理理在 白名单设备中的扫描请求 处理理所有扫描请求和只处理理在 白名单中的连接请求 只处理理在 白名单中设备的连接请求和扫描请求 Espressif 20/31

25 3. 蓝 牙低功耗 BLE 扫描流程在 ESP32 中, 扫描设备主要是通过调 用 esp_ble_gap_set_scan_params 来设置扫描时的参数, 然后调 用 esp_ble_gap_start_scanning 开始扫描 扫描到的设备将会通过 ESP_GAP_BLE_SCAN_RESULT_EVT 事件返回, 最后当 duration 超时时, 会通过 ESP_GAP_SEARCH_INQ_CMPL_EVT 事件返回 注意 : 当 duration 值为 0 时, 将会永久扫描 而不不产 生超时 BLE GAP 实现机制 ESP32 的 BLE 通 用访问规范 (GAP) 采 用调 用 BLE gap API 相关的 API 和注册 BLE gap callback 并通过事件 (event) 返回来获取当前设备状态 3.2. GATT ATT 属性协议 BLE 里里 面的数据以属性 (Attribute) 方式存在, 每条属性由四个元素组成 : 属性句句柄 (Attribute Handle): 正如我们可以使 用内存地址查找内存中的内容 一样, ATT 属性的句句柄也可以协助我们找到相应的属性, 例例如第 一个属性的句句柄是 0x0001, 第 二个属性的句句柄是 0x0002, 以此类推, 最 大可以到 0xFFFF 属性类型 (Attribute UUID): 每个数据有 自 己需要代表的意思, 例例如表示温度 发射功率 电池等等各种各样的信息 蓝 牙组织 (Bluetooth SIG) 对常 用的 一些数据类型进 行行了了归类, 赋予不不同的数据类型不不同的标识码 (UUID) 例例如 0x2A09 表示电池信息,0x2A6E 表示温度信息 UUID 可以是 16 比特的 (16-bit UUID), 也可以是 128 比特的 (128-bit UUID) 属性值 (Attribute Value): 属性值是每个属性真正要承载的信息, 其他 3 个元素都是为了了让对 方能够更更好地获取属性值 有些属性的 长度是固定的, 例例如电池属性 (Battery Level) 的 长度只有 1 个字节, 因为需要表示的数据仅有 0~100%, 而 1 个字节 足以表示 1~100 的范围 ; 而有些属性的 长度是可变的, 例例如基于 BLE 实现的透传模块 属性许可 (Attribute Permissions): 每个属性对各 自的属性值有相应的访问限制, 比如有些属性是可读的 有些是可写的 有些是可读 又可写的等等 拥有数据的 一 方可以通过属性许可, 控制本地数据的可读写属性 Espressif 21/31

26 3. 蓝 牙低功耗 表 3-5. 属性结构表 属性句句柄 属性类型 属性值 属性许可 0x x xFFFE xFFFF 我们把存有数据 ( 即属性 ) 的设备叫做服务器器 (Server), 而将获取别 人设备数据的设备叫做客户端 (Client) 下 面是服务器器和客户端间的常 用操作: 客户端给服务端发数据, 通过对服务器器的数据进 行行写操作 (Write), 来完成数据发送 工作 写操作分两种, 一种是写 入请求 (Write Request), 一种是写 入命令 (Write Command), 两者的主要区别是前者需要对 方回复响应 (Write Response), 而后者不不需要对 方回复响应 服务端给客户端发数据, 主要通过服务端指示 (Indication) 或者通知 (Notification) 的形式, 实现将服务端更更新的数据发给客户端 与写操作类似, 指示和通知的主要区别是前者需要对 方设备在收到数据指示后, 进 行行回复 (Confirmation) 客户端也可以主动通过读操作读取服务端的数据 图 3-5. 客户端和服务器器间的常 见操作 注意 : 关于更更多的服务器器和客户端之间的属性操作, 参考蓝 牙协议 Core_V5.0 Vol3. Part F Chapter 3.4 Attribute Protocol PDUs Espressif 22/31

27 3. 蓝 牙低功耗 服务器器和客户端之间的交互操作都是通过上述的消息 ATT PDU 实现的 每个设备可以指定 自 己设备 支持的最 大 ATT 消息 长度, 我们称之为 MTU ESP32 IDF 里里 面规定 MTU 可以设置的范围是 23~517 字节, 对属性值的总 长度没有做限制 如果 用户需要发送的数据包 长度 大于 (MTU-3)*, 则需要调 用准 入写 入请求 (Prepare Write Request) 来完成数据的写操作 同理理, 在读取 一个数据时候, 如果数据的 长度超过 (MTU- 1), 则需要通过 大对象读取请求 (Read Blob Request) 来继续读取剩余的值 * 注意 : 注意区分 MTU 和空中的单个物理理数据包的最 大 长度 (LE Packet Length) 的区别 前者是针对 Host ATT 层, 而后者针对的是物理理层 (PHY) 简单解释, 即 MTU 针对的是单个 ATT Request 包能否完全装下要发送的数据, 是否需要使 用类似 Prepare Write Request 的包来分包发送 ; 而 LE Packet Length 是底层的物理理层 PHY 在发包的时候, 决定这个包是否需要分成多个物理理包来发送 例例如, 如果 (MTU+4 ) 大于 LE Packet Length, 则 1 个 ATT 包可能需要分成多个物理理包发送 ; 反之, 如果 (MTU+4) 小于 LE Packet Length, 则所有的 ATT 包都能通过 1 个物理理包发送出去 这 里里 MTU 之所以需要先加 4 再去 比较, 是因为实际发送的时候, 需要给包加上 4 个字节的 L2CAP 头信息 GATT 规范 ATT 属性协议规定了了在 BLE 中的最 小数据存储单位, 而 GATT 规范则定义了了如何 用特性值和描述符表示 一个数据, 如何把相似的数据聚合成服务 (Service), 以及如何发现对端设备拥有哪些服务和数据 GATT 规范引进了了特性值的概念 这是由于在某些时候, 一个数据可能并不不只是单纯的数值, 还会带有 一些额外的信息 : 比如这个数据的单位是什什么? 是重量量单位千克 kg 温度单位摄 氏度, 还是其他单位 ; 比如希望具体告知对 方这个数值的名称, 例例如同为温度属性 UUID 下, 希望告知对 方该数据表示 主卧温度, 另 一个数据表示 客厅温度 ; 比如在表示 等 大数据时, 可以增加指数信息, 告知对 方该数据的指数是 10^4, 这样仅需在空中传递 即可 上述内容仅为清楚描述 一个数据众多需求中的 几个例例 子, 实际应 用中还可能出现其他以各种 方式表达的数据需求 为了了包含这些信息, 每个属性中均需要安排 一 大段数据空间, 存储这些额外信息 然 而, 一个数据很有可能 用不不到绝 大部分的额外信息, 因此这种设计并这不不符合 BLE 协议尽可能精简 的要求 在此背景下,GATT 规范引进了了描述符的概念, 每种描述符可以表达 一种意思, 用户可使 用描述符, 描述数据的额外信息 必需说明的是, 每个数据和描述符并 非 一 一对应, 即 一个复杂的数据可以拥有多个描述符, 而 一个简单的数据可以没有任何描述符 Espressif 23/31

28 3. 蓝 牙低功耗 数据本身的属性值及其可能携带的描述符, 构成了了特性 (Characteristic)* 的概念 数据特性包含以下 几个部分 : 特性声明 (Characteristic Declaration): 主要告诉对 方此声明后 面跟的内容为特性数值 从当前特性声明开始到下 一个特性声明之间的所有句句柄 (Handle) 将构成 一个完整的特性 此外, 特性声明还包括紧跟其后的特性数值的可写可读属性信息 特性数值 (Characteristic Value): 特性的核 心部分, 一般紧跟在特性声明后 面, 承载特性的真正内容 描述符 (Descriptor): 描述符可以对特性进 行行进 一步描述, 每个特性可以有多个描述符, 也可以没有描述符 BLE 协议中会把 一些常 用的功能定义成 一个个的服务 (Service)*, 例例如把电池相关的特性和 行行为定义成电池服务 (Battery Service); 把 心率测试相关的特性和 行行为定义成 心跳服务 (Heart Rate Service); 把体重测试相关的特性和 行行为定义成体重服务 (Weight Scale Service) 可以看到, 每个服务包含若 干个特性, 每个特性包含若 干个描述符 用户可以根据 自 己的应 用需求选择需要的服务, 并组成最终的产品应 用 一个完整服务的特性定义参考如下 : 表 3-6. 服务定义示例例 属性句句柄 属性类型 0x0001 服务 1 0x0002 特性声明 1 0x0003 特性数值 1 0x0004 描述符 1 0x0005 特性声明 2 0x0006 特性数值 2 0x0007 描述符 2 0x0008 描述符 3 0x0009 服务 2 Espressif 24/31

29 3. 蓝 牙低功耗 * 注意 : 关于不不同的服务 特性值及描述符的定义, 详 见 : 蓝 牙协议 Core_V5.0 Vol3. Part G Chapter 3 Service Interoperability Requirements 蓝 牙官 网 基于 ESP32 IDF 建 立 GATT 服务 (GATT 服务器器 ) ESP32 IDF Release 1.0 实现了了 手动添加服务和特性的 方法 *, 这种 方式需要 用户基于事件 一条条地添加属性 所有的读写操作都会通过事件到应 用层, 由 用户 自 己组包回复 这种 方式对于不不熟悉 BLE 协议的 用户来说 比较容易易出错, 尤其在需要添加 大型 GATT 数据库的情况下, 不不推荐 用户使 用 * 注意 : ESP IDF 仍保留留了了之前添加服务和特性的接 口和 Example, 用户可参考 gatt_server 例例 子程序 在此背景之下,Release 2.0 基于先前版本, 推出了了通过属性表 (Attribute Table)* 添加服务和特性的功能 用户只需将要添加的服务和特性逐 一填 入 一个表格, 然后调 用 esp_ble_gatts_create_attr_tab 函数, 即可添加对应的服务和特性 此外, 这种属性表添加 方式还 支持底层 自动回复功能 这也就是说, 底层可以 自动回复 一些请求, 并判断 一些错误, 用户只需负责收发数据, 而 无需进 行行复杂的错误判断 这种 方式可以 方便便 用户从其他平台移植规范到 ESP32 平台, 整个过程 无需重新实现全部的 BLE 规范 * 注意 : 通过属性表添加服务和特性更更加简单 方便便, 不不易易出错, 而且底层还可以对收到的数据包 自动进 行行分析和 处理理, 推荐客户使 用, 可参考 gatt_server_service_table 例例 子程序 属性表的结构体规定了了 用户为了了描述 一个属性 而需要初始化的元素, 通过 esp_gatts_attr_db_t 进 行行定义, 总结如下 : 表 3-7. ESP32 IDF 结构体参数表 结构体参数 uint8_t attr_control uint16_t uuid_length 说明定义对于类似 write_response 的相关回复是由底层进 行行 自动回复, 或传到应 用层让 用户 手动回复 ( 推荐使 用 ESP_GATT_AUTO_RSP 自动回复模式 ) 表示 UUID 的 长度, 分 16-bit 32-bit 128-bit 三种 这是由于属性 UUID 是通过指针进 行行传递的, 因此需要说明 长度 Espressif 25/31

30 3. 蓝 牙低功耗 结构体参数 uint8_t *uuid_p uint16_t perm uint16_t max_length uint16_t length uint8_t *value 说明表示当前属性的 UUID 的指针, 用户根据上 面的 UUID 长度, 从指针 里里 面读取指定 长度的 UUID 值 表示当前属性的读写许可 该变量量为按位操作, 每个 比特表示 一个特定的读写属性, 对不不同 比特做或操作, 可以表示多种读写属性 例例如 PERM_READ PERM_WRITE 表示这个属性既可读 又可写 表示当前属性值的最 大 长度, 协议栈主要根据这个变量量为该属性分配内存 如果对 方写 入的属性值超过这 里里定义的最 大 长度, 即回复写错误, 错误原因是写 长度超出数据最 大 长度 表示当前属性的当前实际 长度 例例如, 该属性最 大的 长度是 512 字节, 对 方对其进 行行写操作, 把值设置成了了 2 个字节 0x1122, 我们就设置当前实际 长度为 2 当对 方设备对这个属性进 行行读操作, 我们可以从内存中获取该值的实际 长度, 仅将有实际内容的部分发送过去, 而 非将 512 字节全部发送给对 方 表示当前属性的属性值初始化值 由于这个参数为指针格式, 因此需要从上 面的 Length 获取该值的实际 长度, 从 而从指针 里里获得正确的值 基于 ESP32 IDF 发现对 方设备的服务信息 (GATT 客户端 ) GATT 客户端需要具有发现对 方设备的服务和特性的功能 (Service Discovery) 不不同的设备可能会使 用不不同的发现流程, 下 面以查找对 方设备的 GATT 服务为例例介绍 一下 ESP32 IDF 使 用的服务发现过程 : 首先发现对 方所有的 Service 信息, 包括 Service 的 UUID 和 Handle 范围 - GATT Service,UUID 0x1801,Handles 0x0001~0x GAP Service,UUID 0x1800,Handles 0x0014~0x001C 然后在 GATT 的 Handle 范围内 (0x0001~0x0005), 继续查找所有的特性 (0x2803) - 找到特性 "Service Change Characteristic,Handles 0x0002~0x 其中 0x0002 对应的是这个特性的特性声明 - 其中 0x0003 对应的是这个特性的特性值 - 所以每个特性 至少需要占据 2 个 Handle 的属性 既然 GATT Service 的 Handles 范围是 0x0001~0x0005, 所以在 0x0003 后 面可能跟有相应的描述符, 因此继续从 0x0004 开始查找所有的描述符 - 其中 0x0004 对应的是 Client Characteristic Configuration 描述符 - 其中 0x0005 暂时没有任何信息, 可能是为这个 Service 预留留的 Handle Espressif 26/31

31 3. 蓝 牙低功耗 至此,GATT Service 的所有信息发现完毕 3.3. SMP 本章节主要描述 ESP32 BLE 安全管理理接 口 API 的实现和使 用流程 概述 ESP32 BLE 安全管理理协议 (SMP) 相关 API 已封装在 BLE GAP 模块中, 以供应 用程序进 行行调 用 安全管理理协议可以 用于 生成加密密钥和身份密钥, 定义了了 一套简单的匹配和密钥分发协议, 允许协议栈的其他层与其他设备进 行行安全链接并交换数据 这需要 一个链路路层链接, 并对这个特定的链接有安全需求 BLE 安全管理理器器允许两个设备通过设置安全级别对该链路路进 行行加密 此流程可以参考 蓝 牙核 心规范 4.2 版本 (Bluetooth Core Specification version 4.2) 中对安全管理理章节的相关描述 为了了清楚介绍 BLE 安全管理理模块的实现过程, 这 里里需要 首先解释 几个关键概念 : 配对 (Pairing): 指两个设备同意双 方建 立 一定级别的安全性连接 绑定 (Bonding): 指 至少 一个设备向另 一个设备发送某种识别或安全信息, 供将来的连接使 用 这些识别或安全信息可能是加密密钥 (LTK) 签名密钥 (CSRK) 或地址解析密钥 (IRK) 如果两个设备都可以绑定, 则配对后会进 行行密钥分配, 否则不不会交换绑定信息 如果发送任何绑定信息, 则违反协议 配对可能发 生 而不不 一定需要绑定, 但在配对期间, 两个设备需要通过交换特征确定对 方是否 支持绑定 如果两个设备都不不 支持绑定, 则不不应存储对 方设备的相关安全信息 认证 (Authentication): 不不认证 (Unauthentication) 并不不意味着链路路不不具备任何安全性, 而是没有安全性和认证安全级别之间的中间级别 当 用于链路路加密的密钥具有需要双 方设备确认的安全属性时, 两个设备之间的关系称为认证 在使 用短期密钥 (STK) 方法 生成的功能下, 这种安全属性在配对过程中被赋予了了 一个关键字 对于具有输 入 / 输出和 OOB 方法的设备, 之后产 生和交换的所有密钥都具有认证 (MITM) 属性 ( 使 用 PIN/ 较 大的 OOB 密钥, 这将强制执 行行安全性 ) 如果使 用 Just Works 方法, 所有密钥将具有未验证 (No MITM) 属性 授权 (Authorization): 这是来 自应 用层的执 行行操作的许可 一些程序可能需要授权, 在这种情况下, 应 用程被要求授权 如果没有给出授权, 则该过程将失败 BLE 安全管理理控制器器 BLE 加密流程 BLE 加密流程分为两部分 : Espressif 27/31

32 3. 蓝 牙低功耗 当两个 BLE 设备之间未进 行行过绑定时, 两个设备间将会通过配对步骤进 行行加密, 并根据配对时的信息决定是否需要进 行行绑定 ; 当两个设备已经进 行行过绑定, 一 方设备想跟另 一 方进 行行加密时会直接 走绑定流程 Just work 模式下,Master 主动发起加密请求的流程图如下 : Master Slave API SMP SMP API esp_ble_set_encryption SMP_PAIR_REQ ESP_GAP_BLE_SEC_RE Q_EVT esp_ble_gap_security_rsp SMP_PAIR_RSP Encrypt ESP_GAP_BLE_AUTH_CMP L_EVT ESP_GAP_BLE_AUTH_CM PL_EVT 图 3-6. Just Work 加密流程图 Espressif 28/31

33 3. 蓝 牙低功耗 Passkey notify 模式下,Master 主动发起加密请求的流程图如下 : Master Slave API SMP SMP API esp_ble_set_encryption SMP_PAIR_REQ ESP_GAP_BLE_SEC_RE Q_EVT ESP_GAP_BLE_PASSKEY_ NOTIF_EVT Display the pass key to the user, the peer device should enter this key and sent it to the SMP stack SMP_PAIR_RSP esp_ble_gap_security_rsp esp_ble_passkey_reply Sent the pass key to the SMP stack which is display in the peer device Encrypt ESP_GAP_BLE_AUTH_CMP L_EVT ESP_GAP_BLE_AUTH_CM PL_EVT 图 3-7. Passkey Notify 加密流程图 Espressif 29/31

34 3. 蓝 牙低功耗 BLE 绑定流程两个 BLE 设备间的绑定是通过调 用 GAP 中的 API 实现的 根据蓝 牙核 心规范中的描述, 绑定的 目的是为了了两个 BLE 设备在进 行行 SMP 加密后, 再进 行行重连时能够使 用相同的密钥对链路路进 行行加密, 从 而能简化两个设备再连接时的加密流程 其中, 两个 BLE 设备会在配对过程中交换加密密钥, 并存储起来以便便 长期使 用 绑定状态图如下 : esp_ble_set_encrypti on API SMP LLC LLC SMP API 判断是否已经跟对端设备绑定 (bonding), 如果已经绑定 LLC_START_ENC_CMD LLC_LTK_REQ_EV T LLC_LTK_REQ_RE PLY_CMD Enctrypt LLC_ENC_CHANGE_EVT LLC_ENC_CHANG E_EVT ESP_GAP_BLE_AUT H_CMPL_EVT ESP_GAP_BLE_AUT H_CMPL_EVT 图 3-8. BLE 设备的绑定流程图 注意 : 绑定必须由主设备 (master) 在连接时发起 BLE 安全管理理实现机制 BLE 安全管理理是采 用调 用 BLE GAP 的 API 相关的加密函数, 注册 BLE GAP callback, 并 通过事件返回获取当前的加密状态 Espressif 30/31

35 免责申明和版权公告本 文中的信息, 包括供参考的 URL 地址, 如有变更更, 恕不不另 行行通知 文档 按现状 提供, 不不负任何担保责任, 包括对适销性 适 用于特定 用途或 非侵权性的任何担保, 和任何提案 规格或样品在他处提到的任何担保 本 文档不不负任何责任, 包括使 用本 文档内信息产 生的侵犯任何专利利权 行行为的责任 本 文档在此未以禁 止反 言或其他 方式授予任何知识产权使 用许可, 不不管是明示许可还是暗示许可 Wi-Fi 联盟成员标志归 Wi-Fi 联盟所有 蓝 牙标志是 Bluetooth SIG 的注册商标 乐鑫 IoT 团队 文中提到的所有商标名称 商标和注册商标均属其各 自所有者的财产, 特此声 明 版权归 2017 乐鑫所有 保留留所有权利利