Hörgeräte können auf Android-Mobilgeräten eine verbesserte Barrierefreiheit bieten, indem sie verbindungsorientierte L2CAP-Kanäle (CoC) über Bluetooth Low Energy (BLE) verwenden. 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 CoC-Design bezieht sich auf die Bluetooth Core Specification Version 5 (BT). 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 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 werden kann, müssen die Bluetooth-Systeme in den zentralen und peripheren Geräten folgende Anforderungen erfüllen:
- einen kompatiblen Controller mit BT 4.2 oder höher implementieren. LE Secure Connections wird dringend empfohlen.
- Der zentrale Support muss mindestens zwei gleichzeitige LE-Verbindungen mit Parametern wie in Audio-Paketformat und ‑Timing beschrieben unterstützen.
- Das Peripheriegerät muss mindestens eine LE-Verbindung mit den in Audio-Paketformat und ‑Timing beschriebenen Parametern unterstützen.
- eine LE-Guthaben-basierte Flusssteuerung haben [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 8 Pakete puffern können.
- eine LE-Datenlängen-Erweiterung [BT Vol 6, Part B, Sec 5.1.9] mit einer Nutzlast von mindestens 167 Byte haben.
-
Das zentrale Gerät muss den HCI LE Connection Update Command unterstützen und die Parameter
maximum_CE_Lengthundminimum_CE_Lengthmüssen ungleich null sein. - Der Central muss den Datendurchsatz für zwei LE CoC-Verbindungen zu zwei verschiedenen Peripheriegeräten mit den Verbindungsintervallen und Nutzlastgrößen in Audio packet format and timing (Audio-Paketformat und ‑Timing) aufrechterhalten.
-
Das Peripheriegerät muss die Parameter
MaxRxOctetsundMaxRxTimein den FramesLL_LENGTH_REQoderLL_LENGTH_RSPauf die kleinsten erforderlichen Werte festlegen, 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.
Es wird dringend empfohlen, dass das zentrale und das periphere Gerät den 2 MB 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. Siehe AudioControlPoint. |
| AudioStatusPoint | Lesen/Benachrichtigen | Statusberichtsfeld für den Audio-Kontrollpunkt. Siehe AudioStatusPoint. |
| Lautstärke | Ohne Antwort schreiben | 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] |
Die dem Dienst und den Merkmalen zugewiesenen UUIDs:
Service-UUID: {0xFDF0}
| Merkmal | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| Lautstärke | {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 haben die folgenden Werte:
| Byte | Beschreibung |
|---|---|
| 0 | Version – muss 0x01 sein |
| 1 | Weitere Informationen finden Sie unter DeviceCapabilities. |
| 2-9 | Siehe 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. Es handelt sich um die von BTSIG zugewiesenen Unternehmenskennungen. |
| 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. 0 ist ebenfalls 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» |
|
Schreiben Sie mit Antwort und erwarten Sie eine zusätzliche Statusbenachrichtigung über das Attribut 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 Codec-Feld ist beispielsweise „1“ für G.722 bei 16 kHz. Das Bitfeld für den Audiotyp gibt den/die im Stream vorhandenen Audiotyp(en) an:
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 über das Attribut AudioStatusPoint. | Weist das Peripheriegerät an, die Audiowiedergabe zu beenden. Nach diesem Stopp sollte eine neue Audioeinrichtungssequenz gestartet werden, damit Audio wieder gerendert wird. |
3 «Status» |
|
Schreiben ohne Antwort |
Informiert das verbundene Peripheriegerät darüber, dass es ein Statusupdate für das andere Peripheriegerät gibt. Das verbundene Feld gibt den Typ der Aktualisierung an:
|
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 für die Scanantwort müssen die Peripheriegeräte Dienstdaten haben:
| Byte-Offset | Name | Beschreibung |
|---|---|---|
| 0 | Anzeigenlänge | >= 0x09 |
| 1 | AD-Typ | 0x16 (Service Data – 16-bit UUID) |
| 2–3 | Dienst-UUID |
0xFDF0 (Little-Endian) Hinweis:Dies ist eine temporäre ID. |
| 4 | Protokollversion | 0x01 |
| 5 | Berechtigung |
|
| 6-9 | Abgekürzte HiSyncID | Die vier wichtigsten Bytes der HiSyncId. Diese Bytes sollten 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 angegeben werden.
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.
Während des ersten Pairings ist es wichtig, dass die Peripheriegeräte schnell genug werben, damit das Mobilgerät sie schnell erkennen und eine Verbindung zu ihnen 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 Abtastrate 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 ist. 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 Überlauf 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 2 Audiopakete und 2 leere Pakete für ein ACK zu enthalten, damit Bandbreite für Neuü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 G.722-Ausgabeoktettformat bezieht sich auf Rec. ITU-T G.722 (09/2012), Abschnitt 1.4.4 „Multiplexer“.
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:
- PSM und optional RenderDelay werden gelesen. Diese Werte können vom zentralen System zwischengespeichert werden.
- Der CoC L2CAP-Channel wird geöffnet – das Peripheriegerät muss anfangs 8 Credits gewähren.
- 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.
- Sowohl der zentrale als auch der periphere Host warten auf das Ereignis „Update abgeschlossen“.
-
Starten Sie den Audio-Encoder neu und setzen Sie die Paketfolgennummer auf 0 zurück.
Auf dem AudioControlPoint wird ein
«Start»-Befehl mit den relevanten Parametern ausgegeben. Die Zentrale wartet vor dem Streamen auf eine erfolgreiche Statusbenachrichtigung des vorherigen«Start»-Befehls vom Peripheriegerät. 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. - 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 die Zentrale keine Audioinhalte streamt, sollte sie 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.