【LE Audio】BAP协议精讲[4]: 蓝牙LE音频单播服务器实战指南——从服务部署到能力公示的全流程解析

在蓝牙LE音频单播场景中，Unicast Server（单播服务器）是音频服务的核心提供方——无论是真无线耳机、车载音响还是智能音箱，只要需要接收或发送单播音频，都必须遵循单播服务器的支持要求。这些要求不仅定义了服务器的基础配置，更决定了它能否与客户端无缝协作、稳定传输音频。本文深入拆解单播服务器的核心支持规范，从服务部署、传输配置到能力公示，搞懂每一个要求背后的逻辑与实战价值。

目录

一、核心服务部署：单播服务器的基础设施

1.1 必选服务：ASCS + PACS

二、传输层基础配置：保障数据交互的通信管道

2.1 ATT/EATT核心要求

2.2 传输层的实战意义

三、音频能力公示规范：PACS的额外必修课

3.1 音频能力的强制与可选配置

3.2 PAC记录的格式规范

3.3 音频上下文类型要求

四、音频流控制增强：ASCS的额外要求

4.1 ASE数量的配置规则

4.2 ASE配置的实战价值

五、广播通知格式：单播服务器的自我宣传

5.1 广告格式的核心字段

5.2 广告的作用

六、实战场景：耳机作为单播服务器的配置实例

七、随堂测试

一、核心服务部署：单播服务器的基础设施

单播服务器要正常工作，必须先部署两大核心服务——这是协议明确的强制要求，就像开一家商店必须先办理营业执照和搭建产品展示架，缺一不可。

1.1 必选服务：ASCS + PACS

协议强制规定，单播服务器必须实例化两个服务：

• 音频流控制服务（ASCS，Audio Stream Control Service）：音频流的控制中枢，负责暴露音频流端点（ASE），接收客户端的配置指令（如编解码参数设置、QoS配置、音频流启停）。没有ASCS，客户端就无法控制音频流的生命周期。

• 已发布音频能力服务（PACS，Published Audio Capabilities Service）：音频能力的展示窗口，负责公示服务器支持的编解码格式、采样率、声道数、音频位置等关键信息。客户端通过读取PACS的特征值，才能判断自己能否与服务器匹配传输音频。

这两个服务的关系是控制+公示：PACS让客户端知道服务器能做什么，ASCS让客户端指挥服务器做什么。协议之所以强制要求两者，是为了确保客户端能快速发现服务器能力并精准控制音频流，避免出现能力不匹配或无法控制的兼容问题。

二、传输层基础配置：保障数据交互的通信管道

单播服务器的所有服务交互（如PACS能力读取、ASCS指令传输）都依赖ATT/EATT协议，协议对传输层的配置有明确要求，确保交互高效稳定。

2.1 ATT/EATT核心要求

• 最小ATT_MTU：64字节：单播服务器必须支持至少64字节的ATT_MTU（最大传输单元），无论是非增强型ATT承载还是增强型EATT承载。这个数值不是随意设定的——音频配置参数（如编解码参数、QoS参数）通常需要几十字节的存储空间，64字节的MTU能确保这些参数一次性传输完成，避免分片导致的延迟和传输错误。

• 承载支持灵活：服务器可以选择支持非增强型ATT承载或EATT承载，EATT基于L2CAP的增强流控模式，传输效率更高，适合大数据量交互（如多声道音频配置）。协议不强制要求EATT，但推荐在需要高效传输的场景中使用。

2.2 传输层的实战意义

想象一下：客户端要给服务器配置一套多声道音频参数，包含采样率、帧长、声道分配、QoS延迟要求等。如果MTU太小，这些参数需要分成多包传输，不仅耗时，还可能出现包丢失导致配置失败。64字节的最小MTU刚好能覆盖大部分常规配置场景，确保交互一次成功，这也是协议重视传输层基础配置的核心原因。

三、音频能力公示规范：PACS的额外必修课

