在LE Audio生态落地的过程中，多设备协同是最核心的能力之一------从TWS耳机的左右耳同步，到多音箱环绕声系统的协同响应，再到医疗传感器组的同步采样，都需要一套标准化的机制让设备彼此识别身份、确认归属，并避免多个控制端同时操作的冲突。而Coordinated Set Identification Service（CSIS）正是蓝牙SIG为解决这一问题制定的核心服务规范，也是LE Audio多设备协同的底层基石。
目录
[5.1 传输依赖：基于GATT，支持增强型ATT承载](#5.1 传输依赖：基于GATT，支持增强型ATT承载)
[5.2 字节传输顺序：全特征强制小端序](#5.2 字节传输顺序：全特征强制小端序)
[7.1 版本演进：v1.1的核心更新](#7.1 版本演进：v1.1的核心更新)
[7.2 关键术语约束：RFU与Prohibited的区别](#7.2 关键术语约束：RFU与Prohibited的区别)
作为CSIS系列精讲的第一篇，本文将从该服务的核心定义出发，拆解其协议基础、合规准则、交互规则与底层约束，把看似枯燥的协议定义转化为可落地的开发认知。这些内容是理解后续安全机制、特征实现、广播数据设计的前提，也是实际开发中避免协议一致性测试失败的关键。文中会结合蓝牙SIG的官方规范细节，用开发者的视角解读核心要点。让抽象的协议变得易懂。
一、CSIS的核心定位
想要理解CSIS，首先要明确它的核心作用------规范里对其的核心定义是实现设备的协调集成员识别，并为客户端授予协调集的独占访问权，避免多客户端访问的竞争条件。简单来说，CSIS既像给每个设备分配了属于某个团队的身份证，又像给这个团队设置了唯一的门禁，只有拿到门禁权限的控制端，才能对团队内的设备进行操作。
规范中明确提到，CSIS对设备的实际功能和特性是无感知的，它不负责设备之间的业务数据传输，也不定义设备的协同操作逻辑，只解决身份识别和独占访问两个核心问题。这一特性让CSIS具备极强的通用性，无论是音频设备、医疗传感器，还是工业物联网节点，只要需要多设备协同，都可以基于CSIS实现基础的身份与访问管理。
而这里的核心概念协调集，是指为特定场景配置的一组设备，这些设备会以协调的方式响应控制指令或执行操作。规范中给出了典型的协调集例子：一对助听器、一副TWS耳机、接收多声道音频的音箱组，或是心电传感器、胎压传感器等触发同步测量的传感器节点。这些设备的共同特征是，它们属于同一个业务场景，需要被控制端识别为一个整体，且操作需要同步完成。
举个直观的例子：当我们用手机连接TWS耳机时，手机需要先识别出左右耳耳机属于同一个协调集，而非两个独立的蓝牙设备；同时，手机需要获得这个协调集的独占访问权，避免另一部手机同时连接并控制耳机，这两个核心步骤，都是由CSIS完成的。而如果是一套5.1环绕声音箱系统，6个音箱会组成一个协调集，电视作为控制端，通过CSIS识别所有音箱的身份，并获得独占访问权，从而实现多声道音频的同步播放。
二、协议合规性准则：CSIS实现的硬性标尺
任何蓝牙官方服务规范，都有明确的合规性要求，CSIS也不例外。合规性定义了哪些功能是必须实现的、哪些是可选的、哪些是有条件实现的，这是开发时必须遵循的硬性标尺，也是协议一致性测试的核心考核点。
规范中将CSIS的需求定义为四种类型，分别是强制（Mandatory，M） 、可选（Optional，O） 、排除（Excluded，X）和条件（Conditional，C.n）。其中条件型需求会在对应表格下方给出具体的条件说明，只有满足条件时，该需求才会生效。合规性的核心要求是：规范中定义的每一项能力，都必须按指定方式实现；如果选择实现某个可选功能，也必须严格遵循规范中的定义，不能随意修改。
在实际开发中，合规性的判断是第一步。比如后续会讲到的Set Identity Resolving Key特征是强制实现的，而Coordinated Set Size是可选实现的；Set Member Rank则是条件型的，只有实现了Set Member Lock特征时，才需要强制实现。如果忽略了条件型需求的判断，比如实现了锁特征却未实现排名特征，会直接导致协议一致性测试不通过。
同时，规范中对协议术语的使用制定了严格的语言约定，这也是合规性的一部分。比如shall/mandatory 表示规范强制要求，必须严格实现无偏差；shall not 表示禁止操作，绝对不能违反；should 表示推荐实现，不强制但建议遵循；may/optional 表示允许实现，开发者可根据产品需求选择；must则表示客观事实或必然结果。这些术语的含义在规范中是唯一的，不会随场景变化，开发时需要准确理解------比如当规范中说某个字段shall设为0时，就不能为了开发便利设为其他值。
三、运行基础：服务依赖与蓝牙核心规范兼容
CSIS的运行不需要依赖任何其他蓝牙服务，这是其一个重要的特性。作为一个独立的GATT主服务，CSIS可以直接运行在蓝牙协议栈的GATT层上，无需提前实现其他服务作为基础。这一特性简化了产品的开发流程，尤其是对于小型设备（如低成本传感器、入门级TWS耳机），可以只实现CSIS核心功能，而无需集成其他非必要服务，减少固件体积和开发成本。
在蓝牙核心规范的兼容性上，CSIS支持蓝牙4.2及以上版本，这意味着该服务可以在绝大多数现有的蓝牙设备上实现，无需升级到最新的蓝牙5.2/5.3/6.0版本。这一兼容设计让CSIS的落地门槛大幅降低，无论是老旧设备的升级，还是新设备的开发，都可以快速集成CSIS功能。
需要注意的是，虽然CSIS兼容蓝牙4.2及以上版本，但如果需要实现更高效的传输（比如增强型ATT承载），则需要蓝牙5.2及以上版本的支持，这一点会在后续的传输依赖部分详细讲解。
四、GATT子过程要求：CSIS设备的交互规则
CSIS基于GATT（通用属性配置文件）实现，因此其与客户端的交互需要遵循GATT子过程的相关要求。规范中定义了CSIS服务器端的最小GATT子过程需求，超出该范围的子过程，只要客户端和服务器端都支持，即可使用。
针对非增强型ATT承载，规范中明确了额外的GATT子过程要求，核心分为条件C.1和条件C.2两类，具体要求如下：
|-------------|----------|------------------------------|
| GATT子过程 | 需求类型 | 适用条件 |
| 写入特征值 | C.1 | 实现Set Member Lock特征则强制，否则可选 |
| 通知 | C.1 | 实现Set Member Lock特征则强制，否则可选 |
| 读取特征描述符 | C.1 | 实现Set Member Lock特征则强制，否则可选 |
| 写入特征描述符 | C.1 | 实现Set Member Lock特征则强制，否则可选 |
| 读取长特征值 | C.2 | 服务器支持大于最小ATT_MTU的特征值则强制，否则可选 |
这里的核心是理解条件C.1和C.2的触发逻辑：
C.1的核心：锁特征是CSIS实现独占访问的关键，一旦产品需要实现锁特征，就必须支持写入特征值、通知、读写特征描述符这四个GATT子过程------因为锁特征的操作（加锁、解锁、状态通知）都依赖这些子过程，缺少任何一个，都无法实现完整的锁机制。
C.2的核心：ATT_MTU是蓝牙ATT层的最大传输单元，最小为23字节。如果CSIS的某个特征值长度超过23字节（比如Coordinated Set Name特征支持最长128字节的UTF-8字符串），服务器就必须支持读取长特征值子过程，否则客户端无法完整读取特征值。
在实际开发中，我们需要根据产品的功能需求，提前判断需要支持的GATT子过程。比如一款不支持独占访问的低成本单声道蓝牙音箱，无需实现锁特征，因此C.1对应的子过程都可以选择不实现；而一款支持自定义名称的TWS耳机，其名称特征值可能超过23字节，因此必须实现读取长特征值子过程。
五、传输与字节序：CSIS数据的传输规则
5.1 传输依赖：基于GATT，支持增强型ATT承载
CSIS的传输完全基于GATT，因此没有额外的传输依赖，只要设备支持GATT层，即可运行CSIS。但规范中对ATT承载的类型做了区分，分为增强型ATT承载（EATT）和非增强型ATT承载，两者的核心区别在于传输的可靠性和效率。
非增强型ATT承载基于传统的L2CAP信道，其GATT通知是不可靠的------通知消息可能丢失，且没有重传机制。如果产品使用非增强型ATT承载实现CSIS，需要在应用层做容错处理，比如对关键的状态通知（如锁状态变化），客户端需要定期读取特征值，确认状态的准确性。
增强型ATT承载基于蓝牙5.2引入的增强型基于信用的流控L2CAP信道模式，其传输更可靠、效率更高，GATT通知的丢失率大幅降低。规范中允许高层配置文件指定使用增强型ATT承载，对于对传输可靠性要求高的产品（如医疗传感器、工业设备），建议使用增强型ATT承载，减少应用层的容错开发成本。
5.2 字节传输顺序：全特征强制小端序
规范中明确要求，CSIS的所有特征在传输时，都必须遵循最低有效字节（LSO）优先 的原则，也就是我们常说的小端序 。小端序是蓝牙协议中常见的传输方式，但CSIS的特殊之处在于，所有特征都强制遵循这一规则，没有例外。
在实际开发中，字节序的处理是一个高频踩坑点。比如在实现128位的SIRK特征时，需要将密钥的最低有效字节放在传输数据的首位，而非按人类的阅读习惯将最高有效字节放在首位。如果字节序处理错误，会导致客户端无法正确解析特征值，比如无法识别SIRK、无法读取协调集大小等，最终导致设备间的身份识别失败。
这里给一个简单的实操建议：在开发时，为CSIS单独封装一个字节序转换函数，所有特征值在传输前都通过该函数转换为小端序，避免手动转换出现错误。
六、应用错误码：CSIS交互的错误语言
为了让CSIS服务器和客户端之间的交互更清晰，规范中定义了6个专属的ATT应用错误码，这些错误码是设备间的错误语言，每个错误码对应特定的操作场景，开发时需要严格按照规范返回错误码，不能使用通用的蓝牙错误码替代。
这6个错误码的核心含义和适用场景如下，也是开发和调试中最常遇到的错误类型：
|---------|--------------------------------|-------------------------------------|
| 错误码 | 名称 | 核心含义与适用场景 |
| 0x80 | Lock Denied | 锁请求被拒绝，原因是服务器已被其他客户端锁定 |
| 0x81 | Lock Release Not Allowed | 锁释放被拒绝，原因是锁归其他客户端所有 |
| 0x82 | Invalid Lock Value | 写入无效的锁值，原因是客户端写入了非锁定/解锁的RFU值 |
| 0x83 | OOB SIRK Only | 拒绝读取SIRK，原因是服务器仅支持通过带外（OOB）方式暴露SIRK |
| 0x84 | Lock Already Granted | 锁请求被拒绝，原因是客户端已持有该锁 |
| 0x85 | Value Changed During Read Long | 长特征值读取失败，原因是读取过程中特征值被修改 |
这些错误码的返回时机有严格的规范，比如当客户端重复请求已持有的锁时，服务器必须返回0x84，而非通用的"操作失败"错误码；当客户端尝试释放其他设备持有的锁时，必须返回0x81，而非"权限不足"。在调试时，这些错误码也是定位问题的关键------比如当客户端收到0x80错误码时，即可明确是协调集已被其他控制端锁定，而非本地代码逻辑错误。
需要特别注意的是0x85错误码，它仅适用于长特征值的读取过程。比如客户端正在读取128字节的协调集名称，此时服务器修改了名称，服务器需要立即返回0x85错误码，终止读取过程。这一设计是为了避免客户端读取到不完整、不一致的特征值。
七、版本演进与术语约束
7.1 版本演进：v1.1的核心更新
CSIS的规范从2021年的v1.0，到2022年的v1.0.1，再到2025年的v1.1，核心功能未发生大的变化，主要是修复了勘误并新增了实用特征。其中v1.1的核心更新有两点：
新增Coordinated Set Name特征：为协调集添加了人类可读的名称，客户端可以直接读取协调集的名称，提升了用户体验，比如TWS耳机可以将协调集名称设为"XX耳机"，手机连接时可直接显示；
修复多处勘误：包括合规性、传输依赖、锁特征行为、参考文献等部分的勘误，让规范的定义更严谨，减少了开发时的歧义。
v1.1作为目前的最新版本，也是现在开发中推荐遵循的版本，其新增的名称特征几乎成为了消费电子设备的标配，是提升产品体验的重要细节。
7.2 关键术语约束：RFU与Prohibited的区别
规范中对两个高频出现的术语做了严格的定义，分别是RFU（Reserved for Future Use，保留供未来使用）和Prohibited（禁止），这两个术语的含义完全不同，开发时混淆会导致严重的协议错误。
RFU字段：设备在创建数据包时，必须将RFU字段设为0；接收设备在解析时，需要忽略RFU字段，不能因为RFU字段的值非0而拒绝解析数据包。如果是RFU的位字段，未分配的位必须设为0，接收设备遇到设为1的RFU位，需按0处理。
Prohibited值：设备绝对不能使用Prohibited的字段值；接收设备如果收到包含Prohibited值的数据包，必须拒绝解析，且不做任何响应和处理。
简单来说，RFU是预留未来使用，现在设0忽略 ，而Prohibited是现在绝对不能用，用了就拒绝。比如协调集大小的特征值中，0x00是Prohibited值，设备不能将协调集大小设为0，客户端收到0x00的话直接拒绝；而锁特征的字段中，除了0x01（解锁）和0x02（锁定），其他值都是RFU，客户端写入这些值时，服务器返回0x82错误码。
此外，规范中还对EATT、增强型/非增强型ATT承载做了明确定义，这些术语是理解后续传输和特征实现的基础，这里不再赘述，只需记住：EATT是增强型ATT承载的缩写，是蓝牙5.2引入的特性，主打更可靠的传输。
八、测试
问题：CSIS对蓝牙核心规范的兼容性要求是什么？其服务依赖特性如何？这一特性带来了哪些开发优势？
答案：
CSIS兼容蓝牙4.2及以上版本的核心规范；该服务无任何其他蓝牙服务依赖，是独立的GATT主服务。开发优势体现在两点：一是落地门槛低，绝大多数蓝牙设备均可集成，无需升级核心协议栈；二是简化开发流程，可仅实现CSIS核心功能，减少固件体积和开发成本，尤其适合小型低功耗设备。
问题：CSIS中GATT子过程的条件性要求C.1和C.2分别对应的触发条件和核心子过程是什么？请简要说明。
答案：
C.1的触发条件是设备实现Set Member Lock锁特征，触发后需强制支持写入特征值、通知、读取特征描述符、写入特征描述符四个GATT子过程；C.2的触发条件是服务器支持大于最小ATT_MTU（23字节）的特征值，触发后需强制支持读取长特征值子过程。
问题：CSIS定义的应用错误码中，0x80（Lock Denied）和0x84（Lock Already Granted）的核心区别是什么？分别在什么场景下返回？
答案：
核心区别是锁的归属不同：0x80是服务器已被其他客户端 锁定，当前客户端的锁请求被拒绝；0x84是当前客户端已持有锁，重复发起锁请求被拒绝。0x80适用于多客户端竞争锁的场景，0x84适用于客户端单次会话内重复请求锁的场景。