【LE Audio】BAP协议精讲[2]: 蓝牙LE音频配置核心逻辑

在蓝牙LE音频生态中，BAP协议的配置是整个技术体系的骨架——它定义了设备如何分工、如何协作、如何搭建通信链路，直接决定了音频传输的可行性、稳定性和灵活性。如果把BAP协议看作一套完整的音频交通系统，那么配置就是交通规则、道路规划和角色分工的总纲，规定了谁是“司机”、谁是“调度员”、道路该如何铺设、不同车辆如何共存。本文就深入拆解BAP配置的核心逻辑，从协议栈、角色、协作关系到限制条件，全面搞懂LE音频设备的配置说明书。

一、协议栈架构：LE音频的分层协作体系

任何协议的配置都离不开底层架构的支撑，BAP的协议栈就像一栋“多层建筑”，每层都有明确的职责，层层协作才能实现音频流的有效控制。

1.1 协议栈分层解析

BAP的协议栈遵循蓝牙LE的通用分层逻辑，但针对音频场景做了针对性增强，从下到上依次为：

• Link Layer（链路层）：最底层的无线信号管家，负责处理无线传输、同步、加密等核心功能，是音频流低延迟、高可靠传输的基础。比如单播的CIS（连接同步流）、广播的BIS（广播同步流），其建立和维护都依赖链路层的特征支持。
• HCI（主机控制器接口）：主机与控制器的沟通桥梁，负责传递上层指令到链路层，比如配置CIG（连接同步组）、BIG（广播同步组）的参数，都需要通过HCI指令实现。
• L2CAP（逻辑链路控制和适配协议）：数据分组与流控管理者，为上层协议提供数据分组、重组和流量控制能力，EATT（增强型ATT）就基于L2CAP的增强流控模式实现。
• ATT/EATT（属性协议/增强型属性协议）：数据传输通道，ATT是基础版，EATT是增强版，支持更高的传输效率和更大的MTU（最大传输单元），BAP要求关键角色支持最小64 octets的ATT_MTU，确保配置数据能高效传输。
• GATT（通用属性协议）：设备数据交互字典，定义了服务、特征值的读写、通知等交互方式，BAP的核心服务（ASCS、PACS、BASS）都通过GATT实现属性暴露和交互。
• BAP（基础音频协议）：音频业务总指挥，协调上层的三个核心服务，定义音频流的控制逻辑，是配置逻辑的核心层。
• PACS/ASCS/BASS（辅助服务）：专项功能助手——PACS负责公示音频能力，ASCS负责音频流控制，BASS负责广播扫描，三者是BAP实现具体功能的关键支撑。
• GAP（通用访问协议）：设备社交礼仪，定义设备发现、连接、角色协商的基础规则，BAP的所有角色都需要遵循GAP的角色规范。

1.2 分层协作的核心逻辑

这套协议栈的协作遵循“自上而下指令传递，自下而上数据反馈”的原则：

• 上层（BAP）明确音频传输需求（如单播/广播、声道数、延迟要求）；
• 中间层（GATT/ATT/EATT）负责将需求转化为可传输的属性数据和指令；
• 底层（L2CAP/Link Layer）负责执行指令，搭建物理传输链路，确保数据实时传输。

举个实际场景：手机（Unicast Client）想连接耳机（Unicast Server）播放音乐——BAP层决定采用单播模式，ASCS负责发起音频流控制指令，GATT通过ATT/EATT传递配置参数，链路层建立CIS链路，最终实现音频数据的低延迟传输。

协议中明确规定：“This profile requires Bluetooth LE”，意味着整个配置体系完全基于蓝牙LE技术，充分利用其低功耗、低延迟的特性，这也是BAP能适配真无线耳机、智能穿戴等设备的核心原因。

二、六大核心角色：LE音频的分工体系

BAP定义了六个角色，覆盖单播和广播两大场景，每个角色都有明确的职责边界和行为规范，就像一支分工明确的音频团队，各自承担不同的任务。

2.1 单播场景：一对一的精准协作

