Every true-wireless earbud solution before BLE Audio used a vendor-proprietary method to coordinate left and right earbuds — often a secondary Bluetooth link between the buds, or a master-slave relay. This meant you could not mix earbuds from two different manufacturers, and interoperability was impossible.

BLE Audio standardises this with the concept of a Coordinated Set. A Coordinated Set is simply a group of two or more BLE devices that need to behave as one unit for a specific purpose. The specification is not limited to audio — it could equally bind a pair of ECG patches or a set of industrial sensors — but the primary driver is the earbud use case.

What coordination actually delivers for earbuds:

• Discovering left + right as members of the same set
• Applying volume and mute simultaneously to both
• Ensuring both switch their audio source at the same time (e.g., phone call interrupts music)
• Locking exclusive access to prevent another device grabbing one earbud mid-stream

CSIPS defines exactly two roles:

The Set Member role is deliberately passive — a device simply states it belongs to a set. All the active work of discovery and bookkeeping belongs to the Set Coordinator.

Every Set Member must include an RSI AD Type in its advertising payload. RSI is a 6-byte pseudo-random value that changes periodically, similar to how Resolvable Private Addresses (RPAs) work at the device address level.

The rotating nature of the RSI prevents passive tracking — a sniffer cannot correlate advertisements across time to deduce that the same earbud is always nearby. Only a device that holds the SIRK (see below) can decode and verify that two different RSI values belong to the same set.

The SIRK is a 128-bit secret key that is common to every member of a Coordinated Set and is burned in at manufacture. It serves two purposes:

1. Set verification — a coordinator reads the SIRK from each candidate device and compares values. Matching SIRKs = same set.
2. RSI decoding — the coordinator uses the SIRK to resolve RSI values, confirming a device belongs to the already-known set even before connecting.

Because the SIRK does not change for the lifetime of the device, there is a natural challenge when replacing a broken earbud: the replacement unit must somehow receive the same SIRK as the surviving earbud. BLE Audio does not specify how to do this — manufacturers must design their own provisioning or pairing ceremony for that scenario.

Once the coordinator has the SIRK and knows the set size, it runs the Set Members Discovery Procedure to find all remaining members. The algorithm works like this:

Important edge cases:

• If discovery times out (typically ~10 seconds), the coordinator can still proceed with whatever members it found — it must keep attempting to find missing members in the background.
• Devices that advertise RSI but have a different SIRK are members of a different Coordinated Set and must be ignored.

Any device that is part of a Coordinated Set and works with CAP must implement all four CSIS characteristics. Below is the full picture:

⚠️ Note: Even though no current CAP procedure actively triggers Set Member Lock or Rank on the coordinator side, both characteristics are mandatory to implement on the Acceptor if you are shipping CAP-compliant products. The Lock is available for application-layer use, and Rank is critical for the Ordered Access procedure.

Set Member Lock allows a coordinator to claim temporary exclusive ownership of a device. Once locked, other coordinators cannot run procedures on that Acceptor. When the coordinator finishes its work, it must release the Lock promptly.

Why Rank exists — the race condition problem: Imagine two phones simultaneously trying to lock the same pair of earbuds. Phone A locks the left earbud, Phone B locks the right earbud. Now both phones are stuck — Phone A cannot get the right earbud, Phone B cannot get the left. This is a classic distributed systems deadlock.

The Ordered Access Procedure prevents this by mandating that all coordinators acquire Locks in strictly ascending Rank order:

CAP uses the Ordered Access procedure as a mandatory precursor to all its own procedures whenever a Coordinated Set is involved. It checks for existing locks, and only after confirming all members are free does it proceed — applying the procedure to each member in ascending Rank order.

CAP formally defines the three roles used throughout BLE Audio:

The Commander role is what makes broadcast audio genuinely powerful. Without it, a broadcast source just transmits and any device passively tunes in. With a Commander, a phone can actively direct which earbuds should connect to which broadcast source, coordinate their scanning behaviour, and manage the whole experience.

CAP specifies exactly which GAF components are mandatory (M), optional (O), conditional (C), or excluded (X) for each role. The table below is a simplified view of the most important entries:

Conditional means: if you implement feature A, then feature B becomes mandatory. For example, if an Acceptor is part of a Coordinated Set, it must implement the CSIS Set Member role. The full rules are in Table 3.1 of the CAP specification.

CAP organises all BLE Audio actions into five logical groups. Each group defines a precise sequence of operations drawn from BAPS and CSIPS:

BlueZ implements CSIS support inside the profiles/audio/ directory. The GATT service and its characteristics are registered through the D-Bus interface. Here is the general layout:

bluez/
├── profiles/
│   └── audio/
│       ├── csis.c         ← Coordinated Set Identification Service
│       ├── csis.h
│       ├── cap.c          ← Common Audio Profile orchestration
│       ├── cap.h
│       └── media.c        ← Media/audio stream handling
├── src/
│   └── shared/
│       ├── csis.c         ← GATT client-side CSIS parsing
│       └── csis.h

When BlueZ registers a CSIS server (Set Member role), it creates a GATT service with the four mandatory characteristics. When acting as a Set Coordinator, the client-side code reads these characteristics after bonding and uses them to verify set membership.

If you have a BLE Audio device that implements CSIS, you can explore its characteristics manually using bluetoothctl. After connecting and pairing:

# Connect to the earbud
[bluetooth]# connect AA:BB:CC:DD:EE:FF

# Enter the GATT menu
[bluetooth]# menu gatt

# List all attributes — look for CSIS UUIDs
[bluetooth]# list-attributes

# Example output — CSIS service at handle 0x0040
# Primary Service (Handle 0x0040)
#   UUID: 00001846-0000-1000-8000-00805f9b34fb  ← CSIS Service
#
# Characteristic (Handle 0x0042)
#   UUID: 00002b84-0000-1000-8000-00805f9b34fb  ← SIRK
# Characteristic (Handle 0x0044)
#   UUID: 00002b85-0000-1000-8000-00805f9b34fb  ← Coordinated Set Size
# Characteristic (Handle 0x0046)
#   UUID: 00002b86-0000-1000-8000-00805f9b34fb  ← Set Member Lock
# Characteristic (Handle 0x0048)
#   UUID: 00002b87-0000-1000-8000-00805f9b34fb  ← Set Member Rank

# Read Coordinated Set Size
[bluetooth]# select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service0040/char0044
[bluetooth]# read
# Output: 02   ← Set has 2 members

# Read Rank
[bluetooth]# select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service0040/char0048
[bluetooth]# read
# Output: 01   ← This is Rank 1 (left earbud)

The following Python skeleton shows the conceptual structure of a Set Coordinator discovering and validating members of a Coordinated Set using BlueZ D-Bus APIs:

#!/usr/bin/env python3
"""
CSIS Set Member Discovery — BlueZ D-Bus conceptual skeleton
Demonstrates the Set Members Discovery Procedure logic.

Requires: python-dbus, BlueZ 5.70+ with BLE Audio support
"""

import dbus
import dbus.mainloop.glib
from gi.repository import GLib

BLUEZ_SERVICE  = "org.bluez"
ADAPTER_PATH   = "/org/bluez/hci0"
DBUS_OM_IFACE  = "org.freedesktop.DBus.ObjectManager"
GATT_CHR_IFACE = "org.bluez.GattCharacteristic1"

# CSIS Characteristic UUIDs
SIRK_UUID      = "00002b84-0000-1000-8000-00805f9b34fb"
SET_SIZE_UUID  = "00002b85-0000-1000-8000-00805f9b34fb"
LOCK_UUID      = "00002b86-0000-1000-8000-00805f9b34fb"
RANK_UUID      = "00002b87-0000-1000-8000-00805f9b34fb"

class CSISCoordinator:
    def __init__(self, bus):
        self.bus = bus
        self.om  = dbus.Interface(
            bus.get_object(BLUEZ_SERVICE, "/"),
            DBUS_OM_IFACE
        )
        self.known_sirk    = None   # Set after first member is read
        self.set_size      = 0
        self.members_found = []     # List of verified set member paths

    def read_characteristic(self, dev_path, uuid):
        """Find and read a GATT characteristic by UUID under a device path."""
        objects = self.om.GetManagedObjects()
        for path, ifaces in objects.items():
            if not path.startswith(dev_path):
                continue
            chr_iface = ifaces.get(GATT_CHR_IFACE, {})
            if chr_iface.get("UUID") == uuid:
                char_obj = self.bus.get_object(BLUEZ_SERVICE, path)
                char     = dbus.Interface(char_obj, GATT_CHR_IFACE)
                return bytes(char.ReadValue({}))
        return None

    def verify_and_register_member(self, dev_path):
        """
        After bonding, read SIRK and compare to known value.
        If match → register as verified Set Member.
        """
        sirk_bytes = self.read_characteristic(dev_path, SIRK_UUID)
        if sirk_bytes is None:
            print(f"[!] {dev_path}: No SIRK found, not a CSIS device")
            return False

        if self.known_sirk is None:
            # First member — establish the reference SIRK
            self.known_sirk = sirk_bytes
            size_bytes = self.read_characteristic(dev_path, SET_SIZE_UUID)
            self.set_size = size_bytes[0] if size_bytes else 1
            rank_bytes = self.read_characteristic(dev_path, RANK_UUID)
            rank = rank_bytes[0] if rank_bytes else 0
            print(f"[+] First member found. Set size={self.set_size}, Rank={rank}")
            self.members_found.append({"path": dev_path, "rank": rank})
            return True

        if sirk_bytes == self.known_sirk:
            rank_bytes = self.read_characteristic(dev_path, RANK_UUID)
            rank = rank_bytes[0] if rank_bytes else 0
            print(f"[+] Member verified! Path={dev_path}, Rank={rank}")
            self.members_found.append({"path": dev_path, "rank": rank})
            return True
        else:
            print(f"[-] SIRK mismatch — different Coordinated Set, discarding")
            return False

    def is_set_complete(self):
        return len(self.members_found) >= self.set_size

    def get_ordered_members(self):
        """Return members sorted by ascending Rank — for Ordered Access."""
        return sorted(self.members_found, key=lambda m: m["rank"])

    def acquire_locks_ordered(self):
        """
        Ordered Access Procedure:
        Acquire Set Member Lock on each member in ascending Rank order.
        Prevents deadlock when multiple coordinators compete.
        """
        ordered = self.get_ordered_members()
        for member in ordered:
            lock_bytes = self.read_characteristic(member["path"], LOCK_UUID)
            if lock_bytes and lock_bytes[0] == 0x02:  # 0x02 = Locked by another client
                print(f"[!] Rank {member['rank']} already locked — cannot proceed")
                return False
            # Write 0x01 = Lock
            # (write omitted here — requires WriteValue D-Bus call)
            print(f"[+] Locked Rank {member['rank']}")
        return True

