Bluetooth le audio tutorial – AICS Service Architecture

 

 

Bluetooth le audio tutorial – AICS Service Architecture
Part 2 of 5  |  Declaration, Characteristics & Security
6
Characteristics
Secondary
Service Type
Encryption
Required on all

What We Cover in Part 2

Part 2 zooms into the structural layout of AICS. You will understand why AICS is declared as a Secondary Service, what it means to be an Included Service, how all six characteristics are organized, what properties each one has, and why encryption is required on every single characteristic.

Service Declaration — Secondary & Included

When you define a GATT service, you write a service declaration attribute into the attribute table. This declaration tells clients: “Here starts a new service, and its UUID is X.” For most services you are familiar with (Heart Rate, Battery, etc.) the declaration type is Primary Service.

AICS is different. Its declaration type is Secondary Service. A Secondary Service exists to be referenced by other services — it cannot be used standalone. The rule from the specification is: AICS shall only be instantiated as an included service. This means a Primary Service such as the Volume Control Service (VCS) will have an Include Declaration pointing at the AICS Secondary Service.

Primary vs Secondary Service — Attribute Table Layout
ATT Handle Attribute Type UUID Attribute Value
0x0001 0x2800 (Primary Service) UUID of Volume Control Service
0x0002 0x2802 (Include Declaration) Handle=0x0010, End=0x001F, UUID of AICS
0x0010 0x2801 (Secondary Service) UUID of Audio Input Control Service
0x0011 0x2803 (Char Declaration) Properties=Read|Notify, Handle=0x0012, UUID of Audio Input State
0x0012 Audio Input State UUID [Gain_Setting][Mute][Gain_Mode][Change_Counter]
… (remaining AICS characteristics)
0x2800 = Primary Service UUID  |  0x2801 = Secondary Service UUID  |  0x2802 = Include Declaration UUID
💡 Why Secondary? The design choice makes sense: multiple different Primary Services (VCS, Microphone Control Service) can each include their own AICS instance without duplicating logic. Each AICS instance represents one physical audio input on the device. A stereo device with left and right microphones would have two AICS instances.

Multiple AICS Instances — One Per Audio Input

A single device can have multiple AICS instances. Each instance represents one audio input. The client uses the Audio Input Description characteristic (a plain UTF-8 string) to figure out which instance belongs to which physical input.

Two AICS Instances on a Wireless Microphone Device
AICS Instance #1
Audio Input Description = “Left Mic”
Audio Input Type = Analog (0x02)
Gain_Setting = +3
Mute = Not Muted (0)
AICS Instance #2
Audio Input Description = “Right Mic”
Audio Input Type = Analog (0x02)
Gain_Setting = 0
Mute = Muted (1)
Client reads Audio Input Description first, then addresses each instance separately by its GATT handle range

All Six AICS Characteristics at a Glance

Every AICS instance contains exactly six characteristics, all Mandatory (M). Here is what each one does and the permitted operations on it. Every characteristic requires link-layer encryption — you cannot access any of them over an unencrypted connection.

# Characteristic Name Req Mandatory Properties Optional Properties Security
1 Audio Input State M Read, Notify None Encryption Required
2 Gain Setting Properties M Read None Encryption Required
3 Audio Input Type M Read None Encryption Required
4 Audio Input Status M Read, Notify None Encryption Required
5 Audio Input Control Point M Write None Encryption Required
6 Audio Input Description M Read, Notify (C.1) Write Without Response, Notify Encryption Required
C.1: Notify is Mandatory if Write Without Response is supported; otherwise it is Optional.

Visual Service Map — Characteristic Relationships

These six characteristics do not work in isolation. The diagram below shows how they relate. The Audio Input State characteristic is the central piece — everything else either limits what values it can hold, or lets the client change it.

AICS Characteristic Relationship Map

Gain Setting Properties
Read-only static
Sets valid range for Gain_Setting
Units Min Max
Audio Input Type
Read-only static
Source type: mic, line-in, BT stream
Audio Input Description
Human-readable label
e.g., “Left Mic”, “Line In”
constrains
&
labels
Audio Input State
Read + Notify
Gain_Setting Mute Gain_Mode Change_Counter
Audio Input Status
Read + Notify
Active (0x01) or Inactive (0x00)
writes to
Audio Input Control Point
Write-only
Client sends opcodes here
0x01 Set Gain
0x02 Unmute
0x03 Mute
0x04 Manual Mode
0x05 Auto Mode

