在前两篇内容中，我们依次拆解了PACS的基础规则体系和服务层核心逻辑，从一致性要求、协议兼容、GATT交互约定，到服务声明的唯一性、PAC记录的全组合规则、音频能力与可用性的核心区分，搭建起了PACS的理论框架。而PACS的服务特征，正是这套理论框架落地的具体功能载体，是蓝牙音频设备作为服务器对外暴露音频能力、位置、上下文状态的核心接口，也是客户端与服务器完成音频能力协商、建立音频流连接的关键环节。

---

PACS定义了六大核心服务特征，这些特征并非孤立存在，而是按音频接收、音频发送、上下文管理三大维度形成协同体系，覆盖了设备音频能力的发布、音频位置的声明、实时可用状态的同步全流程。所有特征均要求加密访问，同时按设备的音频收发角色设定了必选、条件选的实现要求，既保证了基础功能的互通性，又为厂商提供了贴合产品需求的实现灵活性。

本文对PACS的六大特征进行全方位解析，从特征的定位、参数格式、行为规则，到特殊场景的实现、错误处理的要求，再到六大特征的联动交互逻辑，结合实际开发场景讲透每个细节，同时梳理开发中的避坑指南，真正掌握PACS特征的实现和应用核心，解决实际开发中遇到的能力解析、状态同步、设备兼容等问题。

---

目录

一、PACS六大特征总纲：先吃透基础实现规则

1.1 四大要求类型：明确实现的硬性与柔性准则

1.2 六大特征核心信息总表：一眼看清实现要求

1.3 实例数量规则：单实例为核心，仅PAC特征支持多实例

1.4 通用属性规则：读为基础，通知为核心，写为可选

1.5 安全权限：全特征强制加密访问

二、接收类特征解析：Sink PAC + Sink Audio Locations

2.1 Sink PAC：音频接收能力的核心公示牌

2.2 Sink Audio Locations：音频接收的声道位置地图

三、发送类特征解析：Source PAC + Source Audio Locations

3.1 Source PAC：音频发送能力的核心公示牌

3.2 Source Audio Locations：音频发送的声道位置地图

3.3 接收/发送类特征的对称设计价值：降低开发与兼容成本

四、上下文类特征解析：Available Audio Contexts + Supported Audio Contexts

4.1 先吃透核心概念：音频上下文（Context Type）

4.2 Supported Audio Contexts：设备的音频场景支持清单

4.3 Available Audio Contexts：设备的音频场景实时营业状态

4.4 Supported与Available的核心区分与联动规则：避免开发混淆

五、PACS 六大特征的联动交互逻辑：从能力发现到连接建立的完整流程

六、PACS 特征开发避坑指南：解决实际开发中的核心问题

七、PACS六大特征的核心设计亮点：蓝牙SIG的设计思路解析

7.1 亮点1：收发特征的对称式设计，实现开发与解析的复用性

7.2 亮点2：PAC记录的灵活承载设计，兼顾标准化与扩展性

7.3 亮点3：音频上下文的分层设计，区分固有支持与实时可用

7.4 亮点4：多客户端差异化的精准适配，满足多连接的资源管理需求

7.5 亮点5：全特征的加密安全设计，保障音频能力交互的安全性

7.6 亮点6：通用规则的全局统一，实现跨厂商的标准化落地

八、测试

---

一、PACS六大特征总纲：先吃透基础实现规则

在逐个解析特征之前，我们需要先掌握PACS特征的通用基础规则，这是所有特征实现的前提，包括特征的要求类型、核心属性、安全权限、实例数量四大维度。这些规则由蓝牙SIG统一定义，是保证不同厂商设备互联互通的核心，也是开发中必须遵守的底层要求。

1.1 四大要求类型：明确实现的硬性与柔性准则

PACS对所有特征的实现要求分为四类，分别是Mandatory（M，必选）、Conditional（C.n，条件式）、Optional（O，可选）、Excluded（X，排除），其中条件式要求会通过编号明确具体的触发条件，这一分类和基础规则中的要求类型保持一致，开发中需先判断产品的音频收发角色，再确定需要实现的特征。

1.2 六大特征核心信息总表：一眼看清实现要求

PACS的六大特征按功能可分为接收类（Sink）、发送类（Source）、上下文类三大类，其中接收类和发送类特征呈对称设计，上下文类特征为全局必选。下表完整呈现了六大特征的要求类型、核心属性、安全权限，同时标注了条件式要求的具体含义，是开发中最核心的参考表：

特征分类	特征名称	要求类型	必选属性	可选属性	安全权限	核心功能
接收类	Sink PAC	C.1	读	通知	加密要求	暴露设备音频接收能力的PAC记录
接收类	Sink Audio Locations	C.2	读	通知、写	加密要求	暴露设备音频接收的声道位置位图
发送类	Source PAC	C.1	读	通知	加密要求	暴露设备音频发送能力的PAC记录
发送类	Source Audio Locations	C.3	读	通知、写	加密要求	暴露设备音频发送的声道位置位图
上下文类	Available Audio Contexts	M	读、通知	无	加密要求	暴露设备实时可用的音频上下文（仅单播）
上下文类	Supported Audio Contexts	M	读	通知	加密要求	暴露设备支持的所有音频上下文（单播+广播）

核心条件式要求解析（C.1/C.2/C.3）：

• C.1：设备必须至少实现Sink PAC或Source PAC其一，这是PACS的核心实现要求，无此特征则无法对外暴露音频核心能力；

• C.2：仅当设备实现Sink PAC时，才可选实现Sink Audio Locations，若未实现Sink PAC则直接排除该特征；

• C.3：仅当设备实现Source PAC时，才可选实现Source Audio Locations，若未实现Source PAC则直接排除该特征。

1.3 实例数量规则：单实例为核心，仅PAC特征支持多实例

PACS对特征的实例数量做了明确规定，这一规则直接决定了开发中的特征部署方式，核心原则为单实例为默认，仅Sink PAC/Source PAC支持多实例部署，具体规则如下：

1. 若实现Sink PAC，服务器上至少存在一个Sink PAC实例，可根据需求部署多个；

2. 若实现Sink Audio Locations，服务器上最多只能存在一个该特征实例；

3. 若实现Source PAC，服务器上至少存在一个Source PAC实例，可根据需求部署多个；

4. 若实现Source Audio Locations，服务器上最多只能存在一个该特征实例；

5. Available Audio Contexts和Supported Audio Contexts为全局必选，服务器上必须且只能存在一个实例。

1.4 通用属性规则：读为基础，通知为核心，写为可选

所有PACS特征的基础属性为读（Read），即客户端均可主动读取特征的当前值，这是设备能力发现的基础；通知（Notify） 为绝大多数特征的核心可选/必选属性，是实现设备状态实时同步的关键，避免客户端通过轮询获取状态导致的蓝牙链路开销增加；写（Write） 仅对两个音频位置特征开放为可选属性，支持客户端对设备的音频声道位置进行配置。

1.5 安全权限：全特征强制加密访问

PACS的所有六大特征均要求Encryption required（加密要求），即客户端与服务器之间必须建立加密的蓝牙连接，才能对特征进行读、写、通知配置等操作。这一要求的核心目的是保护设备的音频能力信息不被非法获取，同时防止第三方设备篡改音频位置、上下文等配置信息，保证蓝牙音频交互的安全性。

可以将PACS的六大特征总纲类比成公司的部门设置规则：总纲规定了公司必须设立哪些核心部门（必选特征）、哪些部门按需设立（条件式特征）、各部门的核心职能（特征功能）、各部门的人员配置上限（实例数量），而后续的单个特征解析，就是对每个部门的具体工作流程、操作规范、协作要求的详细说明。

二、接收类特征解析：Sink PAC + Sink Audio Locations

