Audiounterstützung für Hörgeräte mit Bluetooth LE

Hörgeräte (HA) können auf Android-betriebenen Mobilgeräten durch die Verwendung verbindungsorientierter L2CAP-Kanäle (CoC) über Bluetooth Low Energy (BLE) besser zugänglich sein. CoC verwendet einen elastischen Puffer aus mehreren Audiopaketen, um selbst bei Paketverlusten einen stetigen Audiofluss aufrechtzuerhalten. Dieser Puffer bietet Audioqualität für Hörgeräte auf Kosten der Latenz.

Das Design von CoC referenziert die Bluetooth Core Specification Version 5 (BT). Um an den Kernspezifikationen ausgerichtet zu bleiben, werden alle Multibyte-Werte auf dieser Seite als Little-Endian gelesen.

Terminologie

• Central – das Android-Gerät, das über Bluetooth nach Werbung sucht.
• Peripherie – das Hörsystem, das Werbepakete über Bluetooth sendet.

Netzwerktopologie und Systemarchitektur

Bei der Verwendung von CoC für Hörgeräte geht die Netzwerktopologie von einem einzigen zentralen und zwei Peripheriegeräten aus, eines links und eines rechts, wie in Abbildung 1 zu sehen. Das Bluetooth-Audiosystem betrachtet die linken und rechten Peripheriegeräte als eine einzige Audiosenke. Wenn ein Peripheriegerät aufgrund einer monauralen Anpassung oder eines Verbindungsverlusts fehlt, mischt die Zentrale den linken und rechten Audiokanal und überträgt den Ton an das verbleibende Peripheriegerät. Wenn die Zentrale die Verbindung zu beiden Peripheriegeräten verliert, betrachtet die Zentrale die Verbindung zur Audiosenke als verloren. In diesen Fällen leitet die Zentrale Audio an einen anderen Ausgang weiter.

Abbildung 1. Topologie für die Kopplung von Hörgeräten mit Android-Mobilgeräten unter Verwendung von CoC über BLE

Wenn die Zentrale keine Audiodaten zum Peripheriegerät streamt und eine BLE-Verbindung aufrechterhalten kann, sollte die Zentrale die Verbindung zum Peripheriegerät nicht trennen. Das Aufrechterhalten der Verbindung ermöglicht die Datenkommunikation mit dem GATT-Server, der sich auf dem Peripheriegerät befindet.

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

• Verfolgen Sie die neueren gepaarten linken und rechten Peripheriegeräte.
• Gehen Sie davon aus, dass die Peripheriegeräte verwendet werden, wenn eine gültige Paarung vorhanden ist. Die Zentrale versucht, sich mit dem gekoppelten Gerät zu verbinden oder erneut zu verbinden, wenn die Verbindung unterbrochen wird.
• Gehen Sie davon aus, dass die Peripheriegeräte nicht mehr verwendet werden, wenn eine Kopplung gelöscht wird.

In den oben genannten Fällen bezieht sich die Kopplung auf die Registrierung eines Satzes von Hörgeräten mit einer bestimmten UUID und Links-/Rechtskennungen im Betriebssystem, nicht auf den Bluetooth-Kopplungsprozess.

System Anforderungen

Um CoC für eine gute Benutzererfahrung richtig zu implementieren, müssen die Bluetooth-Systeme in den zentralen und peripheren Geräten:

