Capitolo 1

Capitolo 1

1 Scopo del lavoro e descrizione dello standard Bluetooth.

1.1

Introduzione

In questo capitolo verrà data una breve descrizione delle caratteristiche dell’applicazione da progettare, chiarendo alcuni aspetti riguardanti la tecnologia scelta. Dopo una descrizione generale dello standard si farà una panoramica delle tipologie di reti Bluetooth. Verranno poi descritte le ragioni di scelta dello standard elencando i vantaggi del suo utilizzo in relazione al nostro progetto. Infine, verranno descritti più in dettaglio il protocollo di comunicazione Bluetooth e le modalità con cui i dati vengono trasmessi.

1.2 Considerazioni preliminari

Il Bluetooth è uno standard di comunicazione radio a corto raggio tramite il quale si possono connettere in modo wireless vari dispositivi elettronici. La tecnologia Bluetooth opera nelle frequenze tra 2,4 e 2,5 GHz nella banda denominata ISM (Industrial Scientific Medical), libera da ogni licenza di utilizzo. Inoltre, essa

avviene secondo il metodo FHSS (Frequency Hopping Spread Spectrum), in cui la frequenza non è fissata ma varia saltellando tra 79 frequenze diverse (hopping) ad intervalli regolari, seguendo una sequenza pseudocasuale. I dati possono essere trasmessi su canali sincroni (SCO) e asincroni (ACL). I primi sono tipicamente usati per il traffico audio, i secondi per i dati. Il data rate può arrivare fino a 721 kbit/s. Il range di trasmissione è di circa 10 m, una distanza tutto sommato limitata, quindi limitata è anche la potenza di trasmissione e, di conseguenza, il consumo di energia. Questo fatto risulta particolarmente importante se si pensa usare la tecnologia Bluetooth per la connessione di dispositivi alimentati da batteria, quali palmari, laptop o PDA (Personal Digital Assistant) per i quali l’autonomia risulta un requisito critico. Altre caratteristiche importanti sono l’ingombro ridotto, la sicurezza delle connessioni ed il basso costo. Tutte queste caratteristiche, in particolare l’ultima, rendono la tecnologia Bluetooth particolarmente adatta all’utilizzo veicolare: è possibile creare, a bordo di auto e motoveicoli, delle reti di dispositivi che scambiano informazioni tra loro. In questo contesto, presso il Dipartimento IET è stata realizzato una sistema che permette al conducente e al passeggero di un motoveicolo di comunicare tramite auricolari wireless montati all’interno dei caschi per mezzo di una centralina situata nel motoveicolo che raccoglie, smista ed indirizza opportunamente le informazioni provenienti dai due caschi[4]. L’uso di questa centralina wireless permette ai motociclisti non solo di comunicare in modalità di interfono, funzione che, da solo, sarebbe possibile anche senza centralina, ma di usufruire di vari servizi, gestiti sempre dalla centralina, tra cui la ricezione di chiamate tramite cellulare, da parte di uno degli occupanti del motoveicolo oppure in conferenza a tre, l’ascolto della radio e delle informazioni vocali del navigatore satellitare. La rete costituita da questi tre elementi, la centralina e i caschi, appartiene alla classe più elementare di reti Bluetooth , le piconet. Esse prevedono la presenza di un solo nodo principale, detto master (la centralina nel caso specifico), che si connette e gestisce altri nodi chiamati slave (gli auricolari) (Figura 1-1). Il tipo di connessione instaurato tra il master e gli slave è quindi del tipo punto-multipunto.

Figura 1-1 : la piconet del sistema « Piaggio »

Il progetto di tale sistema per i motoveicoli, realizzato in collaborazione con Piaggio & C. rappresenta lo spunto iniziale per questa tesi. Partendo da questo sistema vogliamo permettere agli occupanti di moto diverse di comunicare fra loro, studiando la possibilità di una scambio di informazioni fra le piconet presenti su diversi motoveicoli. Su ogni motoveicolo è presente una piconet con un master e uno o due slave: la connessione tra diverse piconet rappresenta una rete più estesa che prende il nome di scatternet. Il lavoro seguente, dunque, consiste nell’analisi del funzionamento e delle varie problematiche riguardanti le scatternet e nella realizzazione di una rete siffatta.

Centralina

MASTER

Casco 1

SLAVE

Casco 2

SLAVE

1.3 Dettagli sulla tecnologia Bluetooth

Nel paragrafo precedente è stato accennato che la tecnologia Bluetooth opera nel range di frequenze comprese tra 2,4 e 2,5 GHz e che la comunicazione è basata sul metodo FHSS secondo cui il segnale utile, a banda stretta, modula una portante la cui frequenza varia tra 79 frequenze diverse, a partire dai 2402 MHz e distanziate tra loro di 1 MHz (Figura 1-2).

Figura 1-2 : FHSS

