I dispositivi acustici (HA) possono avere un'accessibilità migliorata sui dispositivi mobili basati su Android utilizzando canali L2CAP (CoC) orientati alla connessione tramite Bluetooth Low Energy (BLE). CoC utilizza un buffer elastico di diversi pacchetti audio per mantenere un flusso audio costante, anche in presenza di perdita di pacchetti. Questo buffer fornisce una qualità audio per gli apparecchi acustici a scapito della latenza.
Il design del CoC fa riferimento alla Bluetooth Core Specification Version 5 (BT). Per rimanere in linea con le specifiche di base, tutti i valori multibyte di questa pagina devono essere letti come little-endian.
Terminologia
- centrale
- Il dispositivo Android che esegue la scansione degli annunci tramite Bluetooth.
- periferica
- La protesi acustica che invia pacchetti di pubblicità tramite Bluetooth.
Topologia di rete e architettura di sistema
Quando si utilizza CoC per gli apparecchi acustici, la topologia di rete presuppone un singolo centro e due periferiche, una a sinistra e una a destra, come mostrato nella Figura 1. Il sistema audio Bluetooth considera le periferiche sinistra e destra come un unico sink audio. Se un dispositivo periferico non è presente, a causa di un adattamento monoaurale o di una perdita di connessione, il centro mixa il canale audio sinistro e destro e trasmette l'audio al dispositivo periferico rimanente. Se il dispositivo centrale perde la connessione a entrambe le periferiche, considera perso il collegamento al sink audio. In questi casi, il centro indirizza l'audio a un'altra uscita.
Figura 1. Topologia per l'accoppiamento di apparecchi acustici con
dispositivi mobili Android che utilizzano CoC su BLE.
Quando il dispositivo centrale non trasmette dati audio alla periferica e può mantenere una connessione BLE, non deve disconnettersi dalla periferica. Il mantenimento della connessione consente la comunicazione dei dati al server GATT residente sul dispositivo periferico.
Durante l'accoppiamento e la connessione degli apparecchi acustici, la centrale deve:
- Tieni traccia delle periferiche sinistra e destra accoppiate più recenti.
- Supponi che le periferiche siano in uso se esiste un accoppiamento valido. La centralina deve tentare di connettersi o riconnettersi al dispositivo accoppiato quando la connessione viene persa.
- Supponi che le periferiche non siano più in uso se un accoppiamento viene eliminato.
Nei casi precedenti, l'accoppiamento si riferisce all'azione di registrare un set di apparecchi acustici con un determinato UUID e designatori sinistro/destro nel sistema operativo, non alla procedura di accoppiamento Bluetooth.
Requisiti di sistema
Per implementare correttamente CoC e garantire una buona esperienza utente, i sistemi Bluetooth nei dispositivi centrali e periferici devono:
- implementa un controller BT 4.2 o versioni successive conforme. LE Secure Connections è vivamente consigliato.
- avere il supporto centrale di almeno due link LE simultanei con parametri come descritto in Formato e temporizzazione dei pacchetti audio.
- supporti almeno un collegamento LE con i parametri descritti in Formato e temporizzazione dei pacchetti audio.
- disporre di un controllo del flusso basato sul credito LE [BT Vol 3, Part A, Sec 10.1]. I dispositivi devono supportare una dimensione MTU e MPS di almeno 167 byte su CoC ed essere in grado di memorizzare nel buffer 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.
-
il dispositivo centrale supporti il comando di aggiornamento della connessione HCI LE
e sia conforme ai parametri
maximum_CE_Lengtheminimum_CE_Lengthdiversi da zero. - il centro mantenga la velocità effettiva dei dati per due connessioni LE CoC a due periferiche diverse con gli intervalli di connessione e le dimensioni del payload nel formato e nella tempistica dei pacchetti audio.
-
il dispositivo periferico deve impostare i parametri
MaxRxOctetseMaxRxTimenei frameLL_LENGTH_REQoLL_LENGTH_RSPsui valori minimi richiesti necessari per queste specifiche. In questo modo, l'unità centrale ottimizza il proprio pianificatore temporale quando calcola la quantità di tempo necessaria per ricevere un frame.
È vivamente consigliato che il dispositivo centrale e quello periferico supportino PHY da 2 MB come specificato nella specifica BT 5.0. Il dispositivo centrale deve supportare collegamenti audio di almeno 64 kbit/s su PHY da 1 M e 2 M. Non deve essere utilizzato il PHY a lungo raggio BLE.
CoC utilizza i meccanismi Bluetooth standard per la crittografia del livello di collegamento e il salto di frequenza.
Servizi GATT ASHA
Una periferica deve implementare il servizio server GATT Audio Streaming for Hearing Aid (ASHA) descritto di seguito. La periferica deve pubblicizzare questo servizio quando è in modalità di rilevamento generale per consentire al dispositivo centrale di riconoscere un sink audio. Tutte le operazioni di streaming LE audio devono richiedere la crittografia. Lo streaming audio BLE è caratterizzato dalle seguenti caratteristiche:
| Caratteristica | Proprietà | Descrizione |
|---|---|---|
| ReadOnlyProperties | Leggi | Vedi ReadOnlyProperties. |
| AudioControlPoint | Scrivi e Scrivi senza risposta | Punto di controllo per lo stream audio. Vedi AudioControlPoint. |
| AudioStatusPoint | Lettura/Notifica | Campo del report di stato per il punto di controllo audio. Vedi 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 silenziata, ovvero il livello di volume non silenziato più basso è -127, che equivale a un'attenuazione di -47,625 dB. Con l'impostazione 0, un tono sinusoidale rail-to-rail in streaming deve rappresentare un ingresso equivalente di 100 dBSPL sull'apparecchio acustico. La centrale deve trasmettere in scala nominale e utilizzare questa variabile per impostare il livello di presentazione desiderato nella periferica. |
| LE_PSM_OUT | Leggi | PSM da utilizzare per connettere il canale audio. Da scegliere dall'intervallo dinamico [BT Vol 3, Part A, Sec 4.22] |
Gli UUID assegnati al servizio e alle caratteristiche:
UUID servizio: {0xFDF0}
| Caratteristica | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| Volume | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
Oltre al servizio GATT ASHA, la periferica deve implementare anche il servizio informazioni dispositivo per consentire al dispositivo centrale di rilevare i nomi dei produttori e i nomi dei dispositivi della periferica.
ReadOnlyProperties
ReadOnlyProperties ha i seguenti valori:
| Byte | Descrizione |
|---|---|
| 0 | Versione: deve essere 0x01 |
| 1 | Consulta DeviceCapabilities. |
| 2-9 | Vedi HiSyncId. |
| 10 | Vedi FeatureMap. |
| 11-12 | RenderDelay. Questo è il tempo, in millisecondi, che intercorre tra il momento in cui la periferica riceve un frame audio e il momento in cui la periferica esegue il rendering dell'output. Questi byte possono essere utilizzati per ritardare un video in modo da sincronizzarlo con l'audio. |
| 13-14 | Riservato per l'uso futuro. Inizializza a zero. |
| 15-16 | ID codec supportati. Si tratta di 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 su 0. |
DeviceCapabilities
| Bit | Descrizione |
|---|---|
| 0 | Lato del dispositivo (0: sinistra, 1: destra) |
| 1 | Indica se il dispositivo è autonomo e riceve dati mono o se fa parte di un set (0: monaurale, 1: binaurale) |
| 2 | Il dispositivo supporta CSIS (0: non supportato, 1: supportato) |
| 3-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. Si tratta degli identificatori dell'azienda assegnati da BTSIG. |
| 2-7 | ID univoco che identifica l'apparecchio acustico. Questo ID deve essere impostato sullo stesso valore sia per la periferica sinistra che per quella destra. |
FeatureMap
| Bit | Descrizione |
|---|---|
| 0 | Supporto dello streaming dell'output audio LE CoC (Sì/No). |
| 1-7 | Riservato (impostato su 0). |
ID codec
Se il bit è impostato, il codec specifico è supportato.
| ID / Numero di bit | Codec e frequenza di campionamento | Velocità in bit richiesta | Durata frame | Obbligatorio su centrale (C) o periferica (P) |
|---|---|---|---|---|
| 0 | Riservata | Riservata | Riservata | Riservata |
| 1 | G.722 a 16 kHz | 64 kbit/s | Variabile | C e P |
|
I numeri da 2 a 15 sono riservati. Anche 0 è riservato. |
||||
AudioControlPoint
Questo punto di controllo non può essere utilizzato quando il LE CoC è chiuso. Per la descrizione della procedura, consulta Avvio e interruzione di un flusso audio.
| Opcode | Argomenti | Sottoprocedura GATT | Descrizione |
|---|---|---|---|
1 «Start» |
|
Scrivi con risposta e prevedi una notifica di stato aggiuntiva tramite la caratteristica AudioStatusPoint. |
Indica alla periferica di reimpostare il codec e avviare la
riproduzione del frame 0. Il campo codec indica l'ID codec da utilizzare
per questa riproduzione.
Ad esempio, il campo del codec è "1" per G.722 a 16 kHz. Il campo bit del tipo di audio indica i tipi di audio presenti nel flusso:
La periferica non deve richiedere aggiornamenti della connessione prima di ricevere un opcode «Stop».
|
2 «Stop» |
Nessuno | Scrivi con risposta e prevedi una notifica di stato aggiuntiva tramite la caratteristica AudioStatusPoint. | Indica alla periferica di interrompere il rendering dell'audio. Dopo l'interruzione, deve essere avviata una nuova sequenza di configurazione audio per riprodurre di nuovo l'audio. |
3 «Status» |
|
Scrivere senza risposta |
Informa la periferica connessa che è disponibile un aggiornamento dello stato dell'altra periferica. Il campo connesso indica il tipo di aggiornamento:
|
AudioStatusPoint
Campo del report di stato per il punto di controllo audio
| Codici operativi | Descrizione |
|---|---|
| 0 | Stato OK |
| -1 | Comando sconosciuto |
| -2 | Parametri illegali |
Annunci per il servizio GATT di ASHA
L'UUID del servizio deve essere presente nel pacchetto di pubblicità. Nell'annuncio o nel frame di risposta della scansione, le periferiche devono avere un Service Data:
| Offset byte | Nome | Descrizione |
|---|---|---|
| 0 | AD Length | >= 0x09 |
| 1 | Tipo di annuncio | 0x16 (dati di servizio - UUID a 16 bit) |
| 2-3 | UUID servizio |
0xFDF0 (little-endian) Nota:questo è un ID temporaneo. |
| 4 | Versione protocollo | 0x01 |
| 5 | Funzionalità |
|
| 6-9 | HiSyncID troncato | I quattro byte più significativi di HiSyncId. Questi byte devono 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 giusto. Il nome non deve indicare il canale sinistro o destro, poiché queste informazioni sono fornite in DeviceCapabilities.
Se le periferiche inseriscono i tipi di dati del nome e del servizio ASHA nello stesso tipo di frame (ADV o SCAN RESP), i due tipi di dati ("Complete Local Name" e "Service Data for ASHA service") devono essere visualizzati nello stesso frame. In questo modo, lo scanner del dispositivo mobile ottiene entrambi i dati nello stesso risultato di scansione.
Durante l'accoppiamento iniziale, è importante che le periferiche pubblichino annunci a una velocità sufficiente per consentire al dispositivo mobile di scoprirle rapidamente e accoppiarsi.
Sincronizzare le periferiche sinistra e destra
Per funzionare con il Bluetooth sui dispositivi mobili Android, i dispositivi periferici sono responsabili della sincronizzazione. La riproduzione sui dispositivi periferici sinistro e destro deve essere sincronizzata nel tempo. Entrambe le periferiche devono riprodurre contemporaneamente i campioni audio dalla sorgente.
I dispositivi periferici possono sincronizzare l'ora utilizzando un numero di sequenza anteposto a ogni pacchetto del payload audio. L'unità centrale garantisce che i pacchetti audio che devono 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 ripetono dopo 256 pacchetti audio. Poiché le dimensioni di ogni pacchetto audio e la frequenza di campionamento sono fisse per ogni connessione, le due periferiche possono dedurre il tempo di riproduzione relativo. Per ulteriori informazioni sul pacchetto audio, vedi Formato e sincronizzazione del pacchetto audio.
Il centro assiste fornendo trigger ai dispositivi binaurali quando potrebbe essere necessario eseguire la sincronizzazione. Questi trigger informano ogni periferica sullo stato del dispositivo periferico accoppiato ogni volta che si verifica un'operazione che potrebbe influire sulla sincronizzazione. I trigger sono:
-
Nell'ambito del comando
«Start»di AudioControlPoint, viene fornito lo stato attuale della connessione dell'altro lato dei dispositivi binaurali. -
Ogni volta che viene eseguita 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 sincronizzazione dei pacchetti audio
Il raggruppamento dei frame audio (blocchi di campioni) in pacchetti consente all'apparecchio acustico di derivare la sincronizzazione dagli ancoraggi di sincronizzazione del livello di collegamento. Per semplificare l'implementazione:
- Un frame audio deve sempre corrispondere all'intervallo di connessione nel tempo. Ad esempio, se l'intervallo di connessione è 20 ms e la frequenza di campionamento è 16 kHz, il frame audio deve contenere 320 campioni.
- Le frequenze di campionamento nel sistema sono limitate ai multipli di 8 kHz per avere sempre un numero intero di campioni in un frame, indipendentemente dal tempo del frame 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. La dimensione della PDU LE
LL deve essere:
dimensione del payload audio + 1 (contatore di sequenza) + 6 (4 per l'intestazione L2CAP, 2 per la SDU) - Un evento di connessione deve essere sempre abbastanza grande da contenere due pacchetti audio e due pacchetti vuoti per un ACK per riservare la larghezza di banda per le ritrasmissioni. Tieni presente che il pacchetto audio potrebbe essere frammentato dal controller Bluetooth della centrale. La periferica deve essere in grado di ricevere più di due pacchetti audio frammentati per evento di connessione.
Per dare un po' di flessibilità alla centrale, la lunghezza del pacchetto G.722 non è specificata. La lunghezza del pacchetto G.722 può variare in base all'intervallo di connessione impostato dal dispositivo centrale.
Il formato ottetto di output G.722 fa riferimento alla Rec. ITU-T G.722 (09/2012) sezione 1.4.4 "Multiplexer"
Per tutti i codec supportati da una periferica, quest'ultima deve supportare i parametri di connessione riportati di seguito. Questo è un elenco non esaustivo delle configurazioni che la centrale può implementare.
| Codec | Velocità in bit | Intervallo di connessione | CE Length (1M/2M PHY) | Dimensioni payload audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 us | 160 byte |
Avviare e interrompere un flusso audio
Prima di avviare uno stream audio, l'unità centrale interroga le periferiche e stabilisce un codec denominatore comune. La configurazione dello stream procede quindi attraverso la seguente sequenza:
- PSM e, facoltativamente, RenderDelay vengono letti. Questi valori potrebbero essere memorizzati nella cache del centro.
- Viene aperto il canale L2CAP CoC. Il dispositivo periferico deve concedere inizialmente 8 crediti.
- Viene emesso un aggiornamento della connessione per passare il link ai parametri richiesti per il codec scelto. La centrale può eseguire questo aggiornamento della connessione prima della connessione CoC nel passaggio precedente.
- L'host centrale e quello periferico attendono l'evento di completamento dell'aggiornamento.
-
Riavvia il codificatore audio e reimposta il conteggio della sequenza di pacchetti su 0.
Un comando
«Start»con i parametri pertinenti viene emesso su AudioControlPoint. La centrale attende una notifica di stato riuscita del comando«Start»precedente dalla periferica prima dello streaming. Questa attesa consente alla periferica di preparare la pipeline di riproduzione audio. Durante lo streaming audio, la replica deve 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.
Il centro invia il comando "Stop" per chiudere lo stream audio. Dopo questo comando, la periferica non deve essere disponibile a ogni evento di connessione. Per riavviare lo streaming audio, segui la sequenza sopra riportata, a partire dal passaggio 5. Quando il dispositivo centrale non trasmette audio in streaming, deve comunque mantenere una connessione LE per i servizi GATT.
La periferica non deve inviare un aggiornamento della connessione al dispositivo centrale. Per risparmiare energia, la centrale potrebbe inviare un aggiornamento della connessione alla periferica quando non riproduce audio in streaming.