接收类特征是为具备音频接收能力的设备设计的核心特征，比如蓝牙音箱、耳机、助听器等，核心作用是对外暴露设备能接收什么样的音频以及能在哪些声道位置接收音频。其中Sink PAC是核心条件式特征，Sink Audio Locations是基于Sink PAC的可选特征，二者配合完成音频接收能力的完整发布。

2.1 Sink PAC：音频接收能力的核心公示牌

Sink PAC是PACS中最核心的特征之一，核心定位是暴露服务器支持音频数据接收时的所有PAC记录，客户端通过解析Sink PAC的PAC记录，就能获取设备的音频编解码ID、采样频率、编码帧字节数等核心接收能力，这是客户端判断能否与设备建立音频接收连接的关键依据。

（1） 特征核心定位与多实例实现场景

Sink PAC的核心作用是承载音频接收的PAC记录，协议中明确其定位为

The Sink PAC characteristic is used to expose PAC records when the server supports reception of audio data。

对于Sink PAC的实例数量，协议未做上限限制，将单实例或多实例的选择权交给厂商，开发中可根据产品需求选择，协议明确给出了三个多实例部署的典型场景，也是实际开发中最常见的应用场景：

• MTU大小限制：若设备支持的ATT_MTU较小，将所有PAC记录放在单个Sink PAC实例中会导致特征值超过MTU承载能力，此时可将PAC记录拆分到多个实例中，避免数据截断；

• 厂商专属与通用能力分离：将支持厂商专属编解码器的PAC记录和支持通用编解码器的PAC记录分别部署在不同实例中，便于客户端快速识别和解析，同时简化厂商专属能力的管理；

• 减少通知数据传输量：将易变化的音频能力PAC记录（如因应用安装/卸载导致的能力变化）和固定的音频能力PAC记录部署在不同实例中，当易变化能力改变时，仅通知对应实例的特征值变化，减少蓝牙链路的数据传输量。

可以将Sink PAC的多实例部署类比成超市的商品分区：超市会将食品、日用品、家电分区摆放，既方便顾客快速找到商品，也方便超市的库存管理，Sink PAC的多实例部署也是如此，按能力类型、变化频率分区承载PAC记录，既方便客户端解析，也优化了设备的状态同步效率。

（2）详细参数格式：吃透每个字段的含义与实现要求

Sink PAC的特征值由一系列结构化参数组成，所有参数均按小端序传输，参数格式遵循长度+内容的通用设计，单个Sink PAC实例可承载一个或多个PAC记录，具体参数格式如下表，其中带[i]的参数为数组参数，对应第i个PAC记录，遵循PACS服务层定义的按记录分组的数组排列规则：

参数名称	字节数	核心含义与实现要求
Number_of_PAC_records	1	本特征实例中的PAC记录数量，强制要求≥1，若为0则不符合规范；取值范围0x01~0xFF
Codec_ID[i]	5	第i个PAC记录的编解码器ID，核心结构化字段，按字节分为三部分： 1. Octet 0：编码格式值，定义在Bluetooth Assigned Numbers的HCI部分； 2. Octet 1-2：公司ID值，若Octet 0不为0xFF则必须为0x0000； 3. Octet 3-4：厂商专属编解码器ID，若Octet 0不为0xFF则必须为0x0000
Codec_Specific_Capabilities_Length[i]	1	第i个PAC记录的编解码器专属能力长度，若该能力为空则必须为0x00；取值范围0x00~0xFF
Codec_Specific_Capabilities[i]	可变	第i个PAC记录的编解码器专属能力内容，字节数与上述长度参数一致，包含采样频率、编码帧字节数等核心能力
Metadata_Length[i]	1	第i个PAC记录的元数据长度，若元数据为空则必须为0x00；取值范围0x00~0xFF
Metadata[i]	可变	第i个PAC记录的元数据，采用LTV（Length-Type-Value）格式，仅当元数据长度非0时存在，用于补充描述音频能力

核心参数解析：

• Codec_ID：5字节的结构化设计是编解码器识别的核心，0xFF为厂商专属编解码器的标识位，当编码格式为厂商专属时，后续的公司ID和厂商专属ID才会生效，否则必须为0，这一设计保证了通用编解码器和厂商专属编解码器的统一识别；

• Codec_Specific_Capabilities：是PAC记录的核心内容，承载了设备的具体音频接收能力，如Supported_Sampling_Frequencies（支持的采样频率）、Supported_Octets_Per_Codec_Frame（支持的编码帧字节数）等，参数格式遵循BAP规范的定义，保证了与LE Audio其他协议的兼容性；

• Metadata：采用LTV通用格式，为音频能力的描述提供了灵活性，厂商可根据产品需求添加自定义元数据，如编解码器的版本、音频质量等级等，且元数据为可选字段，不影响核心能力的解析。

（3）行为规则：读、通知的实现要求与触发场景

Sink PAC的行为规则围绕读和通知两大属性展开，协议对每个属性的实现要求、触发场景、执行逻辑做了明确规定，是开发中必须严格遵守的核心规则，同时所有行为均基于GATT子过程实现，与基础规则中的GATT交互要求保持一致。

①读操作：基础能力发现，无条件返回特征值

读操作是Sink PAC的基础属性，协议要求当客户端发起GATT读特征值请求时，服务器必须无条件返回当前Sink PAC特征的完整值，包括Number_of_PAC_records和所有PAC记录的全部参数。

读操作的执行逻辑无特殊限制，只要客户端与服务器建立了加密的蓝牙连接，即可随时发起，服务器无需做额外的权限校验，仅需保证返回的特征值格式正确、参数完整，这是客户端完成音频能力发现的基础流程。

②通知操作：能力变化时的实时同步，强制触发+分场景执行

通知操作是Sink PAC的可选属性，但若服务器支持PAC记录的变化，则必须实现通知属性，协议中明确

If the server supports changing a PAC record, the server shall support notifications for the Sink PAC characteristic instance containing the PAC record that can change。

PAC记录的变化场景主要包括固件更新、新应用安装/卸载、硬件配置修改等，这些场景会导致设备的音频接收能力发生改变，需要及时通知客户端。

Sink PAC的通知操作遵循配置先行，变化触发的核心逻辑，具体执行规则分为三个步骤，同时按设备的连接状态分两种场景执行：

1. 客户端配置通知：客户端通过GATT的Write Characteristic Descriptors子过程，对Sink PAC的Client Characteristic Configuration（CCC）描述符进行配置，将通知开关置为开启；

2. 特征值变化触发：当包含可变化PAC记录的Sink PAC实例特征值发生改变时，触发通知操作；

3. 服务器发送通知：根据设备的连接状态，服务器按以下规则发送通知：

• 连接状态：服务器立即向客户端发送新的特征值，保证客户端实时获取最新的音频接收能力；

• 断连状态：若设备与客户端为绑定关系，当设备重新与客户端建立连接时，服务器立即发送新的特征值，保证客户端重连后获取的是最新能力。

关键注意点：若Sink PAC为多实例部署，仅需为包含可变化PAC记录的实例实现通知属性，固定不变的PAC记录实例可无需实现通知属性，这能进一步减少开发成本和蓝牙链路的开销。

2.2 Sink Audio Locations：音频接收的声道位置地图

Sink Audio Locations是基于Sink PAC的可选特征，核心定位是暴露服务器支持音频数据接收时的所有声道位置，通过4字节的位图形式，向客户端声明设备能在哪些声道位置接收音频，比如立体声耳机的左声道、右声道，音箱的前置、后置声道等，是客户端实现音频声道适配的关键依据。

（1）特征核心定位与设计原则

Sink Audio Locations的核心作用是承载设备音频接收的声道位置位图，协议中明确其定位为