In questo modo il segnale trasmesso occupa una banda molto più grande di quello trasmesso su una portante a frequenza fissa, ma con una densità spettrale di potenza proporzionalmente più bassa: ciò il nome di trasmissione a spettro espanso (spread spectrum). La modulazione usata è una GFSK, (Gaussian Frequency Shift Keying) con symbol rate di 1MSPS. La politica di accesso al canale è del tipo TDMA-TDD, (Time Division Multiple Access – Time Division Duplex) basata su uno slot temporale della lunghezza nominale di 625 µs, tecnica mediante la quale è possibile trasmettere più canali logici su uno stesso collegamento a radio frequenza.

Figura 1-3 : trasmissione dei pacchetti in slot temporali

La Figura 1-3 rappresenta proprio questa tecnica di trasmissione secondo la quale il master invia (in slot dispari) dei pacchetti di dati allo slave, su frequenze diverse, e lo slave gli risponde inviando dei pacchetti in slot pari su altre frequenze ancora. Quindi tutte le informazioni sono trasmesse per mezzo di pacchetti ognuno dei quali viaggia su una propria frequenza di salto. Essi possono occupare anche più di uno slot temporale e fino ad un massimo di cinque. In questo modo diventa possibile supportare sul medesimo canale fisico un collegamento dati asincrono, al più tre canali sincroni (audio), oppure un unico canale in cui sono mescolati dati e voce. Ogni canale audio supporta traffico full duplex a 64 Kbps: in questo modo diventa possibile la trasmissione di audio di qualità telefonica. Il canale dati asincrono sostiene un data rate massimo unidirezionale di 723.2 Kbps, mantenendo 57.6 Kbps nella direzione inversa, oppure, in alternativa, una trasmissione simmetrica di 433.9 Kbps.

1.4 Le reti Bluetooth

Le reti topologicamente più semplici che possono essere formate usando dispositivi Bluetooth vengono dette piconet, possono essere composte al massimo da otto elementi e sono caratterizzate dalla sequenza delle frequenze di salto seguita dai suoi membri. In essa si distingue un nodo particolare, detto Master, che ha il compito di controllare tutti gli altri, detti Slave. La Figura 1-4 rappresenta graficamente una tipica piconet, col Master raffigurato al centro e gli Slave intorno.

Figura 1-4 : Un esempio di piconet

Affinché un dispositivo possa connettersi ad un altro è assolutamente indispensabile che esso ne conosca l’indirizzo fisico, detto Bluetooth address, unico per ogni dispositivo. Di conseguenza l’azione preliminare ad ogni connessione è quella utile ad ottenere l’indirizzo dei dispositivi presenti all’interno dell’area coperta dalla radio, che viene detta inquiry, e viene sempre eseguita esclusivamente dal Master, che ha il privilegio di iniziare qualunque procedura volta a stabilire una connessione. Affinché un dispositivo sia individuabile, discoverable, per usare il

gergo mutuato dalla terminologia della specifica Bluetooth, dovrà rispondere ad una inquiry ponendosi nella modalità di inquiry scanning. È ragionevole che il Master, non dovendo rispondere ad iniziative di connessione, sia in modalità non-discoverable, ovvero tale da non rispondere ad alcuna inquiry. Tutti i nodi membri di una piconet sono, per definizione di piconet, sincronizzati su una stessa sequenza di frequenze di salto. Ogni membro della piconet stabilisce univocamente la sequenza applicando un particolare algoritmo all’indirizzo fisico ed al clock Bluetooth del Master. Il clock Bluetooth è una sorta di orologio di sistema, presente in ogni apparato e che stabilisce la temporizzazione del frequency hopping, ed è implementato con un contatore a 28 bit. Questo contatore non viene mai resettato, ed ha un ciclo approssimativo di un giorno. Per ovviare al problema della perdita di sincronia dovuto alla inevitabile discrepanza del riferimento temporale dei vari dispositivi, dovuta essenzialmente alle tolleranze sulla frequenza degli oscillatori al quarzo, i moduli impegnati in una connessioni provvedono ad effettuare delle risincronizzazioni periodiche.

In una piconet sono supportate sia connessioni punto-punto che punto-multipunto. La procedura mediante la quale il master si connette effettivamente ad uno Slave di cui conosca l’indirizzo viene detta paging. Perché la connessione possa andare a buon fine gli Slave dovranno porsi nella modalità di page scanning.

Fermi restando i limiti complessivi di banda, all’interno di una stessa piconet può essere presente un collegamento dati punto-multipunto detto ACL (Asynchronous Connection-Less) dal Master verso al più sette Slave, più un massimo di tre connessioni SCO (Synchronous Connection-Oriented). Non possono essere instaurate connessioni SCO senza aver preliminarmente stabilito un link ACL, che è indispensabile per rendere possibili tutte le operazioni di controllo della connessione. Il master può sostenere le tre connessioni SCO con uno solo o con diversi Slave, mentre questi ultimi possono supportare tre collegamenti SCO contemporanei con un singolo Master, due soltanto, invece, con Master diversi. All’interno di una stessa piconet, non possono esistere collegamenti se non fra il Master e gli Slave, per cui questi ultimi non possono comunicare direttamente, a meno di creare essi stessi una nuova piconet.

Più piconet possono comunicare fra loro per mezzo di nodi ponte che partecipano ad entrambe le piconet, formando così una scatternet, ovvero una rete composta da più piconet, fino ad un massimo di dieci in un ambiente ristretto. La Figura 1-5 rappresenta, appunto, una scatternet composta da due piconet. La prima, è costituita dal master (Bluetooth Access Point) e da un solo slave che, a sua volta, è il master della seconda piconet nella quale, invece, sono presenti tre slave. Si è già accennato che dieci è il numero limite di piconet in una scatternet in ambiente ristretto. Questa limitazione è dovuta al fatto che le frequenze di salto disponibili sono solo 79, e, aumentando il numero di piconet in un ambiente dalle ridotte dimensioni, la probabilità di collisioni cresce fino a cessare di essere trascurabile. Per un approfondimento su caratteristiche e problematiche inerenti le scatternet, si rimanda ai capitoli successivi.

Figura 1-5 : Un esempio di scatternet

Piconet 1

1.5 Sicurezza

Per quanto riguarda la sicurezza delle connessioni in una piconet, è stato già anticipato che lo standard, già intrinsecamente abbastanza sicuro grazie alla trasmissione FHSS, prevede strategie e procedure utili per aumentare il livello di protezione. La trasmissione, infatti, su frequenze variabili in modo pseudocasuale, se effettivamente rende più difficile e laborioso intercettare una trasmissione di quanto non lo sia farlo nel caso di un sistema a portante fissa, può essere ritenuta inadeguata a garantire un livello di protezione soddisfacente per un certo particolare utilizzo. Tanto per fare un esempio, un modo relativamente semplice per intercettare una comunicazione siffatta senza conoscere la sequenza delle frequenze può essere quello di disporre ricevitori in parallelo sintonizzati ognuno su una delle 79 possibili frequenze di trasmissione. Lo standard Bluetooth prevede allora la possibilità di attuare l’autenticazione dei dispositivi e il criptaggio della trasmissione.

L’autenticazione è ottenuta usando una chiave segreta condivisa fra due dispositivi, detta link key, e avviene secondo un meccanismo ad ingaggio e risposta (challenge response). In questo meccanismo distinguiamo un dispositivo che chiede di essere autenticato, il richiedente, ed un altro, il verificatore, che ha il compito di decidere se sussistono o meno le condizioni per accordare l’autenticazione. Il dispositivo verificatore manda al richiedente una parola da 128 bit detta challenge, ingaggio. Il richiedente, allora, applica un particolare algoritmo alla parola di challenge, al proprio indirizzo Bluetooth e alla link key. I 32 bit più significativi del risultato di questo calcolo vengono spediti indietro al verificatore, che conferma o meno la risposta. In caso di conferma l’autenticazione ha successo, e la procedura viene ripetuta a ruoli invertiti, permettendo l’autenticazione reciproca. La link key viene stabilita durante una particolare sessione di comunicazione chiamata pairing (o binding), che può richiedere l’inserimento di un PIN (Personal Identification Number) da parte dell’utente. Si dice allora che i due dispositivi sono accoppiati (paired) quando si sono preventivamente connessi per negoziare una link key che ora, quindi, condividono.

Il criptaggio è basato su una chiave a 128 bit, diversa dalla link key e ricavata da quest’ultima, dall’indirizzo fisico del dispositivo e da un numero casuale. È stato pubblicato uno studio in cui il meccanismo di cifratura del Bluetooth è stato messo alla prova sottoponendolo a degli attacchi. L’ordine di complessità degli algoritmi usati negli attacchi fornisce una stima indiretta della sicurezza del sistema. Un primo algoritmo ha una complessità computazionale di 2100, l’altro, del genere detto birthday-type1, di 266. A tutt’oggi non si conoscono attacchi più efficienti di questi, che, se da un lato mettono in evidenza le debolezze del sistema di cifratura, dall’altro, per la loro complessità computazionale, non hanno grande valore pratico. Essendo la sicurezza del collegamento basata essenzialmente sulla segretezza delle chiavi, eventuali malintenzionati tenteranno di entrare in possesso della link key o almeno di una sua parte. Il momento più logico per cercare di carpire la link key o almeno parte di essa è durante il pairing, durante il quale viene inserito il PIN ed i dispositivi creano la link key comune. Se l’intercettatore riesce a rubare il PIN avrà la vita molto più facile nella ricostruzione della link key. Per questo è una buona norma di sicurezza eseguire questa procedura quanto più possibile in privato, ovvero fuori dalla portata d’ascolto (e dallo sguardo) di eventuali malintenzionati, che corrisponde alla portata del sistema, ovvero circa 10 metri.

1.6 Risparmio di energia