单播场景面向一对一音频传输（如手机连耳机、电脑连音箱），核心角色是Unicast Server和Unicast Client。

（1）Unicast Server：音频服务的提供者

Unicast Server是单播场景的被动方，但却是音频服务的核心支撑，其核心职责包括：

• 发送广告包，让Unicast Client能发现自己，比如耳机开机后持续发送广告，告知周边设备“我是可连接的音频设备”；
• 暴露音频能力属性，通过PACS服务公示自己支持的编解码格式、采样率、声道数等，比如耳机告知手机“我支持16kHz采样率的LC3编解码”；
• 暴露ASE（音频流端点）属性，供Unicast Client配置和控制音频流，ASE就像音频流的控制接口，记录着音频流的状态、参数；
• 接受CIG建立请求，允许Unicast Client创建包含一个或多个CIS的CIG，用于传输单播音频流；
• 支持CIS的终止，当音频传输结束时，可主动或被动终止CIS链路。

协议中对其职责的核心定义是：“exposes attributes that the Unicast Client uses to discover, configure, and control ASEs”，这句话精准概括了Unicast Server的核心价值——通过暴露属性，为Unicast Client提供“可发现、可配置、可控制”的基础。

（2）Unicast Client：音频服务的发起者

Unicast Client是单播场景的主动方，负责发起连接和配置，核心职责包括：

• 扫描广告包，发现周边的Unicast Server，比如手机扫描周边的耳机设备；
• 发现Unicast Server的音频能力和音频角色，通过读取PACS服务的属性，判断对方是否支持自己需要的音频传输需求；
• 配置和控制ASE，通过ASCS服务的ASE控制点，设置编解码参数、QoS参数，启动或停止音频流；
• 建立和终止CIG，根据音频需求创建包含CIS的CIG，比如为音乐播放创建单方向CIS，为通话创建双向CIS；
• 监控连接状态，当链路中断时，可尝试重新建立连接或终止CIS。

单播场景的角色交互逻辑很清晰：Unicast Client主动寻找和配置，Unicast Server被动响应和提供服务，两者配合完成一对一的音频传输。

2.2 广播场景：一对多的高效分发

广播场景面向一对多音频传输（如商场背景音乐、会议音频同步），核心角色是Broadcast Source、Broadcast Sink、Broadcast Assistant和Scan Delegator，四个角色形成发射-接收-辅助-代理的完整链路。

（1）Broadcast Source：广播音频的发射台

作为广播场景的核心发起者，其职责是让多个接收设备能收到高质量音频，具体包括：

• 配置和建立BIG，每个BIG包含一个或多个BIS，用于传输不同声道或不同内容的广播音频流，比如智能音箱创建一个BIG，包含左声道BIS和右声道BIS；
• 传输广播配置数据，通过广告包传递BASE（广播音频源端点）结构，告知接收设备编解码格式、声道配置等关键信息；
• 传输同步数据，让接收设备能快速同步到广播流，确保多设备播放同步。

协议中要求：“Broadcast Source transmits data that enables devices to discover and receive broadcast Audio Streams”，意味着Broadcast Source不仅要发音频，还要发指南，让接收设备知道如何接收和解析音频。

（2）Broadcast Sink：广播音频的接收端

相当于广播场景的收音机，负责接收和播放广播音频，核心职责包括：

• 发现广播配置数据，扫描并解析Broadcast Source发送的BASE结构，获取音频流参数；
• 接收广播音频流，同步到BIG中的BIS，解码并播放音频；
• 暴露自身音频能力，通过PACS服务让Broadcast Assistant能获取其支持的音频格式，以便Assistant推荐合适的广播流。

（3）Broadcast Assistant：广播场景的中间人

Broadcast Assistant是广播场景的协调者，解决低功耗设备的扫描负担问题，核心职责包括：

• 发现Broadcast Sink的音频能力，通过读取PACS服务，了解接收设备能支持的广播格式；
• 扫描广播源，代替Scan Delegator（通常是低功耗设备）扫描周边的Broadcast Source，获取广播配置和同步信息；
• 传输关键数据给Scan Delegator，包括广播流的SyncInfo（同步信息）和Broadcast_Codes（解密密钥），帮助低功耗设备快速接入广播流；
• 请求Scan Delegator接收广播，比如通知耳机（Scan Delegator）有一个符合你能力的广播流，可同步接收。

