Bluetooth | NEXT chapters | ||||||
Bluetooth è una tecnologia di trasmissione dati che non ha bisogno di cavi, poichè trasmette inviando onde radio. Grazie a Bluetooth, è possibile trasmettere e ricevere dati tra dispositivi quali un computer, una coppia di cuffie audio, un computer portatile, un cellulare, un tablet, una stampante, un mouse e tutti gli altri dispositivi che contengano un Controller Bluetooth. Alcuni cellulari, per esempio, richiedono l'installazione di complicati software proprietari, per permettere all'utente di trasferire dati, immagini o video, dal cellulare al computer di casa. Ebbene, anche in questo caso, è sufficiente avvicinare il proprio cellulare al computer, attivare Bluetooth ed iniziare la trasmissione. Il solo requisito richiesto è che entrambi i dispositivi abbiano installato un Controller Bluetooth. I cellulari, ormai, ne sono dotati già al momento dell'acquisto, mentre per i computer, se non ne sono dotati, sarà sufficiente acquistarne uno ( adattatore Bluetooth ) con attacco USB, in vendita a pochissimi euro. Un adattatore Bluetooth richiede, ovviamente, anche l'installazione di un software che permetta all'utrente di dialogare con l'adattatore Bluetooth appena installato. Per il sistema operativo Linux, questo software si chiama:
Il package
per configurare l'adattatore Bluetooth. L'adattatore Bluetooth è la chiavetta USB che viene solitamente collegata al computer locale. Spesso, lo si trova già preinstallato nel sistema. Un adattatore Bluetooth permette di scambiare facilmente dati ( immagini, video, testi, applicazioni ) tra il proprio computer e qualsiasi altro dispositivo Bluetooth ( computer, cellulare, tablet, macchina fotografica, etc. ), senza bisogno di software aggiuntivo.
per configurare le connessioni Bluetooth con altri dispositivi Bluetooth che si trovino nel raggio di azione dell'adattatore.
per inviare query SDP alle altre periferiche Bluetooth.
per intercettare il traffico dati in partenza e in arrivo da un dispositivo Bluetooth. Il package Bluez, inoltre, dispone di una serie di comandi che permettono di testare o di utilizzare i protocolli Bluetooth:
oppure di aggiungere una porta seriale allo stack Bluetooth:
Bluetooth è uno standard, finalizzato alla trasmissione di dati, che utilizza frequenze radio su piccole distanze: fino a 1 metro, per le periferiche di classe 3 ( 1 mW, o milliwatt, oppure 0.001 Watt, di potenza ), fino a 10 metri, per le periferiche di classe 2 ( 2.5 mW, o milliwatt, di potenza ), fino a 100 metri, per le periferiche di classe 1 ( 100 mW, o milliwatt, di potenza ). Una periferica Bluetooth, quindi, è dotata di un trasmettitore e di un ricevitore. Quando una periferica bluetooth entra nel raggio di azione di un'altra periferica bluetooth, si crea una rete locale, una Wireless Personal Area Network o WPAN, chiamata Piconet, che permette alle due periferiche di scambiarsi dati. Ciascuna periferica Bluetooth è identificata da un indirizzo univoco a 48-bit ( BD_ADDR ). Bluetooth opera all'interno della banda radio ISM ( Industrial Scientific Medicine ), a 2.4 GHz, una banda di trasmissione aperta a tutti, forni a microonde, telefoni cordless, telecomandi, quindi molto affollata e ad alto rischio di collisione o interferenza, che utilizza frequenze comprese tra i 2400 MHz ed i 2483.5 MHz ( all'interno della banda UHF: Ultra High Frequency ). Per limitare la possibilità di collisioni o interferenze, la soluzione ritenuta più affidabile è quella di spalmare la trasmissione su più frequenze ( spectrum-spreading technique ). Bluetooth suddivide la banda di frequenza in 79 canali, dove il canale n ( con n compreso tra 0 e 78 ) utilizza la frequenza 2402 + n MHz. Ciascun pacchetto di dati, quindi, viene trasmesso su una differente frequenza ( frequency-hopping spread spectrum ), secondo una precisa sequenza, generata, in modo casuale, a partire dall'indirizzo ( BD_ADDR ) di una delle periferiche coinvolte ( master ). In questo modo, una trasmissione Bluetooth rimane su una determinata frequenza per un breve periodo di tempo: nel caso di presenza di interferenze, quindi, il pacchetto di dati verrebbe immediatamente ritrasmesso su una differente frequenza, probabilmente libera da ulteriori interferenze. Un canale Bluetooth è rappresentato da una sequenza predeterminata di differenti frequenze ( sequenza di hopping ). Ciascun canale, a sua volta, è diviso in 1600 finestre temporali, per ogni secondo, con 625 µs ( microsecondi ) assegnati a ciascuna finestra. A ciascuna finestra temporale viene assegnata una determinata frequenza ( frequency-hop/time-division-duplex ( FH/TDD ) scheme ). Questo significa che il segnale radio, all'interno di un canale, compie 1600 salti di frequenza al secondo. Ciascun pacchetto di dati può utilizzare da 1 a 5 finestre temporali. Una piconet è composta da due o più dispositivi che occupano lo stesso canale fisico. I dispositivi appartenenti ad una piconet possono comunicare tra loro utilizzando lo stesso canale fisico dopo essersi sincronizzati ad un clock e ad una sequenza di hopping condivisi. Il clock condiviso è il clock di uno dei dispositivi inclusi nella piconet, dispositivo che assume il ruolo di master, mentre la sequenza di hopping viene calcolata a partire dal clock e dall'indirizzo fisico del master. Il clock è un contatore a 28 bit. Tutti gli altri dispositivi inclusi nella piconet assumono il ruolo di slave del master. Il clock svolge una funzione simile al controllo di flusso, determinando il momento in cui un pacchetto di dati può essere inviato e quando un dispositivo slave può mettersi in ascolto per intercettare le comunicazioni del dispositivo master. Ovviamente, ciascun dispositivo detiene un proprio clock indipendente. È necessario, quindi, che ciascun dispositivo slave si sincronizzi al clock del master. Questo è esattamente ciò che accade nel corso della procedura di inquiry, durante la quale il master invia allo slave il valore del proprio clock, mentre lo slave invia al master il valore dello scostamento del proprio clock rispetto al clock del master. I clock Bluetooth, infatti, non sono sincronizzati su un valore assoluto, bensì sulla differenza tra il valore del clock del dispositivo master ed il valore del clock del dispositivo slave: se il clock del master è a 100 e quello dello slave è a 91, lo scostamento trasmesso dallo slave in fase di inquiry sarà 9. In questo modo, il dispositivo slave, sapendo che il master invia i suoi pacchetti di dati negli slot temporali pari, per sapere in quale momento potrà mettersi in ascolto per intercettare i dati del master dovrà semplicemente aggiungere 9 al valore del suo proprio contatore. Attenzione: in realtà, il calcolo che lo slave deve effettuare è un pochino più complicato, poichè dovrà tenere conto di due altri effetti che possono impedire una corretta sincronizzazione tra i due clock:
Operare come dispositivo slave ( receiver ) può richiedere la stessa potenza richiesta da un dispositivo trasmittente, se non di più. Lo slave si metterà in ascolto in un determinato momento, calcolato nelle modalità appena esposte. Oltre a ciò, il dispositivo slave dovrà anche calcolare il tempo in cui potrà restare in ascolto. Maggiore sarà l'intervallo di tempo di attesa, maggiore sarà il consumo elettrico. Il lasso di tempo dedicato all'ascolto dovrà essere sufficientemente lungo per garantire che qualsiasi messaggio inviato dal master potrà essere captato, ma non potrà essere indefinito. Il periodo dedicato all'ascolto viene chiamato uncertainty window ed abbraccia il momento teorico in cui dovrebbe partire la trasmissione, se i clock dei due dispositivi ( master e slave ) fossero perfettamente sincronizzati, con jitter e drift pari a zero. I protocolli Bluetooth sono organizzati su un clock di sistema con una frequenza di 3,2 KHz, che coincide con un intervallo temporale di 312,5 μs, intervallo temporale utilizzato solo per i processi di inquiry e di paging, mentre, nel caso di due dispositivi connessi, l'intervallo temporale di base è di 625 µs, pari a due periodi di clock ( Bluetooth Sniff and Sniff Sub-rating Modes, 2001–2008 Bluetooth® SIG, Inc. ). In una stessa area, potrebbero coesistere due o più piconet, indipendenti l'una dall'altra. Ciascuna piconet avrebbe, comunque, un suo canale fisico, vale a dire, un suo dispositivo master, un suo clock ed una sua sequenza di hopping. Un dispositivo Bluetooth può appartenere a più piconet, anche simultaneamente, ma non potrà mai svolgere il ruolo di master in più di una piconet, proprio perchè una piconet viene definita dal clock del dispositivo master. Un dispositivo Bluetooth, naturalmente, può apparetenere a più piconet, in qualità di slave. In questo caso, metterebbe in collegamento due o più differenti piconet, creando una scatternet ( una rete di piconet ). Qualsiasi periferica, all'interno di una piconet, può diventare master, ma è proprio la periferica che crea la rete piconet, attraverso i meccanismi di " inquiry " e di " paging ", che, normalmente, assume il ruolo di master. La periferica master può iniziare a trasmettere solo in una finestra temporale pari. Una periferica slave, al contrario, può iniziare a trasmettere solo in una finestra temporale dispari e solo in seguito ad un messaggio ricevuto dalla periferica master e specificatamente indirizzato a lei. Un dispositivo Bluetooth, quindi, è un dispositivo ricetrasmittente, in grado di ricevere o inviare una sequenza di impulsi di energia elettromagnetica ( onde radio ), che potrà, eventualmente, essere intercettata da altre periferiche Bluetooth. La norma 802.11 definisce gli strati inferiori del modello OSI ( Open Systems Interconnection ) per una connessione senza fili che utilizza delle onde elettromagnetiche. Gli strati inferiori del modello OSI, definiti dalla norma 802.11, sono:
Nella tecnologia Bluetooth, il livello più basso del protocol stack, il livello fisico, quello che definisce la trasmissione fisica delle onde radio ( Bluetooth Core Specification Version 4.2 ), è il:
Al livello immediatamente superiore, troviamo le specifiche relative alla banda base, quindi all'organizzazione fisica e logica della trasmisssione dei dati da inviare attraverso il canale fisico descritto al livello inferiore, il Radio Layer ( Bluetooth Core Specification Version 4.2 ):
Il Bluetooth Baseband/Link Controller è quella parte di un sistema Bluetooth che specifica o implementa l'accesso al mezzo di trasmissione e le procedure da eseguire a livello fisico affinchè due o più periferiche Bluetooth possano scambiarsi dati o instaurare un collegamento di rete ad hoc. Il Baseband/Link Controller è responsabile della codifica e della decodifica dei pacchetti di dati Bluetooth, codifica realizzata a partire dai dati originali da trasportare ( PAYLOAD ) e dai parametri relativi al canale fisico, al trasporto logico e al collegamento logico. Il Link Controller, per esempio, trasporta i segnali del Link Control Protocol ( LCP ), usato nelle periferiche Bluetooth di tipo BR/EDR, e del Link Layer ( LL ) Protocol, usato nelle periferiche Bluetooth LE, segnali utilizzati per gestire il controllo di flusso e i segnali di acknowledgement e di richiesta di ritrasmissione dei pacchetti di dati ( Bluetooth Core Specification Version 4.2 ). Il livello Baseband / Link Control, quindi, permette la connessione fisica ( RF: Radio Frequency ) tra due dispositivi Bluetooth. In un sistema che utilizza la tecnica dello Frequency-Hopping-Spread-Spectrum, nella quale i pacchetti di dati vengono inviati in finestre temporali definite, su frequenze anch'esse predefinite, è necessario attivare un qualche meccanismo di sincronizzazione tra i due dispositivi da connettere. Il livello Baseband / Link Control utilizza i due meccanismi chiamati:
La procedura di Inquiry viene utilizzata per scovare altri dispositivi Bluetooth nelle vicinanze, mentre la procedura di Paging viene utilizzata per connettere due dispositivi Bluetooth che si trovino nella stessa piconet. Una procedura di Paging, quindi, può essere eseguita esclusivamente su un dispositivo Bluetooth già identificato attraverso una precedente procedura di Inquiry. Nella fase di inquiry, il master sollecita una risposta da ciascuno dei dispositivi Bluetooth presenti nel suo raggio di azione, mentre il dispositivo Bluetooth che desidera entrare nella piconet, in qualità di slave, risponde alla sollecitazione del master. Nel corso della procedura di inquiry, master e slave si scambiano i rispettivi indirizzi MAC e il valore dei rispettivi clock ( CLK ). Con l'indirizzo MAC ed il valore del clock del master, le periferiche slave sono in grado di sincronizzare il proprio clock al clock del master, calcolando così la corretta sequenza di hopping da utilizzare nella piconet. Il master, in realtà, invia anche un codice identificativo per ciascuna periferica slave, un codice composto da 3 bit che, quindi, limita il numero di possibili slave a sette. Un dispositivo Bluetooth, per scoprire altri dispositivi Bluetooth nelle vicinanze, invia richieste di inquiry, passando dallo stato di STANDBY ( lo stato di default di un dispositivo Bluetooth, a basso consumo energetico ) al sottostato inquiry. Un dispositivo Bluetooth può trovarsi in due stati:
e in nove sottostati:
Un dispositivo in stato di STANDBY non è parte di alcuna piconet. Il dispositivo Bluetooth che esegue la procedura di inquiry, che assumerà il ruolo di master nella futura piconet, non sa nè se esistano altre periferiche nelle vicinanze, nè il canale di frequenze sul quale le eventuali altre periferiche Bluetooth potrebbero essere in ascolto. Per poter inviare un pacchetto di inquiry è necessario, prima, definire una sequenza di frequenze su cui inviare i dati, la cosiddetta inquiry hopping sequence. In un sistema composto da 79 frequenze, la inquiry hopping sequence contiene 32 frequenze distinte. Da queste 32 frequenze, vengono generati due blocchi di 16 frequenze ciascuno ( train ). Assumendo che un pacchetto di dati di inquiry ( ID ) venga trasmesso due volte in ciascuno slot temporale di trasmissione ( Tx ), con 8 slot temporali di trasmissione potremmo esaurire un intero blocco di 16 frequenze. Poichè gli slot temporali di trasmissione ( Tx ) e d ricezione ( Rx ) sono interlacciati, un intero blocco di 16 frequenze occuperà, in totale, 16 slot temporali, pari a 10 ms ( 16 x 625 µs ), poichè il dispositivo master invierà due pacchetti di dati inquiry su due frequenze differenti, all'interno di una regolare finestra di trasmissione di 625 µs ( microsecondi, dove un microsecondo è un milionesimo di secondo ), mentre, nella finestra temporale immediatamente successiva, resterà in ascolto sulle stesse due frequenze, in attesa di un'eventuale risposta da parte di una periferica esterna, che assumerà il ruolo di slave nella futura piconet, passata dallo stato STANDBY al sottostato di inquiry scan. Un blocco di 16 frequenze deve essere ripetuto almeno 256 volte, prima di passare al blocco di 16 frequenze alternativo. Inoltre, per evitare errori, il master deve ripetere almeno 4 blocchi di frequenze, portando a 10,24 secondi la durata del sottostato di inquiry ( 10 ms x 256 x 4 ). Quando la periferica master entra nel sottostato di inquiry, tutte le comunicazioni all'interno della piconet vengono sospese, così da permettere al master di inviare i suoi pacchetti di dati inquiry e alle periferiche slave di restare in ascolto. La periferica master invia i suoi pacchetti di dati su più frequenze, mentre le periferiche slave, chiamate inquiry scanner, monitorano quelle frequenze, utilizzando intervalli di tempo più lunghi, così da aumentare le possibilità di una corretta ricezione. Gli inquiry scanner, infatti, cambiano la frequenza di ascolto ogni 1,28 secondi. Solo 11,25 ms ( millisecondi, o millesimi di secondo ), di quei 1,28 secondi, vengono utilizzati realmente per la scansione. Una volta ricevuto un pacchetto di inquiry dal master, la periferica slave invia, nello slot temporale successivo, cioè 625 µs dopo, un pacchetto di dati FHS ( Frequency Hopping Synchronization ) ed entra in un periodo di backoff, che dura da zero a 1024 finestre temporali ( fino a 640 ms ). Il pacchetto di dati FHS, inviato da uno slave al master, in risposta al pacchetto di inquiry, contiene l'indirizzo MAC della periferica slave, lo scostamento ( offset ) del clock della periferica slave ed un codice CRC ( Cyclic Redundancy Check, un codice usato per verificare l'integratità dei dati ricevuti ). Una volta ricevuto l'indirizzo ed il valore di clock del dispositivo Bluetooth slave, il master potrà instaurare con esso una connessione, attraverso la procedura di paging, che comporta il passaggio della periferica master al sottostato di page e della periferica slave al sottostato di pages scan. I due principali tipi di connessione utilizzati da Bluetooth sono:
È il Link Manager Protocol, utilizzato dal livello immediatamente superiore:
che decide quando il livello Baseband può eseguire il protocollo inquiry, chiedendogli di passare al sottostato inquiry, così da acquisire le informazioni sul dispositivo Bluetooth che si trova all'altro capo del collegamento, quali il suo nome o i valori del suo clock. A questo punto, il Baseband attiva un contatore, il cosiddetto inquiryTimeOut ( inquiryTO ). Il Baseband tornerà allo stato originale, STANDBY o CONNECTION, o su richiesta dello stesso LMP ( Link Manager Protocol ), oppure all'azzeramento del contatore inquiryTO. È sempre il Link Manager Protocol che si occupa, nella gestione di un collegamento Baseband tra due dispositivi Bluetooth, delle operazioni di setup, autenticazione, configurazione della connessione, pairing, cifratura dei dati ed altro ( Bluetooth Core Specification Version 4.2 ). Il Link Manager Protocol si occupa anche di modificare il ruolo svolto da un dispositivo Bluetooth, master o slave, oppure di controllare la potenza di trasmissione oppure di impostare alcune speciali modalità di stato del dispositivo, finalizzate al risparmio energetico:
Come abbiamo già visto, quando un dispositivo Bluetooth si trova nel sottostato di inquiry, due sono le transizioni che possono avvenire:
Le frequenze di trasmissione su cui avvengono questi scambi di dati sono determinate dalla inquiry hopping sequence, generata dal valore di clock nativo del dispositivo master ( CLKN ) e dal General Inquiry Access Code ( GIAC ), il cui valore è sempre 9E8B33 ( hex ). Nelle comunicazioni Bluetooth, " ogni pacchetto di dati inizia con un Access Code. Se lo Access Code è seguto da un header, avrà una lunghezza di 72 bit, altrimenti la sua lunghezza sarà di 68 bit ( shortened access code ). Lo Access Code viene usato come strumento di sincronizzazione, come strumento di compensazioni degli scostamenti DC ( DC offset ), come strumento di identificazione. Lo Access Code identifica i pacchetti di dati scambiati su un canale fisico: tutti i pacchetti di dati inviati in uno stesso canale fisico sono preceduti dallo stesso Access Code. Lo Access Code breve ( shortened access code ) viene usato nei processi di inquiry, paging e park, dove non vengono inviati nè header, nè payload. Un Access Code è composto da un preambolo di 4 bit, da una SYNC WORD ( parola di sincronizzazione ) di 64 bit e da una coda ( TRAILER ) di 4 bit. Quando manca la coda finale, lo Access Code si compone di soli 68 bit. Bluetooth definisce 3 diversi tipi di Access Code:
Il Device Access Code ( DAC ) viene utilizzato nei sottostati page, page scan, page response e viene costruito a partire dall'indirizzo MAC ( BD_ADDR ) del dispositivo Bluetooth sul quale viene eseguito il paging. Il Channel Access Code ( CAC ) viene usato nello stato CONNECTION e nei sottostati synchronization train e synchronization scan e viene costruito a partire dall'indirizzo MAC ( BD_ADDR ) del dispositivo Bluetooth Master. Il Channel Access Code ( CAC ) viene posto all'inizio di tutti i pacchetti di dati scambiati sul canale fisico di una piconet. Infine, lo Inquiry Access Code ( IAC ) viene utilizzato nel sottostato inquiry. C'è un General IAC per le operazioni di inquiry generiche e ci sono 63 IAC dedicate ( Dedicated IAC ), per le operazioni di inquiry dedicate ( per esempio, operazioni di inquiry eseguite su un gruppo dedicato di dispositivi Bluetooth che condividono una determinata caratteristica ). Tutti gli Access Code vengono derivati dalla sezione di un indirizzo MAC ( BD_ADDR ) chiamata LAP ( Lower Address Part ). Ad ogni dispositivo Bluetooth viene assegnato, dalla IEEE ( Institute of Electrical and Electronics Engineers ) Registration Authority, un indirizzo ( BD_ADDR ) composto da 48 bit, suddiviso in tre campi, a partire dal Least Significant Bit ( LSB ):
Mentre UAP e NAP vengono assegnati direttamente dall'IEEE e contengono l'identificativo universale dell'azienda produttrice ( Organizationally Unique Identifier: OUI ), la LAP rappresenta l'identificativo del singolo dispositivo Bluetooth e viene assegnata direttamente dal produttore. Quindi, il seguente indirizzo BD_ADDR:
identifica il prodotto ID 45:8F:35 dell'azienda 00:09:DD ( Mavin Technology Inc., TAIWAN, PROVINCE OF CHINA ). Visto che, in fase di inquiry, il BD_ADDR del dispositivo remoto non è ancora noto, è necessario utilizzare un valore di LAP temporaneo, che, per una richiesta di inquiry generica è sempre:
definito General Inquiry Access Code ( GIAC ), mentre per una richiesta di inquiry dedicata rientra nell'intervallo di valori compresi tra:
definiti Dedicated Inquiry Access Code ( DIAC ). " ( Bluetooth Core Specification Version 4.2 ). I livelli visti fino a qui, Radio, Baseband, Link Manager, costituiscono il cosiddetto modulo, o Controller, Bluetooth, cioè l'hardware e l'insieme delle funzioni e delle operazioni Bluetooth, mentre tutto ciò che appartiene ai livelli superiori viene definito, nel suo insieme, Host. "Il sistema Bluetooth è composto da un Host e da uno o più Controller. Un Host è un'entità logica definita come l'insieme dei livelli posti subito sotto ai profili non-core e sopra alla Host Controller Interface ( HCI )" ( Bluetooth Core Specification Version 4.2 ). Se è vero che in un modello Hosted, i livelli più bassi dello stack Bluetooth risiedono nel Controller Bluetooth, mentre i livelli più alti risiedono in un Host ( un Computer o un micro controller, se si tratta di un dispositivo mobile ), in un modello Embedded, l'intero stack Bluetooth ( compresi i livelli alti ) risiede nel Controller Bluetooth, mentre l'Host esegue un'applicazione utente. Esistono anche sistemi fully embedded ( come le cuffie audio ), in cui stack ed applicazione risiedono nel Controller Bluetooth. La:
è l'interfaccia che permette ai protocolli di livello superiore di comunicare direttamente con il Controller Bluetooth. Lo HCI Firmware implementa i comandi HCI per l'hardware Bluetooth, permettendo l'accesso ai comandi della Baseband, ai comandi del Link manager, ai registri dell'hardware: di stato, di controllo e degli eventi. Grazie agli eventi, l'interfaccia HCI è in grado di informare l'Host Bluetooth che qualcosa è avvenuto. Per esempio, nel gruppo degl eventi generici, ( Generic Events ) troviamo il:
usato dal Controller per restituire lo stato di un comando e di altri parametri ad esso associati, oppure il:
usato dal Controller per informare l'Host che un determinato comando ( descritto dal parametro Command_Opcode ) è stato ricevuto ed è in esecuzione. Se il comando non potesse essere eseguito, questo evento trasporterebbe il codice di errore corrispondente, mentre il Command Complete Event non verrebbe inviato, visto che il comando non verrebbe eseguito. Infine, l'evento:
viene utilizzato per indicare un problema hardware occorso nel Controller. Quando l'Host riceve una notifica di avvenuto evento, sa di dover cercare il tipo di evento occorso nel pacchetto di dati successivo. I comandi HCI sono composti da 16 bit, di cui i 6 bit più significativi indicano il cosiddetto Op-code Group Field ( OGF ), o Gruppo di appartenenza del comando:
I comandi HCI al Link manager permettono all'Host di controllare le connessioni con altri dispositivi Bluetooth, inviando comandi LMP ( Link Manager Protocol ), attraverso il Link Manager (LM), ai dispositivi Bluetooth remoti. I comandi HCI Policy vengono utilizzati per intervenire sul comportamento dei Link Manager locale e remoto, permettendo all'Host di influenzare le modalità in cui il Link Manager ( LM ) gestisce la piconet. I comandi HCI alla Baseband, i comandi di Stato, i comandi di Informazione permettono all'Host l'accesso ai vari registri del Controller Bluetooth locale. I 10 bit meno significativi di un comando HCI indicano il comando vero e proprio, o Op-Code: Op-code Command Field ( OCF ). Quindi, se lo Op-code Command Field ( OCF ) del comando inquiry, appartenente al gruppo di comandi per il Link Control, Op-code Group Field ( OGF ) 0x01, è:
il reale Op-Code del comando inquiry sarà composto dall'insieme dei 6 bit dello Op-code Group Field ( OGF ) e dei 10 bit dello Op-code Command Field ( OCF ):
pari al valore esadecimale:
Per conoscere i comandi e gli eventi HCI disponibili, vedere il documento ufficiale Bluetooth:
oppure le pagine riassuntive contenute nei siti seguenti:
Il chipset Bluetooth contiene i livelli bassi dello stack Bluetooth e la HCI. Per agire sul dispositivo locale ( il dispositivo installato sul proprio computer ), il package Linux Bluez mette a disposizione il comando:
mentre, per agire sui dispositivi remoti, il package Bluez mette a disposizione il comando:
I livelli superiori del Protocol Stack di Bluetooth hanno a che fare con il multiplexing ( o multiplazione, un processo che permette di inviare più flussi di dati, digitali o analogici, in un unico segnale, permettendo, così, di inviare più messaggi distinti in un unico canale condiviso di trasmissione ) del protocollo L2CAP ( Logical Link Control and Adaptation Protocol ), con RFCOMM ( Radio Frequency Communication ), con SDP ( Service Discovery Protocol ). Il compito del protocollo:
è di eseguire il multiplexing dei dati in arrivo dagli strati superiori per instradarli in un'unica connessione ACL ( Asynchronous ConnectionLess ). A livello locale, ad ogni canale logico L2CAP viene assegnato un identificativo ( CID ), che non necessariamente corrisponde all'identificativo assegnato allo stesso canale dal dispositivo Bluetooth remoto. Un canale logico L2CAP non è da confondere con il canale fisico di trasmissione, o Baseband, utilizzato per il Frequency Hopping. Un canale logico L2CAP è un canale che unisce due strati L2CAP residenti su due dispositivi Bluetooth differenti. Un canale L2CAP può trasportare i dati di più protocolli appartenenti agli strati superiori dello stack e a ciascun protocollo viene assegnato un identificativo ( PSM, Protocol Specific Multiplexer ), così da permettere a L2CAP di trasmettere in un flusso simultaneo i dati di protocolli differenti:
L2CAP gestisce solo il traffico dati, non la voce. I pacchetti voce, infatti, vengono immediatamente reinstradati verso il livello Baseband, senza passare da L2CAP. L2CAP opera direttamente sui pacchetti di dati ed è responsabile della segmentazione e del riassemblaggio dei dati, occupandosi di creare pacchetti che siano conformi al payload dell'interfaccia HCI ( i pacchetti creati dai livelli superiori dello stack devono essere ridimensionati per poter attraversare l'apparato fisico ). Questo permette agli strati superiori dello stack di operare utilizzando formati di dati e protocolli più naturali, senza preoccuparsi della futura trasmissione fisica. Il protocollo:
o Radio Frequency Communication, è un protocollo che emula le comunicazioni su porte seriali ( COM ) di un computer, in modo da facilitare la migrazione delle applicazioni esistenti che si aspettano una porta seriale ed un cavo al nuovo collegamento senza fili di Bluetooth. RFCOMM, come TCP, è un protocollo orientato alla connessione. " Il protocollo RFCOMM offre più o meno lo stesso servizio e la stessa affidabilità offerta, in internet, dal protocollo TCP ( Transfer Control Protocol ) ... La differenza maggiore, tra TCP e RFCOMM, almeno dal punto di vista del programmatore, risiede nella scelta del numero di porta da utilizzare. TCP, infatti, supporta ben 65535 porte, su una singola macchina, mentre RFCOMM ne supporta solo 30 " ( Albert Huang, An Introduction to Bluetooth Programming ). Un protocollo orientato alla connessione è un protocollo che richiede una connessione, fisica o logica, tra i due terminali tra i quali avverrà lo scambio di dati. Tale connessione viene instaurata prima dell'invio di qualsiasi dato. Con TCP, ciascuno dei due terminali deve, all'inizio della sessione di comunicazione, inviare all'altro un numero sequenziale iniziale ( Initial Sequence Number o ISN ), che verrà incrementato di 1 ad ogni invio di un nuovo pacchetto di dati, così da impedire che un pacchetto venga perso, senza che il terminale ricevente ne abbia contezza. Il protocollo L2CAP ( Logical Link Control and Adaptation Protocol ) può anche operare come protocollo senza connessione ( connectionless ), senza, quindi, garantire nè l'effettiva ricezione, da parte del destinatario, di tutti i pacchetti inviati, nè la loro ricezione nell'ordine sequenziale di invio, ma questa modalità di comunicazione viene utilizzata in rarissimi casi. Come nei protocolli TCP e RFCOMM, nel protocollo L2CAP è previsto un meccanismo di invio dei dati, con conferma di ricezione da parte del destinatario ( acknowledgement ), con la differenza che i pacchetti di dati non giunti a destinazione ( dei quali non è stata inviata la conferma di ricezione, da parte del destinatario ) possono essere ritrasmessi, almeno fino a quando l'intera connessione non fallisca o il pacchetto di dati raggiunga la sua destinazione, oppure possono essere ritrasmessi per un determinato periodo di tempo, per poi essere scaricati, in caso di fallimento, oppure possono non essere mai ritrasmessi e lasciati immediatamente cadere. Quest'ultimo caso prefigurerebbe una connessione fondata sul miglior sforzo ( best-effort ), una tipologia di connessione molto vicina a quella instaurata dal protocollo UDP ( User Datagram Protocol ), della suite internet TCP/IP, una tipologia di connessione in cui si privilegia la velocità di trasmissione ( invio il pacchetto di dati, mettendocela tutta affinchè possa arrivare a destinazione, ma non mi preoccupo di sapere se l'invio è stato coronato dal successo ), rispetto alla sua affidabilità ( prerogativa di TCP ). Il Service Discovery Protocol, o:
è il protocollo di service discovery di Bluetooth, in cui ciascun dispositivo può agire sia da client, sia da server. I cosiddetti protocolli di service discovery ( quali: il Service Location Protocol, o SLP, lo Univeral Plug and Play, o UPnP, e lo Universal Description Discovery and Integration, o UDDI ) permettono di indicizzare i servizi disponibili per i diversi dispositivi, con la conseguente creazione, su un directory server, di un vero e proprio catalogo pubblico, consultabile direttamente da un qualsiasi computer client o da una qualsiasi applicazione. Un server SDP può rilasciare informazioni esclusivamente sui servizi supportati dal dispositivo sul quale è installato. Per interrogare un dispositivo Bluetooth sui servizi che è in grado di supportare, è disponibile il comando
viene utilizzato per le funzioni avanzate di telefonia, nei telefoni cellulari. Un altro protocollo degno di menzione è:
o OBject EXchange che permette lo scambio di file o di oggetti, via RFCOMM. I profili, in Bluetooth, rappresentano gli standard ai quali le applicazioni devono adeguarsi, affinchè sia garantita l'interoperabilità tra sistemi diversi. I profili Bluetooth definiscono le funzioni e le caratteristiche, proprie di ciascun livello ( layer ), a partire dal livello fisico ( PHY o Radio Layer ) fino a L2CAP ( "vertical slice", o taglio verticale ), che devono necessariamente essere presenti, affinchè siano garantite l'interazione verticale tra un livello e l'altro e l'interazione orizzontale tra uno stesso livello di due dispositivi differenti. In sintesi, un profilo Bluetooth definisce come eseguire un determinato compito, generico o specifico, utilizzando i protocolli esistenti. Nei protocolli, il Bluetooth SIG ( Special Interest Group ) definisce i differenti formati dei pacchetti di dati, i meccanismi di routing, il multiplexing, la codifica e la decodifica dei dati. I profili definiscono i protocolli da utilizzare per una determinata applicazione o per una specifica operazione. Il Profilo di base, il Profilo che qualsiasi dispositivo Bluetooth deve implementare, è il:
che definisce i requisiti minimi che un dispositivo Bluetooth deve soddisfare, i metodi da utilizzare per scoprire nuovi dispositivi Bluetooth ( inquiry ), per connettersi ad altri dispositivi Bluetooth, per autenticarsi, per garantire la sicurezza delle transazioni. Per esempio, per un Controller Bluetooth BR/EDR, il profilo GAP richiede le funzionalità Radio, Baseband, Link Manager, L2CAP e SDP, mentre per un Controller Bluetooth LE richiede il Physical Layer ( PHY ), il Link Layer ( LL, responsabile del framing dei dati, della generazione e della verifica del CRC, o Cyclic Redundancy Check, o controllo a ridondanza ciclica, della cifratura AES dei dati ), L2CAP, il Security Manager ( SM, una serie di algoritmi per la generazione e la gestione delle chiavi di cifratura ), lo Attribute Protocol ( ATT, la base per lo scambio di dati, per le applicazioni Bluetooth LE ) ed il Generic Attribute Profile ( GATT ). " Esistono due forme di tecnologie Bluetooth:
che può includere Enhanced Data Rate ( EDR ) Alternate Media Access Control ( MAC ) e Physical ( PHY ) layer extensions, e:
che comprende alcune funzionalità che offrono un minor consumo energetico, una minore complessità e minori costi, rispetto ad un sistema BR/EDR " ( Bluetooth Core Specification Version 4.2 ). Bluetooth Low Energy ( BLE, definito anche come Bluetooth Smart) fu introdotta nelle specifiche Bluetooth 4.0 ( 2010 ), con lo scopo dichiarato di creare uno standard radio che abbattesse i consumi al minimo, che richiedesse una limitata banda di trasmissione e che si caratterizzasse per una bassa complessità. La sua rapida diffusione è dovuta, fondamentalmente, alla rapida diffusione di smartphone e tablet. Le due tecnologie, BR/EDR ( il classico Bluetooth ) e BLE ( Bluetooth Low Energy ) non sono direttamente compatibili. Un dispositivo Bluetooth fondato sulle specifiche inferiori alla 4.0 non potrà, in alcun modo, comunicare con un dispositivo BLE. Un dispositivo BLE ( Bluetooth Low Energy ) può comunicare con un altro dispositivo BLE ( Bluetooth Low Energy ), ma non può comunicare con un dispositivo BR/EDR, a meno che non si tratti di un dispositivo Dual-mode ( BR/EDR/LE ), un dispositivo che supporta sia BR/EDR che BLE. Per conoscere quale standard Bluetooth supporta l'adattatore Bluetooth collegato al nostro sistema, eseguire il comando:
Per conoscere quale standard Bluetooth supporta un dispositivo Bluetooth esterno al sistema ( che non sia, quindi, l'adattatore stesso ), il cui indirizzo MAC è BD_ADDR, eseguire il comando:
Il sito ufficiale di Bluetooth, alla pagina Assigned Numbers in the Service Discovery Protocol (SDP), mantiene l'elenco delle specifiche, protocolli e profili, attualmente disponibili, a ciascuna delle quali è stato assegnato un numero identificativo ( UUID ), che, nominalmente, è composto da 128 bit, ma che può essere rappresentato da una forma contratta a 32 o a 16 bit. Attualmente, tutti gli UUID a forma contratta sono a 16 bit. Oltre al Generic Access Profile ( GAP ), l'altro profilo necessario a qualsiasi dispositivo Bluetooth è il:
che descrive come utilizzare il protocollo SDP per scovare i servizi disponibili sui dispositivi remoti. Non appena un dispositivo Bluetooth scopre ( inquiry ) un altro dispositivo Bluetooth nelle vicinanze e vi si connette, la prima operazione che deve eseguire è la ricerca dei servizi offerti dal dispositivo remoto appena trovato. Un servizio, per poter essere utilizzato, deve essere supportato da entrambi i dispositivi. Per conoscere i profili supportati dall'adattatore Bluetooth installato nel proprio computer, eseguire uno dei due comandi seguenti:
Per conoscere i profili supportati dal dispositivo Bluetooth remoto, al quale abbiamo connesso l'adattatore Bluetooth, eseguire uno dei due comandi seguenti:
dove MAC_address è l'indirizzo fisico del dispositivo remoto, ottenuto in fase di inquiry:
Un dispositivo Bluetooth, compreso l'adattatore installato nel nostro computer, può utilizzare un modem, collegato direttamente ad un dispositivo Bluetooth remoto, per connettersi ad una rete pubblica, semplicemente utilizzando il profilo:
In questo modo, sarà possibile connettersi alla rete Internet, dal nostro computer, utilizzando la connessione, per esempio, di un telefono cellulare. O viceversa. Il profilo:
probabilmente il più diffuso, permette ad un dispositivo Bluetooth, come un telefono cellulare o il proprio computer, di utilizzare una coppia remota di cuffie audio Bluetooth come microfono ed come altoparlante, o viceversa. Entrambi i profili appena visti, Dial-Up Networking Profile e Headset Profile, emulano una connessione su porta seriale, RS-232. La connessione su porta seriale è realizzata dal profilo:
dal quale, quindi, entrambi i profili precedenti dipendono. Un profilo dipende da un altro profilo quando ne utilizza, anche solo in parte, funzionalità e parametri. I profili visti fino a questo punto, sono tutti dipendenti dai profili precedenti:
Il protocollo per il trasferimento dei file ( OBEX, OBject EXchange ) è stato preso in prestito dalle specifiche della IrDA ( InfraRed Data Association ), l'associazione responsabile degli standard per le comunicazioni senza fili a raggi infrarossi. Normalmente, anche le comunicazioni a infrarossi avvengono su porta seriale ( RFCOMM ): grazie a questa e ad altre similitudini, il protocollo OBEX può essere utilizzato, senza grandi modifiche, anche in campo Bluetooth.
|
|||||||
Bluetooth | The .bit guides: original contents |