Appendice: Il protocollo Bluetooth
I
l protocollo Bluetooth è uno standard per comunicazioni wireless a corto raggio, creato per avere caratteristiche di basso costo, basso consumo, buona sicurezza nella trasmissione dei dati.A.1 Tecnica di trasmissione a radiofrequenza
Il protocollo opera nella banda ISM (Industrial, Scientific, Medical), che è di libero utilizzo, quindi soggetta ad un livello medio di interferenza piuttosto elevato; per evitare problemi di interferenze dovute all’affollamento delle frequenze, l’accesso alla banda è regolato da una normativa che impone l’uso di tecniche di trasmissione a spettro espanso, un limite alla massima potenza in trasmissione ed un limite al minimo guadagno di processo, definito come il rapporto tra la banda del segnale a spettro espanso e la banda del segnale originale.
Il protocollo Bluetooth si adegua a tale normativa adottando uno schema di trasmissione FHSS (Frequency Hopping Spread Spectrum), in cui il segnale modulante, a banda stretta, modula una portante la cui frequenza non è fissata, ma varia, ad intervalli di tempo regolari, saltellando secondo una sequenza pseudocasuale condivisa da trasmettitore e ricevitore. Nel protocollo Bluetooth le frequenze permesse alla portante sono 79, distanziate di 1 MHz l’una dall’altra, a partire da 2,402 GHz. La modulazione utilizzata è invece una GFSK (Gaussian Frequency Shift Keying), in cui uno shift positivo, nel piano della fase, della portante codifica un uno logico, mentre
uno shift negativo codifica uno zero logico; l’aggettivo “gaussiano” indica un filtraggio del segnale con un filtro gaussiano per migliorare le caratteristiche del segnale trasmesso.
La politica di accesso al canale è di tipo TDMA-TDD (Time Division Multiple Access – Time Division Duplex), e si basa su slots temporali con durata nominale di 625 µs. Come si vede in figura A.1 la trasmissione non è full duplex, ma half duplex: i due dispositivi A e B trasmettono e ricevono a turno in slot successivi, seguendo i salti di frequenza della portante.
Figura A.1: Esempio di trasmissione bidirezionale.
Le informazioni vengono trasmesse in pacchetti: di solito un pacchetto occupa uno slot, cosicché ogni pacchetto viene integralmente trasmesso su una frequenza diversa, ma è possibile estendere la durata di un pacchetto fino a cinque slots. I pacchetti possono contenere dati generici (link ACL) o dati audio (link SCO).
Utilizzando la tecnica di trasmissione descritta il protocollo riesce a supportare, su un solo canale fisico, un collegamento dati asincrono, fino a tre canali audio sincroni o un canale misto dati-voce. La banda massima per un canale dati unidirezionale è di 732,2 Kbps, mantenendo 57,6 Kbps nella direzione inversa; volendo implementare una trasmissione simmetrica il data rate massimo è 433,9 Kbps in entrambe le direzioni. Ogni singolo canale audio supporta traffico “full duplex” a 64 Kbps, consentendo così la trasmissione di audio in qualità telefonica (4 KHz di banda).
A.2 Il Bluetooth nelle reti
Il Bluetooth consente la creazione di reti, chiamate piconets, composte da un massimo di otto nodi e caratterizzate dalla sequenza di salto della portante. La piconet ha struttura gerarchica, infatti al suo interno si distingue un nodo master che ha il compito (e l’onere) di controllare tutti gli altri nodi, detti slaves. All’interno di una piconet possono avvenire sia trasmissioni punto-punto che punto - multipunto, ma gli slaves possono comunicare solo con il master e non tra loro, a meno di non creare tra loro un’altra piconet: è infatti prevista la possibilità di interconnettere tra loro più piconets attraverso dei nodi ponte che partecipano ad almeno due piconet, creando così una rete più ampia chiamata scatternet. Il numero massimo di piconet che possono concorrere alla formazione di una scatternet in uno spazio ristretto è indicato in dieci, a causa del fatto che le frequenze di salto sono solo 79, e all’aumentare del numero delle piconets, aumenta ,fino a non essere più trascurabile, anche il rischio di collisioni. Ovviamente un nodo ponte non può essere il master di entrambe le piconets a cui appartiene; di solito le piconets sono strutturate gerarchicamente all’interno della scatternet,
cosicché un nodo slave della piconet superiore è il master della piconet gerarchicamente inferiore, secondo lo schema in figura A.2
Figura A.2: Esempio di scatternet
Affinché un dispositivo possa connettersi ad un altro, a formare una piconet, è necessaria una procedura di mutua autenticazione, che sarà condotta dal dispositivo che vuole creare la piconet ed assumerne il ruolo di master. In questa fase infatti un dispositivo può comportarsi in due modi: se non vuole creare una rete, ma è disposto a far parte di una piconet creata da
un altro dispositivo, allora si porrà in modalità “discoverable”; se invece vuole essere lui a creare e gestire la piconet, allora si porrà in modalità “non discoverable”, e avvierà una procedura di “inquiry”, inviando nel contempo il suo indirizzo fisico, dedicata a scoprire se esistono, e di che tipo sono, i dispositivi presenti nell’area di copertura della radio. I dispositivi in modalità
“discoverable” risponderanno alla inquiry portandosi in modalità “inquiry scanning” ed inviando in risposta al master i loro indirizzi fisici, che sono stati programmati su una memoria non volatile al momento della costruzione. L’indirizzo fisico del master viene quindi usato per stabilire la sequenza di salto della frequenza portante. A questo punto il master può avviare la connessione vera e propria con i dispositivi slave che gli interessano, tramite la procedura di “pairing”, in cui ogni slave negozia con il master una chiave di decrittaggio del segnale, detta “link key”.
E’ opportuno accennare ai meccanismi di sicurezza adottati dal Bluetooth:
la trasmissione FHSS è già intrinsecamente sicura dal punto di vista delle intercettazioni, ma il numero ridotto delle possibili frequenze di salto renderebbe sufficiente porre 79 ricevitori in parallelo, sintonizzati su tutte le frequenze di trasmissione, per riuscire comunque a ricostruire il segnale. Per evitare dunque intromissioni non desiderate, il protocollo Bluetooth supporta il criptaggio del segnale e l’autenticazione dei dispositivi; l’autenticazione è ottenuta usando la link key, ricavata durante la fase di pairing a cui si è già accennato, mentre il criptaggio è basato su una chiave a 128 bits, diversa dalla link key ma ricavata da questa, oltre che dall’indirizzo fisico del master e da un numero casuale. Secondo uno studio in cui si è sottoposto il meccanismo di cifratura a diversi attacchi, la complessità dell’algoritmo più leggero (di tipo
“birthday type” che ha portato a buon fine l’attacco è di 266.
A.3. Il risparmio energetico
Come si è detto il Bluetooth è stato creato per avere caratteristiche di basso consumo: per ottemperare a queste specifiche rende disponibili tre modalità per il risparmio di energia, chiamate sniff, hold e park.
Nella modalità sniff viene ridotta la frequenza con cui uno slave “ascolta”
le trasmissioni del master, che a questo può trasmettere a quello slave solo in particolari slot, distanziati tra loro da un intervallo di tempo detto TSNIFF; nella modalità hold viene interrotta, fino a nuovo ordine, la comunicazione di pacchetti ACL, ma resta possibile la comunicazione di dati audio su link SCO; infine in modalità park il dispositivo non partecipa più alle comunicazioni, pur restando connesso alla piconet: in tal modo il consumo è estremamente ridotto, ma è necessario più tempo per “risvegliare” il dispositivo.
A.4. Lo stack di protocollo
Allo scopo di garantire la comunicabilità fra dispositivi costruiti da fabbricanti diversi, le specifiche di protocollo non definiscono solamente le caratteristiche del sistema radio, ma anche quelle del protocollo di comunicazione. Tale protocollo è organizzato secondo una struttura stratificata, in cui ogni strato, o layer, usa i servizi offerti dai layers sotto di lui per offrire i suoi servizi ai layers sopra di lui. Nella comunicazione tra due dispositivi ogni layer comunica con il suo omologo presente sull’altro dispositivo: quindi in una sola connessione fisica si creano tante connessioni logiche quanti sono i layers utilizzati. Uno schema della gerarchia dei layers è visibile in figura A.3: si dà ora una sommaria descrizione delle funzionalità dei singoli layers.
• il baseband and RF si occupa di gestire la connessione fisica tra dispositivi, implementando la correzione degli errori, il criptaggio, la formazione dei pacchetti trasmessi in aria;
• il link manager è responsabile della creazione dei link ACL e SCO, delle operazioni di inquiry e della gestione delle modalità di basso consumo
Figura A.3: Lo stack di protocollo
• l’HCI (host controller interface) non è un layer vero e proprio, ma serve per l’interfacciamento tra host e host controller: nel gergo Bluetooth si dice host controller, in un sistema basato su un chipset Bluetooth affiancato da un processore esterno, il chipset bluetooth stesso, mentre il processore esterno è chiamato host. L’HCI, tramite due sottolayer (HCI bottom e HCI top) fornisce un metodo uniforme di accesso alle potenzialità in banda base del Bluetooth favorendo il partizionamento dello stack fra i due processori;
• l’L2CAP (Logical Link Control and Adaptation Protocol) consente ai layers superiori di avere una visione semplificata di quelli inferiori, ad esempio
inviando pacchetti più lunghi di quelli che possono effettivamente essere trasmessi in aria;
• l’SDP (Service Discovery Protocol) permette ad un dispositivo di individuare i servizi di cui potrebbe usufruire connettendosi agli altri dispositivi presenti all’interno della sua portata;
• il TCS bin (Telephony Control – binary) è un protocollo bit oriented per il supporto di telefonia cordless attraverso l’interfaccia aerea Bluetooth.
• l’RFCOMM permette di emulare una porta seriale, supportando anche i segnali di handshake RTS e CTS;
Come detto è il layer HCI che consente il partizionamento del sistema in due sottosistemi; se per le comunicazioni tra host e host controller si sceglie di utilizzare una porta UART, si deve far riferimento, per il formato dei dati, all’HCI UART Transfer Layer. Questo stabilisce che i dati devono essere trasmessi e ricevuti in pacchetti, il cui formato dipende dal tipo di dati che il pacchetto porta; esistono quattro tipi di pacchetti, cioè pacchetti comando, evento, SCO, ACL. Il tipo del pacchetto è stabilito da un byte che viene trasmesso subito prima del pacchetto stesso, chiamato “indicatore”; in figura A.4 si vede l’associazione fra indicatori e pacchetti, e si evidenziano le direzioni in cui i pacchetti possono muoversi.
Figura A.4: Indicatori di pacchetto.
I formati dei pacchetti, diverso da tipo a tipo, sono visibili nella figura A.5: in generale ogni pacchetto è dato dall’unione di un “header” e di un
“corpo”, contenente i dati veri e propri.
Figura A.5: dall'alto verso il basso, il formato dei pacchetti ACL, SCO, evento, comando.
A.5. L’audio nel Bluetooth
E’ già stato detto che i segnali audio viaggiano, nello standard Bluetooth, su canali privilegiati detti link SCO, che implementano dei collegamenti punto-punto fra il master ed uno slave specifico. La release 1.1 del protocollo Bluetooth supporta audio in qualità telefonica, con campioni su 8 bits campionati a 8 KSPS in modo da avere una banda di 4KHz, come insegna il teorema di Nyquist.
L’aggettivo “privilegiati” si riferisce al fatto che i pacchetti relativi ai links SCO vengono trasmessi in aria su slot riservati, ad intervalli di tempo regolari detti TSCO, allo scopo di preservare la coerenza temporale dell’audio. I pacchetti SCO non vengono mai ritrasmessi, com’è naturale essendo vettori di dati audio, anche se viene riscontrato un errore di ricezione. Esistono tre tipi di pacchetti SCO, che rappresentano vari compromessi tra occupazione di banda e resistenza agli errori di trasmissione: tali pacchetti vengono definiti HV1, HV2 e HV3 e, in comune, hanno la lunghezza del campo contenente i dati (payload), fissata per tutti e tre i tipi di pacchetto a 240 bits. Quello che differenzia i tre tipi di pacchetto è la quantità di informazione trasmessa per pacchetto; in un pacchetto HV1 i byte vengono trasmessi con un FEC (Forward Error Correction) rate pari ad 1/3, cioè ogni singolo bit viene trasmesso tre volte consecutive, mentre nei pacchetti HV2 e HV3 il FEC rate è pari a 2/3 e 3/3, ovvero bit trasmessi, rispettivamente, due volte ed una sola volta. All’interno di un pacchetto, dunque, i byte di informazione “veri”
sono 10 per l’HV1, 20 per l’HV2 e 30 per l’HV3. Per mantenere il data rate medio costante e pari a 64KBps per i tre tipi di pacchetto, i pacchetti HV1 vengono trasmessi ogni due slot temporali, gli HV2 ogni 4 slot e gli HV3 ogni 6.
Figura A.6: Modalità di trasmissione dei pacchetti SCO
Per i limiti di banda del protocollo all’interno di una piconet possono esistere contemporaneamente ed esclusivamente, al massimo o un link SCO con pacchetti HV1, o due collegamenti con pacchetti HV2 oppure ancora tre collegamenti con pacchetti HV3; in generale sarebbe bene non saturare la banda con l’audio, anche perché, nella maggior parte delle applicazioni, la correzione degli errori non aggiunge miglioramenti percettibili alla qualità dell’audio.
A.6. I profili
Per concludere, si danno alcune note sul concetto di “profilo”. Vengono chiamate “profili” le specifiche di un gruppo di applicazioni che permettono di semplificare la progettazione e l’interoperabilità tra vari dispositivi. I profili sono organizzati gerarchicamente e discendono tutti da un profilo generico, il
“Generic Access Profile” che definisce le regole base per la creazione di canali L2CAP. Volendo realizzare un sistema che possa dirsi “Bluetooth compatibile”, è necessario, nella progettazione del codice residente, adeguarsi
ad un profilo esistente; per rendere questa condizione meno stringente il Bluetooth Special Interest Group (che è un consorzio di aziende interessate nello sviluppo della tecnologia Bluetooth) sviluppa sempre nuovi profili. In figura A.7 si vede l’organizzazione gerarchica dei profili.
Figura A.7: i profili Bluetooth
Gli auricolari utilizzati nel corso dello sviluppo di questo lavoro di tesi sono compatibili con il profilo "headset", che, come si vede, discende dal profilo Serial Port. Il profilo headset è stato creato appositamente per la gestione di auricolari per telefonia cellulare, quindi prevede il caso in cui un sistema di tipo cuffia più microfono si voglia collegare a quello che viene chiamato un audio gateway, ovvero un dispositivo Bluetooth che lavori come punto d’accesso verso un servizio di tipo audio (il telefono, appunto). Non è previsto, però, il caso in cui più dispositivi vogliano collegarsi contemporaneamente allo stesso gateway con un link audio, né quello in cui due slave della piconet vogliano comunicare fra loro per implementare la funzionalità di interfono: quindi, attenzione, gli auricolari sono compatibili
col profilo headset, ma lo stesso non si può dire per il gateway, che pure lavora benissimo con gli auricolari "headset compliant"; in parole povere, volendo vendere il sistema, non sarebbe lecito apporre sulla confezione il logo Bluetooth.
