Part A — Unicast Audio Configurations (1–11)

The spec defines 11 unicast audio configurations. They cover every combination of: how many servers are involved, how many CISes, which directions audio flows, and how many channels each ASE carries. The key variables are:

* Config 6(ii) is mandatory for the Unicast Client and mandatory for each Unicast Server that supports the Audio Sink role with >1 Audio Location.

The Most Important Configurations Explained

Part B — Broadcast Audio Configurations (12–14)

Broadcast configurations are simpler — there is no CIS, no ASE. The Broadcast Source configures the BASE structure to define how BISes carry channels.

Config 13 — Stereo Broadcast (most common for headphones)

Part C — GAP Connection Requirements

BAP defines specific GAP procedures and parameter values that devices must follow. These matter a lot in practice — wrong advertising intervals cause slow pairing; wrong connection intervals slow down GATT discovery and stream setup.

Peripheral (Unicast Server / Broadcast Sink / Scan Delegator)

When a Peripheral is ready for a new connection (non-bonded scenario), it must enter General or Limited Discoverable mode. It must use Extended Advertising PDUs and include the ASCS/PACS/BASS Service UUIDs in the advertising data so that scanning Centrals can identify it as a BAP device.

Central (Unicast Client / Broadcast Assistant)

A Central scans for Peripherals using General or Limited Discovery. It uses the General Connection Establishment procedure (not the Auto procedure) when it wants to filter devices based on the Announcement Type in the Service Data AD type.

Connection Intervals — Short During Setup, Relaxed After

This is a detail often missed but critical for stream setup speed. During service discovery and stream configuration, the connection interval must be short so GATT operations complete fast. After setup, it can be relaxed to save power.

Bonded Device Reconnection

After bonding, a Central must start encryption immediately after each reconnection to verify the bond. If encryption fails (the bond no longer exists on the server side), the Central must re-bond and redo service discovery before using any BAP services. This is important for your implementation — never skip the encryption step even if you think the bond is valid.

Part D — Security Requirements

Security is non-negotiable in BAP. Every GATT characteristic in PACS, ASCS, and BASS requires authentication and encryption before it can be accessed.

What Security Mode 1 Level 2 Actually Means

Privacy (Resolvable Private Addresses)

The Privacy feature (using Resolvable Private Addresses, RPAs) is recommended for all Peripheral and Central roles. The device rotates its BLE address periodically so it cannot be tracked. Devices using Privacy must distribute their Identity Address (IA) and Identity Resolving Key (IRK) during bonding so bonded peers can resolve the address.

For Broadcast Sources, the recommendation from Section 6.1.3 applies instead: keep the advertising address stable for the lifetime of the BIG, or use a non-resolvable private address (not resolvable, because resolvable RPAs require all sinks to know the IRK).

BlueZ — Checking Encryption and Bond Status

/* Check if a connection is encrypted and bonded
 * using BlueZ D-Bus interface org.bluez.Device1 */

#include <gio/gio.h>

void check_device_security(GDBusConnection *conn,
                             const char *device_path)
{
    GVariant *paired, *trusted, *services_resolved;
    GError   *error = NULL;

    /* Get device properties from org.bluez.Device1 */
    paired = g_dbus_connection_call_sync(conn,
        "org.bluez", device_path,
        "org.freedesktop.DBus.Properties", "Get",
        g_variant_new("(ss)", "org.bluez.Device1", "Paired"),
        NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error);

    services_resolved = g_dbus_connection_call_sync(conn,
        "org.bluez", device_path,
        "org.freedesktop.DBus.Properties", "Get",
        g_variant_new("(ss)", "org.bluez.Device1", "ServicesResolved"),
        NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error);

    /* BAP requires: Paired=true AND ServicesResolved=true
     * before accessing PACS/ASCS/BASS characteristics.
     * BlueZ handles SM1L2 (encryption) automatically after pairing.
     * Only read/write characteristics after ServicesResolved=true. */
}

/* You can also check via bluetoothctl:
 * [bluetooth]# info AA:BB:CC:DD:EE:FF
 *   Paired: yes
 *   Trusted: yes
 *   Connected: yes
 *   LegacyPairing: no       ← must be "no" (LE Secure Connections)
 *   ServicesResolved: yes   ← safe to access GATT */

Complete Implementation Checklist

Here is a consolidated checklist based on all four parts of this tutorial series: