在LE Audio的生态中，双耳耳机、助听器、多声道音箱这类需要协同工作的设备早已成为主流，而CSIP作为实现设备协同识别的核心协议，是所有协同场景落地的基础。如果把一个协同工作的设备组比作一支球队，那Set Member就是球队里的每一位队员，是协同集的最小组成单元，所有的协同识别、组管理能力，都依赖Set Member的规范实现。
目录
[一、Set Member的核心定位：CSIP架构中的身份载体](#一、Set Member的核心定位：CSIP架构中的身份载体)
[二、CSIS实例部署规则：Set Member实现的底层基础](#二、CSIS实例部署规则：Set Member实现的底层基础)
[三、增量式CSIS特征实现：Set Member的核心能力](#三、增量式CSIS特征实现：Set Member的核心能力)
[3.1 RSI AD Type：协同集的广播身份码](#3.1 RSI AD Type：协同集的广播身份码)
[3.2 SIRK：协同集的唯一识别密钥](#3.2 SIRK：协同集的唯一识别密钥)
[3.3 Coordinated Set Size：协同集的成员数量标识](#3.3 Coordinated Set Size：协同集的成员数量标识)
[3.4 Service Data：协同集的附加身份信息卡](#3.4 Service Data：协同集的附加身份信息卡)
[3.5 Coordinated Set Name：协同集的人性化名称](#3.5 Coordinated Set Name：协同集的人性化名称)
[四、Set Member实现的核心原则与避坑点](#四、Set Member实现的核心原则与避坑点)
本文从设备开发的视角，拆解作为Set Member需要满足的核心要求、实现要点和设计逻辑，让大家能真正理解协议背后的设计思路，而非单纯的规则记忆。
一、Set Member的核心定位：CSIP架构中的身份载体
在CSIP的整体架构中，仅定义了两个核心角色：Set Coordinator和Set Member，前者是协同集的发现者和管理者（GATT客户端），后者是协同集的组成单元（GATT服务器）。一个协同集由一个或多个Set Member组成，而Set Member的核心职责，就是承载CSIS（Coordinated Set Identification Service） 协同集标识服务，这是整个CSIP协议的核心载体。
简单来说，Set Member就是CSIS服务的运行容器，所有用于协同集识别的关键信息，都以CSIS特征的形式存在于Set Member中，Set Coordinator通过读写这些特征，完成对协同集的发现、识别和管理。这也是为什么Set Member的所有实现要求，都围绕CSIS服务的实例化和特征实现展开。
从协议设计来看，Set Member的实现无并发限制，也无强制的传输层依赖，可基于LE或BR/EDR实现，仅需根据传输层满足对应的拓扑要求即可，这也让CSIP能适配不同的LE Audio设备场景。
二、CSIS实例部署规则：Set Member实现的底层基础
CSIS作为协同集的标识服务，其实例化规则是Set Member实现的第一要务，协议对这部分做了明确的强制要求，核心围绕单协同集单实例展开，共四条核心规则，缺一不可，也是开发中最容易踩坑的点。
一一对应原则：设备为每个所属的协同集实例化一个CSIS，协议中用shall定义了强制要求：A Set Member shall instantiate one CSIS for each Coordinated Set that the Set Member is a member of。这一设计的初衷是保证每个协同集的身份独立，若多个协同集共用一个CSIS，会导致Set Coordinator无法区分设备所属的协同集，直接失去标识的意义。比如一台智能音箱同时属于客厅多音箱协同集和全屋智能控制协同集，就需要实例化两个CSIS。
多实例隔离原则：若设备包含多个CSIS实例，每个实例必须由不同的上层服务包含，上层服务为协同集提供业务上下文。比如上述智能音箱，音频相关的CSIS由音频服务包含，控制相关的CSIS由设备控制服务包含，这样Set Coordinator就能通过服务UUID区分协同集的业务类型。
单服务 单实例 原则：一个上层服务只能包含一个CSIS实例，避免单个业务服务关联多个协同集，导致业务逻辑和身份识别的混乱，这是协议对服务层的强制约束。
单实例 简化原则：若设备仅属于一个协同集，仅有一个CSIS实例，建议不将其纳入其他服务，直接由Set Member承载，减少层级，提升Set Coordinator的发现效率。
以上四条规则，是Set Member实现的基础，也是协议的强制要求，任何一条的违背都会导致设备无法被Set Coordinator正常识别，失去协同能力。
三、增量式CSIS特征实现：Set Member的核心能力
在CSIS基础规范之上，协议对Set Member提出了增量式的特征实现要求，这部分是协同集识别的核心，也是Set Member需要落地的具体能力。这些特征就像队员身份牌上的关键信息，包含了协同集的唯一标识、成员数量、名称等，缺一不可，我们逐一拆解核心特征的实现要求和设计逻辑。
3.1 RSI AD Type：协同集的广播身份码
RSI AD Type是Set Member在未建立连接时，对外广播的协同集身份标识，是Set Coordinator发现协同集的第一道门。协议对其部署做了分传输层的强制要求：
LE传输下，设备处于Bondable模式时，GAP外设角色的Set Member必须在可连接广播数据中包含RSI AD Type；
BR/EDR传输下，GAP B-party角色的Set Member必须在扩展查询响应数据中包含RSI AD Type。
若设备属于多个协同集，可广播多个RSI AD Type（一个协同集对应一个），实现方式自定义，比如通过多广播集、单广播集包含多个等，协议不做强制约束，仅要求标识的完整性。
这一特征的设计核心，是让Set Coordinator在未与设备建立GATT连接时，就能快速发现设备所属的协同集，提升协同集的发现效率，避免无意义的连接尝试。
3.2 SIRK：协同集的唯一识别密钥
Set Identity Resolving Key（SIRK）是协同集的核心唯一标识，相当于球队的队徽密钥，是Set Coordinator识别设备是否属于目标协同集的核心依据。
协议对SIRK的实现有一个强制要求：
If a Set Member instantiates more than one instance of CSIS, the Set Member shall assign different values of the SIRK to each instance
即多CSIS实例必须分配不同的SIRK值。Set Coordinator会通过SIRK解析RSI AD Type中的广播信息，若解析匹配，则判定设备属于目标协同集；若不匹配，则直接忽略。
如果多个CSIS实例复用SIRK，会导致Set Coordinator将不同的协同集判定为同一个，引发协同逻辑的混乱，比如将客厅音箱和卧室音箱错误归为同一集，这也是开发中需要重点规避的点。
3.3 Coordinated Set Size：协同集的成员数量标识
该特征用于标识协同集的设备数量，协议要求：同一协同集的所有Set Member，其对应的CSIS实例的该特征值必须完全一致。比如双耳耳机的Set Size值为2，四声道音箱的Set Size值为4，单设备协同集的Set Size值为1。
Set Coordinator通过该特征值，能明确知道需要发现多少个Set Member才能完成协同集的组建，若发现的设备数量与Set Size值不符，会触发重新发现流程。这一特征是协同集组完整性的核心保障。
3.4 Service Data：协同集的附加身份信息卡
Service Data是对协同集身份信息的补充，主要承载两部分内容：协同集名称和关联服务的UUID，相当于在队员身份牌上增加了球队昵称和球队所属联赛的信息。
协议对其部署为建议要求（should）：LE传输下设备处于可发现模式、BR/EDR传输下，Set Member建议在广播/查询响应数据中包含Service Data；若为多协同集，每个协同集对应一个Service Data实例。
这一特征的设计，让Set Coordinator不仅能识别协同集，还能提前获取协同集的业务类型和名称，提升交互的精准性，比如直接在UI中展示客厅多音箱集，而非单纯的设备列表。
3.5 Coordinated Set Name：协同集的人性化名称
该特征是协同集的可视化名称，可区别于蓝牙设备名，协议要求：
When supported, the Coordinated Set Name characteristic shall expose the same value on all members of the same Coordinated Set as identified by CSIS instances that have been assigned the same SIRK value
即同一协同集的所有Set Member，该特征值必须一致。
比如双耳耳机的两个设备，其蓝牙设备名可能为Left Earbud和Right Earbud，但Coordinated Set Name可统一为我的无线耳机，这样Set Coordinator的UI会将其展示为一个整体，而非两个独立设备，极大提升用户体验。
该特征为可选实现，但一旦实现，一致性是核心要求，若同一协同集的设备名称不一致，会直接破坏用户的协同体验。
四、Set Member实现的核心原则与避坑点
结合上述的实现要求，我们可以总结出Set Member实现的三大核心原则，也是协议设计的底层逻辑，掌握这些原则，能避免大部分开发中的坑：
强制要求必落地：协议中用shall定义的要求，比如CSIS实例的一一对应、SIRK的唯一性、RSI AD Type的传输层部署，是设备兼容CSIP的基础，不落地会直接导致设备无法被识别；
特征值全局一致：同一协同集的所有Set Member，其SIRK、Set Size、Set Name等核心特征值必须完全一致，这是协同集识别和组管理的核心保障；
多实例业务隔离：多CSIS实例必须通过不同的上层服务实现业务隔离，让Set Coordinator能通过服务UUID区分协同集的业务类型，避免逻辑混乱。
而开发中最容易踩的坑主要有三个：单个服务包含多个CSIS实例 、多协同集场景复用SIRK值 、忽略LE Bondable模式下RSI AD Type的广播要求，这三个点也是协议测试中的重点检测项。
五、总结
Set Member作为CSIP协议的设备端载体，其实现的核心就是围绕CSIS服务的实例化 和特征实现 展开，协议的所有要求，最终都是为了保证协同集识别的唯一性 、完整性 和高效性。
对于LE Audio设备开发来说，掌握Set Member的实现要求，是开发协同设备的基础，而后续Set Coordinator与Set Member的交互流程，比如协同集发现、成员发现、独占访问控制等，都是基于这些基础特征展开的。下一篇我们将聚焦Set Coordinator的核心要求，拆解管理端如何发现、识别和管理协同集。
六、测试
问题：Set Member在多Coordinated Set场景下的CSIS实例部署有哪些核心规则？
答案：
核心规则有四条：
1 一个协同集对应一个CSIS实例，强制实例化；
2 多CSIS实例需由不同的上层服务包含，实现业务隔离；
3 一个上层服务只能包含一个CSIS实例，避免逻辑混乱；
4 若为单CSIS实例，建议不纳入其他服务，直接由Set Member承载。
问题：简述Set Member中SIRK特征的核心要求及设计初衷？
答案：
核心要求：单CSIS实例无特殊要求，多CSIS实例必须为每个实例分配不同的SIRK值，保证唯一性。设计初衷：SIRK是协同集的唯一识别密钥，Set Coordinator通过SIRK解析RSI广播信息，判定设备是否属于目标协同集，唯一性是避免协同集识别混乱的核心保障。
问题：LE传输下，Set Member在Bondable模式下对RSI AD Type的部署要求是什么？
答案：
LE传输下，设备处于Bondable模式且为GAP外设角色时，Set Member必须在可连接广播数据中包含RSI AD Type；若设备属于多个协同集，可广播多个RSI AD Type（一个协同集对应一个），实现方式自定义。