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

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

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

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

[2.1 RSI的核心规范要求](#2.1 RSI的核心规范要求)

[2.2 RSI的格式设计](#2.2 RSI的格式设计)

[2.3 RSI的动态性与隐私保护](#2.3 RSI的动态性与隐私保护)

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

[3.1 Service Data的核心规范要求](#3.1 Service Data的核心规范要求)

[3.2 Service Data的完整格式拆解](#3.2 Service Data的完整格式拆解)

[3.3 Service Data的扩展性设计](#3.3 Service Data的扩展性设计)

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

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

[5.1 示例1：Amy's Earbuds（16bit UUID场景，通用音频服务）](#5.1 示例1：Amy’s Earbuds（16bit UUID场景，通用音频服务）)

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

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

七、测试

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

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

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

传统的蓝牙低功耗广播，核心只解决了设备自身被发现的问题，广播数据里的设备地址、设备名称、服务UUID等信息，都是针对单个设备的。但在LE Audio的多设备场景下，比如一副TWS耳机的左右耳、一套5.1声道的蓝牙音箱，客户端需要的不是识别单个设备，而是识别哪些设备属于同一个集合，并且要保证这个识别过程满足两个要求：兼容性 （不同厂商的设备能互相识别）、隐私性（不会因为固定标识被恶意追踪）。

CSIS的广播数据类型就是为了解决这个核心问题而生，它基于蓝牙核心规范的AD Type和Service Data体系进行扩展，没有脱离现有蓝牙广播框架，保证了兼容性；同时通过动态生成的RSI 解决隐私问题，通过标准化的Service Data解决集合信息传递的问题。

简单来说，CSIS广播数据的设计目标就两个：一是让客户端能精准判断哪些设备是一伙的，二是让客户端能获取到这个设备集合的基础信息和关联服务，为后续的协调控制做铺垫。

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

RSI是CSIS广播数据的第一个核心，也是实现协调集机器识别的关键。它的核心特性是动态生成、基于SIRK可解析，既保证了同一个协调集的设备能被客户端精准识别，又避免了因固定标识导致的设备追踪问题。

2.1 RSI的核心规范要求

规范中对RSI的定位有明确的硬性要求：

An RSI identifies the advertising device as belonging to a Coordinated Set. An RSI shall be generated by using the Resolvable Set Identifier generation operation and shall be resolved by using the Resolvable Set Identifier resolution operation.

这句话拆解下来有两个核心点：第一，RSI的唯一作用是标识广播设备属于某个特定的协调集，是协调集的设备组标识，而非单个设备的标识；第二，RSI的生成和解析必须严格遵循规范定义的操作流程，不能自定义实现，这是保证跨厂商设备兼容性的基础------所有符合CSIS规范的设备，都能通过同一套规则生成和解析RSI。

2.2 RSI的格式设计

RSI作为一个独立的AD Type，其格式在规范中定义得非常简洁，整体结构如下表所示，核心只有一个6字节的RSI值，这也是RSI AD Type的全部有效载荷。

|---------------------------|---------|-----------------------------------|
| 字段 | 字节数 | 说明 |
| AD Type标识 | 1 | 蓝牙分配的专属标识（见蓝牙分配号） |
| Resolvable Set Identifier | 6 | 核心RSI值，由24bit hash +24bit prand组成 |

6字节的RSI值并非随机生成，而是由协调集的共享密钥SIRK、24位随机数prand通过规范的哈希和拼接操作生成，这也是RSI能实现同组可解析、异组不可解析的核心原因。同一个协调集的所有设备共享同一个128位的SIRK，因此能基于相同的规则生成RSI，而客户端只要获取到这个SIRK，就能解析出同组设备的RSI，确认设备归属。

2.3 RSI的动态性与隐私保护

RSI的另一个核心设计是动态生成，设备每次广播都可以生成新的RSI值，而不是使用固定值。这一设计的核心目的是保护设备隐私------如果使用固定的集合标识，恶意设备可以通过追踪这个标识来获取设备的使用轨迹，而动态RSI会频繁变化，且只有持有对应SIRK的合法客户端能解析其归属，从根本上避免了追踪问题。

这里需要注意，RSI的动态性依赖于prand的随机性，规范中对prand也有明确的要求：最高两位必须为0和1，且随机部分至少有一个0和一个1，目的是避免生成无效的RSI值，保证客户端解析的成功率。

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

如果说RSI是给机器看的动态标识，那Service Data就是给人机交互和服务关联用的结构化名片。它的核心作用是传递协调集的人类可读信息 和服务关联信息，让客户端不仅能识别出设备组，还能知道这个设备组的名称、对应的核心服务，为后续的用户交互和功能调用做铺垫。

3.1 Service Data的核心规范要求

规范中对Service Data的定位同样有明确说明：

The Service Data exposes both the human-readable name of a Coordinated Set instance that the advertising device is a member of and the UUIDs of services that include this instance of CSIS.

这句话明确了Service Data的两个核心承载内容：一是协调集的人类可读名称，比如TWS耳机的"XX品牌降噪耳机"，这个名称会展示给用户，提升交互体验；二是包含该CSIS实例的所有服务UUID，比如通用音频服务0x1853，客户端通过这些UUID可以直接加载对应的服务逻辑，无需额外的服务发现步骤。

同时规范还有两个强制一致性要求：第一，Service Data中列出的UUID必须是所有包含该CSIS实例的服务UUID，不能遗漏；第二，Service Data中的协调集名称必须和CSIS的Coordinated Set Name特征值完全一致，避免客户端出现信息解析冲突。

3.2 Service Data的完整格式拆解

CSIS的Service Data基于蓝牙标准的0x16类型（Service Data -- 16-bit UUID）设计，整体格式如上图所示，字段层级清晰，且做了极致的字节优化，适配蓝牙广播包的字节限制。

|------------------------------|---------|--------------------------------|
| 字段 | 字节数 | 说明 |
| Length | 1 | 后续Type+Value的总字节数 |
| Type | 1 | 固定0x16，蓝牙标准Service Data标识 |
| Value | 可变 | 核心数据段，包含以下所有字段 |
| CSIS UUID | 2 | 固定0x1846，CSIS服务专属UUID |
| Coordinated Set Associations | 1 | 位域，标识后续UUID的类型和数量 |
| 各类UUID列表 | 可变 | 16bit/32bit/128bit UUID，数量对应位域 |
| Name Length | 1 | 协调集名称的字节数，0表示无名称 |
| Coordinated Set Name | 0-128 | UTF-8编码的协调集名称，非0时存在 |

这里重点讲两个设计巧思满满的字段，也是开发中最需要注意的点：

（1）Coordinated Set Associations：1字节实现多类型UUID数量标识

这个字段是一个8位的位域，把1字节的空间利用到了极致，具体位分配为：

0-1位：表示后续16bit UUID的数量，取值0-3（2位最大表示3）

2-3位：表示后续32bit UUID的数量，取值0-3

4-5位：表示后续128bit UUID的数量，取值0-3

6-7位：RFU（保留未来使用），必须设为0，接收方直接忽略

蓝牙广播包的有效载荷字节数非常有限，这个设计用1字节就实现了三种UUID类型的数量标识，避免了额外的字节开销，是蓝牙规范设计中典型的字节优化思路。开发中需要注意，位域的设置必须和后续的UUID列表完全匹配，比如位域标识1个16bit UUID，后续就必须跟1个2字节的16bit UUID，否则客户端会解析失败。

（2）Name Length：灵活的名称开关

协调集名称字段设计为可选，通过Name Length字段控制：当Name Length为0时，后续的名称字段不存在，节省字节；当Name Length非0时，后续必须跟对应字节数的UTF-8编码名称。这个设计适配了不同的开发场景------比如工业传感器类的协调集，无需人类可读名称，可直接设为0；而消费电子类的TWS耳机、音箱，需要展示名称，可设置对应的值。

3.3 Service Data的扩展性设计

CSIS的Service Data还支持多协调集场景------如果一个设备同时属于多个协调集，那么可以在广播数据或扫描响应数据中添加多个CSIS Service Data实例，每个实例对应一个协调集的信息。比如一个蓝牙音箱，既属于客厅的多声道音箱集，又属于全屋的智能设备集，就可以通过两个Service Data实例分别标注两个集合的信息，客户端会分别解析，实现设备的多集合归属。

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

RSI和Service Data并非独立工作，而是形成了一套完整的**"扫描-解析-关联"**流程，让客户端能从广播数据中快速完成协调集的识别和信息获取。核心分为三个步骤，适配客户端有SIRK和无SIRK两种场景。

广播扫描：客户端扫描蓝牙广播数据，提取其中的RSI AD Type和CSIS Service Data（基于0x1846 UUID识别）；
RSI解析判断：客户端检查本地是否持有该协调集的SIRK：
1. 若持有SIRK：直接使用规范的RSI解析操作，将广播中的RSI值解析为集合归属，确认设备是否属于目标协调集；
2. 若无SIRK：从Service Data中提取关联的服务UUID（比如0x1853通用音频服务），通过该UUID连接设备，从设备的GATT特征中获取该协调集的SIRK；
协调集完整识别：客户端用获取到的SIRK解析其他设备的RSI，完成整个协调集的所有设备识别；同时从Service Data中提取协调集名称展示给用户，通过关联服务UUID加载对应的服务逻辑，为后续的协调控制（如音量同步、声道分配）做准备。

这套流程的设计非常高效，既保证了识别的精准性，又兼顾了首次识别和后续识别的效率：首次识别时通过Service Data的服务UUID获取SIRK，后续识别时直接通过RSI解析，无需重复连接设备，大幅提升了多设备场景下的识别速度。

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

规范中给出了两个经典的Service Data示例，分别对应16bit UUID和128bit UUID场景，这也是实际开发中最常用的两种场景，通过拆解这两个示例，能更直观地理解CSIS广播数据的字节分配和设计逻辑。

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

该示例是一个TWS耳机场景，协调集关联了蓝牙通用音频服务0x1853（16bit UUID），协调集名称为Amy's Earbuds，具体字段值和字节分配如下：

|------------------------------|---------|---------------|-----------------------|
| 字段 | 字节数 | 取值 | 说明 |
| Length | 1 | 0x14 | 后续Type+Value共20字节 |
| Type | 1 | 0x16 | 蓝牙Service Data标识 |
| CSIS UUID | 2 | 0x1846 | CSIS专属UUID |
| Coordinated Set Associations | 1 | 0x01 | 00000001，1个16bit UUID |
| 16bit UUID列表 | 2 | 0x1853 | 通用音频服务UUID |
| Name Length | 1 | 0x0D | 名称共13字节 |
| Coordinated Set Name | 13 | Amy's Earbuds | UTF-8编码名称 |

我们可以验证一下字节数：1（Type）+2+1+2+1+13=20，和Length字段的0x14（十进制20）完全一致，这也是开发中最需要注意的点------Length字段必须精准计算，否则客户端会直接丢弃该广播数据。

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

该示例是一个自定义服务场景，协调集关联了一个128bit的自定义服务UUID，协调集名称为Björn's Set，同时该设备还属于示例1的协调集，因此会在广播数据中添加两个CSIS Service Data实例，具体字段值如下：

|------------------------------|---------|------------------------------------|------------------------|
| 字段 | 字节数 | 取值 | 说明 |
| Length | 1 | 0x23 | 后续Type+Value共35字节 |
| Type | 1 | 0x16 | 蓝牙Service Data标识 |
| CSIS UUID | 2 | 0x1846 | CSIS专属UUID |
| Coordinated Set Associations | 1 | 0x10 | 00010000，1个128bit UUID |
| 128bit UUID列表 | 16 | 0x42DC30535BBD4761A0C6C5237E572E83 | 自定义服务UUID |
| Name Length | 1 | 0x0C | 名称共12字节 |
| Coordinated Set Name | 12 | Björn's Set | UTF-8编码名称 |

这个示例重点展示了128bit UUID的位域设置和字节分配，同时验证了多协调集场景的实现方式------通过多个Service Data实例分别标注，客户端会独立解析每个实例，实现多集合归属的识别。

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

结合规范要求和实际开发经验，整理了5个最容易踩坑的点，也是实现CSIS广播数据时的核心注意事项，避开这些坑，能大幅提升开发效率和兼容性：

RSI生成必须遵循prand规范：prand的最高两位必须是0和1，且随机部分至少有一个0和一个1，否则生成的RSI无效，客户端无法解析；
Length字段必须精准计算：无论是RSI AD Type还是Service Data，Length字段都必须是后续所有字段的总字节数，这是蓝牙广播的通用要求，也是开发中最容易出错的点；
位域设置必须与UUID列表匹配：Coordinated Set Associations位域的取值必须和后续的UUID列表数量、类型完全一致，比如位域标识1个128bit UUID，后续就必须跟16字节的UUID；
名称采用标准UTF-8编码：协调集名称必须使用UTF-8编码，避免多语言场景下的乱码问题，同时Name Length必须和名称的实际字节数一致；
合理利用广播包空间：蓝牙广播包的有效载荷有限，若无需展示名称，可将Name Length设为0，节省字节；若关联的服务UUID较多，可优先使用16bit UUID，减少字节开销。

七、测试

题目：简述CSIS中RSI的核心作用及生成的关键规范要求

答案：

RSI的核心作用是标识广播设备属于某个特定的CSIS协调集，是实现协调集机器识别的核心，同时通过动态生成实现设备隐私保护。

生成的关键规范要求有：

必须通过规范定义的Resolvable Set Identifier generation operation生成；
由24bit hash +24bit prand组成，共6字节；
prand的最高两位必须为0和1，且随机部分至少有一个0和一个1；
基于协调集共享的128位SIRK通过哈希操作生成，同组设备共享SIRK。

题目：CSIS的Service Data中Coordinated Set Associations位域的结构和含义是什么？开发中需要注意什么？

答案：

该位域为1字节8位，结构为0-1位表示16bit UUID数量、2-3位表示32bit UUID数量、4-5位表示128bit UUID数量、6-7位为RFU保留位。取值均为0-3，RFU位必须设为0。

开发中注意点：

位域取值必须与后续的UUID列表数量、类型完全匹配；
RFU位不可随意设置，必须为0；
若无需某类UUID，对应位域设为0，后续不跟该类UUID。

题目：基于CSIS规范，设计一款TWS耳机的广播数据，说明核心字段的设置逻辑

答案：

TWS耳机为消费电子场景，核心关联蓝牙通用音频服务0x1853（16bit UUID），需展示协调集名称，核心字段设置逻辑：

包含RSI AD Type，6字节RSI值基于共享SIRK生成；
Service Data的Type设为0x16，CSIS UUID设为0x1846；
Coordinated Set Associations设为0x01（1个16bit UUID）；
16bit UUID列表设为0x1853；
Name Length设为实际名称字节数，名称为UTF-8编码的耳机品牌名称；
Length字段精准计算后续Type+Value的总字节数。