The Sink Audio Locations characteristic is used to expose the supported Audio Locations when the server supports reception of audio data。

该特征采用设备全局位图的设计原则，即特征值代表设备所有音频接收PAC记录的通用声道位置支持，而非单个PAC记录的专属支持，这一设计简化了客户端的解析逻辑，无需为每个PAC记录单独解析声道位置。

同时，该特征支持本地修改和客户端写入两种值变化方式，是PACS中少数支持写操作的特征之一，厂商可根据产品需求实现写属性，支持客户端对设备的音频声道位置进行配置，比如将立体声耳机的声道位置从左/右声道切换为单声道。

（2）详细参数格式：4字节位图的核心含义

Sink Audio Locations的参数格式非常简洁，仅包含一个4字节的位图参数，所有位的定义均在Bluetooth Assigned Numbers中统一规定，参数格式如下表：

参数名称	字节数	核心含义与实现要求
Sink_Audio_Locations	4	设备音频接收的声道位置全局位图，小端序传输； 1. 取值0x00000000：设备仅支持单声道音频接收，无指定声道位置； 2. 取值非0x00000000：设备支持位图中标识的所有声道位置，且同时支持单声道； 3. 未分配的位为RFU（保留未来使用），必须置0

核心设计原则解析：协议规定非0值的位图同时支持单声道，这是为了保证设备的音频兼容性，比如立体声耳机（支持左/右声道）可同时接收单声道音频，无需额外的参数配置，这一设计避免了因声道不兼容导致的音频接收失败。

（3）行为规则：读、写、通知的联动实现要求

Sink Audio Locations的行为规则围绕读、写、通知三大属性展开，其中读为必选属性，写和通知为可选属性，且写和通知存在强联动关系，协议对三者的实现要求做了明确规定，同时定义了严格的错误处理规则，是开发中的重点和难点。

①读操作：基础位置发现，无条件返回位图值

与Sink PAC一致，读操作是Sink Audio Locations的基础属性，只要客户端与服务器建立了加密的蓝牙连接，即可随时发起GATT读特征值请求，服务器必须无条件返回当前的4字节位图值，无需做额外的权限校验。

服务器返回的位图值必须保证格式正确，RFU位全部置0，否则会导致客户端解析失败，这是开发中需要重点注意的细节。

②写操作：可选配置，严格的格式与内容校验

写操作是Sink Audio Locations的可选属性，协议中明确The server may support writes to the Sink Audio Locations characteristic value by clients，若厂商选择实现写属性，则需要遵守严格的格式校验和内容校验规则，同时必须实现通知属性。

写操作的核心要求：

1. 触发方式：客户端通过GATT的Write Characteristic Value子过程发起写请求，向服务器发送4字节的位图值；

2. 格式校验：服务器首先校验写入的参数长度是否为4字节，非4字节则直接拒绝写请求；

3. 内容校验：服务器校验写入的位图值中RFU位是否为0，若存在RFU位置1则直接拒绝写请求；

4. 值更新：若格式和内容均校验通过，服务器更新Sink Audio Locations的特征值为新的位图值，并触发通知操作。

③通知操作：值变化必触发，本地修改与客户端写入均适配

通知操作是Sink Audio Locations的可选属性，但存在两个强制实现场景，协议中明确规定：

1. 若服务器支持本地修改Sink Audio Locations的特征值（如设备自身的按键操作切换声道），则必须实现通知属性；

2. 若服务器支持客户端写入该特征值，则必须实现通知属性。

通知操作的执行逻辑与Sink PAC一致，遵循配置先行，变化触发的原则，客户端需先配置CCC描述符开启通知，当特征值因本地修改或客户端写入发生改变时，服务器按连接状态发送通知：连接时立即发送，断连重连绑定客户端时发送。

（4）错误处理：写操作的严格校验与错误返回

错误处理是Sink Audio Locations开发中的核心要点，协议对写操作的错误场景做了明确规定，服务器必须按要求返回错误响应，保证客户端能准确识别写失败的原因。

协议中明确

If the server detects that the Sink_Audio_Locations parameter value, written by a client by using the GATT Write Characteristic Value sub-procedure, is not 4 octets in length, or if the parameter value written includes any RFU bits set to a value of 0b1, the server shall respond with an ATT Error Response and shall set the Error Code parameter to Write Request Rejected。

核心错误处理规则：

1. 错误触发场景：仅针对客户端的写操作，读操作和通知操作无错误处理场景；

2. 具体错误类型：参数长度非4字节、RFU位置1，两种场景均触发错误响应；

3. 错误返回格式：服务器返回ATT Error Response（属性协议错误响应），并将错误码设置为Write Request Rejected（写请求被拒绝），该错误码定义在蓝牙核心规范补充文档中；

4. 执行结果：错误发生时，服务器不更新特征值，保持原有位图值不变。

三、发送类特征解析：Source PAC + Source Audio Locations

发送类特征是为具备音频发送能力的设备设计的核心特征，比如蓝牙麦克风、音频采集器、手机等，核心作用是对外暴露设备能发送什么样的音频以及能在哪些声道位置发送音频。发送类特征与接收类特征呈完全对称设计，参数格式、行为规则、错误处理要求基本一致，仅核心定位从音频接收变为音频发送，开发中可基于接收类特征的实现逻辑进行适配，大幅降低开发成本。

3.1 Source PAC：音频发送能力的核心公示牌

Source PAC的核心定位是暴露服务器支持音频数据传输时的所有PAC记录，与Sink PAC对称，客户端通过解析Source PAC的PAC记录，可获取设备的音频编解码ID、采样频率、编码帧字节数等核心发送能力，是客户端判断能否与设备建立音频发送连接的关键依据。

（1）特征核心定位与多实例实现场景

Source PAC的定位与Sink PAC完全一致，仅将接收改为发送，协议中明确其定位为

The Source PAC characteristic is used to expose PAC records when the server supports transmission of audio data。

其多实例部署的规则、典型场景也与Sink PAC完全相同，包括MTU大小限制、厂商专属与通用能力分离、减少通知数据传输量三大场景，开发中可直接复用Sink PAC的多实例设计逻辑。

（2）详细参数格式：与Sink PAC完全一致

Source PAC的参数格式与Sink PAC完全相同，包括Number_of_PAC_records、Codec_ID[i]、Codec_Specific_Capabilities_Length[i]等所有参数，字节数、核心含义、实现要求均无差异，仅参数承载的能力从音频接收能力变为音频发送能力。

例如，Codec_ID[i]的5字节结构化设计、Codec_Specific_Capabilities[i]的编解码器专属能力内容、Metadata[i]的LTV格式，均与Sink PAC一致，这一对称设计让PACS的特征实现具有高度的统一性，减少了厂商的开发和维护成本。

（3）行为规则：读、通知的实现要求与Sink PAC完全一致

Source PAC的行为规则围绕读和通知两大属性展开，实现要求、触发场景、执行逻辑与Sink PAC完全相同：

1. 读操作：客户端发起GATT读请求时，服务器无条件返回完整的特征值，是客户端音频发送能力发现的基础；

2. 通知操作：若服务器支持PAC记录的变化，则必须实现通知属性，通知的配置、触发、执行规则与Sink PAC一致，按设备连接状态分场景发送通知。

3.2 Source Audio Locations：音频发送的声道位置地图

Source Audio Locations是基于Source PAC的可选特征，核心定位是暴露服务器支持音频数据传输时的所有声道位置，与Sink Audio Locations对称，通过4字节的位图形式向客户端声明设备的音频发送声道位置，是客户端实现音频发送声道适配的关键依据。

（1）特征核心定位与设计原则

Source Audio Locations的定位与Sink Audio Locations完全一致，仅将接收改为发送，协议中明确其定位为

