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 dellelettronica, 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 doggi 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 lintervento umano. Infatti
se un dispositivo entra o esce dalla zona coperta dal master viene riconosciuto o tolto
dalla rete automaticamente. Questo grazie alloperazione di inquiry, attraverso la quale
i dispositivi Bluetooth periodicamente sono in grado di scoprire lesistenza 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 allinterno 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 unauricolare,
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 questultimo 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 nellaltra. 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 lutilizzo 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 lunit 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

Lutilizzo 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 unaltra per il livello logico basso.
Linformazione digitale viene prefiltrata con un impulso Gaussiano, in modo che il
passaggio da una frequenza allaltra 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 derrore.
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 quellintervallo 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 luno dallaltro, 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 unalta 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 loperazione 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 unaltra sequenza di hopping, facendo loperazione di
despreading in ricezione, legata per alla nostra sequenza, il nostro segnale utile torna a
banda stretta, mentre linterferenza, 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)

100 mW (20 dBm)

100 m

2.5 mW (4 dBm)

10 m

1 mW (0 dBm)

1m

Tabella 1: Classi di potenza Bluetooth

I dispositivi di Classe 1 hanno dobbligo 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, lRSSI (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 unaccuratezza 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 linterruttore dellantenna (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 lesatta 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 lesperienza
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 lincertezza 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 laccensione 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 lattivazione 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 lattivazione della linea SynthOn prima di attivare la linea RxOn. Inoltre c il
tempo TPHD, che indica il tempo da far trascorrere dopo lattivazione 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 nellaltra
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 dallindirizzo 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 625s 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 allaccensione 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 lintegrit 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 laccess 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 delloffset in continua e lidentificazione, in quanto
laccess 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 dellaccess 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.
Laccess 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 unoperazione 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 dellaccess 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 lindirizzo 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 lAM_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 lintegrit

dellheader.
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 derrore
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 linizio 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 derrore
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 lintegrit 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.

0101

SCO

HV1

Porta 10 byte di informazione. Usa FEC

1/3.

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

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.

1011

ACL

DH3

Porta 183 byte di informazione. Non usa

FEC.

1110

ACL

DM5

Porta 224 byte di informazione. Usa FEC

2/3.

1111

ACL

DH5

Porta 339 byte di informazione. Non usa

FEC.

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 luno dallaltro a seconda del numero di
time slot occupati, della codifica di correzione derrore utilizzata e del fatto che siano
pacchetti voce SCO o dati ACL.
Lidentificazione 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 allerrore, 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 luno
dallaltro 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 nellaltra 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 625s

Guardando invece la modalit asimmetrica, possibile prendere lesempio di pacchetti

DH5 in una direzione e DH1 nellaltra: 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
= 366s
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 lARQ 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 laltro 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 lultimo 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
unindicazione di STOP sul canale LC di ritorno (bit Flow). Quando il trasmettitore
riceve lindicazione di STOP, ferma la sua coda FIFO. Quando il ricevitore torna ad
essere pronto, trasmette unindicazione 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

allinterno 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 daccesso.

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 lACK viene caricato a spalle del
payload del pacchetto di ritorno.
Le possibili cause di ritrasmissione sono:
-

il ricevitore non rileva laccess 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 lultimo payload arrivato. Il Link Manager pu richiedere al
Link Controller di effettuare unoperazione 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 dellARQN 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 allaltro ed effettua operazioni
di alto livello, come stabilire la connessione sotto il controllo di unapplicazione
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 linquiry (Figura 31).

Figura 31: Struttura del pacchetto FHS

Il pacchetto FHS permette allinquisitore 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 dellaccess
code, e il BCH, che costituisce anchesso una parte dellaccess code.
-

Inquiry scan

E latra 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 lapplicazione, 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

dallapplicazione 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 lFHS (usando laccess 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 linquiry 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 lFHS 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 lindirizzo 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 loffset 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 lintero 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 laccess 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 lAM_ADDR non il suo e deve interrompere la
risposta. Fino a che il campo packet type dellheader non dir quanti slot il
pacchetto occuper, potr usare le informazioni per entrare in Low Power Sleep
mode per lintera 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 lhold 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 linquiry, 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 lapparentemente 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 linquiry pu durare molti secondi, il
master si muover effettivamente dalla connessione allinquiry, allo scan o al page e
torner alla connessione lavorando con linsieme di dispositivi che interagiscono
attorno ad esso. In pratica, lentit 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 dellhardware 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 dallarea 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. Linquisitore 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 lunico 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 uninquiry 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 linquisitore 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 linquiry, risponde dopo un time slot con il
pacchetto FHS (Frequency Hopping Synchronisation). In questo modo, molti
dispositivi possono rispondere allinquiry, ma le loro risposte non si accavallano.
Chiaramente linquisitore 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)).
Linquisitore trasmette usando la sequenza di hopping di inquiry, e ascolta in entrambe
le met dello slot ad una data frequenza. Una volta che linquiry 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, linquiry 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 linquisitore sullo stesso canale dello scanner, quando questo
invia lFHS il dispositivo che ha compiuto linquiry pronto a ricevere. Linquiry
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 linquisitore riceve lFHS 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 unaltra
frequenza. Allo stesso modo, se lFHS arriva nella seconda met dello slot, linquisitore
dovr perdere la trasmissione del primo ID del prossimo slot (Figura 36).

Figura 36: Salto di frequenza durante l'inquiry response

88

BLUETOOTH

Linquisitore 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 linquisitore saltasse una volta per slot. Questo possibile perch il
pacchetto ID corto. Se linquiry 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 dallhost.
E possibile evitare linquiry interamente se noto lindirizzo 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?. Loperazione 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 loperazione 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 lintervallo 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 lFHS; 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
nellFHS 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
linterfaccia PCM, attraverso lHCI, processati dallaudio CODEC, mentre in caso di
traffico ACL via lHCI. 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

8128 bit

RAND

128 bit

Tabella 4: Entit utilizzata nell'autenticazione e nella criptazione

Le chiavi di sicurezza sono derivate durante linizializzazione e non sono mai svelate.
Normalemente, la chiave di criptazione derivata dalla chiave di autenticazione
durante il processo di autenticazione. Per quanto riguarda lalgoritmo di autenticazione,
la dimensione della chiave sempre di 128 bit. Nellalgoritmo 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 lalgoritmo di criptaggio e
lhardware. Laumento della chiave, infatti, il metodo pi facile per aumentare la
sicurezza.
Lentit RAND un numero casuale che viene generato allinterno dellunit
Bluetooth. Questo parametro non statico e cambia velocemente.

96

BLUETOOTH

Link Manager
Un dispositivo Bluetooth viene guidato dallhost 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 lLMP

(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 nellheader 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 dallutilizzatore;

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 unoperazione di page-scan e lo slave fa unoperazione di page, ma in questo
intervallo non si possono trasferire dati. Per evitare questa perdita di tempo, lLMP
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 dellaltro 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, lRSSI (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. Lintervallo 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 limplementazione 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, lRSSI, 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,
lautenticazione o il criptaggio dei dati.

104

BLUETOOTH

Host Controller Interface (HCI)

Questo livello mette a disposizione dei livelli superiori uninterfaccia 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
uninterfaccia 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
dallinterfaccia HCI in comandi comprensibili dal Link Manager e dal livello
Baseband. Il driver HCI presente sullhost 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;

Lhost pu essere in sleep ed essere invocato dallinizio di una connessione;

LHCI 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 lintero stack su un processore host? Questo potrebbe essere fatto,
ma la temporizzazione degli slot Bluetooth implica che lhost dovrebbe essere in grado
di rispondere in tempi dellordine 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 dellHCI 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 dallhost per controllare il modulo;

pacchetti di evento usati dal modulo per informare lhost 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 dallhost 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. LOpCode 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. LOGF occupa i 6 bit pi alti, mentre lOCF occupa i
10 bit pi bassi dellOpCode. In Figura 54 riportato lesempio 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. Uneccezione 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 dellesecuzione delloperazione.

Se un comando non pu essere completato subito, si torna un HCI_Commad_Status,
fino a che loperazione termina e viene restituito lHCI_Command_Complete. Un
esempio il comando HCI_Inquiry, che inizia un inquiry. Il risultato dellinquiry non
pu essere tornato fino a quando linquiry non finita, e questo prender del tempo,
cos

lHCI_Command_Status

sar

restituito

immediatamente

per

dire

che

lHCI_Inquiry stato ricevuto. Pi tardi, un HCI_Inquiry_Complete verr ritornato.

Pacchetti dati HCI

Questo tipo di pacchetti sono utilizzati per scambiare dati attraverso lHCI, 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 linizio 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 nellordine dal byte pi significativo a quello meno
significativo. Nellesempio, 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

Levent code identifica levento. 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 dallhost 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 dellerrore.

Livello di trasporto UART

Questo livello di trasporto permette di collegare lhost con lhost controller attraverso
uninterfaccia seriale. Un esempio pu essere il collegamento tra lUART di un modulo
Bluetooth e lUART di un microprocessore, oppure con luscita 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.
Sullinterfaccia 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 luscita del modulo CTS = 0 possibile mandare dati al modulo,
mentre impostando lingresso 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 lUART del modulo sono riportati in tab. 6:

113

BLUETOOTH

Velocit di trasmissione

57600 bps (Ericsson)

Numero di bit

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 linizializzazione , lhost 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 lhost controller
usa levento Number_of_Completed_Packet per indicare allhost la dimensione dei dati
trasmessi e quindi della quantit di spazio che stata liberata nel buffer. Grazie a tali
informazioni lhost 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 lhost 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 lhost comunica allhost 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 lhost ha finito di processare il
pacchetto dati precedente.
Per quanto riguarda i comandi HCI, se il comando inviato dallhost 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 allhost 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 lhost 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 dellhardware

Bluetooth. I parametri influenzano il controllo dei dispositivi Bluetooth e le capacit
dellhost controller, del Link Manager e del livello Baseband. Lhost 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 costruttricedellhardware Bluetooth, e forniscono

informazioni circa lapparecchio Bluetooth e le capacit dellhost controller, del Link
Manager e del Baseband. Lhost 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

Lhost controller modifica tutti i suoi parametri di stato. Questi parametri forniscono
informazioni circa lo stato attuale dellhost controller, del Link Manager e del
Baseband. Lhost 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 sullhardware 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 loperazione di inquiry per
scoprire altri dispositivi Bluetooth nelle vicinanze; tutti gli aspetti del processo di
inquiry sono controllabili attraverso lHCI.
Avvio di un inquiry

Il comando HCI_inquiry viene usato per iniziare il processo di inquiry. Ha tre

parametri:
-

Inquiry LAP laccess code utilizzato;

Inquiry length la lunghezza temporale dellinquiry (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 allinquiry

Le risposte allinquiry vengono riportate nellevento 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
allinquiry.

In Figura 66 mostrato un esempio di risposta allinquiry.

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 linquiry 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 lintervallo in cui si ripete linquiry 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
lHCI possibile configurare alcuni parametri di questa procedura.
Temporizzazione dellInquiry 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 luna 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 dellInquiry 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: lindirizzo 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 unoperazione di page, cio stato
chiamato, spedendo un evento HCI_connection_Request (Figura 69b); lhost
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 lhost non d risposta, la richiesta di
connessione

cade

come

se

lhost

avesse

inviato

un

messaggio

HCI_Reject_Connection_Request.
Se lhost accetta la connessione, dopo uno scambio di messaggi a livello Baseband e
LM per linstaurazione 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,

levento

Connection_Complete che viene ritornato allhost contiene un campo di due byte

chiamato connection_handle (Figura 71). Quando lhost 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 dallhost 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
levento 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 lastrazione 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 luso 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 allinizializzazione 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

linizio 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
lastrazione 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. Limplementazione L2CAP deve essere in grado di

determinare lindirizzo 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
sulliniziatore (il dispositivo che inoltra la richiesta) e laccettore (il dispositivo che
risponde alla richiesta). Quando il protocollo comunica allinterfaccia L2CA
dellaccettore la richiesta, questa manda unindicazione (L2CA_Indication) ai livelli
superiori, che risponderanno con una risposta L2CA_Response. Allinterfaccia L2CA
delliniziatore 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 allaltro 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 lOpcode 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 allecho

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.
Lapplicazione 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

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 allHCI 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

LHCI invia al livello L2CAP levento 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.

LHCI inoltra ai livelli inferiori la risposta positiva dellhost 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 levento 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 dellaltro 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 lha 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 loperazione di configurazione stata

eseguita con successo.

RFCOMM
Il protocollo RFCOMM posizionato sopra il livello L2CAP e mette a disposizione
unemulazione 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.
Allinterno 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 allinterno delle informazioni presenti nel server e decidere se la
comunicazione tra i due dispositivi pu continuare perch stata trovata lapplicazione
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 uninterfaccia con luomo 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 laccess point.
Un profilo molto interessante per il futuro il BNEP (Bluetooth Network
Encapsulation Protocol), e un diagramma dellimplementazione 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 laggiunta di unintestazione BNEP (15 byte), unintestazione
L2CAP (4 byte) e altre intestazioni opzionali. Un pacchetto di 1691 byte corrisponde a
5 pacchetti DH5 (5*339), meno i 4 byte dellheader L2CAP.

142