LE Audio Series · Part 1
Broadcast Audio Scan Service (BASS) — From Zero to Working Code
How hearing aids, earbuds and headsets offload their scanning job to your smartphone using a clean GATT service.
Bluetooth 5.2 · LE Audio · GATT Service · BlueZ 5.x
📚 This 3-part series covers:
| Part 1 You are here — What BASS is, key roles, service architecture |
| Part 2 Broadcast Audio Scan Control Point — all 6 operations in depth |
| Part 3 Broadcast Receive State + BlueZ implementation walkthrough |
1. The Problem BASS Solves
Picture this: you are at an airport and the public address system is broadcasting gate announcements over Bluetooth LE Audio. Your hearing aids want to pick up that broadcast automatically. To do that, they need to scan the air continuously for the broadcast source.
Scanning is expensive. The BLE radio draws significant current every time it listens. For a hearing aid with a tiny 13 mA battery, continuous scanning could drain it in a couple of hours. That is unacceptable.
Meanwhile, your smartphone sits in your pocket with a 4000 mAh battery and a fast Cortex-A processor. It can scan all day without breaking a sweat.
|
❌ Without BASS
- Hearing aid scans continuously
- Battery drains in hours
- Device heats up
- User experience suffers
|
✅ With BASS
- Smartphone does the scanning
- Hearing aid stays in sleep mode
- Battery lasts the full day
- Seamless, transparent to user
|
BASS (Broadcast Audio Scan Service) is the Bluetooth SIG’s standardised solution. It defines a GATT service that lets a power-constrained device (the server) ask a capable device (the client) to scan on its behalf, then hand over the discovered broadcast source information via GATT characteristics.
2. Key Concepts You Need to Know First
Before diving into BASS itself, let us quickly nail down the vocabulary. These terms come from the broader LE Audio / Bluetooth 5.2 ecosystem.
| Term |
What it actually means |
| Broadcast Source |
Any device that streams audio using LE Isochronous Channels. Examples: TV, PA system, concert speaker rack, museum audio guide transmitter. |
| Broadcast_ID |
A 3-byte identifier that uniquely labels a specific broadcast. Think of it as the “channel number” for a particular audio stream. |
| Periodic Advertising (PA) |
A special type of BLE advertisement that repeats at fixed intervals. The Broadcast Source puts all stream metadata here. Before you can listen to audio, you must first sync to the PA. |
| BIG (Broadcast Isochronous Group) |
A container that groups one or more audio streams together. A concert hall might have a BIG with separate streams for left-channel and right-channel audio. |
| BIS (Broadcast Isochronous Stream) |
A single audio stream inside a BIG. Each BIS carries one channel of compressed audio (LC3 codec). A stereo broadcast has two BISes. |
| Broadcast_Code |
A 16-byte encryption key that unlocks an encrypted broadcast. If the venue only wants paying attendees to hear the audio, they distribute this key (e.g. printed on a ticket). |
| PA_Interval |
How often the Periodic Advertising repeats, measured in 1.25 ms units. Knowing this helps a device sync faster without having to scan for a long time. |
| PAST (Periodic Advertising Synchronisation Transfer) |
A procedure where one device that is already synced to a PA passes the sync information (SyncInfo) to another device via a BLE connection. BASS heavily relies on this. |
| SyncInfo |
Raw timing data that lets a device jump straight into synchronisation with a PA without scanning from scratch. Like giving someone the exact GPS coordinates instead of making them search the whole map. |
3. The Three Roles in the BASS Ecosystem
📡
Broadcast Source
TV · Concert PA
Airport announcement
Museum audio guide
Streams PA + BIG + BISes
over BLE radio
|
One-way LE radio broadcast
▶
PA train + BIG audio streams
BLE Connection (GATT)
← Notify: BRS updated
Write: CP operations →
▶
SyncInfo via PAST (optional)
|
🎧
BASS Server
Hearing aid · Earbud
Headset · Cochlear implant
Exposes BASS GATT service
Wants to receive audio
📱
BASS Client
Smartphone · Smartwatch
Tablet · Laptop
Scans on behalf of server
Writes to CP characteristic
|
⚡ Important distinction: The BASS Server is the resource-constrained device that wants audio (e.g. hearing aid). It is the GATT server. The BASS Client is the powerful device (e.g. phone) that helps with scanning. This naming is deliberately flipped from what you might expect.
4. The Full BASS Flow Step by Step
Here is the complete workflow from “nothing connected” to “hearing aid streaming audio from a broadcast source”:
| Step |
Who Acts |
What Happens |
| 1 |
BASS Server (Hearing Aid) |
Advertises its BASS service UUID in connectable extended advertising packets. The phone discovers it and connects. |
| 2 |
BASS Client (Phone) |
Discovers the BASS service and subscribes to notifications on the Broadcast Receive State characteristic. |
| 3 |
BASS Client (Phone) |
Writes Remote Scan Started (0x01) to the Control Point. This tells the hearing aid “I am scanning for you now, you can stop scanning.” |
| 4 |
BASS Client (Phone) |
Finds a broadcast source and writes Add Source (0x02) to the Control Point with all the broadcast details: address, Broadcast_ID, Advertising SID, and which BISes to sync to. |
| 5 |
BASS Server (Hearing Aid) |
Uses the info to find and sync to the Periodic Advertising train (PA). Updates the Broadcast Receive State characteristic. Phone gets a notification. |
| 6 |
BASS Server (Hearing Aid) |
Once synced to PA, attempts to synchronise to the BIG and join the selected BIS streams. Updates the Broadcast Receive State again. |
| 7* |
BASS Client (Phone) [if encrypted] |
If the BIS is encrypted, the Broadcast Receive State will show Broadcast_Code required. The phone writes the key using Set Broadcast_Code (0x04). |
| 8 |
BASS Server (Hearing Aid) |
Decrypts the BIS and streams audio. Broadcast Receive State now shows Decrypting. User hears audio. 🎵 |
5. The BASS GATT Service — Two Characteristics
BASS is declared as a Primary Service. There is exactly one BASS instance per server device. Inside it, there are two types of GATT characteristics:
| BASS Primary Service (UUID: 0x184F) |
| Characteristic 1: Broadcast Audio Scan Control Point (UUID: 0x2BC0) |
| Properties |
Write, Write Without Response |
| Security |
Encryption required (bonded device) |
| Count |
Exactly 1 per server |
| Purpose |
Client writes commands here: start/stop scan, add/modify/remove source, provide Broadcast_Code |
| Characteristic 2: Broadcast Receive State (UUID: 0x2BC1) |
| Properties |
Read, Notify |
| Security |
Encryption required |
| Count |
One or more. The server should have at least as many instances as BIGs it can synchronise to simultaneously. |
| Purpose |
Server exposes sync state here. Client reads/subscribes to know: PA sync status, BIS sync status, encryption state, source identity. |
💡 Why multiple Broadcast Receive State characteristics?
A high-end hearing aid might support syncing to 2 or 3 different BIGs at the same time (left ear, right ear, plus a speech enhancement stream). Each BIG gets its own Broadcast Receive State characteristic so the client can track them independently.
6. GATT Sub-procedure Requirements
When you implement the BASS server in your firmware, these GATT sub-procedures are the minimum you must support. The ATT bearer used is the standard Unenhanced ATT bearer (plain BLE connection).
| GATT Sub-procedure |
Requirement |
Why it is needed |
| Write Characteristic Value |
Mandatory |
Client uses this to write CP operations. Server can send back ATT error responses. |
| Write Without Response |
Mandatory |
Faster CP writes, no ATT response. Server just ignores invalid packets silently. |
| Notifications |
Mandatory |
Server uses this to push Broadcast Receive State updates to the client whenever sync state changes. |
| Read Characteristic Descriptors |
Mandatory |
Client reads the Client Characteristic Configuration Descriptor (CCCD) to check notification status. |
| Write Characteristic Descriptors |
Mandatory |
Client writes to CCCD to enable/disable notifications on Broadcast Receive State. |
| Write Long Characteristic Value |
Conditional |
Required only if the Add Source operation is supported. Needed when CP write exceeds the ATT_MTU (23 bytes default). |
🔒 Security note: Both characteristics require encryption. This means the phone must be bonded (paired and keys exchanged) with the hearing aid before it can read/write anything. You cannot use BASS over an unencrypted BLE connection.
7. Compatibility and Dependencies
| Bluetooth Core Spec version |
Version 5.2 or later (BASS uses features introduced in 5.2) |
| Depends on other GATT services? |
No. BASS has no mandatory service dependencies. |
| Related profile |
Basic Audio Profile (BAP) — defines the Broadcast Source and the audio stream structure that BASS references. |
| Byte order |
Little-endian (LSO first) for all fields. |
| Transport |
No specific transport requirements. Works over both Unenhanced and Enhanced ATT bearers. If you need guaranteed notification delivery, Enhanced ATT (EATT) over L2CAP ECBF is recommended. |
8. Quick UUIDs and Error Codes Reference
| Item |
Value |
Notes |
| BASS Service UUID |
0x184F |
16-bit Bluetooth SIG assigned UUID |
| Control Point UUID |
0x2BC0 |
Broadcast Audio Scan Control Point |
| Broadcast Receive State UUID |
0x2BC1 |
Can have multiple instances |
| Error: Opcode Not Supported |
0x80 |
ATT Application Error — unrecognised opcode |
| Error: Invalid Source_ID |
0x81 |
ATT Application Error — Source_ID does not exist |
📖 What’s next in Part 2?
We will take the Broadcast Audio Scan Control Point apart opcode by opcode. You will see the exact byte format of every operation, sequence diagrams showing how the phone and hearing aid exchange messages, and BlueZ GATT code snippets for writing each operation from your Linux machine.
Coming up: Remote Scan Started/Stopped · Add Source · Modify Source · Set Broadcast_Code · Remove Source · Error handling