The Source Audio Locations characteristic is used to expose the supported Audio Locations when the server supports transmission of audio data。

其设备全局位图的设计原则、单声道兼容原则也与Sink Audio Locations完全相同，开发中可直接复用解析逻辑。

（2）详细参数格式：4字节位图与Sink Audio Locations完全一致

Source Audio Locations的参数格式仅包含一个4字节的Source_Audio_Locations位图参数，字节数、核心含义、实现要求与Sink Audio Locations完全相同：

1. 取值0x00000000：仅支持单声道音频发送；

2. 取值非0x00000000：支持位图标识的声道位置+单声道；

3. RFU位必须置0。

（3）行为规则：读、写、通知的联动要求与Sink Audio Locations完全一致

Source Audio Locations的行为规则围绕读、写、通知三大属性展开，三者的实现要求、联动关系与Sink Audio Locations完全相同：

1. 读操作：基础位置发现，无条件返回4字节位图值；

2. 写操作：可选属性，实现则需遵守严格的格式和内容校验；

3. 通知操作：本地修改或客户端写入时强制实现，执行逻辑与Sink Audio Locations一致。

（4）错误处理：写操作的校验规则与错误返回完全一致

Source Audio Locations的错误处理规则与Sink Audio Locations完全相同，仅将参数名改为Source_Audio_Locations：

1. 错误触发场景为客户端写操作，参数长度非4字节或RFU位置1时触发；

2. 服务器返回ATT Error Response，错误码设置为Write Request Rejected；

3. 错误发生时不更新特征值。

3.3 接收/发送类特征的对称设计价值：降低开发与兼容成本

PACS的接收类和发送类特征采用完全对称的设计，是蓝牙SIG的重要设计思路，其核心价值体现在开发和兼容两个维度：

1. 开发维度：厂商可复用接收类特征的实现逻辑、代码框架开发发送类特征，大幅减少开发工作量和维护成本，同时降低因逻辑不一致导致的开发错误；

2. 兼容维度：客户端可复用接收类特征的解析逻辑解析发送类特征，无需为收发能力开发两套不同的解析代码，提升了客户端与服务器的互联互通效率，减少了兼容问题。

对于同时具备音频收发能力的设备（如带麦克风的蓝牙耳机、手机），只需同时实现接收类和发送类特征，即可完成音频收发能力的完整发布，客户端通过解析对应的特征，就能实现双向的音频能力协商，建立双向音频流连接。

四、上下文类特征解析：Available Audio Contexts + Supported Audio Contexts

上下文类特征是PACS的全局必选特征，所有实现PACS的设备都必须部署，核心作用是对外暴露设备的音频上下文相关状态。音频上下文（Context Type）是蓝牙SIG定义的音频使用场景，如音乐播放、语音通话、导航播报、媒体录音等，每个场景对应一个位域值。

上下文类包含两个核心特征：Supported Audio Contexts（支持的上下文）和Available Audio Contexts（可用的上下文），二者极易混淆，却是PACS中实现设备音频状态实时同步的核心，协议对二者的定位、格式、行为规则做了明确区分，同时定义了严格的联动规则，开发中必须严格区分并遵守联动要求。

4.1 先吃透核心概念：音频上下文（Context Type）

在解析上下文类特征之前，我们需要先明确音频上下文的核心概念，这是理解两个特征的基础。协议中定义Context Type为：

A bitfield of values that, when set to 0b1 for a bit, describes audio data as being intended for the use case represented by that bit

即音频上下文是通过位域值表示的音频使用场景，每个位对应一个具体的场景，置1表示支持/可用该场景，置0则表示不支持/不可用。

音频上下文的具体位域值由Bluetooth Assigned Numbers统一定义，覆盖了蓝牙音频的所有典型使用场景，且支持扩展，厂商可根据需求申请新的场景位域值。核心特点：

1. 位域表示：采用位域形式，可通过单个数值表示多个场景，提升传输和解析效率；

2. 全局统一：所有场景的位域值全局统一，保证不同厂商设备的场景识别一致性；

3. 收发分离：分为接收上下文和发送上下文，分别对应设备的音频接收和发送场景。

4.2 Supported Audio Contexts：设备的音频场景支持清单

Supported Audio Contexts的核心定位是暴露服务器支持的所有音频上下文类型，包括单播和广播音频流的所有使用场景，是设备的固有场景属性，由设备的硬件和固件决定，不会随设备的实时资源状态变化而改变，相当于设备的音频场景支持清单，告诉客户端“我能处理哪些音频使用场景”。

（1）特征核心定位与设计原则

协议中明确其定位为

The Supported Audio Contexts characteristic exposes the server’s support for reception and/or transmission of unicast audio data and/or broadcast audio data associated with specific Context Types。

其核心设计原则包括收发分离和与PAC特征强联动两大点：

• 收发分离：特征值分为接收上下文和发送上下文两部分，分别对应设备的音频接收和发送场景，客户端可独立解析；

• 与PAC特征强联动：若设备未实现Sink PAC，则接收上下文必须为0x0000；若设备未实现Source PAC，则发送上下文必须为0x0000，这一设计保证了上下文场景与设备核心音频能力的一致性。

与PAC记录类似，Supported Audio Contexts的特征值仅在软件更新/固件升级时可能发生变化，比如固件更新新增了对导航播报场景的支持，此时特征值会被修改，其余场景均保持固定。

（2）详细参数格式：双2字节位掩码，收发分离设计

Supported Audio Contexts的特征值采用收发分离的双2字节位掩码设计，两个参数均为小端序传输，位域值定义在Bluetooth Assigned Numbers中，具体参数格式如下表：

参数名称	字节数	核心含义与实现要求
Supported_Sink_Contexts	2	音频接收上下文的位掩码，小端序传输； 1. 置1表示支持该接收场景（单播+广播）； 2. 若未实现Sink PAC，必须为0x0000； 3. RFU位必须置0
Supported_Source_Contexts	2	音频发送上下文的位掩码，小端序传输； 1. 置1表示支持该发送场景（单播+广播）； 2. 若未实现Source PAC，必须为0x0000； 3. RFU位必须置0

核心设计解析：2字节的位掩码可支持最多16个音频上下文场景，完全覆盖了蓝牙音频的所有典型使用场景，同时预留了足够的扩展空间；收发分离的设计让客户端可独立解析设备的接收和发送场景支持情况，简化了解析逻辑。

（3）行为规则：读、通知的实现要求与触发场景

Supported Audio Contexts的行为规则围绕读和通知两大属性展开，读为必选属性，通知为可选属性，且通知的触发场景具有唯一性，是开发中的核心要点。

①读操作：基础场景发现，无条件返回特征值

读操作是Supported Audio Contexts的基础属性，只要客户端与服务器建立了加密的蓝牙连接，即可随时发起GATT读特征值请求，服务器必须无条件返回当前的两个2字节位掩码值，包括Supported_Sink_Contexts和Supported_Source_Contexts。

服务器返回的特征值必须保证与PAC特征的联动一致性，即未实现Sink/Source PAC时，对应的上下文值必须为0x0000，同时RFU位全部置0。

②通知操作：仅场景支持变化时触发，强制实现

通知操作是Supported Audio Contexts的可选属性，但若服务器支持场景支持类型的变化，则必须实现通知属性，协议中明确

If the server supports changes to its supported audio data Context Types, the server shall support notifications of the Supported Audio Contexts characteristic。

与PAC记录的变化场景类似，Supported Audio Contexts的特征值变化场景仅为软件更新/固件升级，即设备的音频场景支持能力因软件/固件修改发生改变时，才会触发通知操作，其余场景特征值均保持固定。

通知的执行逻辑与PAC特征、音频位置特征一致，遵循配置先行，变化触发的原则：客户端先配置CCC描述符开启通知，当特征值发生改变时，服务器按连接状态发送通知，连接时立即发送，断连重连绑定客户端时发送。