（4）Scan Delegator：广播场景的低功耗代理

通常集成在低功耗设备（如耳机、智能手表）中，核心职责是委托他人扫描，自身专注接收，具体包括：

• solicits Broadcast Assistant，主动请求Broadcast Assistant代为扫描广播源，减少自身扫描带来的功耗；
• 接收Broadcast Assistant传输的数据，包括SyncInfo和Broadcast_Codes，无需自己扫描即可快速同步到广播流；
• 告知Broadcast Assistant自己的状态，比如是否准备好接收广播、是否需要解密密钥。

广播场景的角色交互逻辑是：Broadcast Source发射音频和配置，Broadcast Assistant扫描+协调，Scan Delegator代理+接收，Broadcast Sink解码+播放，四个角色分工协作，既保证了广播的覆盖范围，又兼顾了低功耗设备的续航需求。

2.3 角色的核心特征：灵活且互补

BAP的角色设计有两个关键特点：

• 角色可共存：除了“同一连接中不能同时是Unicast Client和Unicast Server”，其他角色组合均可共存，比如一个设备可以同时是Broadcast Source和Broadcast Assistant；
• 职责不重叠：每个角色的核心职责都有明确边界，避免功能冲突，比如配置音频流的职责只属于Unicast Client和Broadcast Source，其他角色不参与。

三、角色与服务的绑定关系：协作的底层规则

BAP的角色并非孤立存在，每个角色都与特定的GATT角色（Server/Client）和核心服务（PACS/ASCS/BASS）绑定，这种绑定关系是设备间能无障碍沟通的关键。

3.1 角色与GATT角色的绑定

GATT角色分为Server和Client，BAP明确规定了每个角色的GATT角色要求：

• Unicast Server：必须是GATT Server，因为需要暴露属性（如音频能力、ASE）供Unicast Client读取和配置；
• Unicast Client：必须是GATT Client，因为需要主动读取Unicast Server的属性，发送配置指令；
• Broadcast Source：无GATT角色要求，因为广播无需建立连接，不需要通过GATT交互；
• Broadcast Sink：必须是GATT Server，需要暴露自身音频能力供Broadcast Assistant读取；
• Broadcast Assistant：必须是GATT Client，需要主动读取Broadcast Sink和Scan Delegator的属性；
• Scan Delegator：必须是GATT Server，需要暴露BASS服务的属性供Broadcast Assistant交互。

这种绑定关系的核心逻辑是：需要暴露属性供他人读取的角色，必须是GATT Server；需要主动读取他人属性的角色，必须是GATT Client。比如耳机（Unicast Server）作为GATT Server，暴露音频能力；手机（Unicast Client）作为GATT Client，读取这些能力并配置。

3.2 角色与核心服务的绑定

BAP的三个核心服务（ASCS、PACS、BASS）与角色的绑定关系也有明确规定（对应服务支持要求表）：

• ASCS：Unicast Server必须是ASCS Server（暴露ASE控制接口），Unicast Client必须是ASCS Client（发送控制指令）；
• PACS：Unicast Server和Broadcast Sink必须是PACS Server（暴露音频能力），Unicast Client必须是PACS Client（读取音频能力），Broadcast Assistant可选择作为PACS Client；
• BASS：Scan Delegator必须是BASS Server（暴露广播扫描相关属性），Broadcast Assistant必须是BASS Client（发送扫描请求和接收扫描结果）。

以单播场景为例：Unicast Client（手机）通过PACS Client读取Unicast Server（耳机）的音频能力，通过ASCS Client发送音频流配置指令，Unicast Server通过ASCS Server接收指令并执行，整个交互过程完全基于服务与角色的绑定关系。

3.3 角色交互的可视化逻辑

(1)单播交互

Unicast Client ↔（ASCS/PACS）↔ Unicast Server，两者通过GATT Client/Server的关系，借助ASCS和PACS实现能力发现和流控制；

