Step-by-Step Walkthroughs of All Five CSIP Procedures with Sequence Diagrams and Complete Security Requirements
Quick Recap from Part 2
In Part 2 we covered the two CSIP roles (Set Coordinator as GATT client, Set Member as GATT server), the four CSIS characteristics (SIRK, Set Size, Member Lock, Member Rank), and how the RSI provides privacy-preserving identification during scanning. Now we put it all together and walk through the actual procedures a coordinator follows to discover and manage a Coordinated Set.
Keywords Covered in This Article
🗺️ Overview: The Five CSIP Procedures
CSIP defines five procedures that a Set Coordinator carries out in a logical sequence. Understanding the order and the dependencies between them is critical before diving into each one.
🔎 Procedure 1: Coordinated Set Discovery
This is always the first step. The coordinator needs to identify at least one Set Member before it can do anything else. The goal of this procedure is to obtain the SIRK of the Coordinated Set, along with the member’s rank and the total set size.
When Does This Run?
The coordinator already knows about the first Set Member — either through previous user interaction (the user paired one earbud), through prior scan data, or through an out-of-band mechanism. At this point it connects to that member and starts the Coordinated Set Discovery procedure.
Connect to the known Set Member over BLE
Perform GATT primary service discovery → find CSIS (UUID 0x1846)
If member is in multiple sets → use Find Included Services to identify the right CSIS instance
Read the Set Identity Resolving Key (SIRK) characteristic
If Type = 0x00 (encrypted): decrypt using sdf(LTK, EncSIRK) to get real SIRK
If Type = 0x01 (plaintext): use Value directly as SIRK
Read the Set Member Rank characteristic (if present)
Read the Coordinated Set Size characteristic (if present)
Accepts connection
Returns primary services list including CSIS
Returns included service declarations
Returns SIRK characteristic value (17 bytes: Type + Value)
Coordinator processes SIRK internally — no more communication needed for this step
Returns rank value (e.g. 0x01)
Returns set size value (e.g. 0x02 for a pair)
The coordinator has obtained the SIRK value, and has successfully read both the Rank and Set Size characteristics (if they were exposed by the member).
The SIRK read fails, or the Rank or Set Size reads fail when those characteristics are present. An OOB mechanism can substitute for the GATT read if one is available.
👥 Procedure 2: Set Members Discovery
Now that the coordinator has the SIRK, it can find the other members. The Set Members Discovery procedure involves active BLE scanning, RSI resolution using the SIRK, and then connecting to each discovered member to verify and store it.
How RSI Scanning Works
Each Set Member includes an RSI AD Type in its advertising data. The coordinator scans for devices and, for every advertising report it receives, extracts the RSI field and runs the RSI resolution function using the SIRK it obtained in Procedure 1. If the resolution succeeds (hash matches), the device is a member of the set.
| Set Coordinator | Action | Set Member (Undiscovered) | Result |
|---|---|---|---|
| Start GAP General Discovery procedure (LE) or Device Discovery (BR/EDR). Set timer TCSIP = 10 seconds. | Scan → | Broadcasting advertising packet containing the RSI AD Type (6-byte RSI) | Coordinator receives ADV report |
| Extract RSI from ADV data. Run RSI Resolution: compute sih(SIRK, prand_from_RSI). Compare computed hash with hash in RSI. | ↕ resolve | (passively advertising) | ✅ Match → This is a set member! ❌ No match → Different set, ignore. |
| Connect to resolved member. Pair. Read SIRK. Confirm SIRK equals the set’s SIRK. Store member. Reset timer TCSIP. | Connect → | Accepts connection, exposes CSIS | Member confirmed and stored |
① All members are found (coordinator counted them using the Set Size value) — timer stops. ② The timer TCSIP expires (recommended value: 10 seconds) — discovery ends with whatever was found. ③ The application explicitly terminates the scan.
A Set Member may transmit multiple advertising sets all containing the RSI. The Set Coordinator should disable deduplication of advertising reports — otherwise it might miss RSIs from the same device broadcast on different advertising sets.
🔒 Procedure 3: Lock Request
The Lock Request procedure solves a classic race condition: when two phones are simultaneously trying to send a coordinated command to the same set of earbuds, the commands could interleave and cause inconsistent state. The Lock Request gives one coordinator exclusive access by writing “Locked” to every member’s Set Member Lock characteristic.
The Lock Request and Lock Release procedures can only be used when the Set Coordinator supports Bondable mode and has bonded with the Set Members. Without bonding, the coordinator must use the Ordered Access procedure (Procedure 5) instead.
How the Lock Request Works
The coordinator writes “Locked” to the Set Member Lock characteristic on each member, starting from the member with the lowest Rank value (Rank 0x01) and moving upward in rank order. Every member that accepts the write returns a success Write Response.
| SC1 (Has lock) | SC2 (Wants lock) | SM1 (Rank 0x01) | SM2 (Rank 0x02) |
|---|---|---|---|
| Write Lock “Locked” → | ← Receives, grants lock | ||
| ← Write Response OK | Send Write Response | ||
| Write Lock “Locked” → | ← Receives, grants lock | ||
| ← Write Response OK — Lock Obtained! | Send Write Response | ||
| SC1 executes its higher-layer procedure (e.g. volume sync) | |||
| Write Lock “Locked” → | ← Already locked by SC1 — sends error | ||
| ← Error: Lock Denied | Returns ATT error code | ||
| Write CCCD 0x0001 (enable notify) → | ← Registers SC2 for notifications | ||
| SC1 finishes its operation, now releases the lock… | |||
| Write Lock “Unlocked” → (SM2 first, then SM1) | ← Sets lock state to Unlocked | ← Sets lock state to Unlocked | |
| ← Notification: Lock = Unlocked | Sends notification to SC2 | ||
| SC2 can now attempt Lock Request again | |||
If any Set Member returns a “Lock Denied” error, the coordinator must stop immediately and not attempt to lock any further members. It must then release the lock on all members that already granted it. Partial locking of a set is not a valid state.
🔓 Procedure 4: Lock Release
After the coordinator finishes its coordinated operation, it must release the lock so that other coordinators can proceed. Lock Release is the reverse of Lock Request: the coordinator writes “Unlocked” to each member’s Set Member Lock characteristic, but this time in descending rank order — starting from the highest rank number and working down to Rank 0x01.
Rank 0x01 → Rank 0x02 → Rank 0x03 → …
(ascending, lowest rank number first)
… → Rank 0x03 → Rank 0x02 → Rank 0x01
(descending, highest rank number first)
The reason for reversed order is to release the “less critical” members first, keeping the most important one (Rank 0x01) locked the longest. This gives other coordinators the smoothest possible handover — by the time Rank 0x01 is released, all secondary members are already free.
📋 Procedure 5: Ordered Access
The Ordered Access procedure is the non-bonded alternative to Lock Request. When the coordinator and Set Members have not bonded, the Lock Request procedure is unavailable (because decrypting the SIRK and writing the Lock characteristic requires a bonded security context). The Ordered Access procedure provides a best-effort collision avoidance mechanism for these scenarios.
Important Distinction
Unlike Lock Request, Ordered Access cannot atomically prevent another coordinator from starting the same procedure simultaneously. It reduces the probability of race conditions through coordinated sequencing, but does not eliminate them. Use Lock Request whenever bonding is available.
How Ordered Access Works
Read the Set Member Lock characteristic from the member with the lowest Rank (Rank 0x01). Do NOT write — just read the current state.
If that member’s lock is Locked: stop. Optionally subscribe to notifications and wait until it becomes Unlocked, then restart from Step 1.
If Unlocked, proceed to the next member (Rank 0x02) and repeat the read. Continue in ascending rank order until all members are checked.
If all members respond with Unlocked: execute the higher-layer procedure (Procedure_A), again starting from Rank 0x01 in ascending order.
🔐 CSIP Security Requirements
Security is a first-class concern in CSIP. The SIRK is a sensitive secret — if it leaks, any device could impersonate a set member or eavesdrop on group membership. CSIP therefore mandates strong encryption and recommends bonding for all deployments.
Minimum Security Level
All characteristics in the CSIS service must be protected at a minimum of Security Mode 1, Level 2 (SM1 L2) over LE. This means that the BLE connection must be encrypted before any characteristic can be read or written. Unauthenticated encryption (Just Works pairing) satisfies this level, but authenticated methods are strongly preferred.
Key Entropy Requirement
The encryption key protecting CSIS characteristics must have at least 128 bits of entropy. This requirement can be satisfied in three ways:
Provides 128-bit keys through elliptic curve Diffie-Hellman. Strongest option.
Derive LE LTK from BR/EDR link key via Cross-Transport Key Derivation.
Out-of-band pairing (e.g. NFC tap) provides sufficient key material.
Bonding and CTKD
Both the Set Coordinator and Set Member should support Bondable mode and the bonding procedure. Bonding stores the LTK so the devices do not need to re-pair on every connection, and it is required for the Lock Request procedure (because decrypting the EncSIRK uses the LTK).
For dual-mode devices (supporting both BR/EDR and LE), Cross-Transport Key Derivation (CTKD) is mandatory. CTKD allows a single pairing over one transport to derive keys for the other, avoiding the poor user experience of asking the user to pair twice.
BLE Privacy and RSI Renewal
BLE privacy (resolvable private addresses) is strongly recommended for Set Members. When privacy is enabled, the device changes its Bluetooth address periodically. The Set Member must generate a fresh RSI every time its private address changes — keeping RSI and address in sync so that neither can be used to track the device independently.
| Security Requirement | Set Coordinator | Set Member |
|---|---|---|
| SM1 Level 1 (No security) | ✘ Excluded | ✘ Excluded |
| SM1 Level 2 (Encrypted, unauthenticated) | Optional | One of L2/L3/L4 mandatory |
| SM1 Level 3 (Encrypted, authenticated — MITM) | Optional | One of L2/L3/L4 mandatory |
| SM1 Level 4 (LE Secure Connections, 128-bit) | Optional | One of L2/L3/L4 mandatory |
| 128-bit key entropy | Mandatory if L2/L3 | Mandatory if L2/L3 |
| Bonding (Bondable mode) | Recommended | Recommended |
| CTKD (for dual-mode BR/EDR+LE devices) | Mandatory (if dual-mode) | Mandatory (if dual-mode) |
| BLE Privacy (RPA) + RSI sync | Recommended | Recommended (+ distribute IA and IRK) |
🏁 Complete Series Summary
You have now completed the full three-part CSIP series. Here is a consolidated summary of everything covered:
A Bluetooth SIG profile that enables a central device to discover, group, and coordinate access to multiple BLE peripherals. Used in TWS earbuds, hearing aids, sensor networks and more.
Set Coordinator (GATT client, phone/tablet) discovers and controls. Set Member (GATT server, earbud/sensor) exposes CSIS and advertises RSI.
Four characteristics: SIRK (the group secret, encrypted or plaintext), Set Size, Set Member Lock (for exclusive access), and Set Member Rank (ordering).
A 6-byte privacy-preserving identifier in ADV data, derived from the SIRK via a hash. The coordinator uses the SIRK to resolve RSIs and identify which advertising devices are set members.
Set Discovery → Members Discovery → Lock Request (bonded) or Ordered Access (non-bonded) → Execute operation → Lock Release. Always in this sequence.
Minimum SM1 L2 with 128-bit key entropy. Bonding strongly recommended. CTKD mandatory for dual-mode devices. Privacy + RSI renewal recommended to prevent device tracking.
CSIP Series Complete!
You now have a solid understanding of CSIP from first principles all the way to implementation-level procedures and security requirements. Explore more BLE protocol stack topics on EmbeddedPathashala.
← Back to Part 1: Introduction ← Back to Part 2: Roles & CSIS All BLE Tutorials →