I dispositivi per apparecchi acustici (HA) possono avere una migliore accessibilità sui dispositivi mobili basati su Android utilizzando i canali L2CAP orientati alla connessione (CoC) su Bluetooth Low Energy (BLE). CoC utilizza un buffer elastico di diversi pacchetti audio per mantenere un flusso costante di audio, anche in presenza di perdita di pacchetti. Questo buffer fornisce la qualità audio per gli apparecchi acustici a scapito della latenza.
Il design di CoC fa riferimento alla Bluetooth Core Specification Version 5 (BT). Per rimanere allineati con le specifiche principali, tutti i valori multibyte in questa pagina devono essere letti come little-endian.
Terminologia
- Central : il dispositivo Android che esegue la scansione degli annunci tramite Bluetooth.
- Periferica : l'apparecchio acustico che invia pacchetti pubblicitari tramite Bluetooth.
Topologia di rete e architettura di sistema
Quando si utilizza CoC per gli apparecchi acustici, la topologia di rete presuppone un'unica centrale e due periferiche, una sinistra e una destra, come mostrato nella Figura 1 . Il sistema audio Bluetooth vede le periferiche sinistra e destra come un singolo sink audio. Se manca una periferica, a causa di un adattamento monofonico o di una perdita di connessione, la centrale mescola il canale audio sinistro e destro e trasmette l'audio alla periferica rimanente. Se la centrale perde la connessione con entrambe le periferiche, allora la centrale considera perso il collegamento con l'audio sink. In questi casi, la centrale indirizza l'audio a un'altra uscita.
Figura 1. Topologia per l'associazione di apparecchi acustici con dispositivi mobili Android che utilizzano CoC su BLE
Quando la centrale non trasmette dati audio alla periferica e può mantenere una connessione BLE, la centrale non deve disconnettersi dalla periferica. Il mantenimento della connessione consente la comunicazione dei dati al server GATT residente sulla periferica.
Quando si accoppiano e si collegano gli apparecchi acustici, la centrale deve:
- Tieni traccia delle più recenti periferiche sinistra e destra accoppiate.
- Si supponga che le periferiche siano in uso se esiste un accoppiamento valido. La centrale tenterà di connettersi o riconnettersi con il dispositivo accoppiato quando la connessione viene persa.
- Si supponga che le periferiche non siano più in uso se un'associazione viene eliminata.
Nei casi precedenti, l' accoppiamento si riferisce all'azione di registrazione di un set di apparecchi acustici con un dato UUID e designatori sinistro/destro nel sistema operativo, non al processo di accoppiamento Bluetooth.
Requisiti di sistema
Per implementare correttamente CoC per una buona esperienza utente, i sistemi Bluetooth nei dispositivi centrali e periferici devono:
- implementare un controller compatibile BT 4.2 o superiore. LE Secure Connections è altamente raccomandato.
- avere il supporto centrale di almeno 2 collegamenti LE simultanei con i parametri descritti in Formato e temporizzazione del pacchetto audio .
- avere la periferica che supporti almeno 1 collegamento LE con i parametri descritti in Formato e temporizzazione del pacchetto audio .
- avere un controllo del flusso basato sui crediti LE [BT Vol 3, Parte A, Sez 10.1]. I dispositivi devono supportare una dimensione MTU e MPS di almeno 167 byte su CoC ed essere in grado di bufferizzare fino a 8 pacchetti.
- avere un'estensione della lunghezza dei dati LE [BT Vol 6, Part B, Sec 5.1.9] con un payload di almeno 167 byte.
- fare in modo che il dispositivo centrale supporti il comando di aggiornamento della connessione HCI LE e rispetti i parametri
maximum_CE_Lengtheminimum_CE_Lengthdiversi da zero. - fare in modo che la centrale mantenga il throughput dei dati per due connessioni LE CoC a due diverse periferiche con gli intervalli di connessione e le dimensioni del carico utile in formato e temporizzazione del pacchetto audio .
- fare in modo che la periferica imposti i parametri
MaxRxOctetseMaxRxTimenei frameLL_LENGTH_REQoLL_LENGTH_RSPin modo che corrispondano ai valori richiesti più piccoli necessari per queste specifiche. Ciò consente alla centrale di ottimizzare il suo programmatore orario durante il calcolo della quantità di tempo necessaria per ricevere un frame.
Si consiglia vivamente che la centrale e la periferica supportino 2 MB PHY come specificato nella specifica BT 5.0. La centrale deve supportare collegamenti audio di almeno 64 kbit/s su entrambi i PHY 1M e 2M. Il PHY BLE a lungo raggio non deve essere utilizzato.
CoC utilizza i meccanismi Bluetooth standard per la crittografia del livello di collegamento e il salto di frequenza.
Servizi ASHA GATT
Una periferica deve implementare il servizio server GATT di Audio Streaming for Hearing Aid (ASHA) descritto di seguito. La periferica deve pubblicizzare questo servizio quando è in modalità rilevabile generale per consentire alla centrale di riconoscere un sink audio. Qualsiasi operazione di streaming audio LE richiederà la crittografia. Lo streaming audio BLE è costituito dalle seguenti caratteristiche:
| Caratteristica | Proprietà | Descrizione |
|---|---|---|
| Proprietà di sola lettura | Leggi | Vedere ReadOnlyProperties . |
| AudioControlPoint | Scrivi e scrivi senza risposta | Punto di controllo per il flusso audio. Vedere AudioControlPoint . |
| AudioStatusPoint | Leggi/Notifica | Campo del report di stato per il punto di controllo audio. Vedere AudioStatusPoint |
| Volume | Scrivi senza risposta | Byte compreso tra -128 e 0 che indica la quantità di attenuazione da applicare al segnale audio in streaming, compresa tra -48 dB e 0 dB. L'impostazione -128 deve essere interpretata come completamente disattivata, ovvero il livello di volume non disattivato più basso è -127, che equivale a un'attenuazione di -47,625 dB. All'impostazione 0, un tono sinusoidale rail-to-rail trasmesso in streaming rappresenterà un ingresso equivalente di 100 dBSPL sull'apparecchio acustico. La centrale trasmetterà a fondo scala nominale e utilizzerà questa variabile per impostare il livello di presentazione desiderato nella periferica. |
| LE_PSM_OUT | Leggi | PSM da utilizzare per collegare il canale audio. Da scegliere dalla gamma dinamica [BT Vol 3, Parte A, Sez 4.22] |
Gli UUID assegnati al servizio e le caratteristiche:
UUID servizio : {0xFDF0}
| Caratteristica | UUID |
|---|---|
| Proprietà di sola lettura | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| Stato audio | {38663f1a-e711-4cac-b641-326b56404837} |
| Volume | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
Oltre al servizio ASHA GATT, la periferica deve implementare anche il Device Information Service per consentire alla centrale di rilevare i nomi dei produttori e dei dispositivi della periferica.
Proprietà di sola lettura
ReadOnlyProperties hanno i seguenti valori:
| Byte | Descrizione |
|---|---|
| 0 | Versione: deve essere 0x01 |
| 1 | Vedere DeviceCapabilities . |
| 2-9 | Vedere HiSyncId . |
| 10 | Vedere FeatureMap . |
| 11-12 | RenderDelay. Questo è il tempo, in millisecondi, da quando la periferica riceve un frame audio fino a quando la periferica esegue il rendering dell'output. Questi byte possono essere utilizzati per ritardare la sincronizzazione di un video con l'audio. |
| 13-14 | Riservato per uso futuro. Inizializza a zero. |
| 15-16 | ID codec supportati . Questa è una maschera di bit degli ID codec supportati. Un 1 in una posizione di bit corrisponde a un codec supportato. Ad esempio, 0x0002 indica che G.722 a 16 kHz è supportato. Tutti gli altri bit devono essere impostati a 0. |
Funzionalità del dispositivo
| Po | Descrizione |
|---|---|
| 0 | Lato dispositivo (sinistra: 0, destra: 1). |
| 1 | Monofonico (0) / Binaurale (1). Indica se il dispositivo è autonomo e riceve dati mono o se fa parte di un set. |
| 2-7 | Riservato (impostato su 0). |
HiSyncID
Questo campo deve essere univoco per tutti i dispositivi binaurali ma deve essere lo stesso per il set sinistro e destro.
| Byte | Descrizione |
|---|---|
| 0-1 | ID del produttore. Sono i Company Identifier assegnati da BTSIG. |
| 2-7 | ID univoco che identifica il set di apparecchi acustici. Questo ID deve essere impostato allo stesso modo sia sulla periferica sinistra che su quella destra. |
FeatureMap
| Po | Descrizione |
|---|---|
| 0 | Streaming di uscita audio LE CoC supportato (Sì/No). |
| 1-7 | Riservato (impostato su 0). |
ID codec
Se il bit è impostato, quel particolare codec è supportato.
| ID / Numero di bit | Codec e frequenza di campionamento | Velocità in bit richiesta | Tempo di inquadratura | Obbligatorio su centrale (C) o periferica (P) |
|---|---|---|---|---|
| 0 | Riservato | Riservato | Riservato | Riservato |
| 1 | G.722 a 16 kHz | 64kbit/sec | Variabile | C e P |
| 2-15 sono riservati. 0 è anche riservato. | ||||
AudioControlPoint
Questo punto di controllo non può essere utilizzato quando il LE CoC è chiuso. Vedere Avvio e arresto di un flusso audio per la descrizione della procedura.
| Codice operativo | argomenti | sottoprocedura GATT | Descrizione |
|---|---|---|---|
1 «Start» |
| Scrivi con risposta e aspettati un'ulteriore notifica di stato tramite la caratteristica AudioStatusPoint . | Indica alla periferica di reimpostare il codec e avviare la riproduzione del fotogramma 0. Il campo codec indica l'ID del codec da utilizzare per questa riproduzione. Ad esempio, il campo del codec è "1" per G.722 a 16 kHz. Il campo del bit del tipo di audio indica i tipi di audio presenti nello stream:
La periferica non deve richiedere aggiornamenti di connessione prima che sia stato ricevuto un opcode «Stop» . |
2 «Stop» | Nessuno | Scrivi con risposta e aspettati un'ulteriore notifica di stato tramite la caratteristica AudioStatusPoint . | Indica alla periferica di interrompere il rendering dell'audio. Una nuova sequenza di configurazione audio deve essere avviata dopo questa interruzione per eseguire nuovamente il rendering dell'audio. |
3 «Status» |
| Scrivi senza risposta | Informa la periferica collegata che c'è un aggiornamento di stato sull'altra periferica. Il campo connesso indica il tipo di aggiornamento:
|
AudioStatusPoint
Campo del report di stato per il punto di controllo audio
| Opcode | Descrizione |
|---|---|
| 0 | Stato OK |
| -1 | Comando sconosciuto |
| -2 | Parametri illegali |
Pubblicità per ASHA GATT Service
L' UUID del servizio deve trovarsi nel pacchetto dell'annuncio. Nell'annuncio o nel frame di risposta alla scansione, le periferiche devono avere un Service Data:
| Offset di byte | Nome | Descrizione |
|---|---|---|
| 0 | Lunghezza d.C | >= 0x09 |
| 1 | Tipo AD | 0x16 (dati di servizio - UUID a 16 bit) |
| 2-3 | UUID di servizio | 0xFDF0 (little endian) Nota: questo è un ID temporaneo. |
| 4 | Versione del protocollo | 0x01 |
| 5 | Capacità |
|
| 6-9 | HiSyncID troncato | Quattro byte meno significativi di HiSyncId . Questi byte dovrebbero essere la parte più casuale dell'ID. |
Le periferiche devono avere un tipo di dati Nome locale completo che indica il nome dell'apparecchio acustico. Questo nome verrà utilizzato nell'interfaccia utente del dispositivo mobile in modo che l'utente possa selezionare il dispositivo corretto. Il nome non deve indicare il canale sinistro o destro poiché queste informazioni sono fornite in DeviceCapabilities .
Se le periferiche mettono il nome e i tipi di dati del servizio ASHA nello stesso tipo di frame (ADV o SCAN RESP), allora i due tipi di dati ("Complete Local Name" e "Service Data for ASHA service") appariranno nello stesso frame. Ciò consente allo scanner del dispositivo mobile di ottenere entrambi i dati nello stesso risultato di scansione.
Durante l'accoppiamento iniziale, è importante che le periferiche annuncino a una velocità sufficientemente rapida da consentire al dispositivo mobile di rilevare rapidamente le periferiche e collegarsi a esse.
Sincronizzazione dei dispositivi periferici sinistro e destro
Per funzionare con Bluetooth su dispositivi mobili Android, i dispositivi periferici sono responsabili di garantire che siano sincronizzati. La riproduzione sui dispositivi periferici sinistro e destro deve essere sincronizzata nel tempo. Entrambi i dispositivi periferici devono riprodurre campioni audio dalla sorgente contemporaneamente.
I dispositivi periferici possono sincronizzare il loro tempo utilizzando un numero di sequenza anteposto a ciascun pacchetto del payload audio. La centrale garantisce che i pacchetti audio destinati ad essere riprodotti contemporaneamente su ogni periferica abbiano lo stesso numero di sequenza. Il numero di sequenza aumenta di uno dopo ogni pacchetto audio. Ogni numero di sequenza è lungo 8 bit, quindi i numeri di sequenza si ripeteranno dopo 256 pacchetti audio. Poiché ogni dimensione di pacchetto audio e frequenza di campionamento è fissa per ogni connessione, le due periferiche possono dedurre il tempo di riproduzione relativo. Per ulteriori informazioni sul pacchetto audio, consulta Formato e temporizzazione del pacchetto audio .
La centrale assiste fornendo trigger ai dispositivi binaurali quando potrebbe essere necessario eseguire la sincronizzazione. Questi trigger informano ogni periferica dello stato del suo dispositivo periferico accoppiato ogni volta che c'è un'operazione che può influenzare la sincronizzazione. I trigger sono:
- Come parte del comando
«Start»di AudioControlPoint, viene fornito lo stato di connessione corrente dell'altro lato dei dispositivi binaurali. - Ogni volta che c'è un'operazione di connessione, disconnessione o aggiornamento dei parametri di connessione su una periferica, il comando
«Status»di AudioControlPoint viene inviato all'altro lato dei dispositivi binaurali.
Formato e temporizzazione del pacchetto audio
L'impacchettamento di frame audio (blocchi di campioni) in pacchetti consente all'apparecchio acustico di derivare la temporizzazione dalle ancore di temporizzazione del livello di collegamento. Per semplificare l'implementazione:
- Un frame audio dovrebbe sempre corrispondere all'intervallo di connessione nel tempo. Ad esempio, se l'intervallo di connessione è di 20 ms e la frequenza di campionamento è di 16 kHz, il frame audio conterrà 320 campioni.
- Le frequenze di campionamento nel sistema sono limitate a multipli di 8kHz per avere sempre un numero intero di campioni in un fotogramma, indipendentemente dalla durata del fotogramma o dall'intervallo di connessione.
- Un byte di sequenza deve precedere i frame audio. Il byte di sequenza deve essere conteggiato con wrap-around e consentire alla periferica di rilevare la mancata corrispondenza o l'underflow del buffer.
- Un frame audio deve sempre rientrare in un singolo pacchetto LE. Il frame audio deve essere inviato come pacchetto L2CAP separato. Le dimensioni della LE LL PDU devono essere:
dimensioni del payload audio + 1 (contatore di sequenza) + 6 (4 per intestazione L2CAP, 2 per SDU) - Un evento di connessione dovrebbe essere sempre abbastanza grande da contenere 2 pacchetti audio e 2 pacchetti vuoti per un ACK per riservare la larghezza di banda per le ritrasmissioni. Si noti che il pacchetto audio potrebbe essere frammentato dal controller Bluetooth della centrale. La periferica deve essere in grado di ricevere più di 2 pacchetti audio frammentati per evento di connessione.
Per dare alla centrale una certa flessibilità, la lunghezza del pacchetto G.722 non è specificata. La lunghezza del pacchetto G.722 può variare in base all'intervallo di connessione impostato dalla centrale.
Il formato dell'ottetto di output G.722 fa riferimento al formato Rec. ITU-T G.722 (09/2012) sezione 1.4.4 "Multiplexer"
Per tutti i codec supportati da una periferica, la periferica deve supportare i parametri di connessione seguenti. Questo è un elenco non esaustivo di configurazioni che la centrale può implementare.
| Codec | Velocità in bit | Intervallo di connessione | Lunghezza CE (1M/2M PHY) | Dimensione del carico utile audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64kbit/sec | 20 ms | 5000/3750 us | 160 byte |
Avvio e arresto di un flusso audio
Prima di avviare un flusso audio, la centrale interroga le periferiche e stabilisce un comune denominatore codec. L'impostazione del flusso procede quindi attraverso la seguente sequenza:
- PSM e, facoltativamente, viene letto RenderDelay. Questi valori possono essere memorizzati nella cache dalla centrale.
- Viene aperto il canale CoC L2CAP – la periferica concederà inizialmente 8 crediti.
- Viene emesso un aggiornamento della connessione per commutare il collegamento ai parametri richiesti per il codec scelto. La centrale può eseguire questo aggiornamento della connessione prima della connessione CoC nel passaggio precedente.
- Sia l'host centrale che quello periferico attendono l'evento di completamento dell'aggiornamento.
- Riavviare il codificatore audio e reimpostare il conteggio della sequenza dei pacchetti su 0. Su AudioControlPoint viene emesso un comando
«Start»con i relativi parametri. La centrale attende una notifica di stato di successo del precedente comando«Start»dalla periferica prima dello streaming. Questa attesa dà alla periferica il tempo di preparare la propria pipeline di riproduzione audio. Durante lo streaming audio, la replica dovrebbe essere disponibile a ogni evento di connessione anche se la latenza della replica corrente potrebbe essere diversa da zero. - La periferica prende il primo pacchetto audio dalla sua coda interna (numero di sequenza 0) e lo riproduce.
La centrale emette il comando «Stop» per chiudere il flusso audio. Dopo questo comando, non è necessario che la periferica sia disponibile ad ogni evento di connessione. Per riavviare lo streaming audio, eseguire la sequenza precedente, partendo dal passaggio 5. Quando la centrale non trasmette audio, dovrebbe comunque mantenere una connessione LE per i servizi GATT.
La periferica non deve rilasciare un aggiornamento di connessione alla centrale. Per risparmiare energia, la centrale può emettere un aggiornamento della connessione alla periferica quando non è in streaming audio.