Si è già accennato che lo standard Bluetooth propone alcune modalità per il risparmio di energia durante una connessione. Esse sono note con i nomi di sniff, hold e park, e corrispondono a tre gradi diversi di riduzione dell’attività del

1 Un attacco birthday-type sfrutta l’idea del paradosso della data di nascita. Se è molto difficile trovare una persona con la nostra stessa data di nascita, è in realtà

sorprendentemente facile, in un gruppo di persone, trovarne due nate nello stesso giorno. Fuori di metafora, è molto più facile trovare due cose uguali in un gruppo omogeneo che trovarne una uguale ad un’altra prefissata. Nell’attacco birthday-type si cercano due messaggi cifrati con la stessa chiave, analizzandone poi lo stato iniziale che, se la chiave è la stessa, deve essere identico.

dispositivo. Nella modalità sniff, la cadenza con la quale uno slave impegnato in un link ACL ascolta le trasmissioni del master, viene ridotta. Il master allora può iniziare una trasmissione verso un particolare slave solo in alcuni particolari slot, distanziati da un intervallo di tempo regolare detto Tsniff, dal valore tipico di 1 s. Un

dispositivo impegnato in un collegamento SCO non può entrare nella modalità sniff. La modalità hold riguarda solo la trasmissione di pacchetti ACL. Si dice infatti che il link ACL con uno slave viene messo in hold mode quando si desidera che esso non supporti, per una durata di tempo fissata, la trasmissione di pacchetti ACL sul canale. Va notato che in questa modalità possono continuare a sussistere eventuali collegamenti SCO. Quando, invece, un dispositivo non necessita di partecipare attivamente alla piconet ma si desidera che esso rimanga sincronizzato, può essere messo in park mode, caratterizzato da una attività, e quindi da un consumo, estremamente ridotti, con l’inconveniente, però, del tempo, relativamente lungo, occorrente a “risvegliare” il dispositivo.

1.7 Lo stack di protocollo

Per garantire l’interoperabilità fra dispositivi costruiti da fabbricanti diversi, la specifica non definisce solamente i requisiti del sistema radio, ma anche il protocollo di comunicazione, descritto nel primo volume della specifica Bluetooth. Esso è organizzato secondo una struttura stratificata, in cui ogni strato, o layer, interagendo con i layer adiacenti usa i servizi dei layer più in basso offrendone a sua volta a quelli superiori. In una comunicazione fra dispositivi Bluetooth ogni layer comunica col suo omologo presente su un altro dispositivo mediante il relativo protocollo, definito dalla specifica. Sono quindi presenti tante connessioni logiche quanti sono i layer utilizzati.

La Figura 1-6 rappresenta graficamente la struttura a strati dello stack di protocollo Bluetooth. Sono omessi soltanto alcuni layer di alto livello, quale il WAP (Wireless

Access Protocol), non indispensabili, ma utili solo per particolari applicazioni che non rientrano negli interessi di questo lavoro.

Figura 1-6 : lo stack di protocollo Bluetooth

Non sono nemmeno rappresentati i layer dell’applicazione e la sua API (Application Programming Interface), per l’ovvia ragione che non appartengono allo stack di protocollo, ma sono piuttosto peculiari del sistema da implementare. Essi comunque possono essere pensati come appoggiati al di sopra dei livelli più alti dello stack, ovvero L2CAP, TCS, SDP, RFCOMM, HCI, di cui, quindi l’applicazione utente può usare i servizi.

Segue una breve descrizione delle principali funzioni espletate dai vari layer.

1.7.1

Nello stack Bluetooth il layer più in basso viene detto Baseband e Bluetooth Radio e serve ad implementare le routine relative alla connessione fisica fra i dispositivi. In particolare esso stabilisce la sequenza delle frequenze di salto e controlla il canale fisico, forma i pacchetti dati che verranno effettivamente trasmessi in aria, implementa la correzione degli errori di trasmissione ed il criptaggio (eventuale) dei dati.

1.7.2

Questo protocollo viene adoperato per il set-up ed il controllo e sicurezza del collegamento, ed i segnali scambiati tra i Link Controller di due dispositivi non si propagano ai layer superiori.

Il Link Manager è responsabile delle operazioni di Paging e Page Scanning (quindi anche dello stabilimento di connessioni ACL e SCO), Inquiry ed Inquiry Scanning e delle modalità di basso consumo (hold, park e sniff); inoltre il Link Manager gestisce le operazioni di autenticazione e criptaggio, per cui gli algoritmi relativi sono inclusi in esso.

Il Link Manager implementa anche il meccanismo del filtraggio eventi, il quale permette lo stabilimento automatico di connessioni senza coinvolgere i layer superiori.

1.7.3

