PAST (Periodic Advertising Sync Transfer) 是蓝牙 5.0 引入的核心特性之一也是 LE Audio 广播音频的关键使能技术。本文从协议原理、HCI 命令、LL 层 PDU 到代码路径完整解析 PAST 如何让第三台设备跳过扫描直接接收广播数据。------------------------------------------------------------------------------------------------------------------------------------------视频链接https://item.taobao.com/item.htm?id1001969040805mi_id000032T4qZX9WZoRwX6YbxlNUaZOfOI6XoxDx0jxsfnwlEcspma21xtw.29178619.0.0Le Audio文章目录还在为蓝牙BLE Audio的学习苦恼吗安排下让你一文彻底了解Le Audio蓝牙低功耗音频的技术-CSDN博客---------------------------------------------------------------------------------------------------------------------------------一、什么是 PASTPAST 全称Periodic Advertising Sync Transfer周期广播同步转移定义在 Bluetooth Core Spec Vol 6, Part B, Section 4.4.5。一句话概括设备 B 把自己已经建立的 Periodic Advertising 同步信息通过 ACL 连接转移给设备 C使 C 无需扫描就能直接接收设备 A 的周期广播。PAST 解决的核心矛盾是问题传统方式PAST 方式发现周期广播必须扫描 ADV_EXT_IND → 跟随 AuxPtr → 接收 AUX_SYNC_IND由已同步设备直接转移 SyncInfo功耗扫描占空比高耳机类设备无法承受零扫描Controller 直接在目标时刻唤醒发现时间需要数个广播周期即时一次 ACL PDU 传输即完成可靠性扫描可能错过 AUX_SYNC_IND通过 ACL 可靠传输二、背景Periodic Advertising 的工作方式理解 PAST 之前必须先理解 Periodic Advertising周期广播的常规同步过程。2.1 周期广播的三层结构Device A (Advertiser) │ ├─ Primary ADV: ADV_EXT_IND (PDU on ch 37/38/39) │ └─ AuxPtr: 指向 Secondary 信道 │ ├─ Secondary ADV: AUX_SYNC_IND (PDU on secondary ch) │ └─ SyncInfo: 周期广播的同步参数 │ └─ TXPower, AdvDataInfo 等 │ └─ Periodic ADV: ADV_PERIODIC (在 SyncInfo 指定的信道/时间发送) └─ 携带 BIGInfo (如果存在 BIG) └─ 携带周期性广播数据2.2 常规同步流程无 PASTScanner 在主信道37/38/39扫描收到ADV_EXT_INDADV_EXT_IND 中的AuxPtr字段指向 Secondary 信道Scanner 跳转到 Secondary 信道接收AUX_SYNC_INDAUX_SYNC_IND 中的SyncInfo包含周期广播的完整调度信息Scanner 用 SyncInfo 计算下一次 Periodic ADV 的时间和信道Scanner 在正确时间唤醒接收ADV_PERIODICPDU问题步骤 1-4 需要持续扫描功耗极高。对于 TWS 耳机这种电池容量极小的设备几乎不可行。三、三设备广播接收原理核心这是本文的核心问题怎样让第三台设备C收到广播者A的广播数据3.1 三种设备角色角色设备说明BroadcasterDevice A发送 Periodic Advertising 的广播者如 TV、手机Scanner / PAST SenderDevice B已扫描并同步 A 的周期广播负责转移同步信息如手机PAST ReceiverDevice C接收 B 转移的 SyncInfo免扫描直接接收 A 的广播如耳机3.2 完整流程7 步阶段一B 同步 A步骤 ①②① B 扫描发现 A 的 ADV_EXT_IND → AUX_SYNC_IND从中提取SyncInfo② B 的 Controller 建立同步生成HCI_LE_Periodic Advertising Sync Established事件Host 获得sync_handle阶段二B-C 建立 ACL 连接步骤 ③③ B 与 C 之间必须先有 BLE ACL 连接。PAST 转移的 LL_PERIODIC_SYNC_IND PDU 就走在这个连接上阶段三PAST 转移步骤 ④⑤④ B 的 Host 发送HCI_LE_Periodic_Advertising_Sync_Transfer命令 → B 的 Controller 在 ACL 连接上发送LL_PERIODIC_SYNC_INDPDU → C 的 Controller 接收⑤ C 的 Controller 自动解析 PDU 中的 SyncInfo建立与 A 的周期广播同步生成Sync Established事件上报 Host阶段四C 直接接收 A 的广播步骤 ⑥⑦⑥ C 的 Controller 根据 SyncInfo在正确的时间、正确的信道唤醒直接接收 A 的ADV_PERIODICPDU——完全无需扫描⑦ C 从 Periodic Advertising 数据中读取BIGInfo同步 BIGBroadcast Isochronous Group接收BISBroadcast Isochronous Stream音频/数据流3.3 为什么 C 能直接接收——原理拆解这是理解 PAST 的关键。Periodic Advertising 本质上是一个确定性调度系统SyncInfo 提供的信息 ├── Offset → 多久之后开始下一次广播 → 解决 WHEN ├── Interval → 每隔多久广播一次 → 解决 PERIODICITY ├── Channel Map→ 用哪些 RF 信道 → 解决 WHERE ├── Access Addr→ 广播的接入地址 → 解决 FILTER ├── CRC Init → CRC 初始值 → 解决 DECODE └── Event Counter → 当前事件序号 → 解决 CHANNEL HOPPING有了这 6 个参数C 的 Controller 能计算下一次广播的绝对时间参考 ACL 连接的锚点 Offset计算跳频序列用 Event Counter 和 Channel Map 推导下一次使用哪个信道在目标时刻唤醒Radio 直接调谐到目标信道过滤和解码用 Access Address 过滤用 CRC Init 校验类比传统扫描像「不知道电视节目表逐个频道翻找」PAST 像「朋友直接把节目表和频道号给你你到点打开就行」。3.4 关键细节PAST 只转移 SyncInfo不转移 BIGInfo一个常见误区PAST 转移的是 Periodic Advertising 的同步信息不是BIGInfo。PAST 转移后C 可以直接接收 Periodic Advertising但 BIGInfo 在 Periodic Advertising 的数据载荷中C 仍需接收至少一个 Periodic ADV PDU 才能获取 BIGInfo获取 BIGInfo 后C 才能同步 BIG 并接收 BIS 数据四、SyncInfo 结构详解SyncInfo 是 PAST 的核心载荷定义在 Core Spec Vol 6, Part B, Section 2.3.4.3字段大小说明Sync Packet Offset13 bits距参考点的时间偏移30us 或 300us 单位Offset Units1 bit0 30us1 300usOffset Adjust1 bit若为 1偏移量额外增加 2^13 × 30usInterval12 bits广播间隔单位 1.25ms范围 7.5ms ~ 81.91875sChannel Map37 bitsbit n 1 表示信道 n 被使用SCA3 bitsSleep Clock Accuracy发送方时钟精度等级Access Address32 bitsPeriodic Advertising train 的接入地址CRC Init24 bitsCRC 初始值Event Counter16 bits当前周期广播事件计数器Channel Hopping 计算C 的 Controller 收到 SyncInfo 后用以下公式计算下一个事件的信道channelIndex (EventCounter 1) mod 37 // 如果 channelIndex 在 Channel Map 中被使用 → 使用该信道 // 否则 → 使用 Channel Map 中 channelIndex 的下一个可用信道每次收到一个 ADV_PERIODICEvent Counter 递增C 据此计算下一次的信道。五、PAST 协议详解5.1 涉及的 HCI 命令发送方Device B命令作用HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Parameters配置 PAST 参数skip允许跳过的事件数、sync_timeout同步超时、CTE 类型HCI_LE_Periodic_Advertising_Sync_Transfer执行转移指定 conn_handle到 C 的 ACL和 sync_handle要转移的同步接收方Device C命令作用HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Receive_Enable使能 PAST 接收mode1 使能指定 conn_handle到 B 的 ACL、skip、sync_timeout生成的 HCI 事件事件触发条件HCI_LE_Periodic_Advertising_Sync_Transfer_ReceivedC 的 Controller 收到 LL_PERIODIC_SYNC_IND 后上报 HostHCI_LE_Periodic Advertising Sync EstablishedC 成功建立同步后上报附带新的 sync_handle5.2 LL_PERIODIC_SYNC_IND PDU这是 PAST 在 LL 层的实际传输载体定义在 Core Spec Vol 6, Part B, Section 2.4.2.12。LL_PERIODIC_SYNC_IND PDU 结构 ┌──────────────────────┬──────────┬────────────────┬──────────────┬─────┬──────────────────┬─────────────┬───────────────┐ │ ID (1 byte) │ Reserved │ SyncInfo │ Channel Map │ PHY │ Access Address │ CRC Init │ Event Counter │ │ (0x00 Sync Transfer)│ │ (17 bytes) │ (5 bytes) │(1B) │ (4 bytes) │ (3 bytes) │ (2 bytes) │ └──────────────────────┴──────────┴────────────────┴──────────────┴─────┴──────────────────┴─────────────┴───────────────┘关键点这个 PDU 在 B-C 的 ACL 连接上以LL Control PDU形式发送B 的 Controller 负责 PDU 构造和发送Host 不需要参与 LL 层细节C 的 Controller 负责解析 PDU 并自动建立同步5.3 PAST 两种模式模式说明使用场景Sync TransferB 转移自己已有的 sync_handleB 是扫描者帮助 C 同步到 ASet Info TransferB 转移自己的广播 Set 信息B 本身是广播者直接告诉 C 自己的周期广播参数Set Info Transfer 用HCI_LE_Periodic_Advertising_Set_Info_Transfer命令适用于「手机既是广播者又想把广播转给耳机」的场景。六、代码路径6.1 BlueZ (Linux)内核态: net/bluetooth/hci_core.c → HCI 命令发送框架 net/bluetooth/hci_event.c → LE Periodic Advertising Sync Established 事件处理 LE Periodic Advertising Sync Transfer Received 事件处理 net/bluetooth/hci_sync.c → HCI 命令同步执行框架 用户态: src/shared/ad.c → 广播数据解析 src/shared/hci-cmd.c → HCI 命令封装 src/android/hal-hci.c → HAL 层接口 monitor/btmon.c → HCI 日志监控工具 mgmt 接口: MGMT_OP_ADD_EXT_ADV_PARAMS → 配置扩展广播 // PAST 相关通过 mgmt 命令触发关键调试用btmon抓 HCI log搜索LE Periodic Advertising Sync Transfer和LL_PERIODIC_SYNC_IND。6.2 Bluedroid (Android)system/bt/stack/hcic/ hciblecmds.c → HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Parameters HCI_LE_Periodic_Advertising_Sync_Transfer HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Receive_Enable hcicmd.c → HCI 命令发送 system/bt/stack/btm/ btm_ble_5_gap.c → BLE 5.x GAP 接口 btm_ble_api.c → BTM_BlePeriodicAdvSyncTransfer 等应用层 API system/bt/stack/btu/ hcitask.c → HCI 任务调度事件分发 system/bt/main/ stack_config.c → 协议栈配置 应用层: frameworks/base/core/java/android/bluetooth/ BluetoothAdapter.java → 公共 API 入口 BluetoothLeBroadcastAssistant.java → LE Audio Broadcast AssistantPAST 调用方七、实际应用场景7.1 LE Audio 广播音频最核心场景这是 PAST 存在的根本原因。场景机场候机厅广播音频 Device A 机场广播发射器发送 Periodic ADV BIG BIS 音频流 Device B 乘客手机Broadcast Assistant扫描发现 A Device C 乘客 TWS 耳机Broadcast Sink接收音频 流程 1. 手机扫描发现机场广播的 Periodic ADV 2. 手机同步 Periodic ADV读取 BIGInfo 3. 手机通过 BASSBroadcast Audio Scan Service写入耳机的 BASS Characteristic 4. 手机通过 PAST 将 SyncInfo 转移给左耳 5. 手机通过 PAST 将 SyncInfo 转移给右耳 6. 左右耳直接接收 A 的 BIS 音频流无需扫描为什么耳机不能自己扫描TWS 耳机电池通常 40-60mAh持续扫描会耗尽电量扫描占空比可能需要 10-30%PAST 方式仅需在 Periodic ADV 时刻唤醒0.1%耳机的天线和 Radio 性能通常弱于手机7.2 电子货架标签ESLDevice A ESL 网关广播价格更新数据 Device B 手机 App管理标签扫描发现 A Device C 电子货架标签通过 PAST 接收更新数据 优势标签平时深度睡眠仅在 PAST 转移后唤醒接收电池寿命可达数年7.3 传感器数据广播Device A 环境传感器周期广播温湿度数据 Device B 网关已同步 A Device C 新加入的显示设备通过 PAST 快速同步 优势新设备无需扫描即可加入数据接收部署灵活八、调试技巧8.1 用 btmon 抓 PAST 流程# 抓取 HCI 日志 sudo btmon -w past_debug.log # 过滤 PAST 相关命令和事件 btmon -r past_debug.log | grep -E Periodic|Sync Transfer|PERIODIC_SYNC关键日志标识 HCI_LE_Periodic_Advertising_Sync_Transfer→ B 发起转移 HCI_LE_Periodic Advertising Sync Established→ C 成功同步LL_PERIODIC_SYNC_IND→ LL 层 PDU 传输8.2 常见问题排查问题可能原因排查方法C 收不到 PASTB-C 之间没有 ACL 连接检查连接状态hcitool leacl确认C 同步建立后立即丢失sync_timeout 太短检查Set_Periodic_ADV_Sync_Transfer_Receive_Enable的 timeout 参数C 同步成功但收不到 ADV_PERIODICA 已停止广播确认 A 仍在发送 Periodic ADVSyncInfo Offset 计算错误ACL 锚点参考不正确检查 LL_PERIODIC_SYNC_IND 的发送时间点C 的 Event Counter 与 A 不同步PAST 转移时延迟过大检查 ACL 连接的 latency 和 timeout8.3 PTS 测试PAST 相关的 PTS 测试用例PAST/SR/BI-01-CSync Transfer 基本流程PAST/SR/BI-02-CSet Info Transfer 流程PAST/SR/BI-03-CPAST 参数配置PAST/CG/BI-01-CController 在 ACL 上发送 LL_PERIODIC_SYNC_IND九、自研协议栈实现要点对于你团队自研蓝牙协议栈 HostPAST 实现需要关注9.1 Host 层职责Host 需要实现的: ├── HCI 命令封装和发送 │ ├── LE_Set_Periodic_ADV_Sync_Transfer_Parameters │ ├── LE_Periodic_ADV_Sync_Transfer │ ├── LE_Set_Periodic_ADV_Sync_Transfer_Receive_Enable │ └── LE_Periodic_ADV_Set_Info_Transfer ├── HCI 事件处理 │ ├── Periodic_Advertising_Sync_Transfer_Received │ └── Periodic_Advertising_Sync_Established ├── sync_handle 管理 │ ├── 维护 sync_handle → 广播源映射表 │ └── PAST 转移后 C 侧生成新 sync_handle └── 上层接口GATT BASS / 应用层 API Host 不需要实现的 (Controller 负责): ├── LL_PERIODIC_SYNC_IND PDU 构造和解析 ├── SyncInfo 中 Offset 的精确时间计算 ├── Channel Hopping 算法 └── Radio 调度何时唤醒、调谐到哪个信道9.2 关键实现细节sync_handle 生命周期管理PAST 转移后B 侧的 sync_handle 仍然有效B 继续同步C 侧生成一个新的 sync_handle。两者独立互不影响。skip 和 timeout 参数skip允许 C 连续错过多少个 Periodic ADV 事件而不丢失同步sync_timeout超过此时间未收到任何 ADV_PERIODIC 则同步丢失范围 10ms~163.84s建议初始值skip 0sync_timeout 1000ms根据实际广播间隔调整Service Data 字段HCI_LE_Periodic_Advertising_Sync_Transfer中的 16-bit Service Data 由 B 的 Host 设置C 的 Host 通过Sync_Transfer_Received事件接收。可携带应用层元数据如广播源 ID。与 BASS 的联动在 LE Audio 场景中PAST 通常由 BASSBroadcast Audio Scan Service触发。B 的 Host 写入 C 的 BASS Add Source Characteristic 后自动触发 PAST 流程。十、总结维度传统扫描同步PAST 转移同步功耗高持续扫描极低仅目标时刻唤醒发现时间数百ms~数秒即时一次 ACL PDU可靠性依赖无线扫描ACL 可靠传输适用设备手机、网关耳机、标签、传感器蓝牙版本5.05.0依赖条件无B-C 间有 ACL 连接PAST 的本质是把「发现」和「接收」解耦。B 负责「发现」扫描C 负责「接收」直接听。中间通过 ACL 连接把同步信息可靠地传递过去。对于你团队的三个工作板块产测陪测PAST 测试用例是产线必测项LE Audio 模组BringupBlueZ/Bluedroid 的 PAST 流程调试是客户常见问题自研协议栈PAST 的 Host 层实现相对简单HCI 命令事件管理但 Controller 侧的 SyncInfo 时间计算是难点参考文档Bluetooth Core Specification v5.4, Vol 6, Part B, Section 4.4.5 (PAST), Section 2.4.2.12 (LL_PERIODIC_SYNC_IND)