(2)广播基础交互

Broadcast Source →（广告包）→ Broadcast Sink，无需GATT交互，直接通过广播包传递配置；

(3)广播辅助交互

Broadcast Assistant ↔（PACS）↔ Broadcast Sink，Broadcast Assistant ↔（BASS）↔ Scan Delegator，通过GATT交互实现能力发现和扫描代理。

这种交互逻辑既保证了单播场景的精准控制，又兼顾了广播场景的高效分发，同时通过辅助角色解决了低功耗设备的扫描难题。

四、并发与拓扑限制：配置的边界条件

BAP的配置并非无限制灵活，而是存在明确的并发和拓扑限制，这些限制源于蓝牙LE的底层技术特性，是保证系统稳定性的关键。

4.1 并发限制：避免角色冲突

协议中明确规定：

“A device shall not concurrently occupy the Unicast Client role and Unicast Server role in a connection to a single device”。

• 原因：Unicast Client对应LL Central角色，Unicast Server对应LL Peripheral角色，而蓝牙LE的同一连接中，两个设备不能同时是LL Central角色，这是底层链路层的技术约束；
• 实际影响：比如手机和耳机建立连接时，手机只能是Unicast Client，耳机只能是Unicast Server，不能互换，也不能同时承担两个角色；
• 例外情况：除了这一对角色，其他角色组合均可并发，比如一个设备可以同时是Broadcast Source和Broadcast Assistant，既发送广播，又协助其他设备扫描。

此外，协议还规定：

“A combination of BAP profile roles on a GATT Server shall have no more than one GATT service defined for the individual profile roles”，

即一个GATT Server上的多个BAP角色，每个角色只能对应一个GATT服务，避免服务冲突。

4.2 拓扑限制：角色与GAP角色的映射约束

BAP角色必须与GAP角色严格映射，GAP角色定义了设备在蓝牙LE中的基础行为模式，这种映射关系决定了设备的拓扑位置（主动/被动、发射/接收）：

• Unicast Client：必须使用GAP Central角色，因为需要主动发起连接，扫描Unicast Server的广告；
• Unicast Server：必须使用GAP Peripheral角色，因为需要被动接受连接，发送广告供Client发现；
• Broadcast Source：必须使用GAP Broadcaster角色，因为需要持续发送广播包，无需建立连接；
• Broadcast Sink：扫描时使用GAP Observer角色（监听广播包），暴露能力时使用GAP Peripheral角色（接受Assistant连接），接收音频时使用GAP Observer角色；
• Broadcast Assistant：扫描时使用GAP Observer/Central角色（发现广播源和Scan Delegator），建立连接时使用GAP Central角色（主动连接Scan Delegator）；
• Scan Delegator：solicits时使用GAP Peripheral角色（发送广告供Assistant发现），接收数据时使用GAP Central/Peripheral角色。

这种映射关系的核心是行为匹配：需要主动发起连接或扫描的角色，对应GAP Central/Observer角色；需要被动接受连接或发送广告的角色，对应GAP Peripheral/Broadcaster角色。

举个例子：Broadcast Sink（耳机）在寻找广播源时，是GAP Observer角色，默默监听周边的广播包；当需要让Broadcast Assistant获取自己的音频能力时，切换为GAP Peripheral角色，发送广告供Assistant连接。

4.3 限制的实际意义

这些限制并非束缚，而是为了避免技术冲突，保证设备间的互操作性：

• 并发限制避免了链路层角色冲突，确保连接稳定；
• 拓扑限制明确了设备的行为模式，让不同厂商的设备都能遵循同一套交互逻辑，避免出现主动方找不到被动方、接收方无法监听发射方的问题。

五、传输依赖：音频配置的通信基础

BAP的所有配置交互和音频传输，都依赖特定的传输方式，这些传输依赖是配置能落地的通信通道。

5.1 核心传输技术：蓝牙LE

协议明确要求：“This profile requires Bluetooth LE”，即BAP完全基于蓝牙LE技术，不支持传统蓝牙BR/EDR。这是因为蓝牙LE具有低功耗、低延迟、支持同步信道（LE Isochronous Channels）的特性，能满足音频传输的核心需求：