Vedremo più avanti che, nel gergo della specifica, il termine host controller indica, in un sistema basato su un core Bluetooth affiancato da un microcontrollore, il core, mentre il termine host indica il microcontrollore esterno. Esso non è un layer vero e proprio poiché né eroga servizi per i layer superiori, né comunica col suo omologo presente su un altro dispositivo, ma serve piuttosto a fornire una interfaccia di comandi per il controller di banda base e per il Link Manager, e accesso allo stato dell’hardware e ai registri di controllo. Se tutta l’applicazione risiede all’interno del core Bluetooth, l’HCI viene visto come un solo layer. Nel caso in cui l’applicazione viene spezzata tra il core Bluetooth e un processore esterno (architettura a due

processori), questa interfaccia è composta di due layer propriamente detti, chiamati HCI-top e HCI-bottom, come è illustrato in Figura 1-7, residenti rispettivamente sull’host e sull’host controller; questi due layer forniscono un metodo uniforme di accesso alle potenzialità di banda base del Bluetooth.

Figura 1-7 : l’interfaccia HCI

1.7.4

• Multiplexing di livelli più alti di protocollo.

• Segmentazione e riassemblaggio dei pacchetti di dimensioni elevate. • Gestione delle connessioni logiche con i layer superiori.

Grazie al L2CAP, è consentito l’invio di pacchetti dati più grandi di quelli permessi dalla semplice trasmissione in aria e l’invio di informazioni sulla qualità del servizio. Non è prevista la segmentazione di pacchetti audio sincroni ma soltanto di dati asincroni.

1.7.5

Questo layer permette ad un dispositivo di individuare i servizi di cui potrebbe usufruire connettendosi ad altri dispositivi Bluetooth presenti all’interno della

portata del ricetrasmettitore, e di notificare agli altri dispositivi i servizi che possono essere forniti. Per fare un esempio possiamo pensare ad un computer munito di un punto di accesso Bluetooth, e ipotizziamo di disporre di un certo numero di periferiche anch’esse dotate di tecnologia Bluetooth. Immaginiamo il caso in cui si voglia stampare un documento: in maniera del tutto automatica il punto di accesso Bluetooth del calcolatore potrà individuare quale fra le periferiche presenti offre questo servizio, e quindi connettervisi per inviare i dati di stampa.

Il SDP è tipicamente costituito dai seguenti componenti:

Sezione 7.01 Service Discovery Database, in cui vengono registrati i servizi offerti dal dispositivo locale.

Sezione 7.02 Service Discovery Server, un’interfaccia che permette di registare servizi nel Service Discovery Database, e di renderli visibili ai dispositivi remoti che ne fanno richiesta.

Sezione 7.03 Service Discovery Client, un’interfaccia che permette di esplorare i Service Discovery Database di dispositivi remoti.

1.7.6

Il TCS-Binary, è un protocollo di tipo bit-oriented, che fornisce funzionalità per il supporto di telefonia cordless attraverso l’interfaccia aerea Bluetooth. Questo layer definisce la segnalazione per il controllo della chiamata quando si vogliono stabilire o cancellare delle chiamate voce o dati tra dispositivi Bluetooth, ed alcuni servizi supplementari, come la presentazione del numero chiamante (CLIP). TCS-Binary fornisce anche un meccanismo per inviare segnali Dual-Tone Multi-Frequency (DTMF) attraverso l’interfaccia RF.

1.7.7

Il layer RFCOMM permette di emulare porte seriali attraverso il layer L2CAP, con i relativi segnali (cambiamenti di stato dell’interfaccia), secondo lo standard ETSI 07.10. Per esempio, RFCOMM può emulare una porta con lo standard RS 232, trasmettendo anche i segnali RTS e CTS.

1.8 L’audio nel Bluetooth

Qualche dettaglio su come viene trattato l’audio nei sistemi Bluetooth. I segnali audio viaggiano su canali privilegiati, detti SCO, Synchronous Connection Oriented, che implementano dei link punto-punto simmetrici fra il Master ed uno Slave specifico. L’attributo “privilegiati” si riferisce al fatto che i pacchetti dei link SCO vengono trasmessi in aria su slot riservati, ad intervalli regolari detti TSCO,

misurati in slot, a differenza degli altri canali, gli ACL, che vengono trasmessi su slot non riservati. La ragione di ciò è la necessità di mantenere la coerenza temporale dell’audio. Ricordiamo che la durata nominale di uno slot è pari a 625 µs. I pacchetti SCO non vengono mai ritrasmessi, dato che essi trasportano audio. Per quanto riguarda la trasmissione in aria si può scegliere fra tre tipi di pacchetti SCO, cioè fra HV1, HV2, HV3 (in Figura 1-8), che rappresentano ognuno un compromesso fra banda occupata e tolleranza agli errori di trasmissione. La lunghezza del campo contenente i dati utili (payload) è fissata per tutti e tre i tipi di pacchetto a 240 bit, ma la quantità di informazione trasmessa per pacchetto è diversa. Infatti i byte trasmessi nei pacchetti HV1 sono protetti con un FEC Forward Error Correction) rate di 1/3 (ogni singolo bit, cioè, viene trasmesso tre volte di fila), quelli HV2 hanno un FEC di 2/3, mentre invece non ci sono bit ridondanti nei pacchetti HV3. In questa maniera si ha che i pacchetti portano rispettivamente 10, 20 e 30 byte di informazione. I pacchetti HV1 vengono spediti ogni due slot temporali (TSCO=2) gli HV2 ogni quattro e gli HV3 ogni sei. In questa

