Bluetooth
Cenni storici
I primi studi sulla tecnologia Bluetooth partono nel 1994, quando la Ericsson Mobile
Communication intraprende una serie di studi allo scopo di trovare delle alternative
wireless per il collegamento tra telefoni e accessori (es. auricolari). Lo studio riguarda
un collegamento radio che, non essendo direzionale, non necessita della cosiddetta “line
of sight”, cioè della visibilità diretta, ed ha quindi degli evidenti vantaggi rispetto alle
tecnologie infrarossi precedentemente utilizzate per collegare tra loro cellulari e
dispositivi vari.
Nel febbraio 1998 nasce il SIG (Special Interest Group), che è un gruppo di compagnie
leader del settore delle telecomunicazioni e dell’elettronica, tra cui Ericsson, Nokia,
Intel, IBM e Toshiba, che lavorano assieme per promuovere e definire le specifiche
Bluetooth. In seguito entrano a far parte del SIG anche Microsoft, Lucent, 3Com e
Motorola; al giorno d’oggi il SIG comprende più di 2000 compagnie.
Nel luglio 1999 viene pubblicata la versione 1.0 delle specifiche Bluetooth, che viene
seguita nel dicembre 1999 dalla versione 1.0b. Nel febbraio 2001 esce la versione 1.1,
mentre sono ancora in fase di definizione le versioni 1.2 e 2.0.
BLUETOOTH
Generalità
Bluetooth è una tecnologia radio studiata appositamente per trasmissioni a corto raggio
(tipicamente 10 m) ed è caratterizzata da un bassissimo consumo di potenza, da un
basso costo e da una bassa complessità. Queste caratteristiche consentono a Bluetooth
di proporsi come la tecnologia del futuro nel campo delle comunicazioni wireless per
apparecchi di piccole dimensioni alimentati a batteria. Inoltre è studiata anche per
connettere e fare interagire tra di loro dispositivi diversi (telefoni, stampanti, notebook,
PDA, impianti HiFi, TV, PC, cellulari, elettrodomestici, etc ), come riportato in Figura
1.
Figura 1: Campi di utilizzo di Bluetooth
Bluetooth permette anche di accedere a reti locali (LAN) tramite dei dispositivi
denominati Access Point, nonché alla rete pubblica PSTN (Public Switched Telephon
Network) e alla rete di telefonia mobile.
Lo standard Bluetooth consente ai dispositivi di connettersi e comunicare tra loro in una
regione limitata attraverso una rete ad hoc chiamata piconet (Figura ), che è costituita
da un massimo di otto dispositivi attivi, di cui uno è il master, ossia colui che inizia lo
scambio di dati, e gli altri sette sono gli slave, che funzionano in risposta al master, e
non hanno altri collegamenti oltre a quello col master. Inoltre è possibile avere fino a
200 dispositivi in modalità “park”, cioè che non possono essere attivi nello scambio di
dati col master, ma che restano sincronizzati con esso.
48
BLUETOOTH
Figura 2: Esempio di piconet
Caratteristica importante dei dispositivi Bluetooth è la loro capacità di creare e
riconfigurare dinamicamente queste piconet senza richiedere l’intervento umano. Infatti
se un dispositivo entra o esce dalla zona coperta dal master viene riconosciuto o tolto
dalla rete automaticamente. Questo grazie all’operazione di inquiry, attraverso la quale
i dispositivi Bluetooth periodicamente sono in grado di scoprire l’esistenza di altri nelle
vicinanze.
Questa possibilità di configurazione automatica permette, ad esempio, di sincronizzare i
dati di un PC portatile e un PDA semplicemente avvicinando i due apparecchi oppure
di passare automaticamente al vivavoce quando si entra in auto parlando al cellulare,
fino al caso di un operatore industriale che con un palmare può muoversi all’interno di
una fabbrica e monitorare e configurare i vari macchinari in maniera veloce ed
efficiente. Tutto questo è possibile grazie al "Service Discovery Protocol" (SDP), che
permette ad un dispositivo Bluetooth di determinare quali sono i servizi che gli altri
apparecchi presenti nella piconet mettono a disposizione. Tale protocollo può fungere
sia da server (ossia può essere interrogato da un altro dispositivo e rispondere con i
propri servizi) sia da client (interrogando gli altri dispositivi) e ogni apparecchio
dispone delle informazioni relative ai servizi di cui è capace e dei protocolli supportati:
altri apparati potranno fare uso di queste informazioni per determinare le possibilità di
interazione con i nodi della piconet. Questo è necessario perché, naturalmente, una
stampante Bluetooth non offre le stesse possibilità di un PDA o di un’auricolare,
pertanto occorre che ogni nodo conosca le funzioni e le possibilità di ogni altro nodo
49
BLUETOOTH
della rete. Per fare un esempio concreto, se un telefonino Bluetooth vuole trasferire un
messaggio di testo a un PDA, potrà interrogare quest’ultimo per sapere se è dotato di
funzionalità e-mail, o se è in grado di ricevere un testo in altro modo. Quando un
dispositivo si inserisce per la prima volta in una piconet, inoltre, effettuerà una
"scansione" di tutti i nodi presenti per capire come può interagire con essi.
Altra caratteristica importante dei dispositivi Bluetooth è quella di poter essere presenti
in più di una piconet contemporaneamente, e di poter addirittura funzionare da master
in una piconet e da slave nell’altra. Un gruppo di piconet legate tra loro viene chiamata
scatternet (Figura 3).
Figura 3: Esempio di scatternet
Lo standard Bluetooth opera nella banda libera ISM (Industrial, Scientific and Medical)
centrata attorno ai 2.4 GHz. Questa banda è occupata da un elevato numero di
emettitori RF, dalle applicazioni wireless proprietarie, allo standard Wireless Ethernet
(IEEE 802.11b), fino ad arrivare a generatori di rumore come i forni a microonde e le
lampade al sodio da strada. Ciò ha reso necessario l’utilizzo di una tecnica di
modulazione robusta alle interferenze: si è scelto una 2-FSK con il frequency hopping
come tecnica di spread spectrum (FHSS).
Questo sistema di comunicazione funziona secondo uno schema Time Division
Multiplexing (TDM), dove l’unità base di operazione è uno slot di durata pari a 625 μs.
Quando i dispositivi sono connessi, negli slot pari è abilitato a trasmettere il master,
mentre negli slot dispari sono abilitati a rispondere gli slave, uno alla volta; in
50
BLUETOOTH
particolare può rispondere lo slave che aveva ricevuto dati dal master nello slot
precedente. In Figura 4 è mostrato un esempio di scambio di dati tra un master e 2
slave.
Figura 4: Scambio di dati tra master e due slave
L’utilizzo della tecnica FHSS comporta che ogni time slot sia caratterizzato da una
frequenza di trasmissione differente, secondo una sequenza di valori frequenziali decisi
dal master seguendo un particolare algoritmo di calcolo del frequency hopping.
Il bitrate massimo raggiungibile in aria è pari a 1 Mbps.
Lo stack Bluetooth
Una chiave delle specifiche Bluetooth è il fatto che esse permettono a dispositivi di
diverse case di lavorare tra di loro, in quanto non definiscono solo un sistema di
trasmissione radio, ma definiscono uno stack software completo per consentire alle
applicazioni di trovare dispositivi Bluetooth nella zona, scoprirne i servizi offerti e
utilizzarli.
Lo stack Bluetooth è definito da una serie di livelli, come si può vedere in Figura 5:
51
BLUETOOTH
Figura 5: Stack Bluetooth
Ciascun blocco di Figura 5 corrisponde a un capitolo delle specifiche Bluetooth;
ciascun livello dello stack verrà descritto dettagliatamente nei paragrafi successivi.
Confrontando lo stack Bluetooth con il più familiare modello di riferimento OSI per i
protocolli di comunicazione (Figura 6), si può notare come i due modelli non
coincidano esattamente tra di loro.
Figura 6: Modello di riferimento OSI e Bluetooth
52
BLUETOOTH
La Figura 6 può comunque aiutare per capire che tipo di relazione c’è tra un livello del
modello OSI e un livello dello stack Bluetooth.
Segue ora una descrizione dettagliata di ciascun livello dello stack Bluetooth, con
particolare attenzione rivolta al livello Radio, specialmente per i vari ritardi in
trasmissione e ricezione, e ai livelli HCI e L2CAP, ossia i livelli ai quali verrà
sviluppato il software a microcontrollore per il controllo del modulo Bluetooth.
53
BLUETOOTH
Radio
Modulazione
Il ricetrasmettitore Bluetooth opera nella banda ISM centrata attorno ai 2.4 GHz.
Utilizza una modulazione di tipo 2-FSK, ossia una modulazione numerica che trasmette
una certa frequenza per il livello logico alto, e un’altra per il livello logico basso.
L’informazione digitale viene prefiltrata con un impulso Gaussiano, in modo che il
passaggio da una frequenza all’altra non avvenga in modo brusco e si ottenga, quindi,
una minore occupazione di banda. Essendo la banda ISM molto rumorosa, è necessario
adottare delle tecniche di spread spectrum, in modo da limitare la probabilità d’errore.
In particolare si utilizza la tecnica del frequency hopping (FHSS), che consiste nello
sparpagliare il segnale su una banda maggiore facendo cambiare in continuazione la
frequenza della portante.
In Figura 7 è mostrato un esempio di trasmissione FHSS, dove ogni Th (tempo di hop)
cambia la frequenza della portante (fh1, fh2, …) e, a seconda che il simbolo dt da
trasmettere sia 0 o 1, viene trasmesso un segnale a una frequenza maggiore o minore
della portante di quell’intervallo Th. Nello standard Bluetooth questo salto di frequenza
avviene 1600 volte al secondo (ogni 625 μs, ossia un time slot del TDM), e i canali
sono fissati e variano a seconda della zona geografica.
Figura 7: Trasmissione FHSS
54
BLUETOOTH
Nella maggior parte dei paesi la banda di frequenze va da 2400 MHz a 2483.5 MHz, e
si hanno 79 canali spaziati di 1 MHz l’uno dall’altro, a partire da 2402 MHz fino a
2480 MHz. In alcuni paesi, a causa delle limitazioni nazionali sulle banda ISM, è stato
specificato uno speciale algoritmo di frequency hopping; un esempio è la Francia, in
cui la banda va dai 2446.5 MHz ai 2483.5 MHz, con 23 canali disponibili, spaziati tra
loro di 1 MHz, a partire da 2454 MHz fino a 2476 MHz. La Figura 8 mostra le varie
bande di frequenza al variare delle zone geografiche; i valori sono espressi in GHz.
Figura 8: Bande di frequenze ISM per FHSS
In Figura 9 si può vedere lo schema di funzionamento di un modulatore FHSS:
Figura 9: Modulatore FHSS
55
BLUETOOTH
La banda disponibile è divisa in N = 79 canali e salta tra questi in funzione della
sequenza pnt generata nel modulatore, in base alla quale viene generata la portante fhi.
Per ogni time slot la banda trasmessa è concentrata attorno alla frequenza della portante
attuale, ed ha una larghezza Δfch dipende dal segnale 2-FSK trasmesso (Figura 10).
Figura 10: Salto di canale FHSS
Quindi il segnale FHSS è a banda stretta, in quanto tutta la potenza è concentrata
attorno al canale in uso; mediando su più salti, la potenza trasmessa si sparge su tutto la
banda utile WSS, che nel nostro caso va da 2.4000 GHz a 2.4835 GHz.
Il fatto di trasmettere su una banda più larga comporta due vantaggi: una bassa densità
di potenza, che significa che il segnale FHSS non disturba altri sistemi e non può essere
rilevato da intrusi, garantendo un alto livello di sicurezza, e una ridondanza, data dal
fatto che i messaggi presenti su differenti frequenze possono essere recuperati in caso di
errore. Questo implica un’alta reiezione delle interferenze e del rumore.
Ci sono due tipi di rumore che possono interferire: un rumore “narrowband”, ossia a
banda stretta, e un rumore “wideband”, ossia a banda larga.
In caso di rumore a banda stretta presente attorno a una determinata frequenza, esso
disturberà solo il canale legato a quella frequenza, bloccando la trasmissione in un
singolo time-slot. Questo è dovuto al fatto che in ricezione (Figura 11) il segnale utile
subisce l’operazione inversa allo spreading (despreading), e torna a banda stretta,
mentre il rumore a banda stretta subisce lo sparpagliamento, e non interferisce con il
segnale utile.
56
BLUETOOTH
Figura 11: Narrowband interference
In caso di rumore a banda larga, che potrebbe essere la trasmissione di un altro segnale
FHSS, che segue però un’altra sequenza di hopping, facendo l’operazione di
despreading in ricezione, legata però alla nostra sequenza, il nostro segnale utile torna a
banda stretta, mentre l’interferenza, non essendo correlata alla nostra sequenza, viene
espansa ulteriormente (Figura 12).
Figura 0.12: Wideband interference
57
BLUETOOTH
Classi di potenza
Le specifiche Bluetooth definiscono tre classi di potenza e le relative distanze che si
possono raggiungere in trasmissione. Ciò è mostrato nella tabella 1:
Power Class
Output Power (Max)
Distance (Max)
1
100 mW (20 dBm)
100 m
2
2.5 mW (4 dBm)
10 m
3
1 mW (0 dBm)
1m
Tabella 1: Classi di potenza Bluetooth
I dispositivi di Classe 1 hanno d’obbligo il requisito del controllo di potenza, che è
opzionale per le classi 2 e 3. Comunque, per un minimo consumo di potenza, è
preferibile avere il controllo di potenza.
Il controllo di potenza agisce tramite un ricevitore che esamina un segnale di
monitorazione della potenza, l’RSSI (Receiver Signal Strength Indication); in caso di
segnale troppo debole viene mandato un segnale di controllo LMP_incr_pow (a livello
Link Manager), che richiede di aumentare la potenza per avere un canale efficiente,
mentre in caso di segnale più forte del necessario, c’è una richiesta di diminuire la
potenza, con un segnale di controllo LMP_decr_pow_req.
La misura RSSI compara il segnale ricevuto con due livelli di soglia, che definiscono il
Golden Receive Power Range (Figura 13).
Figura 13: Golden Receive Power Range
58
BLUETOOTH
La soglia bassa corrisponde a un segnale ricevuto di potenza compresa tra i -56 dBm e i
6 dB sotto la sensibilità attuale del ricevitore. La soglia superiore è 20 dB sopra la
soglia inferiore, con un’accuratezza di ± 6 dB.
Parametri di prestazione del sistema RF
Le specifiche Bluetooth forniscono dei parametri prestazionali per il sistema RF.
Alcuni di questi parametri sono accettabili solo sulla carta, per cui molti dispositivi
Bluetooth in commercio eccedono significativamente rispetto alle prestazioni di
specifica.
Bluetooth deve operare con un Bit Error Rate (BER) massimo dello 0.1%. Questo
significa avere un ricevitore con una sensibilità di -70 dBm, anche se nella realtà i
ricevitori Bluetooth superano questa specifica di 10 dBm o più.
Le specifiche non forniscono valori per il tempo di assestamento nella sintetizzazione.
In Figura 14 sono mostrati i tempi di operazione durante una transazione Rx/Tx.
End of Data burst
Protocol Proc.
Baseband
384 + 10 μs
51 μs
Synthesiser Setting
180 μs
10 μs
625 μs
Figura 14: Requisiti per le temporizzazioni
Dalla figura si nota che il processore del livello più basso prima decide in che stato
mettere il controllore Baseband, che poi deve calcolare la nuova frequenza di
trasmissione secondo la sequenza del FHSS e programmare il sintetizzatore. Questo
impone un tempo di sintetizzatore di circa 180 μs, ma alcuni dispositivi in commercio
hanno tempi migliori, compresi tra i 130 e i 170 μs.
59
BLUETOOTH
Architettura del sistema RF
Esistono diverse alternative di architetture radio; qui consideriamo una semplice
modulazione eterodina a singolo bit per mostrare le componenti di un tipico sistema RF
Bluetooth. Il diagramma a blocchi è illustrato in Figura 15.
Figura 0.15: Sistema Radio
I segnali di controllo TxOn (abilitazione della trasmissione), PaOn (Power Amp),
VcoOn (abilitazione del sintetizzatore) e RxOn (abilitazione del ricevitore) sono
sincronizzati con l’interruttore dell’antenna (Antenna Switch), che indica se trasmettere
o ricevere nello slot temporale corrente. I dati entrano nel TxData in modo seriale, sotto
il controllo del Baseband clock (TxClk); in ricezione, i dati entrano nel Baseband
tramite la linea RxData, sotto il controllo del clock di ricezione (RxClk), che viene
recuperato tramite un apposito circuito di clock recovery. Tipicamente viene utilizzato
un PLL digitale. Il segnale Bluetooth Channel Numeber (ChanNo) deve essere fornito
dal Baseband al sintetizzatore, per produrre l’esatta frequenza della portante nel mixer.
La frequenza si ottiene come (2402 + ChanNo) MHz.
60
BLUETOOTH
La funzione del circuito di clock recovery è di recuperare un segnale di clock valido
da legare ai dati ricevuti. Esistono due modi per recuperare il clock nei sistemi
Bluetooth: il primo consiste nel recuperare il clock conoscendo la sequenza di preamble
di quattro bit più il primo bit della parola di sincronismo (synchword), mentre il
secondo è una tecnica molto più comune (usata per es. nel DECT), dove si utilizza un
PLL digitale. In entrambe i casi, la parte più importante dei dati da cui si recupera il
clock sono i cinque bit della sequenza di preamble (incluso il primo della synchword).
Comunque, la maggior parte dei sistemi RF perdono i primi uno, due o addirittura tre
simboli a causa dei ritardi in ricezione e dei circuiti di soglia in continua. Il risultato di
ciò è che solo uno o due simboli sono disponibili per il clock recovery, e l’esperienza
dimostra che in realtà sono richiesti come minimo quattro o cinque bit. La risposta
solita è muoversi nella synchword e usare alcuni di questi bit . Comunque, usando più
di uno o due bit aumenta l’incertezza nella soglia di correlazione e riduce la sensibilità
del ricevitore. Uno sviluppo futuro per il Bluetooth è quello di aumentare la sequenza di
preamble. Ad esempio il DECT usa una sequenza di preamble di 16 bit.
Temporizzazioni del sistema RF
I diagrammi temporali mostrati nelle figure 2.16 e 2.17 illustrano le temporizzazioni dei
vari segnali sul livello Radio.
I segnali rappresentati nelle figure sono i seguenti:
-
ChanNo: fornisce il numero di canale per ottenere poi la frequenza attuale;
-
SynthOn: comanda l’accensione del VCO della parte radio, e viene attivato sia
in ricezione che in trasmissione;
-
SynthOutputFrequency: indica la frequenza a cui è sintonizzata la radio;
-
TxOn: è il segnale di controllo della trasmissione, e abilita i dati ad essere
trasmessi;
-
RxOn: è il segnale di controllo della ricezione, e viene ativato quando è
possibile ricevere dati.
61
BLUETOOTH
Figura 16: Temporizzazione in trasmissione
Per quanto riguarda la trasmissione, il segnale SynthOn viene attivato quando comincia
lo slot temporale della trasmissione. Il tempo tTO è chiamato Transmitter On delay, ed
indica il tempo minimo da far trascorrere dopo avere attivato la linea di SynthOn prima
di attivare la linea TxOn. Il tempo tPHD è il Phase Detect Off delay, e indica il tempo da
far trascorrere dopo l’attivazione della linea TxOn prima di avviare la trasmissione dei
dati. Questo tempo serve per fare stabilizzare la frequenza della portante.
Figura 17: Temporizzazione in ricezione
62
BLUETOOTH
Osservando la ricezione, il segnale SynthOn segue lo stesso andamento, ed anche qui
si ha un ritardo tRO, Receiver On delay, che adesso indica il tempo da far trascorrere
dopo l’attivazione della linea SynthOn prima di attivare la linea RxOn. Inoltre c’è il
tempo TPHD, che indica il tempo da far trascorrere dopo l’attivazione della linea RxOn
prima di avviare la ricezione dei dati.
I valori specifici di questi tempi variano a seconda del dispositivo fisico utilizzato, e
sono presenti sui data sheet della casa di produzione.
Baseband
Bisogna innanzitutto fare una distinzione tra “Link Controller” e “Baseband” in quanto
le specifiche Bluetooth usano a volte questi due termini in modo ambiguo.
Il Link Controller (LC) è responsabile del trasporto sul link dei vari pacchetti scambiati
provenienti dal Link Manager (Figura 18), e deve mantenere questo collegamento
attivo una volta stabilito, mentre il Baseband controlla il livello Radio, è responsabile
della temporizzazione a basso livello, del controllo degli errori e della gestione dei
collegamenti durante la trasmissione di un pacchetto.
Figura 18: Link control e Baseband
63
BLUETOOTH
Confrontando con lo stack OSI (Figura 6), il livello fisico è costituito da Radio e
Baseband: il livello Radio interfaccia il Baseband con il canale in aria, mentre il
Baseband formatta i dati provenienti dal LC, cioè si occupa della criptazione a basso
livello per una trasmissione robusta e affidabile, riceve i dati dal canale e li passa nei
livelli superiori dello stack.
Come descritto in precedenza il sistema Bluetooth utilizza uno schema di trasmissione
TDM con slot temporali di 625 μs, che è una combinazione tra una comunicazione a
commutazione di pacchetto e una a commutazione di circuito. Alcuni time slot possono
essere dedicati a pacchetti sincroni: infatti è possibile supportare fino a tre canali
sincroni contemporaneamente, in coesistenza con canali dati asincroni.
I canali sincroni hanno una velocità di 64 kbps in entrambe le direzioni, mentre i canali
asincroni possono arrivare a 723.2 kbps in modalità asimmetrica (57.6 kpbs nell’altra
direzione), o 433.9 kpbs in modalità simmetrica.
Canale fisico
Il canale è rappresentato da una sequenza pseudo casuale che indica il salto di
frequenza attraverso i 79 canali (23 per i paesi con banda ISM limitata). Questa
sequenza di salto è unica per la piconet ed è determinata dall’indirizzo del dispositivo
master; la fase è invece determinata dal clock del master. Il canale è diviso in slot
temporali associati ad un determinato salto di frequenza. Ogni unità che partecipa alla
piconet dovrà essere sincronizzata sia temporalmente che frequenzialmente al canale.
Ogni dispositivo deve essere in un determinato istante o master o slave; questi due ruoli
sono così definiti:
-
master: dispositivo che inizia lo scambio di dati;
-
slave: dispositivo che risponde al master.
Inoltre, quando sono in comunicazione, gli slave utilizzano la temporizzazione del
master e saltano in frequenza seguendo la sequenza del master.
64
BLUETOOTH
Figura 19: Slot timing per pacchetti singolo slot
Come si può vedere in Figura 19, il master trasmette per primo allo slave; questo
accade quando entrambi sono sintonizzati alla frequenza fk. Dopo 625μs i due
dispositivi risintonizzano i loro livelli Radio ad una nuova frequenza fk+1, ed ora solo lo
slave è autorizzato a trasmettere, e deve anche rispondere con un ACK o meno riguardo
al pacchetto inviato nello slot precedente.
Le specifiche Bluetooth definiscono pacchetti dati che possono essere lunghi 1, 3 o 5
time slot. In Figura 20 è mostrata la temporizzazione per pacchetti multi-slot, in
particolare pacchetti da tre time slot.
Figura 0.20: Slot timing per pacchetti multi-slot
Usare pacchetti multi-slot consente di raggiungere maggiori data rate, a scapito però di
una peggior affidabilità, in quanto un maggior numero di interferenze possono
intervenire durante tre o cinque slot temporali rispetto a un singolo slot. Tutti i pacchetti
65
BLUETOOTH
hanno lo stesso data header, per cui i pacchetti multi-slot hanno una maggiore
efficienza dati.
Temporizzazione
Come molti protocolli di comunicazione, Bluetooth sincronizza la maggior parte delle
operazioni a un clock interno. Questo assicura, per esempio, la sincronizzazione Tx-Rx
nello scambio di dati tra due dispositivi, differenziando i pacchetti persi e quelli
rispediti. Il clock Bluetooth è un contatore a 28 bit che si resetta a zero all’accensione e
poi conta in ”free-run“, incrementandosi ogni mezzo slot, cioè 312.5 μs.
Ogni dispositivo ha un suo clock interno, detto “native”, denominato CLKN. Quando
un dispositivo opera come master, il suo clock interno CLKN viene usato come clock
della piconet. Se un dispositivo opera come slave si deve invece sincronizzare al clock
del master. Per fare questo, uno slave deve aggiungere un “offset value” al suo clock
nativo (Figura 21), dal quale si ottiene una stima del clock del master, chiamata
“piconet clock”, CLK. Il valore di questo “offset value” viene ricavato durante la
procedura di paging (par. 2.6.5), quando il master manda allo slave un pacchetto FHS,
che contiene il valore attuale del clock CLKN del master. Uno slave, per mantenere la
sincronizzazione col master, si risincronizza ogni volta che riceve, grazie alla
“synchronisation word”, attraverso la quale si riallinea al dispositivo trasmittente.
Figura 21: Sincronizzazione tra master e slave
66
BLUETOOTH
C’è un altro clock definito nel Bluetooth: CLKE, che si ottiene aggiungendo un altro
offset al CLKN dello slave ed è usato nel caso specifico di in cui si stabilisce una
connessione con uno slave prima di essere sincronizzati con il master.
I due bit più bassi del clock (CLK[0] e CLK[1]) sono usati direttamente per delimitare
gli slot di trasmissione e ricezione. Una trasmissione del master avviene sempre quando
CLK[0:1] = 00, mentre una trasmissione di uno slave avviene quando CLK[0:1] = 10.
Collegamenti fisici
Il livello Baseband gestisce due tipi di collegamenti:
-
ACL (Asynchronous Connection-Less)
E’ un collegamento punto-multipunto tra il master e gli slave della piconet.
Negli slot non riservati ai collegamenti SCO, il master può scambiare pacchetti
con ogni slave della piconet. Tra un master e uno slave può esistere solo un
collegamento ACL. E’ una connessione a commutazione di pacchetto. Può
trasportare dati sia dal livello L2CAP che dal livello Link Manager. Uno slave
può trasmettere solo se è stato indirizzato nel precedente slot temporale. Per
garantire l’integrità dei dati, i pacchetti ACL vengono ritrasmessi.
-
SCO (Synchronous Connection Oriented)
E’ un collegamento simmetrico punto-punto tra il master e uno slave della
piconet. Per questo tipo di collegamenti vengono riservati degli slot e può
pertanto essere considerato come una connessione a commutazione di circuito.
Il collegamento SCO viene utilizzato per la trasmissione della voce; un master
può supportare un massimo di tre collegamenti SCO contemporaneamente. I
pacchetti SCO non vengono mai ritrasmessi.
Struttura dei pacchetti Bluetooth
Segue ora una descrizione dei differenti tipi di pacchetti che vengono usati nella
comunicazione tra dispositivi nei link ACL e SCO. Come si osserva in Figura 22, un
67
BLUETOOTH
pacchetto standard Bluetooth è costituito da tre parti, ossia l’access code, il packet
header e il payload.
Figura 22: Struttura di un pacchetto Bluetooth
Access Code
Ogni pacchetto inizia con un access code. I compiti di questo campo sono la
sincronizzazione, la compensazione dell’offset in continua e l’identificazione, in quanto
l’access code viene ricavato dal Bluetooth Device Address del master, cioè ogni
pacchetto sulla stessa piconet ha lo stesso channel access code. In Figura 23 viene
riportato il formato, che è costituito da 72 o 68 bit a seconda che ci sia o meno il
payload.
Figura 23: Struttura dell'Access Code Bluetooth
La prima parte dell’access code (preamble) è costituita da 4 bit (0101 o 1010 a seconda
del primo bit della synchronisation word, per formare una parola di 5 bit, o 01010 o
10101), e serve per rilevare i fronti dei dati ricevuti e creare così un clock con il quale
campionare il resto dei dati in ricezione. La synchronisation word è formata da 64 bit,
di cui 24 sono costituiti dal LAP (Low Address Part) del dispositivo Bluetooth.
L’access code è utilizzato nelle procedure di inquiry e di paging, in cui si usano
pacchetti senza header e payload.
68
BLUETOOTH
Sono definti tre tipi di access code:
-
Channel access Code (CAC): identifica la piconet;
-
Device Access Code (DAC): utilizzato per speciali procedure di segnalazione
(es. paging e risposta al paging). Il paging è un’operazione che viene effettuata
quando un dispositivo vuole creare una connessione e che porta alla
sincronizzazione tra i due dispositivi.
-
Inquiry access Code (IAC): utilizzato nelle operazioni di inquiry, si suddivide in
GIAC (General IAC) nel caso si vogliano trovare tutti i dispositivi nelle
vicinanze e DIAC (Dedicated IAC) nel caso si vogliano trovare solo dispositivi
particolari.
Gli ultimi 4 bit dell’access code (trailer) sono presenti solo se è presente un payload,
sono simili al preamble e servono per eseguire migliori compensazioni in continua e
recupero del clock.
Packet header
Questo campo contiene delle informazioni di controllo del collegamento; il packet
header (Figura 24) contiene 18 bit di informazione, protetti dal codice Forward Error
Correction (FEC) di 1/3, che replica tre volte i dati, per un totale di 54 bit.
Figura 0.24: Struttura del Packet header
Il payload header consiste di sei campi:
-
AM_ADDR (3 bit): rappresenta l’indirizzo di un membro attivo della piconet;
ad ogni slave viene assegnato dal master un indirizzo temporaneo di tre bit, e
69
BLUETOOTH
tutti i pacchetti scambiati tra master e slave devono avere l’AM_ADDR dello
slave. Un AM_ADDR di tutti zeri viene usato per i messaggi di broadcast.
-
TYPE (4 bit): tipo di pacchetto;
-
FLOW (1 bit): viene usato per il controllo di flusso dei pacchetti sui
collegamenti ACL; FLOW = 0 significa che il buffer di ricezione è pieno e la
trasmissione deve essere temporaneamente fermata. Nel periodo in cui FLOW =
0 tuttavia i pacchetti SCO continuano a essere trasmessi.
-
ARQN (1 bit): indicatore di acknowledge, indica al trasmettitore se i dati sono
stati ricevuti correttamente (ARQN = 1) o meno (ARQN = 0).
-
SEQN (1 bit): fornisce una numerazione sequenziale al flusso dei dati, in
quanto questo campo viene invertito ogni volta che si trasmette un nuovo
pacchetto. Questo bit permette di evitare problemi in caso di errore sul bit
ARQN, in qual caso continuerei a ricevere lo stesso pacchetto.
-
HEC (8 bit): Header Error Check, è utilizzato per controllare l’integrità
dell’header.
Payload
Il formato del payload è diverso nel caso di pacchetto SCO o ACL.
-
ACL payload
E’ costituito da un massimo di 2744 bit, ed è formato da tre campi (Figura 25),
cioè il payload header, il payload vero e proprio e il codice controllore d’errore
Cyclic Redundancy Check (CRC).
Figura 0.25: Struttura del payload ACL
70
BLUETOOTH
Il payload header è formato a sua volta a tre campi, cioè il L_CH (Logical
Channel), che indica se è l’inizio o la continuazione di un pacchetto L2CAP o
LMP, il flow flag e il length field (lunghezza) (Figura 26).
Figura 26: Struttura del Payload header ACL
-
SCO payload
Ha una lunghezza fissa di 240 bit (Figura 27), è preceduto dagli stessi access
code e header di un pacchetto ACL benché i vari flow, ARQN e SEQN siano
ridondanti in quanto il controllo di flusso e la ritrasmissione non vengono
applicati nei link SCO. E’ assente anche il campo CRC. I dati presenti nel
payload sono 10, 20 o 30 byte a seconda del FEC scelto (1/3, 2/3 o nessuno).
Figura 27: Struttura di un pacchetto SCO
Correzione d’errore
FEC (Forward Error Correction)
Aggiungendo dei bit di parità generati in funzione dei dati di ingresso, un certo numero
di bit errati può essere rilevato e corretto. Ci sono tre tipi di FEC: 1/3, 2/3 e nessun
FEC.
71
BLUETOOTH
Il più forte, la codifica 1/3 FEC, consiste semplicemente nel nel ripetere ogni bit tre
volte, e viene decodificato prendendo il valore del bit ricevuto più volte. Se un bit viene
ricevuto due volte su tre ad un certo valore, quello è il valore corretto.
La codifica 2/3 è un codice di Hamming (15,10), in cui ogni 10 bit vengono generati 5
bit di patità: quindi, ogni 10 bit in ingresso, ne escono 15.
CRC (Cyclic Redundancy Check)
Il CRC viene applicato su tutti i packet header (HEC) e su tutti i payload, per
convalidare l’integrità dei dati ricevuti. Il CRC è in grado di segnalare un qualsiasi
errore nei dati.
ARQ
Lo schema ARQ consiste nel fare ritrasmettere il pacchetto finché non viene ricevuto
un segnale di acknowledge con cui si segnala che il pacchetto è stato ricevuto
correttamente, o scade un determinato timeout.
Tipi di pacchetto
In tabella 2 sono presenti i vari tipi di pacchetti Bluetooth, con una breve descrizione.
72
Type
Code
SCO/ACL
Nome
-
Comune
ID
0000
Comune
NULL
0001
Comune
POLL
0010
Comune
FHS
0011
ACL
DM1
0100
ACL
DH1
Porta 27 byte di informazione. Non è
protetto da FEC.
1
0101
SCO
HV1
Porta 10 byte di informazione. Usa FEC
1/3.
1
Descrizione
Usato per trasmettere il DAC o il IAC
nelle operazioni di page e inquiry.
Non ha il payload. E’ utilizzato per
ottenere informazioni sul link e sul flusso.
Non necessita di ACK.
Non ha il payload. E’ utilizzato dal master
per sapere se gli slave sono attivi o
meno.
E’ un pacchetto di controllo speciale per
rilevare indirizzo e clock del dispositivo
che sta trasmettendo. UsaFEC 2/3.
Porta 17 byte di informazione. Usa FEC
2/3.
Slot
1/2
1
1
1
1
BLUETOOTH
Porta 20 byte di informazione. Usa FEC
2/3.
0110
SCO
HV2
0111
SCO
HV3
1000
SCO
DV
1001
ACL
AUX1
1010
ACL
DM3
Porta 121 byte di informazione. Usa FEC
2/3.
3
1011
ACL
DH3
Porta 183 byte di informazione. Non usa
FEC.
3
1110
ACL
DM5
Porta 224 byte di informazione. Usa FEC
2/3.
5
1111
ACL
DH5
Porta 339 byte di informazione. Non usa
FEC.
5
Porta 30 byte di informazione. Non usa
FEC.
Combina sia dati che voce. Il campo dati
usa FEC 2/3 e può essere ritrasmesso,
mentre il campo voce no.
Porta 30 byte di informazione. E’ uguale
al DH1 ma non ha il CRC.
1
1
1
1
Tabella 2: Tipi di pacchetto
Questi diversi tipi di pacchetti, differiscono l’uno dall’altro a seconda del numero di
time slot occupati, della codifica di correzione d’errore utilizzata e del fatto che siano
pacchetti voce SCO o dati ACL.
L’identificazione del tipo di pacchetto avviene grazie al campo TYPE del packet header
descritto precedentemente,
Per il traffico ACL esistono sei tipi di pacchetti: DM1 e DH1 a uno slot, DM3 e DH3 a
tre slot e DM5 e DH5 a cinque slot. DH significa Data High rate, mentre DM significa
Data Medium rate. II pacchetti DM trasportano meno informazione utile, ma sono
provvisti di una maggiore protezione all’errore, con una codifica FEC 2/3. I pacchetti
DH invece non hanno FEC ma possono trasportare più dati utili.
Per il traffico SCO esistono tre diversi tipi di pacchetto, che differiscono l’uno
dall’altro semplicemente per il diverso tipo di codifica FEC utilizzato.
Esiste poi un particolare tipo di pacchetto, il DV (Data Voice), in grado di trasportare
sia dati che voce, la cui struttura è riportata in Figura 28.
73
BLUETOOTH
Figura 28: Struttura pacchetto DV
Il campo voce è di 10 byte, senza FEC (come HV1), e non può essere ritrasmesso. Il
campo dati è protetto con una codifica FEC 2/3, un campo CRC, e i flag ARQ, SEQ e
flow.
In tabella 2.3 viene riportata la velocità di trasmissione dei vari pacchetti ACL, facendo
distinzione tra una trasmissione simmetrica, che si ottiene usando lo stesso tipo di
pacchetto in entrambe le direzioni, e una asimmetrica. In generale, è possibile avere
delle applicazioni in cui la trasmissione in una direzione deve essere favorita rispetto a
quella nella direzione opposta. La massima velocità di trasmissione ottenibile è di 732.2
kbps ottenuto con pacchetti DH5 in una direzione, mentre nell’altra si usano pacchetti
DH1 con una velocità di 57.6 kbps.
La massima velocità simmetrica utilizzata è di 433.9 kbps utilizzando pacchetti DH5 in
ambo le direzioni.
Tipo
Velocità max simmetrica
Velocità max asimmetrica (kbps)
(kbps)
Trasmissione
Ricezione
DM1
108.8
108.8
108.8
DH1
172.8
172.8
172.8
DM3
258.1
387.2
54.4
DH3
390.4
585.6
86.4
DM5
286.7
477.8
36.3
DH5
433.9
723.2
57.6
AUX1
185.6
185.6
185.6
Tabella 3: Velocità pacchetti ACL
Il calcolo di queste velocità viene effettuato nel seguente: prendendo, ad esempio, un
pacchetto DH1 in modalità simmetrica, si ha un payload massimo di 27 byte, che può
essere trasmesso al massimo una volta ogni due time slot, cioè ogni 1.25 ms. Quindi:
74
BLUETOOTH
DRsim − DH 1 =
(27 ⋅ 8)bit
= 172.8kbps
1.25ms
Per un pacchetto DH5 in modalità simmetrica si ha invece:
DRsim − DH 5 =
(339 ⋅ 8)bit
= 433.9kbps
10 ⋅ 625μs
Guardando invece la modalità asimmetrica, è possibile prendere l’esempio di pacchetti
DH5 in una direzione e DH1 nell’altra: in questo caso il payload del DH5 (339 byte) si
potrà ripetere una volta ogni 5+1 time slot, cioè 3.75 ms.
DRasim − DH 5 =
(339 ⋅ 8)bit
= 723.2kbps
3.75ms
E’ possibile verificare anche che il pacchetto DH1 ci sta in un time slot: infatti
trasmettendo un payload di 27 byte (216 bit) si ha un overhead di 150 bit, per cui in aria
vanno effettivamente 366 bit; essendo il throughput di 1 Mbps, si ottiene:
Tmax − DH 1 =
(27 ⋅ 8 + 150)bit
= 366μs
10 6 bps
Canali logici
Le specifiche Bluetooth definiscono cinque canali logici che sono trasportati sui link
fisici SCO e ACL, e servono per trasportare informazioni a differenti livelli:
-
Link Control (LC): è un canale di controllo che viene trasportato nel packet
header, e contiene informazioni di basso livello per il controllo del
collegamento, tra cui l’ARQ e il SEQ.
-
Link Manager (LM): è un canale di controllo e trasporta informazioni
scambiate tra i livelli Link Manager di due dispositivi collegati. E’ indicato con
il campo L_CH = 11 nel payload header.
-
UA/UI: il canale UA (User Asynchronous) è utilizzato per trasportare i dati
L2CAP e si identifica con L_CH = 10 per inizio pacchetti e 01 per
continuazione pacchetti, mentre il canale UI (User Isochronous) serve nel caso
di pacchetti che devono essere trasmessi via ACL ma per i quali non è possibile
aspettare più di un certo tempo per avere la trasmissione senza errori; con il
75
BLUETOOTH
canale UI si trasmette impostando un tempo massimo oltre il quale si passa alla
trasmissione del pacchetto successivo.
-
US: il canale US (User Synchronous) viene usato per il trasporto dei dati SCO.
Controllo di flusso
Lo standard Bluetooth specifica di utilizzare delle code FIFO (First In First Out) sia in
ricezione che in trasmissione, per i collegamenti SCO e ACL.
In trasmissione il compito del Link Manager è quello di riempire le code, mentre il
Link Controller si occupa dello svuotamento di esse. In Figura 29 si può osservare lo
schema della routine di trasmissione.
Figura 0.29: TX routine
Gli interruttori S1 e S2 sono controllati dal Link Controller; sono presenti due registri
per il traffico ACL e due per il traffico SCO: uno è chiamato registro current, a cui può
accedere il Link Controller per la composizione del pacchetto, mentre l’altro è detto
next, a cui accede il Link Manager per caricare nuovi dati.
Lo schema della routine di ricezione è mostrato in Figura 30:
76
BLUETOOTH
Figura 30: RX routine
Anche in ricezione sia per il traffico ACL che per il traffico SCO vengono riservati due
registri: uno a cui può accedere il Link Controller e caricare l’ultimo dato arrivato, e un
altro in cui il Link Manager può andare a leggere il precedente dato arrivato.
Se in trasmissione la code sono piene il Link Controller si occupa di evitare perdita di
pacchetti e congestione. Se i dati non possono essere ricevuti, viene trasmessa
un’indicazione di STOP sul canale LC di ritorno (bit Flow). Quando il trasmettitore
riceve l’indicazione di STOP, ferma la sua coda FIFO. Quando il ricevitore torna ad
essere pronto, trasmette un’indicazione di GO.
Il sistema funziona in TDM e gli intervalli di trasmissione sono alternati a quelli di
ricezione in modo sincrono. La piconet è sincronizzata al clock del master.
Indirizzi Bluetooth
Le specifiche Bluetooth definiscono quattro tipi di indirizzi:
-
BD_ADDR: è formato da 48 bit ed è unico per ogni dispositivo Bluetooth.
Deriva dallo standard IEE802, ed è a sua volta diviso in tre campi: LAP (Lower
Address Part) di 24 bit, UAP (Upper Addres Part) di 8 bit e NAP (Nonsignificant Address Part) di 16 bit.
-
AM_ADDR: è composto da tre bit, e identifica univocamente un dispositivo
all’interno della piconet.
-
PM_ADDR: è composto da 8 bit, ed è assegnato ai dispositivi in modalità park.
77
BLUETOOTH
-
AR_ADDR: è composto da 8 bit, ed è utilizzato dai dispositivi in modalità park
per determinare lo slot in cui possono mandare il proprio messaggio d’accesso.
Questo indirizzo non è univoco e può essere assegnato a più dispositivi in park.
Link Controller
Il Link Controller (LC) è costituito da parti hardware e software, è responsabile del
mantenimento del link una volta che è stato creato, esegue protocolli verso i livelli
inferiore, come il protocollo ARQ e la codifica FEC, ed è trasportato nel canale logico
LC (Link Control).
Le funzioni svolte dal Link Controller sono le seguenti:
-
Trasferimento dati con le caratteristiche selezionate coi parametri del QoS
(Qualità of Service);
-
Trasferimento asincrono con successo garantito utilizzando un protocollo ARQ;
-
Trasferimento sincrono;
-
Codifica audio, con data rate di 64 kbps;
-
Criptaggio.
ARQ
Il sistema ARQ (Acknowledgement/Request) viene utilizzato per la ritrasmissione di
pacchetti corrotti. Come visto nel par. 2.5.4, in ogni packet header è presente il flag
ARQN, che indica lo stato del pacchetto ricevuto in precedenza. ARQN = 1 significa
che il pacchetto è stato ricevuto e decodificato correttamente, mentre ARQN = 0
(NAK) significa che la precedente trasmissione non è andata a buon fine; questa è detta
tecnica del piggy-backed acknowledgement, cioè l’ACK viene “caricato a spalle” del
payload del pacchetto di ritorno.
Le possibili cause di ritrasmissione sono:
-
il ricevitore non rileva l’access code del pacchetto;
-
fallisce il controllo HEC (par 2.5.4), per cui non si sa a chi è indirizzato il
pacchetto;
78
fallisce il controllo CRC.
BLUETOOTH
Ogni volta che un nuovo pacchetto viene trasmesso, il flag SEQN viene commutato,
mentre in caso di ritrasmissione il bit non viene cambiato; questo permette al ricevitore
di distinguere un pacchetto che possiede ARQN = 0 a causa di un errore sulla ricezione
di ARQN da un pacchetto che effettivamente possiede un NAK. Quindi il ricevitore, in
caso di ritrasmissione, confronta il SEQN precedente con quello ritrasmesso e se i due
SEQN sono uguali scarta il nuovo payload, che è uguale al precedente, mentre se sono
diversi ritiene valido anche l’ultimo payload arrivato. Il Link Manager può richiedere al
Link Controller di effettuare un’operazione di flush del buffer, cioè di eliminazione di
un pacchetto nel caso in cui questo continui ad essere trasmesso senza successo; ciò
tipicamente avviene dopo un certo tempo in cui si prova a ritrasmettere, detto
automatic_flush_timeout.
Un master può spedire dati a tutti gli slave presenti nella piconet simultaneamente,
usando dei pacchetti broadcast, cioè impostando AM_ADDR = 000. In questo caso
però lo schema di utilizzo dell’ARQN non risulta più essere applicabile, per cui una
soluzione è quella di ritrasmettere il pacchetto per un certo numero di volte.
Stati del Link Controller
Nei vari istanti, un apparecchio Bluetooth può essere in una serie di stati diversi.
Vengono ora definiti i principali stati del Link Controller, prima di una dettagliata
descrizione di come un dispositivo si muove da uno stato all’altro ed effettua operazioni
di alto livello, come stabilire la connessione sotto il controllo di un’applicazione
attraverso lo stack ed il Link Manager.
-
Standby
In questo stato, il dispositivo è inattivo, nessun dato viene trasferito, e il livello
Radio è spento. Dunque, il dispositivo è incapace di rilevare alcun access code.
Questo stato è usato normalmente per abilitare le operazioni a basso consumo.
-
Inquiry
E’ il processo tramite cui il dispositivo che intende diventare il master della
piconet può provare a scoprire tutti gli altri apparecchi Bluetooth attivati nella
sua area locale. Durante la procedura di inquiry, gli apparecchi che stanno
79
BLUETOOTH
subendo un inquiry forniscono il pacchetto FHS (Frequency Hopping
Synchronisation) al dispositivo che sta compiendo l’inquiry (Figura 31).
Figura 31: Struttura del pacchetto FHS
Il pacchetto FHS permette all’inquisitore di costruire una tabella delle
informazioni essenziali richieste per fare una connessione, come il CLKN
(clock nativo), che controlla la temporizzazione on-air, il BD_ADDR, che
controlla la sequenza di frequency hopping e costituisce una parte dell’access
code, e il BCH, che costituisce anch’esso una parte dell’access code.
-
Inquiry scan
E’ l’atra metà della procedura di inquiry, e viene eseguita da tutti i dispositivi
disponibili a diventare slave della piconet. Sebbene la scansione sia opzionale e
sopra l’applicazione, molti dispositivi periodicamente entrano nello stato di
inquiry scan per rendersi disponibili verso quelli in fase di inquiry. Essi
ascoltano per un periodo esteso (questo è necessario, siccome non conoscono né
la temporizzazione nè il comportamento del frequency hopping di alcun
dispositivo inquirente) aspettando o un GIAC (General Inquiry Access Code) o
un DIAC (Dedicated Inquiry Access Code). Quando essi ricevono un messaggio
di inquiry valido, entrano nel sottostato di inquiry response e rispondono con un
FHS come descritto sopra. Gli stati di inquiry e inquiry scan utilizzano una
speciale sequenza di frequency hopping (veloce per inquiry e lenta per inquiry
scan), che è realizzata per ridurre il tempo prima che avvenga
sintonizzazione in frequenza.
-
Inquiry response
In questo stato lo slave risponde con un pacchetto FHS.
80
la
BLUETOOTH
-
Page
Per stabilire una connessione, il dispositivo che è diventato master è istruito
dall’applicazione per svolgere la procedura di page (chiamata). Il master prima
entra nello stato di page, dove trasmette dei messaggi di paging diretti allo slave
che prima ha mandato l’FHS (usando l’access code e le informazioni di
temporizzazione acquisite nella procedura di inquiry). Lo slave acquisisce i
messaggi di paging e il master entra nel sottostato di master response e risponde
con il suo pacchetto FHS.
-
Page scan
Come per l’inquiry scan, un dispositivo tipicamente entrerà nello stato di page
scan periodicamente per permettere ai dispositivi nello stato di page di stabilire
una connessione con essi. Una volta che un device nello stato di page scan ha
ricevuto con successo un pacchetto di page, entra nel sottostato di slave
response, dove acquisisce il pacchetto e aspetta l’FHS del master. Alla ricezione
del pacchetto FHS, lo slave aggiorna il proprio CLK e la propria
synchronisation word prima di entrare nello stato connection. Di nuovo, come
nella procedura di inquiry, la procedura di page usa una speciale sequenza di
hopping (veloce per il page e lenta per il page scan) , che serve a ridurre il
tempo per la sintonizzazione di frequenza. E’ possibile avviare la procedura di
paging senza un inquiry prioritario se l’indirizzo del dispositivo è già
conosciuto, come può essere il caso con un arrangiamento dedicato per un
laptop o un cordless, per esempio. Il device in stato di page è capace di
indirizzare lo slave in questione, ma non essendoci nessun CLKE (stima del
clock dello slave) disponibile, la procedura sarà molto più lunga. In teoria, il
massimo della lunghezza è di 10 s.
-
Master response
Il master entra in questo sottostato dopo che ha ricevuto una risposta dallo slave
a un suo messaggio di page. Il master invia un pacchetto FHS allo slave e se
questo risponde entra nello stato connection.
81
BLUETOOTH
-
Slave response
Lo slave risponde al master ad una richiesta di page, e quando riceve dal master
il pacchetto FHS entra nello stato connection.
-
Connection – Active
Entrando nello stato connection, lo slave commuta al CLK del master
(applicando l’offset al suo CLKN) e poi si sposta sulla sequenza di frequency
hopping del master. Il master trasmette un pacchetto POLL (non ha il payload, è
utilizzato dal master per sapere se gli slave sono attivi o meno) per verificare
che il collegamento sia stato realizzato con successo. Lo slave deve poi
rispondere con qualche tipo di pacchetto, tipicamente un NULL. Il flag ARQN
viene settato a zero per un NAK, ma la trasmissione successiva il master attiva
ARQN e SEQN (alterno). Se la connessione fallisce in questo modo, allora
dopo un adatto timeout, entrambe i dispositivi ritornano nello stato di page e di
page scan rispettivamente, e l’intero processo riparte.
Anche se uno slave non può attualmente essere indirizzato per molti slot, esso
sta sincronizzato al master durante una connessione effettuando la correlazione
con l’access code del master – nel CAC Channel Access Code – in ogni
pacchetto che il master trasmette, anche se non è destinato a quello slave. Il
master deve stare in trasmissione periodicamente, anche se non ci sono dati da
trasmettere. Userà dei pacchetti NULL per questo proposito se necessario.
Una volta che uno slave ha commutato nel CAC e ha ricevuto il pacchetto
header, troverà spesso che l’AM_ADDR non è il suo e deve interrompere la
risposta. Fino a che il campo packet type dell’header non dirà quanti slot il
pacchetto occuperà, potrà usare le informazioni per entrare in Low Power Sleep
mode per l’intera durata della trasmissione del master. Durante lo stato di
connessione, diversi scambi di dati e canali logici sono possibili. Come sempre,
ogni dispositivo connesso deve portarsi nel sottostato Low Power come
descritto sopra.
82
BLUETOOTH
-
Connection – Hold
Nel modo Hold, un device cessa di supportare il traffico ACL per un periodo di
tempo definito per liberare la banda per le altre operazioni come lo scanning,
paging, inquiring o Low Power Sleep. Il dispositivo mantiene il proprio
AM_ADDR. Dopo che l’hold time è finito, il dispositivo si sincronizza col
CAC e comincia ad ascoltare il traffico di nuovo.
-
Connection - Sniff
Nel modo sniff, a uno slave è dato un predefinito slot temporale e una
periodicità per ascoltare il traffico. Lo slave ascolterà uno slot numero Dsniff
ogni Tsniff slots per un periodo di timeout di Nsniff slots. Alla ricezione di un
pacchetto durante questo tempo, esso continuerà a ascoltare finchè i pacchetti
con il suo AM_ADDR termineranno. Esso poi aspetterà il prossimo periodo di
sniff.
-
Connection - Park
Nel modo Park, uno slave cede il suo AM_ADDR e ascolta il traffico solo
occasionalmente. Per la maggior parte, il device è capace di entrare nella
modalità Low Power. Il dispositivo solo necessita di svegliarsi a un definito
istante, detto di “Beacon”, per sincronizzarsi al CAC prima di tornare in Low
Power di nuovo. In questo modo, lo slave è capace di stare sincronizzato al
master anche se esso segue un meno accurato oscillatore, LPO (Low Power
Oscillator).
83
BLUETOOTH
Operazioni del Link Controller
Il diagramma degli stati del Link Controller è mostrato in Figura 32.
Esso apparentemente mostra la strada per uscire dallo stato di standby e andare,
attraverso l’inquiry, allo stato di connessione. In realtà, non c’è una via così diretta. Per
effettuare una connessione, bisogna passare per lo stato di page (master) o page scan
(slave). Il diagramma è concepito per mostrare che lo stato di inquiry può essere
raggiunto sia da standby che da connection. Non mostra la strada per realizzare una
connessione.
Figura 0.32: Diagramma degli stati del Link Controller
Una più semplice vista delle strade principali del diagramma è mostrata in Figura 33,
dove è mostrato in modo chiaro come si crea una connessione partendo da zero, con a
sinistra il master e a destra lo slave.
84
BLUETOOTH
Figura 33: Transizione degli stati da standby a connection
Come sempre in pratica, la transizione degli stati può essere più complessa. Per
esempio, un master connesso già occupato con il traffico SCO può periodicamente fare
delle operazioni di inquiry per cercare nuovi slave, delle operazioni di page per
aggiungere slave alla piconet, o anche page scan o inquiry scan per diventare slave di
un'altra piconet con un altro master.
Infatti, un dispositivo in una scatternet pienamente attiva può commutare da alcuni dei
principali stati ad altri come si muove tra connessione, link setup, inquiry e operazioni
di risparmio energetico. E’ molto importante capire che l’apparentemente semplice
macchina a stati vista prima rappresenta effettivamente solo lo stato di un collegamento
tra due dispositivi in un determinato istante. Non appena si stabilisce un altro
85
BLUETOOTH
collegamento, si entra in un altro ciclo della macchina a stati. Poi, un master può essere
in connessione con uno slave e contemporaneamente essere in inquiry, paging o
scanning con altri device. Infatti, mentre il page o l’inquiry può durare molti secondi, il
master si muoverà effettivamente dalla connessione all’inquiry, allo scan o al page e
tornerà alla connessione lavorando con l’insieme di dispositivi che interagiscono
attorno ad esso. In pratica, l’entità dello stato di controllore richiede un insieme di
contesti per ogni suo collegamento attivo. Questo è vero anche per il protocollo LC, e i
pacchetti ARQN, SEQN e di ritrasmissione.
Le prime implementazioni Bluetooth hanno piazzato la maggior parte di questi controlli
in hardware, e ciò non è stato molto vantaggioso. Una chiave di volta per Bluetooth è
stato dividere i ruoli dell’hardware da quelli del software.
Scoperta di un dispositivo e inquiry
In seguito alla natura ad hoc delle reti Bluetooth, dove dispositivi possono entrare e
uscire dall’area della rete, la topologia della rete e degli appartenenti cambia in
continuazione e deve venire aggiornata continuamente.
Il LC usa gli stati di inquiry e inquiry scan per gestire il processo di discovery device,
nella speranza di scoprire altri apparecchi o di essere scoperti, rispettivamente.
Figura 34: Sequenza di messaggi per inquiry e inquiry scan
86
BLUETOOTH
In Figura 34 sono mostrati i messaggi scambiati tra due dispositivi durante procedure di
inquiry e inquiry scan.
Il dispositivo inquisitore chiede: ”C’è qualcuno?”, mentre il dispositivo scanner (quello
che è in fase di inquiry scan) ascolta se c’è qualche inquisitore. L’inquisitore chiama
trasmettendo pacchetti ID contenenti un IAC (Inquiry Access Code). Di solito, si usa il
GIAC (General), che è il più comune. Si può usare anche il DIAC (Dedicated). In
origine il DIAC serviva per abilitare a entrare solo certi dispositivi, ma l’unico DIAC
funzionante è il LIAC (Limited). Il LIAC è fatto per essere usato da un paio di
dispositivi per un breve periodo. Dovrebbe essere il livello di applicazione a selezionare
un device “noto”. Per risparmiare energia, viene effettuata un’inquiry solo se richiesto
da un livello superiore (HCI), di solito periodicamente.
Quando un device che è in fase di inquiry scan sente un inquiry, può rispondere
immediatamente, ma potrebbero esserci molti scanner che lo vorrebbero fare assieme,
le risposte interferirebbero tra di loro e l’inquisitore le scarterebbe tutte. Per fermare
questo, viene usato un tempo casuale di back-off (RAND slot in Figura 35).
Questa volta, se il dispositivo scanner sente l’inquiry, risponde dopo un time slot con il
pacchetto FHS (Frequency Hopping Synchronisation). In questo modo, molti
dispositivi possono rispondere all’inquiry, ma le loro risposte non si accavallano.
Chiaramente l’inquisitore deve stare in inquiry per più del tempo massimo casuale di
back-off.
Figura 35: Temporizzazioni dell'inquiry
87
BLUETOOTH
La Figura 35 mostra in dettaglio come un device inquisitore trasmette due volte per slot
un ID con un fast hopping (la frequenza con cui trasmette cambia due volte per ogni
slot, In(m), In(m+1),…), cercando di catturare un device in fase di inquiry scan, che
cambia invece frequenza una volta ogni 2048 slot (1.28 sec, Sc(m)).
L’inquisitore trasmette usando la sequenza di hopping di inquiry, e ascolta in entrambe
le metà dello slot ad una data frequenza. Una volta che l’inquiry scanner riceve con
successo un pacchetto ID (in Figura 35, coincidenza di frequenze In(m+1) = Sc(m)),
aspetta per un tempo casuale di back-off, compreso tra 0 e 1023 slot, o più di 640ms per
evitare collisioni. Dopo il periodo RAND, l’inquiry scanner entra nello stato di inquiry
response, e alla prossima ricezione di un pacchetto ID (In(p+1) = Sc(m)), risponderà
con un pacchetto FHS 625 μs più tardi. Entrambe i dispositivi saltano tra due differenti
punti nella sequenze in base al valore del proprio bit CLKN[1], che è 0 per entrambi i
dispositivi (par. 2.5.2). Si ha dunque Sc(m)=In(p+1), per cui la risposta è poi fatta nel
prossimo slot quando CLKN[1]=1, e quindi lo scanner salta si sintonizza alla frequenza
Sc(n) = In(s+1). Essendo l’inquisitore sullo stesso canale dello scanner, quando questo
invia l’FHS il dispositivo che ha compiuto l’inquiry è pronto a ricevere. L’inquiry
scanner rientra in inquiry scan nel prossimo canale (Sc(n+1)), alla sequenza di hop
inquiry e aspetta un altro pacchetto ID.
Non essendoci legami tra i due CLKN, non è un processo esatto ed è il motivo per cui
ci sono errori. Il tempo di inquiry dipende da come si massimizza questa coincidenza.
Se l’inquisitore riceve l’FHS nella prima metà dello slot, non può ricevere una risposta
da un altro slave nella seconda metà dello slot, perché non ha tempo di saltare a un’altra
frequenza. Allo stesso modo, se l’FHS arriva nella seconda metà dello slot, l’inquisitore
dovrà perdere la trasmissione del primo ID del prossimo slot (Figura 36).
Figura 36: Salto di frequenza durante l'inquiry response
88
BLUETOOTH
L’inquisitore salta due volte per slot mentre il dispositivo in inquiry scan ascolta su
una singola frequenza, per cui il tempo speso per avere un inquiry è la metà di quello
che ci vorrebbe se l’inquisitore saltasse una volta per slot. Questo è possibile perché il
pacchetto ID è corto. Se l’inquiry scanner non riceve il primo o il secondo ID entro il
timeout scan, torna in stato di standby o connection. Lo stato di inquiry dura o quanto
serve per avere un numero desiderato di risposte, o fino a che scade il tempo di timeout
fissato dall’host.
E’ possibile evitare l’inquiry interamente se è noto l’indirizzo del dispositivo, e
passando direttamente al paging.
Paging e realizzazione della connessione
I sistemi Bluetooth sono realizzati per effettuare connessioni master-slave. Per stabilire
un link, un dispositivo deve iniziare la connessione indirizzando una richiesta
direttamente all'altro dispositivo chiedendo: “ti connetterai con me?”. L’operazione di
paging consiste proprio in questo.
Figura 37: Sequenza di messaggi per il paging e il page scanning
89
BLUETOOTH
L'altro dispositivo deve parimenti stare ad ascoltare per una richiesta, cioè deve
effettuare l’operazione di page scanning.
Alla fine del paging, il pager diventa il master e il page scanner lo slave, anche se in
seguito possono scambiarsi di ruolo.
In Figura 37 sono mostrati i messaggi scambiati tra due dispositivi durante la
realizzazione di una connessione, usando la procedura di paging.
Il comando di creare una connessione fa entrare il dispositivo in paging, ed inizia a
mandare una serie di pacchetti di paging (pacchetti ID basati sull'indirizzo del
dispositivo chiamato). Nel frattempo, il dispositivo in fase di page scanning è
configurato per fare periodicamente delle scansioni, che durano per un tempo
prefissato.
Il pager trasmette pacchetti ID con l'indirizzo dello scanner. Se lo scanner è in page
scanning durante l’intervallo in cui il pager trasmette alla sua frequenza, allora riceve il
pacchetto ID e risponde con un altro pacchetto ID, in cui usa il proprio indirizzo.
Diversamente dall'inquiry qui c'è solo un device con quell'ID, così un solo dispositivo
risponde e non c'è bisogno di attendere un tempo RAND. Il pager riceve l'ID e capisce
che lo scanner è pronto a ricevere l'FHS. Lo scanner acquisisce l'FHS e risponde con un
altro ID. Adesso lo scanner può estrarre dall'FHS i parametri necessari (Bluetooth CLK,
AM_ADDR, etc…) da usare nella nuova connessione. Con questi parametri, lo scanner
è in grado di calcolare la sequenza di hop del pager. Smette di usare la sequenza di hop
speciale di page e si sposta nella sequenza speciale di hop di connessione assieme al
pager, che è ora il master della nuova connessione. Dopo che entrambi i dispositivi si
sono portati alla nuova sequenza di hop, il master manda un POLL per controllare che
il cambio di sequenza sia avvenuto correttamente. Lo slave risponde con un pacchetto
ACL (tipicamente un NULL). In seguito vengono scambiati vari pacchetti LMP (Link
Manager Protocol). A questo punto, master e slave possono d'accordo scambiare ruoli
se necessario.
La Figura 38 mostra in dettaglio lo scambio di pacchetti e le temporizzazioni tra il
pager e il page scanner durante la procedura di page.
90
BLUETOOTH
Figura 38: Temporizzazione della procedura di paging
Il master trasmette pacchetti ID sul canale che ha previsto lo slave, in base alla stima
del CLKN dello slave (CLKE) ad alta velocità, due salti per slot. Questo è necessario,
siccome il CLKE può essere inaccurato o inesistente perché un inquiry non l'ha stimato.
I 32 canali della sequenza di hop sono divisi nei 16 attorno al canale previsto e gli altri
16 più lontani.
Il gruppo interno di canali, detto treno A, viene provato prima, poi vengono provati gli
altri, del treno B. Questo serve a dare maggiore velocità di risposta se è disponibile un
CLKE, garantendo il successo anche nel caso peggiore in cui non ci sia. Come con
l'inquiry, il pager salta due volte per slot per massimizzare la possibilità di prendere la
frequenza dello scanner. Lo scanner segue la stessa sequenza di hop, ma effettua un
salto ogni 2048 slots (1.28s).
Nella Figura 38, Pg sta per pager hop channel, PgR sta per pager hop channel in stato
di master response, ed è legato al page hop channel durante il quale l'ID viene ricevuto
con successo dallo slave (Pg(n+1)). Una volta che lo scanner ha ricevuto il pacchetto
ID, congela il clock e comincia a saltare in sequenza con il pager. Lo fa usando la
sequenza di hop di page response.
Quando il master riceve l'ID, trasmette il pacchetto FHS all'inizio del prossimo slot e
permette allo slave di sincronizzarsi al suo riferimento di slot. Lo slave deve quindi
aprire il suo correlatore 312.5 μs dopo che l'ID è stato spedito e tenerlo aperto almeno
per 625 μs, siccome l'FHS potrebbe essere dato o in 312.5 μs o 625 μs.
In seguito alla ricezione del pacchetto FHS, lo slave risponde con un ID; da ora
entrambe i dispositivi usano il DAC dello slave, le temporizzazioni dello slave (slave
91
BLUETOOTH
CLKN, master CLKE) e una sequenza di page derivata dal LAP dello slave. La
trasmissione seguente è del master che usa il CAC (Channel Access Code) e il suo
CLKN, che è lo slave in grado di ricevere in quanto è passato al master CACe CLK ed
entrambi sono in stato di connessione. I dispositivi si scambiano ora POLL e NULL per
verificare la connessione. Se il pacchetto POLL non viene ricevuto dopo un certo
periodo, entrambe i dispositivi tornano nello stato di paging o page scanning
rispettivamente.
Operazioni della piconet
In una piconet, il master trasmette e riceve da ciascuno degli slave che sono attivi in
quell'istante e sono allocati con un AM_ADDR. Se non c'è niente da spedire, il master
o omette quello slave o gli trasmette un pacchetto NULL. Se c'è in atto un collegamento
voce sincrono (SCO) con uno degli slave, allora questo deve essere messo in
comunicazione regolarmente in accordo alla velocità di SCO, ogni Tsco.
Link ACL
In Figura 39 è mostrato come un master sia capace di comunicare con diversi slave in
sequenza secondo un traffico esclusivamente di tipo ACL.
Figura 39: Traffico ACL
92
BLUETOOTH
Il master trasmette sempre negli slot pari, gli slave nei dispari. Il diagramma mostra un
esempio di traffico ACL in cui il master trasmette dati solo quando c'è qualcosa da
spedire. In questo caso lo slave 3 è omesso, siccome non c'è nulla da mandargli in quel
momento, e il master è in grado di saltare subito alla comunicazione con lo slave 4.
Link SCO
In Figura 40 è mostrato un master che trasmette con tre slave; in particolare è presente
del traffico SCO con lo slave 2, per il quale sono riservati due slot ogni sei.
Figura 40: Traffico SCO
A causa del fatto che gli slots SCO sono riservati, lo slave SCO risponde nello slot 5 sia
che abbia ricevuto o no dati dal master.
Gli slot SCO possono essere spaziati per usare ogni coppia di slot, ogni seconda (due
slot su quattro) o ogni terza coppia di slot (due su sei). Il fatto che la massima distanza
tra due trasmissioni SCO consecutiva sia di sei slot, con il successivo riservato alla
risposta, fa sì che al massimo un master può sostenere tre link SCO
contemporaneamente con tre slave diversi, mentre uno slave può sostenere fino a tre
link SCO con lo stesso master.
Scambio di ruoli master/slave
Bluetooth permette ai dispositivi di richiedere uno scambio di ruoli tra device in
comunicazione. Per esempio, un master in una piconet può consentire a se stesso di
essere chiamato (paged), connesso a un nuovo device e quindi saltare da slave a master
e da master a slave per integrare un nuovo dispositivo nella piconet. Questo è fatto con
una commutazione master/slave ed è utile nelle situazioni in cui una connessione è stata
93
BLUETOOTH
appena fatta da un dispositivo che normalmente è uno slave, come un computer
portatile che entra in una piconet controllata da un LAN Acces Point.
Il meccanismo essenzialmente porta lo slave a spedire al master l’FHS; il master prende
il CLK offset per compensare il CLKN dello slave, mentre lo slave commuta usando il
proprio CLKN, e ogni device scambia gli access code. Il nuovo master spedisce anche
un messaggio LMP, che contiene la parte bassa del CLK Bluetooth non contenuto
nell’FHS assieme al sub-slot offset (ms) che permette al nuovo slave di sincronizzarsi.
Architettura del livello Baseband/Link Controller
La Figura 41 mostra una possibile struttura di un sistema Baseband/Link Controller.
Figura 41: Architettura Baseband/Link Controller
La strada percorsa dai dati può essere, in caso di traffico SCO, via diretta con
l’interfaccia PCM, attraverso l’HCI, processati dall’audio CODEC, mentre in caso di
traffico ACL via l’HCI. I dati vengono bufferizzati, così potrebbero venire letti
seguentemente alla ricezione, alla velocità del sistema, o memorizzati aspettando la
trasmissione.
Tipicamente, un doppio buffer è usato per fare lo scheduling delle operazioni. Infatti, la
doppia bufferizzazione in trasmissione, è quasi necessaria per un dispositivo multi-link
94
BLUETOOTH
dove la ritrasmissione deve essere anticipata. Il data path è già stato discusso, esso
codifica o decodifica i dati durante Tx o Rx, rispettivamente. Il correlatore Rx
effettivamente sente i dati ricevuti, e quando abilitato, cerca il richiesto access code. Il
sync word generator fornisce una valida sync word derivata dal LAP. Il timebase
produce un CLKN: deve essere accurato con ±20 ppm. Il controllo di offset produce
CLKE. La funzione di selezione di hop combina CLK con BD_ADDR per generare il
canale e mandarlo alla radio. Infine, il sistema di criptaggio produce una parola chiave
che viene letta e mandata al bitstream data path.
Il cuore del sistema è il Link Controller, che controlla le funzioni e le operazioni citate.
Tipicamente consiste di due macchine a stati, una per la trasmissione e una per la
ricezione, che sono mostrate in Figura 42.
Figura 42: Macchina a stati di trasmissione e ricezione LC
95
BLUETOOTH
Sicurezza nel Bluetooth
La tecnologia Bluetooth mette a disposizione un collegamento peer-to-peer per brevi
distanze. Allo scopo di proteggere le informazioni trasmesse, il sistema deve avere
delle misure di sicurezza sia a livello applicativo che di collegamento.
Per quanto riguarda il livello di collegamento, sono presenti quattro entità: un indirizzo
pubblico unico per ogni dispositivo, due chiavi segrete e un numero casuale che è
diverso per ogni transazione (tab. 4).
Entità
Dimensione
BD_ADDR
48 bit
Chiave utente privata, autenticazione
128 bit
Chiave utente privata, criptazione
8–128 bit
RAND
128 bit
Tabella 4: Entità utilizzata nell'autenticazione e nella criptazione
Le chiavi di sicurezza sono derivate durante l’inizializzazione e non sono mai svelate.
Normalemente, la chiave di criptazione è derivata dalla chiave di autenticazione
durante il processo di autenticazione. Per quanto riguarda l’algoritmo di autenticazione,
la dimensione della chiave è sempre di 128 bit. Nell’algoritmo di criptaggio, invece, la
dimensione della chiave può variare da 8 a 128 bit. Questa dimensione può variare per
due ragioni, cioè per i regolamenti presenti nei vari paesi e per facilitare un futuro
aumento della sicurezza senza bisogno di riprogettare l’algoritmo di criptaggio e
l’hardware. L’aumento della chiave, infatti, è il metodo più facile per aumentare la
sicurezza.
L’entità RAND è un numero casuale che viene generato all’interno dell’unità
Bluetooth. Questo parametro non è statico e cambia velocemente.
96
BLUETOOTH
Link Manager
Un dispositivo Bluetooth viene guidato dall’host controller attraverso i comandi HCI,
ma è il Link Manager che si occupa della traslazione di questi comandi in operazioni al
livello Baseband, gestendo le seguenti operazioni:
-
legando gli slave alla piconet e allocando il loro indirizzo attivo;
-
rompendo la connessione per staccare gli slave dalla piconet;
-
configurando il link;
-
controllando le commutazioni master/slave;
-
stabilendo i collegamenti SCO (voce) e ACL (dati);
-
mettendo le connessioni in modalità basso consumo;
-
controllando la modalità test.
Un LM Bluetooth comunica con un LM su un altro dispositivo Bluetooth usano l’LMP
(Link Manager Protocol). Le specifiche Bluetooth definiscono solamente i messaggi
LMP scambiati tra i LM e non scendono in nessun dettaglio su come le istruzioni del
protocollo vengono fatte. In pratica, il LM controlla la gestione della piconet (crea e
distrugge collegamenti), configura i collegamenti e le funzioni di sicurezza.
LMP Protocol Data Units (PDU)
Il protocollo Link Manager (LMP) è costituito essenzialmente da alcuni pacchetti base
denominati PDU, che hanno la struttura mostrata in Figura 43.
Figura 43: Struttura dei LMP PDU
97
BLUETOOTH
Ogni messaggio LMP comincia con un singolo bit Translation IDentifier (TID) che è 0
se il master inizia la transazione e 1 se è lo slave. Poi c’è un OpCode di 7 bits, che
definisce il tipo di messaggio LMP spedito. Infine ci sono una serie di parametri,
ognuno dei quali occupa un intero byte.
Il canale Link Manager
Gli LMP PDU vengono passati come pacchetti single-slot nel canale logico LM.
Questo canale è identificato settando nell’header del payload il logical channel field
L_CH al valore 11. Il bit di flow è usato per interrompere i flussi L2CAP, per cui nel
caso di messaggi LMP è sempre a 0 e in ogni caso viene ignorato dal ricevente.
Setup dei collegamenti
Il LM è responsabile del settaggio e della gestione delle connessioni a livello baseband
che collegano device Bluetooth. I messaggi LMP possono essere usati per stabilire un
link SCO in una connessione ACL esistente. Il LM mantiene i dati sugli slave su cui ha
allocato un AM_ADDR.
Figura 0.44: Sequenza di messaggi LMP per il settaggio di un link ACL
98
BLUETOOTH
In Figura 44 vengono mostrati i messaggi inoltrati nel settaggio di una connessione
ACL. Il Link Controller stabilisce un collegamento tra i dispositivi prima che i
messaggi LMP siano scambiati.
Una volta che il link ACL è stato stabilito, o il master o lo slave possono richiedere di
creare un link SCO , come mostrato in Figura 45.
Figura 45: Sequenza di messaggi LM per la creazione di un link SCO
Infatti un link SCO può essere creato solo tra due dispositivi che possiedono già un
collegamento ACL attivo tra di loro.
Quando il master richiede una connessione SCO, manda un LMP_SCO_req contenete i
parametri per il link, che sono:
-
SCO handle;
-
flags di controllo delle temporizzazioni;
-
Dsco: ritardo SCO, indica quando arriva il primo slot SCO;
-
Tsco: periodo che separa due slot SCO;
-
Tipo di pacchetto SCO usato (HV1, HV2, HV3, DV);
-
Codifica in aria: μ-law, A-law o CVSD.
Lo slave risponde semplicemente con un LMP_accepted o con LMP_not_accepted.
Un master può creare link SCO con più slave. E’ il master che decide le
temporizzazioni del link SCO, perché se le scegliesse lo slave potrebbero accavallarsi
con quelle di un altro link SCO. Quindi se uno slave manda un LMP_SCO_req, il
master, se è in grado di creare un link SCO, risponde con un LMP_SCO_req,
mandando nuovi parametri. Se non può, manda un LMP_not_accepted.
99
BLUETOOTH
Sospensione del link LMP
Se un master o uno slave vuole interrompere il collegamento, manda un LMP_detach
(Figura 46).
Figura 46: Sequenza di messaggi LMP per lo spegnimento di un link
La ragione del distacco è inclusa nel messaggio; alcune possibili sono:
-
connessione terminata dall’utilizzatore;
-
poche risorse;
-
spegnimento.
Scambio di ruolo
Solitamente, chi fa il page diventa il master e chi fa il page scan diventa lo slave. In
alcuni casi può essere necessario cambiare i ruoli. In tal caso, si interrompe il link, il
master fa un’operazione di page-scan e lo slave fa un’operazione di page, ma in questo
intervallo non si possono trasferire dati. Per evitare questa perdita di tempo, l’LMP
fornisce un mezzo per scambiare i ruoli.
Il dispositivo che vuole effettuare lo scambio di ruoli manda un LMP_switch_req.
Durante questo scambio di ruolo è però necessario sincronizzare i dispositivi al clock
del vecchio slave. Quindi questo manda un LMP_slot_offset per segnalare la differenza
tra il suo clock e quello dell’altro dispositivo, e se lo scambio di ruoli è accettato,
manda un pacchetto FHS (Figura 47).
100
BLUETOOTH
Figura 47: Sequenza di messaggi per lo scambio di ruolo
Controllo dei pacchetti multi-slot
Quando un link viene creato, utilizza di default pacchetti single-slot; pacchetti multislot permettono un migliore utilizzo della banda, ma in alcune circostanze non possono
essere usati:
-
su collegamenti rumorosi, in quanto i pacchetti multi-slot sono più facilmente
corruttibili;
-
su collegamenti SCO, in quanto potrebbero non avere spazio a sufficienza.
Figura 48: Sequenza di messaggi per il controllo di pacchetti multi-slot
101
BLUETOOTH
Il master impone una dimensione massima per i pacchetti con la funzione
LMP_max_slot; siccome lo slave non può rifiutarlo non serve che risponda con un
LMP_accepted. Se lo slave spera di cambiare la dimensione massima, può mandare al
master un LMP_max_slot_req. Se il master può permettere allo slave di usare questa
dimensione massima, risponde con un LMP_accepted (Figura 48).
Sicurezza
Nel baseband c’è un meccanismo di criptaggio e decriptaggio. LMP fornisce un
meccanismo di coordinamento e negoziazione delle chiavi di criptaggio.
Modalità basso consumo
LMP supporta il controllo della modalità di connessione basso consumo. In questo
modo, un master o uno slave possono rimanere collegati ma stare in low-power per un
tempo definito.
Controllo di potenza
Un dispositivo Bluetooth può regolare la propria potenza di emissione. Se un
dispositivo ricevente non riceve bene può richiedere al trasmittente di aumentare la
potenza col comando LMP_incr_power_req, mentre nel caso riceva un segnale più
forte
del
dovuto,
può
chiedere
una diminuzione
della
potenza,
con
un
LMP_decr_power_req.
Il controllo di potenza agisce tramite un ricevitore che esamina un segnale di
monitorazione della potenza, l’RSSI (Receiver Signal Strength Indication).
102
BLUETOOTH
Gestione degli errori
Se il LM riceve un PDU con un opcode sconosciuto, replica con un LMP_not_accepted
e con un codice che indica la ragione del non riconoscimento del LMP PDU.
Quality of Service (QoS)
Il LM permette di gestire la QoS del sistema. L’intervallo di poll, che è definito come il
massimo tempo che intercorre tra due trasmissioni consecutive dal master a un
particolare slave, viene controllato allocando la larghezza di banda e il tempo di
latenza. Inoltre, master e slave negoziano il numero di ripetizioni per i pacchetti
broadcast (NBC).
Versione LMP
Il LM supporta le richieste di versione (LMP_version_req) del protocollo LMP
posseduto da un dispositivo. Questo risponde con tre parametri, VersNr,che specifica il
numero della versione di LMP supportata, CompId, riguardo la compagnia che ha
creato l’implementazione LM, e Sub-VersNr, che indica la versione di LM sviluppata
dalla compagnia stessa.
Caratteristiche supportate
Alcune delle caratteristiche dello standard Bluetooth sono opzionali, come i pacchetti
multi-slot, il criptaggio, le modalità basso consumo, l’RSSI, il controllo di potenza, i
link SCO etc.; con il messaggio LMP_features_req si può ottenere un elenco delle
caratteristiche supportate e di quelle che non lo sono.
103
BLUETOOTH
Schema di funzionamento del Link Manager
La Figura 49 schematizza le operazioni effettuate dal livello Link Manager.
Figura 49: Operazioni LMP
Come si nota, ci sono molte strade alternative in questo diagramma, la più semplice
delle quali , dopo che è finita la fase di page o page response, è quella di scambiare
solamente un messaggio di conferma del completamento della connessione.
Altri percorsi più complicati possono includere il cambio di ruolo tra master e slave,
l’autenticazione o il criptaggio dei dati.
104
BLUETOOTH
Host Controller Interface (HCI)
Questo livello mette a disposizione dei livelli superiori un’interfaccia uniforme per
accedere alle capacità hardware (Figura 50).
In sistemi dove i livelli più alti vengono eseguiti sul processore di un dispositivo che
opera da host, mentre i livelli più bassi sono su un device Bluetooth, è richiesta
un’interfaccia tra i livelli superiori e quelli inferiori. Lo standard Bluetooth definisce a
questo scopo il livello HCI.
Figura 50: Interfaccia HCI
Il firmware HCI presente nel modulo Bluetooth traduce tutti i comandi provenienti
dall’interfaccia HCI in comandi comprensibili dal Link Manager e dal livello
Baseband. Il driver HCI presente sull’host riceve gli eventi (asincroni) dal modulo, che
indicano cosa è avvenuto (es. ricezione dati).
Il driver e il firmware comunicano tra di loro attraverso un livello di trasporto, che
permette al driver di inviare dati senza conoscere il mezzo con cui vengono trasmesse
105
BLUETOOTH
queste informazioni. Per questo livello sono definite tre tipi di interfacce, cioè USB,
UART e RS232.
Prendendo per esempio una scheda PCMCIA Bluetooth per PC, questa ha una struttura
con il Baseband e il Link Manager implementati da un processore dedicato presente
sulla card PCMCIA e i livelli più alti, come L2CAP, SDP, RFCOMM e le applicazioni,
sul processore del PC, che funziona da host.
Una scheda di questo tipo usa il livello HCI per separare i livelli inferiori e superiori
per i seguenti motivi:
-
Host come i PC hanno molta capacità per gestire i livelli superiori, permettendo ai
dispositivi Bluetooth di necessitare di meno memoria, di non avere bisogno di DSP
dedicati a calcoli, per cui si riducono i costi;
-
L’host può essere in sleep ed essere invocato dall’inizio di una connessione;
-
L’HCI è utile per i test dei dispositivi Bluetooth.
Figura 51: Posizione dell'HCI nello stack Bluetooth
In Figura 51 è mostrato come lo stack Bluetooth può essere diviso in due parti collegate
tra loro dal livello HCI.
Perchè non spostare l’intero stack su un processore host? Questo potrebbe essere fatto,
ma la temporizzazione degli slot Bluetooth implica che l’host dovrebbe essere in grado
di rispondere in tempi dell’ordine dei microsecondi agli interrupt provenienti dal livello
106
BLUETOOTH
Radio. Sebbene esistano microprocessori che garantiscono elevate prestazioni, è molto
importante mettere i livelli inferiori su un processore dedicato (Baseband Controller)
che garantisce risposte veloci.
La standardizzazione dell’HCI ha permesso di sviluppare diversi driver che possono
essere usati con una grande varietà di moduli Bluetooth, di diversa provenienza.
E’ possibile avere sistemi Bluetooth dove tutti i livelli dello stack vengono eseguiti su
un unico processore dedicato; un esempio sono gli auricolari Bluetooth, che devono
essere piccoli, a basso costo, leggeri e a basso consumo.
Pacchetti HCI
Lo standard Bluetooth definisce i seguenti tipi di pacchetti per il livello HCI:
-
pacchetti di comando usati dall’host per controllare il modulo;
-
pacchetti di evento usati dal modulo per informare l’host delle variazioni di eventi;
-
pacchetti di dati per scambiare dati e voce tra host e modulo.
In Figura 52 sono mostrati questi pacchetti e le loro direzioni di flusso.
Figura 52: Tipi di pacchetti HCI
Pacchetti di comando HCI
Sono usati dall’host per controllare il modulo Bluetooth e monitorare lo stato. La
struttura di un pacchetto di comando HCI è mostrata in Figura 53.
107
BLUETOOTH
Figura 53: HCI Command Packet
Questo tipo di pacchetto comincia con due bytes di OpCode, che identificanoin modo
univoco il tipo di comando. L’OpCode è a sua volta diviso in due parti; OpCode Group
Field (OGF) che identifica il gruppo di comandi, e OpCode Command Field (OCF) che
identifica il comando nel gruppo. L’OGF occupa i 6 bit più alti, mentre l’OCF occupa i
10 bit più bassi dell’OpCode. In Figura 54 è riportato l’esempio di un comando
HCI_Inquiry_Cancel, che ha OGF = 0x01 e OCF = 0x0002.
Figura 54: Costruzione del campo Opcode di un pacchetto di comando HCI
Il campo Opcode viene seguito da un campo di un byte contenente la lunghezza (in
byte) dei parametri che seguono. In Figura 55 è mostrato il comando
HCI_set_UART_baudrate, che serve per impostare la velocità di trasmissione sulla
108
BLUETOOTH
seriale del modulo; questo comando ha OCF = 0x0009 e OGF = 0x3F. Il parametro
0x02 indica la velocità impostata (in questo caso è 115.2 kbps).
Figura 55: Esempio di pacchetto di comando HCI
Se un comando può essere completato subito, viene restituito un evento
HCI_Command_Complete. Un’eccezione è quando si risponde a un reset, cioè al
comando
HCI_Reset.
Qui
è
impossibile
per
il
modulo
mandare
HCI_Command_Complete, e quindi lo manda prima dell’esecuzione dell’operazione.
Se un comando non può essere completato subito, si torna un HCI_Commad_Status,
fino a che l’operazione termina e viene restituito l’HCI_Command_Complete. Un
esempio è il comando HCI_Inquiry, che inizia un inquiry. Il risultato dell’inquiry non
può essere tornato fino a quando l’inquiry non è finita, e questo prenderà del tempo,
così
l’HCI_Command_Status
sarà
restituito
immediatamente
per
dire
che
l’HCI_Inquiry è stato ricevuto. Più tardi, un HCI_Inquiry_Complete verrà ritornato.
Pacchetti dati HCI
Questo tipo di pacchetti sono utilizzati per scambiare dati attraverso l’HCI, sia per
traffico ACL che SCO; a seconda del tipo di collegamento sono definti due pacchetti
dati diversi.
In Figura 56 è mostrata la struttura di un pacchetto dati ACL.
109
BLUETOOTH
Figura 56: HCI Data Packet
Il significato dei vari campi è il seguente:
-
connection handle: identifica univocamente il collegamento a un altro
dispositivo;
-
Packet Boundary flag (PB): indica se il pacchetto è l’inizio o la continuazione
di un pacchetto L2CAP più grande;
-
BroadCast flag: indica se il pacchetto deve essere trasmesso a tutte le unità
Bluetooth presenti o ad una unità ben precisa (point to point);
-
Data Total Length: indica la lunghezza dei dati trasmessi, che al massimo è
65535 byte;
-
Dati: sono i dati effettivi da trasmettere.
Un esempio di pacchetto dati ACL è mostrato in Figura 57:
Figura 57: Esempio di pacchetto dati ACL
Si nota che in un pacchetto Bluetooth, a qualsiasi livello, i parametri che occupano più
di un byte vengono inviati nell’ordine dal byte più significativo a quello meno
significativo. Nell’esempio, il campo Lunghezza dati ha valore 0x0006.
Un pacchetto dati SCO ha la struttura riportata in Figura 58:
110
BLUETOOTH
Figura 58: HCI SCO Data Packet
I pacchetti dati SCO sono molto simili a quelli ACL, con alcune differenze:
-
Non ci sono i flag PB e BC;
-
Il campo Data Total Length è solo di un byte, restringendo il campo dati ad un
massimo di 255 byte.
Un esempio di pacchetto dati SCO è riportato in Figura 59:
Figura 0.59: Esempio di pacchetto dati SCO
Pacchetti evento HCI
Il formato di un pacchetto evento HCI è mostrato in Figura 60:
Figura 60: HCI Event Packet
L’event code identifica l’evento. Il comando HCI_Set_Event_Mask è usato per dire al
modulo Bluetooth di quali eventi si vuole avere informazioni e di quali no. Il comando
HCI_Set_Event_Filter è usato per disabilitare il riporto degli eventi.
111
BLUETOOTH
Un esempio di pacchetto evento HCI è mostrato in Figura 61:
Figura 61: Esempio di pacchetto evento HCI
Livello di trasporto HCI
Per mandare pacchetti HCI dall’host al modulo Bluetooth è necessario avere un livello
di trasporto; le specifiche Bluetooth definiscono tre tipologie di interfacce:
-
USB, Universal Serial Bus;
-
UART, Universal Asynchronous Receiver Transmitter;
-
RS232, interfaccia seriale con correzione dell’errore.
Livello di trasporto UART
Questo livello di trasporto permette di collegare l’host con l’host controller attraverso
un’interfaccia seriale. Un esempio può essere il collegamento tra l’UART di un modulo
Bluetooth e l’UART di un microprocessore, oppure con l’uscita seriale di un PC,
opportunamente interfacciata tramite un MAX232 (Figura 62).
Figura 62: Interfacciamento con seriale PC
112
BLUETOOTH
Attraverso il livello di trasporto UART è possibile trasmettere quattro tipi di pacchetti
HCI, come è mostrato in tab. 2.5:
Tipo di pacchetto HCI
Indicatore
Comando
0x01
Dati ACL
0x02
Dati SCO
0x03
Evento
0x04
Tabella 5: Tipi di pacchetti su UART e indicatori HCI
In tab. 2.5 sono mostrati anche gli indicatori, che servono per differenziare i quattro tipi
di pacchetto e vengono messi davanti ad essi nella trasmissione.
Sull’interfaccia UART è anche possibile utilizzare i due segnali RTS (Request To
Send) e CTS (Clear To Send) (Figura 63); questi sono utili nel caso in cui il buffer del
modulo si riempie: se l’uscita del modulo CTS = 0 è possibile mandare dati al modulo,
mentre impostando l’ingresso del modulo RTS = 1, si disabilita il modulo dalla
ricezione di dati.
Figura 63: Connessioni per il livello di trasporto HCI UART
I parametri di default a cui viene impostato l’UART del modulo sono riportati in tab. 6:
113
BLUETOOTH
Velocità di trasmissione
57600 bps (Ericsson)
Numero di bit
8
Bit di parità
Nessuna parità
Bit di Stop
1 bit di Stop
Controllo di flusso
RTS/CTS
Tabella 6: Settaggi dell'UART
Controllo di flusso HCI
Il controllo di è utilizzato nella direzione host (microcontrollore, PC, etc.) – host
controller (nel modulo Bluetooth) per evitare di spedire dati ACL al modulo quando
questo ha il buffer di trasmissione pieno. Durante l’inizializzazione , l’host esegue il
comando HCI_Read_Buffer_Size, che tornerà dei parametri, tra cui la dimensione
massima dei pacchetti HCI ACL e SCO (header escluso) che possono essere trasmessi
dal modulo, oltre al numero di pacchetti ACL e SCO che il modulo può contenere nel
suo buffer prima della trasmissione. Quando è attiva una connessione l’host controller
usa l’evento Number_of_Completed_Packet per indicare all’host la dimensione dei dati
trasmessi e quindi della quantità di spazio che è stata liberata nel buffer. Grazie a tali
informazioni l’host è sempre a conoscenza della quantità di dati che può trasmettere al
modulo.
Può anche accadere che sia necessario il controllo di flusso nella direzione inversa (host
controller – host); ciò può accadere nel caso in cui l’host sia costituito da un
microcontrollore poco potente. Per abilitare questo controllo si utilizza il comando
Set_Host_Controller_To_Host_Flow_Control; una volta fatto ciò, con il comando
Read_Host_Buffer l’host comunica all’host controller la dimensione del suo buffer per
pacchetti HCI ACL. Quando il suo buffer si libera viene inviato al modulo il comando
Host_Number_Of_Completed_Packet, per indicare che l’host ha finito di processare il
pacchetto dati precedente.
Per quanto riguarda i comandi HCI, se il comando inviato dall’host può essere eseguito
immediatamente, il modulo risponde con un evento HCI_Command_Complete, mentre
se il comando necessita di un certo tempo per essere eseguito, il modulo torna dapprima
114
BLUETOOTH
un evento HCI_Command_Status, che indica quanti comandi sono in fase di
esecuzione e quanti se ne possono ancora eseguire, fino a quando il comando termina, e
si ritorna un HCI_Command_Complete (Figura 64).
Figura 64: Sequenza di messaggi per un comando HCI
Comandi HCI
Le specifiche Bluetooth forniscono diverse categorie di comandi HCI, attraverso i quali
è possibile configurare il modulo, controllare il collegamento, richiedere informazioni o
attivare la modalità test.
Ecco le diverse categorie di comandi HCI:
Link Control
Questa categoria di comandi consente all’host controller di controllare la connessione
ad altri dispositivi Bluetooth; quando vengono usati questi comandi, il LM controlla
come le piconet e le scatternet sono create e mantenute, e viene istruito su come
modificare la connessione, effettuare inquiry e altri comandi LMP.
115
BLUETOOTH
Questo gruppo caratterizzato da OGF = 0x01; esempi di comandi appartenenti ad esso
sono
HCI_inquiry (OCF = 0x0001), HCI_create_connection (OCF = 0x0005) e
change_connection_packet_type (OCF = 0x000F).
Link Policy
Tramite questo gruppo di comandi l’host è in grado di cambiare il modo in cui il Link
Manager gestisce la piconet., cambiando dei parametri di policy (politica). Questi
comandi sono caratterizzati da OGF = 0x02.
Esempi di comandi Link Policy sono HCI_hold_mode (OCF = 0x0001),
HCI_write_link_policy_settings (OCF = 0x000D) e HCI_QoS_setup (OCF = 0x0007).
Host Controller & Baseband
Questi comandi permettono di accedere e controllare diversi elementi dell’hardware
Bluetooth. I parametri influenzano il controllo dei dispositivi Bluetooth e le capacità
dell’host controller, del Link Manager e del livello Baseband. L’host può usare questi
comandi per modificare il comportamento del dispositivo locale che controlla. Sono
caratterizzati da OGF = 0x04; alcuni esempi di comandi Host Controller & Baseband
sono il HCI_write_scan_enable (OCF = 0x001A), il HCI_reset (OCF = 0x0003) e il
HCI_set_host_controller_to_host_flow_control (OCF = 0x0031).
Informational Parameters
Questi comandi sono fissati dalla casa costruttricedell’hardware Bluetooth, e forniscono
informazioni circa l’apparecchio Bluetooth e le capacità dell’host controller, del Link
Manager e del Baseband. L’host non può modificare nessuno di questi parametri.
Questa categoria di comandi ha OGF = 0x04, e alcuni esempi sono il
HCI_read_local_version_information (OCF = 0x0001) e il HCI_read_buffer_size
(OCF = 0x0005).
Status Parameters
L’host controller modifica tutti i suoi parametri di stato. Questi parametri forniscono
informazioni circa lo stato attuale dell’host controller, del Link Manager e del
Baseband. L’host non può modificare nessuno di questi parametri; può solo resettare
116
BLUETOOTH
alcuni parametri specifici. Il gruppo ha OGF = 0x05; alcuni esempi sono il comando
HCI_read_RSSI (OCF = 0x0005) e il HCI_get_link_quality (OCF = 0x0003).
Testing
Questi comandi sono usati per abilitare la modalità test sull’hardware Bluetooth, e
permettono di sistemare alcuni parametri sulle condizioni di test.
Sono caratterizzati da OGF = 0x06; esempi sono il read_loopback_mode (OCF =
0x0001) e il enable_device_under_test_mode (OCF = 0x0003).
Inquiry
Nel par. 2.6.4 si è visto come il livello Baseband usa l’operazione di inquiry per
scoprire altri dispositivi Bluetooth nelle vicinanze; tutti gli aspetti del processo di
inquiry sono controllabili attraverso l’HCI.
Avvio di un inquiry
Il comando HCI_inquiry viene usato per iniziare il processo di inquiry. Ha tre
parametri:
-
Inquiry LAP – l’access code utilizzato;
-
Inquiry length – la lunghezza temporale dell’inquiry (in unità di 1.28 s);
-
Num_responses – il numero di risposte per cui aspettare.
In Figura 65 è mostrato un esempio di comando di inquiry; si nota come il parametro
Inquiry_LAP = 0x9E8833 (da Bluetooth Assign Number), Inquiry length = 5 (6.4 s) e
Num_responses = 0, cioè numero illimitato di risposte.
Figura 65: Comando HCI_inquiry
117
BLUETOOTH
Gestione delle risposte all’inquiry
Le risposte all’inquiry vengono riportate nell’evento HCI_Inquiry_Result. I parametri
ritornati sono i seguenti:
-
Numero di risposte (1 byte);
-
BD_ADDR del dispositivo trovato (6 byte);
-
Page scan repetition mode (1 byte), R0 continuo, R1 page scan ogni 1.28 s, R2
ogni 2.56 s;
-
Page scan period mode (1 byte), P0 (≥ 20 s), P1 (≥ 40 s) e P2 (≥ 60 s);
-
Page scan mode (1 byte),;
-
Classe del dispositivo (3 byte);
-
Clock offset (2 byte), I bit CLKN[16:2] del clock del device che risponde
all’inquiry.
In Figura 66 è mostrato un esempio di risposta all’inquiry.
Figura 66: Evento Inquiry_response
La Figura 67 mostra la sequenza di messaggi HCI scambiati tra host e modulo
Bluetooth durante una procedura di inquiry. Si nota come, mentre l’inquiry è in corso, il
modulo ritorna un evento Command_status, e in seguito vengono restituiti due eventi di
Inquiry_Result, uno per ciascun dispositivo Bluetooth trovato.
118
BLUETOOTH
Figura 67: Sequenza di messaggi HCI durante un'operazione di inquiry
Temporizzazione delle operazioni di inquiry
Per fare in modo che un apparecchio Bluetooth funzionante da master in una piconet sia
in grado di aggiornare continuamente la configurazione della propria rete ad hoc, si
vorrebbe che esso fosse in fase di inquiry in continuazione, cioè sia alla ricerca
continua di nuovi dispositivi; questo però comporterebbe elevati consumi in termini di
batterie, per cui ci si limita ad effettuare operazioni di inquiry periodiche per brevi
intervalli. Un host mette un modulo Bluetooth in inquiry periodica tramite il comando
HCI_Periodic_Inquiry_Mode, che fa parte dei comandi LINK Control, nel quale si
specificano alcuni parametri quali l’intervallo in cui si ripete l’inquiry e la lunghezza.
Inquiry scan
Nel paragrafo 2.6.4 è stato descritto come un dispositivo Bluetooth si rende disponibile
ad essere scoperto da altri dispositivi entrando nella procedura di inquiry scan. Tramite
l’HCI è possibile configurare alcuni parametri di questa procedura.
Temporizzazione dell’Inquiry scan
Si presenta anche qui il problema del consumo per dispositivi che opera un inquiry
scanning. La soluzione è effettuare operazioni di scan per brevi intervalli
periodicamente. Il GAP (Generic Access Profile) raccomanda di effettuare scansioni in
119
BLUETOOTH
finestre di 10.625 ms distanziate al massimo di 2.56 s l’una dall,altra. Questo è in
relazione al fatto che il GAP raccomanda anche di effettuare inquiry di durata di 10.24
s, in modo da essere sicuri che un dispositivo riesca a farsi scoprire (Figura 68).
Figura 68: Temporizzazioni raccomandate per Inquiry e inquiry scan
Abilitazione dell’Inquiry scan
Per abilitare un dispositivo ad entrare in Inquiry scan bisogna utilizzare il comando
HCI_Write_Scan_Enable, con il quale si sceglie se abilitare o meno anche il Page scan.
Infatti questa procedura richiede un parametro (1 byte), che assume questi significati:
-
0x00: default, nessuna scansione abilitata;
-
0x01: abilitato solo Inquiry scan;
-
0x02: abilitato solo Page scan;
-
0x03: abilitate entrambe le scansioni.
Creazione di una connessione
Un dispositivo Bluetooth si connette ad altri effettuando delle operazioni di page, ossia
delle “chiamate”, spedendo dei pacchetti ID (paragrafo 2.6.5).
Un host utilizza il comando HCI_create_connection per iniziare la procedura di page.
Questo comando appartiene alla categoria dei comandi Link Control, e contiene i
seguenti parametri:
-
BD_ADDR: l’indirizzo Bluetooth del dispositivo a cui connettersi;
-
Packet type: tipo di pacchetto da utilizzare (DH1, DM1, DH3,etc.);
120
BLUETOOTH
-
Page_ scan_repetition_mode: intervallo tra due page consecutivi;
-
Page_scan_mode: modalità di page scan;
-
Clock_Offset: clock offset stimatodel dispositivo chiamato rispetto a quello
locale;
-
Allow_role_switch: abilita o meno lo scambio di ruoli.
In Figura 69a è mostrato un esempio di comando HCI_create_connection.
Figura 69: a) Comando HCI_Create_Connection, b) evento HCI_Connection_Request, c) comando
HCI_Accept_Connection_Request
Se un page scan ha successo, il modulo Bluetooth del master spedisce pacchetti ID al
modulo dello slave, il quale, se non è configurato per accettare automaticamente la
connessione, annuncia all’ host che ha subito un’operazione di page, cioè è stato
“chiamato”, spedendo un evento HCI_connection_Request (Figura 69b); l’host
risponde con un HCI_Accept_Connection_Request (Figura 69c) o con un
HCI_Reject_Connection_Request.
In Figura 70 è mostrata la sequenza di pacchetti HCI scambiati tra host e modulo del
futuro master e tra host e modulo del futuro slave durante il page e il page scan
rispettivamente.
121
BLUETOOTH
Figura 70: Sequenza di messaggi HCI nella creazione di una connessione
E’ possibile impostare un tempo massimo per cui il modulo aspetta il comando
HCI_Accept_Connection_Request.
Questo
si
può
fare
tramite
il
comandi
HCI_Write_Connectio_Timeout. Questo valore è di default pari a 5 s, ma può assumere
valori tra 0.625 ms e 29 s. Se entro questo tempo l’host non dà risposta, la richiesta di
connessione
cade
e
come
se
l’host
avesse
inviato
un
messaggio
HCI_Reject_Connection_Request.
Se l’host accetta la connessione, dopo uno scambio di messaggi a livello Baseband e
LM per l’instaurazione della connessione, i due moduli inviano ai rispettivi host dei
pacchetti evento HCI_Connection_Complete (Figura 71).
Figura 71: Evento HCI_Connection_Complete
122
BLUETOOTH
Trasmissione e ricezione dati HCI
Quando
una
connessione
è
creata
attraverso
il
livello
HCI,
l’evento
Connection_Complete che viene ritornato all’host contiene un campo di due byte
chiamato connection_handle (Figura 71). Quando l’host trasmette e riceve dati, questo
connection_handle viene utilizzato nel pacchetto dati HCI ACL per identificare la
connessione.
In Figura 72 è mostrato come i dati vengono scambiati.
Figura 72: Sequenza di messaggi HCI per traffico ACL
I pacchetti HCI_ACL_Data, contengono i dati da spedire dall’host al modulo Bluetooth
del dispositivo trasmettitore. Questi pacchetti dati HCI vengono processati dai livelli
inferiori dello stack, e ciò che va effettivamente in aria sono i pacchetti Baseband. In
Figura 72 si nota che, sempre a livello Baseband, vengono restituiti dei segnali di ACK
(In caso di segnale NAK avviene la ritrasmissione).
Quando un pacchetto viene inviato con successo il modulo Bluetooth restituisce
l’evento HCI_Number_Of_Completed_Packet, che contiene nei suoi parametri il
numero di pacchetti inviati e il connection_handle in questione (quindi la connessione).
123
BLUETOOTH
Logica Link Control and Adaptation Protocol
(L2CAP)
Questo livello preleva dati dai livelli superiori dello stack Bluetooth e dalle applicazioni
e li inoltra verso i livelli inferiori. L2CAP mette a disposizione dei livelli superiori
servizi dati connection-less e orientati alla connessione, oltre a eseguire operazioni di
multiplexaggio, segmentazione e riassemblaggio dei pacchetti, e permette ai protocolli
di livello superiore di trasmettere e ricevere pacchetti fino a 64 kbyte di lunghezza.
Il Baseband supporta due tipi di collegamento, sincrono (SCO) e asincrono (ACL),
mentre le specifiche Bluetooth L2CAP si riferiscono solo ai collegamenti ACL, senza
definire nessun supporto per i link SCO.
In Figura 73a è mostrata la posizione del livello L2CAP in un sistema senza host,
mentre in Figura 73b è mostrato un sistema con host.
Figura 73: Posizione del livello L2CAP nello stack Bluetooth
Le principali funzioni del livello L2CAP sono:
-
Multiplexaggio dei diversi livelli superiori, permettendo loro di condividere i
livelli inferiori;
-
Segmentazione e riassemblaggio dei pacchetti;
-
Gestione dei gruppi, mettendo a disposizione dei livelli superiori l’astrazione di
gruppo sulla piconet;
-
124
Gestione della Qualità of Service per i livelli superiori.
BLUETOOTH
Protocol Multiplexing
L2CAP fornisce questo servizio per permettere a diversi protocolli di livello superiore
di passare dati attraverso un singolo canale ACL; questo livello deve essere quindi in
grado di distinguere i protocolli che girano a livello superiore, in quanto i livelli
inferiori non supportano nessun tipo di campo per i livelli superiori, quali RFCOMM,
SDP e Telephony Control.
Per fare ciò si usa un campo detto PSM (Protocol Service Multiplex), che occupa due
byte nei segnali L2CAP, e che indica il livello superiore che sta occupando il canale. In
tab. 7 sono mostrati i possibili valori che può assumere il PSM.
PSM value
Description
0x0001
SDP
0x0003
RFCOMM
0x0005
Telephony Control
< 0x1000
Riservato
Tabella 7: Valori PSM
Questa funzionalità permette di avere più applicazioni sullo stesso host che
condividono lo stesso collegamento.
L2CAP utilizza un numero di canale, detto channel identifier, per etichettare i pacchetti
quando vengono ricevuti e indirizzarli verso il corretto posto.
Un generico pacchetto L2CAP assume la struttura riportata in Figura 74:
Figura 74: Struttura di un pacchettoL2CAP
Gli identificatori di canale (tab. 7) sono dei numeri locali che identificano un terminale
di un canale logico e sono costituiti da due byte. Il CID = 0x0001 viene usato per i
125
BLUETOOTH
segnali di controllo, mentre i CID che vanno da 0x0040 in poi vengono allocati
dinamicamente, cioè alla prima connessione viene assegnato CID = 0x0040, alla
seconda CID = 0x0041 e così via in modo sequenziale.
CID
Descrizione
0x0000
ID nullo
0x0001
Canale di controllo
0x0002
Connection – Less
0x0003 – 0x003F
Riservati
0x0040 – 0xFFFF
Allocati Dinamicamente
Tabella 8: CID e loro utilizzo
Segmentazione e riassemblaggio
I pacchetti definiti in banda base hanno delle dimensioni limitate; utilizzando il
pacchetto più grande (DH5), si ha un MTU (Maximun Transfer Unit) di 339 byte, che
limita notevolmente l’uso della banda da parte dei pacchetti che, a livello superiore,
sono progettati per pacchetti più grandi.
Il livello L2CAP si occupa di prendere pacchetti di dimensioni maggiori e di
suddividerli in più pacchetti compatibili con il Baseband; inoltre assolve anche il
riassemblaggio di tali pacchetti in banda base, riportandoli alle dimensioni idonee per i
livelli superiori.
Nella procedura di segmentazione il protocollo L2CAP deve scoprire la dimensione
massima che può trasmettere il livello sottostante.
Nel caso in cui L2CAP è presente sul dispositivo senza host (Figura 73a), la
dimensione massima è data dal tipo di pacchetto utilizzato nel livello Baseband (es.
DH3,DM5,etc.); nel caso di sistema con host, è presente il livello HCI, per cui è
necessario eseguire all’inizializzazione dello stack un comando per determinare la
dimensione del buffer HCI presente nel modulo Bluetooth utilizzato.
La segmentazione utilizza poche risorse nei pacchetti in banda base; infatti i primi due
bit del payload header (Figura 33), cioè il campo L_CH, sono definiti per segnalare
126
BLUETOOTH
l’inizio di un pacchetto L2CAP (L_CH = 10) o la continuazione (L_CH = 01) (Figura
75).
Figura 75: Segmentazione di un pacchetto L2CAP
Qualità del servizio (QoS)
Il processo di connessione a livello L2CAP permette di negoziare una certa qualità del
servizio (banda passante, velocità di comunicazione, tempo di latenza, etc.) tra due
unità Bluetooth che hanno instaurato un collegamento ACL.
Il protocollo L2CAP si occupa poi di fare in modo che queste caratteristiche di
comunicazione stabilite nella negoziazione siano garantite, per esempio eseguendo la
funzione HCI_QoS_Setup, che si occupa di impostare i parametri del QoS per una
connessione.
Gestione dei gruppi
Molti protocolli includono il concetto di gruppo di indirizzi. Il livello Baseband
supporta il concetto di piconet, cioè di un insieme di dispositivi che seguono assieme lo
stesso clock, mentre il livello L2CAP mette a disposizione dei livelli superiori
l’astrazione di gruppo sulla piconet, permettendo così a alle applicazioni di mappare in
modo efficiente dei gruppi di protocolli sulla piconet.
Operazioni L2CAP
I messaggi L2CAP vengono scambiati sul canale allocato al channel ID 0x0001, che
viene usato per spedire informazioni di controllo tra livelli L2CAP per gestire e
127
BLUETOOTH
configurare connessioni. L’implementazione L2CAP deve essere in grado di
determinare l’indirizzo Bluetooth (BD_ADDR) del dispositivo che ha mandato il
comando. Le specifiche Bluetooth assegnano dei nomi precisi ai messaggi scambiati
dal livello L2CAP con i livelli inferiori, superiori e pari (Figura 76).
Il prefisso L2CAP_ indica un messaggio scambiato tra entità di pari livello, L2CA_
indica i messaggi scambiati tra L2CAP e livelli superiori, mentre LP_ indica i messaggi
scambiati tra L2CAP e livelli inferiori.
Figura 76: Interazioni L2CAP con gli altri livelli
In Figura 77 è rappresentata la sequenza con cui avvengono le richieste e le risposte tra
i vari livelli. Le due linee verticali esterne rappresentano le interfacce L2CA
sull’iniziatore (il dispositivo che inoltra la richiesta) e l’accettore (il dispositivo che
risponde alla richiesta). Quando il protocollo comunica all’interfaccia L2CA
dell’accettore la richiesta, questa manda un’indicazione (L2CA_Indication) ai livelli
superiori, che risponderanno con una risposta L2CA_Response. All’interfaccia L2CA
dell’iniziatore verrà tornata una conferma L2CA_Confirm.
128
BLUETOOTH
Figura 77: Sequenza temporale di messaggi tra i livelli
Azioni L2CAP verso i livelli inferiori
-
LP_Connect_Req: L2CAP richiede ai protocolli inferiori di creare una
connessione;
-
LP_QoS_Req: richiede ai livelli inferiri di modificare un determinato parametro
della QoS;
-
LP_Connect_Rsp: risposta positiva a una precedente indicazione di connessione;
-
LP_Connectt_Rsp_Neg: risposta negativa a una indicazione di connessione.
Eventi verso L2CAP dai livelli inferiori
-
LP_Connect_Cfm: conferma la richiesta di creare una connessione a livello
Baseband provenente da L2CAP;
-
LP_Connect_Cfm_Neg: indica il fallimento della richiesta di connessione;
-
LP_Connect_Ind: indica che i protocolli di livello inferiore hanno stabilito con
successo una connessione;
-
LP_Disconnect_Ind: indica che i livelli più bassi sono stati disattivati da un
comando LMP o da un timeout;
-
LP_QoS_Cfm: conferma la richiesta di QoS;
-
LP_QoS_Cfm_Neg: indica il fallimento della richiesta di QoS;
-
LP_QoS_Violation_Ind: indica che i livelli inferiori hanno rilevato una violazione
delle specifiche riguardo la Quality of Service.
129
BLUETOOTH
Azioni L2CAP verso i livelli superiori
-
L2CA_Connect_Ind: indica una richiesta di connessione;
-
L2CA_Connect_Cfm: conferma una richiesta di connessione;
-
L2CA_Connect_Cfm_Neg: indica il fallimento di una richiesta di connessione;
-
L2CA_Config_Ind: indica una richiesta di configurazione;
-
L2CA_Config_Cfm: conferma una richiesta di configurazione;
-
L2CA_Config_Cfm_Neg: indica il fallimento di una richiesta di configurazione;
-
L2CA_Disconnect_Ind: indica una richiesta di disconnessione;
-
L2CA_disconnect_Cfm: conferma una richiesta di disconnessione;
-
L2CA_Timeout_Ind: indica che è scaduto un determinato timeout;
-
L2CA_QoS_Violation: indica che è stato violato un parametro del QoS.
Eventi verso L2CAP dai livelli superiori
-
L2CA_Connect_Req: richiesta da un livello superiore di creare un link;
-
L2CA_Connect_Rsp: risposta positiva da un livello superiore alla richiesta di
connessione;
-
L2CA_Connect_Rsp_Neg: risposta negativa da un livello superiore alla richiesta
di connessione;
-
L2CA_Config_Req: richiesta da un livello superiore di configurare il canale;
-
L2CA_Config_Rsp: risposta positiva da un livello superiore alla richiesta di
configurazione del canale;
-
L2CA_Config_Rsp_Neg: risposta negativa da un livello superiore alla richiesta di
configurazione del canale;
-
L2CA_Disconnect_Req: richiesta da un livello superiore di disconnettere il
canale;
-
L2CA_Disconnect_Rsp: risposta positiva alla richiesta di disconnessione del
canale;
-
L2CA_Data_Read: richiesta da un livello superiore di leggere i dati ricevuti dai
livelli inferiori;
-
L2CA_Data_Write: richiesta da un livello superiore di trasmettere dati ai livelli
inferiori.
130
BLUETOOTH
Messaggi tra livelli L2CAP
-
L2CAP_Connect_Req: è stata ricevuto una richiesta di connessione;
-
L2CAP_Connect_Rsp: è stato ricevuto una conferma alla richiesta di connessione;
-
L2CAP_Connect_Rsp_Neg: è stata ricevuta una risposta negativa alla richiesta di
connessione;
-
L2CAP_Config_Req: è stata ricevuta una richiesta di configurazione;
-
L2CAP_Confiq_Rsp:
è
stata
ricevuta
una
conferma
alla
richiesta
di
configurazione;
-
L2CAP_Config_Rsp_Neg: è stata ricevuta una risposta negativa alla richiesta di
configurazione;
-
L2CAP_Disconnect_Req: è stata ricevuta una richiesta di disconnessione;
-
L2CAP_Disconnect_Rsp: è stata ricevuta una conferma alla richiesta di
disconnessione.
-
L2CAP_Connect_Rsp_Pnd: indica che la richiesta di connessione è stata ricevuta
ed è in fase di elaborazione da parte del terminale remoto.
Stati del canale L2CAP
Il canale L2CAP può essere in vari stati:
-
CLOSED: in questo stato non è presente nessun canale;
-
W4_L2CAP_CONNECT_RSP: aspetta una risposta alla richiesta di connessione
da parte di un terminale remoto;
-
W4_L2CA_CONNECT_RSP: aspetta una risposta da I livelli superior riguardo
alla richiesta di connessione;
-
CONFIG: la connessione è stabilita, ma entrambi i dispositivi stanno ancora
negoziando i parametri del canale. Per passare allo stato OPEN è necessario che
entrambi i dispositivi siano pronti;
-
OPEN: la connessione è stabilita e configurata e i dati possono essere trasmessi e
ricevuti;
-
W4_L2CAP_DISCONNECT_RSP: si sta apettando una risposta alla richiesta di
chiusura della connessione;
131
BLUETOOTH
-
W4_L2CA_DISCONNECT_RSP: si apstta una risposta dai livelli superiori alla
richiesta di chiusura della connessione.
In Figura 78 è mostrato uno schema che evidenzia gli stati e gli eventi che causano le
transizioni da uno stato all’altro del canale L2CAP durante la creazione e la chiusura di
una connessione.
Figura 78: Stati e eventi che provocano le transizioni del canale L2CAP
132
BLUETOOTH
Pacchetti L2CAP
Come tutti gli altri livelli Bluetooth, anche il livello L2CAP usa delle strutture di
pacchetti comuni (Figura 79).
Figura 79: Struttura pacchetti L2CAP
Pacchetti dati L2CAP
Il formato di un pacchetto dati L2CAP rispecchia il formato generico di Figura 79 e il
campo dati contiene esclusivamente byte che rappresentano dati utili trasmessi.
In Figura 80 è mostrato un pacchetto dati L2CAP visto dal livello HCI e poi dal livello
L2CAP.
Figura 80: Pacchetto dati L2CAP a livello HCI e L2CAP
133
BLUETOOTH
Pacchetti di segnali L2CAP
Un segnale L2CAP ha la struttura riportata in Figura 81.
Figura 81: Struttura di un pacchetto di comando L2CAP
Il primo byte indica l’Opcode del comando e identifica il contenuto del segnale; c’è poi
un byte , Identifier, che serve , per far corrispondere una richiesta con la sua risposta. E’
utile in particolare per quelle richieste che devono essere spedite in più di un pacchetto.
C’è poi il campo Length che indica la lunghezza dei dati del comando, e Data, che
contiene i parametri della richiesta. In tabella 8 sono mostrati i vari opcode disponibili
per i comandi L2CAP.
Codice
Descrizione
0x01
Comando rifiutato
0x02
Richiesta di connessione
0x03
Risposta a richiesta di connessione
0x04
Richiesta di configurazione
0x05
Risposta a richiesta di configurazione
0x06
Richiesta di disconnessione
0x07
Risposta a richiesta di disconnessione
0x08
Richiesta di echo
0x09
Risposta all’echo
0x0A
Richiesta di informazioni
0x0B
Risposta alla richiesta di informazioni
Tabella 9: Codici comandi L2CAP
134
BLUETOOTH
Un esempio di pacchetto di comando L2CAP, in particolare L2CAP_Connect_Req,
cioè una richiesta di connessione, è mostrato in Figura 82:
Figura 82: Pacchetto L2CAP_Connect_Req
Si nota Opcode = 0x02, che indica L2CAP_Connect_Req, Identifier = 0x01, ad indicare
che è la prima richiesta, Length = 0x0004, cioè ci sono quattro byte di dati, PSM =
0x0001, cioè il livello superiore è SDP e Source CID = 0x0040, cioè è il primo canale
stabilito.
Creazione di una connessione
Il livello L2CAP utilizza link ACL per trasmettere dati senza errori attraverso i livelli
inferiori dello stack Bluetooth. Per stabilire un collegamento, viene utilizzata la
sequenza di messaggi illustrata in Figura 83.
L’applicazione che inizia la connessione richiede al livello L2CAP di connettersi
attraverso il comando L2CA_Connect_Req (1). Se non ci sono già link ACL esistenti,
L2cCAP manda un comando HCI_create_connection (2) al livello HCI, che è quello
immediatamente sotto. Il livello HCI inoltra al Link Manager la richiesta
LM_Connect_Req
(4),
che
provoca
un
messaggio
a
livello
LM
(LMP_Host_Connection_Req (5)) e le procedure di paging a livello Baseband. Il livello
135
BLUETOOTH
LM del dispositivo che deve accettare la connessione manda all’HCI un messaggio
LM_Connect_Req_Ind (7), ad indicare una richiesta di connessione dai livelli inferiori.
Figura 83: Messaggi per la creazione di una connessione L2CAP su HCI
L’HCI invia al livello L2CAP l’evento HCI_Connection_Request_Event (8); L2CAP
risponde
con
un
comando
HCI_Accept_Connection_Request (9).
136
di
accettazione
della
connessione,
BLUETOOTH
Per il preciso scambio di pacchetti a livello HCI si rimanda al paragrafo 2.8.7.
L’HCI inoltra ai livelli inferiori la risposta positiva dell’host alla richiesta, con un
LM_Connect_Rsp (10), si hanno poi due messaggi a livello LMP, LM_Accepted (11) e
LM_setup_complete (12); il LM del dispositivo che richiede la connessione manda al
proprio HCI il messaggio LM_Connect_Cfm (13) di conferma della connessione e poi i
due HCI possono mandare entrambi l’evento HCI_Connectio_Complete_event al
proprio L2CAP. Segue ora una serie di messaggi a livello L2CAP.
Il messaggio L2CAP_Connect_Req (15) ha la struttura riportata in Figura 84, ed è
codificato come visto in Figura 82.
Figura 84: Struttura di un pacchetto L2CAP_Connect_Req
Il messaggio di risposta L2CAP_Connect_Rsp, ha invece la struttura di Figura 85:
Figura 85: struttura di un pacchetto L2CAP_Connect_Rsp
Osservando tale pacchetto a livello HCI, si può vedere la sua codifica (Figura 86).
137
BLUETOOTH
Figura 86: Pacchetto L2CAP_Connect_Rsp
Il campo Destination CID contiene il CID che verrà usato per la connessione dal
dispositivo che sta rispondendo, mentre il Source CID viene copiato dal
L2CAP_Connect_Req.
Configurazione di una connessione
Una volta che la connessione è stata stabilita, deve essere configurata. Il livello L2CAP
del
dispositivo
che
ha
iniziato
la
connessione
manda
un
messaggio
L2CAP_Config_Req, e il livello L2CAP dell’altro dispositivo dovrà rispondere con un
messaggio L2CAP_config_Rsp in caso tutto vada bene, mentre se qualche parametro
non va risponderà con un L2CAP_Config_Rsp_Neg.
La codifica di un pacchetto L2CAP_Config_Req è mostrata in Figura 87.
Figura 87: Pacchetto L2CAP_Config_Req
138
BLUETOOTH
Tramite questo messaggio, è possibile configurare diversi parametri, variando il campo
Type :
-
0x01 per MTU – impostazione massima dimensione pacchetto L2CAP;
-
0x02 per Flush_timeout – impostazione tempo in ms per cui il dispositivo deve
tentare di ritrasmettere un pacchetto fino a quando l’ha trasmesso con successo;
-
0x03 per QoS – impostazione parametri QoS.
Nel progetto verrà impostata la massima dimensione per un pacchetto L2CAP di 200
byte.
La codifica di un pacchetto L2CAP_Config_Rsp è mostrata in Figura 88.
Figura 88: Pacchetto L2CAP_Config_Rsp
Il campo RESULT = 0x0000 significa che l’operazione di configurazione è stata
eseguita con successo.
RFCOMM
Il protocollo RFCOMM è posizionato sopra il livello L2CAP e mette a disposizione
un’emulazione della porta seriale. Tramite questa emulazione, è possibile far girare
tutte le applicazioni che basano il loro funzionamento sulla presenza della porta seriale
senza apportare loro nessuna modifica.
RFCOMM è basato su GSM T07.10, che è un protocollo asimmetrico usato dai
cellulari GSM per multiplexare stringhe di dati su una linea seriale fisica, e mette a
139
BLUETOOTH
disposizione delle applicazioni una porta seriale con i nove segnali RS232; supporta
fino a 60 connessioni simultanee tra due dispositivi.
Il protocollo PPP (Point to Point Protocol), che è utilizzato nei collegamenti internet, ha
bisogno della presenza della porta seriale. Con il protocollo RFCOMM è possibile
utilizzare il sistema PPP per creare una rete locale oppure collegarsi ad internet senza
nessun cambiamento al programma che gestisce il PPP.
All’interno dei profili dello standard Bluetooth è presente il profilo LAN, che permette
di creare una rete locale senza fili tramite il Bluetooth. Questo profilo è possibile grazie
a RFCOMM che permette di instaurare una connessione PPP e su questa far girare il
TCP/IP o qualsiasi applicazione necessaria.
RFCOMM comunica con le trame, che diventano data payload nei pacchetti L2CAP. Ci
sono cinque tipi di trame diversi:
-
SABM (Start Asynchronous Balanced Mode), usato per i comandi di inizio;
-
UA (Unnumbered Acknowledge), usato in risposta quando connesso;
-
DISC (Disconnect), comandi di disconnessione;
-
DM (Disconnected Mode), usato in risposta a un comando quando disconnesso;
-
UIH (Unnumbered Information with Header Check)
RFCOMM usa i canali, ognuno dei quali ha un DLCI (Data Link Connection
Identifier), che è diverso da zero per spedire i dati e uguale a zero per spedire messaggi
di controllo.
A causa del fatto che le trame RFCOMM sono portate nel payload dei pacchetti
L2CAP, è necessario settare una connessione L2CAP prima di una connessione
RFCOMM.
RFCOMM ha un valore PSM riservato per L2CAP, pari a 0x0003. Ogni trama L2CAP
ricevuta con questo PSM sarà spedita a RFCOMM.
La prima trama spedita al canale RFCOMM è SABM (Start Asynchronous Balanced
Mode). Se il dispositivo RFCOMM rispondente si connette, va in ABM (Asynchronous
Balanced Mode) e manda una trama UA (Unnumbered Acknowledgement). Se non si
vuole connettere, rifiuta e manda una trama DM (Disconnected Mode).
140
BLUETOOTH
Service Discovery Protocol (SDP)
Il Service Discovery Protocol (protocollo per la ricerca dei servizi) mette a disposizione
dei dispositivi Bluetooth un mezzo per scoprire le caratteristiche e i servizi offerti da
altri dispositivi bluetooth presenti nelle vicinanze. Una volta che una connessione
L2CAP è stata stabilita tra un client (cioè il dispositivo che inizia la richiesta di
connessione) e un server SDP (cioè il dispositivo che riceve la richiesta), il client può
navigare all’interno delle informazioni presenti nel server e decidere se la
comunicazione tra i due dispositivi può continuare perché è stata trovata l’applicazione
che serve oppure se disconnettersi.
Per esempio se un dispositivo che vuole accedere a internet può interrogare un server
SDP per verificare se è presente un access point.
Per trovare una connessione a un servizio offerta da un server SDP, un client deve
passare attraverso i seguenti passi:
-
stabilire una connessione L2CAP ad un device remoto usando il canale
identificato dal PSM=0x0001;
-
cercare una classe specifica di servizi;
-
recuperare gli attributi necessari per connettersi ai servizi scelti;
-
stabilire una connessione separata (non SDP) per usare il servizio.
Il canale L2CAP usato per il SDP può essere escluso una volta che non è richiesto a
lungo, oppure può venire aperto se il client vuole chiedere al server database per altri
servizi.
Il valore del protocollo L2CAP e del Protocol Service Multiplexor (PSM) per SDP è
definito come 0x0001. Avere PSM noto significa che una volta che un link ACL è stato
stabilito, il client SDP automaticamente conosce il numero da usare per stabilire un link
con il server SDP sul dispositivo remoto.
Bluetooth non definisce un’interfaccia con l’uomo per il SDP; definisce solamente il
protocollo di scambio di dati tra un server che offre servizi e un client che spera di
usarli.
141
BLUETOOTH
Profili
Nello standard Bluetooth vengono definiti vari profili, nei quali vengono descritti i
formati dei pacchetti per varie applicazioni (stampante, accesso LAN, IP su Bluetooth,
etc.). Tramite la definizione di questi profili è possibile rendere interoperabili prodotti
di produttori diversi. Inoltre tramite il SDP è possibile scoprire i servizi che un altro
dispositivo mette a disposizione. Per esempio, se si è in un aeroporto e ci si vuole
connettere a internet, è possibile fare un inquiry per scoprire se nelle vicinanze è
presente un dispositivo Bluetooth, e poi con il SDP vedere se è un access point o meno.
In caso positivo è possibile usare il profilo LAN per comunicare con l’access point.
Un profilo molto interessante per il futuro è il BNEP (Bluetooth Network
Encapsulation Protocol), e un diagramma dell’implementazione è mostrato in Figura
89.
Figura 89: Stack Bluetooth con il protocollo BNEP
Questo protocollo permette di trasmettere pacchetti IP direttamente sopra il livello
L2CAP. Per far ciò L2CAP deve essere in grado di supportare un MTU (Maximun
Transfer Unit) di 1691 byte. Questo in base alla dimensione massima di un pacchetto
Ethernet (1500 byte), con l’aggiunta di un’intestazione BNEP (15 byte), un’intestazione
L2CAP (4 byte) e altre intestazioni opzionali. Un pacchetto di 1691 byte corrisponde a
5 pacchetti DH5 (5*339), meno i 4 byte dell’header L2CAP.
142