Hearing aid devices (HA) can have improved accessibility on Android-powered mobile devices by using connection-oriented L2CAP channels (CoC) over Bluetooth Low Energy (BLE). CoC uses an elastic buffer of several audio packets to maintain a steady flow of audio, even in the presence of packet loss. This buffer provides audio quality for hearing aid devices at the expense of latency.

The design of CoC references the Bluetooth Core Specification Version 5 (BT). To stay aligned with the core specifications, all multi-byte values on this page should be read as little-endian.

Terminology

• Central - the Android device that scans for advertisements over Bluetooth.
• Peripheral - the hearing instrument that sends advertisement packets over Bluetooth.

Network topology and system architecture

When using CoC for hearing aids, the network topology assumes a single central and two peripherals, one left and one right, as seen in Figure 1. The Bluetooth audio system views the left and right peripherals as a single audio sink. If a peripheral is missing, due to a monaural fit or a loss of connection, then the central mixes the left and right audio channel and transmits the audio to the remaining peripheral. If the central loses connection to both peripherals, then the central considers the link to the audio sink lost. In those cases, the central routes audio to another output.

Figure 1. Topology for pairing hearing aids with Android mobile devices using CoC over BLE

When the central is not streaming audio data to the peripheral and can maintain a BLE connection, the central should not disconnect from the peripheral. Maintaining the connection allows the data communication to the GATT server residing on the peripheral.

When pairing and connecting hearing devices, the central should:

• Keep track of the more recent left and right peripherals paired. Those two peripherals should be considered the audio sink.
• Assume the peripherals are in use if a valid pairing exists. The central should attempt to connect or reconnect with the paired device when the connection is lost.
• Assume the peripherals are no longer in use if a pairing is deleted.

In the cases above, pairing refers to the action of registering a set of hearing aids with a given UUID and left/right designators in the OS, not the Bluetooth pairing process.

System requirements

To properly implement CoC for a good user experience, the Bluetooth systems in the central and peripheral devices should:

• implement a compliant BT 4.2 or higher controller
• support at least 2 simultaneous LE links with parameters as described in Audio packet format and timing.
• have an LE credit based flow control [BT Vol 3, Part A, Sec 10.1]. Devices should support an MTU and MPS size of at least 240 bytes on CoC and be able to buffer up to 8 packets.
• have an LE data length extension [BT Vol 6, Part B, Sec 5.1.9] with a payload of at least 87 bytes. It is recommended that the data length is at least 250 bytes.
• have the central device support the HCI LE Connection Update Command and comply with the non-zero minimum_CE_Length parameter.
• maintain the data throughput for two LE CoC connections to two different peripherals with the connection intervals and payload sizes in Audio packet format and timing.
• have the peripheral set the MaxRxOctets and MaxRxTime parameters in the LL_LENGTH_REQ or LL_LENGTH_RSP frames to be the smallest required values that are necessary for these specifications. This lets the central optimize its time scheduler when calculating the amount of time needed to receive a frame.

The peripheral and central may implement 2 Mbit PHY as specified in BT 5. The central should support audio links up to 64 kbit/s on both 1 Mbit and 2 Mbit PHY but can choose to limit support for links requiring more than 64 kbit/s to the 2 Mbit PHY in order to improve coexistence with other 2.4 GHz devices. The BLE long range PHY should not be used.

CoC uses the standard Bluetooth mechanisms for link layer encryption and frequency hopping.

ASHA GATT services

A peripheral should implement the Audio Streaming for Hearing Aid (ASHA) GATT server service described below. The peripheral should advertise this service when in general discoverable mode to let the central recognize an audio sink. Any LE audio streaming operations shall require encryption. The BLE audio streaming consists of the following characteristics:

The UUIDs assigned to the service and characteristics:

Service UUID: {0xFDF0}

In addition to the ASHA GATT service, the peripheral should also implement the Device Information Service to let the central detect the manufacturer names and device names of the peripheral.

ReadOnlyProperties

ReadOnlyProperties have the following values:

