Audiounterstützung von Hörgeräten über Bluetooth LE

Hörgeräte können auf Android-Mobilgeräten eine verbesserte Barrierefreiheit bieten, indem verbindungsorientierte L2CAP-Kanäle (CoC) über Bluetooth Low Energy (BLE) verwendet werden. CoC verwendet einen elastischen Puffer von mehreren Audiopaketen, um einen gleichmäßigen Audiofluss aufrechtzuerhalten, auch bei Paketverlust. Dieser Puffer sorgt für eine gute Audioqualität für Hörgeräte, allerdings auf Kosten der Latenz.

Das Design des CoC bezieht sich auf die Bluetooth (BT) Core Specification Version 6.0. Um den Kernspezifikationen zu entsprechen, müssen alle Mehrbyte-Werte auf dieser Seite als Little-Endian gelesen werden.

Terminologie

zentral

Das Android-Gerät, das über Bluetooth nach Werbung sucht.

Peripheriegerät

Das Hörgerät, das Werbepakete über Bluetooth sendet.

Netzwerktopologie und Systemarchitektur

Bei der Verwendung von CoC für Hörgeräte wird in der Netzwerktopologie ein einzelnes zentrales Gerät und zwei Peripheriegeräte (eines links und eines rechts) angenommen, wie in Abbildung 1 dargestellt. Das Bluetooth-Audiosystem betrachtet die linken und rechten Peripheriegeräte als eine einzige Audio-Senke. Wenn ein Peripheriegerät aufgrund einer monauralen Anpassung oder eines Verbindungsverlusts fehlt, mischt das zentrale Gerät den linken und rechten Audio-Kanal und überträgt den Ton an das verbleibende Peripheriegerät. Wenn die Zentrale die Verbindung zu beiden Peripheriegeräten verliert, betrachtet sie die Verbindung zur Audio-Senke als unterbrochen. In diesen Fällen leitet die Zentrale Audio an einen anderen Ausgang weiter.

Abbildung 1. Topologie für das Koppeln von Hörgeräten mit Android-Mobilgeräten über CoC über BLE.

Wenn das zentrale Gerät keine Audiodaten an das Peripheriegerät streamt und eine BLE-Verbindung aufrechterhalten kann, sollte es die Verbindung zum Peripheriegerät nicht trennen. Durch die Aufrechterhaltung der Verbindung wird die Datenkommunikation mit dem GATT-Server auf dem Peripheriegerät ermöglicht.

Beim Koppeln und Verbinden von Hörgeräten muss die Zentrale Folgendes tun:

• Behalten Sie den Überblick über die zuletzt gekoppelten linken und rechten Peripheriegeräte.
• Gehen Sie davon aus, dass die Peripheriegeräte verwendet werden, wenn eine gültige Kopplung vorhanden ist. Die Zentrale muss versuchen, eine Verbindung zum gekoppelten Gerät herzustellen oder die Verbindung wiederherzustellen, wenn die Verbindung unterbrochen wird.
• Wenn eine Kopplung gelöscht wird, wird davon ausgegangen, dass die Peripheriegeräte nicht mehr verwendet werden.

In den oben genannten Fällen bezieht sich die Kopplung auf die Registrierung eines Hörgeräts mit einer bestimmten UUID und Kennzeichnungen für links/rechts im Betriebssystem und nicht auf den Bluetooth-Kopplungsvorgang.

Systemanforderungen

Damit CoC für eine gute Nutzererfahrung richtig implementiert wird, müssen die Bluetooth-Systeme in den zentralen und peripheren Geräten Folgendes tun:

• Implementieren Sie einen kompatiblen Controller mit BT 4.2 oder höher. Wir empfehlen dringend LE Secure Connections.
• Unterstützung von mindestens zwei gleichzeitigen LE-Verbindungen auf dem zentralen Gerät mit Parametern, die in Audio-Paketformat und ‑Timing beschrieben sind.
• Unterstütze mindestens eine LE-Verbindung auf dem Peripheriegerät mit den in Audio-Paketformat und ‑Timing beschriebenen Parametern.
• Unterstützung einer Durchflusssteuerung auf Grundlage von LE-Guthaben [BT Vol. 3, Part A, Sec. 10.1]. Geräte müssen eine MTU- und MPS-Größe von mindestens 167 Byte auf CoC unterstützen und bis zu acht Pakete puffern können.
• Unterstützung einer LE-Datenlängen-Erweiterung [BT Vol 6, Part B, Sec 5.1.9] mit einer Nutzlast von mindestens 167 Byte.
• Das zentrale Gerät muss den HCI LE Connection Update Command unterstützen und die Parameter maximum_CE_Length und minimum_CE_Length dürfen nicht null sein.
• Aufrechterhaltung des Datendurchsatzes auf dem zentralen Gerät für zwei LE CoC-Verbindungen zu zwei verschiedenen Peripheriegeräten mit den Verbindungsintervallen und Nutzlastgrößen in Audio-Paketformat und ‑Timing.
• Legen Sie die Parameter MaxRxOctets und MaxRxTime in den Frames LL_LENGTH_REQ oder LL_LENGTH_RSP auf dem Peripheriegerät auf die kleinsten erforderlichen Werte fest, die für diese Spezifikationen erforderlich sind. So kann die Zentraleinheit ihren Zeitplan optimieren, wenn sie die Zeit berechnet, die zum Empfangen eines Frames benötigt wird.