4.3 Available Audio Contexts：设备的音频场景实时营业状态

Available Audio Contexts的核心定位是暴露服务器实时可用的音频上下文类型，仅针对单播音频流，是设备的实时资源状态属性，由设备的当前资源使用情况决定，会随设备的资源状态实时变化，相当于设备的音频场景实时营业状态，告诉客户端“我现在能为哪些音频使用场景提供单播服务”。

（1）特征核心定位与核心设计原则

协议中明确其定位为

The Available Audio Contexts characteristic exposes the availability of the server for reception and/or transmission of unicast audio data only, associated with specific Context Types。

其核心设计原则包括仅单播、不超支持范围、多客户端差异化、实时更新四大点，这四大原则是开发中的核心要求，必须严格遵守：

1. 仅单播：仅暴露单播音频流的可用场景，不涉及广播音频流，因为广播音频流为一对多传输，无需判断接收端的资源状态；

2. 不超支持范围：可用的上下文场景不能超出Supported Audio Contexts中声明的支持场景，即Available的位掩码不能包含Supported中未置1的位；

3. 多客户端差异化：服务器可根据客户端的连接状态、权限，为不同客户端暴露不同的可用上下文值，这是PACS中唯一支持多客户端差异化的特征；

4. 实时更新：当设备的资源状态发生变化时，服务器必须立即更新特征值，并触发通知操作，保证客户端获取的是最新的可用状态。

多客户端差异化设计的实际场景：以带麦克风的蓝牙耳机为例，其同时与手机A和手机B建立了加密连接，此时蓝牙耳机的音乐播放场景资源被手机A占用，因此对手机A的音乐播放场景置1（可用），对手机B的音乐播放场景置0（不可用）；而语音通话场景未被占用，对两个手机均置1（可用）。这一设计让设备能更灵活地管理音频资源，提升了多客户端连接时的资源利用效率。

（2）详细参数格式：与Supported Audio Contexts完全一致的双2字节位掩码

Available Audio Contexts的参数格式与Supported Audio Contexts完全相同，采用收发分离的双2字节位掩码设计，字节数、传输方式与Supported一致，仅核心含义从支持的场景变为可用的场景，具体参数格式如下表：

参数名称	字节数	核心含义与实现要求
Available_Sink_Contexts	2	音频接收上下文的实时可用位掩码，小端序传输； 1. 置1表示该接收场景（仅单播）当前可用； 2. 不能包含Supported_Sink_Contexts中未置1的位； 3. RFU位必须置0
Available_Source_Contexts	2	音频发送上下文的实时可用位掩码，小端序传输； 1. 置1表示该发送场景（仅单播）当前可用； 2. 不能包含Supported_Source_Contexts中未置1的位； 3. RFU位必须置0

核心联动要求：Available的位掩码不能超出Supported的范围，这是协议规定的硬性规则，开发中必须在服务器端做严格的校验，若Available的位包含Supported中未置1的位，则会导致客户端解析混乱，甚至建立音频流连接失败。

例如，若Supported_Sink_Contexts中仅音乐播放场景置1，那么Available_Sink_Contexts中只能在音乐播放场景置1，其余场景均只能置0，不能在导航播报场景置1。

（3）行为规则：读、通知的实现要求，多客户端适配为核心

Available Audio Contexts的行为规则围绕读和通知两大属性展开，且两个属性均为必选属性，这是PACS中唯一要求通知为必选属性的特征，足见其在实时状态同步中的核心地位。同时，多客户端差异化适配是其行为规则的核心要点，开发中需重点处理。

①读操作：实时状态获取，按客户端返回差异化值

读操作是Available Audio Contexts的必选属性，其执行逻辑与其他特征存在显著差异：服务器需根据发起读请求的客户端，返回对应的差异化特征值，而非返回全局统一的特征值。

读操作的核心执行要求：

1. 客户端与服务器建立加密连接后，可随时发起GATT读特征值请求；

2. 服务器根据该客户端的连接状态、资源占用情况，获取为该客户端分配的可用上下文值；

3. 服务器返回该客户端对应的Available_Sink_Contexts和Available_Source_Contexts值，保证每个客户端获取的是自身对应的实时可用状态。

②通知操作：实时变化必触发，多客户端独立通知

通知操作是Available Audio Contexts的必选属性，协议中明确该特征的可选属性为无，因此所有实现PACS的设备都必须为该特征实现通知属性，这是因为Available Audio Contexts的特征值随设备资源状态实时变化，需要及时通知客户端，保证音频流连接的稳定性。

Available Audio Contexts的通知操作遵循配置先行，变化触发，多客户端独立的核心逻辑，具体执行规则如下：

1. 客户端独立配置：每个客户端通过GATT的Write Characteristic Descriptors子过程，独立配置CCC描述符的通知开关，服务器为每个客户端维护独立的通知配置状态；

2. 资源变化触发：当设备的资源状态发生改变，导致某个/某些客户端的可用上下文值发生变化时，触发通知操作；

3. 多客户端独立通知：服务器仅向可用上下文值发生变化且开启了通知的客户端发送通知，其余客户端不发送，保证通知的精准性；

4. 通知执行规则：与其他特征一致，连接时立即发送新的特征值，断连重连绑定客户端时发送最新的特征值。

核心注意点：开发中需为每个客户端维护独立的可用上下文值和通知配置状态，这是实现多客户端差异化的关键，若采用全局统一的状态管理，会导致多客户端连接时的状态同步错误。

4.4 Supported与Available的核心区分与联动规则：避免开发混淆

Supported Audio Contexts和Available Audio Contexts是PACS中最易混淆的两个特征，开发中很多兼容问题都源于对二者的区分不清、联动规则遵守不到位。我们从本质属性、变化性、关联音频流、与PAC特征联动、多客户端适配五大维度做核心区分，同时梳理二者的硬性联动规则，让开发中的边界更清晰。

（1）五大维度核心区分

对比维度	Supported Audio Contexts	Available Audio Contexts
本质属性	设备的固有硬件/固件属性，代表能处理哪些场景	设备的实时资源状态属性，代表现在能为哪些单播场景服务
变化性	仅软件/固件更新时可能变化，平时固定不变	随设备资源使用情况实时变化，如连接建立/断开、资源占用/释放
关联音频流	支持单播+广播音频流的所有场景	仅支持单播音频流的场景，与广播无关
与PAC特征联动	未实现Sink/Source PAC时，对应值必须为0x0000	随Supported的值变化而变化，不能超出Supported的范围
多客户端适配	全局统一值，所有客户端读取的内容一致	多客户端差异化值，不同客户端读取的内容可不同

用一个通俗的比喻总结：Supported Audio Contexts就像餐厅的菜单，列出了餐厅能做的所有菜品，菜单不会随当天的食材情况变化；Available Audio Contexts就像餐厅的当日在售菜品，仅列出当天有食材能做的菜品，且会根据食材的消耗情况实时更新，同时餐厅可根据不同的顾客需求，提供不同的在售菜品清单。

（2）三大硬性联动规则

协议对Supported和Available定义了三大硬性联动规则，开发中必须在服务器端做严格的校验和实现，否则会导致设备不符合PACS规范，无法与其他厂商设备互联互通：

1. 范围限制规则：Available的Sink/Source Contexts位掩码，不能包含Supported的Sink/Source Contexts中未置1的位，服务器在更新Available值时，必须做位掩码的交集校验；

2. 同步变化规则：当Supported的特征值发生变化时，服务器必须立即更新Available的特征值，保证Available的值始终在Supported的范围内，若Supported中某个场景置0，则Available中该场景必须立即置0；