maniera il data-rate medio è costante e pari a 64 Kbps che, con campioni profondi 8 bit, equivale ad aver audio ad 8 KBps, ovvero, secondo il teorema di Nyquist, limitato a 4 KHz, di qualità analoga, quindi, a quella telefonica. Per i limiti di banda imposti dallo standard, in una piconet possono esistere contemporaneamente ed in maniera esclusiva, al massimo un collegamento SCO con pacchetti HV1, due collegamenti SCO con pacchetti HV2 o tre collegamenti SCO con pacchetti HV3.

Figura 1-8 : la trasmissione dei pacchetti audio

1.9 I profili Bluetooth

Il secondo volume della specifica Bluetooth definisce quelli che vengono chiamati profili, ovvero delle particolari situazioni di utilizzo dei dispositivi Bluetooth, puntualizzando per ogni profilo i requisiti necessari perché un’applicazione possa essere dichiarata conforme al profilo. Per requisiti si intendono i servizi che devono essere supportati e le procedure atte ad implementare le varie funzioni, ognuna riferita ad un particolare layer dello stack. Nella versione 1.1 della specifica, volume 2, sono descritti i profili generic access, service discovery application, cordless telephony, intercom, serial port, headset, dial-up networking, fax, lan access, generic object exchange, object push, file transfer, synchronization. Nell’ottica della interoperabilità, volendo realizzare una applicazione descritta dai profili è una buona idea conformarsi ad uno di essi. Tuttavia, sebbene il Bluetooth SIG (Special Interest Group, il consorzio di aziende direttamente interessate allo sviluppo della tecnologia Bluetooth) si adoperi per aggiungere alla specifica sempre nuovi profili, capita spesso di immaginare e voler realizzare un’applicazione per cui non sia stato previsto alcun profilo. In questo caso, l’unico profilo che siamo tenuti a rispettare è il generic access profile, che definisce le procedure atte ad assicurare

l’interoperabilità più elementare, essenzialmente garantendo la capacità di un dispositivo di individuare altri apparecchi nelle vicinanze ed eventualmente connettervisi, o di essere a sua volta individuato e connesso. Tra i vari profili esistono delle relazioni di dipendenza, nel senso che alcuni di essi sfruttano gerarchicamente altri profili. Le relazioni fra i vari profili presenti nella versione 1.1 della specifica sono mostrate nella Figura 1-9. Da questa figura si vede piuttosto chiaramente come tutti i profili dipendano direttamente o indirettamente al profilo generic access.

La maggior parte, se non la totalità delle applicazioni oggi esistenti si appoggiano ai profili Bluetooth già definiti. Ricordiamo a questo proposito i dispositivi per il rimpiazzo dei cavi (profilo serial port), auricolari per telefoni cellulari (headset profile), accesso wireless ad una rete di calcolatori (LAN access profile), telefoni wireless per uso domestico (intercom profile), HID (Human Interface Devices) come mouse, tastiere, (profili serial port, generic object exchange), e via dicendo.

1.10

I pacchetti Bluetooth

Come detto prima, la comunicazione tra dispositivi avviene per mezzo di pacchetti di durata che varia da uno fino a cinque slot temporali da 625 µs ciascuno. L’ordinamento dei bit nei pacchetti segue la regola chiamata Little Endian, secondo la quale il primo bit ad essere trasmesso è quello meno significativo (LSB). Ad esempio, se voglio trasmettere su 3 bit il numero 3 (in notazione binaria 011), devo seguire l’ordine 110 e così via.

Il formato standard del pacchetto trasmesso in un canale Bluetooth è indicato in Figura 1-10.

Figura 1-10 : il formato standard dei pacchetti Bluetooth

Ogni pacchetto è suddiviso in tre entità diverse, ognuna delle quali viene trasmessa partendo dal proprio bit meno significativo. Esse sono:

Access Code – è un campo lungo 72 bit ed identifica ogni pacchetto trasmesso nel canale. Tutti i pacchetti scambiati in una data piconet hanno lo stesso access code, che, oltre ad essere usato come identificatore, ha un ruolo importante nella sincronizzazione tra due dispositivi nelle fasi di inquiry e page. Durante queste fasi il pacchetto trasmesso dall’oggetto mittente è costituito solamente da access code,

