Le caratteristiche tecniche del Bluetooth e la sua semplicità di configurazione (affatto casuale) lo rendono particolarmente adatto per essere implementato su oggetti di uso quotidiano che non richiedono grandi competenze tecniche. L'utilizzo principale è "auricolare - cellulare", ma come ben sappiamo viene utilizzato per collegare un gran numero di oggetti, dai palmari alle stampanti, dalle fotocamere ai gamepad della Play Station (anche se la %newwin%[[gente per bene->http://images2.wikia.nocookie.net/__cb20090110041725/nonciclopedia/images/d/d4/Wii_gnocca.gif]] gioca con la Wii). Semplicità d'uso significa che il riconoscimento e il collegamento deve essere triviale, quasi automatico.

Concludiamo l'introduzione con le solite beghe di utilizzo del marchio. Chiunque voglia vendere il proprio dispositivo Bluetooth col suo bel logo sopra, deve registrarsi presso il SIG, compilare una serie di moduli che spieghino cos'è e cosa fa il suo prodotto, pagare circa 1000$ (cifra non monumentale) e ottenere il suo bell'identificativo univoco di 48 bit. Che ce ne facciamo? Tante cose che vedremo man mano. \\
Ovviamente nessuno può impedirmi di creare una radio Bluetooth e usarla su un mio dispositivo, ma se non la certifico non posso venderla.

Come già anticipato, il Bluetooth è stato progettato per reti WPAN, quindi con un corto raggio di azione, e per avere una buona autonomia (da 1 a 7 giorni). Le due cose sono strettamente collegate tra loro, dal momento che l'area di copertura dipende dalla potenza in uscita dell'antenna, e che all'aumentare di questa aumentano anche i consumi energetici. In base alla potenza dell'antenna possiamo distinguere tre classi di dispositivi: classe 1 (100mW -> copertura: 100m), classe 2 (2,5mW -> copertura: 10m), classe 3 (1mW -> copertura: meno di un metro).\\

