很多开发者对BLE广播的理解停留在"设备往外发数据包"这个层面,但当你翻开蓝牙核心规范(Bluetooth Core Specification)的链路层(Link Layer)章节,会发现广播态(Advertising State)远比想象中复杂。尤其在蓝牙5.4中,广播态的能力被进一步扩展。
今天,我们就从链路层状态机的角度,把不可连接状态--广播态的每一个细节掰开揉碎讲清楚。
目录
[1. 链路层状态机:广播态的位置](#1. 链路层状态机:广播态的位置)
[2. 广播态的核心分类维度](#2. 广播态的核心分类维度)
[3. 四类标准广播模式](#3. 四类标准广播模式)
[4. 广播信道索引](#4. 广播信道索引)
[4.1 广播信道索引的两种选择方式](#4.1 广播信道索引的两种选择方式)
[4.2 信道映射(Advertising_Channel_Map)](#4.2 信道映射(Advertising_Channel_Map))
[5. 广播事件](#5. 广播事件)
[5.1 什么是广播事件?](#5.1 什么是广播事件?)
[5.2 广播事件的时序](#5.2 广播事件的时序)
[5.3 广播事件的PDU交互](#5.3 广播事件的PDU交互)
[5.4 拓展广播事件](#5.4 拓展广播事件)
[5.4.1 为什么需要拓展广播?](#5.4.1 为什么需要拓展广播?)
[5.4.2 主广播信道与次广播信道](#5.4.2 主广播信道与次广播信道)
[5.4.3 扩展广播的工作机制](#5.4.3 扩展广播的工作机制)
[5.4.4 扩展广播的PDU类型](#5.4.4 扩展广播的PDU类型)
[5.4.5 容量提升](#5.4.5 容量提升)
[5.5 周期广播事件](#5.5 周期广播事件)
[5.5.1 什么是周期性广播?](#5.5.1 什么是周期性广播?)
[5.5.2 为什么需要周期性广播?](#5.5.2 为什么需要周期性广播?)
[5.5.3 周期性广播的工作机制](#5.5.3 周期性广播的工作机制)
[5.5.4 周期性广播的PDU类型](#5.5.4 周期性广播的PDU类型)
[5.5.5 周期性广播的关键参数](#5.5.5 周期性广播的关键参数)
[5.6 带响应的周期性广播(PAwR)事件](#5.6 带响应的周期性广播(PAwR)事件)
[5.6.1 PAwR在逻辑传输层的定位](#5.6.1 PAwR在逻辑传输层的定位)
[5.6.2 PAwR的事件结构](#5.6.2 PAwR的事件结构)
[5.6.2.1 子事件](#5.6.2.1 子事件)
[5.6.2.2 响应时隙(Response Slot)](#5.6.2.2 响应时隙(Response Slot))
[5.6.2.3 三级结构的容量计算](#5.6.2.3 三级结构的容量计算)
[5.6.3 PAwR的关键时序参数](#5.6.3 PAwR的关键时序参数)
[5.6.4 PAwR的同步机制](#5.6.4 PAwR的同步机制)
[方式一:通过扩展广播同步(Primary Advertising)](#方式一:通过扩展广播同步(Primary Advertising))
[方式二:通过PAST(Periodic Advertising Sync Transfer)](#方式二:通过PAST(Periodic Advertising Sync Transfer))
[5.6.5 PAwR的功耗优势](#5.6.5 PAwR的功耗优势)
[6. 可连接且可扫描的非定向广播事件](#6. 可连接且可扫描的非定向广播事件)
[6.1 PDU的数据结构](#6.1 PDU的数据结构)
[6.2 广播事件的生命周期与交互流程](#6.2 广播事件的生命周期与交互流程)
[6.3 时序与关键行为](#6.3 时序与关键行为)
[7. 可连接定向广播事件](#7. 可连接定向广播事件)
[7.1 定义](#7.1 定义)
[7.2 PDU的数据结构](#7.2 PDU的数据结构)
[7.3 交互流程](#7.3 交互流程)
[7.4 两种占空比模式](#7.4 两种占空比模式)
[7.4.1 高占空比模式(High Duty Cycle)](#7.4.1 高占空比模式(High Duty Cycle))
[7.4.2 低占空比模式(Low Duty Cycle)](#7.4.2 低占空比模式(Low Duty Cycle))
[7.4.3 模式对比](#7.4.3 模式对比)
[7.8 拓展定向广播模式](#7.8 拓展定向广播模式)
[7.8.1 工作机制](#7.8.1 工作机制)
[8. 可扫描非定向广播事件](#8. 可扫描非定向广播事件)
[8.1 定义](#8.1 定义)
[8.2 交互流程](#8.2 交互流程)
[8.3 扩展广播中的ADV_SCAN_IND](#8.3 扩展广播中的ADV_SCAN_IND)
[8.4 为什么需要ADV_SCAN_IND?](#8.4 为什么需要ADV_SCAN_IND?)
[9. 不可连接非扫描非定向广播事件](#9. 不可连接非扫描非定向广播事件)
[9.1 定义](#9.1 定义)
[9.2 交互流程](#9.2 交互流程)
[9.3 时序参数](#9.3 时序参数)
[9.4 设计优势](#9.4 设计优势)
[9.5 典型应用场景](#9.5 典型应用场景)
[10. 可连接非定向广播事件](#10. 可连接非定向广播事件)
[10.1 定义](#10.1 定义)
[10.2 交互流程](#10.2 交互流程)
[10.3 扩展广播中的ADV_IND](#10.3 扩展广播中的ADV_IND)
[11. 可扫描定向广播事件](#11. 可扫描定向广播事件)
[11.1 定义](#11.1 定义)
[11.2 扩展可扫描定向广播的工作机制](#11.2 扩展可扫描定向广播的工作机制)
[11.3 为什么需要"可扫描定向"这个组合?](#11.3 为什么需要"可扫描定向"这个组合?)
[12. 不可连接不可扫描定向广播事件](#12. 不可连接不可扫描定向广播事件)
[12.1 工作机制](#12.1 工作机制)
[12.2 为什么需要"不可连接不可扫描定向"?](#12.2 为什么需要“不可连接不可扫描定向”?)
[13. 广播集](#13. 广播集)
[13.1 为什么需要广播集?](#13.1 为什么需要广播集?)
[13.2 广播集的核心组成](#13.2 广播集的核心组成)
[13.3 广播集的并发能力与限制](#13.3 广播集的并发能力与限制)
[14. 总结](#14. 总结)
[14.1 BLE 全广播类型终极对照表](#14.1 BLE 全广播类型终极对照表)
[14.2 注解与关键约束](#14.2 注解与关键约束)
1. 链路层状态机:广播态的位置
在BLE协议栈中,链路层定义了一个状态机。从蓝牙5.4规范来看,链路层包含以下状态:
-
Standby State(待机态):不上电收发数据的空闲状态
-
Advertising State(广播态):通过广播信道发送数据的状态
-
Scanning State(扫描态):侦听广播信道数据包的状态
-
Initiating State(发起态):侦听可连接广播并发起连接的状态
-
Connection State(连接态):建立单独通道后的状态
-
Synchronization State(同步态):蓝牙5.0引入,用于周期性广播同步
-
Isochronous Broadcasting State(等时广播态):用于传输等时数据流
广播态由Standby状态进入,是设备对外"发声"的唯一通道。广播态的设备可以回到Standby状态,连接成功后也可切换为Connection状态。
2. 广播态的核心分类维度
广播态并非铁板一块。根据设备在广播期间的行为差异,规范将广播划分为多个类型。理解这些分类,是理解"不可连接"的前提。
广播模式主要从以下三个维度划分:
1. 可连接 vs. 不可连接
可连接广播表示扫描方收到该广播后,可以发起连接请求(发送CONNECT_REQ)。这是最常见的广播类型,用于设备发现和连接建立。
不可连接广播则相反------设备声明自己不接受任何连接请求。扫描方无法通过这种广播与设备建立连接。最典型的例子就是蓝牙Beacon包。
2. 可扫描 vs. 不可扫描
可扫描广播表示扫描方收到广播包后,可以发送SCAN_REQ(扫描请求) ,广播者收到后会回复SCAN_RSP(扫描响应),从而传输更多数据。
不可扫描广播则不会响应任何扫描请求。
3. 定向 vs. 非定向
定向广播的广播包只针对特定设备,其他设备会忽略该广播包。非定向广播则面向所有扫描设备,任何扫描方都可以接收和处理。
这三个维度排列组合,就构成了BLE中所有的广播类型。
3. 四类标准广播模式
基于上述维度,蓝牙核心规范(v5.4)定义了四类标准广播模式:
| 广播类型 | PDU类型 | 可连接? | 可扫描? | 定向? | 典型场景 |
|---|---|---|---|---|---|
| 可连接非定向广播 | ADV_IND | ✅ | ✅ | ❌ | 智能手环、TWS耳机 |
| 可连接定向广播 | ADV_DIRECT_IND | ✅ | ❌ | ✅ | 断连后快速重连 |
| 不可连接非定向广播 | ADV_NONCONN_IND | ❌ | ❌ | ❌ | iBeacon、信标 |
| 可扫描非定向广播 | ADV_SCAN_IND | ❌ | ✅ | ❌ | 需传输较多信息的无连接设备 |
"可连接"的本质:设备在广播期间监听并响应CONNECT_REQ链路层包,这要求设备维持完整的链路层状态机,消耗更多RAM与功耗。
"定向广播"的价值:通过在广播包中直接嵌入目标设备的MAC地址,省略了传统扫描-过滤-连接的漫长流程,连接延迟可降至10ms以内。
4. 广播信道索引
BLE在2.4GHz ISM频段共划分了40个射频(RF)信道 ,编号从0到39。信道频率与索引的对应关系为:频率 = 2402 + 2 × 信道索引 MHz。例如,信道0的中心频率是2402MHz,信道39是2480MHz。
这40个信道被划分为两类:
| 信道类型 | 信道索引 | 数量 | 用途 |
|---|---|---|---|
| 数据信道 | 0 ~ 36 | 37个 | 连接建立后的数据传输,支持自适应跳频 |
| 广播信道 | 37, 38, 39 | 3个 | 设备发现、广播数据发送 |
那么问题来了:为什么偏偏是37、38、39这三个索引?
这三个广播信道并非按顺序排列,而是精心选择的:
-
信道37 :中心频率 2402 MHz(频段底部)
-
信道38 :中心频率 2426 MHz(频段中部,靠近Wi-Fi信道6)
-
信道39 :中心频率 2480 MHz(频段顶部)
之所以选择这三个位置,核心考量有两点:
-
抗干扰能力强 :三个信道在频段上彼此相隔甚远,即使ISM频段某个区域受到强干扰(如Wi-Fi、微波炉),也不太可能三个信道同时被阻塞,保证了广播的可靠性。
-
避开Wi-Fi拥塞区域:Wi-Fi在2.4GHz频段通常使用1、6、11三个主信道,BLE的广播信道选择恰好避开了这些信道最密集的区域,减少了与Wi-Fi的冲突概率。
4.1 广播信道索引的两种选择方式
在BLE规范中,广播信道的使用方式经历了从固定顺序 到灵活选择的演变。
- 方式一:固定顺序(蓝牙5.0及以前)
在蓝牙核心规范5.0及更早版本中,广播事件必须按照严格的固定顺序 使用三个主广播信道:37 → 38 → 39。
这意味着每个广播事件中,设备首先在信道37上发送广播PDU,然后在信道38上发送,最后在信道39上发送。顺序不可改变。
- 方式二:任意顺序(蓝牙5.1及以后)
从蓝牙5.1开始,规范放宽了这一限制:广播信道可以在每个广播事件中以任意顺序使用。设备不再必须遵循37→38→39的固定顺序,甚至可以在不同广播事件中使用不同的信道顺序。
这一变化的目的是进一步降低碰撞概率------如果多个广播设备都使用相同的信道顺序,它们可能在所有三个信道上持续碰撞;而随机化顺序后,即使两个设备在同一时刻开始广播,它们在后续信道上的碰撞概率也会显著降低。
4.2 信道映射(Advertising_Channel_Map)
在BLE的HCI(主机控制器接口)层,主机通过命令向控制器传递广播信道的选择策略。具体来说,是通过 Advertising_Channel_Map 参数来完成的。
该参数是一个1字节(8位)的位掩码(Bitmask) ,每一位对应一个广播信道:
| 位 | 对应的广播信道 | 位值(十六进制) |
|---|---|---|
| Bit 0 | 信道37 | 0x01 |
| Bit 1 | 信道38 | 0x02 |
| Bit 2 | 信道39 | 0x04 |
| Bit 3-7 | 保留 | --- |
开发者可以通过组合这些位来选择使用的广播信道:
-
0x01:仅使用信道37 -
0x02:仅使用信道38 -
0x04:仅使用信道39 -
0x07:使用所有三个广播信道(37、38、39)
规范要求至少设置一个信道位,即广播设备不能"一个信道都不用"。
在代码层面,典型的配置方式如下:
cpp
#define BLE_GAP_ADV_CHANNEL_37 0x01
#define BLE_GAP_ADV_CHANNEL_38 0x02
#define BLE_GAP_ADV_CHANNEL_39 0x04
#define BLE_GAP_ADV_CHANNEL_ALL 0x07 // 37 | 38 | 39
5. 广播事件
理解了广播态的分类之后,我们需要进一步追问:广播态具体是如何工作的? 一个广播设备"发一次数据"到底经历了什么?这就引出了广播态最核心的执行单元------广播事件(Advertising Event)。
5.1 什么是广播事件?
广播事件是BLE链路层在广播态下的基本执行单元。简单来说,一个广播事件,就是广播设备在三个主要广播信道上完成一轮广播数据发送的完整过程。
BLE的广播信道一共有三个:37、38、39。一个广播事件从37信道开始,依次经过38信道,结束于39信道------在这三个信道上各发送一次广播PDU。广播事件的结构如下图所示:

在每个信道上,设备发送广播PDU后,会在同一信道上监听至少一个帧间间隔(T_IFS) ,帧间间隔必须小于150微秒------这是为了不错过其他设备可能发来的响应包(如扫描请求或连接请求)。在每个信道上停留的时间不超过10毫秒。
5.2 广播事件的时序
相邻两个广播事件开始之间的时间间隔,在规范中记作 T_advEvent。它的计算公式非常简单:
T_advEvent = advInterval + advDelay
这两个参数共同决定了广播事件的节奏。
advInterval:应用层设置的广播间隔
advInterval由应用层设置,取值范围是20毫秒到10.24秒,单位是0.625毫秒的整数倍。
advInterval是调节广播事件占空比的核心参数:
-
减小advInterval → 单位时间内广播次数增多 → 设备更容易被发现 → 功耗更高
-
增大advInterval → 单位时间内广播次数减少 → 设备被发现需要更长时间 → 功耗更低
advDelay:链路层的随机延迟
advDelay是链路层为每个广播事件 独立生成的伪随机数,范围是0到10毫秒。
这个随机延迟的设计初衷是抗干扰 。如果多个广播设备使用相同的advInterval,它们可能会在完全相同的时间发送广播包,导致信道冲突。advDelay让每个广播事件的起始时间产生0-10ms的随机偏移,有效分散了冲突风险。
但advDelay也带来一个代价:观察者无法精确预知下一次广播的时间,只能持续扫描或使用较大的接收窗口,导致功耗增加。
5.3 广播事件的PDU交互
不同类型的广播事件,在三个信道上的PDU交互模式各不相同,如下图所示:

5.4 拓展广播事件
传统广播事件------在37、38、39三个广播信道上依次发送PDU。这种设计在蓝牙4.x时代够用,但随着BLE设备数量的爆炸式增长,三个广播信道越来越拥挤。同时,31字节的广播数据负载也日渐捉襟见肘。
5.4.1 为什么需要拓展广播?
传统广播的局限性主要体现在三个方面:
① 信道拥挤:所有BLE设备共享37、38、39三个广播信道。随着信标、传感器、穿戴设备等海量BLE设备的部署,这三个信道上的碰撞越来越严重。
② 数据负载小 :传统广播PDU的有效载荷最大只有31字节。对于需要传输较多信息的场景(如位置服务、广播音频等),31字节远远不够。
③ 无法利用新PHY:蓝牙5.0引入了2M PHY和Coded PHY(支持更远距离),但传统广播只能在1M PHY上工作。
扩展广播正是为解决这些问题而设计的。
5.4.2 主广播信道与次广播信道
蓝牙5.0将广播信道重新划分为两类:
| 信道类型 | 信道索引 | 数量 | 用途 |
|---|---|---|---|
| 主广播信道(Primary) | 37, 38, 39 | 3个 | 发送广播头(指向辅助数据的指针) |
| 次广播信道(Secondary) | 0 ~ 36 | 37个 | 发送实际的广播数据负载 |
注意:次广播信道与数据信道使用相同的物理信道(0~36),只是在广播场景下被称为"次广播信道"。
传统广播只在3个主广播信道上工作,而扩展广播通过"主广播发指针 + 次广播发数据 "的两阶段机制,将广播从3个信道扩展到了全部40个信道。
5.4.3 扩展广播的工作机制
扩展广播的核心思想是:主广播只发一个"小纸条",告诉扫描方"数据在哪儿";扫描方根据"小纸条"的指引,去指定信道获取真正的"大块数据" 。
具体分为两个步骤:
步骤一:主广播阶段
广播设备在37、38、39三个主广播信道上发送 ADV_EXT_IND PDU。这个PDU不包含实际的广播数据 ,而是包含一个名为 AuxPtr(辅助指针) 的结构。
AuxPtr包含以下关键字段:
-
信道号(Channel Index) :次广播数据将在哪个信道上发送(0~36)
-
时间偏移(AUX Offset) :距离主广播结束多长时间后,次广播数据开始发送
-
时间偏移的单位(Offset Unit) :偏移量的时间单位
-
时钟精度(CA) :广播设备的时钟精度,用于扫描方校准接收窗口
-
PHY(AUX PHY) :次广播数据使用哪种PHY(1M/2M/Coded)
步骤二:次广播阶段
扫描方收到ADV_EXT_IND后,解析其中的AuxPtr,在指定的时间 切换到指定的信道 (0~36中的某一个),使用指定的PHY 接收真正的广播数据------AUX_ADV_IND PDU。
拓展广播事件的示意图如下:

拓展广播下的辅助广播示例如下:

5.4.4 扩展广播的PDU类型
蓝牙5.0为扩展广播定义了多组新的PDU类型:
| PDU类型 | 物理信道 | 用途 |
|---|---|---|
| ADV_EXT_IND | 主广播(37/38/39) | 扩展广播指示,包含AuxPtr指针 |
| AUX_ADV_IND | 次广播(0~36) | 扩展广播数据,第一个片段 |
| AUX_SCAN_REQ | 次广播(0~36) | 次广播信道上的扫描请求 |
| AUX_SCAN_RSP | 次广播(0~36) | 次广播信道上的扫描响应 |
| AUX_CONNECT_REQ | 次广播(0~36) | 次广播信道上的连接请求 |
| AUX_CHAIN_IND | 次广播(0~36) | 链式扩展广播数据(后续片段) |
| AUX_SYNC_IND | 次广播(0~36) | 周期性广播同步指示 |
其中,ADV_EXT_IND、AUX_ADV_IND、AUX_SCAN_RSP、AUX_SYNC_IND、AUX_CHAIN_IND和AUX_CONNECT_RSP这六种PDU使用统一的通用扩展广播负载格式(Common Extended Advertising Payload Format) 。
5.4.5 容量提升
扩展广播带来的最直接变化是数据容量的飞跃:
| 维度 | 传统广播 | 扩展广播 |
|---|---|---|
| 单个广播包负载 | 最多31字节 | 最多254字节 (AUX_ADV_IND) |
| 链式广播总负载 | 不支持 | 最多1650字节 (多个AUX_CHAIN_IND串联) |
当单个AUX_ADV_IND的254字节仍不够用时,可以通过 AUX_CHAIN_IND 进行链式扩展------多个辅助PDU串联在一起,总负载可达1650字节。每个链式PDU都包含指向下一个PDU的指针,接收方按顺序接收并重组所有数据。
5.5 周期广播事件
扩展广播解决了传统广播"信道少、负载小"的问题,但它依然继承了传统广播的一个核心特征------时序不确定性。
回顾前文:无论是传统广播还是扩展广播,每个广播事件之间都存在一个advDelay(0~10ms的随机值)。这个随机延迟虽然有助于避免信道冲突,但代价是观察者无法精确预知广播何时到来,只能持续扫描或使用较大的接收窗口,导致功耗居高不下。
蓝牙5.0引入的周期性广播(Periodic Advertising) ,正是为了解决这个问题------它把广播从"随机发声"升级为精准的"定时列车"。
5.5.1 什么是周期性广播?
周期性广播是蓝牙5.0基于扩展广播引入的一种特殊广播模式。它的核心特征是:
-
固定间隔 :广播数据以严格固定的时间间隔 发送,没有
advDelay的随机扰动 -
不可连接 :周期性广播本身是不可连接的(Non-connectable)
-
多接收方 :一个广播源可以被一个或多个扫描设备 同时监听,本质上是一对多的组播(Multicast)
-
数据可变:每个广播事件中的数据可以不同,广播源可以在不同周期发送变化的内容
如果把传统广播比作"随机喊话"------喊话的人每次喊话的时间都有点随机偏差,听众只能一直竖起耳朵听;那么周期性广播就是"定时列车"------列车每20毫秒准时到站,乘客只需按时在站台等候即可。
5.5.2 为什么需要周期性广播?
① 功耗优化
这是周期性广播最直接的价值。由于广播间隔严格固定,扫描设备可以精确预知每一个广播事件的到达时间。扫描设备只需在广播事件到达的瞬间短暂唤醒接收数据,其余时间深度休眠。
相比之下,传统广播的扫描设备因为不知道advDelay到底是多少,不得不长时间保持接收状态或频繁唤醒,功耗显著更高。
② 确定性时序
周期性广播为广播通信带来了确定性的时序。这对于需要精确时间同步的应用(如广播音频、大规模传感器数据采集)至关重要。
③ 大规模组播
一个周期性广播源可以被无限多个扫描设备同时接收。这在传统连接模式中是不可想象的------每个连接都需要独立的资源开销。
5.5.3 周期性广播的工作机制
周期性广播并不是独立存在的,它必须依托于扩展广播 。整体流程可以分为两个阶段:宣告阶段 和广播阶段。
阶段一:宣告阶段(通过扩展广播发布"节目预告")
广播源首先在主广播信道(37、38、39) 上发送ADV_EXT_IND PDU。
这个PDU本身不包含周期性广播的数据 ,而是扮演"节目预告"的角色。它通过AuxPtr指向一个在次广播信道(数据信道0~36) 上发送的AUX_ADV_IND PDU。
AUX_ADV_IND中包含了关键的同步信息(SyncInfo) :
-
周期性广播间隔(Periodic Advertising Interval) :两个周期性广播事件之间的时间
-
跳频序列(Hopping Sequence) :每次广播使用哪个数据信道
-
广播源地址:设备的身份信息
-
广播集ID(SID) :标识具体的广播集
扫描设备收到ADV_EXT_IND → AUX_ADV_IND这一组宣告后,就获得了收听周期性广播所需的全部"时刻表"信息。
阶段二:广播阶段(周期性发送"定时列车")
获得同步信息后,广播源开始在次广播信道(数据信道0~36) 上,以严格固定的间隔 发送AUX_SYNC_IND PDU。
AUX_SYNC_IND包含实际的周期性广播数据 。如果数据量超过一个包的大小,可以用AUX_CHAIN_IND PDU接在后面继续发送。AUX_SYNC_IND加上后续的AUX_CHAIN_IND,共同构成周期性广播列车(Periodic Advertising Train) 。
其工作示意图如下:

关键设计:持续可同步
广播源会定期发送新的AUX_ADV_IND 。这样做的目的是:
-
新扫描设备 可以在任何时候加入,通过扫描
ADV_EXT_IND获取同步信息,然后接入周期性广播流 -
已同步的设备 如果丢失了同步(如暂时离开范围),可以在下一次
AUX_ADV_IND到来时重新同步
有些协议栈实现(如Silicon Labs)会在每个周期性广播事件之前 都发送一个AUX_ADV_IND,让新扫描设备能够快速同步。
5.5.4 周期性广播的PDU类型
周期性广播涉及以下几类关键PDU:
| PDU类型 | 物理信道 | 作用 |
|---|---|---|
| ADV_EXT_IND | 主广播(37/38/39) | 扩展广播指示,包含指向AUX_ADV_IND的AuxPtr |
| AUX_ADV_IND | 次广播(0~36) | 包含SyncInfo同步信息(间隔、跳频、地址等) |
| AUX_SYNC_IND | 次广播(0~36) | 周期性广播的核心PDU,包含实际广播数据 |
| AUX_CHAIN_IND | 次广播(0~36) | 当数据超长时,跟在AUX_SYNC_IND后面继续传输 |
5.5.5 周期性广播的关键参数
① 周期性广播间隔(Periodic Advertising Interval)
范围:7.5ms ~ 81.91875s。
这是两个连续周期性广播事件之间的固定时间,没有随机延迟。
② 跳频(Channel Hopping)
周期性广播在次广播信道(数据信道0~36) 上工作。每次广播使用哪个信道,由信道选择算法#2(Channel Selection Algorithm #2) 决定。
CSA#2以伪随机方式选择信道,相比传统算法提供了更多的信道组合,有效降低了碰撞概率。
③ PHY
周期性广播使用与辅助包(AUX_ADV_IND)相同的PHY------可以是1M PHY、2M PHY或Coded PHY(S=2/S=8)。
5.6 带响应的周期性广播(PAwR)事件
前文我们讨论了周期性广播(Periodic Advertising)------它像一列精准运行的"定时列车",以固定间隔发送广播数据,观察者可以精确同步、低功耗接收。
然而,这列"定时列车"有一个明显的局限:数据只能从广播者流向观察者,方向是单向的。观察者无法向广播者回传任何信息。
蓝牙5.4引入的带响应的周期性广播(Periodic Advertising with Responses, PAwR) ,正是为了解决这个问题。它在周期性广播的基础上加入了响应时隙(Response Slots) ,让这列"定时列车"不仅能够广播,还能接收乘客的回应。
PAwR的引入,使得在无连接(Connectionless) 模式下实现一对多、双向、大规模的星型拓扑通信成为可能。
5.6.1 PAwR在逻辑传输层的定位
蓝牙5.4在逻辑传输层定义了三种主要的广播类型:
| 广播类型 | 缩写 | 时序 | 方向 | 典型场景 |
|---|---|---|---|---|
| 广播(Advertising Broadcast) | ADVB | 不规则(有0-10ms随机延迟) | 单向 | 传统Beacon |
| 周期性广播(Periodic Advertising Broadcast) | PADVB | 精确、固定间隔 | 单向 | 广播音频 |
| 带响应的周期性广播 | PAwR | 精确、固定间隔 | 双向 | ESL、传感器网络 |
ADVB包含了传统广播和扩展广播,广播不规则且存在0-10ms的随机延迟。PADVB消除了随机延迟,实现了精确的定时广播。而PAwR在PADVB的基础上,增加了从观察者到广播者的响应通道,实现了双向通信。
5.6.2 PAwR的事件结构
PAwR最关键的变化,是将广播事件从"单次发送"扩展为三级标准化结构

这与PADVB形成鲜明对比------PADVB中每个广播事件只有一个广播数据包 ,而PAwR的每个广播事件由多个子事件(Subevent) 组成。
5.6.2.1 子事件
每个PAwR事件最多包含128个子事件。
每个子事件在时间上占据一个固定的时间段。广播者会在每个子事件的开始时发送一个数据包。这个数据包可以是:
-
AUX_SYNC_SUBEVENT_IND:周期性广播数据包,包含广播者发往观察者的数据 -
AUX_CONNECT_REQ:连接请求,用于在需要更高吞吐量时建立ACL连接
所有同步到该子事件的观察者都会扫描这个数据包并处理其中的有效载荷。
观察者不会监听所有子事件 ,而是只监听自己订阅/同步到的特定子事件。多个观察者可以订阅同一个子事件。这种设计将海量终端设备分组到不同的子事件中,实现了大规模组网。
5.6.2.2 响应时隙(Response Slot)
这是PAwR的"R"部分------与普通周期性广播的核心区别。
广播者在子事件中发送完数据包后,会预留一系列响应时隙(Response Slots) 。观察者可以在这些响应时隙中发送响应数据包(AUX_SYNC_SUBEVENT_RSP),将数据传回给广播者。
每个子事件最多支持256个响应时隙。这意味着一个子事件中最多可以有256个观察者依次发送响应。

关键设计原则 :为避免碰撞,一个响应时隙中只能有一个观察者响应 。哪个观察者在哪个响应时隙上发送响应,由应用层或配置文件决定。
5.6.2.3 三级结构的容量计算
PAwR的三级结构带来了巨大的组网容量:
-
子事件 :最多 128个
-
每个子事件的响应时隙 :最多 256个
-
理论总容量 :128 × 256 = 32,640个终端节点
5.6.3PAwR的关键时序参数
PAwR的精确时序由一系列参数控制。这些参数由广播者(Advertiser/Access Point)定义,并通过同步信息(SyncInfo)传递给观察者。
| 参数 | 含义 | 单位 | 范围 |
|---|---|---|---|
| 子事件间隔(Subevent Interval) | 相邻子事件开始之间的时间 | 1.25ms | 7.5ms ~ 318.75ms |
| 响应时隙延迟(Response Slot Delay) | 广播包结束到第一个响应时隙开始之间的延迟 | 1.25ms | 1.25ms ~ 317.5ms |
| 响应时隙间隔(Response Slot Spacing) | 相邻响应时隙之间的时间 | 0.125ms | 0.25ms ~ 31.875ms |
| 子事件数量(Num Subevents) | 每个PAwR事件的子事件数 | --- | 1 ~ 128 |
| 响应时隙数量(Num Response Slots) | 每个子事件的响应时隙数 | --- | 0 ~ 256 |
响应时隙间隔的设计有一个重要约束:必须确保观察者的完整响应数据包能够在响应时隙内完成传输,并包含帧间间隔(T_IFS,最小150μs)。
5.6.4 PAwR的同步机制
观察者要接入PAwR广播流,需要先完成同步。PAwR支持两种同步方式:
方式一:通过扩展广播同步(Primary Advertising)
与周期性广播类似,观察者首先在主广播信道(37、38、39) 上扫描ADV_EXT_IND PDU,然后跟随AuxPtr到次广播信道接收AUX_ADV_IND PDU。
AUX_ADV_IND中包含SyncInfo 字段和ACAD(Additional Controller Advertising Data) 字段,其中包含了PAwR特有的同步信息:
-
子事件间隔(Subevent Interval)
-
子事件数量(Num Subevents)
-
响应时隙延迟(Response Slot Delay)
-
响应时隙间隔(Response Slot Spacing)
-
响应时隙数量(Num Response Slots)
方式二:通过PAST(Periodic Advertising Sync Transfer)
PAST是蓝牙5.1引入的同步信息传递机制。一个已经与PAwR广播源同步的设备(如功耗较高的网关),可以通过已建立的ACL连接将同步信息传递给另一个低功耗设备。
这样,低功耗设备无需自己执行扫描和同步流程,直接通过连接获取同步信息即可接入PAwR广播流。这对于那些自身扫描能力有限或追求极致功耗的设备非常有用。
5.6.5 PAwR的功耗优势
PAwR的低功耗来自于精确的时间同步 和选择性监听:
-
观察者同步到PAwR后,只监听自己订阅的子事件,不监听其他子事件
-
在每个周期性广播间隔中,观察者只需唤醒一次,扫描一个极短的时间窗口
-
其余时间,观察者可以深度休眠
6. 可连接且可扫描的非定向广播事件
在蓝牙规范中由 ADV_IND PDU(协议数据单元)标识。它是一种"非定向"广播,意味着它不针对任何特定设备,而是向所有扫描者宣告自身存在。
它被称为"可连接且可扫描",是因为它同时具备两种能力:
-
可扫描 :扫描设备可以发送
SCAN_REQ(扫描请求)来获取更多信息。 -
可连接 :发起设备可以发送
CONNECT_REQ(连接请求)来建立连接。
ADV_IND是所有广播类型中最通用、最基础的一种,是大多数BLE外设(如智能手环、传感器)用于被发现和连接的标准方式。
6.1 PDU的数据结构

一个ADV_IND广播包,其有效载荷(Payload)主要包含两部分:
-
AdvA:广播设备的地址(6字节),可以是公共地址或随机地址。 -
AdvData:广播数据(0-31字节),包含设备名称、服务UUID等信息。
这个31字节的AdvData是设备向外宣告自身能力和身份的核心信息载体。
6.2 广播事件的生命周期与交互流程
ADV_IND广播事件的完整流程涉及三种角色的互动:广播者(Advertiser) 、扫描者(Scanner) 和发起者(Initiator)。
1. 事件开始:广播者发送ADV_IND
广播者在37、38、39三个广播信道上依次发送ADV_IND PDU。在每次发送后,它会在同一信道上短暂监听,等待可能的回应。

2. 两种可能的回应
任何收到ADV_IND的设备,可以根据自身角色和需求,选择以下两种回应之一:
-
场景A:扫描请求(SCAN_REQ)与扫描响应(SCAN_RSP)
-
触发者:扫描者(Scanner)。
-
目的:获取广播者更多的信息(如设备全名、支持的更多服务等)。
-
交互 :扫描者发送
SCAN_REQ。广播者收到后,必须在同一广播信道 上回复一个SCAN_RSPPDU。SCAN_RSP的有效载荷同样最大为31字节。这个交互能让扫描者在建立连接前,就获取到比ADV_IND中更丰富的信息。
-
-
场景B:连接请求(CONNECT_REQ)
-
触发者:发起者(Initiator)。
-
目的:与广播者建立ACL数据连接。
-
交互 :发起者发送
CONNECT_REQPDU。一旦广播者收到并接受这个请求,当前的广播事件会立即终止。设备将退出广播态,进入连接态,开始数据通信。
-
6.3 时序与关键行为
-
事件内监听 :在每个广播信道发送完
ADV_IND后,广播者必须监听至少一个帧间间隔(T_IFS,约150μs),以捕获可能的SCAN_REQ或CONNECT_REQ。 -
信道内回应 :无论是
SCAN_RSP还是CONNECT_REQ,所有回应都在接收到请求的同一个广播信道上进行。 -
事件终止条件:一个广播事件在以下情况结束:
-
在所有使用的广播信道上都完成了发送(且未收到连接请求)。
-
在某个信道上收到了
CONNECT_REQ,此时事件提前终止。
-
-
事件间隔 :两个
ADV_IND广播事件之间的间隔,由advInterval(20ms~10.24s)加上一个0~10ms的随机延迟advDelay组成。
7. 可连接定向广播事件
可连接定向广播事件(Connectable Directed Advertising Event) ,就是一条"专线电话"------只有特定的那个人才能接听,也只有那个人才能拨回来。
7.1 定义
可连接定向广播事件 ,在蓝牙规范中由 ADV_DIRECT_IND PDU标识。它是一种可连接、不可扫描、定向的广播类型。
与ADV_IND相比,ADV_DIRECT_IND有三大核心特征:
| 特征 | ADV_IND |
ADV_DIRECT_IND |
|---|---|---|
| 可连接 | ✅ | ✅ |
| 可扫描 | ✅ | ❌(不响应SCAN_REQ) |
| 定向 | ❌ | ✅(仅针对特定设备) |
| 携带自定义数据 | ✅(最多31字节) | ❌(净荷仅含两个地址) |
只有广播包中指定的那个设备才能与之建立链路层连接,其余设备的连接请求均被忽略 。这种广播类型俗称**"回连包"** ,其设计初衷是为了尽可能快地建立连接------尤其是在设备断连后需要快速重连的场景。
7.2 PDU的数据结构

DV_DIRECT_IND的PDU结构极其精简------没有任何自定义广播数据空间。
在广播信道PDU的Header中,PDU Type字段的值为0b0001(即数值1)。
Payload部分仅包含两个6字节的地址:
| 字段 | 长度 | 含义 |
|---|---|---|
| AdvA | 6字节 | 广播者的设备地址(public或random) |
| InitA | 6字节 | 目标接收者的设备地址(即唯一允许发起连接的设备地址) |
TxAdd位指示AdvA是公共地址还是随机地址;RxAdd位指示InitA是公共地址还是随机地址。
整个PDU的有效载荷长度固定为12字节 (6+6)。不包含任何AdvData字段 ------这意味着定向广播不能携带任何自定义广播数据,如设备名称、服务UUID等。
7.3 交互流程
ADV_DIRECT_IND的交互流程与ADV_IND有本质不同:
-
广播者在37、38、39三个主广播信道上依次发送
ADV_DIRECT_INDPDU -
每次发送后,广播者在同一信道上短暂监听 ,等待
CONNECT_REQ -
只有InitA字段中指定的目标设备 才被允许发送
CONNECT_REQ -
其他任何设备(包括扫描者)发送的
SCAN_REQ都会被直接忽略 ------定向广播不可扫描 -
如果广播者在某个信道上收到了来自目标设备的
CONNECT_REQ,广播事件立即终止,双方进入连接态 -
如果未收到,广播者转移到下一个主广播信道继续尝试,或关闭广播事件
7.4 两种占空比模式
ADV_DIRECT_IND支持两种工作模式 :高占空比(High Duty Cycle) 和低占空比(Low Duty Cycle)
7.4.1高占空比模式(High Duty Cycle)
这是定向广播的**"性能优先"** 模式:
-
广播间隔 :两个连续的
ADV_DIRECT_INDPDU(在同一广播信道上)之间的间隔 ≤ 3.75ms -
持续时间 :不得超过1.28秒。如果1.28秒内没有建立连接,控制器自动停止广播
-
功耗:极高。如此密集的发送会让广播信道被占满,影响该区域其他设备的广播
-
适用场景 :快速重连------设备断连后需要立即恢复连接时使用
高占空比定向广播的广播间隔是固定的(≤3.75ms),应用层设置的
advInterval参数会被忽略
其工作示意图如下:

7.4.2 低占空比模式(Low Duty Cycle)
这是定向广播的**"平衡优先"** 模式:
-
广播间隔 :两个连续的
ADV_DIRECT_INDPDU之间的间隔 ≤ 10ms -
持续时间 :无1.28秒硬性限制,可以由应用层灵活控制
-
功耗:相对较低,对广播信道的影响较小
-
适用场景 :需要重连但时间不敏感的场景,或对功耗有较高要求的设备
其工作示意图如下:

7.4.3 模式对比
| 维度 | 高占空比 | 低占空比 |
|---|---|---|
| 同一信道广播间隔 | ≤ 3.75ms | ≤ 10ms |
| 最大持续时间 | 1.28秒(硬性限制) | 无硬性限制(应用层控制) |
| 功耗 | 极高 | 较低 |
| 信道占用 | 极高(可能影响其他设备) | 较低 |
| 连接速度 | 极快 | 较快 |
| 典型场景 | 断连后紧急重连 | 普通重连、低功耗场景 |
7.8 拓展定向广播模式
扩展定向广播利用辅助信道(Secondary Channel) 和更灵活的PDU格式,实现了更大数据负载、更多PHY选择 和更可靠的连接建立。
7.8.1 工作机制
扩展定向广播与传统定向广播最核心的区别在于数据不在主广播信道上直接发送,而是通过两阶段完成:
阶段一:主广播(发送"路标")
广播设备在37、38、39三个主广播信道 上发送ADV_EXT_IND PDU。这个PDU不包含实际的广播数据或目标地址 ,只包含一个名为 AuxPtr(辅助指针) 的结构。
AuxPtr指向辅助广播数据的位置,包含:
-
信道号:辅助数据将在哪个数据信道(0~36)上发送
-
时间偏移:主广播结束后多久,辅助数据开始发送
-
PHY类型:辅助数据使用哪种PHY
阶段二:辅助广播(发送"正文")
目标扫描设备收到ADV_EXT_IND后,解析其中的AuxPtr,在指定的时间 切换到指定的数据信道(0~36) ,接收**AUX_ADV_IND** PDU。
AUX_ADV_IND包含了定向广播的核心信息:
-
AdvA:广播者地址
-
TargetA :目标设备地址(定向的关键)
-
AdvData:实际的广播数据(最多254字节)
如果需要传输更多数据,AUX_ADV_IND后面还可以跟一个或多个**AUX_CHAIN_IND** 链式PDU,总负载可达1650字节。
广播事件工作示意图如下:

含连接请求PDU的工作示意图如下:

8. 可扫描非定向广播事件
8.1 定义
可扫描非定向广播事件 ,在蓝牙规范中由 ADV_SCAN_IND PDU标识。它是一种可扫描、不可连接、非定向的广播类型。
其核心特征可以概括为:
| 特征 | ADV_SCAN_IND |
|---|---|
| 可连接 | ❌(不接受CONNECT_REQ) |
| 可扫描 | ✅(响应SCAN_REQ,回复SCAN_RSP) |
| 定向 | ❌(面向所有扫描设备) |
| 携带自定义数据 | ✅(最多31字节) |
ADV_SCAN_IND的PDU Type字段值为0b0110。
8.2 交互流程
ADV_SCAN_IND的交互流程与ADV_IND有本质区别:
- 广播阶段 :广播者在37、38、39三个主广播信道上依次发送
ADV_SCAN_INDPDU。每次发送后,广播者在同一信道上短暂监听(至少一个T_IFS,约150μs)。

-
扫描请求阶段 :如果扫描设备(Scanner)对广播数据感兴趣,可以发送
SCAN_REQPDU。这是主动扫描模式的行为------被动扫描模式只能监听,不能发送SCAN_REQ。 -
扫描响应阶段 :广播者收到
SCAN_REQ后,在同一个广播信道 上回复SCAN_RSPPDU。SCAN_RSP的有效载荷同样最大为31字节。


- 关键差异 :广播者只监听
SCAN_REQ,不监听CONNECT_REQ。任何发起者(Initiator)发送的连接请求都会被直接忽略。
重要提示 :
ADV_SCAN_IND的扫描响应机制与ADV_IND完全一致。ADV_SCAN_IND广播者在每个信道发送完广播包后会立即开始监听扫描请求,SCAN_REQ和SCAN_RSP之间由T_IFS(150μs)分隔。
8.3 扩展广播中的ADV_SCAN_IND
蓝牙5.0引入扩展广播后,ADV_SCAN_IND在扩展广播框架下也有了新的形态:
-
传统
ADV_SCAN_IND:仅在主广播信道(37/38/39) 上工作,负载最大31字节,仅支持1M PHY -
扩展可扫描广播 :使用
ADV_EXT_IND+AUX_ADV_IND,主广播信道发指针,次广播信道(0~36) 发实际数据,负载可达254字节(链式可达1650字节),支持1M/2M/Coded PHY

一个重要限制 :在蓝牙5.0规范中,扩展广播不能同时是可连接的和可扫描的 。因此,扩展广播框架下的可扫描广播必然是不可连接 的------这与
ADV_SCAN_IND的定位完全一致。
工作示意图:

8.4 为什么需要ADV_SCAN_IND?
既然ADV_IND已经同时支持可扫描和可连接,为什么还需要一个"只可扫描、不可连接"的ADV_SCAN_IND?
① 明确表达"我不接受连接"的意图
ADV_SCAN_IND通过PDU Type明确告诉所有扫描设备:这个设备不接受任何连接请求。这对于那些只需要广播数据、不需要建立连接的设备至关重要。
② 更轻量级的协议栈实现
不可连接的设备无需维护连接状态机、无需处理连接参数更新、无需管理连接加密。这大大简化了协议栈实现,降低了RAM和Flash的占用。
③ 更安全的"信息咨询"模式
由于不建立连接,扫描设备无法通过连接进一步访问广播者的服务和特征。ADV_SCAN_IND相当于给广播者设定了一个"安全边界"------你只能问我SCAN_REQ中允许问的问题,不能越过这条线。
9. 不可连接非扫描非定向广播事件
9.1 定义
不可连接非扫描非定向广播事件 ,在蓝牙规范中由 ADV_NONCONN_IND PDU标识。它是一种不可连接、不可扫描、非定向的广播类型。
其核心特征可以概括为:
| 特征 | ADV_NONCONN_IND |
|---|---|
| 可连接 | ❌(不接受CONNECT_REQ) |
| 可扫描 | ❌(不响应SCAN_REQ) |
| 定向 | ❌(面向所有扫描设备) |
| 携带自定义数据 | ✅(最多31字节) |
| 监听响应 | ❌(发送后不监听任何请求) |
ADV_NONCONN_IND的PDU Type字段值为0b0010。
9.2 交互流程
ADV_NONCONN_IND的交互流程是所有广播类型中最简单的:
- 广播阶段 :广播者在37、38、39三个主广播信道上依次发送
ADV_NONCONN_INDPDU

-
无监听 :每次发送后,广播者不监听任何响应 ------既不监听
SCAN_REQ(扫描请求),也不监听CONNECT_REQ(连接请求) -
直接结束 :广播者发送完一个
ADV_NONCONN_IND后,要么直接移动到下一个广播信道 继续发送,要么直接结束本次广播事件 -
重复事件 :整个广播事件在三个信道上轮询完成后,等待
advInterval + advDelay,进入下一个广播事件
关键差异 :与
ADV_SCAN_IND(可扫描)和ADV_IND(可连接可扫描)不同,ADV_NONCONN_IND的广播者在发送完广播包后不会停留监听,而是立即结束或转移到下一个信道。这是"不可扫描"和"不可连接"在链路层行为上的直接体现。
9.3 时序参数
ADV_NONCONN_IND的时序遵循传统广播的一般规则:
-
广播间隔 :两个连续广播事件开始之间的间隔为
advInterval + advDelay,其中advInterval由应用层设置(20ms~10.24s),advDelay为0~10ms的随机值 -
每个信道广播时长 :≤ 10ms
-
事件持续时间 :至少100ms 。三个信道各发一次构成一个完整的广播事件,由于每个信道≤10ms,三次轮询≤30ms,但规范要求广播事件持续时间至少100ms,意味着设备在一个广播事件中可能会多次轮询三个信道
9.4 设计优势
ADV_NONCONN_IND的设计目标非常明确:纯粹的、单向的数据广播。这一设计带来了独特的优势:
① 功耗最低
由于广播者完全不监听响应,它可以在发送完广播包后立即关闭射频模块进入休眠,无需浪费能量等待任何回应。在广播间隔期间,设备可以深度休眠。
② 协议栈最简单
不可连接、不可扫描意味着设备无需维护任何连接状态机,无需处理扫描请求和连接请求的解析与响应逻辑。协议栈实现最简单,RAM和Flash占用最小。
③ 信道资源占用最少
不监听响应意味着广播者在每个信道上停留的时间最短(仅发送时间),对广播信道的占用最小。这在广播设备密集的环境中尤为有利。
④ 单向通信的"纯粹性"
ADV_NONCONN_IND适用于只有发射机、没有接收机的广播场景。设备只需要向外发送数据,不需要也不期望任何形式的反馈。
9.5 典型应用场景
① iBeacon
这是ADV_NONCONN_IND最经典的应用。Apple的iBeacon规范明确要求使用ADV_NONCONN_IND类型。Beacon设备只向外广播UUID、Major、Minor和信号强度信息,不需要也不接受任何连接或扫描请求。
② 蓝牙Mesh的Provisioning广播
蓝牙Mesh规范规定,未配网设备(Unprovisioned Device)使用ADV_NONCONN_IND类型的广播包来发送Beacon,宣告自己等待配网。
③ 资产追踪标签
资产追踪标签类设备只需周期性广播自己的ID和位置信息,不需要与任何设备建立连接。
④ 环境传感器广播
温度、湿度、空气质量等传感器节点只需周期性广播采集到的数据,无需建立连接。
10. 可连接非定向广播事件
10.1 定义
可连接非定向广播事件 ,在蓝牙规范中由 ADV_IND PDU标识。它是一种可连接、可扫描、非定向的广播类型。
ADV_IND是四种传统广播类型中最通用、最基础 的一种。绝大多数BLE外设(如智能手环、传感器、蓝牙耳机)在上电后首次广播时,使用的就是ADV_IND。
其核心特征可以概括为:
| 特征 | ADV_IND |
|---|---|
| 可连接 | ✅(接受CONNECT_REQ) |
| 可扫描 | ✅(响应SCAN_REQ,回复SCAN_RSP) |
| 定向 | ❌(面向所有扫描设备) |
| 携带自定义数据 | ✅(最多31字节) |
| 典型场景 | 通用外设广播(手环、耳机等绝大多数设备) |
ADV_IND的PDU Type字段值为0b0000。
10.2 交互流程
ADV_IND的交互流程是所有广播类型中最完整、最复杂的,涉及三种角色的互动:
① 广播阶段
广播者在37、38、39三个主广播信道上依次发送ADV_IND PDU。每次发送后,广播者在同一信道上短暂监听(至少一个T_IFS,约150μs),等待可能的回应。
② 扫描请求与扫描响应(SCAN_REQ → SCAN_RSP)
如果扫描设备(Scanner)对广播数据感兴趣,可以发送SCAN_REQ PDU。广播者收到SCAN_REQ后,在同一个广播信道 上回复SCAN_RSP PDU。
SCAN_RSP的有效载荷同样最大为31字节 ,可以包含比ADV_IND中更丰富的信息(如完整的设备名称、更多的服务UUID等)。
一个重要的规范细节 :由于
ADV_IND是可扫描的,即使广播者没有额外的数据要发送,也必须回复一个空的SCAN_RSP。这是规范要求的,不能省略。
③ 连接请求(CONNECT_REQ)
如果发起设备(Initiator)决定与广播者建立连接,可以发送CONNECT_REQ PDU。广播者收到CONNECT_REQ后,当前的广播事件立即终止,双方进入连接态。
④ 交互的时序关系
在一个广播事件中,SCAN_REQ和CONNECT_REQ的监听是同时进行的。广播者在每个信道上发送完ADV_IND后,既监听扫描请求,也监听连接请求。谁先到来,就响应谁。
10.3 扩展广播中的ADV_IND
蓝牙5.0引入扩展广播后,广播机制发生了重大变化。在扩展广播框架下,"可连接"和"可扫描"的属性通过**AdvMode字段**来配置,而不是通过不同的PDU类型来区分。
扩展广播相比传统ADV_IND的主要提升:
| 维度 | 传统ADV_IND |
扩展广播(可连接模式) |
|---|---|---|
| 广播信道 | 仅37/38/39(3个) | 主37/38/39 + 辅助0~36(40个) |
| 单包负载 | 最多31字节 | 最多254字节 |
| 链式总负载 | 不支持 | 最多1650字节 |
| PHY支持 | 仅1M PHY | 1M / 2M / Coded |
| 传输效率 | 同一数据在3个信道上重复发送3次 | 主信道发指针,辅助信道发一次数据 |
一个重要限制 :在蓝牙5.0规范中,扩展广播不能同时是可连接的和可扫描的 。这意味着扩展广播框架下的"可连接"广播必然是不可扫描 的------这与传统
ADV_IND"可连接且可扫描"的行为不同。
其工作示意图如下:


11. 可扫描定向广播事件
11.1 定义
在传统BLE广播中,四种标准广播类型分别是:
| 广播类型 | PDU类型 | 可连接? | 可扫描? | 定向? |
|---|---|---|---|---|
| 可连接可扫描非定向 | ADV_IND |
✅ | ✅ | ❌ |
| 可连接定向 | ADV_DIRECT_IND |
✅ | ❌ | ✅ |
| 可扫描非定向 | ADV_SCAN_IND |
❌ | ✅ | ❌ |
| 不可连接非扫描非定向 | ADV_NONCONN_IND |
❌ | ❌ | ❌ |
在这四种传统广播类型中,并不存在"可扫描定向"(Scannable Directed)这个组合。如果你查阅蓝牙核心规范,会发现它明确列出了四种事件类型,其中"Scannable directed event"并不在其中。
为什么不存在?
因为在传统广播中,"定向"(Directed)与"可扫描"(Scannable)在功能上是互斥的:
-
定向广播 (
ADV_DIRECT_IND)的设计目标是极速连接 。为了达到这个目标,它把PDU精简到极致------只包含两个地址(AdvA和InitA),不携带任何广播数据 ,也不响应任何扫描请求 。它只做一件事:监听CONNECT_REQ。 -
可扫描广播 (
ADV_SCAN_IND)的设计目标是信息交换 。它接受SCAN_REQ并回复SCAN_RSP,用于在连接前交换更多信息。
这两个目标本身就是矛盾的------定向广播追求"快",可扫描广播追求"多"。在传统广播中,没有一种PDU类型能同时满足这两个需求。
结论:在传统广播(蓝牙4.x)中,"可扫描定向广播事件"并不存在。
而蓝牙5.0引入扩展广播后,"可扫描"和"定向"这两个属性终于可以独立组合 了。在扩展广播框架下,广播模式通过**AdvMode字段**中的独立标志位来配置。
于是,"非连接可扫描定向广播"(Non-connectable Scannable Directed) 成为了一个合法的广播类型。
其核心特征为:
| 特征 | 扩展可扫描定向广播 |
|---|---|
| 可连接 | ❌(不接受连接请求) |
| 可扫描 | ✅(响应扫描请求) |
| 定向 | ✅(仅针对特定目标设备) |
| 数据携带 | 仅支持扫描响应数据 (SCAN_RSP) |
11.2 扩展可扫描定向广播的工作机制
扩展可扫描定向广播使用两阶段"指路"机制 ,与传统定向广播(ADV_DIRECT_IND)有本质区别:
阶段一:主广播(发送"路标")
广播设备在37、38、39三个主广播信道上发送ADV_EXT_IND PDU。这个PDU包含一个**AuxPtr(辅助指针)** ,指向辅助广播数据的位置(信道号、时间偏移、PHY类型等)。
阶段二:辅助广播(发送"正文")
目标扫描设备收到ADV_EXT_IND后,跟随AuxPtr切换到指定的数据信道(0~36),接收AUX_ADV_IND PDU。
AUX_ADV_IND中包含了:
-
AdvA:广播者地址
-
TargetA :目标设备地址(定向的关键)
-
广播模式:设置为"非连接、可扫描、定向"
扫描请求与响应
由于广播是可扫描的,目标设备(或任何收到广播的设备,取决于过滤策略)可以发送AUX_SCAN_REQ,广播者回复AUX_SCAN_RSP。
注意 :在扩展可扫描定向广播中,只有扫描响应数据(
SCAN_RSP)是支持的 。这意味着实际的广播数据负载是通过扫描响应来传递的,而不是在AUX_ADV_IND中直接携带。
11.3 为什么需要"可扫描定向"这个组合?
这个组合看似矛盾,实则有其独特的应用价值:
① 定向信息分发 + 轻量级反馈
某些场景下,设备只想向特定目标发送信息,但又需要接收对方的反馈或确认。例如:
-
设备A只想向设备B推送配置信息
-
设备B收到后需要回复确认(通过
SCAN_RSP) -
但设备A和设备B之间不需要建立完整的ACL连接
② 隐私保护
定向广播确保只有指定的目标设备 才能感知到广播的存在并进行交互。其他设备即使扫描到ADV_EXT_IND,也无法解析后续的AUX_ADV_IND中的定向信息(因为TargetA不匹配)。
③ 大规模网络中的精准寻址
在包含成千上万个节点的网络中(如电子货架标签、传感器网络),广播者可以通过定向广播精准地向某一个节点发送信息,同时该节点可以通过扫描响应回复确认。
12. 不可连接不可扫描定向广播事件
蓝牙5.0引入扩展广播后,广播类型的定义方式发生了根本变化。在扩展广播框架下,广播的"可连接"、"可扫描"、"定向"三个属性通过独立的标志位来配置,而不是通过硬编码的PDU类型来区分。
于是,"不可连接不可扫描定向广播"(Non-connectable Non-scannable Directed) 成为了一个合法的广播类型。
其核心特征为:
| 特征 | 扩展不可连接不可扫描定向广播 |
|---|---|
| 可连接 | ❌(不接受任何连接请求) |
| 可扫描 | ❌(不响应任何扫描请求) |
| 定向 | ✅(仅针对特定目标设备) |
| 数据携带 | ✅ (通过AUX_ADV_IND携带最多254字节,链式可达1650字节) |
12.1 工作机制
扩展不可连接不可扫描定向广播使用两阶段"指路"机制:
阶段一:主广播(发送"路标")
广播设备在37、38、39三个主广播信道上发送ADV_EXT_IND PDU。这个PDU包含一个**AuxPtr(辅助指针)** ,指向辅助广播数据的位置(信道号、时间偏移、PHY类型等)。
阶段二:辅助广播(发送"正文")
目标设备(即ADV_EXT_IND中TargetA字段指定的设备)收到ADV_EXT_IND后,跟随AuxPtr切换到指定的数据信道(0~36),接收AUX_ADV_IND PDU。
AUX_ADV_IND中包含了:
-
AdvA:广播者地址
-
TargetA :目标设备地址(定向的关键)
-
AdvData :实际的广播数据(最多254字节,可通过
AUX_CHAIN_IND链式扩展到1650字节) -
广播模式:设置为"非连接、非扫描、定向"
12.2 为什么需要"不可连接不可扫描定向"?
这个组合看似"功能最少",实则有独特的应用价值:
① 精准定向的信息推送
某些场景下,设备只想向特定目标发送信息,且不需要任何形式的反馈或确认。例如:
-
设备A只想向设备B推送一条加密的配置指令
-
设备B只需要接收这条指令,无需回复任何确认
-
其他设备不应感知到这次通信的存在
② 隐私保护最大化
定向广播确保只有指定的目标设备才能解析广播内容。再加上不可扫描(不响应任何扫描请求),进一步降低了设备被无关扫描者发现和追踪的风险。
③ 最低功耗的单向通信
由于不监听任何响应(既不监听连接请求,也不监听扫描请求),广播者可以在发送完辅助PDU后立即关闭射频模块进入休眠,功耗达到最低。
④ 大规模网络中的定向唤醒
在包含成千上万个节点的网络中(如电子货架标签、传感器网络),广播者可以通过定向广播精准地向某一个节点发送唤醒指令或配置更新,而不需要建立连接。
13. 广播集
Advertising Set(广播集) 是蓝牙5.0引入扩展广播后,为实现多角色、并行、独立广播而设计的核心概念。
简单来说,一个广播集就是一个拥有独立参数、独立数据、独立生命周期的广播"实例"。
13.1 为什么需要广播集?
在蓝牙4.x的传统广播中,一个设备同一时间只能进行一种广播,所有广播参数(间隔、数据、功率等)都是全局共享的。如果需要切换广播内容或策略,就必须先停止当前广播,修改参数,再重新启动。
蓝牙5.0打破了这一限制。广播集让一个BLE设备能够同时运行多个相互独立的广播任务。每个广播集都像是一个独立的"虚拟广播员",拥有自己的"台词"(数据)、"语速"(间隔)和"音量"(功率),并且可以同时"发声"。
13.2 广播集的核心组成
一个完整的广播集由以下几个核心部分组成:
-
独立的参数(Parameters):每个广播集都可以独立配置广播间隔、发射功率、PHY模式(1M/2M/Coded)、是否可连接等属性。
-
独立的数据(Data):每个广播集拥有自己的广播数据(ADV Data)和扫描响应数据(Scan Response Data),内容完全独立。
-
唯一的标识(Handle & SID):
-
Advertising Handle(广播句柄):由主机(Host)在创建广播集时分配,是一个0x00到0xEF的任意数值。所有后续针对该广播集的操作(如设置数据、启动/停止广播)都需要通过这个句柄来指定。
-
Advertising SID(广播集ID):包含在广播数据包的ADI(Advertising Data Info)字段中,用于接收端识别该数据包属于哪个广播集。发送端和接收端通过SID来"对号入座"。
-
13.3 广播集的并发能力与限制
-
并发数量 :理论上,一个BLE控制器可以同时运行最多16个 广播集。但在实际开发中,具体数量受芯片、协议栈和资源配置的限制。例如,在Zephyr RTOS中,广播集的数量是可配置的(
BT_CTLR_ADV_SET),默认值通常较小。 -
可连接性限制 :虽然可以同时存在多个广播集,但可连接的广播集数量是受限的。通常情况下,同一时间只能有一个广播集是可连接的。其他广播集必须配置为不可连接模式(Non-connectable)。这是因为设备的链路层资源(如连接状态机)是有限的,无法同时处理来自多个广播集的连接请求。
14. 总结
14.1 BLE 全广播类型终极对照表
| 类别 | 子类型 / 配置 | 核心PDU / 信令 | 可连接 | 可扫描 | 定向 | 时序特征 | 最大负载 | 通信方向 | 典型场景 |
|---|---|---|---|---|---|---|---|---|---|
| 传统广播 (4.0~4.2) | 可连接可扫描非定向 | ADV_IND |
✅ 是 | ✅ 是 | ❌ 否 | 随机延迟 (advDelay) | 31 字节 | 双向 (SCAN+CONN) | 通用外设(手环、耳机) |
| 可连接定向 | ADV_DIRECT_IND |
✅ 是 | ❌ 否 | ✅ 是 | 随机/高占空比(≤3.75ms) | 0 字节 | 仅连接 | 快速重连(断连1.28秒恢复) | |
| 可扫描非定向 | ADV_SCAN_IND |
❌ 否 | ✅ 是 | ❌ 否 | 随机延迟 (advDelay) | 31 字节 | 扫描响应 | 信息咨询台(只问答不连接) | |
| 不可连接非扫描非定向 | ADV_NONCONN_IND |
❌ 否 | ❌ 否 | ❌ 否 | 随机延迟 (advDelay) | 31 字节 | 纯单向 | Beacon、信标广播 | |
| 扩展广播 (5.0+) (注1) | 可连接 + 非扫描 + 非定向 | ADV_EXT_IND + AUX_ADV_IND |
✅ 是 | ❌ 否 | ❌ 否 | 随机延迟 (advDelay) | 254B / 1650B(链式) | 仅连接 | 大数据快速连接(固件升级等) |
| 非连接 + 可扫描 + 非定向 | ADV_EXT_IND + AUX_ADV_IND |
❌ 否 | ✅ 是 | ❌ 否 | 随机延迟 (advDelay) | 254B / 1650B(链式) | 扫描响应 | 大数据广播(传输配置/长数据) | |
| 非连接 + 非扫描 + 非定向 | ADV_EXT_IND + AUX_ADV_IND |
❌ 否 | ❌ 否 | ❌ 否 | 随机延迟 (advDelay) | 254B / 1650B(链式) | 纯单向 | 大数据Beacon(高精度位置信息) | |
| 非连接 + 可扫描 + 定向 (注2) | ADV_EXT_IND + AUX_ADV_IND(含TargetA) |
❌ 否 | ✅ 是 | ✅ 是 | 随机延迟 (advDelay) | 254B / 1650B(链式) | 扫描响应(仅限目标) | 定向信息分发(特定设备获取反馈) | |
| 非连接 + 非扫描 + 定向 (注2) | ADV_EXT_IND + AUX_ADV_IND(含TargetA) |
❌ 否 | ❌ 否 | ✅ 是 | 随机延迟 (advDelay) | 254B / 1650B(链式) | 纯单向 | 定向密语(隐私保护、精准唤醒) | |
| 周期性广播 (5.0+) | 周期性广播 (PADVB) | AUX_SYNC_IND (定时列车) |
❌ 否 | ❌ 否 | ❌ 否(组播) | 严格固定 (无advDelay) | 254B / 1650B(链式) | 纯单向 | LE Audio广播音频、精准时间同步 |
| PAwR (5.4) | 带响应周期性广播 | AUX_SYNC_SUBEVENT_IND + 响应时隙 |
❌ 否(通常) | ❌ 否 | ❌ 否(子事件分组) | 严格固定 (无advDelay) | 254B / 1650B(链式) | 双向 (响应时隙) | 电子货架标签(ESL)、大规模传感器 |
14.2 注解与关键约束
-
注1(扩展广播硬性限制) :在蓝牙5.0+扩展广播中,"可连接"与"可扫描"两个标志位互斥 。因此,不存在"可连接且可扫描"的扩展广播类型。若需要同时具备这两种能力,必须回退到传统广播(
ADV_IND)。 -
注2(扩展定向新增):在传统广播中不存在"定向+可扫描"或"定向+不可连接"的组合。这两行是蓝牙5.0扩展广播通过独立标志位才实现的新功能。
-
Advertising Set(广播集) :蓝牙5.0+支持同时运行最多16个广播集,每个集可独立选择上表中的任意一种"扩展广播"配置。但同一时刻只能有一个广播集处于"可连接"状态(链路层资源限制)。