在LE Audio的广播音频体系中，Broadcast Audio Scan Service（BASS）是实现低功耗设备接收广播音频的核心服务，而想要吃透BASS的完整协议逻辑，打好入门根基是关键。作为BASS协议的开篇内容，这部分核心定义了BASS实现的底层准则、设备交互的硬性要求、数据传输的统一规则，还有读懂整个协议的通用语言体系，相当于为后续学习BASS的服务特征、操作流程、状态管理铺好了路。
目录
[7.1 规范常用词汇的明确定义](#7.1 规范常用词汇的明确定义)
[7.2 RFU：为协议升级预留的空白位置](#7.2 RFU：为协议升级预留的空白位置)
[7.3 Prohibited：绝对不能使用的无效值](#7.3 Prohibited：绝对不能使用的无效值)
如果把BASS协议比作一套搭建广播音频接收设备的施工图纸，这部分内容就是图纸的通用技术规范，规定了施工必须遵守的材料标准、工艺要求、符号含义，脱离这些规则，后续的功能实现就会出现互联互通的问题，甚至完全不符合协议要求。本文从合规性准则、依赖关系、交互要求、错误处理、通用规则等维度，把这些入门核心内容讲透，同时结合协议设计的底层逻辑，用通俗的比喻帮大家理解，让后续的协议学习更顺畅。
一、合规性准则：BASS实现的底层红线
协议的核心合规性要求是所有设备实现BASS的基础，也是保证不同厂商设备互联互通的前提。协议中明确了核心原则：每个被规范定义的能力都必须按照指定的方式实现，协议会提供部分设计灵活性的可选功能，但如果设备选择实现某一个可选功能，就必须严格按照协议的要求完成实现，不能随意修改或简化。
这一原则看似简单，却是蓝牙协议互联互通的核心保障。蓝牙作为全球通用的无线技术，不同厂商的设备从芯片到软件实现千差万别，而合规性准则就像交通规则，所有上路的车辆都必须遵守基础规则，可选的行驶方式（如走高速、走国道）也必须在对应规则内进行。比如BASS中定义的广播源添加操作，协议会明确其参数格式、状态转换逻辑，所有实现该功能的设备都必须严格遵循；而部分设备可能因硬件限制不实现广播源修改功能，这一选择被协议允许，但如果选择实现，就不能更改其参数要求和行为逻辑。
协议中还提到，这种设计灵活性的提供是为了适配不同产品的需求，比如助听器这类极简低功耗设备，可能仅实现核心的广播接收和加密密钥设置功能，而智能音箱这类设备则可以实现完整的BASS操作集，这一设计让BASS能适配从医疗设备到消费电子的各类硬件形态。
二、服务与传输依赖：BASS轻量设计的底层逻辑
协议对BASS的服务依赖和传输依赖做了极简的定义，这一设计也是为了适配LE Audio低功耗、高适配的核心需求，让BASS能轻松集成到各类蓝牙设备中，无需依赖其他服务或传输层的特殊配置。
2.1 服务依赖：无 耦合 的独立服务
BASS被定义为无服务依赖的独立GATT主服务，不需要依赖蓝牙体系中的其他服务即可实现完整功能。这一点与蓝牙中的部分服务形成了鲜明对比，比如一些音频服务需要依赖通用音频属性服务（GAAS），而BASS的独立设计让其成为一个模块化组件，设备厂商在实现时，无需额外集成其他服务，只需单独注册BASS服务即可，大幅降低了集成成本和硬件资源占用，尤其适合助听器、TWS耳机这类硬件资源有限的低功耗设备。
2.2 传输依赖：灵活的 传输层 适配
协议对BASS没有施加任何强制的传输层要求，无论是基础的非增强型ATT承载，还是增强型EATT承载，都可以运行BASS服务。唯一的例外是，如果设备对BASS状态通知的可靠性有要求，高层协议可以要求设备支持EATT承载。
EATT是增强型属性协议，基于增强型L2CAP流控通道实现，相比基础ATT，它提升了数据传输的可靠性、速率，还支持多通道并发，能有效避免状态通知的丢失。比如医疗级助听器对广播音频的状态同步要求极高，一旦同步状态通知丢失，可能影响听障人士的使用，这类设备就可以选择基于EATT实现BASS；而普通的蓝牙扬声器对通知可靠性要求较低，使用基础ATT即可满足需求。这种灵活的传输层适配，让BASS能根据设备的实际需求选择对应的传输方式，兼顾可靠性和功耗。
三、蓝牙核心规范兼容：BASS的运行底座
BASS明确要求兼容蓝牙核心规范5.2及以上版本，这一要求并非随意设定，而是因为LE Audio的核心广播音频特性，都是在蓝牙5.2版本中首次引入的，这些特性是BASS实现广播音频扫描、同步、接收的底层技术底座。
蓝牙5.2为LE Audio新增了一系列核心能力，其中与BASS强相关的包括广播等时流（ BIS ） 、广播等时组（BIG） 、周期性广播同步（ PA **）、周期性广播同步传输（PAST）**等，这些能力定义了广播音频的传输形态、同步方式，而BASS正是基于这些底层能力，实现了广播源的扫描委托、状态管理、加密解密等上层功能。如果设备的蓝牙核心规范低于5.2，就无法支持这些LE Audio核心特性，自然也无法实现BASS服务。
这一兼容性要求也为设备厂商划定了硬件底线：想要实现BASS服务，设备的蓝牙芯片必须支持蓝牙5.2及以上版本，这是保证BASS功能正常运行的硬件基础。
四、GATT子过程要求：设备间交互的硬性通信话术
BASS是基于GATT（通用属性配置文件）实现的服务，而GATT子过程是GATT设备之间进行数据交互的基础操作，协议明确了BASS服务器在非增强型ATT承载上的GATT子过程最低要求，这些要求是BASS客户端与服务器之间能够正常交互的前提，相当于设备之间必须会说的基础通信话术，少了任何一种，都无法完成正常的指令交互和状态同步。
协议将GATT子过程的要求分为强制（M） 、**条件必选（C.n）**两类，核心要求如下表所示：
|----------------------------------|--------|------------------------------|
| GATT子过程 | 要求 | 核心作用 |
| Write Characteristic Value | M | 客户端向服务器发送带响应的指令，服务器需返回操作结果 |
| Write Without Response | M | 客户端向服务器发送无响应的指令，低延迟、高效率 |
| Notifications | M | 服务器主动向客户端推送状态变化，实时同步BASS状态 |
| Read Characteristic Descriptors | M | 客户端读取BASS特征的描述符，获取特征属性、权限等信息 |
| Write Characteristic Descriptors | M | 客户端配置BASS特征的描述符，如订阅状态通知 |
| Write Long Characteristic Value | C.1 | 传输超长特征值，支持Add Source操作则必选 |
其中条件必选C.1的要求是：如果服务器支持Add Source操作，就必须实现Write Long Characteristic Value子过程。这是因为Add Source操作需要向服务器传递广播源的详细信息，包括地址、Broadcast_ID、元数据等，这些数据的总长度可能超过ATT的最小MTU（23字节），需要通过长特征值写入的方式传输，因此该子过程成为Add Source操作的配套要求。
协议还补充了一个推荐要求：如果服务器支持的特征值长度超过非增强型ATT承载的最小MTU，建议服务器实现Read Long Characteristic Values子过程，这一要求是为了让客户端能正常读取超长的BASS状态特征值，保证状态获取的完整性。
为了更直观地理解这些子过程的协作逻辑，我们用一个简单的交互场景说明：客户端想要订阅服务器的BASS状态通知，首先通过Read Characteristic Descriptors 读取状态特征的客户端配置描述符（CCCD），然后通过Write Characteristic Descriptors 向CCCD写入订阅指令，当服务器状态变化时，通过Notifications 向客户端推送新状态；客户端想要向服务器发送添加广播源的指令，若数据长度超过MTU，则通过Write Long Characteristic Value 发送，服务器完成操作后，通过Write Characteristic Value的响应告知客户端操作结果。
五、应用层错误码：BASS交互的错误提示语言
为了让BASS客户端与服务器之间能清晰地反馈操作错误，协议定义了两个专属的ATT应用层错误码，这两个错误码对应了BASS交互中最常见的两类错误，是设备之间的错误提示语言，让接收方能够快速定位错误原因，做出对应的处理。
5.1 0x80：Opcode Not Supported（不支持的操作码）
该错误码触发的场景是：客户端向BASS扫描控制点写入了一个服务器不支持的操作码，服务器检测到后，会向客户端返回该错误码。需要注意的是，这一错误仅在客户端使用Write Characteristic Value （带响应写）时返回，如果客户端使用Write Without Response（无响应写），服务器则直接忽略该操作，不返回任何错误。
比如服务器因硬件限制，仅实现了Set Broadcast_Code（0x04）这一必选操作，若客户端向其写入Modify Source（0x03）操作码，服务器就会返回0x80错误码，告知客户端该操作不被支持。
5.2 0x81：Invalid Source_ID（无效的广播源标识）
该错误码触发的场景是：客户端写入的Source_ID与服务器中任何一个广播接收状态特征中的Source_ID都不匹配，服务器检测到后，向客户端返回该错误码。同样，该错误仅在带响应写时返回，无响应写时服务器直接忽略。
Source_ID是服务器为每个广播源分配的唯一标识，是客户端操作指定广播源的核心依据，若客户端写入的Source_ID不存在，服务器无法定位到对应的广播源，自然无法完成操作，此时就会返回0x81错误码。比如服务器中仅存在Source_ID=0x01的广播源，客户端写入Source_ID=0x02的修改指令，服务器就会返回该错误。
这两个错误码的定义，让BASS的错误处理更标准化，不同厂商的设备在遇到同类错误时，都会返回统一的错误码，客户端无需针对不同厂商做差异化的错误解析，大幅提升了互联互通性。
六、字节传输顺序：数据交互的统一书写格式
协议明确要求，BASS所有特征使用的字节都必须以最低有效字节（LSO）优先 的方式传输，也就是我们常说的小端序，这是BASS数据交互的统一格式要求，也是保证不同设备数据解析一致性的关键。
小端序的核心特点是：多字节数据中，低位字节存放在内存的低地址端，高位字节存放在高地址端，传输时先发送低位字节。比如一个2字节的PA_Interval值为0x1234，小端序传输时会先发送0x34（LSO），再发送0x12。与之相对的大端序则是高位字节优先，不同的字节序如果不统一，会导致数据解析完全错误。
比如BASS中的Broadcast_Code是16字节的加密密钥，若客户端以大端序传输，服务器以小端序解析，得到的密钥与实际密钥完全不同，最终会导致广播流解密失败；再比如BIS同步状态的位图参数，字节序错误会让服务器误判同步的BIS索引，导致音频流接收异常。因此，小端序的统一要求是BASS数据交互的基础，所有实现BASS的设备都必须严格遵循，这一要求就像统一的文字书写格式，所有人都按同一格式书写，才能保证信息被正确识别。
协议还提到，最低有效字节的标识在蓝牙SIG的特征定义中已有明确规定，设备实现时直接参考即可，无需额外定义。
七、协议的通用语言规则：读懂BASS规范的词典
想要读懂整个BASS协议，甚至所有的蓝牙规范，必须先掌握协议的通用语言规则，这部分内容定义了规范中常用词汇的准确含义、RFU（未来保留）和Prohibited（禁止）的处理准则，相当于读懂规范的专属词典，不掌握这些规则，很容易误解协议的要求。
7.1 规范常用词汇的明确定义
蓝牙SIG为规范中的核心词汇制定了统一的含义，避免了语义模糊带来的实现偏差，其中最常用的包括shall、must、should、may、can等，这些词汇在BASS规范中高频出现，每一个都代表着不同的实现要求：
shall：表示必须，用于定义强制的实现要求，是设备必须遵守的硬性条款；
must：表示必然结果或客观事实，要么是强制要求的自然结果，要么是无需证明的事实；
will：表示客观事实，仅用于陈述确定的内容，无要求含义；
should：表示推荐，是协议建议的实现方式，不强制，但遵循会提升设备的兼容性和体验；
may：表示允许，是协议提供的设计灵活性，设备可选择实现或不实现；
can：表示能力，用于描述因果关系，如某一操作能触发某一状态变化。
比如协议中"shall be no more than one BASS instance on a server"，这里的shall表示强制要求，所有服务器都只能存在一个BASS实例；而"servers should expose a number of BRS characteristics equal to the number of BIGs"，这里的should表示推荐，服务器最好按支持的BIG数量提供BRS特征，不遵循也不违反协议，但可能影响多广播源的管理能力。
7.2 RFU：为协议升级预留的空白位置
RFU即未来保留，规范中部分字段、参数值、操作码会被标记为RFU，协议对RFU的处理制定了严格的准则，核心分为三点：
设备在生成包含RFU字段的数据包时，必须将RFU字段的值设为0，除非协议另有规定；
设备在解析包含RFU字段的数据包时，必须忽略该字段，不能因该字段的非0值而拒绝解析整个数据包；
若RFU是某一参数的取值范围，设备不能将该参数设置为RFU值，接收方若收到RFU值，可拒绝该数据。
这一设计是为了给协议的后续升级预留空间，比如BASS的操作码0x06-0xFF被标记为RFU，未来蓝牙SIG可以在这些预留的操作码中定义新的操作，而现有设备在收到这些操作码时，要么忽略（无响应写），要么返回不支持的操作码错误（带响应写），不会出现设备崩溃或解析异常的情况，保证了协议升级的向下兼容性。
7.3 Prohibited：绝对不能使用的无效值
Prohibited即禁止，规范中部分枚举值、参数值会被标记为Prohibited，其处理准则比RFU更严格：
设备绝对不能将参数设置为Prohibited值，这是协议明确禁止的；
设备若收到包含Prohibited值的数据包，必须忽略该数据包，不处理、不响应，同时可拒绝整个数据结构。
与RFU不同，Prohibited值不是为未来升级预留，而是明确的无效值，比如BASS中Advertiser_Address_Type的取值仅为0x00和0x01，其他值均为RFU，而非Prohibited，而部分特征的枚举状态会定义Prohibited值，避免设备使用无效的状态值。这一规则从源头杜绝了无效参数的传输，减少了设备之间的交互错误。
八、核心术语体系：BASS的专业词汇表
BASS规范中使用了大量的专业术语，这些术语并非BASS独创，而是分别定义在蓝牙核心规范5.2及以上版本和基础音频配置文件（BAP）中，协议对这些核心术语做了统一引用，形成了BASS的专业词汇表，这些术语是理解BASS广播音频交互逻辑的关键，高频出现在后续的服务特征和操作流程中。
我们挑选了其中最核心的几个术语，结合其在BASS中的实际作用做解析：
-
Broadcast Isochronous Group（BIG）/Broadcast Isochronous Stream（BIS）：BIG是广播等时组，由一个或多个BIS组成，是BASS同步的基本单位；BIS是广播等时流，是实际承载音频数据的传输单元，BASS最终要接收和解码的就是BIS；
-
periodic advertising train（PA）：周期性广播序列，是广播源发送的包含同步信息的广播包序列，BASS服务器想要同步BIG，必须先同步到对应的PA，是BIS同步的前提；
-
PAST：周期性广播同步传输，是将PA的同步信息从客户端传输到服务器的过程，是BASS实现远程扫描委托、降低服务器功耗的核心；
-
Remote Scanning：远程扫描，即服务器委托客户端代为扫描广播源，是BASS的核心设计初衷之一，也是降低低功耗设备扫描功耗的关键；
-
SyncInfo：同步信息，包含PA的同步参数，如间隔、偏移等，服务器通过SyncInfo才能完成与PA的同步，进而实现BIS的同步。
这些术语之间形成了清晰的逻辑关联：服务器通过Remote Scanning 委托客户端扫描PA，客户端将PA的SyncInfo 通过PAST 传输给服务器，服务器通过SyncInfo同步到PA ，进而同步到BIG ，最终接收和解码BIS中的音频数据。这一关联也是BASS的核心工作逻辑，掌握这些术语，就能理清后续BASS操作流程的主线。
九、测试
问题：BASS对GATT子过程的强制要求有哪些？若支持Add Source操作，还需满足什么条件要求？
答案：
-
BASS在非增强型ATT承载上的强制GATT子过程包括Write Characteristic Value、Write Without Response、Notifications、Read Characteristic Descriptors、Write Characteristic Descriptors；
-
若服务器支持Add Source操作，必须实现Write Long Characteristic Value这一条件必选子过程，原因是Add Source操作的参数长度可能超过ATT最小MTU，需要长特征值写入传输。
问题：BASS定义的两个应用层错误码分别是什么？触发场景是什么？
答案：
-
0x80：Opcode Not Supported，触发场景是客户端写入了服务器不支持的操作码；
-
0x81：Invalid Source_ID，触发场景是客户端写入的Source_ID与服务器中所有广播接收状态特征的Source_ID都不匹配。两个错误码均仅在客户端使用带响应写时返回，无响应写时服务器直接忽略操作。
问题：简述BASS中RFU和Prohibited的核心处理准则，二者的关键区别是什么？
答案：
-
RFU处理准则：发送方需将RFU字段设为0，接收方需忽略RFU字段；若为参数取值，发送方不能使用，接收方可拒绝。
-
Prohibited处理准则：发送方绝对不能使用该值，接收方收到后需忽略数据包，不处理不响应。
-
关键区别：RFU是为协议未来升级预留的空间，并非无效值；Prohibited是明确的无效值，协议禁止使用，处理准则更严格。