# --- Main ---
if __name__ == "__main__":
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
    bus = dbus.SystemBus()
    coordinator = CSISCoordinator(bus)
    print("CSIS Set Coordinator initialised.")
    print("Connect + pair with devices and call coordinator.verify_and_register_member(path)")

For quick debugging of connected BLE Audio devices and their CSIS advertisement data at the HCI level:

# Enable LE scanning and look for RSI AD Type (0x2E) in advertising reports
# Use hcidump to capture raw HCI events

sudo hcidump -i hci0 -X 2>/dev/null | grep -A 5 "2e:"

# Or use btmon for a more structured view
sudo btmon 2>/dev/null | grep -i "RSI\|CSIS\|Coordinated"

# To see what GATT services a connected BLE Audio device exposes,
# use bluetoothctl after connecting:
bluetoothctl
[bluetooth]# connect AA:BB:CC:DD:EE:FF
[bluetooth]# info AA:BB:CC:DD:EE:FF

# Example relevant output:
#  UUID: Coordinated Set Identification (00001846-...)
#  UUID: Audio Stream Control Service  (0000184e-...)
#  UUID: Published Audio Capabilities  (00001850-...)

# For a full attribute dump:
bluetoothctl
[bluetooth]# menu gatt
[bluetooth]# select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF
[bluetooth]# list-attributes

• CSIPS is the foundation of multi-device coordination in BLE Audio — without it, each earbud is an isolated device.
• The RSI is a privacy-preserving rotating identifier; only a device holding the SIRK can verify set membership.
• The SIRK is a 128-bit shared secret burned in at manufacture — it is the “group password” for a Coordinated Set.
• All four CSIS characteristics (SIRK, Set Size, Lock, Rank) are mandatory for CAP-compliant Acceptors, even if Lock and Rank are not actively used by any current CAP procedure.
• The Ordered Access procedure uses ascending Rank order for Lock acquisition — this eliminates deadlocks between competing Set Coordinators.
• CAP is the recipe book: it sequences BAPS, CSIPS, VCP, MICP and MCP into complete procedures for every common audio action.
• The Commander role elevates broadcast audio from passive casting to an actively managed distribution service.
• Top-level profiles (HAP, TMAP, PBP) are just CAP with narrower options — they don’t reinvent the wheel.

• Not advertising RSI — If a Set Member does not include the RSI AD Type in its advertisement, a Set Coordinator cannot identify it as a group candidate. This is the single most common reason CSIS discovery silently fails.
• Mismatched SIRK at provisioning — If a replacement earbud ships with a different default SIRK than the surviving one, the coordinator will reject it as a different set. Manufacturers must plan for a re-pairing ceremony.
• Skipping Ordered Access — Jumping straight into Lock acquisition without following ascending Rank order opens the door to race conditions in multi-device scenarios (e.g., two phones trying to grab the same set).
• Not releasing the Lock — A coordinator that crashes or disconnects without releasing the Set Member Lock will leave the Acceptor inaccessible until the lock times out (behavior is implementation-defined).
• Confusing Initiator and Commander — The Initiator carries audio streams (unicast). The Commander does not carry streams — it manages broadcast. Assigning the wrong role in your GATT database leads to profile conformance failures.