在上一篇的CAS基础约定精讲中【LE Audio】CAS精讲1: 基础约定定乾坤，读懂音频协同的通用规则，我们吃透了蓝牙音频设备实现CAS的通用法则，那些看似琐碎的语言、字段、传输规则，是CAS落地的底层地基。而本次要讲的CAS服务核心规则，正是建立在这层地基之上的主体框架------它定调了CAS作为一款蓝牙服务的实现准则，明确了其依赖关系、版本兼容、落地要求等核心内容。
目录
[2.1 蓝牙核心规范兼容：5.3及以上是硬性门槛](#2.1 蓝牙核心规范兼容：5.3及以上是硬性门槛)
[2.2 无传输层依赖：不绑定任何蓝牙传输方式](#2.2 无传输层依赖：不绑定任何蓝牙传输方式)
[3.1 无专属ATT错误码：沿用通用错误处理体系](#3.1 无专属ATT错误码：沿用通用错误处理体系)
[3.2 无额外GATT子过程：依托通用GATT框架实现](#3.2 无额外GATT子过程：依托通用GATT框架实现)
如果说基础约定是CAS的语法规则，那服务核心规则就是CAS的句式模板，规定了这款服务该以何种形态存在、何种方式实现、何种逻辑协同。这些规则的设计极度简洁，没有冗余的功能性要求，一切都围绕CAS的核心定位------标准化身份标识服务展开，也正因这份简洁，才让CAS能被全球不同厂商快速适配，成为LE Audio时代多设备音频协同的通用标准。接下来我们就从依赖、兼容、传输、实现、行为五个核心维度，拆解CAS服务的落地规则，看懂这款服务的设计巧思。
一、唯一服务依赖：CSIS是CAS的协同搭档
一款蓝牙服务的依赖关系，直接决定了其实现的复杂度和协同逻辑，而CAS的设计在这一点上做到了极致精简：仅有且必须依赖CSIS（Coordinated Set Identification Service）。规范中明确标注CAS depends on CSIS，这一强制要求划定了CAS的功能边界，也决定了其与多设备协同的核心关联。
我们可以用一个简单的比喻理解这份依赖关系：如果CAS是蓝牙音频设备的身份登记处，负责给设备发放包含基础身份和组队身份的标识，那CSIS就是组队信息库，存储着所有多设备协同集的组队信息，没有这个信息库，登记处就无法为设备标注组队身份。具体来说，CAS的核心功能有两层，一是标识设备支持CAP接收方角色，二是若设备属于协同集则标识其组队身份，而第一层功能可独立实现，第二层功能的实现必须依托CSIS------因为CSIS是蓝牙体系中专门负责协同集标识与管理的服务，只有通过CSIS，CAS才能获取到设备的协同集信息，进而完成组队身份的标注。
这份唯一依赖的设计，是CAS规范的一大亮点：一方面大幅降低了厂商的研发成本，无需为CAS适配多个底层服务，只需完成与CSIS的联动即可；另一方面让CAS的协同逻辑更清晰，避免了多依赖带来的兼容冲突，确保不同厂商实现的CAS，在多设备协同标识上遵循统一的逻辑。
二、版本与传输：5.3打底的万能适配者
CAS的服务规则中，对蓝牙核心规范版本和传输层做了明确的兼容与依赖界定，这两点决定了CAS的适配范围和落地灵活性，也是其能覆盖传统蓝牙音频和新一代LE Audio的关键。
2.1 蓝牙核心规范兼容：5.3及以上是硬性门槛
规范明确该规格与蓝牙核心规范5.3版本及更高版本兼容，这并非随意设定的门槛，而是与CAS的应用场景和蓝牙5.3的技术升级高度契合。蓝牙5.3版本在蓝牙音频领域做了多项关键优化，包括更低的连接功耗、更强的抗干扰能力、更高效的GATT属性传输、更完善的LE Audio基础支持，这些优化恰好为CAS的标识功能提供了底层技术支撑。
比如CAS的核心是标识信息的传输与解析，蓝牙5.3提升了GATT的传输效率，让CAS的UUID、协同集标识等信息能被快速传输和解析，避免了因底层传输卡顿导致的设备识别失败；而LE Audio作为蓝牙音频的未来，其核心特性如低功耗、广播音频、多设备协同，均基于蓝牙5.3及以上版本实现，CAS兼容5.3及以上，也为其与LE Audio的深度融合铺平了道路，确保CAS能成为LE Audio设备的通用标识标准。
2.2 无传输层依赖：不绑定任何蓝牙传输方式
与明确的版本兼容要求不同，CAS没有任何与传输相关的依赖，这意味着它是一款完全的上层服务，不绑定BR/EDR（基础速率/增强数据速率）、BLE（蓝牙低功耗）等任何蓝牙传输层。无论是传统蓝牙音频设备使用的BR/EDR，还是LE Audio设备使用的BLE，甚至是未来新的蓝牙传输方式，都能实现CAS服务。
这一设计让CAS成为了蓝牙音频领域的万能适配者，厂商无需为不同传输层的设备开发定制化的CAS实现方案，一套逻辑可适配所有传输类型的蓝牙音频设备。比如同一款芯片方案，既可以做传统BR/EDR蓝牙音箱，也可以做BLE低功耗耳机，只需在现有框架下实现一次CAS，就能让两款设备都具备标准化的身份标识能力，大幅提升了研发效率，也让CAS的生态覆盖范围更广。
三、协议与过程：借道而行的轻量实现
CAS作为一款GATT层的蓝牙服务，在ATT错误码和GATT子过程上没有提出任何额外要求，而是完全沿用蓝牙核心规范的通用规则，这一设计让CAS的实现更轻量，成为了一款"零额外成本"的蓝牙服务。
3.1 无专属ATT错误码：沿用通用错误处理体系
规范明确该服务不定义或引用任何Attribute Profile错误码，ATT（属性协议）是蓝牙设备之间传输属性数据的核心协议，错误码则是设备间反馈传输问题的通用语言。CAS不新增专属错误码，意味着厂商无需为CAS开发新的错误识别和处理逻辑，只需沿用蓝牙核心规范中已有的ATT错误码体系即可。
比如当CAS标识信息传输出现超时、数据丢失时，设备会直接反馈蓝牙核心规范中定义的通用错误码，研发人员无需额外学习新的错误码含义，就能快速定位问题。这一设计保证了设备间错误处理的统一性，也让CAS的调试和维护更简单。
3.2 无额外GATT子过程：依托通用GATT框架实现
GATT（通用属性配置文件）是基于ATT的上层协议，定义了蓝牙设备之间属性数据的传输框架和子过程，所有GATT服务器都需遵循一套通用的GATT子过程要求。规范明确CAS不需要任何额外的GATT子过程，只需满足所有GATT服务器的通用要求即可。
这一点可以比喻为CAS借道通用GATT通道实现自身的标识信息传输，而不是单独开辟专属通道。对于厂商而言，这意味着无需修改现有的GATT底层逻辑，也无需开发新的GATT子过程，只需在现有GATT框架下，将CAS的相关属性（如UUID、CSIS关联信息）按规则注册即可，大幅降低了CAS的开发难度和接入成本。这也是为什么众多厂商能快速在产品中实现CAS的重要原因之一。
四、服务声明：CAS实现的四大强制铁律
服务声明是CAS服务规则的核心，也是厂商实现CAS时必须严格遵守的硬性要求，规范用多个shall句式明确了这部分内容，每一条都直指CAS标准化标识的核心需求，我们将其总结为四大强制铁律，这四条规则共同确保了CAS标识的唯一性、准确性和协同性。
铁律一：服务器上最多仅能存在一个 CAS 实例
规范中明确There shall be no more than one CAS instance on a server，shall代表强制要求，无任何变通空间。这一规则的核心目的是避免设备出现身份混乱，就像一个自然人只能有一个合法的身份证，一台蓝牙设备的服务器也只能有一个CAS标识，确保其他设备在识别时，只会获取到一个唯一的CAS身份信息，不会因多个实例导致标识解析错误。
铁律二：必须实例化为主服务，可被其他服务包含
CAS shall be instantiated as a Primary Service and may be included by other services，这一规则决定了CAS在蓝牙服务体系中的身份地位。主服务是蓝牙设备中优先级较高的服务类型，会被其他设备优先发现和解析，将CAS实例化为主服务，能确保其标识信息被快速识别，避免因服务优先级过低导致的识别延迟。而允许被其他服务包含，则让CAS的标识功能能与其他蓝牙音频服务（如A2DP、HFP）协同工作，比如音乐播放服务可包含CAS，在传输音频的同时，同步获取设备的CAS标识信息。
铁律三： UUID 必须使用蓝牙分配号的专属值
CAS的服务UUID shall be set to Common Audio Service as defined in Bluetooth Assigned Numbers，UUID是蓝牙服务的全球唯一标识码，蓝牙分配号则是蓝牙SIG统一管理的UUID库，为各类蓝牙服务分配专属的唯一标识。这一规则确保了全球所有实现CAS的设备，都使用同一个专属UUID，避免了因厂商自定义UUID导致的设备识别失败------比如设备A用自定义UUID实现CAS，设备B就无法识别其为CAS设备，而统一专属UUID则让所有设备能快速精准识别CAS服务。
铁律四：协同集设备必须关联唯一CSIS实例
If the device implementing CAS is a member of a Coordinated Set, the CAS instance shall include the CSIS instance that identifies the Coordinated Set as an included service，同时规范还明确CAS shall include no more than one instance of CSIS。这一规则是CAS实现多设备协同标识的核心，分两层含义：一是若设备属于协同集，CAS必须将该设备的CSIS实例作为内嵌服务，通过这种关联，其他设备能通过CAS直接获取到设备的CSIS协同集信息；二是CAS最多只能关联一个CSIS实例，避免了一台设备同时属于多个协同集导致的组队混乱，确保协同集标识的唯一性。
这四大强制铁律，是CAS实现标准化标识的核心保障，每一条都围绕**"唯一、准确、高效"**的原则设计，也是厂商在实现CAS时最需要重点关注的部分，任何一条的违规实现，都会导致CAS失去其通用标识的价值。
五、服务行为：无定义的安静标识员
CAS服务规则中最特殊的一点，就是明确There is no behavior defined for this service，即该服务没有任何被定义的行为。这一点让CAS与其他蓝牙音频服务形成了鲜明的对比，比如A2DP有音频传输的行为逻辑，HFP有语音通话的行为逻辑，而CAS没有任何属于自己的功能性行为。
我们可以将CAS比喻为一名安静的标识员，它的工作只有一个------为蓝牙音频设备标注身份信息，既不参与音频的传输、解码，也不参与设备的协同控制，只是将设备的CAP合规性和CSIS协同集信息，以标准化的方式呈现给其他设备，供其识别和调用。而设备的协同控制、音频传输等行为，均由CSIS、A2DP、LE Audio等其他服务完成。
这一无行为设计，是CAS规范的核心巧思：一方面让CAS的体积更轻量，实现更简单，厂商无需为其开发复杂的行为逻辑；另一方面让CAS能与其他蓝牙音频服务无缝协同，不会因行为逻辑冲突导致设备工作异常。同时，无行为设计也让CAS的扩展性更强，未来蓝牙音频体系新增任何功能性服务，都能与CAS实现联动，而无需修改CAS的底层规则。
六、写在最后：简洁是CAS的核心设计哲学
通读CAS的服务核心规则，能清晰感受到其贯穿始终的设计哲学------简洁。唯一的服务依赖、无传输层绑定、无额外协议要求、四大核心强制声明、无专属行为定义，所有规则都在做减法，没有任何冗余的设计，而这份简洁，恰恰是CAS能成为蓝牙音频通用标识标准的关键。
在蓝牙音频技术向LE Audio升级、多设备协同成为主流需求的背景下，市场需要的不是一款功能复杂的新服务，而是一款能实现标准化标识、让不同品牌、不同类型设备能无缝识别和协同的基础服务。CAS正是精准契合了这一需求，用极简的设计实现了最核心的价值，成为了LE Audio时代蓝牙音频生态的黏合剂。
而这些服务核心规则，与上一篇的基础约定共同构成了CAS完整的技术实现框架，接下来我们将在此基础上，继续精讲CAS的SDP互操作性规范，看看这款服务在传统BR/EDR蓝牙中如何实现标识的发现与传输。
七、测试
题目：CAS的唯一服务依赖是什么？该依赖对CAS的核心功能有何影响？
答案：
CAS的唯一服务依赖是CSIS协同集标识服务。该依赖决定了CAS的第二层核心功能实现，即CAS若要标识设备属于某一协同集，必须依托CSIS获取协同集信息；若无CSIS，CAS仅能实现第一层功能，即标识设备支持CAP接收方角色，无法完成多设备协同集的身份标注。
题目：简述CAS服务声明的四大强制要求，其中shall句式体现了规范的何种约束性？
答案：
四大强制要求为：
-
服务器上最多仅能存在一个CAS实例；
-
必须实例化为蓝牙主服务，可被其他服务包含；
-
UUID使用蓝牙分配号定义的专属值；
-
协同集设备的CAS必须包含一个CSIS实例，且最多仅能包含一个。
shall句式在蓝牙规范中代表强制要求，意味着厂商实现CAS时必须严格遵守，无任何变通或可选空间，是规范的核心约束性体现。
题目：CAS无服务行为定义的设计，对其落地和协同有哪些优势？
答案：
该设计的优势主要有三点：
-
实现层面，无需开发复杂的功能性行为逻辑，让CAS更轻量，厂商开发和接入成本大幅降低；
-
协同层面，不会与A2DP、LE Audio等其他蓝牙音频服务产生行为逻辑冲突，可无缝协同工作；
-
扩展层面，未来蓝牙音频体系新增任何功能性服务，都能与CAS联动，无需修改CAS底层规则，扩展性更强。