3. PAC联动规则：当设备的Sink/Source PAC特征被移除/禁用时，服务器必须将Supported对应的Contexts值置0x0000，同时将Available对应的Contexts值也置0x0000。

五、PACS 六大特征的联动交互逻辑：从能力发现到连接建立的完整流程

PACS 的六大特征并非孤立存在，而是按 “能力支持→能力发布→位置声明→场景支持→场景可用” 的逻辑形成完整的联动体系，客户端与服务器之间的音频能力协商、音频流连接建立，正是通过六大特征的协同交互完成的。

掌握六大特征的联动交互逻辑，是理解 PACS 整体工作流程的核心，也是开发中保证设备交互正确性的关键。以下是客户端从发现 PACS 服务到建立单播音频流连接的完整流程，该流程基于 LE Audio 的通用交互规范，是实际开发中最典型的应用场景，同时涵盖了六大特征的所有核心操作：

阶段 1：蓝牙连接建立与 PACS 服务发现（基础准备）

1. 客户端与服务器进行蓝牙配对，建立加密的蓝牙 GATT 连接，满足 PACS 特征的加密访问要求；

2. 客户端通过 GATT 的服务发现子过程，扫描服务器上的 PACS 服务（单实例，固定 UUID），确认服务器支持 PACS；

3. 客户端扫描 PACS 服务下的所有特征，确认服务器实现的特征类型（Sink PAC/Source PAC / 音频位置 / 上下文），为后续的能力解析做准备。

阶段 2：基础能力与场景支持发现（固有属性读取）

1. 客户端读取Supported Audio Contexts特征值，解析服务器支持的音频接收 / 发送场景（单播 + 广播），确定服务器是否支持客户端所需的音频场景；

2. 客户端读取Sink PAC/Source PAC特征值（至少其一），解析 PAC 记录的核心参数，包括编解码器 ID、采样频率、编码帧字节数等，确定服务器的音频收发能力是否与客户端匹配；

3. 若服务器实现了Sink Audio Locations/Source Audio Locations特征，客户端读取其特征值，解析服务器的音频声道位置，为音频声道适配做准备。

核心判断：若服务器的 Supported Audio Contexts、Sink/Source PAC 的能力与客户端的需求不匹配，客户端直接终止交互，不建立音频流连接；若匹配，则进入下一阶段。

阶段 3：实时可用状态获取（实时属性读取）

1. 客户端读取Available Audio Contexts特征值，获取服务器为该客户端分配的实时可用音频场景（仅单播）；

2. 客户端判断服务器的实时可用场景是否包含自身所需的场景，若包含则进入下一阶段，若不包含则等待或终止交互。

阶段 4：通知配置（实时状态同步准备）

1. 客户端通过 GATT 的 Write Characteristic Descriptors 子过程，为Sink PAC/Source PAC、Sink/Source Audio Locations（若实现）、Supported Audio Contexts（若支持变化）、Available Audio Contexts配置 CCC 描述符，开启所有核心特征的通知开关；

2. 服务器为客户端维护独立的通知配置状态，完成实时状态同步的准备工作。

阶段 5：音频流参数协商（核心能力适配）

1. 客户端基于解析到的 PAC 记录参数，选择双方均支持的音频参数（编解码器、采样频率、编码帧字节数等），向服务器发起音频流参数协商请求；

2. 服务器基于自身的 PAC 记录全组合规则，校验客户端选择的参数组合是否有效，若有效则返回确认响应，若无效则返回拒绝响应并给出支持的参数范围；

3. 若服务器实现了音频位置特征，客户端基于解析到的声道位置位图，配置音频流的声道输出 / 输入方式，完成声道适配。

核心依据：参数协商的唯一依据是服务器 PAC 记录中声明的能力，客户端不能要求服务器支持 PAC 记录中未声明的参数组合，否则服务器会直接拒绝。

阶段 6：单播音频流连接建立（正式交互）

1. 客户端与服务器完成音频流参数协商后，基于 LE Audio 的 BAP 规范建立单播音频流连接；

2. 服务器更新Available Audio Contexts特征值，将当前使用的音频场景置为 占用，并向客户端发送通知，同步最新的可用状态；

3. 客户端接收到通知后，确认音频场景的占用状态，完成单播音频流的建立，开始音频数据的传输。

阶段 7：实时状态同步与连接管理（交互中）

1. 能力变化同步：若服务器的 PAC 记录、支持的音频上下文发生变化，服务器通过对应的特征通知客户端，客户端根据新的能力重新进行参数协商；

2. 位置变化同步：若服务器的音频声道位置发生改变（本地修改 / 客户端写入），服务器通过音频位置特征通知客户端，客户端实时调整声道适配方式；

3. 可用状态同步：若服务器的资源状态发生变化（如其他客户端占用资源、当前资源释放），服务器通过 Available Audio Contexts 特征向受影响的客户端发送通知，客户端根据新的可用状态调整音频流；

4. 连接断开：当音频流传输完成后，客户端与服务器断开单播音频流连接，服务器更新 Available Audio Contexts 特征值，将对应的音频场景置为 “可用”，并通知客户端。

以上流程覆盖了 PACS 六大特征的所有核心交互场景，开发中需严格遵循该流程的逻辑，保证设备与其他厂商设备的互联互通性。同时，流程中所有的特征操作均需遵守协议定义的行为规则，如通知的触发条件、参数的格式要求等

六、PACS 特征开发避坑指南：解决实际开发中的核心问题

在 PACS 特征的实际开发中，很多工程师会因对协议细节理解不到位，出现能力解析错误、状态同步失败、设备兼容问题等情况。结合协议要求和实际开发经验，我们梳理了六大核心避坑点，每个坑点包含错误原因、解决方案，帮助开发人员避开开发中的常见误区，保证设备的合规性和兼容性。

6.1 避坑点 1：PAC 特征多实例部署的逻辑混乱

错误表现：多实例部署时，将不同类型的 PAC 记录无序拆分，或为所有实例都实现通知属性，导致客户端解析混乱、蓝牙链路开销增加；

错误原因：未理解协议中多实例部署的场景要求，无规则地拆分 PAC 记录；

解决方案：

1. 按协议要求的三大场景进行多实例部署，如 MTU 限制、厂商专属与通用能力分离、易变与固定能力分离；

2. 仅为包含可变化 PAC 记录的实例实现通知属性，固定能力的实例无需实现；

3. 为每个 PAC 特征实例添加清晰的标识，便于客户端识别不同实例的能力类型。

6.2 避坑点 2：位域 / 范围参数的解析与实现错误

错误表现：对 PAC 记录中的位域（如采样频率）、范围（如编码帧字节数）参数解析错误，或未遵守全组合规则，导致客户端参数协商失败；

错误原因：未掌握位域 / 范围的表示规则，或忽略了 PAC 记录的全组合硬性要求；

解决方案：

1. 严格按蓝牙 SIG 的定义解析位域参数，置 1 的位代表支持对应的能力，需做按位或运算解析；

2. 范围参数按 “最小值 + 最大值” 解析，支持区间内的所有值；

3. 严格遵守全组合规则，若需支持离散值，需将 PAC 记录拆分为多个独立实例，而非在一个记录中选择性支持。

6.3 避坑点 3：通知机制的实现漏洞

错误表现：通知触发不及时、断连重连后不发送通知、多客户端通知混乱，导致客户端无法实时同步服务器状态；错误原因：未遵守 配置先行，变化触发 的通知逻辑，或未为不同客户端维护独立的通知状态；

解决方案：

1. 所有特征的通知均需在客户端配置 CCC 描述符后才触发，未配置则不发送；

2. 服务器特征值变化时，需立即触发通知，连接状态下实时发送，断连重连绑定客户端时主动发送；

3. 对 Available Audio Contexts 特征，为每个客户端维护独立的通知配置状态，仅向受影响的客户端发送通知。