Wir empfehlen dringend, dass das zentrale und das periphere Gerät den 2M PHY unterstützen, wie in der BT 5.0-Spezifikation angegeben. Das zentrale Gerät muss Audioverbindungen mit mindestens 64 kbit/s auf 1M- und 2M-PHYs unterstützen. Der BLE-PHY mit großer Reichweite darf nicht verwendet werden.

CoC verwendet die standardmäßigen Bluetooth-Mechanismen für die Verschlüsselung der Verbindungsschicht und das Frequency Hopping.

ASHA-GATT-Dienste

Ein Peripheriegerät muss den unten beschriebenen GATT-Serverservice für ASHA (Audio Streaming for Hearing Aid) implementieren. Das Peripheriegerät muss diesen Dienst im Modus „Allgemein auffindbar“ bewerben, damit das zentrale Gerät eine Audio-Senke erkennen kann. Alle LE Audio-Streamingvorgänge müssen verschlüsselt werden. Das BLE-Audiostreaming hat die folgenden Merkmale:

Merkmal	Properties	Beschreibung
ReadOnlyProperties	Lesen	Weitere Informationen finden Sie unter ReadOnlyProperties.
AudioControlPoint	Schreiben und schreiben ohne Antwort	Kontrollpunkt für Audiostream. Weitere Informationen finden Sie unter AudioControlPoint.
AudioStatusPoint	Lesen/Benachrichtigen	Statusberichtsfeld für den Audio-Kontrollpunkt. Weitere Informationen finden Sie unter AudioStatusPoint.
Volume	Schreiben ohne Antwort	Byte zwischen -128 und 0, das die Stärke der Dämpfung angibt, die auf das gestreamte Audiosignal angewendet werden soll. Der Bereich reicht von -48 dB bis 0 dB. Der Wert -128 muss als vollständig stummgeschaltet interpretiert werden.Der niedrigste nicht stummgeschaltete Lautstärkepegel ist -127, was einer Dämpfung von -47, 625 dB entspricht. Bei Einstellung 0 muss ein gestreamter Rail-to-Rail-Sinuston einem Eingang von 100 dBSPL auf dem Hörgerät entsprechen. Das zentrale Gerät muss in nominalem Vollbereich streamen und diese Variable verwenden, um die gewünschte Darstellungsebene auf dem Peripheriegerät festzulegen.
LE_PSM_OUT	Lesen	PSM, das zum Verbinden des Audio-Channels verwendet werden soll. aus dem dynamischen Bereich [BT Vol 3, Part A, Sec 4.22] ausgewählt werden.

In den folgenden Tabellen werden die dem Dienst zugewiesenen UUIDs und ihre Merkmale beschrieben.

Dienst-UUID:{0xFDF0}

