【LE Audio】CSIP精讲[4]：Set Coordinator全流程管控与实现精要

在LE Audio的技术体系中，多设备协同是核心能力之一------从双耳TWS耳机的同步调音，到多音箱组的环绕声播放，再到医疗传感器的联合采集，都需要一套标准化的机制实现设备集群的统一识别、访问与控制。Coordinated Set Identification Profile（CSIP）正是为解决这一问题而生，而Set Coordinator作为CSIP体系中的核心协调者，就像多设备集群的指挥中心，负责完成协调集的发现、成员遍历、排他访问、有序操作等全流程工作。

[一、CSIP与Set Coordinator的核心定位](#一、CSIP与Set Coordinator的核心定位)

[二、Set Coordinator的能力基线：必选、可选与条件性要求](#二、Set Coordinator的能力基线：必选、可选与条件性要求)

[2.1 核心能力要求的分类与解读](#2.1 核心能力要求的分类与解读)

[2.2 条件性要求的核心触发条件：Bondable mode](#2.2 条件性要求的核心触发条件：Bondable mode)

[2.3 能力基线的设计逻辑：从能工作到体验好](#2.3 能力基线的设计逻辑：从能工作到体验好)

[三、GATT子过程能力：Set Coordinator的技术支撑](#三、GATT子过程能力：Set Coordinator的技术支撑)

[3.1 GATT子过程的要求分类](#3.1 GATT子过程的要求分类)

[3.2 关键子过程的核心价值](#3.2 关键子过程的核心价值)

[3.3 GATT子过程要求的设计逻辑：灵活性与规范性平衡](#3.3 GATT子过程要求的设计逻辑：灵活性与规范性平衡)

四、服务与特征发现

[4.1 服务发现：找到核心的CSIS服务](#4.1 服务发现：找到核心的CSIS服务)

[4.2 特征发现：获取协调集的核心信息](#4.2 特征发现：获取协调集的核心信息)

[4.3 服务与特征发现的实操流程](#4.3 服务与特征发现的实操流程)

[五、CSIS核心操作流程：Set Coordinator的全生命周期管理能力](#五、CSIS核心操作流程：Set Coordinator的全生命周期管理能力)

[5.1 协调集发现流程：找到协调集的身份证号](#5.1 协调集发现流程：找到协调集的身份证号)

[5.2 成员节点发现流程：遍历协调集的所有前线终端](#5.2 成员节点发现流程：遍历协调集的所有前线终端)

[5.3 锁申请与锁释放流程：实现协调集的排他控制权](#5.3 锁申请与锁释放流程：实现协调集的排他控制权)

[5.4 有序访问流程：无绑定模式下的竞争缓解方案](#5.4 有序访问流程：无绑定模式下的竞争缓解方案)

[5.5 读取协调集名称流程：提升用户体验的锦上添花](#5.5 读取协调集名称流程：提升用户体验的锦上添花)

[六、Set Coordinator的实操设计考量：从协议到落地](#六、Set Coordinator的实操设计考量：从协议到落地)

[6.1 秩次（Set Member Rank）的设计：定义协调集的操作优先级](#6.1 秩次（Set Member Rank）的设计：定义协调集的操作优先级)

[6.2 定时器的配置：平衡效率与鲁棒性](#6.2 定时器的配置：平衡效率与鲁棒性)

[6.3 多协调集的处理：实现隔离与高效管理](#6.3 多协调集的处理：实现隔离与高效管理)

[6.4 跨传输适配：兼顾LE和BR/EDR的特性](#6.4 跨传输适配：兼顾LE和BR/EDR的特性)

[6.5 安全与隐私：守护协调集的通信安全](#6.5 安全与隐私：守护协调集的通信安全)

七、测试

本文围绕Set Coordinator的核心能力要求、技术基线、操作流程展开深度解析，从协议设计逻辑到实际落地考量，把这套看似抽象的蓝牙协议转化为可理解、可落地的实操知识，同时结合实际应用场景做通俗化解读，让你真正吃透CSIP中协调者的设计与实现。

一、CSIP与Set Coordinator的核心定位

要理解Set Coordinator的能力要求，首先要明确其在CSIP体系中的角色边界和价值。CSIP的核心目标是定义Coordinated Set（协调集） 的识别与管理机制，所谓协调集，就是为了实现特定业务场景而组合的设备集群，比如一对TWS耳机、一套5.1声道音箱、一组心电监测传感器，这些设备需要接收统一的控制指令并做出协同响应。

在CSIP的二元角色模型中，分为Set Coordinator（协调者） 和Set Member（成员节点） 两类设备：

Set Coordinator是GATT Client角色，作为协调集的控制方，负责发现协调集、遍历所有成员节点、申请排他访问权限、执行有序控制操作，是整个集群的指挥中心；

Set Member是GATT Server角色，作为协调集的终端节点，需要实例化Coordinated Set Identification Service（CSIS），对外暴露协调集的标识、大小、名称等核心信息，接受Set Coordinator的控制。

二者的关系就像指挥中心与前线终端------前线终端只需要按规范暴露自身信息和控制接口，而指挥中心需要具备从找到第一个终端到统一指挥所有终端的全流程能力，这也是Set Coordinator的能力要求被单独重点定义的原因。

需要注意的是，CSIP协议本身与设备的具体业务功能解耦，只负责协调集的识别与访问管理，而具体的协同控制逻辑（比如音量同步、音频流分发）则由更高层的LE Audio协议定义，Set Coordinator只需要完成打通控制链路的基础工作。同时，CSIP兼容蓝牙4.2及以上版本，支持LE和BR/EDR两种传输方式，Set Coordinator的能力设计也充分考虑了跨传输的适配性。

二、Set Coordinator的能力基线：必选、可选与条件性要求

Set Coordinator的所有能力要求都围绕完成协调集的全生命周期管理展开，协议将其能力分为必选（M） 、可选（O） 和条件性（C.n） 三类，其中条件性要求是协议设计的灵活性体现，会根据设备是否支持特定功能（如Bondable mode）而变化。这一能力基线是设计Set Coordinator的核心依据，也是协议对协调者的最低要求定义。

2.1 核心能力要求的分类与解读

协议中明确了Set Coordinator的10项核心能力要求，其中必选能力是所有协调者必须实现的基础，条件性要求则是针对高级功能的扩展，具体如下：

必选能力：服务发现、特征发现、协调集发现流程、成员节点发现流程、RSI解析、有序访问流程。这6项能力是实现协调集基础管理的核心，缺一不可，比如RSI解析是识别协调集成员的关键，有序访问流程是避免多客户端竞争的基础；

条件性能力C.1 ：SIRK解密功能、锁申请流程、锁释放流程。这三项能力仅当设备支持Bondable mode时为必选，否则不支持。Bondable mode是蓝牙的绑定模式，支持该模式的设备可以建立长期绑定关系，实现更安全的排他访问，而SIRK解密是获取加密协调集标识的关键，锁申请/释放则是排他访问的核心流程；

条件性能力C.2 ：读取协调集名称流程。该能力仅当Set Coordinator支持协调集名称特征时为必选，否则为可选。协调集名称是为了提升用户体验，让设备能以统一名称展示整个集群（如"我的TWS耳机"），而非单独展示每个成员节点，属于非核心的体验类能力。

2.2 条件性要求的核心触发条件：Bondable mode

Bondable mode是蓝牙核心规范中定义的设备模式，支持该模式的设备可以与其他设备建立绑定关系，存储长期密钥（LTK），实现免密重连和更安全的通信。协议将SIRK解密、锁申请/释放绑定到Bondable mode，核心原因是：

加密的SIRK是协调集的安全标识，只有绑定后的设备才有解密权限，避免协调集信息被未授权设备获取；

排他锁的申请与释放需要基于安全的绑定关系，防止未授权设备抢占控制权限，导致协调集的控制混乱。

如果设备不支持Bondable mode，就无法实现加密SIRK的解析和排他锁的管理，此时协议提供有序访问流程作为替代方案，通过非加密的方式降低多客户端竞争的概率，满足基础的协同控制需求。这一设计充分兼顾了协议的安全性和兼容性，既满足了高端设备的安全需求，也为入门级设备保留了基础功能。

2.3 能力基线的设计逻辑：从能工作到体验好

Set Coordinator的能力基线设计遵循从基础到高级、从功能到体验的逻辑：必选能力确保协调者能完成协调集的基础管理，条件性能力则在基础功能之上实现更安全、更友好的管理。比如：

必选的RSI解析和成员节点发现流程，确保协调者能找到协调集的所有成员，完成最基础的集群识别；

条件性的锁申请/释放流程，在基础识别之上实现排他访问，避免多手机同时控制同一套TWS耳机的问题；

条件性的读取协调集名称流程，在功能之上提升用户体验，让用户能以集群为单位管理设备。

这种设计让不同厂商、不同定位的设备可以根据自身需求选择能力实现范围，既保证了协议的通用性，又为产品差异化设计留出了空间。

三、GATT子过程能力：Set Coordinator的技术支撑

Set Coordinator作为GATT Client，所有的服务发现、特征读写、流程执行都基于GATT子过程实现，协议对Set Coordinator的GATT子过程能力做出了明确要求，这是协调者能与Set Member进行通信的技术基础。如果把Set Coordinator的核心能力比作指挥中心的业务能力，那么GATT子过程能力就是指挥中心的通信基础设施，基础设施不到位，业务能力就无从谈起。

3.1 GATT子过程的要求分类

协议在通用GATT Client要求的基础上，为Set Coordinator补充了13项具体的子过程要求，同样分为必选、可选和条件性三类，核心可以分为服务发现类 、特征发现类 、特征读写类 、通知类 和辅助类五大类，具体要求如下：

必选子过程：发现所有特征描述符、查找包含服务、读取特征值、写入特征值、读取特征描述符。这5项是GATT Client与Server通信的基础，比如读取/写入特征值是Set Coordinator与Set Member交互的核心方式，查找包含服务则是识别多协调集成员节点的关键；

条件性子过程C.1 ：发现所有主服务、通过UUID发现主服务。至少支持其中一项，否则为可选。这是服务发现的两种核心方式，协议不强制具体实现方式，只要求能完成主服务发现，兼顾了实现的灵活性；

条件性子过程C.2 ：发现服务的所有特征、通过UUID发现特征。至少支持其中一项，否则为可选。与服务发现类似，这是特征发现的两种核心方式，满足即可；

条件性子过程C.3 ：写入特征描述符。仅当支持通知子过程时为必选，否则不支持。特征描述符是配置通知的关键，比如Client Characteristic Configuration（CCCD）描述符，写入该描述符才能开启特征的通知功能；

条件性子过程C.4 ：交换MTU、读取长特征值。仅当支持协调集名称特征时为必选，否则为可选。协调集名称是可变长度的字符串，可能超过默认的ATT_MTU长度，需要通过交换MTU提升传输效率，通过读取长特征值获取完整的名称信息；

可选子过程：通知。支持则可以接收Set Member的特征值变化通知（如SIRK变化、协调集大小变化），不支持则需要通过轮询获取最新信息，属于体验类优化。

3.2 关键子过程的核心价值

在所有GATT子过程中，有几项是Set Coordinator实现核心功能的关键，其设计价值和实际作用需要重点理解：

查找包含服务（Find Included Services） ：这是识别多协调集成员节点的核心。部分Set Member可能属于多个协调集（比如一款智能音箱既属于客厅的音箱组，又属于全屋的智能设备组），此时会实例化多个CSIS，每个CSIS对应一个协调集。Set Coordinator需要通过查找包含服务，找到每个CSIS对应的上层服务，从而区分不同的协调集；

发现所有特征描述符（Discover All Characteristic Descriptors）：特征描述符包含了特征的关键配置信息（如通知权限、读写权限），Set Coordinator需要通过该子过程获取描述符信息，才能完成特征的配置和交互，比如开启SIRK的通知功能；

读取长特征值（Read Long Characteristic Values）：针对可变长度的特征值（如协调集名称），默认的ATT_MTU可能无法承载完整的信息，此时需要通过该子过程分段读取，确保获取完整的特征值。

3.3 GATT子过程要求的设计逻辑：灵活性与规范性平衡

协议对GATT子过程的要求设计，充分体现了灵活性与规范性的平衡：

规范性：对核心的读写、发现子过程做必选要求，确保所有Set Coordinator都能实现基础的GATT通信，保证协议的互通性；

灵活性：对服务发现、特征发现的具体方式做"二选一"的条件性要求，对体验类的子过程（如通知、交换MTU）做可选或条件性要求，让厂商可以根据设备的硬件资源、定位和需求选择实现方式，避免过度的技术限制。

比如，入门级的蓝牙设备硬件资源有限，可以选择实现通过UUID发现主服务这种更高效的方式，而不实现发现所有主服务；高端设备则可以实现所有子过程，提升通信的灵活性和体验。

四、服务与特征发现

如果把协调集的成员节点比作未知的环境，那么服务发现 和特征发现 就是Set Coordinator的环境探索能力------只有先找到Set Member上的CSIS服务，再发现该服务下的核心特征，才能获取协调集的标识、大小、锁状态等关键信息，为后续的协调集管理打下基础。服务与特征发现是Set Coordinator执行所有流程的前置步骤，协议对其做出了严格且详细的要求。

4.1 服务发现：找到核心的CSIS服务

服务发现的核心目标是在Set Member上找到CSIS服务，这是所有后续操作的起点。协议对Set Coordinator的服务发现流程做出了明确要求，同时兼顾了LE和BR/EDR两种传输方式的适配性：

传输方式适配：在LE传输下，Set Coordinator必须使用发现所有主服务或通过UUID发现主服务中的一种；在BR/EDR传输下，遵循通用的GATT服务发现规范；

核心要求 ：无论采用哪种方式，Set Coordinator必须发现CSIS服务，因为CSIS是Set Member暴露协调集信息的唯一服务，没有找到CSIS，就无法获取任何协调集相关信息；

多CSIS处理 ：如果Set Member实例化了多个CSIS（属于多个协调集），Set Coordinator必须通过查找包含服务子过程，找到每个CSIS对应的上层服务，从而区分不同的协调集，确定目标协调集的CSIS实例。

CSIS服务的UUID是协议预定义的，Set Coordinator可以通过UUID快速定位该服务，这也是最高效的服务发现方式。在实际开发中，推荐优先实现通过UUID发现主服务，既可以提升发现效率，又能减少与其他无关服务的交互。

4.2 特征发现：获取协调集的核心信息

特征发现的核心目标是发现CSIS服务下的所有核心特征 ，协议为CSIS定义了5项核心特征，Set Coordinator对这些特征的发现要求分为必选和可选两类，这也是协调集管理的信息基础。5项核心特征的发现要求和核心价值如下：

|----------------------------------|----------|---------------------------|
| 特征名称 | 发现要求 | 核心价值 |
| Set Identity Resolving Key（SIRK） | 必选 | 协调集的唯一身份标识，是识别协调集和成员节点的核心 |
| Coordinated Set Size | 必选 | 协调集的成员节点数量，是判断是否找到所有成员的依据 |
| Set Member Lock | 必选 | 协调集的锁状态，是实现排他访问和有序访问的关键 |
| Set Member Rank | 必选 | 成员节点的秩次，是定义操作顺序的依据 |
| Coordinated Set Name | 可选 | 协调集的人类可读名称，提升用户体验 |

4.2.1 必选特征的核心作用

4项必选特征是Set Coordinator实现协调集管理的核心，彼此之间相互配合，构成了协调集的基础信息体系：

SIRK：是协调集的身份证号，每个协调集有唯一的SIRK，成员节点会基于SIRK生成RSI（可解析标识）并对外广播，Set Coordinator通过解析RSI就能识别该节点是否属于目标协调集；SIRK支持加密（Type=0x00）和明文（Type=0x01）两种形式，加密形式需要通过SIRK解密功能解析；
Coordinated Set Size：是协调集的成员数量，比如TWS耳机的该值为2，5.1音箱组的该值为6，Set Coordinator通过该值可以判断是否已经找到协调集的所有成员节点；
Set Member Lock：是协调集的权限锁，有Locked和Unlocked两种状态，Locked表示该节点已被某个Set Coordinator控制，Unlocked表示该节点处于空闲状态；
Set Member Rank：是成员节点的优先级序号，协议规定按秩次从小到大的顺序执行操作（如锁申请），秩次0x01为最高优先级，通常分配给协调集中最核心的节点（如TWS耳机的主耳机）。

4.2.2 特征发现的附加要求

除了发现特征本身，协议还对特征发现的附加操作做出了要求：

通知配置：如果某个特征支持通知（如SIRK、Coordinated Set Size），Set Coordinator可以发现并配置其CCCD描述符，开启通知功能。当特征值发生变化时（如协调集成员数量增加），Set Member会主动向Set Coordinator发送通知，Set Coordinator可以及时做出响应（如重新执行成员节点发现流程）；
描述符发现：Set Coordinator必须发现所有特征的描述符，尤其是CCCD描述符，这是配置特征通知、读写权限的关键；
长特征值处理 ：如果协调集名称特征的长度超过（ATT_MTU-3）个字节，Set Coordinator需要通过读取长特征值子过程获取完整的名称信息，确保名称展示的准确性。

4.3 服务与特征发现的实操流程

在实际开发中，Set Coordinator的服务与特征发现是一个标准化的串行流程 ，遵循**"连接Set Member→发现主服务→定位CSIS→发现CSIS特征→发现特征描述符→配置通知（可选）"**的步骤，具体如下：

Set Coordinator通过GAP流程与目标Set Member建立连接；
执行服务发现子过程，遍历Set Member上的所有主服务或通过UUID直接定位CSIS服务；
如果存在多个CSIS服务，执行查找包含服务子过程，区分不同协调集的CSIS实例，确定目标CSIS；
执行特征发现子过程，发现目标CSIS下的所有核心特征；
执行特征描述符发现子过程，发现每个特征的描述符（尤其是CCCD）；
对需要开启通知的特征（如SIRK），写入CCCD描述符，开启通知功能；
读取必选特征的初始值，获取协调集的基础信息，为后续流程做准备。

这一流程是标准化的，所有Set Coordinator都需要遵循，确保了不同厂商设备之间的互通性。在实际开发中，可以通过优化发现顺序（如优先通过UUID发现CSIS）提升发现效率。

五、CSIS核心操作流程：Set Coordinator的全生命周期管理能力

如果说服务与特征发现是Set Coordinator的环境探索能力，那么CSIS核心操作流程 就是协调者的核心业务能力 ------协议定义了六大核心流程，覆盖了从发现协调集到访问协调集的全生命周期，分别是：协调集发现流程、成员节点发现流程、锁申请流程、锁释放流程、有序访问流程、读取协调集名称流程。这六大流程是Set Coordinator设计与实现的核心重点，也是协议的核心内容。

5.1 协调集发现流程：找到协调集的身份证号

协调集发现流程是Set Coordinator管理协调集的第一个核心流程 ，核心目标是获取目标协调集的唯一标识SIRK，同时获取协调集的大小、成员节点秩次等基础信息，相当于为指挥中心找到集群的身份证号，只有拿到这个身份证号，才能后续识别集群的所有成员。

5.1.1 流程触发条件

Set Coordinator在与至少一个Set Member建立连接 ，并完成CSIS服务与特征发现后，触发该流程。触发的前提是Set Coordinator已经通过广播数据、用户选择等方式，确定了一个待识别的Set Member，这是流程的起点。

5.1.2 核心操作步骤

协调集发现流程是一个标准化的串行步骤，协议对每个步骤都做出了必选要求，具体如下：

1. 定位目标CSIS：如果Set Member实例化了多个CSIS，Set Coordinator通过查找包含服务子过程，确定目标协调集对应的CSIS实例，避免操作错误的协调集；

2. 读取SIRK特征值：Set Coordinator读取Set Identity Resolving Key特征值，获取SIRK的原始数据，包括Type字段和Value字段；

3. 解析SIRK：根据Type字段的值解析SIRK：

Type=0x00：SIRK为加密形式，Set Coordinator调用SIRK解密函数，将EncSIRK（Value字段）作为输入，解密得到真实的SIRK；
Type=0x01：SIRK为明文形式，Set Coordinator直接将Value字段作为真实的SIRK；

4. 读取必选附加特征：Set Coordinator读取Set Member Rank特征值和Coordinated Set Size特征值（如果Set Member支持）；

5. OOB方式补充（可选）：Set Coordinator也可以通过带外（OOB）方式（如NFC、二维码）获取SIRK和协调集大小，作为GATT读取的补充。

5.1.3 成功与失败判定

协议对协调集发现流程的成功和失败判定做出了严格定义，这是流程执行的核心节点，也是开发中需要重点处理的逻辑：

成功判定：Set Coordinator成功获取SIRK值，且成功读取所有Set Member暴露的必选附加特征（Set Member Rank、Coordinated Set Size），流程完成；
失败判定：出现以下任意一种情况，流程失败：
- 无法通过GATT读取或OOB方式获取SIRK值；
- 无法读取Set Member暴露的Set Member Rank特征值；
- 无法读取Set Member暴露的Coordinated Set Size特征值。

流程失败后，Set Coordinator无法继续管理该协调集，需要向上层应用返回错误信息，由应用决定是否重试或终止操作。

5.1.4 实操设计考量

在实际开发中，协调集发现流程的设计需要注意两个关键点：

多CSIS的区分：必须通过查找包含服务子过程定位目标CSIS，避免因操作错误的CSIS导致后续流程全部出错；
SIRK的安全存储：SIRK是协调集的核心标识，尤其是加密的SIRK，需要安全存储，避免泄露，防止未授权设备解析RSI识别协调集成员；
重试机制：如果GATT读取失败，建议增加重试机制（如3次重试），提升流程的鲁棒性，避免因临时的通信干扰导致流程失败。

5.2 成员节点发现流程：遍历协调集的所有前线终端

成员节点发现流程是在协调集发现流程成功完成 后触发的，核心目标是根据SIRK解析RSI，找到协调集的所有成员节点 ，相当于指挥中心根据集群的身份证号，找到所有的前线终端。这一流程是实现协调集统一管理的关键步骤，协议对其传输适配、解析逻辑、超时机制做出了详细要求。

5.2.1 流程触发条件

Set Coordinator成功获取目标协调集的SIRK值后，触发该流程。如果Set Coordinator接收到SIRK或Coordinated Set Size特征的通知（特征值变化），也会重新触发该流程，确保成员节点信息的实时性。

5.2.2 核心操作步骤

成员节点发现流程的核心是RSI的扫描与解析，协议对LE和BR/EDR两种传输方式的扫描方式做出了不同要求，整体步骤如下：

1. 配置扫描参数：Set Coordinator配置扫描参数，其中LE传输下扫描包含RSI AD Type的广播PDU，BR/EDR传输下执行设备发现流程，接收包含RSI AD Type的扩展查询响应数据；

2. 设置超时定时器 ：Set Coordinator可选设置定时器T_CSIP(set_member_discovery_timeout)，协议建议该定时器的值为10秒，用于控制扫描的最大时长；

3. 扫描并接收RSI ：Set Coordinator开始扫描，接收所有Set Member广播的RSI数据，需要注意的是，Set Member可能广播多个包含RSI的广播集，因此Set Coordinator应该关闭重复广播报告过滤，避免遗漏；

4. 解析RSI：Set Coordinator调用RSI解析函数，使用之前获取的SIRK作为密钥，解析接收到的RSI数据；

5. 验证并连接节点：

解析成功：说明该节点属于目标协调集，Set Coordinator与该节点建立连接、配对，并读取其SIRK值，验证是否与目标SIRK一致；
解析失败：说明该节点不属于目标协调集，直接忽略；

6. 更新定时器 ：每成功发现一个成员节点，Set Coordinator重置超时定时器，确保有足够的时间找到所有节点；

7. 判断是否完成：Set Coordinator根据Coordinated Set Size特征值，判断是否已经找到所有成员节点，找到则停止扫描。

5.2.3 流程完成判定

成员节点发现流程的完成判定是多条件触发，满足以下任意一种情况，流程即完成，这是协议设计的灵活性体现：

所有成员节点被发现：Set Coordinator找到的成员节点数量等于Coordinated Set Size特征值，停止扫描，流程正常完成；
超时定时器过期：T_CSIP(set_member_discovery_timeout)定时器过期，无论是否找到所有成员，流程终止；
应用层终止：上层应用主动发送终止指令，流程立即终止。

流程完成后，Set Coordinator需要向上层应用返回已发现的成员节点信息，包括节点地址、秩次、锁状态等，为后续的控制操作做准备。

5.2.4 交互设计与实操考量

成员节点发现流程的设计需要重点关注扫描效率 和鲁棒性，实际开发中需要注意以下几点：

关闭重复过滤：Set Member可能广播多个广播集，关闭重复广播报告过滤是避免遗漏成员节点的关键，这是协议明确要求的；

定时器的合理配置：协议建议定时器为10秒，在实际开发中可以根据应用场景调整，比如短距离的TWS耳机可以设置为5秒，长距离的音箱组可以设置为15秒；

RSI解析的实时性：RSI解析是CPU密集型操作，需要保证解析的实时性，避免因解析延迟导致遗漏广播包；

配对后的SIRK验证：与节点建立连接后，必须验证其SIRK值是否与目标SIRK一致，防止因RSI解析错误导致连接错误的节点；

断连节点的处理：如果发现某个成员节点处于断连状态，建议将其标记为"离线"，并在后续流程中跳过，避免影响整体操作。

5.3 锁申请与锁释放流程：实现协调集的排他控制权

锁申请流程和锁释放流程是成对出现 的，是Set Coordinator实现协调集排他访问 的核心流程，相当于指挥中心获取集群的唯一控制权，防止其他指挥中心同时操作，导致控制混乱。这两个流程仅当Set Coordinator支持Bondable mode时才会实现，是协议的高级功能，也是高端设备的核心能力之一。

5.3.1 核心交互时序

协议中给出了锁申请和锁释放流程的典型交互时序，涉及两个Set Coordinator（SC1、SC2）和两个Set Member（SM1、SM2），核心交互如下：

SC1向SM1发送Write Request（Lock=Locked），SM1返回Write Response，锁申请成功；

SC1向SM2发送Write Request（Lock=Locked），SM2返回Write Response，锁申请成功，SC1获取协调集的排他控制权；

SC1执行后续的控制操作（如音量调节、音频流分发）；

SC2向SM1发送Write Request（Lock=Locked），SM1返回Error Response（Lock Denied），锁申请失败；

SC2向SM1的Lock特征CCCD描述符发送Write Request（0x01），开启锁状态通知，等待锁释放；

SC1完成控制操作后，向SM2发送Write Request（Lock=Unlocked），SM2返回Write Response；

SC1向SM1发送Write Request（Lock=Unlocked），SM1返回Write Response，锁释放成功；

SM1向SC2发送Notification（Lock=Unlocked），通知SC2锁已释放，SC2可以重新申请锁。

这一时序图覆盖了锁申请、锁竞争、锁释放、状态通知的全场景，是实际开发中最典型的交互逻辑，所有Set Coordinator都需要遵循这一交互规范。

5.3.2 锁申请流程：获取排他控制权

锁申请流程的核心目标是将协调集中目标节点的Lock特征设置为Locked状态，获取排他控制权，协议对操作顺序、异常处理、重试机制做出了严格要求。

1. 流程触发条件 ：Set Coordinator成功发现协调集的所有成员节点，且需要执行排他性的控制操作（如TWS耳机的配对、音箱组的模式切换），由上层应用触发；

2. 操作顺序要求 ：Set Coordinator必须按照Set Member Rank秩次从小到大的顺序，向目标节点发送锁申请请求，即先向秩次0x01的节点申请，再向秩次0x02的节点申请，以此类推；协议建议将秩次0x01分配给协调集中最核心的节点，确保核心节点优先被控制；

3. 目标节点范围 ：Set Coordinator可以向所有成员节点 或部分成员节点申请锁，具体由上层协议定义，比如部分节点离线时，可仅向在线节点申请；

4. 成功判定：所有目标节点都返回Write Response，说明锁申请成功，Set Coordinator获取排他控制权；

5. 失败判定与异常处理 ：如果任意一个目标节点返回Error Response（Lock Denied或Lock Already Granted），锁申请失败，此时Set Coordinator需要执行两个核心操作：

立即停止向剩余节点发送锁申请请求，避免不必要的通信；
对已经成功申请到锁的节点，立即执行锁释放流程，将其Lock特征恢复为Unlocked状态，保证数据一致性；

6. 重试机制 ：锁申请失败后，Set Coordinator可以注册目标节点的Lock特征通知，当节点的Lock状态变为Unlocked时，自动重新触发锁申请流程；也可以在等待一段实现定义的时间后，手动重试。

5.3.3 锁释放流程：归还排他控制权

锁释放流程的核心目标是将协调集中所有节点的Lock特征恢复为Unlocked状态 ，归还排他控制权，让其他Set Coordinator可以申请锁。该流程仅当Set Coordinator已成功获取排他控制权时才能触发，是锁申请流程的逆流程。

流程触发条件 ：Set Coordinator完成排他性的控制操作，由上层应用触发；或锁申请失败后，为已申请成功的节点触发；

操作顺序要求 ：与锁申请流程相反，Set Coordinator必须按照Set Member Rank秩次从大到小的顺序，向所有节点发送锁释放请求，即先向秩次最高的节点释放，再向秩次次高的节点释放，以此类推；这一设计是为了保证核心节点（秩次0x01）最后被释放，确保控制操作的完整性；

成功判定：所有节点都返回Write Response，说明锁释放成功，协调集恢复为空闲状态；

异常处理 ：如果某个节点返回错误响应，Set Coordinator需要继续向剩余节点发送锁释放请求，并记录错误信息，向上层应用返回，确保尽可能多的节点释放锁，减少协调集的异常状态。

5.3.4 实操设计考量

锁申请和释放流程是Set Coordinator中最复杂的流程之一 ，实际开发中需要重点关注数据一致性 和异常处理，具体如下：

操作顺序的严格遵循：必须按照秩次的大小顺序执行申请和释放操作，这是协议的强制要求，也是保证多设备协同的关键；
锁状态的实时同步：建议开启Lock特征的通知功能，实时同步节点的锁状态，避免因通信中断导致的锁状态不一致；
超时处理：向节点发送Write Request后，需要设置超时定时器，避免因节点离线导致流程卡死；
资源释放：获取排他控制权后，如果Set Coordinator与节点的连接中断，建议在重连后验证锁状态，若连接无法恢复，应主动释放锁；
多协调集的锁隔离：如果Set Member属于多个协调集，其不同CSIS的Lock特征是相互独立的，Set Coordinator需要保证锁操作的隔离性，避免操作错误的协调集锁。

5.4 有序访问流程：无绑定模式下的竞争缓解方案

有序访问流程是锁申请/释放流程的替代方案 ，当Set Coordinator不支持Bondable mode，或与Set Member未建立绑定关系时，无法执行锁申请/释放流程，此时通过有序访问流程降低多客户端竞争的概率 ，实现协调集的基础有序控制。这一流程是协议的保底方案，确保所有Set Coordinator都能实现基础的协同控制。

5.4.1 流程触发条件

Set Coordinator不支持Bondable mode ，或与Set Member未建立绑定关系，且需要执行协调集的控制操作（如音量调节、播放暂停），由上层应用触发。

5.4.2 核心操作步骤

有序访问流程的核心是先检查锁状态，再执行控制操作，通过标准化的操作顺序降低竞争概率，具体步骤如下：

1. 定义目标操作：Set Coordinator定义需要执行的控制操作（Procedure_A），如向所有成员节点写入音量值；

2. 检查锁状态 ：Set Coordinator按照Set Member Rank秩次从小到大的顺序，读取所有目标节点的Lock特征值；

3. 判断锁状态：

存在任意一个节点的Lock状态为Locked：说明当前有其他Set Coordinator在操作，流程暂停，Set Coordinator可以注册该节点的Lock特征通知，当状态变为Unlocked时，重新触发流程；
所有节点的Lock状态为Unlocked：说明协调集处于空闲状态，继续执行后续步骤；

4. 执行控制操作 ：Set Coordinator按照Set Member Rank秩次从小到大的顺序，向所有目标节点执行Procedure_A，完成控制操作；

5. 流程完成：所有节点都成功执行Procedure_A，流程完成，向上层应用返回成功信息。

5.4.3 核心设计价值与实操考量

有序访问流程的设计并非实现严格的排他访问，而是通过先检查后执行的标准化步骤，最大限度地降低多客户端竞争的概率，其核心价值是为无绑定模式的设备提供基础的有序控制能力。实际开发中需要注意以下几点：

操作顺序的严格遵循：必须按照秩次从小到大的顺序检查锁状态和执行控制操作，这是降低竞争的关键；

无锁状态的非绝对性：由于检查锁状态和执行控制操作之间存在时间窗口，可能出现"检查时为Unlocked，执行时已被其他Coordinator锁定"的情况，开发中需要增加异常处理机制；

轻量操作优先：有序访问流程适合执行轻量的控制操作（如音量调节、播放暂停），不适合执行复杂的、耗时的操作（如配对、模式切换），复杂操作建议在支持Bondable mode的设备上执行；

重试机制：如果执行控制操作时出现错误，建议增加重试机制，提升流程的鲁棒性。

5.5 读取协调集名称流程：提升用户体验的锦上添花

读取协调集名称流程是体验类的可选流程 ，核心目标是获取协调集的人类可读名称，让Set Coordinator可以将协调集作为一个整体展示给用户（如"我的TWS耳机"），而非单独展示每个成员节点（如"我的TWS耳机-左""我的TWS耳机-右"），提升用户的设备管理体验。

5.5.1 流程触发条件

Set Coordinator支持Coordinated Set Name特征，且成功发现协调集的成员节点后，由上层应用触发（如用户打开设备管理界面时）。

5.5.2 核心操作步骤

读取协调集名称流程的步骤较为简单，协议对其长特征值处理做出了明确要求，具体如下：

选择读取节点 ：由于协调集中所有成员节点的Coordinated Set Name特征值完全一致，Set Coordinator只需选择任意一个节点读取即可，建议选择秩次0x01的核心节点；
读取特征值：Set Coordinator读取Coordinated Set Name特征值；
长特征值处理 ：如果特征值长度超过（ATT_MTU-3）个字节，Set Coordinator通过读取长特征值子过程，分段读取并拼接，获取完整的名称信息；
名称同步：Set Coordinator将获取的协调集名称同步到所有成员节点的展示信息中，实现统一展示。

5.5.3 实操设计考量

读取协调集名称流程是简单的体验类流程，实际开发中需要注意两个关键点：

仅读取一次即可：所有成员节点的名称特征值一致，无需重复读取，避免不必要的通信，提升效率；
长特征值的拼接：必须正确处理长特征值的分段读取和拼接，确保名称的完整性，避免出现乱码或截断；
名称更新的实时性：如果开启了Coordinated Set Name特征的通知功能，当名称发生变化时，Set Coordinator需要及时更新展示信息，保证用户体验的一致性。

六、Set Coordinator的实操设计考量：从协议到落地

通过前面的解析，我们已经掌握了Set Coordinator的能力要求和核心流程，但协议只是给出了标准化的要求和规范 ，实际开发中还需要结合硬件资源、应用场景、传输方式等因素做落地设计，这也是从懂协议到能开发的关键。

6.1 秩次（Set Member Rank）的设计：定义协调集的操作优先级

Set Member Rank是协调集成员节点的操作优先级标识 ，协议规定了操作顺序必须基于秩次，因此秩次的设计直接影响Set Coordinator的操作效率和协同效果，实际设计中需要遵循核心节点优先的原则：

核心节点分配秩次0x01：将协调集中最核心、最稳定的节点分配为秩次0x01，比如TWS耳机的主耳机、音箱组的主音箱，确保核心节点优先被控制，提升操作的稳定性；
秩次的连续性：协调集的秩次建议按连续的数字分配（0x01、0x02、0x03......），避免跳号，方便Set Coordinator遍历和排序；
秩次的唯一性：同一协调集中的每个节点的秩次必须唯一，避免出现秩次冲突，导致Set Coordinator的操作顺序混乱；
多协调集的秩次独立：如果Set Member属于多个协调集，其不同CSIS的Set Member Rank可以独立分配，无需保持一致，适应不同协调集的业务需求。

6.2 定时器的配置：平衡效率与鲁棒性

Set Coordinator的多个流程都涉及定时器（如成员节点发现的T_CSIP(set_member_discovery_timeout)、GATT写入的超时定时器），定时器的配置需要在效率和鲁棒性之间找到平衡，避免因定时器过短导致流程失败，或因定时器过长导致操作延迟：

遵循协议建议值：协议建议成员节点发现的定时器为10秒，开发中可以以此为基准，根据应用场景微调；
短距离场景调短定时器：对于短距离、小范围的协调集（如TWS耳机、近距离传感器），可以将定时器调短至5-8秒，提升发现效率；
长距离场景调长定时器：对于长距离、大范围的协调集（如全屋音箱组、室外传感器），可以将定时器调长至15-20秒，提升鲁棒性，避免遗漏节点；
GATT操作的定时器配置：GATT写入/读取的超时定时器建议设置为1-3秒，既可以避免因通信干扰导致的流程卡死，又不会影响操作的实时性。

6.3 多协调集的处理：实现隔离与高效管理

部分Set Member可能属于多个协调集，此时会实例化多个CSIS，Set Coordinator需要实现多协调集的隔离与高效管理，避免操作混乱：

CSIS实例的唯一标识：为每个CSIS实例分配唯一的标识（如结合上层服务的UUID），让Set Coordinator可以快速区分不同的协调集；
独立的状态管理：为每个协调集维护独立的状态信息（SIRK、成员节点、锁状态、名称），实现状态的隔离管理，避免相互干扰；
批量操作的支持：支持对多个协调集的批量操作（如批量扫描、批量发现），提升多协调集管理的效率；
用户层面的区分：在用户界面中，将不同的协调集进行明确区分，让用户可以直观地选择目标协调集，避免误操作。

6.4 跨传输适配：兼顾LE和BR/EDR的特性

CSIP协议支持LE和BR/EDR两种传输方式，Set Coordinator的设计需要兼顾两种传输方式的特性，实现跨传输的适配和互通：

扫描方式的适配：LE传输下扫描广播PDU，BR/EDR传输下执行设备发现流程，分别遵循两种传输方式的GAP规范；
MTU的适配 ：LE传输的默认ATT_MTU较小（23字节），BR/EDR传输的MTU较大，Set Coordinator需要支持MTU交换，提升长特征值（如协调集名称）的传输效率；
安全机制的适配：LE传输使用SM1安全模式，BR/EDR传输使用SM4安全模式，Set Coordinator需要分别遵循两种传输方式的安全要求，实现加密通信；
连接管理的适配：LE传输的连接功耗较低，BR/EDR传输的连接带宽较高，Set Coordinator可以根据协调集的业务需求（如音频传输、传感器采集），选择合适的传输方式。

6.5 安全与隐私：守护协调集的通信安全

Set Coordinator作为协调集的控制方，掌握着协调集的核心标识（SIRK）和成员节点信息，其安全与隐私设计直接关系到整个协调集的通信安全，开发中需要重点关注以下几点：

SIRK的安全存储：SIRK是协调集的核心标识，尤其是加密的SIRK，需要存储在设备的安全存储区域（如安全芯片、加密闪存），避免泄露；
加密通信的强制开启：与Set Member的通信必须开启加密，遵循协议的安全要求（LE传输为SM1 Level 2及以上，BR/EDR传输为SM4 Level 2），防止数据被窃听和篡改；
RSI的解析权限控制：仅允许授权的Set Coordinator解析RSI，避免未授权设备识别协调集成员节点；
绑定关系的管理：支持Bondable mode的设备，需要实现绑定关系的管理（如删除绑定、重连绑定），让用户可以控制设备的授权范围；
隐私地址的支持：支持蓝牙的隐私地址功能，定期更新设备的地址，避免被跟踪和定位。

七、测试

问题：请简述Set Coordinator执行协调集发现流程的核心步骤及流程失败的判定条件？

答案：

1. 核心步骤：

（1）定位目标CSIS：若Set Member有多个CSIS，通过查找包含服务子过程确定目标协调集的CSIS实例；

（2）读取SIRK特征值：读取Set Identity Resolving Key特征值，获取Type和Value字段；

（3）解析SIRK：Type=0x00时调用SIRK解密函数解析加密SIRK，Type=0x01时直接获取明文SIRK；

（4）读取附加特征：读取Set Member Rank和Coordinated Set Size特征值（Set Member暴露时）；

（5）可选OOB补充：通过NFC、二维码等OOB方式获取SIRK和协调集大小。

2. 失败判定条件：

出现以下任意一种情况，流程失败：

（1）无法通过GATT读取或OOB方式获取SIRK值；

（2）无法读取Set Member暴露的Set Member Rank特征值；

（3）无法读取Set Member暴露的Coordinated Set Size特征值。

问题：Set Coordinator执行锁申请流程时收到某Set Member的Lock Denied错误响应，应如何处理？请说明具体的操作步骤？

答案：

当收到Lock Denied错误响应时，锁申请流程立即失败，Set Coordinator需按以下步骤处理：

停止后续申请：立即停止向剩余的Set Member发送锁申请的Write Request，避免不必要的通信交互；
释放已获取的锁：对已经成功申请到锁的Set Member，立即执行锁释放流程，将其Lock特征值恢复为Unlocked，保证协调集的锁状态一致性；
注册锁状态通知：向返回Lock Denied的Set Member注册Lock特征的通知功能，开启CCCD描述符，实时感知其锁状态变化；
触发重试机制：当该Set Member的Lock状态变为Unlocked时，自动重新触发锁申请流程；或等待实现定义的时间后，手动重试；
上报错误信息：将锁申请失败的原因、涉及的Set Member信息向上层应用上报，由应用层进行后续的用户提示。

问题：Ordered Access（有序访问）流程的适用场景是什么？请简述其核心执行步骤？

答案：

1. 适用场景 ：有序访问流程是锁申请 / 释放流程的替代方案，适用于Set Coordinator 不支持 Bondable mode ，或Set Coordinator 与 Set Member 未建立绑定关系的场景，用于降低多客户端竞争的概率，实现协调集的基础有序控制。该流程适合执行轻量的控制操作（如音量调节、播放暂停、传感器参数微调），不适合复杂的、耗时的协同操作。

2. 核心执行步骤：

（1）定义目标操作：明确需要对协调集执行的控制操作 Procedure_A，确定需要参与操作的 Set Member 列表；

（2）检查锁状态：按照 Set Member Rank 秩次从小到大的顺序，依次读取所有目标节点的 Set Member Lock 特征值；

（3）锁状态判断：若存在任意一个节点的 Lock 特征值为 Locked，立即暂停流程，可注册该节点的锁状态通知，待状态变为 Unlocked 后重新触发流程；若所有节点的 Lock 特征值均为 Unlocked，继续执行后续步骤；

（4）执行目标操作：按照 Set Member Rank 秩次从小到大的顺序，依次向所有目标节点执行 Procedure_A，完成控制指令的下发；

（5）流程收尾：若所有节点均成功执行 Procedure_A，判定流程完成，向上层应用返回成功信息；若某个节点执行失败，立即终止后续操作，上报错误并提供重试选项。