【LE Audio】CSIS精讲[3]：协调集广播识别的双核心——RSI与服务数据设计

做LE Audio开发的同学应该都清楚，TWS耳机、多声道音箱、助听器这类多设备协调工作的场景，核心难点之一就是让客户端快速、精准地识别出哪些设备属于同一个协调组。而Coordinated Set Identification Service作为LE Audio中实现多设备协调的核心服务，其广播数据设计就是解决这个问题的第一步。

目录

一、CSIS广播数据的设计初衷：解决多设备的集合识别难题

二、RSI AD Type：协调集的动态唯一标识，核心是可解析、防追踪

2.1 RSI的核心规范要求

2.2 RSI的格式设计

2.3 RSI的动态性与隐私保护

三、Service Data：协调集的结构化信息名片，核心是标准化、可扩展

3.1 Service Data的核心规范要求

3.2 Service Data的完整格式拆解

3.3 Service Data的扩展性设计

四、RSI与Service Data的协同工作逻辑：从广播扫描到协调集完整识别

五、实战示例解析：从规范到实际的广播数据落地

5.1 示例1：Amy’s Earbuds（16bit UUID场景，通用音频服务）

5.2 示例2：Björn’s Set（128bit UUID场景，自定义服务）

六、开发避坑指南：CSIS广播数据实现的5个关键注意点

七、测试

如果把一个协调集比作一支团队，那CSIS定义的广播数据就相当于团队的出行标识——RSI AD Type是团队的动态工牌，保证只有自己人能识别且不会被外人追踪；Service Data则是团队的结构化名片，不仅标注了团队名称，还关联了团队的核心业务范围。这两个核心组件各司其职，又协同工作，构成了CSIS协调集从被发现到被精准识别的基础。

这篇内容会从设计初衷、核心组件、协同逻辑、实战示例四个维度，把CSIS广播数据的设计讲透，同时结合实际开发给出避坑要点，让大家不仅能看懂规范，还能落地到实际开发中。

一、CSIS广播数据的设计初衷：解决多设备的集合识别难题

传统的蓝牙低功耗广播，核心只解决了设备自身被