从喊话到私聊：蓝牙低功耗通信技术原理
声明：
本文内容基于蓝牙技术联盟（Bluetooth SIG）公开发布的《蓝牙核心规范》。文中涉及的“典型设计”、“常见做法”为嵌入式与物联网行业公开的通用工程实践，不代表任何特定产品的私有实现，不构成产品规格或商业秘密泄露。本文非 SIG 官方文档，仅供科普学习，按现状（AS‑IS）提供。
引子：先看全景，一次完整的蓝牙通信长什么样
你拿出车钥匙按一下，门开了。
钥匙怎么知道车在哪？车怎么知道是自家钥匙？中间发生了什么？
整个过程是这样的：
钥匙平时在休眠。你按键，它醒了，开始喊：“有没有车要找我？”车一直竖着耳朵听，听到后回应：“听到了，我们单独聊。”于是双方建立一条私聊通道。通道通了，再对一下暗号，确认对面是正主。暗号对上了，你按的那个指令才执行。事情办完，断开连接，钥匙继续休眠。
就这几步：唤醒→喊话→听见→私聊→对暗号→执行→断开→休眠。
下面拆开讲。
一、低功耗设计（Bluetooth Low Energy / Advertising Interval / Connection Interval）
1.1 为什么要“睡觉”
钥匙平时在睡觉。
“睡觉”的意思是：蓝牙全部关掉——不广播、不连接、不收发数据，只有一颗超低功耗的传感器还在监听着外部动静。整机电流降到微安级。
为什么必须这样？纽扣电池容量有限。如果蓝牙射频持续工作，电流在毫安级别，几天就没电。要让设备能用上数年，必须在99%以上的时间里处于休眠状态，只在必要的时候醒来干活，干完立刻回去睡。
这是蓝牙低功耗（Bluetooth Low Energy）这个名字的根本含义——“低功耗”不是营销词，而是从物理层到应用层贯穿始终的设计原则。
1.2 休眠与唤醒
进入休眠态时，蓝牙射频全部关闭。不广播、不扫描、不连接、不处理任何通信事务。只有唤醒检测电路保持工作。
仅由按键触发唤醒。
为什么不做运动唤醒？设备放在口袋里，走路、弯腰、坐下都会产生加速度变化。如果用运动传感器唤醒，一天内可能误唤醒数百次，电池撑不住。只有按键按下，才是明确的“用户正在使用”信号。
有些设计还做了进一步防误触：短按不生效，必须持续按住一定时长，或两个按键同时按下才能唤醒。
1.3 广播间隔
设备被唤醒后进入广播态，开始发送广播包。
广播不是持续发射——设备发送一个广播包后，关闭射频进入短暂休眠，等待下一个广播时刻到来再发送下一个。两个连续广播事件开始之间的时间，称为广播间隔（Advertising Interval） 。
广播间隔的本质是功耗与响应速度之间的取舍：
| 间隔 | 效果 |
|---|---|
| 短 | 单位时间内广播次数多，扫描方更快发现，响应快，但平均功耗高 |
| 长 | 单位时间内广播次数少，功耗低，但扫描方发现设备需要更长等待时间 |
设备在不同阶段使用不同的广播间隔。需要快速响应时使用短间隔，不急于被发现时使用长间隔以降低功耗，电池电量低时自动延长间隔以延长剩余续航。
1.4 连接间隔
连接建立后，通信以连接事件（Connection Event） 为单位进行。每个连接事件中，双方同时醒来，在约定的数据信道上交换数据包，交换完成后各自回到休眠状态，直到下一个连接事件到来。
两个连续连接事件开始之间的时间，称为连接间隔（Connection Interval） 。
蓝牙规范定义连接间隔的范围为7.5毫秒到4秒。间隔越短，数据吞吐量越大、响应越快，但平均功耗越高。间隔越长，功耗越低，但数据延迟增加。
典型设计支持动态调整连接间隔：有频繁数据交换时使用短间隔；长时间无数据交换时拉长间隔；空闲超时后主动断开连接。
1.5 功耗管理的本质
广播间隔和连接间隔的调整，本质上是控制射频工作时间占总时间的比例——也就是占空比（Duty Cycle） 。
占空比越低，平均功耗越低。BLE之所以能实现微安级平均功耗，核心机制就是在所有非必要的时间里让设备处于休眠状态，只在约定的短暂窗口内开启射频。
二、物理信道与协议栈（Physical Channel / GAP / GATT / L2CAP / ATT）
2.1 ISM频段
蓝牙低功耗工作在2.4GHz ISM频段。
ISM（Industrial, Scientific and Medical，工业、科学和医疗）频段是国际电信联盟无线电通信部门（ITU-R）在全球范围内划定的、允许工业、科学研究和医疗设备免费使用的无线电频段。2.4GHz频段覆盖范围为2.400GHz到2.4835GHz，总带宽83.5MHz，全球通用，无需申请许可证。
免费使用的代价是拥挤。Wi-Fi、ZigBee、蓝牙、微波炉都在这个频段上工作，设备之间必须通过技术手段在共享频段中共存。
2.2 信道划分
BLE将2.4GHz频段划分为40个物理信道，每个信道宽度2MHz，按中心频率编号0到39。
这40个信道分为两类：
3个广播信道（Advertising Channels）：
| 信道编号 | 中心频率 |
|---|---|
| 37 | 2402 MHz |
| 38 | 2426 MHz |
| 39 | 2480 MHz |
三个广播信道在频段中呈分散分布——低端、中部、高端各一个。这样设计是为了避免三个广播信道同时被Wi-Fi信号干扰。Wi-Fi信道通常占据频段的中部或特定位置，分散布局确保至少有一个广播信道可以避开干扰正常工作。
37个数据信道（Data Channels）：
编号0到36，覆盖2404MHz到2478MHz范围，用于连接建立后的数据传输。
2.3 广播信道的工作方式
设备在广播态时，在每个广播事件中依次在三个广播信道上发送相同的广播包。
一个广播事件的典型发送序列为：在信道37上发送一个广播包，然后切换到信道38发送，再切换到信道39发送。三个信道发送完毕后，该广播事件结束。下一个广播事件重新从信道37开始。
需要注意的是：如果广播者在广播事件中途收到了连接请求（CONNECT_REQ），该广播事件会立即终止，不再继续发送剩余信道的广播包。
为什么在三个信道上都发一遍？因为扫描方可能在任何信道上监听。扫描方在三个广播信道之间轮流切换监听，广播方在三个信道上轮流发送，双方只要在同一个信道、同一个时间点上匹配，就能完成一次广播接收。
2.4 数据信道与跳频
连接建立后，通信切换到37个数据信道。数据通信采用自适应跳频（Adaptive Frequency Hopping，AFH） 。
跳频的基本过程：
- 主设备和从设备在连接建立时，通过CONNECT_REQ中的参数约定跳频序列的生成算法和初始种子
- 每次连接事件开始时，双方独立使用相同算法计算出当前要使用的信道编号
- 双方在同一时间切换到同一信道，完成数据交换
- 下一个连接事件，双方计算下一个信道，继续跳转
跳频解决两个问题：
第一，抗干扰。 2.4GHz频段拥挤，Wi-Fi等设备会产生突发性干扰。跳频让通信在37个信道之间不断切换，某个信道被干扰时，通信可以迅速跳到其他信道继续。
第二，安全性。 跳频使攻击者无法预测下一包在哪个信道上出现。
2.5 协议栈分层架构
蓝牙协议栈采用严格的分层架构。每一层有明确的职责边界，下层对上层提供标准服务接口。
| 层级 | 名称 | 职责 |
|---|---|---|
| 第1层 | 物理层（PHY） | 调制/解调，将比特流转换为无线信号 |
| 第2层 | 链路层（LL） | 设备地址管理、广播/数据PDU的组装与解析、自动重传、链路层加密 |
| 第3层（Host） | L2CAP | 协议复用、数据分包与重组、流控 |
| 第3层（Host） | ATT | 属性协议，定义客户端-服务器模型下的属性读写操作 |
| 第3层（Host） | GAP | 广播、扫描、连接、配对流程管理 |
| 第3层（Host） | GATT | 基于ATT的服务框架，定义特征值和服务的数据组织方式 |
| 第3层（Host） | SM | 安全管理，配对流程、密钥生成与分发 |
2.6 GAP层
GAP（Generic Access Profile，通用访问规范）是BLE设备发现和连接管理的核心层。
GAP定义了四种设备角色：
| 角色 | 行为 |
|---|---|
| 广播者（Broadcaster） | 只发送广播，不接收连接 |
| 观察者（Observer） | 只接收广播，不发起连接 |
| 外围设备（Peripheral） | 可广播且可被连接 |
| 中心设备（Central） | 可扫描、可发起连接 |
在典型的钥匙-车辆场景中，钥匙端作为外围设备向外广播，车辆端作为中心设备执行扫描并发起连接。
2.7 GATT层
GATT（Generic Attribute Profile，通用属性配置）定义了连接建立后的数据交互方式。
GATT的核心概念：
- 服务（Service）： 一组相关特征的集合，代表一个完整的逻辑功能模块
- 特征值（Characteristic）： 数据交互的最小单元，包含一个值和零个或多个描述符
- 描述符（Descriptor）： 描述特征值的附加属性
在实际产品设计中，可以定义一个128位UUID的专有服务，包含两个特征值：一个用于指令下发，一个用于响应上报和通知。
GAP管“怎么连上”，GATT管“连上后怎么传数据”。两者在协议栈中处于同一层级，职责分离。
三、广播与扫描（Advertising / Scanning / ADV_IND / ADV_NONCONN_IND）
3.1 广播态与扫描态
设备唤醒后进入广播态，开始在三个广播信道上按顺序发送广播PDU。
广播态的核心行为：设备周期性发送广播PDU，在两个广播事件之间进入短暂休眠以降低功耗。
扫描设备处于扫描态，在三个广播信道上按顺序轮流监听。
扫描分两种模式：
- 被动扫描（Passive Scanning）： 只接收广播PDU，不发送任何请求
- 主动扫描（Active Scanning）： 收到广播PDU后，向广播者发送SCAN_REQ（扫描请求），广播者收到后用SCAN_RSP（扫描响应）回复额外数据
典型设计中，扫描方使用主动扫描以获取完整的广播数据。
3.2 广播PDU类型
蓝牙规范为广播信道定义了多种PDU类型。常用的两种是：
ADV_IND：可连接可扫描非定向广播。
ADV_IND是最通用的广播PDU。它表示广播者可以被连接，同时也会响应SCAN_REQ。扫描方收到ADV_IND后，可以发送SCAN_REQ请求更多数据，也可以发送CONNECT_REQ建立连接。
ADV_NONCONN_IND：不可连接不可扫描非定向广播。
ADV_NONCONN_IND表示广播者只发送信号，不接受连接请求，也不响应SCAN_REQ。这种类型的特征是效率最高——广播者不需要为任何响应预留时间。
这两种PDU类型可以根据不同业务场景选用。
3.3 广播数据格式
广播数据由一个或多个AD Structure组成。每个AD Structure遵循LTV（Length-Type-Value）格式：
- Length（1字节）： AD Type和AD Data的总字节数
- AD Type（1字节）： 数据类型标识，由蓝牙核心规范补充（Core Specification Supplement）定义
- AD Data（Length-1字节）： 具体数据载荷
常见的AD Type值包括：
| AD Type | 含义 |
|---|---|
| 0x01 | Flags（设备发现模式、LE能力标志） |
| 0x03 | Complete List of 16-bit Service UUIDs |
| 0x09 | Complete Local Name（完整设备本地名称） |
| 0xFF | Manufacturer Specific Data（制造商自定义数据） |
关于AD Type 0xFF（Manufacturer Specific Data）：
这是蓝牙核心规范中预留的厂商自定义数据类型。当AD Type为0xFF时，AD Data的前两个字节为Company ID（由蓝牙SIG分配的厂商ID），后续字节由厂商自行定义。微信的AirSync协议、iBeacon协议等都利用这个字段承载自定义数据。
接收方通过检查AD Type和Company ID来识别广播来源。
3.4 广播间隔的实现机制
广播间隔是连续两个广播事件开始之间的时间。
一个广播事件指：在三个广播信道上依次发送所有广播PDU的过程。对于ADV_IND，一个广播事件包含三个广播包的发送，分别位于信道37、38、39。
广播间隔由链路层定时器控制。在每个广播事件结束后，链路层启动一个计数器，计数器溢出后触发下一个广播事件的开始。
3.5 地址类型
广播PDU中包含发送方的蓝牙设备地址。蓝牙规范定义了多种地址类型，典型设计使用以下两种：
静态地址（Static Address）：
设备初始化时随机生成一个48位地址，存储于非易失存储器中。设备生命周期内保持不变。
特征：长期稳定，便于对方设备识别和绑定。缺点是可能被用于位置跟踪。
可解析随机私有地址（Resolvable Private Address，RPA）：
由设备定时更新——通常每15分钟或每次连接断开后更换。RPA由24位哈希和24位prand组成。其中prand的低22位为随机数，最高2位为地址类型标志。只有持有正确IRK（Identity Resolving Key）的设备才能将RPA解析为设备真实身份。
特征：无法被不具备IRK的设备识别，无法用于长期位置跟踪。
四、连接与加密（Connection / LTK / LE‑ACL）
4.1 连接发起
扫描方收到ADV_IND后，在同一个广播信道上发送CONNECT_REQ（连接请求）。收到CONNECT_REQ后，广播者立即终止当前广播事件，双方同时进入连接态。
CONNECT_REQ中包含建立连接所需的关键参数：
- 接入地址（Access Address）： 一个32位的随机值，用于在数据信道中唯一标识该连接
- 跳频算法参数： 包括跳频序列的初始种子和信道映射表
- 连接间隔： 连接事件发生的时间间隔
- 从设备延迟： 从设备可以跳过不响应的最大连接事件数
- 超时时间： 连接丢失的判定阈值
- 信道映射： 标记37个数据信道中哪些可用、哪些不可用
连接建立后，广播者停止广播。
4.2 连接事件与连接间隔
连接态中的通信以连接事件（Connection Event）为单位。
连接事件的定义：主设备和从设备在约定的时间点同时从休眠中醒来，切换到约定的数据信道，交换数据包。一个连接事件中可以包含多个数据包的往返。
每个连接事件开始时，主设备发送一个数据包，从设备在约定时间后回复。如果主设备没有数据要发送，可以发送空包以维持连接。如果从设备没有数据要发送，可以跳过该连接事件（受从设备延迟参数限制）。
连接间隔的选择涉及三个方面的权衡：
| 连接间隔 | 功耗 | 响应延迟 | 数据吞吐量 |
|---|---|---|---|
| 短 | 高 | 低 | 高 |
| 长 | 低 | 高 | 低 |
4.3 从设备延迟
从设备延迟（Slave Latency）是BLE另一个关键的省电参数。
定义：从设备在没有数据需要发送的情况下，可以跳过不响应的最大连续连接事件数量。
这个机制让从设备在空闲时进一步降低功耗——它不需要在每个连接事件中都醒来，可以连续跳过多个连接事件，继续保持睡眠。
4.4 LE数据连接
BLE连接建立后，通信使用LE-ACL逻辑传输。所有指令、响应和通知均通过LE-ACL承载。
LE-ACL是异步传输，支持数据包重传，不保证固定时延，但保证可靠交付。
4.5 LTK生成机制
连接建立时，双方执行蓝牙安全配对流程。
配对流程包含三个阶段：
阶段1：配对能力交换（Pairing Feature Exchange）
双方交换I/O能力、认证需求、密钥分发需求。
阶段2：密钥生成（Key Generation）
基于阶段1交换的信息，使用椭圆曲线密钥协商协议（ECDH）或标准密钥协商方法生成临时密钥和短期密钥。LE安全连接（LE Secure Connections）使用ECDH生成单次密钥，不依赖临时密钥（TK）或短期密钥（STK）。
阶段3：密钥分发（Key Distribution）
完成认证后，双方分发用于后续加密连接的密钥：
- LTK（Long Term Key，长期密钥）： 128位密钥，用于加密连接后的所有数据包
- IRK（Identity Resolving Key，身份解析密钥）： 用于解析RPA地址
- CSRK（Connection Signature Resolving Key，连接签名解析密钥）： 用于数据签名和验证
配对完成后，LTK存储于双方设备的非易失存储器中。
4.6 链路层加密
LTK由链路层管理，对上层完全透明。
当上层有数据要发送时，数据直接交给链路层。链路层使用当前链路层会话密钥对数据包进行加密，然后通过物理层发送。接收端链路层收到后自动解密，将明文数据交给上层。
加密使用AES-CCM算法，这是一个结合了加密和消息完整性校验的组合模式。AES-CCM使用128位密钥，在加密数据的同时生成消息完整性检查码（MIC），确保数据既有机密性也有完整性。
五、认证（Authentication / Challenge-Response）
5.1 为什么需要应用层认证
LTK保护的是通信通道的机密性和完整性——它确保通道里的数据不被窃听、不被篡改。
但LTK不解决身份问题。任何设备都可以与设备建立蓝牙连接并协商LTK，因为BLE的链路层加密不验证对方设备的应用层身份。
所以，在LTK保护的通道之上，还需要一层应用层认证（Application Layer Authentication） ，确认通信对端的合法身份。
5.2 挑战-响应机制
应用层认证采用挑战-响应（Challenge-Response） 机制。这是一种标准的身份验证方法，在物联网和嵌入式设备认证中被广泛使用——验证方证明自己持有正确的密钥材料，而不需要在通道上直接传输密钥。
认证流程的基本逻辑如下：
- 验证方生成一个随机数（挑战值），通过加密通道发送给被验证方
- 被验证方收到随机数后，用内部存储的密钥材料在安全硬件中进行计算，将计算结果连同自己的随机数一起发回
- 验证方用自己存储的密钥材料进行同样的计算
- 比对双方的计算结果，一致则认证通过，不一致则断开连接
关键安全属性：
- 真正的密钥材料从未在通道上传输
- 通道上传输的只有随机数和计算结果
- 即使攻击者捕获了完整的认证流程数据包，也无法推导出密钥材料
- 每次认证使用新的随机数，防止重放攻击
5.3 安全硬件隔离
密钥存储和加密计算在安全硬件（Secure Element / Hardware Security Module）中进行。
安全硬件的安全属性：
- 隔离执行： 加密计算在安全硬件内部完成，主CPU无法读取内部状态或中间结果
- 密钥保护： 密钥存储在安全硬件的非易失存储器中，外部总线不可访问
- 物理防篡改： 安全硬件具有物理防护层
- 防侧信道攻击： 安全硬件的加密操作设计为恒定时间执行
应用层软件只调用安全硬件接口，不接触密钥本身。
5.4 认证模式
典型的系统设计根据业务场景定义多种认证模式：
标准认证模式： 仅验证身份，不改变任何存储内容。用于日常使用。
建立模式： 用于首次建立信任关系。认证通过后，被验证方写入密钥材料，状态从未建立切换为已建立。
强制模式： 用于特殊情况（如对端模块更换导致原有密钥信息丢失）。强制覆盖写入新密钥。若流程中途失败，原有密钥材料必须保留。
六、指令交互（Command / Response / TLV / CRC16）
6.1 请求-响应模型
认证通过后，双方进入指令交互阶段。
指令交互采用请求-响应（Request-Response） 模型：
- 请求方发送指令
- 响应方执行指令并返回结果
- 每个请求必须对应一个响应
如果请求方在预设时间内没有收到响应，做超时处理。
6.2 应用层协议框架
在GATT提供的通用数据通道之上，应用层可以定义自己的协议框架来组织数据。
典型的自定义协议框架包含：
- 帧结构： 包含帧起始标志、长度字段、控制字段、序号字段和载荷
- 控制字段： 包含分包标识、同步/异步模式标志、加密标志和方向标志
- 载荷格式： 采用TLV（Tag-Length-Value）格式组织数据
帧结构的设计要点：
- 分包标识用于支持大消息拆分：消息长度超过单帧承载能力时，拆分为起始包、中间包和结束包
- 序号字段用于接收方按正确顺序重组分片
- 同步模式下接收方必须立即返回响应；异步模式下接收方可以先回复确认，后续再单独发送执行结果
- 加密标志控制载荷是否使用应用层会话密钥加密
6.3 TLV格式与CRC校验
载荷的TLV格式：
- Tag（标签）： 标识数据类型
- Length（长度）： Value的字节数
- Value（值）： 具体数据
多个TLV单元可以拼接在同一个载荷中。
TLV格式的好处：
- 可扩展： 新增数据类型只需定义新Tag
- 自描述： 接收方通过Tag即可识别数据含义
- 灵活： 不同TLV单元的排列顺序不受限制
典型设计在帧尾部附加校验字段，对帧头+载荷进行CRC16校验（CCITT标准多项式）。
接收方收到帧后，首先计算帧头+载荷的CRC16，与帧中的校验字段比对。不匹配则判定为传输错误，丢弃该帧。
CRC16可以检测单比特错误和大部分突发错误。
七、安全机制（RPA / Replay Attack / Whitelist / IRK / CSRK）
7.1 RPA地址更新机制
可解析随机私有地址（RPA）的生成和解析基于IRK。
RPA的生成逻辑：
- prand为24位字段：低22位为随机数，最高2位为地址类型标志
- 使用ah()函数（基于AES-CMAC-128算法），以IRK为密钥，对prand进行计算
- 取计算结果的前24位作为哈希值
- RPA = 24位哈希 + 24位prand，共48位
RPA的解析逻辑：
- 从RPA中提取prand（24位）
- 使用同样的ah()函数计算期望哈希值
- 比对期望哈希值与RPA中的哈希值，一致则解析成功
只有持有正确IRK的设备才能将RPA解析为设备真实身份。
7.2 防重放攻击
重放攻击（Replay Attack） 的基本原理：攻击者录下合法设备发送的指令信号，在合法设备离开后将录下的信号重新发射出去。
典型设计中，每条关键指令携带一个严格递增的序号。接收方维护最后接收序号：
- 发送端每次发送指令时序号+1
- 接收端收到指令后检查序号：如果序号小于或等于最后接收序号，判定为重放攻击，丢弃该指令
- 序号在每次连接开始时重置
7.3 白名单过滤
白名单是验证方维护的一个认证设备列表，存储所有已建立信任关系的设备身份标识。
白名单可以在链路层和应用层同时生效：
- 链路层：扫描过滤只响应白名单内设备地址的广播
- 应用层：认证阶段不在白名单中的设备直接拒绝
白名单管理：建立模式下将设备加入白名单；通过管理端删除设备时将设备从白名单中移除。
八、功耗与容错（Dynamic Interval / OTA A/B Partition）
8.1 广播间隔的动态调整
广播间隔可以根据设备状态自动调整：
- 正常广播态：使用当前阶段对应的预设间隔
- 低电量态：自动延长至更长间隔以延长续航
- 过渡态：使用较短的间隔以确保连接建立成功
调整由链路层根据上层指令自动完成。
8.2 连接间隔的动态调整
连接间隔在连接态期间根据数据活跃度动态调整：
- 有频繁数据交换时使用短间隔，保证吞吐量和响应速度
- 长时间无数据交换时逐步拉长间隔，降低功耗
- 超过空闲阈值后主动断开连接
连接间隔更新可以通过链路层或L2CAP层完成，具体方式取决于蓝牙版本。
8.3 多级功耗管理
典型系统设计实现多级功耗管理策略，在不同状态下使用不同的功耗参数：
- 正常工作：使用默认参数
- 短时空闲：延长广播间隔或连接间隔
- 长时间空闲：主动断开连接
- 低电量：强制延长广播间隔，禁用非必要功能
各级之间通过定时器或外部条件自动切换。
8.4 连接超时与丢失处理
链路层维护一个连接超时定时器。在超时时间内没有收到任何数据包，链路层判定连接已丢失，退出连接状态回到待机。
连接丢失后，设备重新进入广播态。
8.5 固件升级与容错
固件升级采用A/B双分区设计，也称为乒乓升级（Ping-pong Update） 。设备内部有两个独立的存储分区：
- A区： 当前运行版本
- B区： 备用分区
升级流程：
- 通过无线连接将新固件分包传输至设备
- 接收并写入B区，每个分包进行校验
- 完整固件接收完成后进行整体完整性校验
- 校验通过后，将启动标志切换至B区
- 设备复位，从B区启动运行新固件
升级过程中的容错保障：
- 如果升级流程在任何阶段失败，系统自动切回A区原有版本
- 原有版本完好，设备继续正常工作
这种设计的核心优势是“升级不中断、失败可回滚”。
结语
从广播发现到连接建立，从链路加密到应用认证，从指令交互到功耗管理，这套体系围绕两个核心目标设计：
省电——设备靠电池供电。休眠机制、动态广播间隔、动态连接间隔、多级功耗管理，每一层都把功耗压到最低。
安全——不能让外人冒充、偷听、重放。LTK链路加密、应用层挑战-响应认证、序号防重放、RPA防跟踪、白名单过滤、安全硬件隔离，构成多层防御。
这八个部分构成了完整的通信框架：休眠 → 唤醒 → 广播 → 扫描 → 连接 → 链路加密 → 应用认证 → 指令交互 → 断开 → 回到低功耗。
附录
附录A：蓝牙广播数据格式参考
广播数据由一个或多个AD Structure组成。
AD Structure格式：
| 字段 | 长度 | 说明 |
|---|---|---|
| Length | 1字节 | AD Type + AD Data的总长度 |
| AD Type | 1字节 | 数据类型 |
| AD Data | Length-1字节 | 具体数据 |
常用AD Type值：
| AD Type值 | 名称 | 用途 |
|---|---|---|
| 0x01 | Flags | 设备发现模式、LE能力标志 |
| 0x03 | Complete List of 16-bit Service UUIDs | 完整16位服务UUID列表 |
| 0x09 | Complete Local Name | 设备完整本地名称 |
| 0x16 | Service Data - 16-bit UUID | 16位UUID对应的服务数据 |
| 0xFF | Manufacturer Specific Data | 厂商自定义数据 |
Manufacturer Specific Data（0xFF）格式：
| 字段 | 长度 | 说明 |
|---|---|---|
| Company ID | 2字节 | 由蓝牙SIG分配的厂商ID |
| Manufacturer Data | 可变 | 厂商自定义 |
附录B：蓝牙ATT协议参考
ATT（Attribute Protocol）PDU格式：
| 字段 | 长度 | 说明 |
|---|---|---|
| Opcode | 1字节 | 操作方法 |
| Attribute Parameters | 可变 | 由Opcode决定 |
| Authentication Signature | 可选 | 13字节 |
常用ATT Opcode类型：
| Opcode值 | 名称 | 用途 |
|---|---|---|
| 0x02 | Exchange MTU Request | 交换MTU大小 |
| 0x03 | Exchange MTU Response | 交换MTU响应 |
| 0x04 | Find Information Request | 查找信息请求 |
| 0x08 | Read By Type Request | 按类型读请求 |
| 0x09 | Read By Type Response | 按类型读响应 |
| 0x0A | Read Request | 读请求 |
| 0x0B | Read Response | 读响应 |
| 0x12 | Write Request | 写请求 |
| 0x13 | Write Response | 写响应 |
| 0x1B | Handle Value Notification | 句柄值通知 |
| 0x1D | Handle Value Indication | 句柄值指示 |
附录C：蓝牙L2CAP与CID参考
主要固定信道ID（CID）：
| CID值 | 用途 |
|---|---|
| 0x0004 | ATT协议 |
| 0x0005 | L2CAP信令 |
| 0x0006 | 安全管理（SM） |
| 0x0007 | 安全管理信令（LE） |
附录D：BLE空口包结构参考
广播信道PDU头部PDU Type：
| PDU Type值 | 名称 | 说明 |
|---|---|---|
| 0x00 | ADV_IND | 可连接可扫描非定向广播 |
| 0x01 | ADV_DIRECT_IND | 可连接定向广播 |
| 0x02 | ADV_NONCONN_IND | 不可连接不可扫描非定向广播 |
| 0x03 | SCAN_REQ | 扫描请求 |
| 0x04 | SCAN_RSP | 扫描响应 |
| 0x05 | CONNECT_REQ | 连接请求 |
完整空口包格式（1M PHY）：
| 字段 | 长度 | 说明 |
|---|---|---|
| Preamble | 1字节 | 前导码，用于接收端时钟同步 |
| Access Address | 4字节 | 广播包固定值，数据包由CONNECT_REQ指定 |
| PDU | 2-257字节 | 广播信道PDU或数据信道PDU |
| CRC | 3字节 | 24位CRC校验值 |
以上格式均为蓝牙核心规范（Bluetooth Core Specification）公开定义。具体实现中的字段长度、端序等细节请参考蓝牙核心规范和对应芯片的技术手册。
-----------------------------------------------------
📝 全部笔记托管于 GitHub，后续更新优先同步本仓。
📌 如有疏漏，欢迎指正。
🔗 GitHub仓库：kyshipit/tech-notes
-----------------------------------------------------