DeviceCapabilities

HiSyncID

FeatureMap

Codec IDs

If the bit is set, then that particular codec is support.

AudioControlPoint

This control point cannot be used when the LE CoC is closed. See Starting and stopping an audio stream for the procedure description.

Advertisements for ASHA GATT Service

The service UUID must be in the advertisement packet. In either the advertisement or the scan response frame, the peripherals must have a Service Data:

The peripherals must have a Complete Local Name data type that indicates the name of the hearing aid. This name will be used on the mobile device's user interface so the user can select the right device. The name should not indicate the left or right channel since this information is provided in DeviceCapabilities.

If the peripherals put the name and ASHA service data types in the same frame type (ADV or SCAN RESP), then the two data types should appear in the same frame. This lets the mobile device scanner get both data in the same scan result.

During the initial pairing, it is important that the peripherals advertise at a rate fast enough to let the mobile device quickly discover the peripherals and bond to them.

Synchronizing left and right peripheral devices

To work with Bluetooth on Android mobile devices, peripheral devices are responsible for ensuring that they are synchronized. The playback on the left and right peripheral devices needs to be synchronized in time. Both peripheral devices must play back audio samples from the source at the same time.

Peripheral devices can synchronize their time by using a sequence number prepended to each packet of the audio payload. The central will guarantee that audio packets that are meant to be played at the same time on each peripheral have the same sequence number. The sequence number is incremented by one after each audio packet. Each sequence number is 8-bit long, so the sequence numbers will repeat after 256 audio packets. Since each audio packet size and sample rate is fixed for each connection, the two peripherals can deduce the relative playing time. For more information about the audio packet, see Audio packet format and timing.

Audio packet format and timing

Packing audio frames (blocks of samples) into packets lets the hearing instrument derive timing from the link layer timing anchors. To simplify the implementation:

• An audio frame should always match the connection interval in time. For example, if the connection interval is 15ms and sample rate is 1 kHz, then the audio frame should contain 240 samples.
• Sample rates in the system are restricted to multiples of 8kHz to always have an integer number of samples in a frame regardless of the frame time or the connection interval.
• A sequence byte should prepend audio frames. The sequence byte should be counting with wrap-around and allow the peripheral to detect buffer mismatch or underflow.
• An audio frame should always fit into a single LE packet. The audio frame should be sent as a separate L2CAP packet. The size of the LE LL PDU should be:
  audio payload size + 1 (sequence counter) + 6 (4 for L2CAP header, 2 for SDU)
• A connection event should always be large enough to contain 2 audio packets and 2 empty packets for an ACK to reserve bandwidth for retransmissions.

To give the central some flexibility, the G.722 packet length is not specified. The G.722 packet length can change based on the connection interval that the central sets.

For all the codecs that a peripheral supports, the peripheral should support the connection parameters below. This is a non-exhaustive list of configurations that the central can implement.

Starting and stopping an audio stream

Before starting an audio stream, the central queries the peripherals and establishes the best quality common denominator codec. The stream setup then proceeds through sequence:

1. PSM, and optionally, PreparationDelay is read.
2. CoC L2CAP channel is opened – the peripheral should grant 8 credits initially.
3. A connection update is issued to switch the link to the parameters required for the chosen codec.
4. Both the central and the peripheral host wait for the update complete event.
5. Restart the audio encoder, and reset the packet sequence count to 0. A «Start» command with the relevant parameters is issued on the AudioControlPoint. During audio streaming, the replica should be available at every connection event even though the current replica latency may be non-zero.
6. The peripheral takes the first audio packet from its internal queue (sequence number 0) and plays it.

The central issues the «Stop» command to close the audio stream. Once the audio stream is closed, the peripheral may ask for more relaxed connection parameters. Go through the sequence above again to restart the audio streaming. When the central is not streaming audio, it should still maintain a LE connection for GATT services.

The peripheral should not issue a connection update to the central. To save power, the central may issue a connection update to the peripheral when it is not streaming audio.