• 低功耗：适配真无线耳机、智能穿戴等电池供电设备；
• 低延迟：同步信道能提供微秒级的传输延迟，保证音频实时性；
• 多连接支持：支持同时建立多个CIS/BIS链路，适配多声道、多设备场景。

5.2 ATT/EATT承载要求

BAP要求关键角色（Unicast Client/Server、Broadcast Sink/Assistant、Scan Delegator）必须支持ATT或EATT承载：

• ATT（非增强型）：适用于数据量小、交互简单的场景，比如读取设备的基础音频能力；
• EATT（增强型）：基于L2CAP的增强流控模式，支持更高的传输效率和更大的MTU，适用于大数据量交互，比如配置复杂的多声道音频参数。

协议还规定：“The Unicast Server shall support a minimum ATT_MTU of 64 octets”，即Unicast Server的ATT_MTU最小为64字节，这是为了确保配置参数（如编解码配置、QoS参数）能一次性传输，避免分片导致的延迟和错误。

5.3 传输的可靠性保障

BAP通过两层机制保障传输可靠性：

• 链路层保障：LE同步信道（CIS/BIS）提供面向连接（单播）或无连接（广播）的可靠传输，支持重传机制（单播）和抗干扰设计；
• 应用层保障：GATT的通知、确认机制，确保配置指令的接收和执行状态能被反馈，比如Unicast Client发送配置指令后，会等待Unicast Server的通知确认，避免配置失败。

六、配置逻辑的实际应用场景

BAP的配置逻辑并非抽象的规则，而是深度适配实际应用场景，以下两个典型场景能直观体现配置的核心价值：

6.1 场景一：手机连接真无线耳机（单播）

角色分配：手机=Unicast Client，耳机=Unicast Server；

配置流程：

1. 耳机（Unicast Server）启动后，以GAP Peripheral角色发送广告，暴露ASCS和PACS服务；
2. 手机（Unicast Client）以GAP Central角色扫描广告，发现耳机；
3. 手机通过GATT Client读取耳机的PACS属性，获取其支持的音频能力（如16kHz LC3编解码）；
4. 手机通过ASCS Client发送配置指令，设置编解码参数和QoS参数（如低延迟模式）；
5. 手机建立CIG，包含一个CIS链路；
6. 耳机接受CIS建立请求，切换到Streaming状态，开始接收音频数据。

6.2 场景二：智能音箱广播音乐到多个耳机（广播）

角色分配：智能音箱=Broadcast Source，耳机=Broadcast Sink+Scan Delegator，手机=Broadcast Assistant；

配置流程：

1. 智能音箱（Broadcast Source）以GAP Broadcaster角色发送广告，包含BASE结构（编解码、声道配置）；
2. 耳机（Scan Delegator）以GAP Peripheral角色发送广告，请求Broadcast Assistant代为扫描；
3. 手机（Broadcast Assistant）以GAP Central角色扫描到耳机和智能音箱，读取耳机的PACS属性（确认支持的格式）；
4. 手机获取智能音箱的广播配置和SyncInfo，传输给耳机；
5. 手机传输Broadcast_Codes（如果加密）给耳机；
6. 耳机（Broadcast Sink）以GAP Observer角色同步到智能音箱的BIG，解码并播放音频。

这两个场景完美体现了BAP配置的灵活性和实用性——单播场景注重精准控制，广播场景注重高效分发，且都通过角色分工、服务绑定和传输保障，实现了高质量的音频传输。

七、随堂测试

题目：请简述BAP协议定义的六大角色及其核心职责，并说明单播与广播场景的角色组合。

答案：BAP的六大角色及核心职责如下：

1. Unicast Server：发送广告、暴露音频能力和ASE、接受CIG建立，是单播场景的服务提供者；
2. Unicast Client：扫描广告、发现设备能力、配置ASE和CIG，是单播场景的服务发起者；
3. Broadcast Source：配置BIG、传输广播配置和音频流，是广播场景的发射者；
4. Broadcast Sink：发现广播配置、接收并解码音频流，是广播场景的接收者；
5. Broadcast Assistant：扫描广播源、读取Broadcast Sink能力、传输SyncInfo和Broadcast_Codes，是广播场景的辅助者；
6. Scan Delegator：委托Broadcast Assistant扫描、接收同步数据，是低功耗设备的扫描代理。

角色组合：

• 单播场景：Unicast Client + Unicast Server；
• 广播场景：Broadcast Source + Broadcast Sink + Broadcast Assistant + Scan Delegator（低功耗设备需Scan Delegator，否则可直接Broadcast Source + Broadcast Sink）。

题目：BAP协议中角色与GATT角色的绑定规则是什么？请举例说明这种绑定的必要性。

答案：绑定规则核心：

1. 需要暴露属性供他人读取的角色，绑定为GATT Server（如Unicast Server、Broadcast Sink、Scan Delegator）；
2. 需要主动读取他人属性的角色，绑定为GATT Client（如Unicast Client、Broadcast Assistant）；
3. 无需GATT交互的角色，无GATT角色要求（如Broadcast Source）。

必要性举例：Unicast Server绑定为GATT Server，需暴露音频能力（PACS）和ASE（ASCS）属性；Unicast Client绑定为GATT Client，需主动读取这些属性并发送配置指令。若没有这种绑定，设备间无法实现属性交互，导致能力发现和流控制无法完成，单播音频传输无法建立。

题目：BAP协议的并发限制有哪些？请说明限制的技术原因。

答案：

BAP的核心并发限制是：同一设备在与单个设备的连接中，不能同时担任Unicast Client和Unicast Server角色。

技术原因：Unicast Client对应蓝牙LE的LL Central角色，Unicast Server对应LL Peripheral角色；而蓝牙LE的底层链路层规定，同一连接中两个设备不能同时担任LL Central角色，否则会导致链路冲突，无法建立稳定连接。其他角色组合无并发限制，因为不会引发LL角色冲突。

问题：BAP中Unicast Client和Unicast Server的主要区别是什么？请结合应用场景说明。

答案：

Unicast Client是GATT客户端，负责发起连接、发现Server的音频能力，并配置音频流。例如，智能手机作为Client，连接无线耳机（Server）进行通话。Unicast Server是GATT服务器，暴露音频编解码能力和流端点，等待Client连接。主要区别在于角色主动性：Client主动扫描和控制，Server被动响应。在实际应用中，这种分工确保了音频流的可靠建立，避免了设备间的控制冲突。

问题：解释BAP的Broadcast Source如何通过BASE结构组织多声道音频流。

答案：

Broadcast Source使用BASE（Broadcast Audio Source Endpoint）结构在周期性广告中发布流配置。BASE采用三级层次：组级（BIG）、子组级（逻辑音频流集合）和BIS级（单个流）。每个子组包含一个或多个BIS，代表不同的音频频道（如左/右声道）。Source通过LTV（Length-Type-Value）结构设置编解码参数，例如LC3的采样率和声道分配。这种组织方式允许Sink设备选择性同步，支持灵活的多语言或立体声场景。

问题：BAP的拓扑限制中，为什么不允许Unicast Client和Server在同一连接中并发？（蓝牙SIG认证培训材料）

答案：

这是由蓝牙链路层角色冲突决定的。在LE连接中，Unicast Client必须充当Central角色，而Unicast Server必须充当Peripheral角色。蓝牙核心规范（Volume 6, Part B）规定，一个连接中不能有两个设备同时担任Central角色，否则会导致链路控制失败。此限制确保了连接的稳定性和角色清晰性，避免数据冲突。

博主简介 byte轻骑兵，现就职于国内知名科技企业，专注于嵌入式系统研发，深耕 Android、Linux、RTOS、通信协议、AIoT、物联网及 C/C++ 等领域。乐于技术分享与交流，欢迎关注互动！

⚠️ 版权声明 本文为原创内容，未经授权禁止转载。商业合作或内容授权请联系邮箱并备注来意。