6.4 避坑点 4：Available 与 Supported 的联动校验缺失

错误表现：Available 的位掩码超出 Supported 的范围，或 Supported 变化后 Available 未同步更新，导致客户端解析混乱；

错误原因：未在服务器端实现 Available 与 Supported 的联动校验逻辑；

解决方案：

1. 在服务器端添加位掩码交集校验，保证 Available 的位始终是 Supported 中位的子集；

2. 监听 Supported 特征值的变化，一旦发生变化，立即更新 Available 特征值，移除超出新范围的场景；

3. 当 PAC 特征被移除 / 禁用时，同步将 Supported 和 Available 对应的上下文值置 0x0000。

6.5 避坑点 5：RFU 位未按要求置 0

错误表现：特征参数中的 RFU 位被置 1，导致客户端解析失败或服务器拒绝客户端的写请求；

错误原因：忽略了协议中 RFU 位必须置 0 的硬性要求；

解决方案：

1. 所有特征参数中的 RFU 位，在设备发送 / 生成参数时必须强制置 0；

2. 客户端写入参数时，服务器需校验 RFU 位是否为 0，若置 1 则按协议要求返回错误响应；

3. 开发中添加通用的 RFU 位校验函数，对所有特征参数进行统一校验。

6.6 避坑点 6：多客户端差异化的实现缺失

错误表现：对所有客户端返回相同的 Available Audio Contexts 值，导致多客户端连接时资源管理混乱；

错误原因：未理解 Available Audio Contexts 的多客户端差异化设计原则，采用全局统一的状态管理；

解决方案：

1. 为每个连接的客户端维护独立的设备上下文，包括可用场景值、通知配置状态、资源占用情况；

2. 客户端发起读请求时，根据客户端的唯一标识返回对应的 Available 值；

3. 资源状态变化时，仅更新受影响客户端的可用场景值，并发送通知。

七、PACS六大特征的核心设计亮点：蓝牙SIG的设计思路解析

PACS的六大特征设计并非零散的功能堆砌，而是蓝牙SIG基于蓝牙音频设备的互联互通需求、开发落地的易用性、实际场景的灵活性三大核心目标打造的标准化体系，从v1.0到v1.0.2的版本迭代中，也仅针对细节errata修正，未改变核心设计框架，足见这套设计的合理性和前瞻性。结合PACS官方规范的定义和实际设备开发的落地经验，我们能提炼出六大核心设计亮点，这也是理解蓝牙音频标准化设计思路的关键。

7.1 亮点1：收发特征的对称式设计，实现开发与解析的复用性

接收类（Sink）和发送类（Source）特征采用完全对称的参数格式、行为规则、错误处理逻辑，是PACS最直观的设计亮点。官方规范中明确Sink PAC与Source PAC、Sink Audio Locations与Source Audio Locations的定义仅将接收（reception）替换为传输（transmission），其余要求完全一致。

这种设计的核心价值在于最大化复用性：从开发端，厂商只需实现一套接收类特征的代码框架，稍作修改即可适配发送类特征，大幅减少开发工作量和维护成本，也降低了因逻辑不一致导致的兼容错误；从解析端，客户端无需为音频收发能力开发两套解析逻辑，统一的解析规则能提升设备间的交互效率。

同时，对称式设计也贴合蓝牙音频设备的实际形态——多数设备（如蓝牙耳机、手机）同时具备音频收发能力，对称的特征体系能让设备的能力发布更规整，客户端的能力协商更清晰。

7.2 亮点2：PAC记录的灵活承载设计，兼顾标准化与扩展性

PAC记录作为PACS承载音频核心能力的载体，其设计兼顾了标准化约束和落地扩展性，是PACS设计的核心精髓，官方规范对PAC记录的格式、组合规则做了严格定义，同时也给厂商留下了灵活的实现空间：

1. 结构化参数+LTV元数据：PAC记录采用固定的结构化参数（Codec_ID、编解码器专属能力等）保证标准化，同时引入LTV格式的Metadata字段作为可选扩展，厂商可根据产品需求添加自定义信息（如编解码器版本、音频质量等级、硬件适配信息等），且元数据不影响核心能力的解析，实现标准不缺失，扩展不受限；

2. 位域/范围的参数表示：对采样频率、编码帧字节数等核心能力，支持位域（多值可选）和范围（区间值）两种表示方式，能高效承载设备的多能力支持，避免单参数多记录的冗余；

3. 单/多实例的弹性部署：PAC特征支持单实例承载所有PAC记录，也支持多实例拆分部署，官方规范还明确了MTU限制、厂商专属/通用能力分离、易变/固定能力分离三大多实例部署场景，让厂商能根据设备的硬件配置（如ATT_MTU大小）和产品特性灵活设计；

4. 严格的全组合规则：官方规范强制要求PAC记录中多参数的所有组合均需支持，若需离散值则需拆分PAC记录，这一硬性规则从根源上避免了厂商选择性支持导致的客户端参数协商失败，保证了设备间的互联互通性。

7.3 亮点3：音频上下文的分层设计，区分固有支持与实时可用

将音频上下文拆分为Supported Audio Contexts（支持的上下文）和Available Audio Contexts（可用的上下文）两个独立特征，是PACS针对实际场景的精准设计，也是解决“设备能做什么”和“设备现在能做什么”区分问题的核心方案。

官方规范中对二者的定位做了明确划分：Supported是设备的固有硬件/固件属性，由设备能力决定，仅在软件/固件更新时变化，且覆盖单播+广播所有音频流；Available是设备的实时资源状态属性，由资源占用情况决定，实时变化，且仅针对单播音频流。同时还定义了“Available不能超出Supported范围”的硬性联动规则，保证了二者的数据一致性。

这种分层设计完美贴合蓝牙音频的实际使用场景：比如一款蓝牙耳机支持音乐播放、语音通话两大场景（Supported），但当它正在与手机建立音乐播放的单播连接时，音乐播放场景的资源被占用，此时对该手机的Available中音乐播放场景置0，而对其他未连接的手机仍置1，既让客户端能清晰判断设备的核心能力，也能实时获取设备的资源状态，避免无效的连接请求。

7.4 亮点4：多客户端差异化的精准适配，满足多连接的资源管理需求

在Available Audio Contexts特征中引入多客户端差异化设计，是PACS针对蓝牙音频设备多客户端连接场景的重要考量，也是PACS中唯一支持“同一特征对不同客户端返回不同值”的设计。

官方规范中明确服务器可为每个客户端暴露不同的Available Audio Contexts值，同时要求为每个客户端维护独立的通知配置状态，仅向受影响的客户端发送通知。这一设计让设备能更精细化地管理音频资源：比如蓝牙音箱同时与手机A、平板B建立加密连接，当手机A占用了音箱的音乐播放资源时，音箱对手机A的Available中音乐播放场景置1，对平板B置0，而语音播报场景对二者均置1，实现了资源的按需分配。

相较于全局统一的状态管理，多客户端差异化设计能大幅提升设备的资源利用效率，也能避免多客户端连接时的状态混乱，贴合当下蓝牙设备多端互联的实际需求。

7.5 亮点5：全特征的加密安全设计，保障音频能力交互的安全性

PACS的六大特征均强制要求Encryption required（加密访问），即客户端与服务器必须建立加密的蓝牙GATT连接，才能进行读、写、通知配置等操作，这是蓝牙SIG针对设备能力交互的安全设计，也是蓝牙音频标准化的重要组成部分。

音频能力信息虽非敏感隐私数据，但设备的编解码器、采样频率等能力参数是音频流连接的核心依据，若被非法获取或篡改，可能导致设备被恶意连接、音频流传输异常等问题。而加密访问的要求能保证只有完成蓝牙配对的合法客户端才能获取设备的音频能力信息，也能防止第三方设备篡改音频位置、上下文等配置信息，从传输层保障了PACS特征交互的安全性。

