EmbeddedPathashala · Bluetooth LE Audio Series · Part 2
Introduction — What CAS Is, Why It Exists, and How It Works
What is the Common Audio Service?
The Common Audio Service (CAS) is a GATT Primary Service defined in the Bluetooth SIG Common Audio Service Specification v1.0 (March 2022). It has one job: identify a device as a CAP Acceptor.
When a CAP Initiator (like a smartphone) connects to a remote device, the very first thing it checks is whether the remote device has a CAS instance on its GATT server. If CAS is present, the Initiator knows it is talking to a CAP Acceptor — a device that understands the LE Audio framework and supports the relevant services (PACS, ASCS, etc.).
If CAS is absent, the Initiator does not attempt any CAP procedures. CAS acts as the entry gate for the entire Common Audio Profile.
CAS uses a design pattern that appears in other Bluetooth services: the “identity flag” service. The service exists purely to declare capability — it carries no data, defines no characteristics, and performs no operations. The presence of the service UUID itself is the entire message.
| Pattern | How It Works | Real-World Analogy |
|---|---|---|
| Advertisement UUID | Device advertises the CAS UUID in its AD structure. Initiator can filter scan results for this UUID without even connecting. | A store’s sign in the window — tells you what it sells before you walk in. |
| GATT Primary Service | After connection, Initiator discovers GATT services. Finding CAS (0x1853) as a Primary Service confirms the device is a CAP Acceptor. | A business card — just a name and role, no extra data needed. |
| CSIS Inclusion | If the device is also a member of a Coordinated Set, CAS includes the CSIS service handle as an “Included Service” declaration inside CAS. | The business card that also says “Part of XYZ Group” — extra info about membership. |
CAS UUID — The 16-bit Assigned Number
CAS uses a 16-bit Bluetooth SIG assigned UUID. Bluetooth SIG maintains a central registry of assigned numbers. The CAS UUID 0x1853 was registered as part of the LE Audio specification work in 2022.
All 16-bit UUIDs are simply short forms of 128-bit UUIDs using the Bluetooth Base UUID. The full 128-bit form is used in GATT when the stack needs the complete UUID.
| 16-bit short form | 0x1853 |
| 128-bit full form | 00001853–0000-1000-8000-00805f9b34fb |
| Base UUID (fixed) | 00000000-0000-1000-8000-00805f9b34fb Bluetooth Base UUID — same for all 16-bit and 32-bit assigned UUIDs |
bt_uuid16_create(&uuid, 0x1853) or pass the full 128-bit string directly.CAS GATT Structure
Below is the complete GATT attribute table for CAS. Notice how minimal it is. A standard GATT service needs at minimum a Service Declaration attribute. That is all CAS has — plus an optional Included Service declaration pointing to CSIS.
| Handle | Attribute Type | Attribute Value | Permissions |
|---|---|---|---|
| 0x0020 | «Primary Service» UUID: 0x2800 |
0x1853 (CAS UUID) | Read |
| — No further attributes (no characteristics) — | |||
The service ends immediately after the Service Declaration. The Initiator reads handle 0x0020, finds UUID 0x1853, and concludes: “This is a CAP Acceptor.”
| Handle | Attribute Type | Attribute Value | Permissions |
|---|---|---|---|
| 0x0020 | «Primary Service» UUID: 0x2800 |
0x1853 (CAS UUID) | Read |
| 0x0021 | «Include Declaration» UUID: 0x2802 |
Handle range of CSIS + UUID 0x1846 | Read |
| — CAS ends here; CSIS attributes are in a separate service starting at its own handle — | |||
| 0x0030 | «Primary Service» UUID: 0x2800 |
0x1846 (CSIS UUID) | Read |
| 0x0031 | Set Identity Resolving Key (SIRK) Characteristic of CSIS |
16-byte encrypted key identifying the Coordinated Set | Read (Encrypted) |
| 0x0033 | Coordinated Set Size Characteristic of CSIS |
Number of members in the set (e.g., 0x02 for a pair) | Read |
| 0x0035 | Member Lock Characteristic of CSIS |
Lock / Unlock state — prevents other Initiators connecting during an active stream | Read/Write (Encrypted) |
Important: CAS does not contain the CSIS attributes directly inside itself. It contains an Include Declaration (UUID 0x2802) that points to the handle range where the CSIS service starts. The CSIS service is a separate Primary Service — CAS just links to it.
In GATT, an Include Declaration is a special attribute type (UUID 0x2802) that allows one service to reference another service. It stores:
- The starting handle of the included service
- The ending handle of the included service
- The UUID of the included service (only for 16-bit UUIDs)
When a CAP Initiator reads the Include Declaration inside CAS and finds it pointing to a CSIS service, the Initiator knows two things at once: the device is a CAP Acceptor (from CAS) AND it is a member of a Coordinated Set (from the CSIS inclusion). This is more efficient than making the Initiator discover CSIS independently.
Why Does CAS Have No Characteristics?
Students often ask: “If CAS carries no data, why is it even a GATT service? Why not just use an advertisement flag?”
There are three reasons the Bluetooth SIG designed CAS this way:
After establishing a BLE connection, the CAP Initiator always performs GATT Primary Service Discovery. Making CAS a GATT Primary Service means it is found automatically in the same discovery pass that finds PACS, ASCS, and other services — no extra step required.
The GATT Include Declaration mechanism (UUID 0x2802) only works inside a service. If CAS were just an advertisement flag, there would be no standardised GATT location to put the Include Declaration pointing to CSIS. By being a GATT service, CAS can house that Include Declaration cleanly.
Defining CAS as a GATT service with an assigned UUID means future revisions of the specification can add characteristics to CAS without changing the fundamental discovery mechanism. The UUID stays the same; characteristics can be added in a new spec version.
CAS Declaration Rules (From the Spec)
| # | Rule | From Spec | Mandatory? |
|---|---|---|---|
| R1 | Only one CAS instance | There shall be no more than one CAS instance on a server. | SHALL |
| R2 | CAS is a Primary Service | CAS shall be instantiated as a «Primary Service» and may be included by other services. | SHALL |
| R3 | UUID must be CAS UUID | The service UUID shall be set to «Common Audio Service» as defined in Bluetooth Assigned Numbers. | SHALL |
| R4 | Include CSIS if in Coordinated Set | If the device implementing CAS is a member of a Coordinated Set, the CAS instance shall include the CSIS instance that identifies the Coordinated Set as an included service. | SHALL (if set member) |
| R5 | Max one CSIS instance included | The CAS shall include no more than one instance of CSIS. | SHALL |
| R6 | No defined behavior | There is no behavior defined for this service. | N/A |
| R7 | BT Core 5.3+ required | This specification is compatible with Bluetooth Core Specification Version 5.3 or later. | Compatibility |
CAS in the LE Audio Discovery Flow
| CAP Initiator (Smartphone) | CAP Acceptor (Earbuds) |
| 1. LE Scan — filter for ServiceData UUID 0x1853 or scan all and check after connect |
Advertising — may include UUID 0x1853 in AD payload |
| 2. ACL Connection established (LE) | Connection accepted |
| 3. GATT: Discover All Primary Services ATT_READ_BY_GROUP_TYPE_REQ (UUID 0x2800) |
Returns list: CAS(0x1853), PACS(0x1850), ASCS(0x184E), CSIS(0x1846)… |
| 4. Find CAS (0x1853) in response ✓ Confirmed: This is a CAP Acceptor |
|
| 5. Read CAS Include Declarations ATT_READ_BY_TYPE_REQ (UUID 0x2802) |
If set member: returns Include Declaration pointing to CSIS handle range |
| 6. If CSIS found via Include: read SIRK to identify partner earbud Then proceed with PACS discovery → ASCS → stream setup |
All characteristics used with CAS (which applies to CSIS when included) shall be transmitted with the Least Significant Octet (LSO) first — i.e. little-endian format. This is the standard for all GATT services in the LE Audio family.
The CAS UUID 0x1853 is transmitted over the air as bytes 53 18 (LSO first) in ATT PDUs.
/* CAS UUID on the wire (little-endian in ATT_READ_BY_GROUP_TYPE response): */
/* UUID 0x1853 transmitted as: 53 18 */
/* Example ATT response showing CAS primary service: */
/* Length | Start Handle | End Handle | UUID */
/* 04 | 20 00 | 21 00 | 53 18 */
/* ^^^^ */
/* 0x1853 in LE = 53 18 */Key Takeaways — CAS Introduction
Next: CAS — Coordinated Sets, SDP, and BlueZ Implementation
In Part 3 we go hands-on: CSIS internals for Coordinated Sets, the CAS SDP record for BR/EDR interoperability, and complete BlueZ C code showing how to register CAS and include CSIS in a GATT database.