Aparaty słuchowe (HA) mogą mieć lepszą dostępność na urządzeniach mobilnych z systemem Android dzięki wykorzystaniu zorientowanych na połączenie kanałów L2CAP (CoC) przez Bluetooth Low Energy (BLE). CoC używa elastycznego bufora kilku pakietów audio, aby utrzymać stały przepływ audio, nawet w przypadku utraty pakietów. Ten bufor zapewnia jakość dźwięku dla aparatów słuchowych kosztem latencji.
Projekt CoC nawiązuje do specyfikacji Bluetooth Core w wersji 5 (BT). Aby zachować zgodność z podstawowymi specyfikacjami, wszystkie wartości wielobajtowe na tej stronie należy odczytywać jako little-endian.
Terminologia
- Central - urządzenie z Androidem, które skanuje reklamy przez Bluetooth.
- Urządzenie peryferyjne — aparat słuchowy, który wysyła pakiety reklam przez Bluetooth.
Topologia sieci i architektura systemu
Podczas korzystania z CoC w aparatach słuchowych topologia sieci zakłada jedną centralę i dwa urządzenia peryferyjne, jedno lewe i jedno prawe, jak pokazano na rysunku 1 . System audio Bluetooth postrzega lewe i prawe urządzenie peryferyjne jako pojedynczy odbiornik audio. Jeśli brakuje urządzenia peryferyjnego z powodu dopasowania monofonicznego lub utraty połączenia, centrala miksuje lewy i prawy kanał audio i przesyła dźwięk do pozostałego urządzenia peryferyjnego. Jeśli centrala utraci połączenie z obydwoma urządzeniami peryferyjnymi, uzna, że połączenie z ujściem audio zostało utracone. W takich przypadkach centrala kieruje dźwięk do innego wyjścia.
Rysunek 1. Topologia parowania aparatów słuchowych z urządzeniami mobilnymi z systemem Android przy użyciu CoC przez BLE
Gdy centrala nie przesyła strumieniowo danych audio do urządzenia peryferyjnego i może utrzymywać połączenie BLE, centrala nie powinna odłączać się od urządzenia peryferyjnego. Utrzymanie połączenia umożliwia przesyłanie danych do serwera GATT rezydującego na urządzeniu peryferyjnym.
Podczas parowania i łączenia aparatów słuchowych centrala:
- Śledź nowsze sparowane lewe i prawe urządzenie peryferyjne.
- Załóżmy, że urządzenia peryferyjne są używane, jeśli istnieje prawidłowe parowanie. Centrala będzie próbowała połączyć się lub ponownie połączyć ze sparowanym urządzeniem, gdy połączenie zostanie utracone.
- Załóżmy, że urządzenia peryferyjne nie są już używane, jeśli parowanie zostanie usunięte.
W powyższych przypadkach parowanie odnosi się do czynności polegającej na zarejestrowaniu zestawu aparatów słuchowych z danym identyfikatorem UUID i oznaczeniem lewy/prawy w systemie operacyjnym, a nie procesem parowania Bluetooth.
Wymagania systemowe
Aby właściwie wdrożyć CoC dla dobrego doświadczenia użytkownika, systemy Bluetooth w urządzeniach centralnych i peryferyjnych powinny:
- wdrożyć zgodny kontroler BT 4.2 lub nowszy. Zalecane jest stosowanie LE Secure Connections.
- mieć centralę obsługującą co najmniej 2 jednoczesne łącza LE z parametrami opisanymi w sekcji Format i synchronizacja pakietów audio .
- mieć urządzenie peryferyjne obsługujące co najmniej 1 łącze LE z parametrami opisanymi w sekcji Format pakietu audio i taktowanie .
- mieć kontrolę przepływu opartą na kredytach LE [BT tom 3, część A, rozdz. 10.1]. Urządzenia powinny obsługiwać rozmiar MTU i MPS wynoszący co najmniej 167 bajtów w CoC i być w stanie buforować do 8 pakietów.
- mieć rozszerzenie długości danych LE [BT tom 6, część B, rozdział 5.1.9] z ładunkiem co najmniej 167 bajtów.
- mieć urządzenie centralne obsługujące polecenie aktualizacji połączenia HCI LE i zgodne z niezerowymi parametrami
maximum_CE_Lengthiminimum_CE_Length. - zlecić centrali utrzymywanie przepustowości danych dla dwóch połączeń LE CoC z dwoma różnymi urządzeniami peryferyjnymi z odstępami między połączeniami i rozmiarami danych w formacie pakietu audio i taktowaniu .
- zlecić urządzeniu peryferyjnemu ustawienie parametrów
MaxRxOctetsiMaxRxTimew ramkachLL_LENGTH_REQlubLL_LENGTH_RSPna najmniejsze wymagane wartości wymagane dla tych specyfikacji. Pozwala to centrali zoptymalizować harmonogram czasowy podczas obliczania ilości czasu potrzebnego do odebrania ramki.
Zdecydowanie zaleca się, aby centrala i urządzenia peryferyjne obsługiwały 2MB PHY zgodnie ze specyfikacją BT 5.0. Centrala powinna obsługiwać łącza audio o przepustowości co najmniej 64 kbit/s zarówno w 1M, jak i 2M PHY. Nie należy stosować PHY dalekiego zasięgu BLE.
CoC wykorzystuje standardowe mechanizmy Bluetooth do szyfrowania warstwy łącza i przeskoku częstotliwości.
Usługi ASHA GATT
Urządzenie peryferyjne powinno implementować opisaną poniżej usługę serwera Audio Streaming for Hearing Aid (ASHA) GATT. Urządzenie peryferyjne będzie rozgłaszać tę usługę, gdy jest w trybie ogólnego wykrywania, aby centrala mogła rozpoznać ujście audio. Wszelkie operacje przesyłania strumieniowego audio LE wymagają szyfrowania. Strumieniowe przesyłanie dźwięku BLE ma następujące cechy:
| Charakterystyka | Nieruchomości | Opis |
|---|---|---|
| Właściwości tylko do odczytu | Czytać | Zobacz ReadOnlyProperties . |
| AudioControlPoint | Pisz i pisz bez odpowiedzi | Punkt kontrolny dla strumienia audio. Zobacz AudioControlPoint . |
| AudioStatusPoint | Przeczytaj/Powiadom | Pole raportu o stanie punktu sterowania dźwiękiem. Zobacz AudioStatusPoint |
| Tom | Pisz bez odpowiedzi | Bajt z przedziału od -128 do 0 wskazujący stopień tłumienia, jaki należy zastosować do przesyłanego strumieniowo sygnału audio, w zakresie od -48 dB do 0 dB. Ustawienie -128 należy interpretować jako całkowicie wyciszone, tj. najniższy niewyciszony poziom głośności to -127, co odpowiada tłumieniu -47,625 dB. Przy ustawieniu 0, przesyłany strumieniowo ton sinusoidalny typu „szyna do szyny” odpowiada 100 dBSPL na wejściu w aparacie słuchowym. Centrala będzie transmitować w nominalnej pełnej skali i użyje tej zmiennej do ustawienia pożądanego poziomu prezentacji w urządzeniu peryferyjnym. |
| LE_PSM_OUT | Czytać | PSM do podłączenia kanału audio. Do wyboru z zakresu dynamicznego [BT tom 3, część A, rozdz. 4.22] |
Identyfikatory UUID przypisane do usługi i charakterystyki:
UUID usługi : {0xFDF0}
| Charakterystyka | UUID |
|---|---|
| Właściwości tylko do odczytu | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| Stan dźwięku | {38663f1a-e711-4cac-b641-326b56404837} |
| Tom | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
Oprócz usługi ASHA GATT, urządzenie peryferyjne powinno również implementować usługę informacji o urządzeniu, aby umożliwić centrali wykrywanie nazw producentów i nazw urządzeń urządzenia peryferyjnego.
Właściwości tylko do odczytu
ReadOnlyProperties mają następujące wartości:
| Bajt | Opis |
|---|---|
| 0 | Wersja — musi być 0x01 |
| 1 | Zobacz Możliwości urządzenia . |
| 2-9 | Zobacz HiSyncId . |
| 10 | Zobacz FeatureMap . |
| 11-12 | Opóźnienie renderowania. Jest to czas, w milisekundach, od momentu odebrania przez urządzenie peryferyjne ramki audio do wyrenderowania danych wyjściowych przez urządzenie peryferyjne. Bajtów tych można użyć do opóźnienia wideo w celu synchronizacji z dźwiękiem. |
| 13-14 | Zarezerwowane do wykorzystania w przyszłości. Inicjalizuj do zera. |
| 15-16 | Obsługiwane identyfikatory kodeków . To jest maska bitowa obsługiwanych identyfikatorów kodeków. 1 w miejscu bitowym odpowiada obsługiwanemu kodekowi. Na przykład 0x0002 wskazuje, że obsługiwane jest G.722 przy 16 kHz. Wszystkie pozostałe bity powinny być ustawione na 0. |
Możliwości urządzenia
| Fragment | Opis |
|---|---|
| 0 | Strona urządzenia (0: lewa, 1: prawa) |
| 1 | Wskazuje, czy urządzenie jest samodzielne i odbiera dane w trybie mono, czy też jest częścią zestawu (0: monofoniczne, 1: obuuszne) |
| 2 | Urządzenie obsługuje CSIS (0: nieobsługiwane, 1: obsługiwane) |
| 3-7 | Zarezerwowany (ustawiony na 0) |
HiSyncID
To pole musi być unikalne dla wszystkich aparatów binauralnych, ale musi być takie samo dla lewego i prawego zestawu.
| Bajt | Opis |
|---|---|
| 0-1 | Identyfikator producenta. Są to identyfikatory firmy nadawane przez BTSIG. |
| 2-7 | Unikalny identyfikator identyfikujący zestaw aparatów słuchowych. Ten identyfikator musi być ustawiony tak samo na lewym i prawym urządzeniu peryferyjnym. |
Mapa funkcji
| Fragment | Opis |
|---|---|
| 0 | Obsługiwane strumieniowe przesyłanie dźwięku LE CoC (tak/nie). |
| 1-7 | Zarezerwowany (ustawiony na 0). |
Identyfikatory kodeków
Jeśli bit jest ustawiony, obsługiwany jest ten konkretny kodek.
| Numer identyfikacyjny / bitu | Kodek i częstotliwość próbkowania | Wymagana szybkość transmisji bitów | Czas klatki | Obowiązkowe na centralnej (C) lub obwodowej (P) |
|---|---|---|---|---|
| 0 | Skryty | Skryty | Skryty | Skryty |
| 1 | G.722 przy 16 kHz | 64 kb/s | Zmienny | C i P |
| 2-15 są zarezerwowane. 0 jest również zarezerwowane. | ||||
AudioControlPoint
Z tego punktu kontrolnego nie można korzystać, gdy LE CoC jest zamknięte. Zobacz Uruchamianie i zatrzymywanie strumienia audio, aby zapoznać się z opisem procedury.
| Kod operacji | Argumenty | podprocedura GATT | Opis |
|---|---|---|---|
1 «Start» |
| Pisz z odpowiedzią i oczekuj dodatkowego powiadomienia o stanie za pośrednictwem funkcji AudioStatusPoint . | Nakazuje urządzeniu peryferyjnemu zresetować kodek i rozpocząć odtwarzanie klatki 0. Pole kodek wskazuje identyfikator kodeka, który ma być użyty do tego odtwarzania. Na przykład pole kodeka to „1” dla G.722 przy 16 kHz. Pole bitowe typu audio wskazuje typy audio obecne w strumieniu:
Urządzenie peryferyjne nie powinno żądać aktualizacji połączenia przed otrzymaniem kodu operacji «Stop» . |
2 «Stop» | Nic | Pisz z odpowiedzią i oczekuj dodatkowego powiadomienia o stanie za pośrednictwem funkcji AudioStatusPoint . | Nakazuje urządzeniu peryferyjnemu zatrzymać renderowanie dźwięku. Po tym zatrzymaniu należy zainicjować nową sekwencję konfiguracji dźwięku, aby ponownie renderować dźwięk. |
3 «Status» |
| Pisz bez odpowiedzi | Informuje podłączone urządzenie peryferyjne o aktualizacji stanu drugiego urządzenia peryferyjnego. Połączone pole wskazuje typ aktualizacji:
|
AudioStatusPoint
Pole raportu o stanie punktu sterowania dźwiękiem
| Kody operacji | Opis |
|---|---|
| 0 | Stan OK |
| -1 | Nieznane polecenie |
| -2 | Niedozwolone parametry |
Reklamy serwisu ASHA GATT
Identyfikator UUID usługi musi znajdować się w pakiecie anonsu. W ogłoszeniu lub ramce odpowiedzi skanowania urządzenia peryferyjne muszą mieć dane usługi:
| Przesunięcie bajtów | Nazwa | Opis |
|---|---|---|
| 0 | Długość AD | >= 0x09 |
| 1 | Typ AD | 0x16 (dane usługi — 16-bitowy identyfikator UUID) |
| 2-3 | Identyfikator UUI usługi | 0xFDF0 (little-endian) Uwaga: To jest identyfikator tymczasowy. |
| 4 | Wersja protokołu | 0x01 |
| 5 | Zdolność |
|
| 6-9 | Obcięty HiSyncID | Cztery najmniej znaczące bajty HiSyncId . Te bajty powinny być najbardziej losową częścią identyfikatora. |
Urządzenia peryferyjne muszą mieć typ danych Pełna nazwa lokalna , który wskazuje nazwę aparatu słuchowego. Ta nazwa będzie używana w interfejsie użytkownika urządzenia mobilnego, aby użytkownik mógł wybrać odpowiednie urządzenie. Nazwa nie może wskazywać lewego ani prawego kanału, ponieważ ta informacja jest podana w DeviceCapabilities .
Jeżeli urządzenia peryferyjne umieszczają nazwę i typy danych usługi ASHA w tym samym typie ramki (ADV lub SCAN RESP), wówczas oba typy danych („Pełna nazwa lokalna” i „Dane usługi dla usługi ASHA”) pojawią się w tej samej ramce. Dzięki temu skaner urządzeń mobilnych może uzyskać oba dane w tym samym wyniku skanowania.
Podczas wstępnego parowania ważne jest, aby urządzenia peryferyjne reklamowały się z szybkością wystarczającą do umożliwienia urządzeniu mobilnemu szybkiego wykrycia urządzeń peryferyjnych i połączenia się z nimi.
Synchronizacja lewego i prawego urządzenia peryferyjnego
Aby pracować z Bluetooth na urządzeniach mobilnych z systemem Android, urządzenia peryferyjne są odpowiedzialne za zapewnienie ich synchronizacji. Odtwarzanie na lewym i prawym urządzeniu peryferyjnym musi być zsynchronizowane w czasie. Oba urządzenia peryferyjne muszą jednocześnie odtwarzać próbki audio ze źródła.
Urządzenia peryferyjne mogą synchronizować swój czas za pomocą numeru sekwencyjnego dołączanego do każdego pakietu ładunku audio. Centrala gwarantuje, że pakiety audio, które mają być odtwarzane w tym samym czasie na każdym urządzeniu peryferyjnym, mają ten sam numer sekwencyjny. Numer sekwencyjny zwiększa się o jeden po każdym pakiecie audio. Każdy numer sekwencyjny ma długość 8 bitów, więc numery sekwencyjne będą się powtarzać po 256 pakietach audio. Ponieważ każdy rozmiar pakietu audio i częstotliwość próbkowania są ustalone dla każdego połączenia, dwa urządzenia peryferyjne mogą określić względny czas odtwarzania. Aby uzyskać więcej informacji o pakiecie audio, zobacz Format i synchronizacja pakietu audio .
Centrala pomaga, dostarczając wyzwalacze do urządzeń obuusznych, gdy może zaistnieć potrzeba synchronizacji. Wyzwalacze te informują każde urządzenie peryferyjne o stanie sparowanego urządzenia peryferyjnego za każdym razem, gdy wykonywana jest operacja, która może wpłynąć na synchronizację. Wyzwalacze to:
- W ramach polecenia
«Start»AudioControlPoint podawany jest aktualny stan połączenia po drugiej stronie obuusznych urządzeń. - Zawsze, gdy na jednym urządzeniu peryferyjnym następuje połączenie, rozłączenie lub aktualizacja parametrów połączenia, polecenie
«Status»z AudioControlPoint jest wysyłane do drugiej strony obuusznych urządzeń.
Format i czas pakietu audio
Pakowanie ramek dźwiękowych (bloków próbek) w pakiety umożliwia aparatowi słuchowemu pobieranie taktowania z kotwic taktowania warstwy łącza. Aby uprościć implementację:
- Ramka audio powinna zawsze odpowiadać interwałowi połączenia w czasie. Na przykład, jeśli interwał połączenia wynosi 20 ms, a częstotliwość próbkowania wynosi 16 kHz, wówczas ramka audio powinna zawierać 320 próbek.
- Częstotliwości próbkowania w systemie są ograniczone do wielokrotności 8 kHz, aby zawsze mieć całkowitą liczbę próbek w ramce, niezależnie od czasu ramki lub interwału połączenia.
- Bajt sekwencji powinien poprzedzać ramki audio. Bajt sekwencji będzie zliczany z zawijaniem i umożliwia urządzeniu peryferyjnemu wykrycie niedopasowania lub niedopełnienia bufora.
- Ramka audio zawsze mieści się w pojedynczym pakiecie LE. Ramka audio zostanie wysłana jako osobny pakiet L2CAP. Rozmiar LE LL PDU powinien wynosić:
rozmiar ładunku audio + 1 (licznik sekwencji) + 6 (4 dla nagłówka L2CAP, 2 dla SDU) - Zdarzenie połączenia powinno zawsze być wystarczająco duże, aby zawierało 2 pakiety audio i 2 puste pakiety, aby potwierdzenie mogło zarezerwować przepustowość dla retransmisji. Należy pamiętać, że pakiet audio może być fragmentowany przez kontroler Bluetooth centrali. Urządzenie peryferyjne musi być w stanie odebrać więcej niż 2 pofragmentowane pakiety audio na zdarzenie połączenia.
Aby zapewnić centrali pewną elastyczność, długość pakietu G.722 nie jest określona. Długość pakietu G.722 może się zmieniać w zależności od interwału połączenia ustawionego przez centralę.
Wyjściowy format oktetu G.722 odwołuje się do formatu Rec. ITU-T G.722 (09/2012) sekcja 1.4.4 „Multiplekser”
W przypadku wszystkich kodeków obsługiwanych przez urządzenie peryferyjne urządzenie peryferyjne powinno obsługiwać poniższe parametry połączenia. To jest niewyczerpująca lista konfiguracji, które centrala może wdrożyć.
| Kodek | Szybkość transmisji | Interwał połączenia | Długość CE (1M/2M PHY) | Rozmiar ładunku audio |
|---|---|---|---|---|
| G.722 przy 16 kHz | 64 kb/s | 20 ms | 5000/3750 nas | 160 bajtów |
Uruchamianie i zatrzymywanie strumienia audio
Przed rozpoczęciem strumienia audio centrala wysyła zapytanie do urządzeń peryferyjnych i ustala kodek ze wspólnym mianownikiem. Następnie konfiguracja strumienia przebiega zgodnie z następującą sekwencją:
- PSM i opcjonalnie RenderDelay jest odczytywany. Wartości te mogą być buforowane przez centralę.
- Kanał CoC L2CAP jest otwarty – urządzenie peryferyjne przyzna początkowo 8 kredytów.
- Wydawana jest aktualizacja połączenia w celu przełączenia łącza na parametry wymagane dla wybranego kodeka. Centrala może wykonać tę aktualizację połączenia przed połączeniem CoC w poprzednim kroku.
- Zarówno host centralny, jak i peryferyjny czekają na zdarzenie zakończenia aktualizacji.
- Zrestartuj koder audio i zresetuj licznik sekwencji pakietów do 0. Na AudioControlPoint wydawane jest polecenie
«Start»z odpowiednimi parametrami. Centrala czeka na pomyślne powiadomienie o statusie poprzedniego polecenia«Start»z urządzenia peryferyjnego przed przesyłaniem strumieniowym. To oczekiwanie daje urządzeniu peryferyjnemu czas na przygotowanie potoku odtwarzania dźwięku. Podczas przesyłania strumieniowego audio replika powinna być dostępna przy każdym zdarzeniu połączenia, nawet jeśli bieżące opóźnienie repliki może być niezerowe. - Urządzenie peryferyjne pobiera pierwszy pakiet audio ze swojej wewnętrznej kolejki (numer kolejny 0) i odtwarza go.
Centrala wydaje polecenie «Stop» w celu zamknięcia strumienia audio. Po tym poleceniu urządzenie peryferyjne nie musi być dostępne przy każdym zdarzeniu połączenia. Aby wznowić transmisję strumieniową audio, wykonaj powyższą sekwencję, zaczynając od kroku 5. Kiedy centrala nie przesyła strumieniowo audio, powinna nadal utrzymywać połączenie LE dla usług GATT.
Urządzenie peryferyjne nie wysyła aktualizacji połączenia do centrali. Aby oszczędzać energię, centrala może zaktualizować połączenie z urządzeniem peryferyjnym, gdy nie przesyła ono strumieniowo dźwięku.