同时，加密要求也与蓝牙Core Specification的安全规范保持一致，厂商无需额外开发安全逻辑，只需遵循蓝牙通用的加密配对流程，即可满足PACS的安全要求。

7.6 亮点6：通用规则的全局统一，实现跨厂商的标准化落地

PACS对所有特征制定了全局统一的通用规则，从字节传输顺序、RFU位处理，到通知机制、错误处理，均做了明确且唯一的定义，这是跨厂商设备能实现互联互通的核心基础，也是标准化设计的核心要求：

1. 字节序统一为小端序：官方规范明确所有PACS特征的参数均采用最低有效字节（LSO）优先的小端序传输，与蓝牙Core Specification的字节传输规则保持一致，避免了因字节序不一致导致的参数解析错误；

2. RFU位的严格处理：所有特征的参数中，RFU（保留未来使用）位必须置0，接收端若检测到RFU位置1，需按协议要求处理（如写操作时返回错误），这一规则为PACS的版本迭代预留了扩展空间，同时避免了因RFU位处理不一致导致的兼容问题；

3. 通知机制的统一逻辑：所有特征的通知均遵循配置先行（客户端配置CCC描述符）、变化触发、断连重连同步的核心逻辑，仅在触发条件上略有差异，统一的通知规则让客户端能实现通用的通知处理框架；

4. 错误处理的标准化：对音频位置特征的写操作，官方规范明确了唯一的错误类型（参数长度非4字节、RFU位置1）和错误返回方式（ATT Error Response + Write Request Rejected），避免了厂商自定义错误码导致的客户端无法识别错误的问题。

这些全局统一的通用规则，让不同厂商的设备在实现PACS时拥有统一的标准标尺，从根源上减少了跨厂商的兼容问题，也是PACS能成为蓝牙LE Audio核心服务的重要原因。

八、测试

问答题：请详细区分PACS中Supported Audio Contexts和Available Audio Contexts的核心差异，以及二者的硬性联动规则？

答案：

Supported Audio Contexts（支持的上下文）和Available Audio Contexts（可用的上下文）是PACS中上下文管理的两大核心特征，核心差异体现在5个维度，同时官方规范定义了3条硬性联动规则：

（1）核心差异

1. 本质属性：Supported是设备的固有硬件/固件属性，代表设备能处理哪些音频场景；Available是设备的实时资源状态属性，代表设备“现在能为哪些单播音频场景提供服务”。

2. 变化性：Supported仅在软件/固件更新时可能变化，平时固定不变；Available随设备的资源占用/释放、连接建立/断开实时变化。

3. 关联音频流：Supported覆盖单播+广播所有蓝牙音频流；Available仅针对单播音频流，与广播无关。

4. 与PAC特征联动：若设备未实现Sink/Source PAC，Supported对应的Sink/Source Contexts必须置0x0000；Available无直接的PAC联动，仅通过Supported间接关联。

5. 多客户端适配：Supported是全局统一值，所有客户端读取的内容一致；Available支持多客户端差异化，不同客户端可读取不同的值。

（2）硬性联动规则

1. 范围限制规则：Available的Sink/Source Contexts位掩码不能包含Supported中未置1的位，即可用的场景必须是设备支持的场景；

2. 同步变化规则：当Supported的特征值发生变化时，服务器必须立即更新Available的特征值，移除超出新范围的场景；

3. PAC联动规则：当设备的Sink/Source PAC特征被移除/禁用时，服务器需将Supported对应的Contexts置0x0000，同时将Available对应的Contexts也置0x0000。

问答题：PACS中Sink PAC/Source PAC支持多实例部署，官方规范中明确的三大典型场景是什么？多实例部署时的通知实现有什么要求？

答案：

1. 官方规范中明确的Sink PAC/Source PAC多实例部署的三大典型场景为：

• ATT_MTU大小限制：若设备支持的ATT_MTU较小，将所有PAC记录放在单个实例中会导致特征值超过MTU承载能力，拆分多实例可避免数据截断；

• 厂商专属与通用能力分离：将支持厂商专属编解码器的PAC记录和通用编解码器的记录部署在不同实例，便于客户端快速识别，也简化厂商专属能力的管理；

• 减少通知数据传输量：将易变化的PAC记录（如应用安装/卸载导致的能力变化）和固定的记录部署在不同实例，能力变化时仅通知对应实例，减少蓝牙链路开销。

2. 多实例部署时的通知实现要求：仅为包含可变化PAC记录的实例实现通知属性，固定不变的PAC记录实例无需实现通知属性。若某个实例的PAC记录发生变化，服务器仅需向配置了该实例通知的客户端发送通知，无需同步其他实例的状态。

题目：Sink PAC特征值中，Codec_ID字段占5个字节，请详细说明这5个字节各部分的含义，以及在什么情况下Company ID和Vendor-specific codec ID必须为0。

答案：

Codec_ID的5个字节分配如下：字节0表示Coding Format（编码格式），取值在蓝牙分配编号的HCI部分定义；字节1-2表示Company ID（公司标识符）；字节3-4表示Vendor-specific codec ID（厂商自定义编解码ID）。只有当字节0的值为0xFF（表示厂商自定义编码格式）时，字节1-4才有效，用于标识具体的厂商和私有编解码；如果字节0不是0xFF，则字节1-4必须全部为0。这种设计既支持标准编码格式（直接使用字节0），也支持私有编码格式（通过0xFF标记后跟公司ID和私有ID），保证了编码格式标识的全球唯一性。

题目：某蓝牙耳机支持作为单播服务器接收音频，同时也支持作为单播服务器发送音频（例如，耳机内置麦克风可以回传上行音频）。请问该耳机必须实现PACS中的哪些特征值？哪些是可选的？

答案：

由于耳机同时支持接收和发送音频，它必须同时支持Sink PAC和Source PAC（满足C.1条件，至少支持一个，这里实际支持了两个）。Sink Audio Locations和Source Audio Locations都是可选的，耳机可以选择是否实现它们。Available Audio Contexts是强制必须实现的，因为所有PACS服务器都必须支持这个特征值。Supported Audio Contexts也是强制必须实现的。因此，强制实现的是：Sink PAC、Source PAC、Available Audio Contexts、Supported Audio Contexts。可选实现的是：Sink Audio Locations、Source Audio Locations。

题目：当客户端想要向一个PACS服务器发起媒体播放（Media Context）时，它应该按照什么顺序读取哪些特征值来判断是否能够成功建立音频流？请结合特征值的作用说明理由。

答案：

客户端应该按照以下顺序操作：

1. 首先读取Supported Audio Contexts，查看服务器的Supported_Sink_Contexts中是否包含媒体位（Media）。如果不包含，说明服务器根本不支持媒体播放，无需继续。

2. 如果支持，再读取Sink PAC，获取服务器支持的编解码参数，确认客户端能够提供兼容的音频格式。

3. 如果需要考虑声道配置，可以读取Sink Audio Locations，了解服务器的音频位置支持情况。

4. 在准备发起音频流之前，读取Available Audio Contexts，检查Available_Sink_Contexts中媒体位当前是否为1。如果为0，说明服务器虽然支持媒体，但当前资源不足（例如正在通话），暂时不可用；如果为1，则可以发起音频流。

5. 在音频流持续期间，可以订阅Available Audio Contexts的通知，以便在服务器可用性变化时（例如媒体变得不可用）及时处理。 这个顺序保证了客户端先了解静态能力，再确认动态状态，最后才采取行动，避免了无效的尝试和资源浪费。

---

博主简介

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（技术咨询或合作请备注需求）

⚠️ 版权声明

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

---