PACS作为能力公示服务，协议对单播服务器有额外要求——不仅要公示能力，还要按统一格式公示，确保客户端能正确解析。这部分是互操作性的关键，也是最容易出现兼容问题的地方。

3.1 音频能力的强制与可选配置

单播服务器的音频能力以LC3编解码为核心（LC3是LE音频的默认编解码），协议明确了强制支持和可选支持的参数组合：

（1）强制支持的配置（必须实现，否则无法兼容）：

• 音频宿（接收音频）：16kHz采样率、10ms帧长、40字节/编解码帧（32kbps）；24kHz采样率、10ms帧长、60字节/编解码帧（48kbps）。

• 音频源（发送音频）：16kHz采样率、10ms帧长、40字节/编解码帧（32kbps）。

（2）可选支持的配置（根据产品定位选择）：

• 更低的采样率（8kHz）：适合语音通话场景，功耗更低。

• 更高的采样率（32kHz、44.1kHz、48kHz）：适合高清音乐播放，音质更好。

• 不同帧长（7.5ms）：帧长越短，音频延迟越低，适合游戏、实时通话等场景。

这些配置的核心逻辑是兼顾通用性和灵活性：强制配置覆盖了最常用的语音和音乐场景，确保不同厂商的设备能基础兼容；可选配置则允许厂商根据产品定位（如入门级耳机vs高端音箱）提供差异化功能。

3.2 PAC记录的格式规范

服务器的音频能力通过PAC记录（Published Audio Capability record）公示，每个PAC记录对应一套音频配置，协议对格式有严格要求：

• 标准LC3编解码：Codec_ID字段的第0字节为LC3编码格式值，其余4字节为0。

• 厂商自定义编解码：如果支持厂商专属编解码，Codec_ID字段第0字节为0xFF（表示厂商自定义），第1-2字节为公司ID（来自蓝牙分配编号），第3-4字节为厂商自定义编解码ID。

这种格式统一的好处是：客户端无需适配不同厂商的私有格式，只要按协议解析Codec_ID，就能快速识别服务器支持的编解码类型，降低兼容成本。

3.3 音频上下文类型要求

音频上下文（Context Type）定义了音频的使用场景（如媒体播放、语音通话、通知），协议要求：

• 无论服务器是音频源还是音频宿，都必须支持“unspecified”（未指定）上下文类型。

• 这是为了兼容那些没有明确场景的音频传输，确保即使客户端未指定上下文，服务器也能正常接收或发送音频。

四、音频流控制增强：ASCS的额外要求

ASCS作为音频流控制服务，协议对单播服务器的额外要求集中在ASE（音频流端点）的配置上——ASE是音频流的控制接口，服务器必须根据自身的音频能力配置足够的ASE数量，确保能同时处理多个音频流或多声道音频。

4.1 ASE数量的配置规则

ASE分为Sink ASE（接收音频）和Source ASE（发送音频），数量配置遵循按需分配原则，核心规则如下：

• 若服务器支持多声道（音频位置字段中多个bit为1），则必须支持接收/发送多声道音频。

• 若不支持声道多路复用（每个ASE只能传输1个声道）：ASE数量 ≥ 音频位置字段中置1的bit数（即声道数）。

• 若支持声道多路复用（每个ASE可传输多个声道）：ASE数量 ≥ 声道数 ÷ 最大支持的单ASE声道数。

举个例子：某耳机作为单播服务器，支持左、右两个音频位置（声道数=2），且支持单ASE传输2个声道（多路复用），则只需配置1个Sink ASE即可；若不支持多路复用，则需要配置2个Sink ASE。

4.2 ASE配置的实战价值

ASE数量直接决定了服务器能同时处理的音频流数量和声道数。比如支持双向通话的耳机，需要1个Sink ASE（接收音乐）和1个Source ASE（发送语音）；而支持多声道的家庭影院音箱，可能需要多个ASE来分别传输前置、后置、中置声道的音频。协议的要求确保了服务器的ASE数量能匹配其公示的音频能力，避免出现“公示支持多声道但没有足够ASE”的矛盾。

五、广播通知格式：单播服务器的自我宣传