ed ha il compito di segnalare la propria identità al ricevente. Ci sono vari tipi di access code tra cui Inquiry Access Code (IAC) e Device Access Code (DAC). Il primo viene usato dal mittente nella fase di inquiry e può essere di due tipi: uno generale (GIAC), standard per tutti i dispositivi, ed uno dedicato ad una classe di dispositivi (DIAC). Il secondo, invece, viene usato sempre dal mittente nella fase di paging ed è ottenuto dai dati ricevuti in risposta all’inquiry. E’ indirizzato, quindi, solamente al dispositivo che ha risposto all’inquiry e che si appresta ad entrare nella modalità di page scan.

Header - è lungo 54 bit ed è costituito da sei sottocampi denominati: AM_ADDR, TYPE, FLOW, ARQN, SEQN e HEC, di cui quelli più utili al nostro scopo sono i primi due. Il sottocampo AM_ADDR, di 3 bit, identifica univocamente ciascuno slave della stessa piconet (al massimo 7), ed è presente sia nei pacchetti indirizzati a quello slave sia nei suoi messaggi di risposta al master. Per indicare pacchetti inviati dal master e non indirizzati a qualche particolare slave (broadcast packets), l’AM_ADDR prende il valore 000. Il sottocampo TYPE, invece, è lungo 4 bit e specifica il tipo di pacchetto attualmente in uso. La sua interpretazione è strettamente connesso al link fisico (ACL o SCO), quindi, prima di tutto bisogna sapere a quale link è associato il pacchetto per poi determinarne il tipo. Per quanto riguarda gli altri sottocampi, si può accennare che essi gestiscono il corretto invio, ricezione e sequenza dei pacchetti ACL.

Payload – può arrivare fino a 2745 bit di lunghezza ed include i dati veri e propri, che possono essere di tipo voce o altri.

Ecco un breve accenno ad alcuni tipi di pacchetti.

Pacchetto ID - un pacchetto costituito solamente dal campo access code di 68 bit, che può essere un IAC o un DAC. Si tratta di un pacchetto molto robusto dato che il ricevente, tramite un correlatore di bit, confronta con esso tutti i pacchetti ricevuti successivamente per verificare la loro provenienza. Viene usato, ad esempio, durante un inquiry, un paging o in una routine di risposta.