Audio Input Type — What Values Are Possible?

The Audio Input Type characteristic holds a single byte whose meaning is defined in the Bluetooth SIG Assigned Numbers document. The most common values you will see in practice are:

Hex Value Input Type Name Typical Device Example
0x00 Unspecified Generic device, type not defined
0x01 Bluetooth (Isochronous Stream) LE Audio isochronous stream from another BT device
0x02 Microphone Built-in or external microphone
0x03 Analog (Line In) 3.5mm jack or RCA line input
0x04 Digital S/PDIF, I2S digital input
0x05 Ambient / Environment Hearing aid passthrough microphone
0x06 Local / Internal Audio mixed internally on the device
🔧 BlueZ Note: The Audio Input Type value is read-only and static — the server must not change it while a client is connected. Set it once when building the GATT attribute table for your AICS server and leave it fixed.

Audio Input Status — Active or Inactive

The Audio Input Status tells the client whether the audio input is currently active (processing audio) or inactive (disconnected, disabled, or off). This is separate from mute — an inactive input is not producing audio at all; a muted input is active but silenced at output.

Audio Input Status — Active vs Inactive vs Muted
Status Value Mute Field What Is Happening Audio Output
Active (0x01) Not Muted (0) Microphone is powered and capturing audio; output is passing through with current gain ▶ SOUND
Active (0x01) Muted (1) Microphone is powered and capturing audio; output is silenced by software mute 🔇 MUTED
Inactive (0x00) Any The audio input is powered off, physically disconnected, or the stream source has ended ⏹ NOTHING

Security — Why Encryption is Required on Every Characteristic

All six AICS characteristics are marked Encryption Required. This means the BLE link must be encrypted (bonding or at minimum just-works pairing with encryption) before the server will respond to any ATT operation. If a client attempts to read or write without encryption, the server returns ATT error code 0x0F (Insufficient Encryption).

The reason is straightforward: AICS controls the microphone gain of medical-grade and privacy-sensitive devices like hearing aids. You do not want a random nearby device to be able to silently mute someone’s hearing aid or boost their microphone gain without consent.

Security Requirement — ATT Read Request Flow

GATT Client (Phone)
1. Pair & encrypt link
(SMP pairing completes)
3. ATT Read Request
Handle: 0x0012
5. Receives: [03][00][02][07]
(Gain=3, NotMuted, Manual, CC=7)
Encrypted BLE
ATT over L2CAP
GATT Server (Hearing Aid)
2. SMP keys exchanged
Link now encrypted
4. Checks: link encrypted? YES
Returns ATT Read Response
If NOT encrypted: returns
ATT Error 0x0F (Insuff. Enc.)

Quick Reference — Characteristic Properties Summary

1. Audio Input State
📖 Read — get current [Gain | Mute | Mode | CC]
🔔 Notify — auto-push on any state change
Size: 4 bytes total
2. Gain Setting Properties
📖 Read — get [Units | Min | Max]
❌ No Notify — static value
Size: 3 bytes total
3. Audio Input Type
📖 Read — source type byte
❌ No Notify — static value
Size: 1 byte
4. Audio Input Status
📖 Read — active/inactive byte
🔔 Notify — push when status changes
Size: 1 byte
5. Audio Input Control Point
Write — client sends opcode + operands
❌ No Read, No Notify
Size: 2–3 bytes per write
6. Audio Input Description
📖 Read — UTF-8 label string
Write Without Response — client renames input (optional)
🔔 Notify — push when description changes
Size: variable (UTF-8)

Key Terms in Part 2

Primary Service (0x2800) Secondary Service (0x2801) Include Declaration (0x2802) Write Without Response Encryption Required ATT Error 0x0F Audio Input Type Audio Input Status CCCD

Next: Part 3 — Audio Input State Deep Dive

Part 3 explains every bit of the 4-byte Audio Input State characteristic — Gain, Mute, Mode, and the Change_Counter anti-race mechanism.

→ Part 3: Audio Input State

Leave a Reply

Your email address will not be published. Required fields are marked *