单播服务器需要通过扩展广告告知周边客户端“我是可连接的音频设备，且支持哪些音频场景”，协议定义了统一的广告格式，确保客户端能快速识别。

5.1 广告格式的核心字段

服务器发送的扩展广告PDU包含以下关键信息（封装在服务数据中）：

• 音频流控制服务UUID：标识这是支持BAP的单播服务器。

• 公告类型：0x00（通用公告，仅告知可连接）、0x01（定向公告，主动请求连接）。

• 可用音频上下文：4字节字段，标识服务器当前可支持的音频场景（如媒体、通话）。

• 元数据：可选字段，以LTV格式携带额外信息（如设备名称、厂商信息），仅在元数据长度≠0时存在。

5.2 广告的作用

这个广告就像单播服务器的招牌：客户端扫描周边设备时，通过解析广告中的服务UUID和可用音频上下文，能快速筛选出符合自己需求的服务器（比如需要播放音乐的客户端，会优先选择支持媒体上下文的服务器）。定向公告则适用于需要快速建立连接的场景（如耳机开机后主动请求连接手机）。

六、实战场景：耳机作为单播服务器的配置实例

为了让大家更直观理解，我们以真无线耳机为例，看看单播服务器的实际配置：

这样的配置既满足协议要求，又贴合耳机的实际使用场景——既能接收音乐，又能支持通话，且通过多路复用减少ASE数量，降低硬件成本。

七、随堂测试

题目：蓝牙LE音频单播服务器必须实例化哪两个核心服务？各自的作用是什么？

答案：

必须实例化ASCS（音频流控制服务）和PACS（已发布音频能力服务）。

作用：

  ① ASCS是音频流的控制中枢，负责暴露ASE（音频流端点），接收客户端的编解码配置、QoS设置、音频流启停等指令；

  ② PACS是音频能力的展示窗口，负责公示服务器支持的编解码格式、采样率、声道数、音频位置等信息，让客户端快速判断是否兼容。

题目：单播服务器对ATT_MTU的最小要求是什么？为什么需要这个要求？

答案：最小ATT_MTU要求为64字节。

原因：音频配置参数（如编解码参数、QoS参数、声道分配）通常需要几十字节的存储空间，64字节的MTU能确保这些参数一次性传输完成，避免分片传输导致的延迟增加、包丢失或配置失败，保障客户端与服务器的交互效率和稳定性。

题目：单播服务器的ASE数量配置需遵循哪些核心规则？请举例说明。

答案：

核心规则：

  ① 支持多声道时，必须配置足够的ASE以传输所有声道；

  ② 不支持多路复用时，ASE数量≥声道数（音频位置字段置1的bit数）；

  ③ 支持多路复用时，ASE数量≥声道数÷单ASE最大支持声道数。

举例：某音箱支持左、右、中置3个声道，不支持多路复用，则需配置3个Sink ASE；若支持单ASE传输3个声道，则只需配置1个Sink ASE即可。

题目：请简述Unicast Server在BAP中的核心功能及其必须实例化的服务。

答案：

Unicast Server负责管理单向音频流传输，必须实例化音频流控制服务（ASCS）和发布音频能力服务（PACS）。ASCS用于配置和控制音频流，而PACS暴露设备的音频编解码能力，确保客户端能发现并协商合适的音频参数。

题目：描述PACS中供应商特定编解码器的配置格式及其意义。

答案：

供应商特定编解码器使用5字节Codec_ID字段：首字节0xFF表示供应商格式，随后两字节为公司ID，最后两字节为编解码器ID。这种格式允许厂商扩展自定义音频格式，保持标准化的同时支持创新，增强协议灵活性。

博主简介

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

📌 主页与联系方式

• CSDN：https://blog.csdn.net/weixin_37800531

• 知乎：https://www.zhihu.com/people/38-72-36-20-51

• 微信公众号：嵌入式硬核研究所

• 邮箱：byteqqb@163.com（技术咨询或合作请备注需求）

⚠️ 版权声明

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