Die Barrierefreiheit von Hörgeräten auf Android-Mobilgeräten kann durch die Verwendung verbindungsorientierter L2CAP-Kanäle (CoC) über Bluetooth Low Energy (BLE) verbessert werden. CoC verwendet einen elastischen Puffer mit mehreren Audiopaketen, um einen gleichmäßigen Audiofluss aufrechtzuerhalten, auch bei Paketverlust. Dieser Puffer bietet Audioqualität für Hörgeräte, allerdings auf Kosten der Latenz.
Das Design von CoC bezieht sich auf die Bluetooth Core Specification Version 5 (BT). Gemäß den Hauptspezifikationen müssen alle mehrbyteigen Werte auf dieser Seite im Little-Endian-Format gelesen werden.
Terminologie
- Central: Das Android-Gerät, das über Bluetooth nach Anzeigen 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, vorausgesetzt, wie in Abbildung 1 dargestellt. Das Bluetooth-Audiosystem betrachtet die linken und rechten Peripheriegeräte als einen einzelnen Audio-Sink. Wenn ein Peripheriegerät aufgrund eines Mono-Anschlusses oder Verbindungsverlusts fehlt, mischt die Zentrale den linken und rechten Audiokanal und überträgt den Audiostream an das verbleibende Peripheriegerät. Wenn die Zentrale die Verbindung zu beiden Peripheriegeräten verliert, betrachtet sie die Verbindung zum Audio-Sink als verloren. In diesen Fällen leitet die Zentrale Audio an eine andere Ausgabe weiter.
Abbildung 1 Topologie zum Koppeln von Hörgeräten mit Android-Mobilgeräten über CoC über BLE
Wenn die Steuereinheit keine Audiodaten an das Peripheriegerät streamt und eine BLE-Verbindung aufrechterhalten kann, sollte die Verbindung zwischen Steuereinheit und Peripheriegerät nicht getrennt werden. Durch die Aufrechterhaltung der Verbindung ist die Datenkommunikation mit dem GATT-Server auf dem Peripheriegerät möglich.
Beim Koppeln und Verbinden von Hörgeräten muss die Steuerzentrale:
- Sie können nachverfolgen, welche linken und rechten Peripheriegeräte zuletzt gekoppelt wurden.
- Angenommen, die Peripheriegeräte werden verwendet, wenn eine gültige Kopplung besteht. Die Zentrale versucht, eine Verbindung zum gekoppelten Gerät herzustellen oder wiederherzustellen, wenn die Verbindung unterbrochen wird.
- Angenommen, die Peripheriegeräte werden nicht mehr verwendet, wenn eine Kopplung gelöscht wird.
In den oben genannten Fällen bezieht sich das Koppeln auf die Registrierung einer Reihe von Hörgeräten mit einer bestimmten UUID und den Beschriftungen „links“ und „rechts“ im Betriebssystem, nicht auf den Bluetooth-Kopplungsprozess.
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 BT 4.2- oder höher-Controller implementieren. LE Secure Connections wird dringend empfohlen.
- Die Zentrale muss mindestens zwei gleichzeitige LE-Links mit den unter Audiopaketformat und -Timing beschriebenen Parametern unterstützen.
- Das Peripheriegerät muss mindestens eine LE-Verbindung mit den unter Audiopaketformat und -timing beschriebenen Parametern unterstützen.
- eine LE-Guthabenbasierte Verkehrssteuerung haben [BT Band 3, Teil A, Abschnitt 10.1]. Geräte müssen eine MTU und MPS-Größe von mindestens 167 Byte bei CoC unterstützen und bis zu 8 Pakete puffern können.
- eine LE-Datenlängenerweiterung [BT Band 6, Teil B, Abschnitt 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 einen Wert ungleich null haben. - Die Zentrale muss den Datendurchsatz für zwei LE CoC-Verbindungen zu zwei verschiedenen Peripheriegeräten mit den Verbindungsintervallen und Nutzlastgrößen im Audiopaketformat und -Timing aufrechterhalten.
-
Der Peripherie muss die Parameter
MaxRxOctetsundMaxRxTimein denLL_LENGTH_REQ- oderLL_LENGTH_RSP-Frames auf die kleinsten erforderlichen Werte festlegen, die für diese Spezifikationen erforderlich sind. So kann die zentrale Einheit den Zeitplaner optimieren, wenn sie die Zeit berechnet, die zum Empfangen eines Frames benötigt wird.
Es wird dringend empfohlen, dass die zentrale und die periphere Einheit 2 MB PHY gemäß der BT 5.0-Spezifikation unterstützen. Die Zentrale muss Audio-Links mit mindestens 64 kbit/s sowohl auf 1‑Mbit- als auch auf 2‑Mbit-PHYs unterstützen. Der BLE Long Range PHY darf nicht verwendet werden.
CoC verwendet die standardmäßigen Bluetooth-Mechanismen für die Verschlüsselung der Sicherungsschicht und das Frequenzhopping.
ASHA GATT-Dienste
Ein Peripheriegerät muss den unten beschriebenen GATT-Serverdienst „Audio Streaming for Hearing Aid“ (ASHA) implementieren. Das Peripheriegerät muss diesen Dienst angeben, wenn es sich im allgemeinen Erkennungsmodus befindet, damit die Zentrale einen Audio-Sink erkennen kann. Für alle LE Audio-Streaming-Vorgänge ist eine Verschlüsselung erforderlich. Das BLE-Audiostreaming hat folgende Merkmale:
| Merkmal | Properties | Beschreibung |
|---|---|---|
| ReadOnlyProperties | Gelesen | Weitere Informationen finden Sie unter ReadOnlyProperties. |
| AudioControlPoint | „Schreiben“ und „Schreiben, ohne zu antworten“ | Kontrollpunkt für Audiostream. Siehe AudioControlPoint. |
| AudioStatusPoint | Lesen/Benachrichtigen | Statusberichtsfeld für den Audiokontrollpunkt. Siehe AudioStatusPoint. |
| Lautstärke | Schreiben ohne Antwort | Ein Byte zwischen -128 und 0, das die Dämpfung angibt, die auf das gestreamte Audiosignal angewendet werden soll (von -48 dB bis 0 dB). Die Einstellung -128 wird als vollständige Stummschaltung interpretiert. Die niedrigste Lautstärke, bei der die Stummschaltung aufgehoben ist, ist -127, was einer Dämpfung von -47,625 dB entspricht. Bei der Einstellung 0 entspricht ein gestreamter Sinuston von Rail-to-Rail einem Eingangspegel von 100 dB SPL am Hörgerät. Die Zentrale muss im nominalen Vollformat streamen und mit dieser Variablen die gewünschte Darstellungsebene im Peripheriegerät festlegen. |
| LE_PSM_OUT | Gelesen | PSM, das für die Verbindung des Audiokanals verwendet werden soll. Aus dem dynamischen Bereich ausgewählt werden [BT Bd. 3, Teil A, Abschnitt 4.22] |
Die UUIDs, die dem Dienst und den Eigenschaften zugewiesen sind:
Dienst-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 die Zentrale die Hersteller- und Gerätenamen des Peripheriegeräts erkennen kann.
ReadOnlyProperties
ReadOnlyProperties haben die folgenden Werte:
| Byte | Beschreibung |
|---|---|
| 0 | Version – muss 0x01 sein |
| 1 | Siehe DeviceCapabilities. |
| 2-9 | Siehe HiSyncId. |
| 10 | Weitere Informationen finden Sie unter FeatureMap. |
| 11-12 | RenderDelay. Dies ist die Zeit in Millisekunden, die vergeht, bis das Peripheriegerät einen Audioframe empfängt und die Ausgabe rendert. Mit diesen Bytes kann ein Video verzögert werden, um es mit dem Audio zu synchronisieren. |
| 13-14 | Reserviert für zukünftige Verwendung. Sie werden auf Null initialisiert. |
| 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. Beispiel: 0x0002 gibt an, dass G.722 bei 16 kHz unterstützt wird. Alle anderen Bits müssen auf 0 gesetzt sein. |
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: Mono, 1: Binaural) |
| 2 | Gerät unterstützt CSIS (0: nicht unterstützt, 1: unterstützt) |
| 3-7 | Reserviert (auf „0“ festgelegt) |
HiSyncID
Dieses Feld muss für alle binauralen Geräte eindeutig sein, aber für den linken und rechten Satz identisch.
| Byte | Beschreibung |
|---|---|
| 0-1 | ID des Herstellers. Das sind die von BTSIG zugewiesenen Unternehmens-IDs. |
| 2-7 | Die eindeutige ID, mit der das Hörgerät identifiziert wird. Diese ID muss sowohl auf dem linken als auch auf dem rechten Peripheriegerät gleich sein. |
FeatureMap
| Bit | Beschreibung |
|---|---|
| 0 | Wird LE CoC-Audioausgabe-Streaming unterstützt (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 Abtastrate | Erforderliche Bitrate | Frame Time | Erforderlich für zentrale (C) oder periphere (P) |
|---|---|---|---|---|
| 0 | Reserviert | Reserviert | Reserviert | Reserviert |
| 1 | G.722 bei 16 kHz | 64 kBit/s | Variable | C und P |
|
Die Nummern 2–15 sind reserviert. 0 ist ebenfalls reserviert. |
||||
AudioControlPoint
Dieser Kontrollpunkt kann nicht verwendet werden, wenn der LE CoC geschlossen ist. Eine Beschreibung des Verfahrens finden Sie unter Audiostream starten und beenden.
| Opcode | Argumente | GATT-Unterprozedur | Beschreibung |
|---|---|---|---|
1 «Start» |
|
Schreibe mit Antwort und erwarte eine zusätzliche Statusbenachrichtigung über das AudioStatusPoint-Attribut. |
Hiermit wird das Peripheriegerät angewiesen, den Codec zurückzusetzen und die Wiedergabe von Frame 0 zu starten. Das Codec-Feld gibt die Codec-ID an, die für diese Wiedergabe verwendet werden soll.
Für G.722 bei 16 kHz ist das Codec-Feld beispielsweise „1“. Das Bit-Feld für den Audiotyp gibt den Audiotyp bzw. die Audiotypen an, die im Stream vorhanden sind:
Das Peripheriegerät darf keine Verbindungsaktualisierungen anfordern, bevor ein «Stop»-Opcode empfangen wurde.
|
2 «Stop» |
Keine | Schreibe mit Antwort und erwarte eine zusätzliche Statusbenachrichtigung über das AudioStatusPoint-Attribut. | Weist das Peripheriegerät an, das Rendern von Audio zu beenden. Nach diesem Stopp sollte eine neue Audioeinrichtungssequenz gestartet werden, um Audio wieder zu rendern. |
3 «Status» |
|
Ohne Antwort schreiben |
Informiert das verbundene Peripheriegerät darüber, dass es ein Statusupdate für das andere Peripheriegerät gibt. Das verbundene Feld gibt die Art der Aktualisierung an:
|
AudioStatusPoint
Statusberichtsfeld für den Audiokontrollpunkt
| Opcodes | Beschreibung |
|---|---|
| 0 | Status OK |
| -1 | Unbekannter Befehl |
| -2 | Unzulässige Parameter |
Werbung für ASHA-GATT-Dienst
Die Dienst-UUID muss im Werbepaket enthalten sein. Entweder in der Anzeige oder im Scan-Antwortframe müssen die Peripheriegeräte Servicedaten enthalten:
| Byte-Offset | Name | Beschreibung |
|---|---|---|
| 0 | Anzeigenlänge | >= 0x09 |
| 1 | Anzeigentyp | 0x16 (Dienstdaten – 16-Bit-UUID) |
| 2–3 | Dienst-UUID |
0xFDF0 (Little Endian) Hinweis:Dies ist eine temporäre ID. |
| 4 | Protokollversion | 0x01 |
| 5 | Funktion |
|
| 6-9 | Abgeschnittene HiSyncID | Die vier signifikantesten Bytes der HiSyncId. Diese Bytes sollten der zufälligste Teil der ID sein. |
Die Peripheriegeräte müssen den Datentyp Complete Local Name (Vollständiger lokaler Name) haben, der den Namen des Hörgeräts angibt. Dieser Name wird auf der Benutzeroberfläche des Mobilgeräts verwendet, damit der Nutzer das richtige Gerät auswählen kann. Der Name darf nicht auf den linken oder rechten Kanal hinweisen, da diese Informationen in DeviceCapabilities angegeben werden.
Wenn die Peripheriegeräte den Namen und die Datentypen des ASHA-Dienstes in denselben Frame-Typ (ADV oder SCAN RESP) einfügen, müssen die beiden Datentypen („Complete Local Name“ und „Service Data for ASHA service“) im selben Frame erscheinen. So kann der Scanner für Mobilgeräte beide Daten im selben Scanergebnis abrufen.
Während der Erstkopplung ist es wichtig, dass die Peripheriegeräte schnell genug werben, damit das Mobilgerät sie schnell erkennt und eine Verbindung herstellen kann.
Linke und rechte Peripheriegeräte synchronisieren
Damit Bluetooth auf Android-Mobilgeräten funktioniert, müssen Peripheriegeräte synchronisiert werden. Die Wiedergabe auf dem linken und rechten Peripheriegerät muss zeitlich synchronisiert sein. Beide Peripheriegeräte müssen Audio-Samples aus der Quelle gleichzeitig wiedergeben.
Peripheriegeräte können ihre Zeit mithilfe einer Sequenznummer synchronisieren, die vor jedem Paket der Audionutzlast eingefügt wird. Die Zentrale sorgt dafür, dass Audiopakete, die gleichzeitig auf jedem Peripheriegerät wiedergegeben werden sollen, dieselbe Sequenznummer haben. Die Sequenznummer erhöht sich nach jedem Audiopaket um eins. Jede Sequenznummer ist 8 Bit lang. Die Sequenznummern werden also nach 256 Audiopaketen wiederholt. Da die Größe und die Abtastrate der Audiopakete für jede Verbindung festgelegt ist, können die beiden Peripheriegeräte die relative Wiedergabezeit ableiten. Weitere Informationen zum Audiopaket findest du unter Audiopaketformat und -timing.
Die Zentrale unterstützt die binauralen Geräte, indem sie ihnen Trigger zur Verfügung stellt, wenn die Synchronisierung erforderlich ist. Diese Trigger informieren jedes Peripheriegerät über den Status seines gekoppelten Peripheriegeräts, wenn ein Vorgang die Synchronisierung beeinträchtigen kann. Die Trigger sind:
-
Im Rahmen des
«Start»-Befehls von AudioControlPoint wird der aktuelle Verbindungsstatus der anderen Seite der binauralen Geräte angegeben. -
Bei einer Verbindung, einer Trennung oder einer Aktualisierung der Verbindungsparameter auf einem Peripheriegerät wird der Befehl
«Status»von AudioControlPoint an die andere Seite der binauralen Geräte gesendet.
Audiopaketformat und -timing
Durch das Packen von Audioframes (Stichprobenblöcken) in Pakete kann das Hörgerät das Timing aus den Zeitankern der Sicherungsschicht ableiten. Zur Vereinfachung der Implementierung:
- Ein Audioframe sollte immer zeitlich mit dem Verbindungsintervall übereinstimmen. Wenn das Verbindungsintervall beispielsweise 20 ms und die Abtastrate 16 kHz beträgt, muss der Audioframe 320 Stichproben enthalten.
- Die Abtastraten im System sind auf Vielfache von 8 kHz beschränkt, damit unabhängig von der Framezeit oder dem Verbindungsintervall immer eine ganze Anzahl von Samples in einem Frame vorhanden ist.
- Audioframes müssen mit einem Sequenzbyte beginnen. Das Sequenzbyte muss mit Überlauf zählen und es dem Peripheriegerät ermöglichen, einen Puffer-Mismatch oder einen Unterlauf zu erkennen.
-
Ein Audioframe muss immer in ein einzelnes LE-Paket passen. Der Audioframe muss als separates L2CAP-Paket gesendet werden. Die Größe der LE LL-PDU muss folgendermaßen sein:
Audionutzlastgröße + 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 ein ACK zu enthalten, um Bandbreite für die erneute Übertragung zu reservieren. Das Audiopaket kann vom Bluetooth-Controller der Zentrale fragmentiert werden. Das Peripheriegerät muss mehr als zwei fragmentierte Audiopakete pro Verbindungsereignis empfangen können.
Um der Zentrale etwas Flexibilität zu bieten, wird die G.722-Paketlänge nicht angegeben. Die G.722-Paketlänge kann sich je nach dem vom Zentralgerät festgelegten Verbindungsintervall ändern.
Das G.722-Oktettausgabeformat bezieht sich auf den Abschnitt 1.4.4 „Multiplexer“ der Rec. ITU-T G.722 (09/2012).
Für alle Codecs, die ein Peripheriegerät unterstützt, 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 | CE-Länge (1M/2M PHY) | Größe der Audionutzlast |
|---|---|---|---|---|
| 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 die Zentrale die Peripheriegeräte ab und stellt einen gemeinsamen Codec her. Die Streameinrichtung verläuft dann in der folgenden Reihenfolge:
- PSM und optional RenderDelay werden gelesen. Diese Werte werden möglicherweise vom Zentralgerät im Cache gespeichert.
- CoC-L2CAP-Kanal wird geöffnet – das Peripheriegerät gewährt anfangs 8 Guthabenpunkte.
- Es wird eine Verbindungsaktualisierung durchgeführt, 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 ausführen.
- Sowohl der zentrale als auch der periphere Host warten auf das Ereignis „Update complete“.
-
Starte den Audioencoder neu und setze die Paketsequenzzählung auf 0 zurück.
Ein
«Start»-Befehl mit den relevanten Parametern wird an den Audio-Kontrollpunkt gesendet. Die Zentrale wartet vor dem Streaming auf eine Statusbenachrichtigung über den erfolgreichen Abschluss des vorherigen«Start»-Befehls vom Peripheriegerät. Dadurch hat das Peripheriegerät Zeit, seine Audiowiedergabepipeline vorzubereiten. Während des Audiostreams sollte das Replikat bei jedem Verbindungsereignis verfügbar sein, auch wenn die aktuelle Replikatlatenz nicht null ist. - Das Peripheriegerät nimmt das erste Audiopaket aus seiner internen Warteschlange (Sequenznummer 0) und spielt es ab.
Die Zentrale gibt den Befehl „Stopp“ 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, wiederholen Sie die oben genannten Schritte ab Schritt 5. Wenn die Steuereinheit kein Audio streamt, sollte sie dennoch eine LE-Verbindung für GATT-Dienste aufrechterhalten.
Das Peripheriegerät darf keine Verbindungsaktualisierung an die Zentrale senden. Um Strom zu sparen, kann die Zentrale eine Verbindungsaktualisierung an das Peripheriegerät senden, wenn kein Audio gestreamt wird.