• Implementieren Sie einen kompatiblen BT 4.2- oder höheren Controller. LE Secure Connections wird dringend empfohlen.
• Die Zentrale muss mindestens 2 gleichzeitige LE-Links mit Parametern unterstützen, wie sie in Audiopaketformat und -timing beschrieben sind.
• Das Peripheriegerät muss mindestens 1 LE-Link mit den unter Format und Timing von Audiopaketen beschriebenen Parametern unterstützen.
• haben eine auf LE-Guthaben basierende Flusssteuerung [BT Band 3, Teil A, Abschnitt 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.
• haben eine LE-Datenlängenerweiterung [BT Vol 6, Teil B, Abschnitt 5.1.9] mit einer Nutzlast von mindestens 167 Bytes.
• das zentrale Gerät den HCI LE-Verbindungsaktualisierungsbefehl unterstützen und die von Null verschiedenen Parameter maximum_CE_Length und minimum_CE_Length .
• Lassen Sie die Zentrale den Datendurchsatz für zwei LE-CoC-Verbindungen zu zwei verschiedenen Peripheriegeräten mit den Verbindungsintervallen und Nutzlastgrößen im Audiopaketformat und -timing aufrechterhalten.
• Lassen Sie das Peripheriegerät die MaxRxOctets und MaxRxTime Parameter in den LL_LENGTH_REQ oder LL_LENGTH_RSP Frames auf die kleinsten erforderlichen Werte setzen, die für diese Spezifikationen erforderlich sind. Dadurch kann die Zentrale ihren Zeitplaner optimieren, wenn sie die Zeitdauer berechnet, die zum Empfangen eines Rahmens benötigt wird.

Es wird dringend empfohlen, dass die zentrale und die Peripherie 2 MB PHY unterstützen, wie in der BT 5.0-Spezifikation angegeben. Die Zentrale muss Audioverbindungen von mindestens 64 kbit/s sowohl auf 1M- als auch auf 2M-PHYs unterstützen. Der BLE-Langstrecken-PHY darf nicht verwendet werden.

CoC verwendet die Standard-Bluetooth-Mechanismen für Link-Layer-Verschlüsselung und Frequenzsprungverfahren.

ASHA GATT-Dienste

Ein Peripheriegerät soll den unten beschriebenen GATT-Serverdienst Audio Streaming for Hearing Aid (ASHA) implementieren. Das Peripheriegerät soll diesen Dienst ankündigen, wenn es sich im allgemein erkennbaren Modus befindet, damit die Zentrale eine Audiosenke erkennen kann. Alle LE-Audio-Streaming-Vorgänge müssen verschlüsselt werden. Das BLE-Audio-Streaming besteht aus folgenden Merkmalen:

Die dem Dienst zugeordneten UUIDs und Merkmale:

Dienst-UUID : {0xFDF0}

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

ReadOnlyProperties

ReadOnlyProperties haben die folgenden Werte:

Gerätefähigkeiten

HiSyncID

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

FeatureMap

Codec-IDs

Wenn das Bit gesetzt ist, wird dieser bestimmte Codec unterstützt.

AudioControlPoint

Dieser Kontrollpunkt kann nicht verwendet werden, wenn das LE CoC geschlossen ist. Siehe Starten und Stoppen eines Audiostreams für die Beschreibung des Verfahrens.

AudioStatusPoint

Statusberichtsfeld für den Audiokontrollpunkt

Werbung für ASHA GATT Service

Die Dienst-UUID muss im Ankündigungspaket enthalten sein. Entweder in der Ankündigung oder im Scan-Antwortrahmen müssen die Peripheriegeräte über Servicedaten verfügen:

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

Wenn die Peripheriegeräte den Namen und die ASHA-Dienstdatentypen in denselben Rahmentyp (ADV oder SCAN RESP) setzen, dann sollen die zwei Datentypen ("Vollständiger lokaler Name" und "Dienstdaten für ASHA-Dienst") in demselben Rahmen erscheinen. Dadurch erhält der Mobilgerätescanner beide Daten in demselben Scanergebnis.

Während der anfänglichen Kopplung ist es wichtig, dass die Peripheriegeräte mit einer Rate ankündigen, die schnell genug ist, damit das mobile Gerät die Peripheriegeräte schnell erkennen und sich mit ihnen verbinden kann.

Synchronisieren von linken und rechten Peripheriegeräten

Um mit Bluetooth auf Android-Mobilgeräten zu arbeiten, müssen Peripheriegeräte sicherstellen, dass sie synchronisiert sind. 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 synchronisieren, indem sie eine Sequenznummer verwenden, die jedem Paket der Audio-Nutzlast vorangestellt wird. Die Zentrale garantiert, dass Audiopakete, die gleichzeitig auf jedem Peripheriegerät abgespielt werden sollen, dieselbe Sequenznummer haben. Die Sequenznummer wird nach jedem Audiopaket um eins erhöht. Jede Sequenznummer ist 8 Bit lang, sodass sich die Sequenznummern nach 256 Audiopaketen wiederholen. Da jede Audiopaketgröße und Abtastrate für jede Verbindung festgelegt ist, können die beiden Peripheriegeräte die relative Spielzeit ableiten. Weitere Informationen zum Audiopaket finden Sie unter Audiopaketformat und -timing .

Die Zentrale hilft, indem sie den binauralen Geräten Auslöser bereitstellt, wenn die Synchronisation möglicherweise stattfinden muss. Diese Trigger informieren jedes Peripheriegerät über den Status seines gepaarten Peripheriegeräts, wann immer es eine Operation gibt, die die Synchronisation beeinflussen könnte. Die Auslöser sind:

• Im Rahmen des «Start» -Befehls von AudioControlPoint wird der aktuelle Verbindungszustand der Gegenseite der binauralen Geräte angegeben.
• Wann immer eine Verbindung, Trennung oder Aktualisierung der Verbindungsparameter an einem Peripheriegerät stattfindet, wird der «Status» -Befehl von AudioControlPoint an die andere Seite der binauralen Geräte gesendet.

Format und Timing von Audiopaketen

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

• Ein Audioframe sollte zeitlich immer mit dem Verbindungsintervall übereinstimmen. Wenn beispielsweise das Verbindungsintervall 20 ms und die Abtastrate 16 kHz beträgt, dann soll der Audiorahmen 320 Abtastungen enthalten.
• Abtastraten im System sind auf Vielfache von 8 kHz beschränkt, um immer eine ganzzahlige Anzahl von Abtastungen in einem Rahmen zu haben, unabhängig von der Rahmenzeit oder dem Verbindungsintervall.
• Audioframes soll ein Sequenzbyte vorangestellt werden. Das Folgebyte soll mit Umlauf gezählt werden und es dem Peripheriegerät ermöglichen, eine Pufferfehlanpassung oder einen Unterlauf zu erkennen.
• Ein Audiorahmen soll immer in ein einzelnes LE-Paket passen. Der Audioframe soll als separates L2CAP-Paket gesendet werden. Die Größe der LE LL PDU muss sein:
  Audionutzlastgröße + 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, um Bandbreite für Neuübertragungen zu reservieren. Beachten Sie, dass das Audiopaket möglicherweise vom Bluetooth-Controller der Zentrale fragmentiert wird. Das Peripheriegerät muss in der Lage sein, mehr als 2 fragmentierte Audiopakete pro Verbindungsereignis zu empfangen.

Um der Zentrale eine gewisse Flexibilität zu geben, wird die G.722-Paketlänge nicht angegeben. Die G.722-Paketlänge kann sich basierend auf dem von der Zentrale festgelegten Verbindungsintervall ändern.

Das G.722-Ausgabe-Oktettformat verweist auf die Rec. ITU-T G.722 (09/2012) Abschnitt 1.4.4 „Multiplexer“

Für alle Codecs, die ein Peripheriegerät unterstützt, soll das Peripheriegerät die nachstehenden Verbindungsparameter unterstützen. Dies ist eine nicht erschöpfende Liste von Konfigurationen, die die Zentrale implementieren kann.

Starten und Stoppen eines Audiostreams

Vor dem Starten eines Audiostroms fragt die Zentrale die Peripheriegeräte ab und stellt einen gemeinsamen Nenner-Codec her. Das Stream-Setup durchläuft dann die folgende Sequenz:

1. PSM und optional RenderDelay wird gelesen. Diese Werte können von der Zentrale zwischengespeichert werden.
2. Der CoC L2CAP-Kanal wird geöffnet – das Peripheriegerät gewährt zunächst 8 Credits.
3. Es wird eine Verbindungsaktualisierung ausgegeben, um die Verbindung auf die für den ausgewählten Codec erforderlichen Parameter umzuschalten. 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 Update-Complete-Ereignis.
5. Starten Sie den Audio-Encoder neu und setzen Sie den Paketsequenzzähler auf 0 zurück. Auf dem AudioControlPoint wird ein «Start» -Befehl mit den entsprechenden Parametern ausgegeben. Die Zentrale wartet vor dem Streaming auf eine erfolgreiche Statusmeldung des vorangegangenen «Start» -Befehls vom Peripheriegerät. Dieses Warten gibt dem Peripheriegerät Zeit, seine Audiowiedergabe-Pipeline vorzubereiten. Während des Audiostreamings sollte die Kopie bei jedem Verbindungsereignis verfügbar sein, auch wenn die aktuelle Replikatlatenz möglicherweise nicht Null ist.
6. Das Peripheriegerät nimmt das erste Audiopaket aus seiner internen Warteschlange (Sequenznummer 0) und spielt es ab.

Die Zentrale gibt den Befehl «Stop» , um den Audiostream zu beenden. Nach diesem Befehl muss das Peripheriegerät nicht bei jedem Verbindungsereignis verfügbar sein. Um das Audio-Streaming neu zu starten, führen Sie die obige Sequenz ab Schritt 5 durch. Wenn die Zentrale kein Audio-Streaming durchführt, sollte sie dennoch eine LE-Verbindung für GATT-Dienste aufrechterhalten.

Das Peripheriegerät darf keine Verbindungsaktualisierung an die Zentrale ausgeben. Um Strom zu sparen, kann die Zentrale eine Verbindungsaktualisierung an das Peripheriegerät ausgeben, wenn es kein Audio-Streaming durchführt.