Lo standard Bluetooth si è molto evoluto nel tempo, portando correzioni e migliorie nelle varie versioni di rilascio. Le principali innovazioni riguardano la sicurezza (nelle prime versioni ci voleva poco per fregare i dati altrui), la velocità di trasmissione (dal limite di 720 Kb/s ora si può arrivare a 3 Mb/s), migliorie nella comunicazione (maggiore qualità, minori consumi) ed altro ancora. Il 21 aprile 2010 il SIG ha completato la stesura delle specifiche per il core della versione 4.0, ma per il rilascio si parla di fine anno/inizio 2011 (http://www.bluetooth.com/English/PRESS/Pages/NewsDetail.aspx?ID=186).

Ogni chip Bluetooth ha associato un identificativo univoco sulla faccia della terra (grazie alla lungimirante e lucrosa gestione del SIG), che ogni potenziale master può usare come seme di un algoritmo per la generazione pseudocasuale di una sequenza di frequenze. Una piconet è quindi formata da slave in accordo col master sulla sequenza da lui comunicata, quindi anche se continuiamo a parlarci su frequenze diverse ci becchiamo sempre. Poiché in un secondo di trasmissione dati si hanno 1600 salti (diventano 3200 nelle fasi di inquiry e paging) va da sé che la sincronizzazione è fondamentale: se ci disaccoppiamo di 0.625 microsecondi (un ''time slot'') non ci becchiamo più.

I primi tre layer (Bluetooth Radio, Bluetooth Baseband, LMP) possono essere considerati come la parte firmware dello stack, perché associati al componente hardware che fa la trasmissione radio; sono chiamati anche ''controller''. Al di sopra di essi si collocano i protocolli software, nel loro insieme individuati come ''host'', poiché legati all'ambiente in cui la radio opera. In figura non si vede (potete vederlo %newwin%[[qui->http://cgi.cse.unsw.edu.au/~cs4411/wiki/images/a/a9/Bluetooth_stack.jpg]] ), ma tra queste due sezioni si colloca l' '''Host to Controller Inteface''' (HCI), che è opzionale e come il nome stesso suggerisce fa da interfaccia comune ad entrambi.

* ''traffico audio'', che è simmetrico (ho due canali, uno di ingresso e uno di uscita), sincrono e orientato alla connessione ('''SCO''', ''Synchronous Connection-Oriented'' link). Orientato alla connessione significa che apre un canale tra master e slave e lo tiene aperto per tutto il tempo della comunicazione; in questo caso è una scelta che ha senso dal momento che sta trattando un flusso audio continuo. Non c'è controllo dell'errore, quindi nessuna ritrasmissione dei pacchetti corrotti o non ricevuti (se capisci capisci, se no pazienza). Un master può supportare al massimo tre canali audio attivi contemporaneamente (per limiti di banda), su cui trasmette a 64 Kb/s per slot;

L'unità di misura della trasmissione dati Bluetooth è il pacchetto, che può estendersi per 1, 3 o 5 time slots consecutivi. Come è strutturato un pacchetto lo vedremo nella prossima lezione, per il momento ci basta sapere che è formato da un header con tutte le informazioni necessarie del caso e da un payload. Introduciamo alcune caratteristiche del processo di trasmissione a partire dall'immagine seguente:

* se il pacchetto da trasmettere è lungo più di un time slot, sarà trasmesso sempre alla stessa frequenza. La risposta però non avverrà sulla frequenza successiva a quella di trasmissione, ma a quella a cui si sarebbe dovuti arrivare normalmente se avessimo avuto tutti pacchetti da 1. Guardando l'immagine in alto si capisce meglio: in f'_2_' si trasmette un pacchetto di tre time slot, ma la frequenza di risposta usata non è f'_3_', bensì f'_5_' (f'_2+3_').

# la comunicazione può fallire in entrambe le direzioni di trasmissione: dal master allo slave (mancato ricevimento del pacchetto), dallo slave al master (mancato ricevimento dell'ACK)

In generale i dispositivi Bluetooth possono essere nei tre stati principali che abbiamo già visto, ovvero ''standby'', ''connected'' (o ''attivi'') e ''parked''. Esistono poi una serie di sottostati per cui bisogna passare per stabilire una connessione e abilitare i dispositivi alla fase di discovery. Il passaggio tra questi sottostati avviene attraverso comandi che partono dal link manager LMP o da segnali interni del link controller (ad esempio segnali di timeout).\\

La procedura di '''inquiry''' permette al potenziale master di fare la discovery dei dispositivi a portata di antenna, o viceversa al potenziale slave di essere rilevato. L'intera operazione avviene sullo strato fisico dello stack, con la formazione di una canale fisico temporaneo il cui frequency hopping è limitato a 32 sole frequenze (distribuite equamente sui 79 MHz totali) dette di ''wake-up''. Se un nodo in standby riceve un pacchetto di inquiry IAC su tali frequenze, si sente interrogato dall'ambiente e deve decidere se partecipare o meno alla piconet. Se sì, si passa allo procedura di '''paging''', in cui lo slave viene interrogato sui servizi (profili) di cui dispone e invitato a partecipare alla piconet instaurando una connessione grazie alle informazioni inviate dal master (la sequenza di hopping, la sincronizzazione col clock, il suo indirizzo nella piconet, ...). Il canale fisico messo a disposizione per la procedura di paging è specifico per la coppia di dispositivi che ne sono protagonisti, e se questa va a buon fine entrano finalmente in modalità '''connected'''.

Il '''pairing''' è un meccanismo che realizza il duplice obiettivo di controllare quali dispositivi possono connettersi al mio, e stabilire automaticamente delle connessioni con quelli considerati sicuri (''trusted'') quando diventano a portata di antenna. Ciò è implementato attraverso lo scambio di una chiave segreta condivisa (l'operazione è effettuata in genere direttamente dall'utente), che può essere ulteriormente raffinato introducendo diversi livelli di crittazione (ad esempio dell'identità dell'altro, dei certificati scambiati o dell'intero traffico). I motivi dietro questi raffinamenti, introdotti dalla versione 2.1 del Bluetooth, erano che con un semplice scambio chiavi in chiaro (generalmente di 4 cifre) si è particolarmente esposti ad attacchi brute-force, e il fatto che le piconet abbiano un'estensione ridotta non è una buon motivo per stare tranquilli dato che eventuali attaccanti potrebbero munirsi di antenne bibliche per intercettare gli scambi.\\

Il fatto di avere tanti profili ha dei pro e dei contro: se ne definisco pochissimi poi ci saranno problemi di compatibilità perché questa è demandata a livello applicativo (e nessuno si vuole prendere la briga di assicurarla), mentre se ne definisco troppi sono pesantemente vincolato in quello che posso fargli fare. E' la solita coperta troppo corta.

Concludiamo facendo notare che tra i tanti criteri in base ai quali scelgo i protocolli wireless da utilizzare per le mie soluzioni, non è affatto da trascurare la grandezza dei loro stack. Essa è infatti direttamente collegata alle risorse che richiede al sistema, non solo come peso sulla memoria, ma anche sulla capacità di elaborazione del microprocessore integrato. Ad esempio, i device su cui gira lo Zigbee non supporterebbero neanche per scherzo la trasmissione via TCP/IP (dove infilerebbero il suo monumentale stack nei miseri 32Kb a disposizione? Esatto, lì). Altro esempio, non posso pensare di mettere un processore a 32bit in un'auricolare per fargli fare autonomamente VoIP, a meno che non voglio attaccare un calcolatore all'orecchio degli utenti.

La procedura di '''inquiry''' permette al potenziale master di fare la discovery dei dispositivi a portata di antenna, o viceversa al potenziale slave di essere rilevato. L'intera operazione avviene sullo strato fisico dello stack, con la formazione di una canale fisico temporaneo il cui frequency hopping è limitato a 32 sole frequenze (distribuite equamente sui 79 MHz totali) dette di ''wake-up''. Se un nodo in standby riceve un pacchetto di inquiry IAC su tali frequenze, si sente interrogato dall'ambiente e deve decidere se partecipare o meno alla piconet. Se sì, si passa allo procedura di '''paging''', in cui lo slave viene interrogato sui servizi (protocolli) di cui dispone e invitato a partecipare alla piconet instaurando una connessione grazie alle informazioni inviate dal master (la sequenza di hopping, la sincronizzazione col clock, il suo indirizzo nella piconet, ...). Il canale fisico messo a disposizione per la procedura di paging è specifico per la coppia di dispositivi che ne sono protagonisti, e se questa va a buon fine entrano finalmente in modalità '''connected'''.

Concludiamo facendo notare che tra i tanti criteri in base ai quali scelgo i protocolli wireless da utilizzare per le mie soluzioni, non è affatto da trascurare la grandezza dei loro stack. Essa è infatti direttamente collegata alle risorse che richiede al sistema, non solo come peso sulla memoria, ma anche sulla capacità di elaborazione del microprocessore integrato. Ad esempio, lo Zigbee non supporterebbe neanche per scherzo la trasmissione via TCP/IP (dove infilerebbe il suo monumentale stack nei suoi miseri 32Kb a disposizione? Esatto, lì). Altro esempio, non posso pensare di mettere un processore a 32bit in un'auricolare per fargli fare autonomamente VoIP, a meno che non voglio attaccare un calcolatore all'orecchio degli utenti.

I primi tre layer (Bluetooth Radio, Bluetooth Baseband, LMP) possono essere considerati come la parte firmware dello stack, perché associati al componente hardware che fa la trasmissione radio; sono chiamati anche ''controller''. Al di sopra di essi si collocano i protocolli software, nel loro insieme individuati come ''host'', poiché legati all'ambiente in cui la radio opera. In figura non si vede (potete vederlo %newwin%[[qui->http://cgi.cse.unsw.edu.au/~cs4411/wiki/images/a/a9/Bluetooth_stack.jpg]], ma tra queste due sezioni si colloca l' '''Host to Controller Inteface''' (HCI), che è opzionale e come il nome stesso suggerisce fa da interfaccia comune ad entrambi.

'''Rapacioli dixit:'''\\

Alcune immagini di questa pagina sono prese dalle slide del prof [[Rapacioli->Giovanni Rapacioli]]

"E poi diciamolo, la maggior parte si rifferenzia per cazzate”.

%center%http://it.wikipedia.org/wiki/File:Bluetooth.svg

%sottotitolo%Appunti del 23-27 Aprile

%sottotitolo%Appunti del 23-27 Aprile