Merkmal	UUID
ReadOnlyProperties	{6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint	{f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
AudioStatus	{38663f1a-e711-4cac-b641-326b56404837}
Volume	{00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT	{2d410339-82b6-42aa-b34e-e2e01df8cc1a}

Zusätzlich zum ASHA GATT-Dienst muss das Peripheriegerät auch den Geräteinformationsdienst implementieren, damit das zentrale Gerät die Herstellernamen und Gerätenamen des Peripheriegeräts erkennen kann.

ReadOnlyProperties

ReadOnlyProperties hat die folgenden Werte:

Byte	Beschreibung
0	Version – muss 0x01 sein
1	Weitere Informationen finden Sie unter DeviceCapabilities.
2-9	Weitere Informationen finden Sie unter HiSyncId.
10	Weitere Informationen finden Sie unter FeatureMap.
11-12	RenderDelay. Die Zeit in Millisekunden, die vergeht, bis das Peripheriegerät die Ausgabe rendert, nachdem es einen Audio-Frame empfangen hat. Mit diesen Bytes kann ein Video verzögert werden, um es mit dem Audio zu synchronisieren.
13-14	Reserviert für zukünftige Verwendung. Mit Nullen initialisieren.
15-16	Unterstützte Codec-IDs. Dies ist eine Bitmaske der unterstützten Codec-IDs. Eine 1 an einer Bitposition entspricht einem unterstützten Codec. 0x0002 gibt beispielsweise an, dass G.722 bei 16 kHz unterstützt wird. Alle anderen Bits müssen auf 0 gesetzt werden.

DeviceCapabilities

Bit	Beschreibung
0	Geräteseite (0: links, 1: rechts)
1	Gibt an, ob das Gerät eigenständig ist und Monodaten empfängt oder ob es Teil eines Sets ist (0: monaural, 1: binaural).
2	Gerät unterstützt CSIS (0: nicht unterstützt, 1: unterstützt)
3-7	Reserviert (auf 0 gesetzt)

HiSyncId

Dieses Feld muss für alle binauralen Geräte eindeutig sein, aber für das linke und rechte Set gleich sein.

Byte	Beschreibung
0-1	ID des Herstellers. Dies ist die von BTSIG zugewiesene Unternehmens-ID.
2-7	Eindeutige ID zur Identifizierung des Hörgeräts. Diese ID muss sowohl für die linke als auch für die rechte Peripherie auf denselben Wert festgelegt werden.

FeatureMap

Bit	Beschreibung
0	Unterstützung von LE CoC-Audiostreaming (Ja/Nein).
1-7	Reserviert (auf 0 gesetzt).

Codec-IDs

Wenn das Bit gesetzt ist, wird der entsprechende Codec unterstützt.

ID / Bitnummer	Codec und Samplerate	Erforderliche Bitrate	Frame Time	Obligatorisch für zentral (C) oder peripher (P)
0	Reserviert	Reserviert	Reserviert	Reserviert
1	G.722 bei 16 kHz	64 kBit/s	Variable	C und P
2–15 sind reserviert.

AudioControlPoint

Dieser Kontrollpunkt kann nicht verwendet werden, wenn die LE CoC geschlossen ist. Eine Beschreibung des Verfahrens finden Sie unter Audiostream starten und beenden.

Opcode	Argumente	GATT-Unterprozedur	Beschreibung
1 «Start»	uint8_t codec uint8_t audiotype int8_t volume int8_t otherstate	Schreiben Sie mit Antwort und erwarten Sie eine zusätzliche Statusbenachrichtigung mit dem Merkmal AudioStatusPoint.	Weist das Peripheriegerät an, den Codec zurückzusetzen und die Wiedergabe von Frame 0 zu starten. Das Feld codec gibt die Codec-ID an, die für diese Wiedergabe verwendet werden soll. Das Feld codec ist beispielsweise „1“ für G.722 bei 16 kHz. Das Bitfeld für den Audiotyp gibt die im Stream vorhandenen Audiotypen an: 0: Unbekannt 1: Klingelton 2 – Anruf 3 – Media Das Feld otherstate gibt an, ob die andere Seite der binauralen Geräte verbunden ist. Der Feldwert ist 1, wenn das andere Peripheriegerät verbunden ist, andernfalls ist der Wert 0. Das Peripheriegerät darf keine Verbindungsupdates anfordern, bevor ein «Stop»-Opcode empfangen wurde.
2 «Stop»	Keine	Schreiben Sie mit Antwort und erwarten Sie eine zusätzliche Statusbenachrichtigung mit dem Merkmal AudioStatusPoint.	Weist das Peripheriegerät an, die Audiowiedergabe zu beenden. Nach diesem Stopp muss eine neue Audioeinrichtungssequenz gestartet werden, damit wieder Audio gerendert wird.
3 «Status»	uint8_t connected	Schreiben ohne Antwort	Informiert das verbundene Peripheriegerät darüber, dass es ein Statusupdate für das andere Peripheriegerät gibt. Das Feld connected gibt den Typ der Aktualisierung an: 0 – Anderes Peripheriegerät getrennt 1 – Anderes Peripheriegerät angeschlossen 2 – Bei einer der beiden Verbindungen ist eine Aktualisierung der LE-Verbindungsparameter aufgetreten.

AudioStatusPoint

Statusberichtsfeld für den Audiosteuerungspunkt

Opcodes	Beschreibung
0	Status: OK
-1	Unbekannter Befehl
-2	Illegale Parameter

Werbung für den ASHA-GATT-Dienst

Die Dienst-UUID muss im Werbepaket enthalten sein. Sowohl in der Anzeige als auch im Frame der Scanantwort müssen die Peripheriegeräte einen Dienstdatentyp haben:

Byte-Offset	Name	Beschreibung
0	AD-Länge	>= 0x09
1	AD-Typ	0x16 (Dienstdaten – 16-Bit-UUID)
2–3	Dienst-UUID	0xFDF0 (Little-Endian) Hinweis:Dies ist eine temporäre ID.
4	Protokollversion	0x01
5	Berechtigung	0 – linke (0) oder rechte (1) Seite 1 – Einzelgerät (0) oder zwei Geräte (1). 2 – Gerät unterstützt CSIS (<0: nicht unterstützt, 1: unterstützt) 3–7 – reserviert. Diese Bits müssen null sein.
6-9	Abgekürzt: HiSyncId	Die vier wichtigsten Bytes der HiSyncId. Diese Bytes müssen der zufälligste Teil der ID sein.

Die Peripheriegeräte müssen einen Datentyp Complete Local Name haben, der den Namen des Hörgeräts angibt. Dieser Name wird in der Benutzeroberfläche des Mobilgeräts verwendet, damit der Nutzer das richtige Gerät auswählen kann. Der Name darf nicht den linken oder rechten Kanal angeben, da diese Informationen in DeviceCapabilities enthalten sind.

Wenn die Peripheriegeräte den Namen und die ASHA-Dienstdatentypen im selben Frame-Typ (ADV oder SCAN RESP) platzieren, müssen die beiden Datentypen („Complete Local Name“ und „Service Data for ASHA service“) im selben Frame enthalten sein. So kann der Scanner des Mobilgeräts beide Daten in einem Scanergebnis erfassen.

Beim ersten Koppeln ist es wichtig, dass die Peripheriegeräte schnell genug werben, damit das Mobilgerät sie schnell erkennen und eine Verbindung herstellen kann.

Linke und rechte Peripheriegeräte synchronisieren

Damit Bluetooth auf Android-Mobilgeräten funktioniert, müssen Peripheriegeräte für die Synchronisierung sorgen. Die Wiedergabe auf den linken und rechten Peripheriegeräten muss zeitlich synchronisiert werden. Beide Peripheriegeräte müssen gleichzeitig Audio-Samples von der Quelle wiedergeben.

Peripheriegeräte können ihre Zeit mithilfe einer Sequenznummer synchronisieren, die jedem Paket der Audio-Nutzlast vorangestellt wird. Die zentrale Einheit sorgt dafür, dass Audiopakete, die gleichzeitig auf jedem Peripheriegerät wiedergegeben werden sollen, dieselbe Sequenznummer haben. Die Sequenznummer wird nach jedem Audiopaket um eins erhöht. Jede Sequenznummer ist 8 Bit lang. Die Sequenznummern werden also nach 256 Audiopaketen wiederholt. Da die Größe der einzelnen Audiopakete und die Samplerate für jede Verbindung festgelegt sind, können die beiden Peripheriegeräte die relative Wiedergabezeit ableiten. Weitere Informationen zum Audiopaket finden Sie unter Audiopaketformat und ‑timing.

Das zentrale Gerät unterstützt die Synchronisierung, indem es Trigger an die binauralen Geräte sendet, wenn eine Synchronisierung erforderlich sein könnte. Diese Trigger informieren jedes Peripheriegerät über den Status des gekoppelten Peripheriegeräts, wenn ein Vorgang ausgeführt wird, der sich auf die Synchronisierung auswirken kann. Die Trigger sind:

• Im Rahmen des «Start»-Befehls von AudioControlPoint wird der aktuelle Verbindungsstatus der anderen Seite der binauralen Geräte angegeben.
• Immer wenn ein Vorgang zum Herstellen, Trennen oder Aktualisieren von Verbindungsparametern auf einem Peripheriegerät ausgeführt wird, wird der «Status»-Befehl von AudioControlPoint an die andere Seite der binauralen Geräte gesendet.

Audio-Paketformat und ‑Timing

Durch das Verpacken von Audio-Frames (Blöcken von Samples) in Pakete kann das Hörgerät das Timing von den Timing-Ankern der Link-Schicht ableiten. Um die Implementierung zu vereinfachen:

• Ein Audio-Frame sollte immer mit dem Verbindungsintervall übereinstimmen. Wenn das Verbindungsintervall beispielsweise 20 ms und die Abtastrate 16 kHz beträgt, muss der Audio-Frame 320 Samples enthalten.
• Die Abtastraten im System sind auf Vielfache von 8 kHz beschränkt, damit in einem Frame immer eine ganzzahlige Anzahl von Stichproben vorhanden ist, unabhängig von der Frame-Zeit oder dem Verbindungsintervall.
• Audio-Frames muss ein Sequenzbyte vorangestellt werden. Das Sequenzbyte muss mit Wrap-around zählen und es dem Peripheriegerät ermöglichen, Pufferabweichungen oder ‑unterläufe zu erkennen.
• Ein Audio-Frame muss immer in ein einzelnes LE-Paket passen. Der Audio-Frame muss als separates L2CAP-Paket gesendet werden. Die Größe der LE LL-PDU muss Folgendes sein:
  Größe der Audio-Nutzlast + 1 (Sequenzzähler) + 6 (4 für L2CAP-Header, 2 für SDU)
• Ein Verbindungsereignis sollte immer groß genug sein, um zwei Audiopakete und zwei leere Pakete für eine Bestätigung (ACK) zu enthalten, damit Bandbreite für erneute Übertragungen reserviert wird. Das Audiopaket kann vom Bluetooth-Controller des Hub fragmentiert werden. Das Peripheriegerät muss mehr als zwei fragmentierte Audiopakete pro Verbindungsereignis empfangen können.

Um der Zentrale etwas Flexibilität zu geben, ist die G.722-Paketlänge nicht angegeben. Die Paketlänge von G.722 kann sich je nach vom zentralen Gerät festgelegtem Verbindungsintervall ändern.

Das Oktettformat der G.722-Ausgabe bezieht sich auf Abschnitt 1.4.4 „Multiplexer“ von ITU-T G.722 (09/2012).

Für alle Codecs, die von einem Peripheriegerät unterstützt werden, muss das Peripheriegerät die folgenden Verbindungsparameter unterstützen. Dies ist eine unvollständige Liste der Konfigurationen, die die Zentrale implementieren kann.

Codec	Bitrate	Verbindungsintervall	Länge des Verbindungselements (1 M/2 M PHY)	Größe der Audio-Nutzlast
G.722 bei 16 kHz	64 kBit/s	20 ms	5.000/3.750 µs	160 Byte

Audiostream starten und beenden

Bevor ein Audiostream gestartet wird, fragt das zentrale Gerät die Peripheriegeräte ab und legt einen gemeinsamen Codec fest. Die Einrichtung des Streams erfolgt dann in der folgenden Reihenfolge:

1. PSM und optional RenderDelay werden gelesen. Diese Werte können vom zentralen System zwischengespeichert werden.
2. Der CoC-L2CAP-Channel wird geöffnet – das Peripheriegerät muss anfangs acht Credits gewähren.
3. Es wird eine Verbindungsaktualisierung ausgegeben, um den Link auf die für den ausgewählten Codec erforderlichen Parameter umzustellen. Die Zentrale kann diese Verbindungsaktualisierung vor der CoC-Verbindung im vorherigen Schritt durchführen.
4. Sowohl der zentrale als auch der periphere Host warten auf das Ereignis „Update abgeschlossen“.
5. Starten Sie den Audio-Encoder neu und setzen Sie die Paketfolgennummer auf 0 zurück. Auf AudioControlPoint wird ein «Start»-Befehl mit den relevanten Parametern ausgegeben. Die Zentrale wartet auf eine Benachrichtigung mit dem Status „Erfolgreich“ für den vorherigen «Start»-Befehl vom Peripheriegerät, bevor sie mit dem Streamen beginnt. Durch diese Wartezeit hat das Peripheriegerät Zeit, die Audiowiedergabe-Pipeline vorzubereiten. Während des Audiostreamings sollte das Replikat bei jedem Verbindungsereignis verfügbar sein, auch wenn die aktuelle Replikatlatenz ungleich null ist.
6. Das Peripheriegerät nimmt das erste Audiopaket aus seinem internen Warteschlange (Sequenznummer 0) und spielt es ab.

Die Zentrale gibt den Befehl «Stop» aus, um den Audiostream zu schließen. Nach diesem Befehl muss das Peripheriegerät nicht bei jedem Verbindungsereignis verfügbar sein. Wenn Sie das Audiostreaming neu starten möchten, führen Sie die oben beschriebene Abfolge ab Schritt 5 aus. Wenn das zentrale Gerät kein Audio streamt, sollte es trotzdem eine LE-Verbindung für GATT-Dienste aufrechterhalten.

Das Peripheriegerät darf keine Verbindungsaktualisierung an das zentrale Gerät senden. Um Strom zu sparen, kann das zentrale Gerät eine Verbindungsaktualisierung an das Peripheriegerät senden, wenn kein Audio gestreamt wird.