Pacchetto NULL – è costituito dal campo access code e dal campo header. E` lungo 126 bit e viene inviato al mittente per notificare l’esito positivo della

trasmissione del pacchetto. Non ha bisogno di un messaggio di conferma da parte del mittente.

Pacchetto POLL – è uguale al pacchetto NULL con l’unica differenza che necessita di un messaggio di conferma da parte di chi lo riceve. Viene usato dal master per “sondare” gli slave, cioè, verificare se hanno qualche informazione da inviare. Il messaggio di conferma da parte degli slave è necessario, anche se non hanno alcun dato da inviare al master.

Pacchetto FHS – è un pacchetto di controllo, costituito da tutti i sottocampi. Il suo payload ha una lunghezza di 160 bit, ma, essendo codificato in modalità 2/3 FEC, diventa di 240 bit. Viene trasmesso in un solo slot temporale e si usa più comunemente come risposta ad un inquiry, ad un paging oppure durante un master-slave switch. In inquiry, il pacchetto non necessita di una conferma da parte del master, mentre in paging esso viene ritrasmesso fino a che non sia confermato dal master, oppure fino allo scadere del tempo. Nel suo corpo, tra l’altro, ci sono l’indirizzo del dispositivo Bluetooth ed il suo clock, che viene aggiornato prima di ogni ritrasmissione del pacchetto. Da notare che quando il pacchetto FHS viene usato come risposta ad un inquiry, l’AM_ADDR del header è settato a 0, dato che la piconet non è stata ancora creata. Comunque, il pacchetto non dovrebbe essere considerato di tipo broadcast. Nel caso della risposta al paging, invece, l’AM_ADDR esiste già, e viene inserita nel campo header del pacchetto. Il campo payload è mostrato in Figura 1-11.

C’è da osservare che l’indirizzo del dispositivo (bluetooth device address - BD_ADDR), lungo 48 bit, occupa tre sottocampi: LAP, UAP e NAP, rispettivamente di 24, 8 e 16 bit. Inoltre, il penultimo sottocampo CLK, di 26 bit, contiene il clock del dispositivo, campionato ogni volta che viene trasmesso l’access code del pacchetto stesso ed aggiornato prima che il pacchetto venga ritrasmesso, per dare un sicuro punto di riferimento al master.

1.11 Scatternet e motoveicoli: primo accenno

Si è già detto che il presente lavoro nasce come studio per l’estensione di un sistema wireless già realizzato. Per capire meglio in che modo procedere chiariamo meglio la struttura del sistema dal quale stiamo traendo spunto.

Il progetto realizzato in collaborazione con Piaggio & C consiste in una rete wireless, costituita da una piconet a tre nodi: un master e due slave (in Figura 1-12). Il master (punto di accesso wireless) è situato a bordo del motoveicolo e provvede a connettersi con i due slave, situati nei caschi del conducente e del passeggero. I due caschi possono, così, comunicare tra di loro usando le connessioni SCO con il nodo master, diventando quest’ultimo il ponte di comunicazione tra di essi. Inoltre il master si preoccupa di fornire ai caschi diversi servizi quali l’ascolto della radio, la ricezione delle informazioni provenienti dal navigatore satellitare e le chiamate da e verso il cellulare con uno o entrambi i caschi realizzando così la conferenza a tre. Per fare tutto ciò esso smista in maniera opportuna i dati provenienti da tutte le sorgenti interfacciate con esso e le invia al destinatario opportuno.

Figura 1-12 : la piconet a due slave

Se il master è caratterizzato da potenza di calcolo adeguata per fornire diversi servizi ed eseguire operazioni di vario genere sui dati ricevuti, ai caschi spetta il solo compito di rispondere alla richiesta di connessione e di mantenere il collegamento radio con il punto di accesso. La ragione per cui il master si prende sulle spalle quasi tutto il carico di lavoro sta nel fatto che per esso non ci sono problemi di consumo di energia, dato che viene alloggiato sul motoveicolo, mentre i caschi, vincolati ad un’alimentazione a batteria, svolgendo il minimo delle operazioni possibili massimizzano la loro autonomia.

Quello che ci proponiamo di fare è di mettere in comunicazione due o più di questi sistemi, realizzando una scatternet. In questo senso possiamo considerare il nostro come un primo passo verso l’ampliamento del sistema. Immaginiamo che i conducenti di due o più motoveicoli vogliano comunicare tra di loro, oppure uno di

loro voglia passare una telefonata ricevuta agli altri. In questi casi le piconet, cioè i sistemi sul singolo motoveicolo, devono poter creare una connessione inter-piconet.

Figura 1-13 : una generica scatternet tra motoveicoli

In Figura 1-13 è rappresentata una scatternet generica tra 5 piconet, che rappresentano 5 diversi motoveicoli. Si nota come siano possibili tante modalità di connessione tra i nodi appartenenti a piconet diverse (rappresentate dalle frecce blu); possiamo avere delle connessioni tra master di una piconet e slave di un’altra e tra due master o due slave di diverse piconet. Da notare che ogni connessione inter-piconet tra due nodi è una connessione master-slave, quindi nelle connessioni tra due nodi master o due nodi slave, uno dei due cambia ruolo in quella determinata connessione, mentre conserva il suo ruolo precedente nella propria piconet. Il nodo che partecipa attivamente in entrambe le piconet viene tipicamente definito nodo

MASTER

MASTER MASTER

MASTER MASTER

SLAVE 2

SLAVE 1 SLAVE 1 SLAVE 2

SLAVE 2 SLAVE 1 SLAVE 2 SLAVE 1 SLAVE 2 SLAVE 1

Piconet 1 Piconet 2 Piconet 3

ponte e, dato che ogni piconet è caratterizzata da una determinata sequenza di frequency hopping, esso deve adattarsi a due sequenze diverse.

Senza perdere in generalità focalizziamo l’attenzione sulle modalità di connessione tra due sole piconet, cercando di analizzarle nell’ottica di un utilizzo specifico a bordo dei motoveicoli. L’analisi si potrebbe naturalmente allargare nel caso di più piconet, senza particolari differenze.

Le modalità di connessione di due piconet in una scatternet sono sostanzialmente di tre tipi, a seconda del nodo che svolge il ruolo di ponte. Nel primo tipo, mostrato in Figura 1-14, i due nodi master A e B stabiliscono un collegamento tra di loro, dopodiché il master A diventa uno slave (A) nella piconet B, pur continuando ad assumere il ruolo di master nella piconet A. Esso viene definito nodo ponte master-slave. Nel secondo tipo, in Figura 1-15, è lo slave 1-B della piconet B a connettersi come slave (3-A) anche al master A diventando, così, un nodo ponte slave-slave.

Figura 1-14 : la scatternet di tipo 1 MASTER A

MASTER B

SLAVE 1-A SLAVE 2-A SLAVE 1-B SLAVE 2-B

PICONET A

PICONET B

SLAVE A

NODO PONTE MASTER-SLAVE

Figura 1-15 : la scatternet di tipo 2

Figura 1-16 : la scatternet di tipo 3

MASTER A _{MASTER B}

SLAVE 1-A SLAVE 2-A SLAVE 1-B SLAVE 2-B

PICONET A

PICONET B

SLAVE 3-A NODO PONTE SLAVE-SLAVE

MASTER A MASTER B

SLAVE 1-A SLAVE 2-A

SLAVE 1-B SLAVE 2-B

PICONET A

PICONET B

PICONET C

In Figura 1-16, sono gli slave 2-A e 1-B a connettersi tra loro e a dare luogo ad una terza piconet C. Infatti, lo slave 2-A diventando il master C per la terza piconet, assume il ruolo di nodo ponte master-slave, mentre lo slave 1-B diventa il nodo ponte slave-slave.