Università degli Studi di Pisa Facoltà di Ingegneria
Corso di Laurea in Ingegneria Elettronica Tesi di Laurea

Confronto tra due protocolli per reti Wireless: IEEE 802.11 e Bluetooth

Relatori:
Prof.   R. Saletti

Prof.   P. Terreni

Ing.   F. Potortì

Ing.   N. Celandroni

Anno Accademico 2001/2002

List of Figures

    2.1  WLAN Ad Hoc
    2.2  WLAN con Infrastruttura
    2.3  Modello generico di un sistema di comunicazioni Spread Spectrum
    2.4  Allocazione dei canali e sequenza pseudocasuale
    2.5  FHSS: uso del canale nel dominio del tempo
    2.6  DSSS: spettro dei segnali trasmesso e ricevuto
    2.7  DSSS: spreading dei dati
    3.1  Il protocollo Bluetooth (blocchi color arancio)
    3.2  La modulazione GFSK
    3.3  Bluetooth:baseband e link control
    3.4  Formato del BD_ADDR
    3.5  Piconet
    3.6  Scatternet
    3.7  Schema generale dei pacchetti Bluetooth
    3.8  Struttura dell'Access Code
    3.9  Struttura della sync word
    3.10  Struttura del packet header
    3.11  Meccanismo ARQ di Bluetooth
    3.12  Struttura del payload ACL
    3.13  Struttura del pacchetto DV
    3.14  Trasmissione di pacchetti broadcast
    3.15  Bluetooth: da Standby a Connection
    3.16  Schema della selezione delle frequenze di hop
    3.17  Selezione degli hop nello stato CONNECTION
    3.18  Selection Kernel per i sistemi a 79 hops
    3.19  Ciclo TX/RX in Inquiry
    3.20  Cronologia eventi e pacchetti della procedura di inquiry
    3.21  La procedura di inquiry nel dominio del tempo
    3.22  Cronologia eventi e pacchetti della procedura di page
    3.23  La procedura di page nel dominio del tempo
    3.24  Scambio di messaggi LMP per la richiesta della modalità Hold
    3.25  Sniff slots nel dominio del tempo
    3.26  Struttura generale del Beacon Channel
    3.27  Definizione delle Access Windows
    3.28  Procedura di accesso in modalità park
    3.29  Access windows e link SCO
    3.30  Scambio di ruoli master/slave
    4.1  L'architettura completa IEEE 802.11
    4.2  Relazioni tra i servizi IEEE 802.11
    4.3  Architettura del MAC IEEE 802.11
    4.4  Valori e limiti del parametro CW
    4.5  Procedura di backoff
    4.6  Procedura di accesso base
    4.7  IEEE 802.11: frammentazione
    4.8  Trasmissione fragment-burst
    4.9  Procedura di accesso con meccanismo RTS/CTS
    4.10  Problema dei nodi nascosti
    4.11  Meccanismo RTS/CTS e frammentazione
    4.12  Alternanza tra CFP e CP
    4.13  Formato dell'elemento CF parameter Set
    4.14  Beacon e CFP
    4.15  PCF: trasmissione PC verso STA
    4.16  PCF: trasmissione STA verso STA
    4.17  Struttura del campo Capability Information
    4.18  Trasmissione dei beacon in una BSS
    4.19  Trasmissione dei beacon in una IBSS
    4.20  Power management nelle BSS con infrastruttura
    4.21  Power management in una IBSS
    4.22  Primitive
    4.23  Scan Attivo
    4.24  Formato generale del frame MAC
    4.25  Formato del Frame Control Field
    4.26  WEP
    4.27  Composizione del frame di tipo dati
    4.28  Composizione dei frame di tipo management
    4.29  Modulazioni usate dal livello fisico FHSS
    4.30  Base hopping sequence per USA e Europa (tranne Francia e Spagna)
    4.31  FHSS: formato dei pacchetti PLCP
    4.32  Canali disponibili IEEE 802.11 DSSS
    4.33  Sequenza di Barker per IEEE 802.11 DSSS
    4.34  DSSS: spettro del segnale modulato
    4.35  DSSS: canali non sovrapposti nella banda ISM
    4.36  DSSS: formato dei pacchetti PLCP
    4.37  IEEE802.11b: canali non sovrapposti
    4.38  IEEE802.11b: canali sovrapposti
    4.39  IEEE802.11b: formato dei pacchetti PLCP con Long Preamble e Header
    4.40  IEEE802.11b: formato dei pacchetti PLCP con Short Preamble e Header
    5.1  Topologia di una rete Bluetooth: piconet
    5.2  Topologia di una rete Bluetooth: scatternet
    5.3  Topologia con infrastruttura e definizione di ESS
    5.4  La famiglia degli standard IEEE 802
    6.1  Soluzione PRISM 3 per IEEE802.11b
    6.2  Macchina a stati per la gestione dell'alimentazione di una scheda wireless IEEE 802.11
    6.3  Schema del chip CSR Bluecore01b per Bluetooth
    6.4  Consumo di potenza del chip CSR Bluecore01
    6.5  Consumo di potenza del chip CSR Bluecore2-External

List of Tables

    2.1  Bande tipicamente utilizzate per applicazioni WLAN
    3.1  Bande di frequenza Bluetooth
    3.2  Classi di potenza dei dispositivi Bluetooth
    3.3  Range teorico in base alla classe di potenza dei dispositivi Bluetooth
    3.4  Contenuto del campo L_CH
    3.5  Pacchetti speciali
    3.6  Pacchetti ACL
    3.7  Pacchetti SCO
    3.8  Ingressi al selection kernel per la fase di inquiry scan
    3.9  Ingressi al selection kernel per la fase di inquiry
    3.10  Inquiry-Incremento delle ripetizioni dei treni in presenza di link SCO
    3.11  Ingressi al selection kernel per la fase di inquiry response
    3.12  Ingressi al selection kernel per la fase di page scan
    3.13  Page scan-Relazione tra T_pagescan, N_page e le modalità di page R0, R1 e R2
    3.14  Ingressi al selection kernel per la fase di page
    3.15  Page - Relazione tra T_pagescan, N_page e le modalità di page R0,R1 e R2 in presenza di link SCO
    3.16  Ingressi al selection kernel per la fase di page response (slave)
    3.17  Ingressi al selection kernel per la fase di page response (master)
    3.18  Ingressi al selection kernel per lo stato connection
    3.19  Bluetooth: comandi usati per la modalità hold
    3.20  Bluetooth: comandi usati per la modalità sniff
    3.21  Bluetooth: comandi usati per la modalità park
    3.22  Bluetooth: gestione della sicurezza
    4.1  IEEE 802.11: standard approvati
    4.2  IEEE 802.11: standard in via di approvazione
    4.3  IEEE 802.11: standard in via di sviluppo
    4.4  IEEE 802.11: servizi disponibili
    4.5  IEEE 802.11: valori degli IFS per i vari PHY
    4.6  IEEE 802.11: valori dei limiti del CW per i vari PHY
    4.7  Composizione del payload dei frame Beacon
    4.8  Uso dei campi CF-Pollable e CF-Poll Request da parte dell'AP
    4.9  Uso dei campi CF-Pollable e CF-Poll Request da parte delle STA
    4.10  Modalità Power Management
    4.11  Parametri della primitiva MLME-SCAN.Request
    4.12  Parametri della primitiva MLME-SCAN.Confirm
    4.13  Parametri della primitiva MLME-JOIN.Request
    4.14  Elemento BSSDescription
    4.15  Parametri della primitiva MLME-JOIN.Confirm
    4.16  Valori possibili dei campi Type e Subtype del frame control field
    4.17  Valori possibili dei campi Type e Subtype del frame control field (continua)
    4.18  Combinazioni dei campi To/From DS nei frame di tipo dati
    4.19  Codifica dei bit del campo Duration/ID
    4.20  Relazione tra To/From DS e i campi Address in un frame dati
    4.21  Bande operative IEEE 802.11 FHSS
    4.22  Codifica dei simboli 2GFSK
    4.23  Codifica dei simboli 4GFSK
    4.24  Modulazione DBPSK
    4.25  Modulazione QBPSK
    4.26  Schema per la generazione dei parametri di fase
    4.27  Modulazione QPSK dei parametri di fase
    4.28  IEEE802.11b: canali operativi in Europa (tranne Francia e Spagna)
    5.1  Tempi di scoperta dei dispositivi IEEE 802.11 con scan attivo
    5.2  Confronto IEEE 802.11 e Bluetooth: creazione delle reti
    5.3  Classi di potenza dei dispositivi Bluetooth
    5.4  Confronto tra i data rate di alcuni sistemi Audio
    6.1  Modalità Power Save disponibili con il chipset PRISM e consumi di una scheda PCMCIA
    6.2  Consumi di una scheda PCMCIA basata sul chipset PRISM 2
    6.3  Confronto tra i consumi di Bluetooth e IEEE 802.11 in modalità continua
    6.4  Confronto tra i consumi di Bluecore e PRISM per un traffico a 64kbps

Chapter 1
Premessa

Scopo del presente lavoro di tesi è stato lo studio ed il confronto tra alcuni standard di comunicazione wireless nell'ambito della realizzazione di reti locali di computer (Wireless LAN). Il confronto è stato effettuato a livello di protocollo e particolare attenzione è stata rivolta al sottolivello MAC (Media Access Control).

Cosa sono le Wireless LAN

Le comunicazioni wireless, ed in particolare il Wireless Networking, rappresentano una tecnologia in rapida espansione che consente all'utente un accesso a reti e servizi senza necessità di cablaggi. Possiamo pensare, ad esempio,ad un utente provvisto di una serie di dispositivi, generalmente indipendenti l'uno dall'altro, quali il telefono cellulare, il computer portatile, il PDA¹e cosi via ed immaginare una situazione in cui questi dispositivi possano interagire fra di loro, ad esempio per condividere documenti presenti sul proprio computer portatile durante una riunione oppure per ricevere la posta elettronica sul PDA invece che sul computer fisso e tutto ciò senza necessità di alcun cablaggio. Possiamo pensare ad operazioni più "quotidiane" come entrare in un centro commerciale e veder comparire sul nostro PDA le ultime novità e le offerte del giorno oppure scaricare sul computer portatile mappe ed informazioni turistiche mentre si passa un casello autostradale o si sosta in una stazione di servizio. Tutto questo oggi è già possibile dal punto di vista tecnologico e le sperimentazioni sono già state avviate con successo in molte parti del mondo, Italia compresa. Le reti locali wireless sono senza dubbio uno dei possibili fulcri dell'attuale e futura innovazione tecnologica.

Ovviamente l'approccio wireless nella realizzazione di reti di computer presenta dei vantaggi ma anche degli svantaggi rispetto al classico approccio cablato .Questi aspetti saranno illustrati nell'Introduzione di questa tesi, insieme ad una panoramica sui vari "tipi" di comunicazione wireless, distinti sia in relazione ai vari campi di applicazione che in relazione ai vari mezzi trasmissivi che si possono usare per eliminare la presenza dei cavi. In seguito, nel Capitolo 2, vedremo una panoramica generale sugli standard wireless attualmente disponibili per la realizzazione di Wireless LAN, mentre nel Capitolo 3 analizzeremo in dettaglio le caratteristiche dei protocolli scelti come obiettivo della tesi, ovvero Bluetooth e IEEE802.11.

Chapter 2
Introduzione

Vantaggi e svantaggi dell'approccio Wireless

In via teorica, gli utenti di una rete locale wireless vogliono usufruire degli stessi servizi e vorranno disporre delle stesse potenzialità a cui una rete cablata li ha abituati. In pratica, l'equivalenza tra i due approcci wireless e wired, è una sfida aperta. In particolare l'approccio wireless, a fronte di innegabili vantaggi, è soggetto ad alcuni limiti non presenti nell'approccio cablato. Osserviamo i punti chiave del confronto tra i due approcci.

Mobilità

La libertà di movimento è uno dei vantaggi maggiori dei terminali² wireless nei confronti di quelli cablati, che sono statici quando connessi alla rete locale. La mobilità impone peró la necessità di considerare, a livello di sviluppo di sistemi, il problema dell' "handoff". In una wireless LAN ogni terminale ha un'area di copertura chiamato "cella", sfruttando un paradigma delle reti di telefonia cellulare; in teoria, le celle di una stessa rete si sovrappongono e quindi, per la maggior parte del tempo, un terminale si trova all'interno della cella di uno o più terminali. Se i terminali sono mobili, essi devono poter passare da una cella ad un'altra in maniera "trasparente" e senza perdere la connessione alla rete. Questo processo di passaggio è detto appunto handoff. Grazie alla mobilità dei terminali è più facile la gestione della loro posizione ovvero è agevolata la scalabilità delle reti. Di solito in fase di progetto di nuovi edifici , si potrebbe considerare la possibilità di cablare gli ambienti dedicati alla presenza di nodi di una rete locale (uffici, centri di calcolo e cosi via). È ovvio che tutto diventa più difficile per edifici già esistenti e per cui non è stata prevista la suddetta possibilità. Quest'ultima situazione è invece facilmente gestibile con le reti locali wireless. È notevolmente più semplice inoltre l'installazione di una rete locale laddove limiti ambientali e strutturali impedirebbero l'installazione e la gestione di una rete locale cablata standard (ad esempio strutture culturali quali musei ed edifici storici da salvaguardare).

Allocazione delle frequenze

Tutti gli utenti di una stessa rete locale wireless devono operare su una banda di frequenza comune, a prescindere dal mezzo trasmissivo scelto. Le bande di frequenza dedicate a particolari applicazioni devono ,di solito, essere approvate e necessitano di una licenza. Inoltre questa regolamentazione può variare da paese a paese. Questo problema è stato risolto dagli odierni standard per wireless LAN, i quali usano delle particolari bande di frequenza accessibili nella maggior parte dei paesi senza bisogno di alcuna licenza. La tabella 2.1 riassume le bande di frequenza che non hanno bisogno di licenza³ :

Interferenza e Affidabilità

L'interferenza nelle comunicazioni wireless può essere causata dalle cosiddette collisioni, ovvero trasmissioni simultanee da parte di due o più terminali wireless nella stessa banda di frequenza. In realtà il problema dell'interferenza e' più ampio e coinvolge anche dispositivi di uso comune che non hanno nulla a che vedere con le wireless LAN ma che possono causare non pochi problemi al funzionamento di queste ultime (ad esempio, un comune forno a microonde che opera nella banda 2.4-2.5 GHz). L'affidabilità del canale di comunicazione è misurata in BER (Bit Error Rate). Questo valore indica il numero di bit che hanno presentato un errore relativamente al numero totale di bit ricevuti per una trasmissione. Di solito viene espresso con una potenza negativa del dieci e dà un'indicazione di quante volte un pacchetto (o un'altra unità informativa) dev'essere ritrasmessa a causa di un errore.

Riservatezza dei dati

In una rete cablata il mezzo di trasmissione può essere reso sicuro fisicamente e l'accesso alla rete può essere controllato facilmente. In una wireless LAN, invece il mezzo trasmissivo è aperto a tutti i terminali wireless che si trovano nel raggio d'azione di un trasmettitore ed è perciò più difficile gestire la sicurezza sia delle trasmissioni che dell'accesso alle varie reti. La riservatezza dei dati e la protezione degli accessi sono di solito realizzati tramite crittografia a vari livelli. Alcune conseguenze dell'adozione di un certo grado di sicurezza indurranno probabilmente una certa riduzione delle prestazioni insieme ad un aumento dei costi dei dispositivi.

Consumo di potenza

I dispositivi di una rete cablata standard di solito sono alimentati dalla tensione di rete. I dispositivi wireless invece, dovendo essere portatili nonché mobili, sono di solito alimentati a batteria. Essi devono perciò essere progettati con la massima attenzione per quanto riguarda l'efficienza energetica.

Sicurezza degli utenti

Sono in corso da diverso tempo molteplici studi sui problemi che le emissioni RF ( Radio Frequenza ) potrebbero causare alla salute dell'utente. Le reti devono perciò essere progettate per minimizzare la potenza trasmessa dai dispositivi di rete. Per quel che riguarda i dispositivi wireless che utilizzano la tecnologia IR (Infra Red) i trasmettitori ottici devono essere progettati, ed in seguito installati, in modo da evitare danni alla vista.

Throughput

Dal punto di vista del throughput⁴ le wireless LAN, a causa di limiti sia fisici che di banda disponibile, partono svantaggiate rispetto alle reti cablate ma, nel corso degli anni le tecnologie che consentono la realizzazioni di wireless LAN sono migliorate, fino a poter disporre oggi di terminali wireless che possono comunicare ad una velocità di circa 54 Mbit/s.

Strutture tipiche e tecnologie per Wireless LAN

Le Wireless LAN forniscono tutte le funzionalità delle LAN cablate ma senza richiedere alcun cablaggio fisico. Possiamo distinguere sostanzialmente due tipi di configurazione per le WLAN ⁵ ovvero :

• Reti Ad Hoc

• Reti con Infrastruttura

La topologia "Ad Hoc" consiste nell'associazione spontanea di un gruppo di terminali con lo scopo di realizzare delle comunicazioni senza il sostegno di un'infrastruttura di rete ovvero di un coordinamento da parte di un particolare terminale. La comunicazione avviene quindi direttamente tra i terminali e l'area di copertura è limitata dal range dei singoli terminali. Questa struttura non prevede la connessione con una rete cablata ed è quindi costituita soltanto da terminali di tipo wireless.

La topologia "Infrastructured", al contrario, viene realizzata per fornire agli utenti dei servizi particolari (ad esempio la connessione con una rete LAN cablata preesistente o con reti WAN⁶ come Internet), oppure per aumentare l'area di copertura della rete WLAN. La comunicazione tra i terminali viene coordinata da un terminale particolare⁷ che gestisce anche i suddetti servizi aggiuntivi.

Dal punto di vista tecnologico, rispetto al mezzo trasmissivo utilizzato i dispositivi si dividono in 3 categorie principali :

• IR WLAN : Le comunicazioni wireless che utilizzano la porzione dello spettro denominata "infrarosso⁸", sono comunemente utilizzate per una vasta gamma di dispositivi di controllo remoto. Di recente, le suddette comunicazioni ottiche sono state oggetto di studio anche per quel che riguarda le applicazioni nel campo delle reti di computer. Come per qualsiasi soluzione tecnica, anche questa presenta vantaggi e svantaggi. Innanzitutto, come visto anche in tabella 2.1, lo spettro infrarosso è virtualmente illimitato e questo può permettere il raggiungimento di un'elevata capacità trasmissiva. Inoltre lo spettro infrarosso è immune da problemi di licenze. La radiazione infrarossa ha delle particolari caratteristiche che la rendono interessante per alcuni tipi di configurazione WLAN. Ovviamente tale radiazione non può oltrepassare muri o altre superfici opache, ma, grazie alle sue proprietà di riflessione, può essere riflessa diffusamente da oggetti colorati. Perciò si può realizzare una WLAN che copra un'intera stanza usando la riflessione del soffitto o delle pareti. Operando in questo modo, ad esempio, sono nulle le interferenze tra due WLAN operanti in ambienti adiacenti. Infine, il costo delle apparecchiature IR è relativamente basso cosi come la loro complessità.
Questo mezzo trasmissivo presenta anche degli svantaggi : essendo una radiazione luminosa, è soggetta ad interferenza da parte di tutte le altre sorgenti luminose quali luce solare o luce artificiale. Per acquisire maggiore robustezza nei confronti di queste interferenze si potrebbe pensare di aumentare la potenza dei trasmettitori ma quest'ultima è comunque limitata da problemi di consumo di potenza e dai pericoli derivanti dall'uso dei raggi infrarossi.

• Spread Spectrum WLAN : Il mezzo trasmissivo utilizzato è la Radio Frequenza. Attualmente la tecnica dello spread spectrum⁹ è quella più usata per la realizzazione di WLAN. Questa tecnica è stata inizialmente sviluppata per usi militari, proprio perchè l'idea che sta alla base dello spread spectrum è quella di "espandere" il contenuto informativo di un segnale su una banda maggiore di quella richiesta per rendere l'intercettazione più difficile. Questa non è l'unica ragione del successo della tecnica dello spread spectrum: i trasmettitori spread spectrum utilizzano gli stessi livelli di potenza dei trasmettitori narrowband¹⁰ ma , poichè lo spettro dei segnali è molto più ampio, la loro densità spettrale di potenza è notevolmente più bassa di quella dei trasmettitori narrowband. Dunque, i segnali spread spectrum e quelli narrowband possono occupare la stessa banda con bassissima interferenza.
Come tutti i dispositivi che utililizzano un mezzo trasmissivo RF, anche i dispositivi spread spectrum WLAN sono soggetti al problema cosiddetto "multi-path fading". Questo termine indica la situazione nella quale un segnale RF arriva ad un ricevitore da una serie di singoli percorsi di propagazione a causa delle riflessioni del segnale trasmesso su oggetti stazionari o in movimento. La lunghezza dei suddetti percorsi di propagazione è generalmente diversa e perciò i vari segnali arrivano al ricevitore con diversi ritardi. Questi ritardi si traducono in differenze di fase sui segnali. Il segnale risultante al ricevitore è la somma vettoriale dei segnali componenti e quindi tipicamente si hanno delle variazioni di ampiezza che hanno dato origine al termine "fading" poichè è molto probabile che l'ampiezza del segnale risultante sia più bassa di quella del segnale trasmesso.
La tecnica di spread spectrum può essere implementata in vari modi. Cronologicamente la prima implementazione è stata il cosiddetto frequency hopping spread spectrum mentre attualmente si preferisce usare la tecnica direct sequence spread spectrum. In generale si usa il modello mostrato in figura 2.3:

I dati vengono inviati ad un channel encoder che produce un segnale analogico con una banda relativamente stretta attorno ad una frequenza centrale. Questo segnale viene poi modulato usando una sequenza casuale di cifre detta pseudorandom sequence ed è proprio questa modulazione che incrementa significativamente la banda del segnale che dev'essere trasmesso. Dal lato del ricevitore, si usa la stessa pseudorandom sequence per demodulare il segnale spread spectrum. Infine il segnale viene inviato al channel decoder per recuperare il contenuto informativo. Osserviamo ora più in dettaglio le tecniche che implementano lo spread spectrum.

Frequency Hopping Spread Spectrum

Questa implementazione consiste nel trasmettere il segnale usando una sequenza pseudo casuale di frequenze radio¹¹, "saltando" di frequenza in frequenza ad intervalli di tempo fissati (ovvero con uno specifico "hop rate"). Dall'altro lato del canale, solo i ricevitori che conoscono la particolare sequenza di hopping del trasmettitore possono ricevere correttamente l'informazione.

La figura 2.4 mostra come vengano allocati un certo numero di "canali" per il segnale FH¹².

Come si vede dalla figura 2.5, il trasmettitore opera su una frequenza alla volta per un periodo di tempo prefissato¹³, durante il quale uno o più bit vengono trasmessi; dopodiché esso continua a trasmettere ma "saltando" alla frequenza che viene immediatamente dopo nella sequenza di hopping prestabilita in maniera "pseudo casuale".

Direct Sequence Spread Spectrum

Ogni singolo bit d'informazione del segnale originale viene codificato con un codice rappresentato da una sequenza di bit detta "chipping code". Questo processo detto "spreading" espande il segnale su una banda più ampia di quella richiesta per la trasmissione e tale espansione è direttamente proporzionale al numero di bit che compongono il chipping code. La sequenza di spreading è generata ad una velocità più alta rispetto al data rate del segnale informativo originale. Nel trasmettitore, il segnale informativo viene combinato in qualche modo con il chipping code (di solito si compie una operazione di OR Esclusivo (XOR) tra i due segnali). In seguito questa combinazione viene convertita in un simbolo che viene modulato e trasmesso. Dal lato del ricevitore si effettua l'operazione inversa (detta "De-spreading") per ottenere il segnale originario. Osserviamo le seguenti figure :

La figura 2.7 si riferisce in particolare all'operazione di spreading mediante sequenza di Barker, che analizzeremo in dettaglio nel capitolo dedicato allo standard IEEE 802.11.

Volendo fare un confronto tra le due tecniche possiamo osservare che :

• - I sistemi FH sono suscettibili al rumore durante un singolo "slot" ma a lungo termine possono realizzare una comunicazione quasi senza errori poichè la comunicazione si sposta lungo tutta la banda. I sistemi FH sono più semplici di quelli DS nel senso che gli schemi di modulazione utilizzati sono più semplici e quindi richiedono una minore complessità dal lato del ricevitore. A fronte di questi aspetti positivi dei sistemi FH, osserviamo che il loro data rate massimo è condizionato dall'ampiezza dei canali e, sfruttando tutta la banda a loro disposizione, tendono a causare maggiori interferenze su altri sistemi.
• - Il vantaggio principale dei sistemi DS è la possibilità di ottenere data rate più alti rispetto ai sistemi DS usando schemi di modulazione più complicati. Comunque, in generale, i metodi di modulazione usati nei dispositivi DS complicano la circuiteria dal lato del ricevitore.
• - La situazione attuale del mercato WLAN basati su Spread Spectrum vede una quasi completa predominanza dei sistemi DS sui sistemi FH.

Part 1
Panoramica sui protocolli per Wireless LAN

Chapter 3
Bluetooth

Bluetooth¹⁴[4],[5] è uno standard globale per comunicazioni wireless basato su un sistema radio a basso costo e a corto raggio d'azione. Questa tecnologia facilita il rimpiazzo dei cavi di collegamento tra dispositivi, realizzando un collegamento radio universale. Stampanti, computer portatili, computer fissi, PDA, fax, tastiere, joystick, mouse, tutti questi dispositivi possono far parte di un sistema Bluetooth. Oltre a sostituire i cavi, Bluetooth può anche agire da collegamento verso reti preesistenti (ovvero agire da bridge) oppure può essere visto come un sistema per realizzare piccole reti ad hoc quando ci si trova lontano da altre infrastrutture di rete. L'idea che portò alla tecnologia Bluetooth nacque nel 1994 quando la Ericsson Mobile Communication avviò uno studio di fattibilità di un sistema radio a basso consumo di potenza e a corto raggio per eliminare i cavi di collegamento tra i propri telefoni cellulari e i vari accessori (cuffie, PDA, schede per PC portatili e computer fissi). Nel 1998, Ericsson, Nokia, IBM, Toshiba e Intel formarono il Bluetooth SIG (Special Interest Group). Nel 1999 furono rilasciate le prime specifiche del protocollo Bluetooth (Bluetooth V1.0). L'anno seguente si unirono al Bluetooth SIG altre quattro compagnie: 3COM, Agere (Lucent Technologies), Microsoft, e Motorola, e venne lanciato sul mercato il primo prodotto finale ovvero un headset (cuffia e microfono per telefono cellulare) della Ericsson. Attualmente, le specifiche Bluetooth sono alla versione V1.1 e da marzo 2002 sono disponibili anche le specifiche IEEE802.15.1, rilasciate dall'IEEE (Institute for Electric and Electronic Engineering http://www.ieee.org) , perfettamente compatibili con le suddette specifiche Bluetooth v1.1. Le previsioni di mercato vedono un volume di circa 50 milioni di chip Bluetooth venduti entro l'anno 2002 e, a medio termine, si prevede un passaggio dai 10.4 milioni di chip venduti nel 2001, ai 690 milioni nel 2006.

3.1  Il protocollo Bluetooth

Il protocollo Bluetooth contiene una serie di specifiche che definiscono i vari livelli del protocollo stesso. Una caratteristica peculiare delle specifiche Bluetooth consiste nel fatto che esso non definisce solo un'interfaccia radio ma un intero stack¹⁵ software che permette ai dispositivi di trovarsi a vicenda, scoprire quali servizi essi offrano e quindi usare tali servizi. Il protocollo Bluetooth è organizzato a livelli, anche se alcune funzioni che esso offre sono distribuite su più di un livello.

Ciascun blocco di colore arancio nella figura 3.1 corrisponde ad un capitolo della parte delle specifiche Bluetooth, denominata Core. In più, nel core, troviamo altri tre capitoli:

• Modalità di Test dei dispositivi Bluetooth
• Richieste di compatibilità Bluetooth
• Interfaccia di controllo per la modalità Test

Oltre al core, Bluetooth fornisce anche i cosiddetti Profiles, che danno dei dettagli su come alcune particolari applicazioni dovrebbero usare il protocollo Bluetooth.

3.2  Il livello Radio

La sezione radio è una parte fondamentale di un dispositivo Bluetooth. I dispositivi Bluetooth operano nella banda ISM 2.4 GHz. Questa banda non richiede la licenza delle frequenze utilizzate ma, e, proprio per questo, i dispositivi Bluetooth devono essere molto tolleranti rispetto alle interferenze presenti. In USA e nella maggior parte dell'Europa sono disponibili 83.5 MHz; in questa banda vengono allocati 79 canali RF spaziati di 1 MHz. In Giappone, Francia e Spagna sono disponibili solo 23 canali RF sempre spaziati di 1 MHz.

Bluetooth adotta la tecnica frequency hopping spread spectrum, quindi il canale fisico è rappresentato da una sequenza pseudo casuale dei 79 (o 23) canali RF disponibili; ovviamente, i dispositivi progettati per operare in paesi con un insieme ridotto di frequenze di hopping, non possono funzionare nei paesi in cui sono disponibili tutti i canali RF previsti per la banda ISM 2.4 GHz, né viceversa. La velocità di segnalazione è di 1Msimbolo/s e questo si traduce in una velocità di trasferimento teorica di 1 Mbit/s poiché è stato scelto come schema di modulazione il GFSK (Gaussian shaped Frequency Shift Keying). Il canale fisico è diviso in slot da 625μs, ed i dispositivi cambiano frequenza una volta ogni pacchetto¹⁶, tenendo presente che un pacchetto può durare uno, tre oppure cinque slot.

3.2.1  La modulazione GFSK

La modulazione GFSK è una variante della modulazione FSK (Frequency Shift Keying, che, per un bit d'informazione di valore 1 origina uno scostamento di frequenza positivo rispetto alla portante nominale del canale in cui il sistema FH sta operando ad un dato istante. Al contrario, un bit di valore 0 dà origine ad uno scostamento negativo della suddetta portante. La modulazione GFSK adottata da Bluetooth prevede un prodotto BT¹⁷ pari a 0.5 e un indice di modulazione compreso tra 0.28 e 0.35. Il prodotto BT è il prodotto della distanza frequenziale tra segnali adiacenti(0.5 MHz) (bandwidth) e la durata temporale del simbolo(1 μs) (time). Un valore per BT di 0.5 corrisponde alla minima distanza di separazione tra le portanti che garantisce l'ortogonalità¹⁸ tra segnali in canali adiacenti. L'indice di modulazione rappresenta l'ampiezza del già citato scostamento di frequenza (o deviazione di frequenza) (fd), e può essere espresso come 2×fd×T, dove T è la durata del simbolo. Ciò si traduce in un intervallo di variazione della frequenza da 140 KHz a 175 KHz. Le specifiche Bluetooth danno un minimo di 115 KHz come variazione assoluta.

La G-FSK adotta un filtro Gaussiano per "addolcire" le transizioni di frequenza, cosicché la frequenza portante cambia seguendo un inviluppo di forma Gaussiana e vengono ridotte le dimensioni spettrali dei lobi laterali, migliorando così l'efficienza spettrale e riducendo l'interferenza intersimbolica. Il filtro Gaussiano agisce sul flusso dei bit trasmessi e può essere implementato sia nella sezione radio tramite un filtro analogico, sia nella sezione digitale del livello baseband usando un filtro FIR implementato come un linear feedback shift register(LFSR) o, infine, come una parte di una lookup table.

3.2.2  Classi di potenza

I dispositivi Bluetooth vengono divisi in 3 classi di potenza, a seconda della potenza massima d'uscita del trasmettitore.

3.2.3  Caratteristiche del ricevitore

Definiamo actual sensitivity level (effettivo livello di sensibilità) di un ricevitore RF il livello del segnale d'ingresso per il quale si ottiene un BER pari a 0.1%. Per un ricevitore Bluetooth, viene richiesto un actual sensitivity level minimo di -70dBm. È interessante notare come i dispositivi radio Bluetooth siano dotati di una funzionalità loop back , utile per misurare la loro prestazione in termini di BER¹⁹.

3.3  Il livello Baseband

Cominciamo a descrivere questo livello dello stack Bluetooth facendo una distinzione chiara tra i termini link controller e baseband, i quali sono a volte usati ambiguamente nelle specifiche Bluetooth.

Il link controller (LC) si occupa di svolge operazioni relative alla trasmissione di diversi pacchetti, in risposta ai comandi del link manager (LM). Le entità LC ai due lati di una connessione gestiscono il processo di creazione della connessione stessa richiesta dal LM, e mantengono nel tempo la connessione, una volta stabilita. Il baseband invece, è responsabile delle operazioni di codifica e decodifica, di controllo della temporizzazione a basso livello e, in generale, è responsabile della gestione della connessione ma nel dominio del singolo pacchetto dati.

3.3.1  Indirizzamento dei dispositivi

Ogni dispositivo Bluetooth ha un indirizzo di 48 bit compatibile IEEE MAC detto Bluetooth device address (BD_ADDR). Questo indirizzo è diviso in 3 parti:

• BD_ADDR[47:32] - NAP[15:0]
  Usato per inizialiazzare il flusso che va al ``motore'' che realizza la crittografia (LFSR).
• BD_ADDR[31:24] - UAP[7:0]
  Usato per inizializzare i meccanismi HEC (header error correction) e CRC (cyclic redundancy check) e per il FH.
• BD_ADDR[23:0] - LAP[23:0]
  Usato per la generazione della sync word e per il FH.

3.3.2  Master, slave,piconet e scatternet

Come abbiamo visto, Bluetooth adotta la tecnica FHSS, la banda operativa è divisa in canali spaziati di 1 MHz e la velocità di modulazione è di 1Msimbolo/s. Il canale fisico è diviso in slot da 625μs, e i dispositivi cambiano frequenza una volta ogni pacchetto, tenendo presente che un pacchetto può durare uno, tre oppure cinque slot.

L'hop rate²⁰ è fissato a 1600 hops/s.
La tecnica frequency hopping impone che i dispositivi Bluetooth che vogliono comunicare, conoscano e seguano la stessa sequenza di hopping. I dispositivi Bluetooth possono operare in due diverse modalità :

• Master
• Slave

Questo non vuol dire che, a livello circuitale e costruttivo, vi siano delle differenze tra un dispositivo che opera come master e uno che opera come slave. E' il master che decide la sequenza di hopping, gli slave che vogliono comunicare con un certo master devono sincronizzarsi in frequenza e tempo con la sequenza di hopping del master. Una serie di slave che operano insieme e sono sincronizzati con uno stesso master formano una cosiddetta Piconet.

Una piconet può essere formata da un master ed un massimo di sette slave "attivi", dove per slave attivo si intende un'unità che rimane sincronizzata al master della piconet. Lo standard Bluetooth prevede comunque, come vedremo in seguito, alcune modalità di funzionamento per i dispositivi (modalità park ad esempio) che permettono di ampliare "virtualmente" la dimensione di una piconet, nel senso che alcuni dispositivi, essenzialmente per limitare il consumo delle batterie, potranno dissociarsi temporanemente dall'attività della piconet, ma rimanere informati periodicamente dal master in modo da poter rientrare attivamente nella piconet in qualsiasi momento, purché ovviamente ci sia posto.
E' il livello baseband che descrive ed applica l'algoritmo usato dai dispositivi Bluetooth per derivare una sequenza di hopping dal proprio BD_ADDR e dal proprio clock. In una singola piconet, la sequenza di hopping è unica ed è derivata dal BD_ADDR e dal clock del master. Quando uno slave si unisce alla piconet viene informato dal master stesso sul proprio BD_ADDR e sul proprio clock cosicché lo slave possa calcolare la sequenza di hopping da usare per le comunicazioni nella piconet.
Oltre a controllare la sequenza di hopping, il master è il vero dominatore del mezzo trasmissivo, nel senso che esso decide quando i dispositivi che fanno parte della propria piconet possono trasmettere. Bluetooth distingue a questo proposito due tipi di traffico:

• Voce
• Dati

Il master decide quando gli slave possono trasmettere allocando degli slot per il traffico voice e degli slot per il traffico dati. Per il traffico dati, uno slave può trasmettere solo in risposta ad una trasmissione del master ad esso indirizzata, ovvero se il master durante uno slot riservato al traffico data ha trasmesso un pacchetto indirizzato verso uno specifico slave, il successivo slot è allocato automaticamente per una eventuale trasmissione di dati da parte unicamente di quel particolare slave, a prescindere se esso abbia o non abbia effettivamente dati da trasmettere. Per il traffico voce invece, gli slave trasmettono in slot riservati dal master, a prescindere se siano stati destinatari di una precedente trasmissione oppure no. In ogni caso, la comunicazione avviene sempre tra il master e uno slave, cosicché se uno slave dovesse trasmettere un pacchetto ad un altro slave nella stessa piconet, tale pacchetto dovrebbe comunque passare attraverso il master. Questo sistema di divisione degli slot temporali fra 2 dispositivi si chiama Time division duplex (TDD). Abbiamo visto come il numero degli slave attivi che compongono una piconet sia limitato a sette. Si può comunque realizzare un'area di copertura più ampia (realizzando così una rete più grande) collegando insieme più piconet, a formare quella che Bluetooth definisce Scatternet.

Quando un dispositivo è presente in più di una piconet, deve dividersi e operare per un certo numero di slot in una piconet, usando la sequenza di hopping di quella piconet, e poi, cambiando sequenza di hopping, passare ad operare in un'altra piconet. Nella figura 3.6, a sinistra osserviamo una scatternet in cui un dispositivo Bluetooth si comporta da master per una piconet e da slave nell'altra piconet. A destra osserviamo invece la situazione in cui un dispositivo si comporta da slave in due piconet diverse. Non è possibile utilizzare un dispositivo Bluetooth come master in due piconet diverse, poiché, per definizione, tutti i dispositivi sincronizzati con uno stesso master fanno parte della stessa piconet. Come abbiamo visto, una caratteristica frequente dei terminali wireless è la mobilità; un terminale Bluetooth mobile può quindi, muovendosi, perdere contatto con la propria piconet: non c'è alcun problema poichè il suo collegamento alla piconet ha un supervision timeout che assicura la chiusura dei collegamenti quando i dispositivi Bluetooth si allontanano dall'area di copertura della piconet (vedi 3.3.7).

3.3.3  Temporizzazione e Clock

Illustreremo ora il concetto del clock Bluetooth. Bluetooth sincronizza la maggior parte delle operazioni con un clock in tempo reale. Esso servirà, ad esempio, a sincronizzare gli scambi di dati tra i dispositivi, distinguere tra pacchetti ritrasmessi o persi, generare una sequenza pseudo casuale predicibile e riproducibile. Il clock Bluetooth è realizzato con un contatore a 28 bit che viene posto a 0 all'accensione del dispositivo e subito dopo continua senza fermarsi mai, incrementandosi ogni 312.5μs(metà slot quindi). Il ciclo del contatore copre approssimativamente la durata di un giorno:

312.5μs×2²⁸ ≅ 23.3 ore

Ogni dispositivo Bluetooth ha il suo native clock (CLKN) che controlla la temporizzazione di quel dispositivo. Oltre a questo valore, proprio di ogni dispositivo, Bluetooth definisce altri due clock

• CLK: questo è il clock della piconet, coincide con il CLKN dell'unità master della piconet. Tutte le unità attive nella piconet devono sincronizzare il proprio CLKN con il CLK. La sincronizzazione avviene aggiungendo un offset al CLKN dello slave per farlo coincidere con il CLK della piconet.
• CLKE: anche questo clock è derivato tramite un offset dal CLKN ed è usato dal master nel caso specifico della creazione di una connessione verso uno slave, e prima che tale slave si sia sincronizzato con il master (ovvero quando si tratta di un nuovo slave).

I primi 2 bit del contatore vengono usati direttamente per delimitare gli slot e i cosiddetti "mezzi slot", per la trasmissione e ricezione dei pacchetti; essi servono anche a stabilire nel tempo gli slot Tx (trasmissione) o Rx (ricezione) a seconda se il dispositivo in questione stia funzionando da master o da slave. Una trasmissione da parte del master comincerà sempre quando CLK[1:0]=00(slot di indice pari), mentre una trasmissione da parte di uno slave comincerà sempre quando CLK[1:0]=10 (slot di indice dispari).

3.3.4  Tipi di Link: ACL e SCO

Un "link" è un collegamento che viene stabilito tra un dispositivo master e un dispositivo slave. Una volta instaurato tale collegamento, ci sono due tipi di "servizi" che possono essere svolti sfruttando il collegamento:

• Servizi di tipo Asincrono : vengono riferiti da Bluetooth con il termine ACL (Asynchronous Connection-Less)
• Servizi di tipo Sincrono : vengono riferiti da Bluetooth con il termine SCO (Synchronous Connection-Oriented)

Tali servizi sono svolti tramite lo scambio di pacchetti. Vi sono alcuni pacchetti dedicati esclusivamente ai servizi ACL, altri dedicati esclusivamente ai servizi SCO ed infine dei pacchetti "misti".

ACL

Un link²¹ACL esiste non appena viene creata una connessione tra un master e uno slave. Un master può avere un qualsiasi numero di link ACL con un certo numero di slave diversi, ma può esistere solo un link ACL tra due dispositivi²². Un link ACL realizza un collegamento a commutazione di pacchetto tra il master e lo slave: i pacchetti vengono scambiati sporadicamente e cioè quando sono disponibili dei dati da inviare dai livelli superiori dello stack Bluetooth. La scelta di quale slave deve ricevere o trasmettere è fatta dal master slot per slot al passare del tempo, e così sono possibili sia dei servizi asincroni che "isocroni"²³. Alcuni tipi di pacchetti ACL prevedono la possibilità di sfruttare degli schemi di ritrasmissione e delle tecniche di controllo d'errore, per aumentare la robustezza della trasmissione. Uno slave può rispondere con un pacchetto ACL nel successivo slot "slave-master" se e solo se è stato indirizzato direttamente nel precedente slot "master-slave". Ovviamente, date le caratteristiche del mezzo trasmissivo RF, tutti gli slave nell'area di copertura di un master ascoltano le sue trasmissioni. Se uno slave, ascoltando le trasmissioni ovvero i pacchetti, non riesce a decodificare il proprio indirizzo in un certo pacchetto, non è autorizzato a trasmettere nel prossimo slot slave-master. C'è la possibilità anche di inviare dei pacchetti broadcast, che possono essere ricevuti da tutti gli slave in ascolto.

SCO

Un link SCO fornisce un collegamento simmetrico tra master e slave, banda riservata all'interno del canale e scambio di dati su base periodica sotto forma di slot riservati proprio per questo tipo di collegamento. Perciò, un link SCO realizza un collegamento a commutazione di circuito tra master e slave. Un master può realizzare fino a 3 link SCO con 3 diversi slave contemporaneamente. Uno slave può realizzare fino a 3 link SCO con lo stesso master oppure 2 con master diversi. I pacchetti di un link SCO non vengono mai ritrasmessi. Uno slave può sempre rispondere ad un pacchetto SCO, nello slot SCO riservato alla risposta, anche se non è stato capace di decodificare il proprio indirizzo nel pacchetto ricevuto. Un trasferimento periodico SCO può essere interrotto solo da un messaggio broadcast del tipo LMP (Link Manager Protocol): solo in questo caso il master può trasmettere in slot riservati SCO pacchetti diretti da qualche altra parte rispetto alla destinazione dei pacchetti SCO. Ogni dispositivo dovrà programmare il traffico ACL in modo da rispettare gli slot riservati al traffico SCO. L'unica eccezione è, come detto, rappresentata dai pacchetti di controllo del LMP che servono, tra l'altro, anche a chiudere un link SCO qualora non sia più necessario.

3.3.5  Struttura dei pacchetti Bluetooth

Ciascun pacchetto Bluetooth consiste di:

1. Access Code
2. Packet Header
3. Payload²⁴

Access Code

Durante la connessione tra i dispositivi, quando un link (ACL o SCO) è stato instaurato, l'access code serve ad identificare i pacchetti che provengono da uno specifico master, poiché esso è derivato dal BD_ADDR del master stesso. In questo modo, se uno slave attivo in una piconet gestita da un master dovesse trovarsi contemporaneamente nell'area di copertura di un altro dispositivo Bluetooth, ricevendo quindi anche i pacchetti trasmessi da quest'ultimo, può distinguere quali sono i pacchetti relativi alla propria piconet e scartare invece quelli con un access code diverso, e tutto ciò semplicemente decodificando 68 (72) bit di access code anziché un pacchetto completo. La prima parte dell'access code è un preambolo che serve a rilevare i limiti dei dati ricevuti. Tale preambolo è "0101" oppure "1010", in dipendenza del primo bit della sync word. L'ultima parte dell'access code è il cosiddetto trailer che è presente solo se il pacchetto che segue all'access code in questione possiede un payload (esiste un tipo di pacchetto costituito dal semplice access code, senza header né payload; in quel caso l'access code è di 68 bit e non c'è il trailer).

La figura 3.9 mostra la struttura della sync word che è la parte essenziale dell'access code. La sync word possiede delle particolari proprietà²⁵ che facilitano il compito del "correlatore", ovvero del componente che il dispositivo Bluetooth in ricezione usa per stabilire se il pacchetto che segue l'access code è significativo oppure no. E' opportuno a questo proposito specificare i vari tipi di access code che si possono incontrare nei pacchetti trasmessi usando il protocollo Bluetooth :

• Channel Access Code (CAC) E' derivato dal LAP del BD_ADDR del master e viene usato da tutti i dispositivi in quella piconet durante lo scambio dei dati. Come detto precedentemente, è riconoscendo il CAC della piconet che uno slave riconosce pacchetti eventualmente ad esso indirizzati.
• Device Access Code (DAC) Il DAC è derivato dal LAP di uno specifico slave ed è usato dallo stesso slave nella fase di Page Scan²⁶ e dal master nella fase di Page²⁷ verso quello slave specifico.
• General Inquiry Access Code (GIAC) Il GIAC è usato da tutti i dispositivi durante le procedure di Inquiry²⁸. Il suo valore è fissato dalle specifiche Bluetooth e vale 0x9E8B33.
• Dedicated Inquiry Access Code (DIAC) Ha la stessa funzione del GIAC (inquiry) ma è usato per restringere la ricerca a particolari classi di dispositivi Bluetooth (ad esempio si possono cercare solo nuove stampanti, o PC o palmari).

Dunque, per concludere il discorso sull'access code, in dipendenza dallo stato dell'unità Bluetooth, il correlatore si aspetterà un particolare access code tra quelli appena visti. Se la correlazione con l'access code di riferimento avrà dato risultato positivi, allora il dispositivo Bluetooth continuerà ad ascoltare il resto del pacchetto.

Packet Header

Il packet header contiene informazioni di controllo associate al pacchetto. In totale l'header contiene 18 bit d'informazione, che vengono protetti con un codice FEC (forward error correction) di 1/3, che replica 3 volte ciascun bit d'informazione. Questo livello di ridondanza è necessario poiché le informazioni contenute nell'header sono importanti ai fini del corretto funzionamento del link. Infine viene anche utilizzato un controllo CRC (cyclic redundancy check) sull'header stesso al fine di evitare il proseguimento della ricezione e codifica del payload che segue nel caso il controllo CRC riesca. Vediamo ora in dettaglio i vari campi dell'header.

AM_ADDR

Durante la procedura di page, il master assegnerà un Active Member Address allo slave. Questo AM_ADDR costituirà un handle²⁹ usato per indirizzare tutte le comunicazioni verso quello slave e verrà usato dal master per distinguere le risposte dei diversi slave. Il campo è di 3 bit e quindi é sufficiente per indirizzare 7 slave. Un AM_ADDR pari a "000" corrisponde ad un pacchetto broadcast che verrà ricevuto da tutti gli slave della piconet³⁰.

Packet Type

Questo campo definisce il tipo di traffico trasportato dal pacchetto in questione (SCO,ACL,NULL o POLL), il tipo di correzione d'errore adottata per il payload e quanti slot occuperà il payload stesso.

Flow

Questo campo funziona da flag per segnalare che il dispositivo che sta inviando il pacchetto corrente non è più in grado di ricevere dati a causa del riempimento del proprio buffer di ricezione.

ARQN e SEQN

Tramite il flag ARQN viene realizzato il meccanismo di ARQ (automatic repeat request) di Bluetooth. Questo meccanismo è previsto solo per i link ACL, mentre invece i pacchetti di un link SCO non vengono mai ritrasmessi. Il suo funzionamento è semplice: quando lo slave riceve correttamente il pacchetto inviatogli dal master, pone il bit ARQN a 1 nel pacchetto che esso manda in risposta al master. Basandosi su questa informazione, il master decide se trasmettere un nuovo pacchetto o ritrasmettere lo stesso. Il master continuerà a ritrasmettere lo stesso pacchetto finché non riceverà un'indicazione sulla corretta ricezione del pacchetto stesso oppure finché non scadrà un timeout. Il meccanismo è uguale per i pacchetti dal master verso lo slave. Tutto ciò realizza un semplice algoritmo "stop and wait" che aiuta a minimizzare l'overhead dovuto alle ritrasmissioni. Sempre in questo contesto, il flag SEQN serve ad informare il destinatario di un pacchetto quando quest'ultimo è un pacchetto ritrasmesso oppure un pacchetto nuovo. Il bit SEQN viene cambiato (toggled) ogni volta che viene trasmesso un pacchetto nuovo. Il meccanismo ARQ appena descritto, può tuttavia causare un certo ritardo variabile nel flusso dei dati. Alcuni tipi di link ammettono un limite al massimo ritardo nel flusso dei dati: un ritardo dovuto alle ritrasmissioni è accettato fino al suddetto limite, dopodiché il dato viene abbandonato³¹. Nelle specifiche Bluetooth è definita un'operazione detta flushing, con la quale s'interrompe il processo di ritrasmissione se si supera un certo valore e si forza il dispositivo a trasmettere il dato successivo, abbandonando quello corrente. Questa operazione è regolata da un timer, il flushing timeout, che specifica in pratica per quanto tempo l'unità può continuare a ritrasmettere un pacchetto prima di abbandonarlo e passare al successivo. Sono possibili anche configurazioni estreme, quali nessuna ritrasmissione e ritrasmissioni infinite.

Header Error Check(HEC)

E' una funzione CRC a 8 bit applicata all'header. Il polinomio generatore è :

g(D)=D8+D7+D5+D2+D+1

Come abbiamo visto, il fallimento del controllo HEC permette ad un dispositivo ricevente di ignorare il resto del pacchetto.

Payload ACL

Il payload ACL è diviso in 3 parti :

Payload Header

L'header del payload di un pacchetto ACL è a sua volta composto dai seguenti campi :

L_CH

Bluetooth definisce 4 canali logici realizzati tramite i link SCO e ACL. Non vengono usati spesso in letteratura sebbene siano importanti per capire le differenze tra i contenuti dei diversi pacchetti e quindi capire le differenze tra le varie informazioni che essi trasportano (vedi tabella 3.4).

1. LC (Link Control)
   Questo canale logico viene realizzato dall'header di pacchetto e consiste nei dati ARQ, SEQ e i dati di controllo associati. Come detto precedentemente, questi dati sono fondamentali per il mantenimento del link.
2. LM (Link Manager)
   Questo canale viene realizzato tramite un payload ACL dedicato e contiene dati di controllo LM (link manager) che vengono scambiati tra le due entità LM (locale e remota). Tipicamente viene realizzato tramite un pacchetto comune ai link SCO e ACL³² in modo che le informazioni LM possano essere trasportate anche durante l'attività di un link SCO.
3. UA/UI (User Asynchronous data/User Isochronous data)
   Questo canale viene realizzato tramite il payload ACL e contiene dati provenienti dal livello L2CAP, che si occupa, tra l'altro, anche della segmentazione e riassemblaggio dei pacchetti. A questo proposito, la frammentazione è indicata da con un particolare valore di L_CH :
• L_CH=10 per il pacchetto iniziale
• L_CH=01 per un pacchetto "continuazione"
4. US (User Synchronous)
   Questo canale viene realizzato tramite il payload dei pacchetti SCO.

flow

Questo flag controlla il trasferimento dei dati a livello L2CAP(logical link control and adaptation layer)

lenght

Questo campo specifica la lunghezza in byte del payload stesso.

Struttura pacchetti SCO

I pacchetti SCO hanno lo stesso access code e header dei pacchetti ACL³³, anche se i campi flow, ARQ e SEQ sono ridondanti perchè per il link SCO non è previsto il controllo sul flusso dei dati e lo schema di ritrasmissione visto per ACL; manca anche il campo CRC. La lunghezza del payload è fissata a 30 byte, ove il contenuto informativo può essere 10, 20 o 30 byte a seconda del rapporto FEC usato (1/3, 2/3 o nessun FEC).

Struttura del pacchetto misto ACL/SCO

Il pacchetto chiamato DV è un pacchetto speciale utilizzato nei link di tipo SCO. Esso può trasportare fino a 10 byte di informazioni di tipo voice, come si vede dalla figura. Il campo voice field non può essere ritrasmesso e ad esso non è applicato alcun metodo FEC. Questo pacchetto trasporta anche fino a 9 byte (72 bit) di informazioni di tipo data. Il campo data field è protetto da un FEC 2/3 (5 bit di parità vengo aggiunti ad ogni blocco di 10 bit) , un campo CRC e i soliti campi flow, ARQ e SEQ. La ritrasmissione della porzione data è possibile e avviene sempre tramite un altro pacchetto DV nello stesso link SCO.

Pacchetti di controllo: ID, POLL, NULL e FHS

Bluetooth prevede 4 pacchetti di controllo: ID, POLL, NULL e FHS. Essi sono comuni a entrambi i tipi di link, SCO e ACL. Vengono usati per la sincronizzazione, e per altre funzioni di controllo del canale che verranno esaminate in seguito.

Trasmissione Broadcast

Il master può mandare dati contemporaneamente a tutti gli slave attivi in una piconet (broadcast). Ciò viene fatto mettendo nel campo AM_ADDR tutti e 3 i bit a 0. Visto che un pacchetto broadcast è diretto verso più slave, non è applicabile l'algoritmo ARQ visto a pagina 30. Al posto di quest'ultimo algoritmo si irrobustisce la trasmissione broadcast semplicemente ripetendo sempre un pacchetto broadcast un certo numero di volte. Il flag ARQN non viene usato, al contrario del flag SEQN che viene usato per indicare la ritrasmissione di uno stesso pacchetto broadcast. Un messaggio broadcast viene scomposto in un certo numero di pacchetti Bluetooth e ciascun pacchetto viene ripetuto N_BC.

3.3.6  Prestazioni di un link Bluetooth a livello baseband

Le tabelle 3.6 e 3.7, riassumono i pacchetti Bluetooth utilizzati a livello banda base:

I diversi pacchetti ACL, attraverso la presenza o assenza di FEC e CRC e tramite le diverse dimensioni dei payload, mediano tra un basso throughput con una maggiore robustezza del link e tra un più alto throughput con una minore robustezza del link. Una maggiore protezione contro gli errori implica una maggiore ridondanza dei dati, mentre i pacchetti più lunghi (ad esempio Dx3/Dx5 con x=H o M) sono più suscettibili agli errori data la loro maggiore permanenza sul mezzo trasmissivo.

I pacchetti SCO usano un livello crescente di correzione d'errore, aggiungendo ridondanza ai dati e perciò robustezza al link. E' il Link Manager (LM) che, controllando costantemente la qualità e l'affidabilità di un link, decide quale tipo di pacchetto è appropriato in un dato istante. Alcuni dispositivi non supporteranno alcuni tipi di pacchetti,e quindi, al momento dell'inizializzazione del link, ci sarà bisogno di una accordo su quest'aspetto.

Il throughput simmetrico è ottenuto usando lo stesso tipo di pacchetti in entrambe le direzioni (master to slave e slave to master). Comunque, molte applicazioni richiedono un'occupazione di banda asimmetrica e quindi, in generale, un link può trasportare un tipo di pacchetti in una direzione e un altro tipo nell'altra direzione. Perciò, il throughput massimo pari a 732 kb/s può essere ottenuto usando pacchetti di 5 slot in una direzione e pacchetti mono slot a 57.6 kb/s nell'altra. Il massimo throughput simmetrico, ovvero 433.9 kb/s, può essere ottenuto usando pacchetti DH5 in entrambe le direzioni.

3.3.7  Supervisione del link

Sia il master che lo slave, posseggono un timer, T_supervision, che viene inizializzato col valore supervisionTO e viene resettato ogni volta che viene ricevuto un pacchetto che contiene il giusto AM_ADDR e che passa con successo il controllo HEC. Viene usato lo stesso timeout per SCO e ACL. Il valore supervisionTO è negoziato dalle due unità Bluetooth a livello LM. Il suo valore dev'essere maggiore dei periodi di hold e sniff (vedi 3.4.14 e 3.4.15). Per default il valore supervisionTO è pari a 20s, ma può essere impostato con un comando HCI (host controller interface) ad un qualsiasi valore tra 0.625 μs e 40.9s. Per quel che riguarda gli slave in modalità park, la supervisione del link viene effettuata con periodiche operazioni di unpark e park (vedi 3.4.16)

3.4  Il Link Controller

La funzione del link controller (LC) comincia dove finisce l'azione del processore baseband³⁴. Vedremo come il link controller configura e gestisce i link e il livello sottostante (baseband). Il link controller di un dispositivo Bluetooth si occupa di realizzare operazioni visibili ad alto livello come l'inquiry e il page e gestisce i link con i diversi dispositivi, anche con quelli situati in altre piconet.

3.4.1  Stati del link controller

In un dato istante di tempo, un'unità Bluetooth può trovarsi in uno dei seguenti stati :

1. Stati Principali
• Standby
• Connection
2. Sottostati
• Page
• Page Scan
• Inquiry
• Inquiry Scan
• Master Response
• Slave Response
• Inquiry Response

Questi sottostati sono stati temporanei, usati per costruire una nuova piconet oppure per aggiungere nuovi slave ad una piconet esistent. In particolare:

• Inquiry e Inquiry Scan sono dedicati alla ricerca di nuovi dispositivi. Un dispositivo Bluetooth che volesse scoprire nuovi dispositivi nel proprio raggio di trasmissione, dovrebbe compiere un processo di inquiry e scoprirebbe i dispositivi che contemporaneamente volessero farsi scoprire trovandosi in inquiry scan. Durante l'inquiry, il dispositivo raccoglie informazioni utili per realizzare successivamente delle connessioni con i dispositivi scoperti.
• Inquiry Response è lo stato in cui si porta un dispositivo scoperto durante le fasi precedenti, per trasmettere delle informazioni utili sul proprio stato(CLKN, BD_ADDR) al dispositivo che lo ha scoperto (inquiry).
• Page, Page Scan, Master Response e Slave Response sono dedicati alla realizzazione di una nuova connessione tra 2 dispositivi Bluetooth. La creazione di tale connessione viene facilitata dalla conoscenza reciproca di parametri quali CLKN e BD_ADDR dei 2 dispositivi.
  La figura seguente mostra qual' è in generale il percorso che viene seguito da 2 unità Bluetooth, dallo standby alla creazione di una connessione e quindi di una piconet.

Bisogna notare che lo standard Bluetooth non impone la suddetta successione degli stati, nel senso che, se ad esempio disponiamo di due o più dispositivi Bluetooth, probabilmente dello stesso costruttore, che si conoscono a vicenda, ovvero che conoscono i rispettivi BD_ADDR, non c'è bisogno di effettuare la procedura di Inquiry e si può passare direttamente alla fase di page. Questa possibilità è stata resa disponibile per realizzare interfacce MMI (Man Machine Interface) minimali.

3.4.2  Sequenze di hopping

Bluetooth specifica diverse sequenze di hopping associate ai suddetti stati e sottostati. A parte lo stato Standby, a cui non è associata nessuna sequenza di hopping³⁵, sono definite 10 diverse sequenze, 5 per i sistemi realizzati per i paesi in cui sono a disposizione 79 canali e altre 5 per i sistemi realizzati per i paesi in cui sono a disposizione solo 23 canali. Usando la notazione () come riferimento ai paesi con un insieme ridotto di canali disponibili, le diverse sequenze definite dallo standard Bluetooth sono:

• Page hopping sequence: costituita da 32 (16) diverse frequenze scelte fra le 79 disponibili. Questa sequenza è periodica e il periodo è proprio 32 (16).
• Page response sequence: costituita da 32 (16) frequenze in corrispondenza biunivoca con quelle della page hopping sequence.
• Inquiry sequence: costituita da 32 (16) frequenze scelte fra le 79 disponibili. Questa sequenza è periodica e il periodo è proprio 32 (16).
• Inquiry sequence: costituita da 32 (16) frequenze in corrispondenza biunivoca con quelle della inquiry hopping sequence.
• Channel hopping sequence: sequenza utilizzata nello stato Connection, costituita da 79 (23) frequenze distribuite nella banda disponibile.

3.4.3  Schema generale per la generazione delle sequenze di hopping

In generale, lo schema di selezione consiste in due fasi:

• selezione di una sequenza
• mappatura della sequenza selezionata nelle frequenze

Gli ingressi sono il clock e l'indirizzo corrente. In particolare, nello stato connection, l'indirizzo è quello del master della piconet e anche il clock (CLKN) è il CLKN del master (CLK). Sempre in connection, vengono usati solo i 27 bit più significativi (MSB) del clock, mentre per i sottostati page e inquiry vengono usati tutti e 28 i bit. Inoltre, durante la fase di page, viene usato il clock stimato(CLKE). L'indirizzo usato è composto da 28 bit che comprendono sia l'intero UAP che l'intero LAP³⁶; in connection viene usato l'indirizzo del master, in page viene usato l'indirizzo dello slave sottoposto alla procedura di page e in inquiry viene usato il GIAC³⁷ per generare i campi UAP e LAP. L'uscita è una sequenza pseudocasuale di 79 (23) frequenze disponibili.
Per i sistemi che utilizzano l'intero insieme delle frequenze disponibili (79), il meccanismo di selezione sceglie un "segmento" di 32 frequenze di hopping che coprono una banda di circa 64Mhz e le utilizza in ordine casuale. In seguito viene scelto un altro segmento da 32 frequenze di hop e il processo continua. Nei sottostati page, page scan, page response viene usato sempre lo stesso segmento da 32 frequenze di hop³⁸. Il segmento viene scelto tramite l'indirizzo, quindi unità diverse avranno segmenti diversi. Possiamo vedere il meccanismo appena descritto nella figura seguente (gli ingressi saranno definiti volta per volta, per la varie fasi):

Selection Kernel

Il selection kernel è il sistema che realizza il meccanismo di selezione. La figura seguente rappresenta lo schema a blocchi per i sistemi che usano sequenze di 79 hop.³⁹

3.4.4  Standby

Questo è lo stato di "`default"' per un dispositivo Bluetooth. Quest'ultimo risulta inattivo, non viene scambiato alcun tipo di dati e la sezione radio è spenta; solo il contatore che realizza il native clock è attivo. Questo stato è usato di solito per realizzare un funzionamento a basso consumo di potenza (low-power mode).

Procedura di inquiry

Questa procedura, realizzata tramite i sottostati inquiry, inquiry scan e inquiry response, viene definita dallo standard Bluetooth per consentire applicazioni in cui l'unità sorgente non conosce l'indirizzo dell'unità destinataria. Un'applicazione possibile è, come abbiamo detto precedentemente, la scoperta di altri dispositivi Bluetooth nel proprio raggio di trasmissione/ricezione. Durante la fase di inquiry, l'unità che compie tale fase raccoglie i BD_ADDR e i clock attuali di tutte le unità che le rispondono, ovvero quelle che contemporaneamente si trovano nella fase di inquiry scan; infatti la fase di inquiry scan è la fase corrispondente usata da un dispositivo Bluetooth che intende farsi scoprire. Successivamente, l'unità che ha concluso con successo la procedura di inquiry, può decidere di creare una o più nuove connessioni con le unità scoperte, utilizzando la procedura di page che vedremo in seguito.
Un'unità che vuole scoprire altre unità Bluetooth entra dunque nel sottostato inquiry, durante il quale trasmette ripetutamente il messaggio di inquiry; tale messaggio non contiene alcuna informazione sull'unità che lo sta inviando ed è costituito da un pacchetto ID il cui access code è pari al valore GIAC⁴⁰. La trasmissione dei suddetti pacchetti avviene usando diverse frequenze in accordo alla sequenza di inquiry precedentemente definita⁴¹. Un'unità che vuole farsi scoprire, al contrario, entra nel sottostato inquiry scan per rispondere ad eventuali messaggi di inquiry. La risposta ai messaggi di inquiry è opzionale, ovvero un'unità Bluetooth non è costretta a rispondere ai messaggi di inquiry. Descriveremo ora lo scambio dei messaggi durante questa procedura e la soluzione al problema delle collisioni nella risposta ai messaggi di inquiry.

3.4.5  Inquiry scan

Nel sottostato inquiry scan un'unità Bluetooth ascolta i pacchetti trasmessi sul canale alla ricerca di messaggi di inquiry. La durata della fase di scan è indicata come T_{w\textunderscore inquiry\textunderscore scan}, ed è sufficiente a coprire 16 frequenze di inquiry (circa 20s). Quando un'unità entra nel sottostato inquiry scan, essa seleziona una frequenza per lo scan in accordo alla inquiry hopping sequence.

La sequenza sarà generata tramite il GIAC e un altro parametro detto DCI (default check initialization) che vale 0x00: infatti gli ingressi A₂₇₋₂₄ sono proprio i 4 LSB del DCI, mentre i rimanenti bit dell'ingresso A sono il LAP del GIAC. La fase nella sequenza è determinata dall'ingresso X e quindi, come si vede dalla tabella, tale fase cambia ogni 1.28s, ovvero ogni 1.28s viene selezionata una nuova frequenza di scan. L'inquiry hopping sequence è divisa in due insiemi di frequenze, che Bluetooth chiama "treni", A e B costituiti da 16 frequenze ciascuno. Se viene ricevuto un messaggio di inquiry durante il periodo T_{w\textunderscore inquiry\textunderscore scan}, l'unità compie un backoff⁴² portandosi in connection o in standby prima di entrare ancora nel sottostato inquiry scan. La durata del backoff è determinata in maniera casuale e può variare da 1 a 1023 slot (circa 0.64s). Dopo aver effettuato tale backoff, l'unità entra nel sottostato inquiry response. Il sottostato inquiry scan può essere raggiunto sia dallo stato standby che dallo stato connection. Nel primo caso, non vi sono connessioni attive cosicché l'unità può sfruttare tutta la capacità⁴³ del canale per effettuare l'inquiry scan. Nel caso in cui l'unità si trovi nello stato connection e voglia effettuare una procedura di inquiry scan, può ottenere una capacità maggiore utilizzando delle modalità speciali in cui possono essere posti i link ACL e che vedremo in seguito. Nel caso siano presenti dei link SCO, questi ultimi hanno priorità sulle procedure di inquiry. Saranno comunque utilizzati i pacchetti SCO con la minore occupazione di banda (HV3). Sempre in questo caso, è opportuno che il dispositivo aumenti la dimensione di T_{w\textunderscore inquiry\textunderscore scan}, per aumentare la probabilità di rispondere ad un messaggio di inquiry. In termini quantitativi, se è presente un solo link SCO con pacchetti HV3 e T_SCO=6slot, Bluetooth raccomanda una finestra di scan (T_{w\textunderscore inquiry\textunderscore scan}) di almeno 36 slot (22.5ms); se sono presenti 2 link SCO con pacchetti HV3 e T_SCO=6slot, Bluetooth raccomanda invece una finestra di scan di almeno 54 slot (33.75ms).

Bluetooth definisce inoltre T_inquiryscan, l'intervallo di tempo che intercorre tra due periodi (finestre) consecutivi di inquiry scan. Questo T_inquiryscan dovrà essere al massimo 2,56s.

3.4.6  Inquiry

Il sottostato inquiry viene usato quando un'unità vuole scoprire nuovi dispositivi. Osserviamo la seguente figura:

Le frequenze TX e RX seguono rispettivamente la sequenza inquiry hopping sequence e inquiry response sequence. Queste sequenze vengono determinate sempre a partire dal GIAC e dal CLKN dell'unità che compie l'inquiry. Osserviamo la seguente tabella:

L'ingresso X è definito così:

Xi(79)=[CLKN16−12+koffset+(CLKN4−2,0−CLKN16−12)mod16]mod32

(3.1)

Come si vede dalla figura 3.19, in ogni slot TX il master trasmetterà in sequenza su due frequenze di hop. Ciò è possibile poichè il messaggio di inquiry è costituito dal solo pacchetto ID (68 bit) e quindi il sintetizzatore di frequenze ha almeno 224μs per cambiare la frequenza. Nello slot RX seguente, il master ascolterà in sequenza su due frequenze selezionate in accordo alla inquiry response sequence. Quest'ultima sequenza è strettamente correlata alla inquiry hopping sequence: per ogni hop della inquiry hopping sequence vi è un corrispondente hop della inquiry response sequence. In questo sottostato, per permettere la trasmissione di due pacchetti per ogni TX slot, l'hop-rate del sintetizzatore viene esattamente raddoppiato, passando dai 1600 hops/s a 3200 hops/s. Le risposte ai messaggi di inquiry sono costituite da pacchetti FHS. Una volta ricevuta una risposta, essa viene letta dopodiché l'unità continua il processo di inquiry. Quindi, un'unità in fase di inquiry non comunica la ricezione di una risposta all'unità in inquiry scan che ha inviato la risposta stessa. Anche per la fase di inquiry vengono definiti i due treni, A e B. Ognuno di questi treni ha una durata di 10ms⁴⁴ e un singolo treno dev'essere ripetuto per N_inquiry=256 volte prima di poter passare alla scansione delle frequenze dell'altro treno.

La procedura di inquiry prosegue fino all'arresto da parte del LM (quando decide di aver raccolto un numero sufficiente di risposte) oppure quando viene esaurito un time-out (inquiryTO). Il sottostato inquiry può essere raggiunto sia dallo stato standby che dallo stato connection. Nel primo caso, non vi sono connessioni attive cosicché l'unità può sfruttare tutta la capacità del canale per effettuare l'inquiry. Nel caso in cui l'unità si trovi nello stato connection, essa deve guadagnare la massima capacità possibile per effettuare l'inquiry. Viene espressamente raccomandato di utilizzare alcune modalità speciali per le connessioni ACL (come già accennato nel caso dell'inquiry scan). Anche in questo caso, eventuali link SCO hanno priorità sull'inquiry. Per guadagnare comunque una capacità sufficiente per l'inquiry, è consigliabile utilizzare pacchetti SCO di tipo HV3. A seconda del numero di link SCO presenti, si dovrà anche aumentare N_inquiry.

3.4.7  Inquiry response

La procedura di inquiry prevede una risposta solo da parte dello slave. Il master manda infatti i messaggi di inquiry e nel frattempo ascolta per ricevere risposta, ma dopo la lettura delle risposte continua a trasmettere messaggi di inquiry. Quando uno slave che si trova in inquiry scan riceve un messaggio di inquiry, esso restituisce in risposta un pacchetto FHS contenente i propri parametri. A questo punto, le specifiche Bluetooth prevedono una procedura di back-off che l'unità in inquiry scan deve effettuare prima di inviare la risposta al master; questo per evitare un classico problema di collisione. Infatti, il processo di inquiry non è direttamente indirizzato ad un particolare slave, e così può accadere che due o più slave si trovino contemporaneamente in inquiry scan e quindi possano potenzialmente rispondere entrambi ai messaggi di inquiry di un master nel loro range. Ovviamente tale possibilità è abbastanza remota: due slave dovrebbero essere in inquiry scan nello stesso momento e, per di più, dovrebbero essere in ascolto sulla stessa frequenza nello stesso momento. Ricordiamo che la fase nella inquiry hopping sequence è determinata del CLKN dell'unità, ovvero la frequenza iniziale di inquiry scan, nonché il treno cui questa frequenza appartiene, viene determinata dal valore di CLKN nel momento in cui si attiva l'inquiry scan. I CLKN di due unità non sincronizzate sono in genere diversi e quindi è difficile che si possa verificare un evento favorevole alla collisione suddetta. Comunque, al fine di evitare la collisione, viene effettuato il seguente processo:

• Se uno slave in inquiry scan riceve un messaggio di inquiry, seleziona un numero casuale RAND compreso tra 0 e 1023.
• Lo slave ritorna in connection o standby per un numero di slot pari a RAND (quindi dopo un tempo compreso tra 0 e 0.64s).
• Dopo questo back-off, lo slave ritorna nel sottostato inquiry scan. Se riceve ancora un altro messaggio di inquiry, esso passa nel sottostato inquiry response e invia un pacchetto FHS⁴⁵ esattamente 625μs dopo aver ricevuto il messaggio di inquiry.

Se al rientro dal back-off non viene rilevato un nuovo messaggio di inquiry per un tempo pari a inqrespTO⁴⁶, lo slave ritorna in standby o in connection. Se invece esso riceve un messaggio di inquiry e invia in risposta il pacchetto FHS, aggiunge 1 alla fase della inquiry hopping sequence e rientra nel sottostato inquiry scan. Se viene ricevuto un nuovo messaggio di inquiry, la procedura viene ripetuta, back-off compreso (il valore RAND verrà ricalcolato).

Eventuali link SCO hanno la priorità, cioè se la risposta (FHS) ad un inquiry si sovrappone ad uno slot SCO, essa non viene mandata ma si aspetta la ricezione di un altro messaggio di inquiry. Per ciò che riguarda la generazione della sequenza di hopping utilizzata nel sottostato inquiry response osserviamo la seguente tabella:

L'ingresso X è così definito:

Xir(79)=[CLKN16−12+N]mod32

(3.2)

Il valore di N viene incrementato dopo ogni trasmissione di un pacchetto FHS in risposta ad un inquiry. Non vi sono restrizioni al valore iniziale di N. Per quel che riguarda gli ingressi A, vengono ricavati a partire dal LAP del GIAC e dai 4 bit meno significativi(LSB) del DCI(A₂₇₋₂₄).

Osserviamo ora una figura che riassume lo scambio di messaggi durante la procedura di inquiry:

Nella figura seguente invece, viene visualizzata la procedura di inquiry nel dominio del tempo.

Procedura di Page

Con la procedura di page viene stabilita una connessione. Per stabilire tale connessione è necessario conoscere solo il BD_ADDR del destinatario, mentre la conoscenza del CLKN del destinatario è utile per accelerare la procedura di page. Un'unità che stabilisce una connessione, attraverso la procedura di page, diviene automaticamente il master della connessione. Il processo di page può seguire diversi "schemi" di paging. Bluetooth definisce uno schema di paging obbligatorio, ovvero che dev'essere implementato da tutti i dispositivi compatibili Bluetooth. Questo schema è usato quando due unità Bluetooth si incontrano per la prima volta e prevede che il processo di page segua immediatamente il processo di inquiry. Due unità, una volta connesse, possono mettersi d'accordo decidendo di adottare uno schema di paging diverso. Considereremo solo lo schema di paging obbligatorio.

3.4.8  Page scan

Nel sottostato page scan, un'unità Bluetooth ascolta il canale alla ricerca di pacchetti di page ad esso indirizzati, ovvero pacchetti ID il cui access code è uguale al proprio DAC. La durata del periodo di scan è indicata con T_wpagescan e sarà sufficiente a coprire 16 frequenze di page, cioè circa 20 secondi. Quando un'unità entra nel sottostato page scan, essa seleziona una frequenza per lo scan in accordo alla page hopping sequence.

La sequenza sarà generata a partire dal BD_ADDR dell'unità (ingressi A nella tabella precedente). La fase nella sequenza è determinata dai bit CLKN₁₆₋₁₂ (ove CLKN è il clock nativo dell'unità che compie lo scan) e quindi tale fase cambia ogni 1.28s, ovvero ogni 1.28s viene selezionata una nuova frequenza di scan.

Il sottostato page scan può essere raggiunto sia dallo stato standby che dallo stato connection. Nel primo caso, non vi sono connessioni attive cosicché l'unità può sfruttare tutta la capacità del canale per effettuare il page scan. Nel caso in cui l'unità si trovasse nello stato connection e volesse effettuare una procedura di page scan, può ottenere una capacità maggiore utilizzando delle modalità speciali in cui possono essere posti i link ACL. Nel caso siano presenti dei link SCO, questi ultimi hanno priorità sulle procedure di page scan. Saranno comunque utilizzati i pacchetti SCO con la minore occupazione di banda (HV3). Sempre in questo caso, è opportuno che il dispositivo aumenti la dimensione di T_{w\textunderscore page\textunderscore scan}, per aumentare la probabilità di rispondere ad un messaggio di page. In termini quantitativi, se è presente un solo link SCO con pacchetti HV3 e T_SCO=6slot, Bluetooth raccomanda una finestra di scan di almeno 36 slot (22.5ms); se sono presenti 2 link SCO con pacchetti HV3 e T_SCO=6slot, Bluetooth raccomanda invece una finestra di scan di almeno 54 slot (33.75ms).

Bluetooth definisce inoltre T_pagescan, l'intervallo di tempo che intercorre tra due periodi (finestre) consecutivi di page scan. Le specifiche Bluetooth prevedono 3 tipi di scan in relazione proprio al valore assunto da T_pagescan. Queste 3 possibilità determineranno anche il comportamento dell'unità che realizzerà un page verso questa unità in page scan. Osserviamo a questo proposito la seguente tabella:

Come si vede dalla tabella 3.13, le modalità di page scan sono distinte in base al valore di T_pagescan, che può essere esattamente uguale a T_{w\textunderscore page\textunderscore scan}, nel qual caso lo scan risulta continuo, oppure T_pagescan può essere minore o uguale a 1,28s o 2,56s. Sempre dalla tabella osserviamo che il valore di T_pagescan influenza il comportamento dell'unità che vorrà effettuare una procedura di page diretta verso l'unità che risulta in page scan, nel senso che a seconda della durata di T_pagescan andrà aggiustato il valore N_page ovvero il numero delle ripetizioni relative alle trasmissioni dei messaggi di page usando le frequenze dei due treni A e B. L'informazione sul valore di T_pagescan viene inviata anch'essa nel pacchetto FHS⁴⁷.

3.4.9  Page

Il sottostato page è usato dal master (sorgente della connessione) per creare una connessione verso uno specifico slave (destinatario della connessione), il quale periodicamente si porta nel sottostato page scan per ricevere richieste di connessione. Il master tenta di raggiungere lo slave trasmettendo ripetutamente e su diversi canali pacchetti ID il cui access code è pari al DAC dello slave. Per realizzare tale procedura, per prima cosa il master usa il BD_ADDR dello slave che vuole raggiungere per ricavare la page hopping sequence, che sarà usata dallo slave quando entrerà nel sottostato page scan⁴⁸. Per quel che riguarda la fase nella suddetta frequenza, il master usa una stima del clock dello slave (CLKE) per fare una previsione sulla frequenza alla quale lo slave destinatario inizierà la fase di page scan. Per la temporizzazione TX/RX dei messaggi di page si può far riferimento alla figura 3.19. In maniera simile a quanto visto per la fase di inquiry, in ogni slot TX il master trasmetterà in sequenza su due frequenze di hop. Ciò è possibile poichè il messaggio di page è costituito dal solo pacchetto ID (68 bit) e quindi il sintetizzatore di frequenze ha almeno 224μs per cambiare la frequenza. Nello slot RX seguente, il master ascolterà in sequenza su due frequenze selezionate in accordo alla page response hopping sequence. Quest'ultima sequenza è strettamente correlata alla page hopping sequence: per ogni hop della page hopping sequence vi è un corrispondente hop della page response hopping sequence. In questo sottostato, per permettere la trasmissione di due pacchetti per ogni TX slot, l'hop-rate del sintetizzatore viene raddoppiato, passando dai 1600 hops/s a 3200 hops/s.

Inoltre, come abbiamo visto per tutte le fasi precedenti, anche per la fase di page le 32 frequenze dedicate della page hopping sequence vengono divise in due treni A e B da 16 frequenze ciascuno. Osserviamo la seguente tabella:

L'ingresso X è così definito:

Xp(79)=[CLKE16−12+koffset+(CLKE4−2,0−CLKE16−12)mod16]mod32

(3.3)

Nel sottostato page il master inizierà la trasmissione dei messaggi di page usando le frequenze del treno A così definite:

{ f(k−8),...,f(k),...,f(k−7)}

(3.4)

dove f(k) è la frequenza, stimata dal master in base alle informazioni su quel particolare slave ottenute durante la fase di inquiry, alla quale l'unità in page scan dovrebbe iniziare lo scan. L'indice k dipende da tutti gli ingressi descritti nella tabella 3.14. Quando la differenza tra il clock del master e quello dello slave è compresa tra −8·1.28s=10.24s e +7·1.28s=8.96s, allora una delle frequenze definite in (3.4) sarà sicuramente la frequenza su cui lo slave in page scan sta ascoltando. Comunque, visto che il master non può sapere in quale momento lo slave entrerà nella fase di page scan, esso sarà costretto a ripetere la trasmissione dei messaggi di page sulle frequenze del treno A per N_page volte o fino a quando non viene ricevuta una risposta. Come abbiamo visto dalla tabella 3.13, N_page dipenderà dalla modalità di scan posseduta dallo slave che il master intende raggiungere. Quando invece la differenza tra il clock del master e quello dello slave è minore di −8·1.28s oppure maggiore di +7·1.28s, allora è necessario utilizzare le frequenze del treno B.

{ f(k−16),f(k−15),...,f(k−9),f(k−8),...,f(k−15)}

(3.5)

Anche il treno B viene ripetuto N_page volte. Se non viene rilevata una risposta, si ritorna ad utilizzare le frequenze del treno A per N_page volte e così via. L'uso in alternanza delle frequenze dei 2 treni continua finché non si riceve una risposta oppure non scade il time-out pageTO. Se invece viene ricevuta una risposta, il master passa nella fase master response.

Il sottostato page può essere raggiunto sia dallo stato standby che dallo stato connection. Nel primo caso, non vi sono connessioni attive cosicché l'unità può sfruttare tutta la capacità del canale per effettuare il page. Nel caso in cui l'unità si trovasse nello stato connection e volesse effettuare una procedura di page, può ottenere una capacità maggiore utilizzando delle modalità speciali in cui possono essere posti i link ACL. Nel caso siano presenti dei link SCO, questi ultimi hanno priorità sulle procedure di page. Saranno comunque utilizzati i pacchetti SCO con la minore occupazione di banda (HV3). Sarà inoltre necessario modificare opportunamente il valore N_page. Le specifiche Bluetooth consigliano i seguenti valori per N_page:

Procedura di Page response

Quando uno slave in stato di page scan riceve un messaggio di page da un master, inizia una procedura per la sincronizzazione tra il master e lo slave. Entrambe le suddette unità Bluetooth compiono una procedura di risposta (master response e slave response) per scambiarsi informazioni utili per continuare nella realizzazione della connessione vera e propria. La figura 3.22 riassume i passi compiuti dalle due unità coinvolte nel page response e che verranno esaminati in dettaglio nei paragrafi seguenti.

Nella figura 3.23 invece troviamo la temporizzazione dei messaggi usati per compiere i passi appena visti.

3.4.10  Slave response

Dopo aver ricevuto il messaggio di page (pacchetto ID con il proprio DAC), lo slave risponde con un pacchetto ID identico. Questa risposta avviene 625μs dopo la ricezione del messaggio del master, usando una frequenza appartenente alla page response sequence e collegata direttamente alla frequenza alla quale era stato trasmesso dal master il messaggio di page. Come si vede dalla figura 3.22, dopo aver mandato il messaggio di risposta, lo slave attiva il proprio ricevitore e aspetta l'arrivo del pacchetto FHS che conterrà i parametri caratteristici del master (BD_ADDR da cui ricavare la channel hopping sequence, il CLKN del master ecc.). Se quest'ultimo pacchetto viene inviato e ricevuto con successo dallo slave, lo slave stesso invia come risposta un pacchetto ID contente il proprio DAC, per confermare al master l'avvenuta ricezione del pacchetto FHS; tale risposta avviene sempre usando la page response hopping sequence. Dopo l'invio della suddetta risposta il transceiver dello slave si sincronizza sulla channel hopping sequence e quindi finalmente lo slave si porta nello stato connection. La modalità connection viene 'inaugurata' da un pacchetto POLL inviato dal master, cui lo slave può rispondere con un pacchetto qualsiasi (tipicamente si usa un pacchetto NULL). Questo è ciò che succede se la procedura di setup della connessione va a buon fine. Se il pacchetto POLL non viene ricevuto dallo slave oppure se il master non riceve il pacchetto di risposta al proprio POLL, dopo un numero di slot pari a newconnectionTO dopo la conferma dell'avvenuta ricezione del pacchetto FHS, il master e lo slave torneranno nei sottostati page e page scan rispettivamente. Può accadere anche che lo slave non riceva il pacchetto FHS del master; in questo caso esso continua ad ascoltare il canale secondo le frequenze della page response hopping sequence fino a che non riceve appunto il pacchetto FHS oppure non scade il timeout pagerespTO. In quest'ultimo caso viene concessa un'unlteriore possibilità per realizzare la connessione poichè lo slave ritorna nel sottostato page scan per un tempo pari a T_wpagescan. Se non viene ricevuto alcun messaggio di page durante quest'ulteriore periodo di page scan, lo slave ritorna nello stato in cui si trovava prima di entrare nella prima fase di page scan e riprenderà la sua politica periodica di page scan.

Per ciò che riguarda la generazione della sequenza di hopping, osserviamo la seguente tabella:

L'ingresso X è così definito:

Xprs(79)=[CLKN16−12*+N]mod32

(3.6)

Per evitare di perdere l'aggancio appena effettuato con il master a causa delle differenze tra il CLKN dello slave e il valore CLKE stimato dal master, il valore dei bit CLKN₁₆₋₁₂ dev'essere registrato nel momento in cui viene ricevuto il messaggio di page e poi mantenuto solamente per quel che riguarda la generazione degli ingressi al selection kernel. L'asterisco in 3.6 indica proprio che i 4 bit CLKN₁₆₋₁₂ vengono registrati e mantenuti. L'espressione 3.6 rappresenta il valore che l'ingresso X assume nello slot (N+1)-esimo dopo la ricezione del messaggio di page. Il contatore N viene posto a 0 quando lo slave risponde per confermare l'avvenuta ricezione del messaggio di page. Dopodiché il valore di N viene incrementato di uno ogni volta che CLKN₁diventa 0 (ovvero ogni volta che inizia uno slot TX del master). L'ingresso X viene costruito secondo 3.6 fino a che non viene inviato con successo il pacchetto FHS e la relativa risposta da parte dello slave. Dopodiché lo slave entra nello stato connection, nel quale si usa una diversa tabella degli ingressi al selection kernel.

3.4.11  Master response

Quando il master riceve una risposta al proprio messaggio di page, entra nel sottostato master response. Per cominciare, invia un pacchetto FHS, contenente tra l'altro il proprio BD_ADDR e il proprio CLKN. Dopo la trasmissione del suddetto pacchetto FHS, il master aspetta una seconda risposta da parte dello slave, a conferma dell'avvenuta ricezione del pacchetto FHS. Ancora una volta la suddetta risposta consiste in un pacchetto ID con il DAC dello slave indirizzato. Se questa risposta non arriva, il master ritrasmette il pacchetto FHS, con il clock CLKN aggiornato al valore attuale; la ritrasmissione continua usando sempre la page hopping sequence finché non arriva una risposta oppure non scade il timeout pagerespTO. In quest'ultimo caso, il master ritorna nel sottostato page scan e segnala l'errore al LM. Se invece viene ricevuta la risposta dello slave all'invio del pacchetto FHS, il transceiver del master si porta sulla channel hopping sequence e invia allo slave un pacchetto POLL. Anche questa trasmissione richiede una conferma da parte dello slave, risposta che deve arrivare nella forma di un pacchetto qualsiasi (tipicamente un pacchetto NULL) entro un numero di slot pari a newconnectionTO altrimenti il master tornerà nel sottostato page e lo slave nel sottostato page scan.

Per ciò che riguarda la generazione della sequenza di hopping, osserviamo la seguente tabella:

L'ingresso X è così definito:

Xprm(79)=[CLKE16−12*+koffset*+(CLKE4−2,0*−CLKE16−12*)mod1+6N]mod32

(3.7)

Come abbiamo visto in 3.4.10, anche in questo caso il valore del CLKE viene registrato al momento della ricezione del pacchetto ID dello slave in risposta al messaggio di page, e poi viene mantenuto. Anche il valore di k_offset viene registrato e mantenuto. Il master calcolerà il valore dell'ingresso X allo stesso modo dello slave, ovvero incrementando il contatore di uno ogni volta che il valore CLKE₁ viene posto a 0 (inizio di uno slot TX del master). Il primo incremento dev'essere fatto prima di mandare il pacchetto FHS.

3.4.12  Connection

In questo stato la connessione tra master e slave è stata stabilita e le due unità possono scambiarsi pacchetti. Entrambe le unità usano ora il CAC (channel access code), la channel hopping sequence e il CLKN del master (ora denominato CLK ad indicare che è comune alle unità della piconet). Il master inizia le proprie trasmissioni negli slot pari (CLK₁₋₀=00), lo slave inizia le proprie trasmissioni negli slot dispari (CLK₁₋₀=10). Osserviamo di seguito la tabella degli ingressi al selection kernel:

I primi pacchetti scambiati all'inizio dello stato connection sono messaggi di controllo che contengono informazioni essenziali che caratterizzano il collegamento appena realizzato e informazioni aggiuntive sulle unità Bluetooth coinvolte (ad esempio vengono definiti eventuali link SCO e altri parametri). Dopo questo scambio di informazioni utili, il trasferimento vero e proprio dei dati può finalmente cominciare.

Lo stato connection può essere abbandonato tramite i comandi detach e reset. La connessione tra due unità Bluetooth può essere terminata in qualsiasi momento da entrambe le parti. Il comando detach serve proprio a questo scopo; i parametri di configurazione della connessione che viene terminata vengono comunque mantenuti. Il comando reset invece è un hard reset di tutti i processi dell'host controller e del link manager. Dopo un comando reset, tutto il controller va riconfigurato.

Durante l'operazione in stato connection, un'unità Bluetooth può assumere diverse modalità operative: hold mode, sniff mode, active mode, park mode. Esaminiamo ora in dettaglio queste modalità.

3.4.13  Connection-Active mode

In active mode, l'unità Bluetooth partecipa attivamente alla piconet. Il master programma le trasmissioni in base alle richieste di traffico da e verso gli slave. In più esso realizza delle trasmissioni su base periodica per consentire agli slave di rimanere sincronizzati⁴⁹. Gli slave in active mode ascoltano il canale negli slot "master-to-slave" (i già citati TX slot del master). Usando il campo "type" (vedi pagina pageref), gli slave indirizzati possono conoscere quanti slot sono stati riservati dal master per la trasmissione del messaggio e rimanere attivi di conseguenza. Gli slave non indirizzati possono a loro volta entrare in "sleep" ovvero deferire l'ascolto del canale per tutta la durata del messaggio.

3.4.14  Connection-Hold mode

Durante lo stato connection, un link ACL verso uno slave può essere messo in modalità hold⁵⁰. Questo vuol dire che quello slave, temporaneamente, non supporterà l'invio e la ricezione di pacchetti ACL, mentre potrà comunque supportare eventuali link SCO. Questa modalità è utile per risolvere i problemi di capacità in termini di banda disponibile sul canale, già citati in relazione alle fasi di inquiry e page. Quindi un'unità Bluetooth può usare la modalità hold per fermare temporaneamente il trasferimento dei dati su un link ACL in modo da riservare capacità per inquiry, page, scan o passare ad operare in altra piconet. L'unità in modalità hold può anche entrare in uno stato a basso consumo di potenza (low power) e inoltre essa manterrà il proprio AM_ADDR. Le specifiche Bluetooth definiscono 3 modi per utilizzare la modalità hold; questi 3 modi vengono gestiti da 2 comandi LMP (link manager protocol):

Il parametro hold time specifica quanto tempo dovrà durare l'hold per quel link ACL, mentre il parametro hold instant specifica quando dovrà iniziare l'hold per quel link ACL.

3.4.15  Connection-Sniff mode

Con questa modalità si può ridurre il ciclo di operatività di uno slave relativamente alla sua attività di ascolto del canale. In condizioni standard, se uno slave possiede un link ACL attivo, deve mettersi in ascolto sul canale in tutti gli slot TX del master per ricevere eventuali pacchetti. Con la modalità sniff, possiamo ridurre il numero di slot che il master può utilizzare per trasmettere pacchetti ad uno slave specifico (quello in modalità sniff). In pratica il master è costretto a iniziare la trasmissione dei messaggi verso lo slave in modalità sniff solo in alcuni slot dedicati, detti sniff slots. Questi slot si ripetono periodicamente ad intervalli di T_sniff. Osserviamo la seguente figura:

Il master e lo slave si metteranno d'accordo sia sull'"offset" (vedi figura), ovvero l'inizio del primo sniff slot, che sul T_sniff. Il parametro N_{sniff attempt} indica la finestra temporale (espressa in numero di slot) durante la quale lo slave in modalità sniff sarà in ascolto per eventuali trasmissioni da parte del master. Anche quest'ultimo parametro andrà negoziato tra master e slave⁵¹.

Lo slave in modalità sniff , una volta iniziata la finestra di sniff, ascolterà il canale per un numero di slot RX (TX del master) pari a N_{sniff attempt}. Se durante questi slot esso non viene indirizzato (ovvero non decodifica alcun pacchetto con il proprio AM_ADDR), smette di ascoltare il canale. Se al contrario, viene ricevuto un pacchetto con il proprio AM_ADDR, alla fine degli slot previsti dal parametro N_{sniff attempt}, lo slave rimarrà in ascolto per un numero di slot pari a N_{sniff timeout}, in attesa di altri dati ad esso indirizzati. Possiamo osservare che, data la non completa affidabilità del collegamento radio Bluetooth, la finestra definita in base a N_{sniff attempt} dovrebbe avere dimensioni tali da permettere al master di ritentare le trasmissioni verso uno slave in modalità sniff. Inoltre possiamo osservare il caso estremo in cui il valore N_{sniff timeout} è tale da riempire l'intero T_sniff, ovvero, una volta che uno slave ha ricevuto un pacchetto durante gli sniff slot (N_{sniff attempt}), continuerà ad ascoltare per l'intera durata dello sniff interval⁵².

La gestione della modalità sniff avviene tramite i comandi LMP riassunti nella seguente tabella:

Inoltre, anche in questo caso vi possono essere diverse possibilità per entrare ed uscire dalla modalità sniff.

3.4.16  Connection-Park mode

La modalità park è utile quando uno slave non vuole partecipare attivamente alla piconet, ma vuole comunque rimanere sincronizzato al canale. La modalità park prevede una attività molto bassa e quindi riduce notevolmente il consumo di potenza. Quando uno slave decide di portarsi in modalità park, rinuncia al proprio AM_ADDR e ottiene altri 2 indirizzi, entrambi di 8 bit:

• PM_ADDR: parked member address
• AR_ADDR: access request address

Il PM_ADDR distingue uno slave "parked"⁵³ da un altro. Quest'indirizzo viene usato durante la procedura di "unparking" (uscita dalla modalità park) iniziata dal master. Vi è la possibilità che un'unità in modalità park abbia l'indirizzo PM_ADDR uguale a 0 (tutti i bit 0): quest'indirizzo è riservato e l'uscita dalla modalità park viene in quel caso effetuata usando il BD_ADDR del dispositivo Bluetooth. L'indirizzo AR_ADDR viene invece usato durante la procedura di unparking iniziata dallo slave. Poichè gli slave in modalità park non posseggono un AM_ADDR, tutto i pacchetti diretti verso di essi saranno dei pacchetti broadcast (vedi pagina pageref).

Ad intervalli regolari, uno slave in modalità park si attiva per risincronizzarsi e ascoltare il canale per ricevere eventuali pacchetti broadcast. Questo processo viene supportato dal master che fornisce il cosiddetto beacon channel⁵⁴ che verrà descritto nel prossimo paragrafo. La struttura dei beacon verrà comunicata allo slave all'inizio della fase di park e, se dovesse cambiare, il master si occuperà di comunicare i cambiamenti mediante opportuni pacchetti broadcast inviati agli slave in modalità park.

Come abbiamo già visto⁵⁵, la modalità park può essere usata per connettere più di 7 slave ad un master.

Struttura generale del beacon channel

Quando uno o più slave passano in modalità park, il master costruisce un cosiddetto "beacon channel" per supportare i suddetti slave.

Come si può vedere dalla figura 3.26, il beacon channel è costituito da un beacon slot o da un treno di beacon slot equidistanti, ripetuti con un periodo costante. Il valore T_B rappresenta il beacon interval ovvero il periodo con cui si ripetono i beacon slot. Questi ultimi sono in numero N_B (N_B ≥ 1) e sono spaziati di ∆_B. L'inizio del primo beacon slot del treno è chiamato beacon instant e serve da riferimento per la temporizzazione del beacon channel. T_B e N_B andranno scelti opportunamente in modo da permettere ad uno slave in modalità park di sincronizzarsi anche in un ambiente con interferenze. I comandi LMP usati per gestire tale modalità sono riassunti nella seguente tabella:

Il beacon channel serve essenzialmente per:

• trasmissione di pacchetti speciali che gli slave in modalità park possono usare per risincronizzarsi.
• trasmissione di messaggi verso gli slave in modalità park per comunicare eventuali cambiamenti nella struttura del beacon channel.
• invio di pacchetti broadcast generali verso gli slave in modalità park.
• realizzare procedure di unparking di uno o più slave in modalità park.

E' importante notare che anche nel caso del beacon channel, eventuali link SCO hanno la precedenza, per cui la trasmissione dei beacon potrebbe essere interrotta.

Beacon access windows

Vengono definite, sempre nel contesto del beacon channel, delle access window, nelle quali gli slave in modalità park possono richiedere di uscire dalla stessa modalità. Per aumentare l'affidabilità di questa procedura, le access window possono essere ripetute M_access volte (M_access ≥ 1).

Come si vede dalla figura 3.27, la serie delle access window inizia D_access dopo il beacon instant e la durata delle singole access window è indicata con T_access. All'interno di queste access window, l'accesso agli slave avviene con una tecnica di polling:

Come si vede dalla figura 3.28, viene usato uno schema TDM simile a quello usato nel canale della piconet, ovvero trasmissioni master-to-slave si alternano a trasmissioni slave-to-master. Gli slot slave-to-master sono divisi in 2 mezzi slot da 312.5μs ciascuno. In base all'indirizzo AR_ADDR, ogni slave ha il suo spazio per inviare una richiesta di unparking, però può farlo solo se nel precedente slot master-to-slave ha ricevuto un pacchetto broadcast. In questo senso il master effettua un polling (interrogazione) degli slave. Possiamo osservare la figura seguente:

Un eventuale link SCO può sovrapporsi alla ripetizione delle access windows e come si vede dalla figura, la presenza di un pacchetto SCO nello slot master-to-slave numero 2 (ovvero il terzo slot da sinistra), per prima cosa impone che anche lo slot successivo sia occupato da un pacchetto SCO (stavolta slave-to-master), e, in più, fa si che le eventuali richiesta di unparking degli slave con AR_ADDR pari a 3 e 4 non possano venire ascoltate (questo poiché come abbiamo detto, le richieste possono avvenire solo se nel precedente slot master-to-slave era stato inviato un pacchetto broadcast).

Inoltre uno slave in modalità park può decidere di non ascoltare tutti i beacon train forniti dal master. Come si può vedere dalla tabella 3.21, nel messaggio LMP_park_req sono inclusi i parametri N_Bsleep e D_Bsleep che indicano rispettivamente quanti beacon train lo slave salterà e a partire da quale istante. Possiamo comunque notare che, essendo il valore T_Bsleep espresso su 2 byte, il massimo intervallo tra due consecutivi beacon train è circa 41s⁵⁶; inoltre N_Bsleep è espresso su un byte e quindi uno slave può saltare fino a 255 beacon train consecutivi. Nel caso peggiore quindi uno slave potrebbe rimanere in modalità park senza ascoltare alcun beacon train per circa 2,9 ore e questo, considerando che in modalità park lo slave di solito è in low-power e quindi il suo CLKN subisce un drift rispetto al CLKN del master, potrebbe causare la totale perdita del sincronismo tra lo slave e il master. L'unico rimedio a questa situazione è una serie di unparking e parking occasionali dello slave.

3.4.17  Struttura e gestione di una Scatternet

Una scatternet Bluetooth è un gruppo di piconet interconnesse tra loro. Un master o uno slave in una piconet A può diventare uno slave in un'altra piconet B quando viene ad essere il destinatario di un page da parte del master della piconet B. Dall'altro lato, un'unità Bluetooth attiva in una piconet A può effettuare un page verso il master o uno slave di una piconet B: in questo caso poichè l'unità che effettua il page è sempre master, sarà richiesto uno "scambio di ruoli" (master-slave switch).

Affinché un'unità possa partecipare a più di una piconet, essa dovrà operare in time multiplexing. Nel caso in cui un'unità Bluetooth possegga soltanto dei link ACL, essa potrà richiedere di entrare in hold o park nella piconet corrente, dopodiché per tutta la durata dell'hold o park potrà essere attiva in un'altra piconet cambiando i parametri del canale. Anche la modalità sniff può risultare utile in quanto, negli intervalli di tempo tra gli sniff slot, si può passare ad operare in un'altra piconet. Se sono presenti link SCO, l'operatività in un altra piconet è possibile solo durante gli slot compresi tra quelli riservati a link SCO; ciò è possibile solo se il link SCO è realizzato tramite pacchetti HV3 (quelli con occupazione di banda minore) e anche in quest'eventualità, sono solo 2 gli slot disponibili per visitare un'altra piconet.

3.4.18  Scambio dei ruoli master-slave

Bluetooth consente ad una qualsiasi unità di richiedere uno scambio di ruoli rispetto ad un altra unità con la quale si sta comunicando. Il processo di scambio dei ruoli consiste in una serie di scambi di messaggi tra master e slave che possiamo osservare nella figura seguente:

3.5  Livelli superiori dello stack Bluetooth

Riguardando la figura 3.1, possiamo dire che i livelli Radio e Baseband rappresentano il livello fisico (PHY) nella reppresentazione a 7 livelli OSI/ISO.

• Il livello Link Manager si occupa della configurazione dei link ACL e SCO (inizializzazione, mantenimento, conclusione), autenticazione, sicurezza, QoS, controllo del consumo di potenza, scheduling delle trasmissioni. In assenza di un sistema HOST (HCI), fornisce il protocollo LMP, basato su una serie di comandi, che consente di controllare il livello baseband e quindi il MAC.
• HCI: Host Controlled Interface, fornisce un'interfaccia a comandi per i livelli Link Manager e Baseband. Rende inoltre accessibili i registri di stato e controllo. Tale interfaccia è stata prevista per fornire un metodo d'accesso comune alle capacità del livello Baseband, rendendo così più facile l'uso di hardware realizzato da costruttori diversi.
• Il livello L2CAP (Logical Link Control and Adaptation Layer) fornisce servizi connection oriented e connectionless ai livelli superiori. I suoi compiti includono multiplexing dei protocolli⁵⁷, segmentazione e riassemblaggio delle PDU (protocol data unit) provenienti dai livelli superiori e aventi dimensioni maggiori di 64KB, supporto QoS (quality of service). In particolare, per quest'ultima funzionalità, il livello L2CAP consente, al momento dell'instaurazione della connessione tra due dispositivi Bluetooth, lo scambio di informazioni riguardanti il livello QoS della connessione stessa. Inoltre L2CAP si occupa di fare rispettare quanto negoziato riguardo il QoS.
• RFCOMM è un protocollo usato per emulare le porte seriali RS232, utile perchè molte applicazioni già esistenti sono basate su una comunicazione seriale. Possono esistere fino a 60 connessioni contemporanee tra due dispositivi Bluetooth. RFCOMM è basato su un sottoinsieme di TS07.10⁵⁸ e può anche emulare un null-modem. Il Service Discovery Protocol (SDP) permette ai dispositivi mobili di scoprire quali servizi sono disponibili nelle loro vicinanze e le caratteristiche di tali servizi. Il protocollo SDP permette al client di cercare servizi con caratteristiche specifiche (rappresentate da un numero detto UUID), oppure di navigare tra i servizi offerti dal server. Il protocollo SDP fornisce dei mezzi per scoprire i servizi ma non per accedere a tali servizi.
• È possibile realizzare TCP/IP direttamente su L2CAP, ma attualmente, non sono ancora stati definiti dei profili per questa possibilità. La maggior parte delle implementazioni del TCP/IP sono basate su PPP realizzato su RFCOMM. La grande popolarità del protocollo TCP/IP sta comunque spingendo la ricerca per migliorarne le prestazioni sui link Bluetooth.

3.5.1  Sicurezza

Una nota di riguardo va sicuramente fatta in merito alla sicurezza dei dati trasmessi tramite un link Bluetooth. Bluetooth fornisce delle misure di sicurezza sia a livello di applicazione (application layer) che a livello di collegamento (link layer). Per quel che riguarda quest'ultimo livello vengono usate 4 diverse "entità" per gestire la sicurezza:

Quindi abbiamo un indirizzo pubblico (BD_ADDR), 2 chiavi segrete e un numero casuale (RAND) che è diverso per ogni transazione. Le chiavi segrete vengono derivate durante l'inizializzazione e non vengono più rivelate. Normalmente la chiave di cifratura (encryption key) viene derivata dalla chiave di autenticazione (authentication key) durante il processo di autenticazione. Per il suddetto processo la dimensione della chiave usata è sempre 128 bit. Invece per il processo di cifratura (encryption), la dimensione della chiave varia tra 1 e 18 ottetti. La dimensione della chiave di cifratura è configurabile per 2 motivi:

1. la prima giustificazione riguarda le diverse richieste imposte agli algoritmi di crittografia in diversi paesi, sia relativamente alla possibilità di esportare i prodotti, sia relativamente allo stato della riservatezza elettronica in generale.
2. la flessibilità della dimensione della chiave di cifratura fornisce un valido aiuto per un futuro miglioramento della sicurezza senza bisogno di riprogettare tutto il sistema crittografico.

La chiave di cifratura è diversa dalla chiave di autenticazione. Ogni volta che viene attivata la crittografia, viene generata una chiave di cifratura e il tempo di vita di tale chiave non necessariamente corrisponde al tempo di vita della chiave di autenticazione. La natura della chiave di autenticazione è più statica di quella della chiave di cifratura: una volta stabilita, sarà la particolare applicazione in esecuzione sul dispositivo Bluetooth a decidere se e quando cambiarla. La chiave di autenticazione viene chiamata link key.

RAND è un numero casuale, che può essere derivato da un processo casuale o pseudocasuale nell'unità Bluetooth. Non è un parametro statico e cambia frequentemente.

Chapter 4
IEEE 802.11

Lo scopo dello standard IEEE 802.11 è quello di "fornire connettività wireless a dispositivi o stazioni che richiedono un'istallazione rapida, siano essi portatili o palmari o ancora montati su veicoli mobili all'interno di una "local area" [2]. Il suddetto standard definisce le funzioni e i servizi richiesti ai dispositivi compatibili con esso per operare all'interno delle reti ad hoc e con infrastruttura, anch'esse compatibili con lo standard. Esso definisce delle procedure MAC e tecniche di trasmissione dei segnali attraverso un livello fisico (PHY) che potrà essere la radio frequenza (RF) o la radiazione infrarossa (IR). La comunicazione è "orientata al pacchetto⁵⁹". Vengono descritte anche delle procedure per fornire un certo livello di riservatezza delle informazioni.

Una caratteristica molto importante del protocollo definito dallo standard IEEE 802.11 è che un dispositivo mobile può comunicare con altri dispositivi, fissi o mobili, in maniera trasparente, ovvero, al di sopra del livello MAC, un dispositivo IEEE 802.11 viene visto come un qualsiasi dispositivo appartenente ad una LAN IEEE 802.x⁶⁰ e offre dei servizi comparabili con quelli offerti da un dispositivo 802.x appunto. In altre parole la mobilità dei dispositivi viene gestita a livello MAC.

4.1  Gli standard IEEE 802.11

Nel 1997 l'istituto IEEE (Institute for Electric and Electronic Engineering), approvò uno standard per wireless LAN denominato "802.11", che specificava la realizzazione di dispositivi capaci di ottenere 1 o 2 Mbps in termini di velocità di trasferimento[1]. Lo standard specifica il livello MAC e il livello PHY per la trasmissione nella banda ISM 2.4 GHz. La banda utilizzata si estende da 2.4 GHz fino a 2.4835 GHz in Nord America e Europa, mentre in Giappone le normative vigenti impongono una banda da 2.471 GHz a 2.497GHz. Due anni più tardi, in seguito agli ottimi risultati ottenuti da produttori quali Lucent Technologies e Harris Semiconductor (ora Intersil Corp.), l'istituto IEEE ratificò un nuovo standard, con prestazioni migliori, denominato IEEE 802.11b; esso permetteva di ottenere 11 Mbps in termini di velocità di trasferimento ed è lo standard su cui sono basati la maggior parte dei dispositivi attualmente disponibili sul mercato. In realtà IEEE 802.11b non è uno standard "ex novo", bensì specifica delle modifiche alle tecniche di modulazione ( e quindi al livello PHY) che permettono di elevare la velocità di trasferimento e mantengono comunque la compatibilità all'indietro verso i dispositivi IEEE 802.11.

Il nome IEEE 802.11(b) risulta un pò troppo ostico per il mercato dell'utente finale e quindi sempre più spesso sui dispositivi attualmente sul mercato si trova la sigla Wi-Fi, contrazione di Wireless Fidelity; Wi-Fi è un marchio di qualità poichè attesta la certificazione del dispositivo da parte della Wi-Fi Alliance.

Sempre nel 1999 l'istituto IEEE ratificò le specifiche di un altro standard della famiglia 802.11, la variante denominata 802.11a. Le specifiche riguardano sempre il livello MAC e il livello PHY, ma la banda utilizzata è la U-NII (Unlicensed National Information Infrastructure) 5 GHz e, mediante la tecnica di modulazione OFDM (orthogonal frequency division multiplexing), i dispositivi realizzati in conformità allo standard IEEE 802.11a possono ottenere fino a 54 Mbps in termini di velocità di trsferimento. Anche in questo caso si usa sempre più spesso la denominazione Wi-Fi5 per indicare i dispositivi compatibili con lo standard IEEE 802.11a.

Attualmente lo stato delle specifiche 802.11 può essere riassunto così:

Note:

1. La banda U-NII non necessita di licenze ma è disponibile solo in Nord America. Sono molteplici gli sforzi per ottenere l'uso senza licenza di tale banda anche in Europa ma attualmente i dispositivi compatibili IEEE 802.11a non possono funzionare in Europa.
2. Grazie a una tecnica di codifica specificata ma descritta come opzionale nelle specifiche IEEE 802.11b, ovvero la PBCC (packet binary convolutional code), è stato possibile realizzare dei dispositivi compatibili 802.11b che raggiungono i 22 Mbps in termini di velocità di trasferimento. Tali dispositivi realizzano questa velocità solo comunicando con altri dispositivi che utilizzano la stessa tecnica di codifica e risultano compatibili con i dispositivi 802.11(b).

La seguente tabella riassume invece gli standard in via di approvazione (draft):

E' interessante soprattutto lo standard IEEE 802.11g, che promette di raggiungere le stesse prestazioni della versione 802.11a in termini di velocità di trasferimento, pur operando nella banda ISM 2.4 GHz (e quindi disponibile anche in Europa), e mantenendo la compatibilità con i dispositivi 802.11b senza bisogno di hardware aggiuntivo. Infatti sono attualmente disponibili sul mercato dei dispositivi "ibridi" 802.11a e 802.11b ma ovviamente, a causa della diversità sia della banda utilizzata che della tecnica di modulazione, tali dispositivi necessitano di hardware separato per supportare i due standard.

Infine osserviamo l'ultima tabella che riassume gli standard ancora a livello di sviluppo, ovvero a livello di task group (TG):

4.2  La normativa italiana

Come già accennato, la banda di 2,4GHz non è soggetta a licenze in molti paesi del mondo tra cui l'Italia e può essere utilizzata da chiunque nell'ambito però di severi limiti di emissione di potenza; il limite di emissione in Italia per apparati a "bassa potenza" è pari a 0,1W/mq per la potenza dell'onda piana equivalente⁶¹ (più diffusamente noto come limite di 100mW), come stabilito dal decreto ministeriale 381/98 all'articolo 4, comma 2.
La regolamentazione applicata alle attività di telecomunicazioni è quella prevista nel decreto del Presidente della Repubblica num. 447 del 5 ottobre 2001
All'articolo 4 si specifica che:
1. Una licenza individuale è necessaria nel caso di installazione di una o più stazioni radioelettriche o del relativo esercizio di collegamenti di terra e via satellite richiedenti un'assegnazione di frequenza, con particolare riferimento a sistemi:
a) fissi, mobili terrestri, mobili marittimi, mobili aeronautici; [omissis]
All'articolo 5 si specifica che: 1.Un'autorizzazione generale è necessaria nel caso di: [omissis]
b) installazione o esercizio di sistemi che impiegano bande di frequenze di tipo collettivo: [omissis]
2) senza alcuna protezione, mediante dispositivi di debole potenza, compresi quelli rispondenti alla raccomandazione CEPT/ERC/REC 70-03. [omissis]
2.2) di installazione o esercizio di reti locali radiolan e hiperlan, ad eccezione di quanto disposto dall'articolo 6, comma 1, lettera b); [omissis]
All'articolo 6 si specifica che: 1. Sono di libero uso le apparecchiature che impiegano frequenze di tipo collettivo, senza alcuna protezione, per collegamenti a brevissima distanza con apparati a corto raggio, compresi quelli rispondenti alla raccomandazione CEPT-ERC/REC 70-03, tra le quali rientrano in particolare: [omissis]
b) reti locali di tipo radiolan e hiperlan nell'ambito del fondo, ai sensi dell'articolo 183, comma secondo, del decreto del Presidente della Repubblica n. 156 del 1973; sono disciplinate ai sensi dell'articolo 5 le reti hiperlan operanti obbligatoriamente in ambienti chiusi o con vincoli specifici; per "fondo" in materia di telecomunicazioni si richiama la legge del 1973 all'articolo 183 che recita: Nessuno può eseguire od esercitare impianti di telecomunicazioni senza aver ottenuto la relativa concessione o, per gli impianti di cui al comma secondo dell'art.1, la relativa autorizzazione. Tuttavia è consentito al privato di stabilire, per suo uso esclusivo, impianti di telecomunicazioni per collegamenti a filo nell'ambito del proprio fondo o di più fondi di sua proprietà, purchè contigui, ovvero nell'ambito dello stesso edificio per collegare una parte di proprietà del privato con altra comune, purchè non connessi alle reti di telecomunicazione destinate a pubblico servizio. Parti dello stesso fondo o più fondi dello stesso proprietario si considerano contigui anche se separati, purchè collegati da opere permanenti di uso esclusivo del proprietario, che consentano il passaggio pedonale. [omissis]
Questo articolo vieta l'erogazione di servizi a terzi pur anche nell'ambito del proprio fondo, ed in particolare vieta esplicitamente l'interconessione della cella WLAN Wi-Fi ad una rete pubblica (Internet).

Riassumendo, il decreto del 5 ottobre 2001 prevede tre categorie di utilizzo:

• Licenza individuale
• Autorizzazione Generale (in questo caso sono dovuti dei contributi per ogni sede e per ogni variazione)
• Uso libero

Quindi :

• non vi è nessun canone da pagare per l'utilizzo/installazione di una wireless LAN.
• qualora i dispositivi radio garantiscano una copertura limitata solo all'area o edificio di proprietà, non è necessaria alcuna autorizzazione.
• nel caso in cui la copertura della rete wireless vada ad interessare anche suolo pubblico, strade o altre proprietà, è necessario richiedere un'autorizzazione al Ministero delle Poste e Telecomunicazioni.

E' comunque vietata espressamente l'interconnessione di sistemi radiolan a reti pubbliche di telecomunicazioni quali Internet e la rete telefonica.

4.3  L'architettura di una WLAN IEEE 802.11

Una WLAN 802.11 è basata su una architettura cellulare, ovvero l'area in cui deve essere distribuito il servizio viene suddivisa in celle proprio come accade nei sistemi di distribuzione per servizi di telefonia cellulare. Ciascuna cella viene chiamata BSS (basic service set). Una BSS è un'insieme di "stazioni" (STA) ovvero dispositivi fissi o mobili compatibili IEEE 802.11. Le STA vengono controllate tramite una coordination function (CF) e lo standard 802.11 ne prevede due:

• Distributed Coordination Function (DCF)
  che è obbligatoria per ogni BSS;
• Point Coordination Function (PCF)
  che invece è opzionale.

Una "coordination function" è in pratica un insieme di regole per l'accesso al mezzo trasmissivo e la realizzazione dei vari servizi offerti dal protocollo e quindi dalle diverse STA. L'attributo "distributed" assegnato al DCF indica l'assenza di un coordinamento centralizzato al funzionamento delle STA di una BSS, ovvero l'accesso al mezzo trasmissivo e il trasferimento dei dati è totalmente distribuito tra le STA di quella BSS. Al contrario, quando in una BSS è attiva la funzione PCF (ricordiamo che la sua implementazione è opzionale), allora esiste una particolare STA che regola l'accesso al mezzo trasmissivo e la realizzazione dei servizi, e le altre STA devono seguire le regole dettate dalla STA che controlla la BSS.

La configurazione di rete più semplice realizzabile con dispositivi 802.11 è la cosiddetta IBSS (indipendent BSS), che è una rete "ad hoc" formata da almeno 2 STA. Una BSS può a sua volta essere parte integrante di una rete più ampia, la cosiddetta extended service set (ESS). Una ESS è formata da una serie di BSS interconnesse tra di loro tramite un distribution system (DS). Tipicamente il DS potrebbe essere una rete cablata (ethernet o altra). Dal punto di vista logico, la BSS e il DS utilizzano dei mezzi trasmissivi diversi: la BSS utilizza il wireless medium (WM) mentre il DS utilizza il distribution system medium (DSM). L'architettura IEEE 802.11 è indipendente da un mezzo trasmissivo specifico e quindi il WM e il DSM possono essere uguali ma possono anche non esserlo. In ogni caso le specifiche IEEE 802.11 coprono solo il WM. Le STA connesse al DS vengono dette access point (AP). Lo standard IEEE 802.11 divide i servizi offerti dalle STA in due categorie:

• Station services (SS)
• Distribution system services (DSS)

I servizi DSS vengono realizzati tramite gli access point e sono dei servizi che permettono al MAC il trasporto dei pacchetti tra due STA che non possono comunicare direttamente poichè non sono nell'area di copertura radio l'una dell'altra. Lo standard definisce anche il concetto di portal. Un portal è un dispositivo che permette l'interconnessione tra una rete LAN 802.11 e un'altra rete 802.x. Questo concetto rappresenta una descrizione astratta di una parte delle funzionalità di un bridge. Anche se lo standard non lo richiede espressamente, la maggior parte delle installazioni riuniscono l'access point e il portal in un'unica entità fisica.

La seguente figura riassume tutti i componenti tipici di un'architettura di rete 802.11:

4.4  Servizi offerti dalle reti IEEE 802.11

Abbiamo visto la divisione fatta dallo standard tra station services e distribution system services. Ora analizziamo meglio i singoli servizi e osserviamo innanzitutto la seguente tabella che li riassume mantenendo la distinzione suddetta:

In tutto vi sono 9 servizi, di cui 6 sono collegati al trasporto dei pacchetti tra le STA (MSDU (MAC service data unit) delivery) e 3 vengono usati per controllare l'accesso e la riservatezza delle WLAN 802.11. I servizi sono realizzati tramite uno o più tipi di MAC frame: alcuni saranno realizzati utilizzando dei frame di tipo management, altri da frame di tipo data. In una IBSS (ad hoc network), sono disponibili solo i servizi denominati "station services" (SS).

Authentication

Tramite questo servizio, viene condivisa la reciproca identità tra due STA che vorranno comunicare. Se non verrà stabilito un livello di autenticazione accettabile da entrambe le parti, il processo di autenticazione fallirà. IEEE 802.11 supporta diversi processi di autenticazione: si tratta tuttavia di un'autenticazione a "livello di collegamento" (link level), mentre un'autenticazione ad esempio di tipo "utente-utente" (user level) è supportata ma non viene specificata nello standard. Un esempio di schema di autenticazione supportato è lo schema "a chiave condivisa" (shared key), ma questo implica che sia implementata l'opzione WEP (wired equivalent privacy) di cui parleremo in seguito.

Deauthentication

Questo servizio viene invocato quando dev'essere cancellata un'autenticazione. In un ESS, come vedremo, l'autenticazione è un prerequisito per un altro servizio, l'associazione; dunque al momento della deautenticazione, viene a mancare anche l'associazione. La deautenticazione è una notifica, non una richiesta e quindi non può essere rifiutata da nessuna delle due parti.

Privacy

Per raggiungere un livello di riservatezza dei dati paragonabile a quello di una rete cablata, in cui solo i dispositivi fisicamente connessi alla rete possono ascoltare il traffico, lo standard IEEE 802.11 fornisce la possibilità di cifrare il contenuto dei messaggi trasmessi dalle STA. Questa funzionalità viene ottenuta tramite il servizio privacy. IEEE 802.11 specifica inoltre come opzionale il meccanismo WEP (wired equivalent privacy) per la cifratura dei dati. Il servizio di privacy può essere invocato solo per i frame di tipo data e per alcuni frame che controllano l'autenticazione. Tutte le STA iniziano a funzionare "in chiaro" (senza cifratura), per realizzare i servizi di autenticazione e privacy. Se il servizio privacy non viene invocato, tutti i messaggi verranno trasmessi non cifrati.

I "distribution system services" (DSS) vengono usati per distribuire i messaggi all'interno del "distribution system" (DS) e per supportare il concetto di "mobilità".

Distribution

Questo è il servizio principale usato dalla STA 802.11. Viene invocato da ciascun messaggio da o per una STA 802.11 operante in una ESS. Con riferimento alla figura  4.1, consideriamo un messaggio mandato dalla STA1 verso la STA4. Il messaggio viene prima ricevuto dalla STA2 che è l'AP della BSS cui la STA1 appartiene. L'AP invia il messaggio al servizio di distribuzione implementato nel DS, il quale si occupa di distribuirlo alla STA3 (un altro AP) la quale accede al WM per trasferire finalmente il messaggio al destinatario STA4. Come il messaggio verrà trasmesso all'interno del DS non viene specificato da IEEE 802.11: lo standard specifica delle informazioni da fornire al DS per determinare l'AP di "uscita" del suddetto messaggio. Tali informazioni vengono fornite attraverso i 3 servizi: association, reassociation e disassociation.

Integration

Questo servizio permette il trasporto delle MSDU tra una WLAN 802.11 e il DS attraverso un portal. Quindi i messaggi inviati da una STA 802.11 che devono essere ricevuti da una LAN preesistente attraverso un portal, invocheranno il servizio di integration prima della distribuzione tramite il DS. Anche questo servizio non viene coperto dallo standard.

Come abbiamo visto, vi sono altri servizi che supportano il servizio di distribuzione (distribution): le informazioni necessarie al corretto funzionamento del servizio distribution vengono fornite dai servizi di "associazione"; cioè prima che un dato possa essere gestito dal servizio distribution, una STA dev'essere "associata".

Per capire il concetto di associazione, è necessario prima capire il concetto di "mobilità".

Vi sono 3 tipi di transizioni che definiscono il concetto di mobilità di un dispositivo IEEE 802.11:

No-transition

Questo tipo di mobilità prevede 2 sottoclassi che sono in genere indistinguibili:

1. Static ovvero nessun movimento.
2. Local movement ovvero movimento nell'area di copertura delle STA con cui stiamo comunicando.

BSS-transition

Questo tipo di mobilità riguarda i movimenti di una STA da una BSS ad un'altra ma sempre all'interno della stessa ESS.

ESS-transition

Questo tipo di mobilità riguarda i movimenti di una STA da una BSS appartenente ad una ESS in una BSS appartenente ad un'altra ESS. In realtà questa possibilità è supportata solo in teoria, poichè IEEE 802.11 non garantisce il mantenimento delle connessioni a più alto livello.

Queste categorie di mobilità sono supportate dai servizi di associazione.

Association

Tramite questo servizio, una STA comunica la propria presenza all'AP della propria BSS. Viene sempre invocato da una STA. Una STA non può associarsi con più di un AP in uno stesso momento, questo per assicurare che il servizio di distribuzione trovi un AP unico per trasportare i messaggi del DS. L'association è sufficiente a gestire la mobilità di tipo "No-transition" ed è necessaria ma non sufficiente a gestire la mobilità "BSS-transition".

Disassociation

Tramite questo servizio viene cancellata un'associazione attualmente in corso. Il DS viene informato della disassociazione dall'AP corrispondente. Può essere invocato sia dalla STA che dall'AP. E' una notifica, non una richiesta e quindi non può essere rifiutata da nessuna delle due parti.

Reassociation

Per supportare la transizione di tipo "BSS-transition" è necessario invocare il servizio di riassociazione. Tramite questo servizio, viene spostata un'associazione corrente da un AP ad un altro. Questo tiene informato il DS della mappa tra AP e STA quando quest'ultima si sposta da una BSS ad un'altra. La riassociazione permette inoltre di cambiare i parametri di una associazione corrente mentre la STA rimane associata all'AP. La riassociazione viene sempre invocata dalla STA.

La seguente figura illustra le relazioni tra i vari servizi:

4.5  Livello MAC del protocollo IEEE 802.11

Lo standard IEEE 802.11 specifica un protocollo MAC che comprende una serie di funzioni che realizzano tutte le possibili operazioni di una WLAN 802.11. In generale, il livello MAC gestisce e mantiene le comunicazioni tra le STA, coordinando l'accesso al mezzo trasmissivo condiviso. Il livello MAC è in pratica il "cuore" di una WLAN 802.11: esso si serve del livello fisico (PHY) per le funzioni di rilevamento della portante (carrier sensing), trasmissione e ricezione dei frame 802.11.

4.5.1  Architettura del MAC

L'architettura del MAC IEEE 802.11 può essere descritta dalla figura 4.3:

4.5.2  Distributed Cooordination Function(DCF)

Il meccanismo di accesso base è denominato Distributed Coordination Function (DCF), basato sul meccanismo di "accesso multiplo con rilevamento della portante e prevenzione delle collisioni" (Carrier Sense Multiple Access with Collision Avoidance-CSMA/CA). Il DCF dev'essere implementato in tutte le STA e viene utilizzato sia nelle reti ad hoc (IBSS) che nelle configurazioni con infrastruttura (AP). Una STA, prima di trasmettere, deve "sentire" il mezzo trasmissivo (vedi pagina pageref) per controllare che un'altra STA non stia trasmettendo. Se in base alle regole del carrier sensing la STA stabilisce che il mezzo non è occupato, può trasmettere un frame. Se il frame trasmesso era direttamente indirizzato ad un'altra STA (unicast), quest'ultima usa un immediato positive acknowledgment (frame ACK) per indicare la corretta ricezione del frame. Se quest'ultimo frame ACK non viene ricevuto, perchè il mittente non lo riceve oppure perchè il destinatario non è riuscito a ricevere correttamente il dato inviatogli, il mittente programma la ritrasmissione del dato. Si noti che le due situazioni appena descritte, ovvero non ricezione del frame ACK oppure mancata trasmissione dello stesso da parte del destinatario, sono indistinguibili da parte del mittente.

Il protocollo CSMA/CA impone che vi sia un intervallo di tempo specificato tra le trasmissioni di due frame successivi. Questo intervallo viene genericamente chiamato IFS (Inter Frame Space)⁶². Una STA che vuole trasmettere dovrà assicurarsi che il mezzo trasmissivo risulti libero per l'adeguato IFS prima di provare a trasmettere. Se al contrario il mezzo viene rilevato come "occupato" , la STA deve rimandare la trasmissione fino al termine di quella in corso. Dopo questo ritardo e anche immediatamente dopo una qualsiasi trasmissione avvenuta con successo, una STA deve compiere la cosiddetta procedura di backoff. Questa procedura consiste nel selezionare un ritardo casuale (random backoff interval) e rimandare la trasmissione decrementando un contatore (random backoff interval counter) ogni volta che il mezzo trasmissivo viene rilevato libero. Questa procedura viene esaminata a pagina in pageref. Quanto appena descritto rappresenta l'accesso base secondo le regole del DCF. E' tuttavia prevista dallo standard una modifica al meccanismo di accesso base, che prevede lo scambio di due piccoli frame di controllo RTS e CTS prima di ogni trasmissione dati, essenzialmente pensata per ridurre ulteriormente le collisioni e ridurre i problemi derivanti dalle situazioni di tipo "nodi nascosti". Questa tecnica viene esaminata a pagina pageref ed il suo utilizzo è opzionale.

Meccanismo carrier-sense

Per determinare lo stato del mezzo trasmissivo viene usato un meccanismo di carrier-sense (controllo della portante), realizzato dal livello fisico (PHY) a beneficio del MAC; il MAC stesso inoltre, realizza un meccanismo di virtual carrier-sense. Se una STA opera con il metodo di accesso base sommariamente descritto in 4.5.2, allora può avere delle informazioni relative ad una trasmissione in corso da parte di un'altra STA dal campo "Duration/ID" (vedi 4.8) incluso nell'header dei frame. Tramite questo campo la STA conosce il tempo per il quale il mezzo trasmissivo risulterà ancora occupato, anche in caso di messaggi frammentati su più frame.

Anche nel caso sia abilitato il meccanismo RTS/CTS, viene realizzato il virtual carrier-sense, per mezzo di un contatore denominato NAV (Network Allocation Vector), che viene impostato opportunamente tramite le informazioni contenute nei frame RTS e CTS. Vedremo in dettaglio questa procedura a pagina pageref.

Interframe space (IFS)

L'intervallo di tempo tra due frame consecutivi è detto IFS. Lo standard definisce quattro diversi IFS, che definiscono 3 diversi livelli di priorità nella procedura di accesso al mezzo trasmissivo. Più piccolo è il tempo IFS, maggiore sarà la priorità dell'operazione che si basa su quell'IFS. Gli IFS sono definiti come intervalli di tempo sul mezzo trasmissivo e sono indipendenti dalla velocità di trasferimento del canale. Gli IFS saranno differenti per le 3 implementazioni del livello fisico previste dallo standard (radiazione infrarossa, direct sequence spread spectrum e frequency hopping spread spectrum).

Short IFS (SIFS)

Questo IFS viene usato per l'acknowledgement (ACK) immediato di un frame, per la risposta di tipo CTS (clear to send) and un frame RTS (request to send), per delimitare le trasmissioni delle varie MPDU (MAC protocol data unit) ovvero le parti in cui vengono frammentate le già citate MSDU se le loro dimensioni eccedono un limite prefissato; viene usato inoltre nella risposta ad un polling del PCF e infine nelle risposte a qualsiasi frame inviato dall'AP durante il contention-free period (CFP).

Point coordination function IFS (PIFS)

Questo IFS viene usato dalle STA che operano in PCF per ottenere l'accesso al mezzo trasmissivo all'inizio del CFP.

Distributed coordination function IFS (DIFS)

Questo IFS viene usato dalle STA che operano in DCF per ottenere l'accesso al mezzo e trasmettere frame contenenti dati oppure frame di controllo.

Extended IFS (PIFS)

E il più lungo IFS ed è usato da una stazione che ha ricevuto un pacchetto di cui non è stata in grado di comprendere il contenuto. Questo è necessario per proteggere la stazione (la quale non comprende l'informazione di durata necessaria per il virtual carrier sense) da collisioni con i futuri pacchetti appartenenti al messaggio corrente.

Alcuni IFS sono stabiliti dallo standard in modo assoluto. Altri vengono definiti relativamente ad altre grandezze quali lo slot-time. Lo slot-time è una grandezza molto importante proprio perchè è usato come unità di misura di intervalli di tempo quali gli IFS ma anche come unità di misura nel meccanismo del random backoff. L'intervallo di backoff infatti risulta suddiviso in quanti di durata pari al valore slot-time. Si veda a proposito il paragrafo successivo.

Osserviamo dunque alcuni valori derivati dallo standard[1]:

Gli altri IFS possono essere ottenuti con le seguenti formule:

PIFS=SIFS×SlotTime   DIFS=SIFS+2×SlotTime

(4.1)

Random Backoff

Abbiamo visto che il meccanismo carrier-sense dev'essere invocato ogni volta che una STA vuole trasmettere un frame. Se il mezzo trasmissivo è occupato, la trasmissione dev'essere ritardata fino a quando non si trova il mezzo libero per un periodo di tempo continuato ⁶³ maggiore o uguale al DIFS o al EIFS se l'ultimo frame non era stato ricevuto correttamente. Dopo questo intervallo (DIFS o EIFS), e se il contatore di backoff (backoff timer) non è già pari a 0, la STA genera un periodo di ritardo casuale (random backoff), che ritarda ulteriormente la trasmissione. Questo processo è stato previsto per minimizzare le collisioni derivanti dai tentativi di accesso al mezzo da parte di più STA che avevano ritardato la propria trasmissione a causa di uno stesso evento.

La durata del random backoff può essere espressa da:

BackoffTime=Random()×SlotTime

(4.2)

ove "Random" è un intero pseudocasuale uniformemente distribuito nell'intervallo [0,CW]. CW indica il parametro detto Contention Window, che rappresenta in pratica un'unità di misura per il random backoff. CW è compreso nell'intervallo [CW_min,CW_max], e la sua gestione può essere descritta così:

• CW inizialmente assumerà il valore CW_min. Questo valore, come anche CW_max dipendono dallo specifico PHY.
• I valori che CW può assumere in sequenza sono dati dalle potenze crescenti di 2, meno 1, fino ad arrivare al valore CW_max.
• Ogni STA ha un contatore (retry counter) che viene incrementato ogni volta che un frame non viene trasmessa con successo. Un incremento del retry counter provoca un incremento di CW.
• Se CW raggiunge il valore CW_max, ulteriori tentativi di trasmissione falliti non modificheranno il suo valore.
• CW verrà resettato a CW_min dopo ogni tentativo di trasmissione concluso con successo

Alcuni valori dallo standard:

Nella figura 4.5, possiamo vedere una possibile situazione relativa alla procedura di backoff appena descritta.

La STA "A" trasmette un frame mentre le altre STA ritardano a causa di questa trasmissione. Alla fine di quest'ultima, tutte le STA controllano il mezzo trasmissivo per un tempo pari a DIFS, dopodichè tutte le STA eseguono la procedura di random backoff. Risulta "vincente" la STA "C", che possedeva un random backoff minore rispetto alle altre STA concorrenti. Come si vede dalla figura 4.5, il timer di backoff delle STA viene decrementato solo se quando il mezzo risulta libero. Infatti, nel momento in cui la STA "C" vince la contesa per l'accesso al mezzo, il timer di backoff delle STA concorrenti "B" e "D" viene fermato e il suo valore mantenuto. Al termine della trasmissione della STA "C" viene osservato da tutte le STA un ritardo pari a DIFS; successivamente la contesa per l'accesso al canale viene risolta in favore della STA "D", che aveva un valore residuo del random backoff timer minore rispetto alla concorrente STA "B" ( si notino le differenze tra le aree più scure in figura).

Procedura di accesso standard

La figura 4.6 illustra il meccanismo di accesso base del DCF:

Riassumendo:

• In generale una STA che opera secondo le regole del DCF, trasmette un frame quando rileva il mezzo libero continuamente e per un tempo pari a DIFS (o EIFS).
• Se il mezzo viene invece rilevato come occupato, viene seguita la procedura di backoff descritta a pagina pageref.

Una caratteristica importante del MAC IEEE802.11 consiste nella cosiddetta capacità di frammentazione/deframmentazione delle unità informative che vengono trasmesse e ricevute dalle STA. Si possono dunque frammentare le MSDU (MAC Service Data Unit) e le MMPDU (MAC Management Protocol Data Unit), in unità più piccole, che abbiamo finora chiamato frame e che lo standard IEEE 802.11 indica anche con l'acronimo MPDU (MAC Protocol Data Unit).

La frammentazione delle MSDU e delle MMPDU è prevista per aumentare l'efficienza delle trasmissioni, poichè unità informative più piccole sono più facilmente trasferibili, anche nel caso che le condizioni del canale siano sfavorevoli (interferenze, traffico elevato etc.).

L'operazione di ricomposizione di una MSDU (o MMPDU) frammentata viene chiamata deframmentazione. Solo le unità informative unicast possono essere frammentate, mentre non è prevista questa possibilità per i messaggi multicast o broadcast.

La frammentazione è gestita tramite il parametro "FragmentationThreshold", che definisce la dimensione dei frame nei quali viene frammentata una MSDU.

Possiamo vedere dalla figura 4.8 come una STA che abbia avuto accesso al mezzo trasmissivo, possa usare il SIFS, cioè il più breve degli intervalli di attesa, per trasmettere i vari frammenti di una MSDU, senza quindi dover ricontendere l'accesso al mezzo per ogni singolo frammento:

In questo modo, una STA che ha accesso al mezzo continua a trasmettere, ad intervalli di SIFS, le MPDU in cui ha frammentato una MSDU, fino a che queste ultime MPDU non sono finite oppure finchè viene mancato un ACK⁶⁴.

Procedura di accesso con meccanismo RTS/CTS

Nella figura 4.9, osserviamo la procedura di accesso con meccanismo RTS/CTS:

*  Nodi Nascosti

Si dice che un nodo (STA) A è nascosto ad un nodo B appartenente alla stessa BSS, quando i due nodi sono fuori dalla reciproca portata radio, cioè non possono comunicare direttamente.

Possiamo visualizzare, tramite la figura 4.10, un possibile problema legato alla presenza di nodi nascosti:

Le STA A e C non sentono le reciproche trasmissioni e, quindi, può capitare che entrambe portino avanti due trasmissioni contemporanee verso la STA B che si trova nel raggio di copertura di entrambe. Ovviamente questo causa una serie di collisioni e la STA B non riceverà correttamente i pacchetti che le altre STA tentano di inviargli. Per ovviare a questo problema si usa il meccanismo RTS/CTS:

• Una STA che volesse trasmettere una MPDU verso un'altra STA (ad esempio in figura 4.10 la STA A vorrebbe trasmettere un dato alla STA B), dovrà prima inviare un frame di tipo RTS diretto alla STA B. Le STA che possono ricevere correttamente tale frame RTS, grazie al campo "Duration/ID" contenuto nell'header di tale frame, aggiusteranno di conseguenza il proprio NAV in modo da deferire l'accesso al mezzo poichè un'altra STA ha iniziato una trasmissione. Nel caso visualizzato in figura 4.10, la STA C non riceve le informazioni contenute nel frame RTS inviato dalla STA A.
• La STA B, ricevuto il frame RTS, risponde con il frame CTS (dopo un intervallo SIFS), comunicando di essere pronta ad accettare dei dati. Il frame CTS verrà stavolta ricevuto dalla STA C, la quale aggiusterà il proprio NAV in base a quanto contenuto nell'header del suddetto frame CTS. Dunque, la STA C, pur non sentendo l'inizio della trasmissione della STA A poichè fuori dal raggio di copertura di quest'ultima, sente comunque la trasmissione della STA B, e, ritarda l'accesso al mezzo trasmissivo fino alla fine della trasmissione in corso.
• Il frame di dati veri e propri sarà inviato esattamente un SIFS dopo la trasmissione del frame CTS, senza controllare il mezzo.

L'uso di questo meccanismo è opzionale, e, poichè provoca un leggero overhead⁶⁵ dovuto alla presenza dei 2 frame RTS/CTS, si può configurare in modo che venga attivato solo per le trasmissioni di frame di dimensioni significative. Tutti i frame di dimensione maggiore del parametro RTSThreshold, saranno soggetti al meccanismo RTS/CTS. Se il valore di RTSThreshold è 0, vuol dire che tutti i frame saranno inviati col meccanismo RTS/CTS. Se il valore di RTSThreshold è maggiore della massima dimensione consentita per le MSDU, allora nessun frame sarà inviato col meccanismo RTS/CTS. Il meccanismo RTS/CTS può essere usato anche in caso di frammentazione delle MSDU.

Come si vede dalla figura 4.11, i frame RTS/CTS vengono scambiati solo per il primo frammento, e, in seguito, viene usato ai fini del settaggio NAV, il campo "Duration/ID" dei frame dati e dei frame ACK che li seguono.

Broadcast e multicast

La trasmissione broadcast (o multicast) di frame dati, in generale non è soggetta al meccanismo RTS/CTS. Questo è vero però solo per i frame in cui il bit ToDS (vedi 4.8) è pari a 0, nel qual caso viene usata la procedura di accesso base e non viene inviato alcun frame ACK. Nel caso in cui un frame broadcast (o multicast) abbia invece il bit ToDS pari a 1, tale frame segue le regole della procedura di accesso con RTS/CTS, questo perchè il suddetto frame è diretto verso l'AP.

La suddetta distinzione in base al valore del bit ToDS si riflette anche sulla ritrasmissione dei frame: solo nel caso in cui ToDS sia pari a 1 è previsto il meccanismo di recupero dei dati non ricevuti correttamente (ovvero la ritrasmissione dei frame).

Trasmissione degli ACK

Tutti i frame unicast di tipo dati richiedono espressamente una "conferma di ricezione", effettuata dal destinatario tramite la trasmissione del frame ACK (acknowledgment), come abbiamo già accennato. Tale frame dev'essere inviato, a prescindere dallo stato del mezzo trasmissivo, esattamente un SIFS dopo un frame dati. Nel caso in cui il suddetto frame dati abbia il bit ToDS pari a 1, è l'AP che deve inviare il frame ACK. Come abbiamo già visto, non viene inviato alcun ACK per i frame broadcast (o multicast).

La STA che invia un frame dati con richieste di ACK stabilisce che la propria trasmissione è fallita se non riceve un ACK entro il tempo definito dal parametro ACKTimeout.

Procedure di recupero

Il recupero degli errori, ovvero dei frame non ricevuti correttamente, è gestito dalla STA mittente, tramite ritrasmissione dei suddetti frame finchè gli stessi non vengono ricevuti correttamente oppure finchè non viene raggiunto un certo limite (retry limit).

Ogni STA possiede due contatori detti STA short retry count (SSRC) e STA long retry count (SLRC).

Il contatore SSRC viene incrementato ogni volta che fallisce la trasmissione di un frame MAC appartenente ad una MSDU o ad una MMPDU la cui dimensione è minore o uguale al valore RTSThreshold, mentre tale contatore viene resettato quando la suddetta trasmissione avviene con successo.

Il contatore SLRC viene incrementato ogni volta che fallisce la trasmissione di un frame MAC appartenente ad una MSDU o ad una MMPDU la cui dimensione è maggiore al valore RTSThreshold, mentre tale contatore viene resettato quando la suddetta trasmissione avviene con successo.

I frame ritrasmessi sono contraddistinti dal valore 1 nel campo Retry.⁶⁶.

I tentativi di ritrasmissione di una MSDU o MMPDU finiscono quando il contatore SSRC raggiunge il limite imposto dal parametro ShortRetryLimit, o quando il contatore SLRC raggiunge il limite imposto dal parametro LongRetryLimit. Quando viene raggiunto almeno uno di questi limiti, la MSDU o la MMPDU in questione viene scartata.

Lo standard IEEE 802.11 fissa a 7 il valore dei limiti ShortRetryLimit e LongRetryLimit.

Rilevamento dei frame duplicati

Una STA dev'essere in grado di rilevare, a livello MAC, la ricezione di frame già ricevuti. Questo processo è facilitato dal campo Sequence Control che è composto da un numero di sequenza e da un numero di frammento e che è incluso in ogni frame di tipo dati e management. Dunque, le MPDU che fanno parte di una stessa MSDU avranno lo stesso numero di sequenza e le diverse MSDU avranno (con elevata probabilità) un numero di sequenza differente. Il numero di sequenza è generato dalla STA trasmittente ed è parte di una sequenza crescente di interi. La STA ricevente mantiene una cache dei dati <Address 2 - numero di sequenza - numero di frammento>⁶⁷ più recenti. La stessa STA scaricherà dunque tutti quei frame che hanno il bit Retry settato e i cui valori <Address 2 - numero di sequenza - numero di frammento> corrispondono ad un record della cache. La STA effettuerà comunque la procedura di ACK (se il frame lo richiede) anche se poi scarterà il frame a causa della duplicazione.

4.5.3  Point Coordination Function (PCF)

Il MAC IEEE 802.11 prevede un metodo di accesso opzionale chiamato Point Coordination Function (PCF), che può essere usato però solo nelle reti con infrastruttura. Questo metodo di accesso prevede che un'entità logica detta Point Coordinator (PC), che risiede nell'AP della BSS, stabilisca istante per istante mediante un'operazione di polling quale STA sia autorizzata a trasmettere. Questo tipo di accesso potrebbe richiedere un coordinamento ulteriore nel caso in cui, nella stessa area e sullo stesso canale, si trovassero ad operare due BSS in PCF. Quest'ultima situazione non è specificata dallo standard.

Il PCF utilizza un meccanismo virtual carrier-sense insieme ad un meccanismo d'accesso basato su priorità. Il metodo d'accesso fornito dal PCF può dunque essere utilizzato per realizzare un accesso di tipo contention-free (CF), ovvero il PC controlla integralmente la trasmissione delle STA cosicchè si elimina la contesa di queste ultime per il mezzo trasmissivo.

E' previsto dallo standard che i metodi DCF e PCF debbano coesistere: quando in una BSS è presente un PC, i due metodi di accesso si alternano creando un Contention-free Period (CFP) cui segue un Contention Period (CP).

Tutte le STA di una BSS in cui è presente un PC attivo, possono operare correttamente e, se associate con l'AP in cui risiede appunto l'entità PC, possono ricevere frame in accordo alle regole del PCF. Così come è opzionale per un AP agire da PC, allo stesso modo è opzionale per una STA implementare la possibilità di rispondere alle richieste del PC durante il CFP. Le STA che implementano tale possibilità sono riferite nello standard come STA CF-Pollable. La procedura d'accesso verrà descritta a pagina pageref.

Struttura e temporizzazione del CFP.

Il metodo PCF è usato per il trasferimento dei frame durante il CFP. Il CFP si alterna nel tempo con il CP, durante il quale è il metodo DCF a controllare il trasferimento dei frame. Lo standard IEEE 802.11 impone che sia comunque sempre presente un CP di durata sufficiente a trasmettere almeno una sequenza completa di frame. Questa possibilità viene imposta dallo standard per permettere la trasmissione dei frame di tipo Management⁶⁸.Ciascun CFP comincia con un frame speciale detto beacon, che contiene delle informazioni importanti sul CFP, tra le quali un elemento di tipo DTIM (Delivery Traffic Indication Map), che è a sua volta un particolare pacchetto TIM (Traffic Indication Map).

Il campo CF Parameter Set è così strutturato:

Il beacon che segna l'inizio del CFP ha il campo CFPCount pari a 0, altrimenti tale campo indica quanti DTIM (incluso il frame attuale) verranno trasmessi prima dell'inizio del prossimo CFP. Il PC genera dei periodi CFP ad intervalli pari al valore del parametro CFPRate, espresso in termini di intervalli DTIM e comunicato alle STA della BSS tramite il campo CFPPeriod del CF Parameter Set visto in figura 4.13. Possiamo vedere un esempio nella figura seguente:

In questo esempio, il CFP si ripete ogni 2 intervalli DTIM e l'intervallo DTIM a sua volta è pari a 3 intervalli beacon.

Il PC può terminare un CFP prima della sua fine prevista. Tale fine è specificata dal parametro CFP-MaxDuration anch'esso incluso nel CF Parameter Set. Il termine prematuro del CFP potrebbe essere dovuto, ad esempio, alla mancanza di traffico da gestire. Come si vede dalla figura 4.12, il traffico contention che segue il periodo CFP, potrebbe causare un ritardo nella trasmissione del beacon che inizia il prossimo CFP. In questa situazione, la durata del successivo periodo CFP risulta diminuita proprio del suddetto ritardo. Lo standard prevede che in caso di mezzo trasmissivo occupato dalla trasmissione DCF di un frame, la trasmissione del beacon debba essere ritardata fino al completamento del frame DCF. Quindi, nell'alternanza tra i due metodi di accesso, viene garantita una durata minima per il CP, ma non viene garantita una durata minima per il CFP, anzi ne viene definita una durata massima. Questo significa che il CFP non garantisce alcuna banda minima di trasmissione.

Procedura di accesso base

Il metodo di accesso contention-free è basato su uno schema di tipo polling (interrogazione) controllato dall'entità logica detta PC che risiede nell'AP di una BSS con topologia infrastrutturata. Il PC acquisisce il controllo del mezzo trasmissivo all'inizio di ogni CFP, e tenta di mantenere questo controllo per tutta la durata del CFP usando un IFS minore di quello usato dalle STA che operano secondo le regole del DCF. Abbiamo già accennato al suddetto IFS (PIFS ovvero Point Coordination Function IFS), e dalla tabella possiamo effettivamente vedere come il suo valore sia inferiore al DIFS, che è il tempo IFS che viene usato dalle STA che operano secondo le regole dal DCF per intercalare le trasmissioni consecutive dei frame. Quindi, all'inizio di un CFP, il PC controlla il mezzo trasmissivo, e, se risulta libero per un tempo maggiore o uguale a PIFS, il PC trasmette un beacon con il CF Parameter set e l'elemento DTIM. Tutte le altre STA settano il proprio NAV proprio in base all'informazione CFP-MaxDuration, in modo da evitare possibili trasmissioni non causate da poll del PC, sia da parte di STA CF-Pollable che da parte di tutte le altre STA. Le STA CF-Pollable e il PC non usano il meccanismo RTS/CTS durante il CFP. Quando una STA CF-Pollable viene interrogata dal PC, essa può trasmettere soltanto una MPDU, diretta verso il PC o verso una qualsiasi altra STA, e può effettuare un cosiddetto piggyback dell'ACK per un frame ricevuto dal PC, usando un particolare sottotipo di frame dati. La ricezione del frame appena inviato dalla STA che è stata interrogata dev'essere confermata con l'invio di un frame ACK dopo un SIFS, proprio come col metodo DCF, a conferma del fatto che il metodo PCF non è un'entità logica a se stante ma dipende strettamente dal DCF. Se tale conferma non avviene (o la STA mittente non la riceve), la STA che è stata autorizzata a trasmettere dal PC non può ritrasmettere il frame fino a quando non viene interrogata nuovamente dal PC, oppure può decidere di ritrasmetterlo durante il CP. Il PC può invece ritentare la trasmissione di un frame di cui non ha avuto l'ACK, dopo un tempo PIFS.

Le figure 4.15 e 4.16, illustrano i casi appena descritti, ovvero una trasmissione PC-STA e una trasmissione STA-STA, entrambe durante il CFP.

La presenza e la gestione del NAV durante il CFP sono utili per facilitare l'operatività delle reti nella situazione di sovrapposizione dei rispettivi periodi CFP e delle rispettive aree di copertura. Tuttavia, come abbiamo già detto, il modo in cui tali BSS in questa situazione, coordinano i rispettivi CFP, non è coperto dallo standard IEEE 802.11.

Definiamo gli istanti in cui, nominalmente, dovrebbe iniziare la trasmissione del beacon che segna l'inizio del CFP come TBTT (Target Beacon Trasmission Time). In questi istanti tutte le STA, eccetto l'AP, inizializzeranno il proprio NAV al valore CFP-MaxDuration. Questo evento ha 2 effetti:

• Impedisce alle STA diverse dall'AP di prendere il controllo del mezzo durante il CFP.
• Risolve il problema dei nodi nascosti, così come faceva il meccanismo RTS/CTS per il DCF.

Una STA che vuole unirsi ad una BSS in cui opera un PC, usa le informazioni contenute in elemento del CF Parameter Set, il CFPDurRemaining, presente nei beacon e nei frame di tipo Probe Response, il cui uso verrà descritto in seguito. Usando tali informazioni, le nuove STA aggiornano il proprio NAV in modo da non interferire con un eventuale CFP in corso.

Il PC può concludere anzitempo il CFP trasmettendo un frame di tipo CF-End (o CF-End+ACK): una STA che riceva uno di questi due frame, a qualsiasi BSS essa appartenga, è autorizzata a resettare il proprio NAV.

Riepilogo delle regole del metodo PCF

E' opportuno riepilogare le regole che definiscono il metodo d' accesso PCF:

• Il PC può inviare dei frame di tipo unicast, broadcast o multicast ad ogni STA attiva ed anche ad eventuali STA CF-Pollable ma in Power Save (in seguito vedremo le modalità definite power save).
• Durante il periodo CFP, ogni STA CF-Pollable deve operare dopo un SIFS nel seguente modo:

1. se ha ricevuto un frame di tipo Data+CF-Poll oppure Data+CF-ACK+CF-Poll, deve rispondere con un frame di tipo Data+CF-ACK oppure semplicemente con un frame CF-ACK se non ha dati da inviare
2. se ha ricevuto un frame di tipo CF-Poll deve rispondere con un frame di tipo Data oppure Null
3. se ha ricevuto un frame di qualsiasi altro tipo (dati o management), deve rispondere con un frame di tipo ACK

• Le STA non CF-Pollable si comportano praticamente seguendo le regole del metodo DCF, e quindi rispondono alla ricezione di un frame di qualsiasi tipo (dati o management) usando un frame ACK dopo un SIFS.
• Quando una STA CF-Pollable viene interrogata dal PC con un Poll (frame Data+CF-Poll, Data+CF-ACK+CF-Poll, CF-Poll o CF-ACK+CF-Poll), può mandare un frame verso una STA qualsiasi. Se tale frame è diretto al PC, o deve passare attraverso il PC perchè diretto al DS, il PC stesso deve confermare la ricezione del frame usando l' indicazione CF-ACK (frame Data+CF-ACK, CF-ACK, Data+CF-ACK+CF-Poll, CF-ACK+CF-Poll o CF-End+CF-ACK) dopo un SIFS. Se invece il frame è diretto verso una STA (che sia CF-Pollable oppure no), la STA destinataria confermerà con un frame ACK dopo un SIFS.

Polling list

Il PC può realizzare 2 diverse forme del servizio contention-free: con o senza interrogazioni. Queste due modalità sono comunicate tramite l' elemento Capability Information che si trova nei frame beacon, probe response, association response, reassociation response che vengono inviati dall'AP.

In particolare, i campi CF-Pollable e CF-Poll Request vengono così interpretati quando i frame in cui sono contenuti provengono da un AP/PC:

Se il PC realizza un CFP soltanto per il trasporto di frame verso il DS, così come può fare durante il funzionamento DCF, esso non ha bisogno di creare e gestire una polling list e non genererà quindi mai dei frame contenenti l'indicazione CF-Poll. Se al contrario, il PC prevede di usare le interrogazioni (poll) per le STA che lo richiedono (CF-Pollable), esso genera e mantiene una polling list e la usa per generare dei frame con l'indicazione CF-Poll, ovvero per generare le interrogazioni alle STA incluse nella lista stessa. La polling list è solo un costrutto logico e non viene resa disponibile all'esterno del PC.

Analizziamo ora le procedure minime di gestione della polling list, osservando che un AP/PC può implementare varie tecniche per la suddetta gestione ma queste sono fuori dalla copertura dello standard IEEE 802.11:

• Quando la polling list è popolata, durante il CFP il PC deve mandare almeno un frame di tipo CF-Poll ad una STA inclusa nella polling list.
• Le STA nella polling list sono interrogate in ordine di AID (Association Identifier) crescente⁶⁹. Il valore AID è un identificativo di 16 bit, di valore compreso tra 1 e 2007, che viene assegnato alla STA dall'AP appunto in fase di associazione (Association), durante la quale la STA stessa comunica il suo futuro comportamento in base alla seguente tabella (i campi CF-Pollable e CF-Poll request sono compresi nell'elemento Capability Information presente nei frame di tipo Association e Reassociation Request):
  

• Se rimane tempo durante il CFP, tutti i frame CF sono stati inviati e tutte le STA della polling list sono state interrogate, il PC può decidere di:

1. generare uno o più frame CF-Polls verso una o più STA della polling list
2. mandare frame di tipo dati o management a una o più STA (anche non appartenenti alla polling list).
3. Se il CFP termina prima che tutte le STA della polling list vengano interrogate, la polling list riprenderà dal punto in cui si è interrotta nel successivo periodo CFP.

Come abbiamo visto nella tabella 4.9 , una STA comunica la propria posizione nei confronti della polling list al momento dell'associazione o riassociazione. Tale posizione può essere modificata tramite il servizio di riassociazione. Sempre dalla stessa tabella, possiamo notare che c'è anche la possibilità per una STA di essere CF-Pollable ma di non voler essere mai interrogata. Questa possibilità che può sembrare inutile, sarà esaminata meglio nella sezione dedicata al Power Save.

4.5.4  Sincronizzazione

Illustriamo ora le procedure che consentono a tutte le STA di una BSS di rimanere sincronizzate con un clock comune. La sincronizzazione è basata su una funzione, gestita da ogni singola STA, detta TSF (Timing Synchronization Function) e su un timer, il TSF Timer.

Sincronizzazione nelle WLAN IEEE 802.11 con infrastruttura

In una WLAN IEEE 802.11 con infrastruttura, l'AP provvederà a realizzare la funzione TSF e controllerà il clock comune. L'AP trasmetterà periodicamente dei frame di tipo beacon, contenenti una copia (timestamp, vedi descrizione del frame beacon) del proprio TSF Timer, per consentire alle altre STA della BSS di sincronizzarsi con quest'ultimo. Una STA che riceve questo beacon, deve accettare senza condizioni le informazioni relative al timestamp dell'AP e aggiustare il proprio TSF Timer in base al timestamp stesso.

*  Generazione e trasmissione dei beacon

L'AP dunque genera dei beacon ad intervalli pari al valore BeaconPeriod, stabilendo perciò la temporizzazione della BSS. Abbiamo già definito a pagina pageref col termine TBTT gli istanti in cui l'AP nominalmente, ovvero in mancanza di traffico in corso e quindi con il mezzo trasmissivo libero, dovrebbe iniziare la trasmissione di un frame di tipo beacon. Possiamo osservare un esempio nella figura 4.18:

*  Ricezione dei beacon

Una STA appartenente ad una WLAN IEEE 802.11 con infrastruttura, deve usare le informazioni contenute nei beacon solo se il campo BSSID coincide con l'indirizzo MAC dell'AP che gestisce la BSS di cui la STA fa parte. Se il suddetto confronto è positivo, la STA modifica il proprio timer TSF con il valore del timestamp ricevuto col beacon, altrimenti significa che ha ricevuto il beacon di un'altra BSS, che deve ignorare.

Sincronizzazione nelle WLAN IEEE 802.11 ad hoc

La funzione TSF in una WLAN ad hoc, o IBSS, è implementata con un algoritmo distribuito cui prendono parte tutte le STA della IBSS. Una qualsiasi STA è in grado di generare e trasmettere beacon, in accordo alla procedura che vedremo, e le altre STA devono operare le modifiche, al proprio timer TSF, solo se il valore timestamp, ricevuto tramite il beacon o frame di tipo probe response, è in ritardo rispetto al proprio.

*  Generazione dei beacon

La generazione dei beacon è distribuita. Il periodo di trasmissione dei beacon (beacon period) è incluso nei frame di tipo beacon o probe response, e tutte le STA devono adottare questo parametro al momento in cui si uniscono alla IBSS. Il parametro beacon period è stabilito dalla STA che inizializza la IBSS. Il beacon period a sua volta definisce gli istanti TBTT. Ad ogni TBTT ogni STA deve:

1. Sospendere qualsiasi eventuale procedura di backoff in corso.
2. Calcolare un ritardo casuale, uniformemente distribuito nell'intervallo [0 ; 2×CW_min×SlotTime].
3. Aspettare questo ritardo casuale, come nella procedura di backoff.
4. Se durante quest'attesa viene ricevuto un beacon generato da un'altra STA, viene cancellato il ritardo casuale calcolato e viene abbandonata la procedura di trasmissione del beacon, riprendendo eventuali backoff sospesi.
5. Se invece non viene ricevuto alcun beacon durante l'attesa, allora la STA invia il beacon con il proprio timestamp.

Si noti che è possibile che più di una STA in una IBSS generi e invii un beacon subito dopo il TBTT, o a causa di una non corretta ricezione di un beacon inviato da un'altra STA, o a causa di collisione tra le trasmissioni dei beacon stessi.

*  Ricezione dei beacon

Una STA appartenente ad una IBSS accetta le informazioni contenute in ogni beacon ricevuto solo se il sottocampo IBSS dell'elemento Capability Information è posto ad 1 ed il contenuto del campo SSID del beacon è uguale all'indirizzo MAC della IBSS. In questo caso, la STA modificherà il proprio timer TSF con il valore ricevuto con il beacon solo se quest'ultimo è in ritardo rispetto al proprio TSF .

4.6  Power management e modalità Power Save

4.6.1  Power management in una WLAN con infrastruttura

Relativamente al consumo di potenza, una STA può trovarsi in uno dei seguenti 2 stati:

Awake

la STA funziona a pieno regime.

Doze

la STA non riceve nè trasmette e perciò consuma pochissima potenza.

Una STA si sposta da uno stato all'altro in base ai cosiddetti Power Management Modes (modalità di gestione della potenza). Queste modalità sono riassunte nella tabella 4.10.

Una STA che voglia cambiare modalità di funzionamento deve comunicarlo all'AP tramite il bit Power Management contenuto nel Frame Control Field dei pacchetti⁷⁰. Il valore di questo bit indicherà all'AP quale sarà, a conclusione dello scambio di frame in corso durante il quale non può ovviamente cambiare nulla, la modalità di funzionamento scelta dalla STA. Se la modalità scelta è la modalità PS (Power Save) l'AP non deve trasmettere alcuna MSDU alla STA in PS, bensì deve conservare tutto il traffico relativo alla STA e trasmetterglielo in momenti prestabiliti.

La STA in PS ascolterà il canale periodicamente per ricevere dei frame di tipo beacon nei quali trova l'elemento TIM (Traffic Indication Map). La ricezione dei beacon, relativamente alla procedura di gestione degli elementi TIM, è regolata dai parametri ListenInterval e ReceiveDTIMs.

In particolare, il parametro ListenInterval viene comunicato dalla STA all'AP al momento dell'associazione e indica all'AP in quali beacon la STA sarà in ascolto⁷¹. Il parametro ReceiveDTIMs, invece, è comunicato dalla STA all'AP al momento del cambio di modalità operativa (da AM a PS), ed indica se la STA in questione riceverà ed interpreterà o meno i beacon con elemento DTIM.

In pratica, l'AP costruisce l'elemento TIM come una mappa virtuale del traffico che esso mantiene in memoria per tutte le STA che si trovano in PS. Quest'ultime, ricevendo e analizzando il TIM contenuto nei beacon, possono sapere se l'AP ha del traffico in attesa destinato ad esse, ed agire di conseguenza ovvero:

• In una BSS operante col metodo DCF, o durante il CP che segue il CFP se la BSS opera col metodo PCF, la STA in PS trasmette un frame di tipo PS-Poll (Power Save Poll) all'AP per segnalare che è pronta a ricevere il traffico bufferizzato nell'AP stesso. L'AP risponde subito con la MSDU bufferizzata oppure può confermare (ACK) la ricezione del frame PS-Poll e rispondere più tardi.
• Se il TIM indica che il frame bufferizzato verrà inviato durante il CFP, la STA (che sarà dunque una STA CF-Pollable), non manderà alcun frame PS-Poll, ma aspetterà il proprio turno all'interno del CFP per ricevere il traffico bufferizzato nell'AP, rimanendo in AM per tutta la durata del CFP stesso.

Nel caso in cui almeno una STA della BSS sia in PS, l'AP deve bufferizzare tutto il traffico broadcast e multicast e trasmetterlo alla STA (o alle STA) immediatamente dopo la trasmissione del primo beacon che contiene un'indicazione di tipo DTIM (vedi pagina pageref).

Una STA che ritorna dallo stato Doze allo stato Awake deve compiere una procedura di Clear Channel Assesment (CCA), con la quale può riconoscere correttamente una sequenza di frame in corso e impostare il proprio NAV.

Definizione dei TIM

Un elemento TIM contiene una mappa virtuale delle STA in PS per le quali l'AP mantiene del traffico bufferizzato. In aggiunta, il TIM indica anche la presenza di traffico bufferizzato di tipo broadcast o multicast.

Ad ogni STA in una WLAN con infrastruttura viene assegnato, in fase di associazione, un identificativo AID. E' proprio tramite questo AID che l'AP costruisce il TIM. L'AID=0 è riservato al traffico broadcast o multicast bufferizzato.

Possiamo distinguere due tipi di TIM:

*  TIM

E' un elemento TIM standard che viene incluso in ogni frame di tipo beacon.

*  DTIM

E' un elemento TIM trasmesso al posto di un TIM normale, ad intervalli pari al valore del parametro DTIMPeriod. Immediatamente dopo la trasmissione di un beacon con un elemento DTIM, l'AP deve mandare tutto il traffico bufferizzato di tipo broadcast e multicast, prima di cominciare ad inviare quello unicast.

La figura 4.20 illustra una situazione possibile, con l'ipotesi che venga trasmesso un elemento DTIM ogni 3 elementi TIM. La linea più in alto rappresenta l'asse dei tempi. La linea immediatamente sotto illustra l'attività dell'AP. Quest'ultimo programma la trasmissione di un beacon affinché avvenga ad ogni istante TBTT (ovvero ad intervalli Beacon Interval). Siccome il mezzo può essere occupato nell'istante TBTT, quindi la trasmissione del beacon può essere ritardata. Notiamo che:

• subito dopo un beacon contenente un elemento DTIM, l'AP trasmette tutto il traffico broadcast bufferizzato.
• la STA in PS la cui attività nel tempo è descritta dalla terza linea ???? CHIEDERE

Funzione Aging

L'AP implementa una funzione cosiddetta di aging, che serve a cancellare il traffico che ha bufferizzato per un periodo di tempo troppo lungo. Questa funzione dev'essere basata sul parametro ListenInterval di ciascuna STA, ovvero la funzione dev'essere tale da non cancellare il traffico prima che sia passato un intervallo pari a ListenInterval. La definizione di una tale funzione è comunque fuori dalla trattazione dello standard IEEE 802.11.

4.6.2  Power management in una WLAN ad hoc (IBSS)

La gestione della modalità power save nelle WLAN IEEE 802.11 ad hoc è simile a quella vista per le WLAN che hanno una topologia con infrastruttura, ovvero le STA conservano in un buffer il traffico unicast e multicast destinato a STA che si trovano in modalità PS, e tale traffico viene annunciato, prima di essere inviato, in periodi prestabiliti nei quali tutte le STA, anche quelle in PS appunto, sono in ascolto. Il suddetto annuncio viene fatto tramite un frame dedicato alle WLAN ad hoc, il cosiddetto ATIM (Ad hoc Traffic Indication Map)⁷².

Facendo riferimento alla figura 4.21, si definisce ATIM Window l'intervallo di tempo in cui tutte le STA, incluso quelle in PS, sono nello stato Awake. La durata della ATIM Window è specificata dal parametro ATIMWindow (che si trova nell'elemento IBSS Parameter Set dei frame di tipo beacon e probe response⁷³). Essa inizia subito dopo l'istante TBTT e durante questa finestra temporale possono essere trasmessi solo frame di tipo beacon o ATIM. Quando una STA deve inviare una o più MSDU ad un'altra STA che si trova in modalità PS, essa deve innanzitutto inviare verso la STA in PS un frame ATIM durante l'ATIM Window. Sempre nella figura 4.21, osserviamo come la STA A abbia la necessità di inviare un frame alla STA B che si trova in PS. Allora, durante l'ATIM Window, la STA A invia un frame ATIM direttamente indirizzato alla STA B, che si trova nello stato Awake per tutta la durata dell'ATIM Window. La ricezione di un ATIM di tipo diretto (unicast) dev'essere confermata dalla STA ricevente (con un frame di tipo ACK); in caso contrario, la STA trasmittente tenta la ritrasmissione effettuando una procedura di backoff, sempre all'interno della ATIM Window. I frame di tipo ATIM di tipo multicast non prevedono alcuna conferma. La STA B, ricevendo un ATIM ad essa indirizzato, innanzitutto conferma tale ricezione con un frame ACK diretto alla STA A, e poi rimane nello stato Awake per tutta la durata del beacon interval corrente, in attesa di ricevere la (o le) MSDU che la STA A deve inviarle. Se una STA in PS non riceve alcun frame ATIM durante l'ATIM Window, può tornare nello stato Doze alla fine della ATIM Window, fino al prossimo istante TBTT ovvero all'inizio della successiva ATIM Window.

Quindi, alla fine della ATIM Window, possono iniziare le trasmissioni di tutti i frame unicast che sono stati annunciati con successo (ovvero quelli i cui relativi ATIM sono stati confermati con l'ACK) durante l'ATIM Window, e possono iniziare le trasmissioni di tutti i frame multicast e broadcast annunciati durante l'ATIM Window. La trasmissione di questi frame segue le regole del metodo d'accesso DCF⁷⁴.

Nella IBSS, a causa della mancanza di un'entità quale un AP che coordini la WLAN, una STA può soltanto stimare lo stato (AM o PS) di una qualsiasi altra STA nella IBSS. Il modo in cui una STA compie questa stima è fuori dalle specifiche dello standard IEEE 802.11, anche se viene consigliato di basarsi sulle informazioni relative al power management (bit Power Management nel Frame Control Field) trasmesse dalle altre STA, oppure anche su informazioni quali una cronologia delle trasmissioni riuscite e fallite verso le altre STA. In quest'ultimo caso, l'uso del meccanismo RTS/CTS in una IBSS può facilitare le stima dello stato PS delle STA: se un frame RTS viene inviato ma non viene ricevuto un frame CTS, la STA mittente può dedurre che la STA destinataria sia in modalità PS.

4.7  Procedure di Scan e Join

Le procedure di scan e join sono realizzate da una serie di funzioni o primitive.

Una primitiva (in figura rappresentate come frecce) è una procedura che permette di attivare ed usufruire dei servizi forniti dal livello inferiore di un certo protocollo organizzato a livelli. In particolare le primitive usate per le procedure di scan sono:

• MLME-SCAN.Request⁷⁵
• MLME-SCAN.Confirm

Lo standard IEEE 802.11 prevede 2 tipi di scan:

1. Active (attivo)
2. Passive (passivo)

Lo scan può essere utilizzato dunque per:

• trovare una rete ed connettersi ad essa
• trovare un nuovo AP (Roaming)
• inizializzare una IBSS (ad hoc network)

Successivamente alla procedura di scan, tramite la quale si ricercano le BSS e si acquisiscono i loro parametri, una STA può decidere di effettuare una procedura di join, per richiedere di entrare a far parte di una specifica BSS fra quelle trovate. Le primitive usate per le procedure di scan sono:

• MLME-JOIN.Request
• MLME-JOIN.Confirm

4.7.1  Scan passivo

Se si sceglie questo tipo di scan, la STA si mette in ascolto su ciascun canale specificato nella ChannelList della primitiva MLME-SCAN.Request (vedi 4.7.2), per il tempo specificato sempre nella suddetta primitiva, aspettando di riconoscere dei frame di tipo Beacon contenenti il particolare SSID⁷⁶ scelto, oppure aspettando di riconoscere un Beacon con l'SSID broadcast, a seconda di quanto specificato nella primitiva MLME-SCAN.Request. Alla fine dello scan, ovvero quando tutti i canali scelti sono stati esaminati, viene usata la primitiva MLME-SCAN.Confirm per conservare tutte le informazioni raccolte, a beneficio di un'eventuale successiva procedura di join.

4.7.2  Scan Attivo

Questa modalità di scan implica la generazione di frame di tipo Probe e la successiva elaborazione dei frame Probe Response. Al momento della ricezione della primitiva MLME-SCAN.Request con il parametro ScanType che indica uno scan attivo, una STA deve compiere la seguente procedura:

Per ciascun canale da esaminare,

• aspetta che trascorra il tempo indicato dal parametro ProbeDelay;
• ottiene l'accesso al mezzo secondo le regole del metodo DCF;
• invia un frame di tipo Probe Request con l'indirizzo broadcast , il SSID e il BSSID broadcast;
• resetta e fa partire un ProbeTimer
• la STA continua a mandare frame di tipo Probe finchè rileva il mezzo libero e il ProbeTimer risulta inferiore al valore MinChannelTime, dopodichè la STA resetta il proprio NAV e passa ad esaminare il successivo canale. Può capitare che la STA rilevi il mezzo occupato quando tenta di mandare frame di tipo Probe Request, quindi ritarda la trasmissione dei suddetti frame ma rimane su quel canale al massimo fino a che il ProbeTimer raggiunge il valore MaxChannelTime, dopodichè raccoglie tutte le risposte ottenute e passa ad esaminare il canale successivo.
• resetta il proprio NAV e passa ad esaminare il canale successivo.

Regole per l'invio dei frame Probe Response

Una STA che riceve un frame di tipo Probe Request deve rispondere con un frame di tipo Probe Response solo se il valore SSID nel probe request è il SSID di tipo broadcast oppure se coincide esattamente con il proprio SSID. I frame di tipo probe response vanno indirizzati direttamente alla STA che ha inviato i frame probe request, e vanno inviati secondo le regole del metodo DCF. Anche un AP deve rispondere ad un probe response secondo le regole appena descritte. In una IBSS invece, è la STA che ha generato l'ultimo beacon che ha il compito di rispondere ai frame probe response. In questa situazione, vi è la possibilità che più di una STA in una IBSS risponda ai probe request, poichè è possibile che più di una STA nella IBSS invii un beacon.

In ogni BSS, in un dato momento, dev'esserci almeno una STA nello stato Awake (ovvero in modalità AM), per rispondere ai probe request. Una STA che invia un beacon, deve rimanere nello stato Awake e rispondere ai probe request fino a che non riceve un altro beacon con il valore BSSID corrente. Nel caso in cui la STA che invia un beacon sia un AP, esso deve sempre rimanere nello stato Awake per rispondere ai probe request.

*  Primitiva MLME-SCAN.Request

Questa primitiva supporta il processo di scan per la ricerca di BSS nel raggio di copertura di una STA. Tale primitiva viene invocata con i seguenti parametri:

*  Primitiva MLME-SCAN.confirm

Questa primitiva restituisce la descrizione dell'insieme delle BSS rilevate durante il processo di scan. Tale primitiva viene invocata con i seguenti parametri:

*  Primitiva MLME-JOIN.Request

Questa primitiva serve a richiedere la sincronizzazione e quindi l'ingresso in una BSS da parte di una nuova STA. I parametri di questa primitiva sono:

*  Primitiva MLME-JOIN.Confirm

Questa primitiva conferma l'avvenuta sincronizzazione con una BSS. Questa primitiva richiede i seguenti parametri:

4.7.3  Roaming

La topologia con infrastruttura consente l'implementazione di un sistema per la gestione delle transizioni delle stazioni mobili da una BSS ad un altra (roaming). Lo standard fornisce come supporto la procedura di Riassociazione. Quando un terminale mobile IEEE 802.11 decide di spostarsi da una BSS ad un'altra nelle vicinanze, tipicamente per migliorare le condizioni di ricezione come avviene nelle reti cellulari, compie una procedura di scan, come visto a pagina pageref, alla fine della quale possiede una lista di AP che può ordinare ad esempio in base alla qualità del segnale. Una volta scelto l'AP verso cui ha deciso di spostarsi, invia una richiesta (un frame Reassociation Request) verso questo AP. Il frame Reassociation Request contiene anche l'indirizzo MAC dell'AP cui la stazione è correntemente associata. Successivamente, l'AP prescelto invia alla stazione un frame Reassociation Response, comunicandole l'esito della procedura.

Possiamo osservare che:

• lo standard specifica che l'AP verso cui una stazione si è spostata, riassociandosi, deve comunicare al sistema di distribuzione l'avvenuta riassociazione, cosicchè il sistema di distribuzione può sempre univocamente determinare un AP che serve la stazione che si è spostata da una BSS ad un'altra. In pratica deve avvenire uno scambio d'informazioni tra i due AP coinvolti nell'operazione di roaming. Tutto questo non fa comunque parte dello standard, cosicchè sono stati sviluppate molte soluzioni proprietarie. Vi è comunque un particolare Task Group (IEEE 802.11f) all'interno dell'organizzazione IEEE che sta studiando un protocollo, al momento in fase di bozza, detto IAPP (inter access point protocol) per standardizzare questa procedura.

4.8  Formato dei pacchetti

Ciascun pacchetto MAC (o frame come lo abbiamo chiamato finora), è composto dai seguenti componenti base:

1. MAC Header: che comprende informazioni di controllo, informazioni sugli indirizzi mittente e destinatario etc.
2. Frame Body: di lunghezza variabile, contiene informazioni relative al tipo di frame specificato nell'header (ad esempio, se il frame è di tipo dati il frame body conterrà i dati stessi, ovvero il payload).
3. Frame Check Sequence (FCS): è il CRC a 32 bit usato per rilevare gli errori di ricezione.

4.8.1  Formato generale dei frame

La figura 4.24 illustra il formato dei frame MAC del protocollo IEEE 802.11:

I campi: Address 1, Address 2, Address 3, Sequence Control, Address 4 e Frame Body sono presenti solo in alcuni tipi di frame.

4.8.2  Descrizione dei campi

Frame control

La figura 4.25, mostra il contenuto del campo frame control incluso nell'header:

E' opportuno analizzare alcuni campi di maggiore importanza:

Campi Type e Subtype  

Lo standard prevede 3 tipi di frame: data, control e management. Ciascuno dei tipi ha a sua volta molti sottotipi e questi possono essere riassunti nelle tabelle 4.16 e 4.17:

Campi ToDS e FromDS  

Le diverse combinazioni dei campi ToDS e FromDS e i loro significati possono essere riassunti nella seguente tabella:

Campo More Fragments  

Questo bit, se posto ad 1, indica che il frame corrente è una parte (MPDU) di un messaggio (MSDU) che è stato frammentato a livello MAC, e quindi seguiranno altri frammenti dello stesso messaggio. Il suo valore è 0 in tutti gli altri casi.

Campo Retry  

Il bit retry è posto a 1 se il frame corrente rappresenta una ritrasmissione di un frame precedente. Questo è utile nella rilevazione dei frame duplicati, come abbiamo visto in 66.

Campo WEP  

Il bit WEP, se settato a 1, indica che il Frame Body (ovvero il payload) contiene delle informazioni che sono state cifrate con l'algoritmo WEP. Solo i frame del tipo Data e del tipo Management, sottotipo Authentication, possono avere il bit WEP settato a 1, tutti gli altri frame hanno tale bit settato a 0. Se il bit WEP è settato a 1, il frame body aumenta di dimensione come si vede dalla figura 4.26:

Il processo di cifratura espande il frame body di 8 bytes.

Campo Duration/ID

Le dimensioni di questo campo sono 16 bit e il suo contenuto può essere riassunto dalla tabella seguente:

Come già visto, il campo Duration/ID è usato per aggiornare il NAV delle STA che accedono al mezzo secondo le regole del metodo DCF.

Campi di tipo Address

Nell'header dei pacchetti MAC IEEE 802.11 vi sono 4 campi dedicati agli indirizzi, ciascuno dei quali contiene un indirizzo a 48 bit conforme allo standard IEEE Std 802-1990. Un indirizzo MAC può essere di 2 tipi:

1. Indirizzo individuale. L'indirizzo associato ad una particolare STA nella rete.
2. Indirizzo di gruppo. Un indirizzo relativo a destinazioni multiple. Anche qui abbiamo 2 sottotipi:

• Multicast. Un indirizzo associato, a livello superiore al MAC, ad un gruppo di STA della rete.
• Broadcast. Un particolare indirizzo multicast che indirizza tutte le STA appartenenti ad una specifica LAN. Quando i bit del campo Destination Address sono tutti pari a 1, questa situazione viene interpretata come un trasferimento broadcast.

I suddetti 4 campi dedicati agli indirizzi possono contenere una delle seguenti indicazioni: BSSID (BSS Identifier), Destination Address (DA), Source Address (SA), Trasmitter Address (TA) e Receiver Address (RA), sebbene alcuni frame possano non contenere alcuni dei campi d'indirizzo.

In alcuni casi, l'uso di un particolare campo d' indirizzo è direttamente collegato alla sua posizione (1-4) all'interno dell'header del frame MAC. Ad esempio, quando una STA vuole confrontare il proprio indirizzo con l'indirizzo destinazione di un frame, controlla sempre il contenuto del campo Address 1, oppure l'indirizzo del ricevente (ovvero della STA destinataria immediatamente successiva) dei frame CTS e ACK è sempre ottenuta dal campo Address 2 nel corrispondente frame RTS o nel frame che si sta confermando con l'ACK.

BSSID  

Questo campo rappresenta un indirizzo a 48 bit avente lo stesso formato degli indirizzi MAC IEEE 802, che identifica univocamente ciascuna BSS. Se quest'ultima possiede un'infrastruttura, ovvero è presente l'AP, il campo BSSID rappresenta l'indirizzo MAC della STA in cui risiede l'AP.

In una IBSS, quest'indirizzo viene generato casualmente.

Il valore pari a tutti 1 del campo BSSID, rappresenta una situazione di broadcast per tutte le BSS. Può essere usato solo nei frame di tipo probe request (vedi 4.7).

Destination address (DA)  

Il campo DA contiene un indirizzo MAC (individuale o di gruppo) che identifica la (o le) entità MAC intese come destinataria (o destinatarie) finale della MSDU (o del singolo frammento MPDU) contenuto nel frame body.

Source Address (SA)  

Il campo SA contiene un indirizzo MAC individuale che identifica l'entità MAC dalla quale ha avuto origine la trsmissione della MSDU (o MPDU).

Receiver Address (RA)  

Il campo RA contiene un indirizzo MAC (individuale o di gruppo) che identifica l'entità (o le entità) MAC che, relativamente al WM (Wireless Medium), sarà l'immediata destinataria del frame body corrente.

Trasmitter Address (TA)  

Il campo TA contiene un indirizzo MAC individuale che identifica la STA che ha trasmesso, relativamente al WM, la MPDU contenuta nel frame body.

Campo Sequence control

Il campo Sequence Control è costituito da 16 bit: 12 bit di Sequence Number e 4 bit di Fragment Number.

Il campo sequence number contiene il numero di sequenza di una MSDU o di una MMPDU. Ad ogni MSDU o MMPDU trasmessa da una STA viene assegnato un sequence number, tramite un contatore modulo 4096, che parte da 1 e viene incrementato di uno per ogni MSDU o MMPDU. Ciascun frammento della stessa MSDU o MMPDU contiene lo stesso sequence number che è stato assegnato a quella MSDU o MMPDU. Il sequence number rimane invariato per tutte le ritrasmissioni della MSDU o MMPDU oppure di uno dei loro frammenti.

Il campo fragment number indica il singolo frammento di una MSDU o MMPDU. Tale campo è 0 per il primo frammento di una MSDU o MMPDU e viene incrementato di uno per ogni frammento trasmesso. Rimane tuttavia costante durante le ritrasmissioni di uno stesso frammento.

Campo FCS

Questo campo contiene un codice CRC (Cyclic Redundancy Check) a 32 bit, calcolato su tutti i campi dell'header e del frame body. Il polinomio generatore del FCS è:

G(x)=x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1

4.8.3  Descrizione di alcuni frame importanti

E' utile, a titolo di esempio, riportare la composizione di alcuni frame che abbiamo visto essere importanti per il corretto funzionamento di una WLAN IEEE 802.11

Composizione dei frame di tipo dati  

La composizione di un frame di tipo dati non dipende non varia a seconda dei sottotipi, ed è definito dalla figura 4.27:

Il contenuto dei campi d'indirizzo dipende dai valori dei campi ToDS e FromDS, come si vede dalla tabella 4.20, e ricordando che i valori ToDS e FromDS possono essere interpretati come da tabella 4.18:

Quando il contenuto del campo è N/A, il campo stesso è omesso. Il campo Address 1 contiene sempre l'indirizzo MAC del destinatario del frame, mentre il campo Address 2 contiene sempre l'indirizzo MAC della STA che sta trasmettendo il frame.

Una STA usa in contenuto del campo Address 1 per capire se il frame è ad essa indirizzato. Nel caso in cui il campo Address 1 contenga un indirizzo di gruppo (multicast o broadcast), viene esaminato anche il valore BSSID⁷⁷ per capire se il frame multicast o broadcast ha avuto origine nella stessa BSS della STA ricevente.

Una STA usa il contenuto del campo Address 2 per indirizzare il frame ACK, quando richiesto.

RA è l'indirizzo MAC del'AP che nel sistema di distribuzione wireless è l'immediato destinatario del frame, o del frammento. TA invece è l'indirizzo MAC dell'AP che, sempre nel sistema di distribuzione wireless, è l'immediato mittente del frame o del frammento.

Il valore BSSID viene così interpretato:

• se la WLAN è di tipo ``con infrastruttura'', il BSSID coincide con l'indirizzo MAC della STA IEEE 802.11 che funziona da AP;
• se la WLAN è una rete ad hoc (IBSS), il BSSID è l'identificativo della IBSS (scelto casualmente).

Il frame body consiste nell'MSDU (o in un suo frammento MPDU) più i campi aggiunti dal WEP nel caso sia stata attivata quest'opzione. Il frame body è nullo nei frame Null, CF-ACK, CF-Poll, e CF-ACK+CF-Poll.

Il campo Duration viene inizializzato come segue:

• Per tutti i frame inviati durante il CFP, viene impostato al valore 32768
• Per i frame inviati durante il CP:

1. Se il campo Address 1 contiene un indirizzo di gruppo, il campo Duration viene azzerato.
2. Se il campo More Fragments è 0 nel Frame Control Field e il campo Address 1 contiene un indirizzo individuale, nel campo Duration viene scritta la durata, in microsecondi, necessaria per trasmettere un frame ACK più un intervallo SIFS⁷⁸.
3. Se il campo More Fragments è settato a 1 nel Frame Control Field (dunque si tratta di un frammento di MSDU) e il campo Address 1 contiene un indirizzo individuale, nel campo Duration viene scritta la durata, in microsecondi, necessaria a trasmettere il successivo frammenti delle MSDU in questione più 2 frame ACK più 3 intervalli SIFS.

Composizione generale dei frame di tipo Management  

Anche la composizione dei frame di tipo Management non varia a seconda dei diversi sottotipi. Possiamo osservare tale composizione in figura 4.28:

Il frame body è composto in parte da campi di dimensione fissata, ed in parte da elementi informativi, ovvero raggruppamenti di più dati che possono avere dimensione variabile. Alcuni campi o elementi informativi sono obbligatori ed è obbligatorio anche l'ordine in cui devono comparire all'interno del frame body.

4.9  Livello fisico (PHY) del protocollo IEEE 802.11

Lo standard IEEE 802.11, prevede 3 diverse implementazioni del livello fisico che consente il trasporto delle informazioni tra le STA di una WLAN compatibili:

• IR Infrarosso
• FHSS Frequency Hopping Spread Spectrum (Radiofrequenza)
• DSSS Direct Sequence Spread Spectrum (Radiofrequenza)

Il livello PHY è costituito dalle seguenti 2 funzioni:

• PLCP (Physical Layer Convergence Function) che, grazie alla procedura PLCP (Physical Layer Convergence Procedure), mappa le MPDU IEEE 802.11 (Mac Protocol Data Unit) in frame dal formato compatibile con il sistema PMD (vedi a seguito) ed in generale semplifica l'interfaccia tra il MAC ed il livello PHY.
• PMD (Physical Medium Dependent) è un sistema che definisce le caratteristiche di un mezzo trasmissivo wireless (WM) e definisce i metodi per trasmettere e ricevere dati attraverso tale mezzo trasmissivo, oltre a fornire funzioni CCA (Clear Channel Assessment).

Nelle sezioni successive analizziamo le implementazioni FHSS e DSSS, poichè sono le più usate nei dispositivi commerciali.

4.9.1  IEEE 802.11 FHSS

Abbiamo già visto nell'Introduzione i principi generali di un sistema di trasmissione a RF (Radiofrequenza) che adotti la tecnica denominata Frequency Hopping.

Le caratteristiche del PHY FHSS specificato dallo standard IEEE 802.11 sono esaminate di seguito.

Bande operative

Il PHY IEEE 802.11 FHSS è stato definito per operare nella banda ISM 2.4 GHz. Per le normative europee si veda la tabella (RIF a quella dell'introduzione anche se andrebbe rifatta come da tabella pag 123 dello standard).

L'intervallo di frequenze utilizzabile dai dispositivi che usano questo PHY è specificato, relativamente alla posizione geografica, nella seguente tabella:

Come si vede dalla tabella 4.21, in Europa (escluse Francia e Spagna) sono definite 79 canali di hop, non sovrapposti e spaziati di 1 MHz.

Livelli di potenza di emissione

In Europa, il limite imposto alla potenza di trasmissione dei dispositivi IEEE 802.11 è 100 mW EIRP⁷⁹. Lo standard impone inoltre che tutti i dispositivi realizzati in conformità con esso debbano supportare almeno un livello di potenza trasmessa pari a 10 mw EIRP.

Nel caso in cui si realizzasse un dispositivo conforme allo standard, ma con la capacità di trasmettere segnali di potenza maggiore di 100 mW EIRP, dev'essere implementato un meccanismo di controllo della potenza di trasmissione che operi in modo da ridurre la potenza del segnale trasmesso ad un livello minore o uguale a 100 mW, quando necessario.

Modulazione del segnale

La trasmissione del segnale avviene usando la modulazione GFSK (Gaussian shaped Frequency Shift Keying) con un prodotto BT (bandwitdh-time) pari a 0.5; in particolare:

*  2-GFSK

Questa modulazione prevede che il simbolo 1 venga codificato con una deviazione positiva (+f_d), rispetto alla portante F_c, mentre prevede che il simbolo 0 venga codificato con una deviazione negativa (−f_d), rispetto alla portante. La velocità di segnalazione (F_clk) è pari ad 1 Msimbolo/s, cosicchè otteniamo una velocità di trasferimento (data-rate) pari a 1 Mbit/s. Il fattore di deviazione h₂ (definito come la differenza tra le frequenze al centro delle sequenze 0000 e 1111 diviso per 1 MHz), è 0.32. Quindi si ha:

*  4-GFSK

Questa modulazione prevede la seguente codifica:

Ove h₄=0.45×h₂=0.144. Questa codifica consente di raddoppiare il data rate: la velocità di segnalazione è sempre 1 Msimbolo/s , ma ogni simbolo codifica 2 bit di informazione e quindi otteniamo un data rate di 2Mbit/s.

Generazione delle sequenze di hopping

Facciamo in seguito riferimento a sistemi che possiedono 79 canali di hop (USA e Europa tranne Francia e Spagna). Ogni singola entità PMD (ovvero ogni STA) genera una sequenza pseudocasuale composta da 79 hop. Sono previste 78 diverse sequenze, organizzate in 3 insiemi da 26 sequenze ciascuno. L'algoritmo di generazione assicura una distanza minima di 6 canali tra due hop consecutivi. I 3 insiemi da 26 sequenze sono stati pensati per facilitare l'allocazione di più reti nella stessa area; il rischio di collisioni tra pacchetti trasmessi da STA che operano in reti WLAN che usano sequenze di hopping appartenenti a insiemi diversi è minimo, e alcuni test indicano che il throughput non degrada sensibilmente anche se si collocano fino a 15 diverse reti nella stessa area.

Definiamo F_x lo schema composto dalle 79 frequenze di hop per una specifica WLAN (o BSS, ovviamente tutte le STA della WLAN adottano lo stesso schema F_x).

Fx={ fx(1),fx(2),...,fx(p)}

ove:

• f_x(i) è il numero del canale per la i-esima frequenza dell'x-esimo schema di hopping
• p è il numero dei canali disponibili (nel nostro caso p=79)

La frequenza f_x(i) viene calcolata così:

fx(i)=[b(i)+x]mod (79)+2

ove b(i) rappresenta l'i-esimo elemento della cosiddetta base hopping sequence, definita, sempre nel caso dei sistemi con 79 hop, dalla seguente tabella:

Come abbiamo già detto, sono definiti nello standard 78 schemi (o sequenze) di hopping, ovvero 78 permutazioni delle 79 frequenze disponibili, organizzati in 3 insiemi da 26 schemi ciascuno. Questi insiemi sono:

1. x={ 0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75}
2. x={ 1,4,7,10,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58,61,64,67,70,73,76}
3. x={ 2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59,62,65,68,71,74,77}

Facciamo un esempio per chiarire meglio: supponiamo che una STA operi in una WLAN che adotta lo schema 33 che appartiene al set 1, mentre un altra STA operi in un'altra WLAN collocata nella stessa area della prima WLAN ma adottando lo schema 71, che appartiene al set 3. Allora gli hop della prima STA saranno definiti dalla relazione:

F33={ f33(1),f33(2),...,f33(79)}

e

f33(1)=[b(1)+33]mod (79)+2=0+33+2=35⇒2.435 GHz

f33(2)=[b(2)+33]mod (79)+2=23+33+2=58⇒2.458 GHz

e cosi via. Come si vede, tra gli hop 1 e 2 vi è una distanza di 23 MHz, e questo è utile per ridurre la possibilità di collisioni successive: se il canale 1 (f=2.435 GHz) risultasse disturbato ed il pacchetto trasmesso utilizzando quella frequenza non venisse inviato o ricevuto correttamente, la successiva ritrasmissione avvererebbe sul canale 2 (f=2.458 GHz) che dista dal primo 23 MHz e, presumibilmente, non è coinvolto nei disturbi che agivano sul canale 1. Allo stesso tempo, osserviamo la sequenza generata per la seconda WLAN, sovrapposta geograficamente alla prima, ma che utilizza lo schema 71 del set 3:

F71={ f71(1),f71(2),...,f71(79)}

e

f71(1)=[b(1)+71]mod (79)+2=0+71+2=73⇒2.473 GHz

f71(2)=[b(2)+71]mod (79)+2=15+2=17⇒2.417 GHz

e cosi via. Come si vede, vale lo stesso discorso fatto per la prima WLAN per quel che riguarda le interferenze sui singoli canali; inoltre le frequenze che fanno parte dello schema scelto dalla seconda WLAN saranno per la maggior parte differenti da quelle che fanno parte dello schema scelto dalla prima WLAN, cosicchè si minimizza il rischio di collisione tra i pacchetti delle diverse WLAN.

Hop Rate

L'hop rate, ovvero la frequenza con la quale viene cambiato il canale di hop è 2.5 hop/s (quindi la frequenza operativa cambia ogni 400 ms).

Formato dei pacchetti PLCP

Il formato dei pacchetti PLCP è descritto dalla figura seguente:

Il PLCP Preamble viene trasmesso sempre a 1Mbps e dev'essere completato in 96μs. Contiene delle informazioni utili per la compensazione dell'offset di frequenza, l'aggiustamento del guadagno, selezione dell'antenna. Il campo SFD (start frame delimiter) è una sequenza prefissata di bit che segnala l'inizio vero e proprio del frame. Il PLCP Header viene trasmesso sempre a 1 Mbps e dev'essere completato in 32μs. PLW specifica il numero di byte contenuti nella PSDU, mentre PSF specifica il data rate utilizzato per trasmettere la PSDU.

4.9.2  IEEE 802.11 DSSS

Ancora una volta, possiamo far riferimento a quanto visto nell'Introduzione per quello che riguarda l'implementazione Direct Sequence della tecnica Spread Spectrum. Le caratteristiche del PHY DSSS dello standard IEEE 802.11 sono esaminate nel seguito.

Bande operative

Il PHY IEEE 802.11 DSSS è stato definito per operare nella banda ISM 2.4 GHz⁸⁰. Per le normative europee si veda la tabella (RIF a quella dell'introduzione anche se andrebbe rifatta come da tabella pag 123 dello standard). La tabella seguente riporta le frequenze centrali e gli identificativi (CHNL_ID) dei canali disponibili:

Ogni canale ha un'ampiezza di 22 MHz⁸¹. Nel caso in cui si vogliano allocare nella stessa area più WLAN, per limitare l'interferenza reciproca, è necessario che le frequenze centrali dei canali di ogni WLAN siano spaziate di almeno 25 MHz.

Codifica

Il PHY DSSS dello standard IEEE 802.11 usa, per codificare il flusso informativo, una particolare sequenza di Barker composta da 11 simboli (cosiddetti chip). La sequenza scelta è:

+1,−1,+1,+1,−1,+1,+1,+1,−1,−1,−1

Le sequenze di Barker⁸² possiedono buone proprietà di correlazione aperiodica, che significa semplicemente che, a causa del comportamento non ripetitivo del codice di Barker, un filtro a comparazione può facilmente riconoscere il codice di Barker in una sequenza di bit.

Modulazioni e data rate

Lo standard specifica 2 modulazioni e 2 data rate associati alle modulazioni stesse, per il PHY DSSS: un basic access rate, basato sulla modulazione DBPSK (Differential Binary Phase Shift Keying), ed un enhanced access rate, basato sulla modulazione QBPSK (Quadrature Binary Phase Shift Keying).

La velocità di modulazione è pari a 1Msimbolo/s. Un simbolo è composto dagli 11 chips della sequenza di Barker vista. Se si sceglie la modulazione DBPSK, si ottiene un data rate pari a 1 Mb/s, poichè ogni simbolo codifica 1 bit d'informazione. Se invece si sceglie la modulazione QBPSK, si ottiene un data rate di 2 Mb/s, poichè ogni simbolo codifica 2 bit d'informazione.

Spettro del segnale modulato

La figura 4.34 mostra lo spettro del segnale DSSS prima e dopo lo spreading.

Si noti che lo spettro ha la forma di un inviluppo dall'espressione:

(  sinx x )2

La modulazione (ovvero la somma modulo 2 del segnale in banda base e della sequenza di barker), effettivamente espande il segnale su una banda più ampia. Il lobo principale della figura 4.34 è una funzione della forma d'onda modulante e della velocità di chipping. Una regola comunemente usata nei sistemi DSSS consiste nel fissare la banda null to null ⁸³ al doppio del valore della velocità di chipping. Usando quindi una sequenza di Barker a 11 chip, con un chip rate di 11 Mcps (mega chip per second), la banda null to null del segnale espanso risulta 22MHz. Questo consente di allocare nella banda ISM 2.4 GHz fino a 3 canali DSSS non sovrapposti.

Formato dei pacchetti PLCP

Il formato dei pacchetti PLCP è descritto dalla figura seguente:

Sia il PLCP Preamble che il PLCP Header devono essere trasmessi a 1Mbps.

4.9.3  IEEE 802.11 Hi-Rate DSSS

Nel 1998, Lucent Technologies e Harris Semiconductor (ora parte della Intersil Corp.) proposero all'istituto IEEE l'inserimento nello standard della tecnica di codifica CCK (Complementary Code Keying), la quale, utilizzata per effettuare lo spreading dei segnali nell'implementazione PHY DSSS al posto della sequenza di Barker, consentiva di raggiungere velocità di trasferimento dei dati di 5.5 Mbps e 11 Mbps. L'istituto IEEE accettò tale proposta e, nel 1999, venne rilasciata la specifica IEEE 802.11b, che non prevede modifiche al livello MAC, ma introduce sostanziali novità per l'implementazione DSSS del livello PHY.

CCK

I codici CCK usati nello standard IEEE 802.11b per effettuare lo spreading dei segnali per il PHY DSSS, appartengono alla classe dei polyphase complementary codes, hanno una lunghezza di 8 chip e un chipping rate di 11Mchip/s. Quindi un simbolo è rappresentato da 8 chip complessi. Usando una velocità di segnalazione di 1.375 MSimboli/s (contro gli 1 MSimboli/s dello standard IEEE 802.11), il segnale a 11Mbps ottenuto occuperà la stessa banda del segnale a 2Mbps dello standard IEEE 802.11, consentendo quindi l'allocazione di 3 canali non sovrapposti nella banda ISM.

La code word CCK da 8 chip viene ottenuta dalla formula seguente:

c={ e^{j(ϕ₁+ϕ₂+ϕ₃+ϕ₄)},e^{j(ϕ₁+ϕ₃+ϕ₄)},e^{j(ϕ₁+ϕ₂+ϕ₄)},

Con questa formula quindi si generano i codici CCK usati per ottenere data rate di 11Mbps e 5.5Mbps⁸⁴. Scegliendo il data rate 11Mbps, gli 8 codici generati (un simbolo quindi) codificano 8 bit d'informazione, mentre per il data rate 5.5Mbps vengono trasmessi 4 bit per simbolo e quindi gli 8 codici generati codificano 4 bit d'informazione. Facciamo un esempi o riferendoci al data rate 11Mbps. Il flusso informativo viene partizionato in byte (d7,d6,d5, ...,d0), ove d0 è il LSB ed il primo bit in ordine di tempo. Questi 8 bit vengono usati per generare i parametri di fase ϕ₁−ϕ₄, come si può vedere dalla tabella seguente:

La codifica si basa sulla modulazione DQPSK (differential quadrature phase shift keying), che può essere visualizzata nella seguente tabella:

Ad esempio, se il flusso dei dati fosse d7,d6,d5, ...,d0=10110101, dalle tabelle 4.26 e 4.27, si ha che: d1,d0=01 e così ϕ₁=π, d3,d3=01 e così ϕ₂=π, d5,d4=11 e così ϕ₃=−π/2 ed infine d7,d6=10 e così ϕ₄=π/2. Riportando tali valori nella formula di c si ha:

c={ 1,−1,j,j,−j,j,−1,−1}

avendo applicato anche la formula di Eulero e^jθ=cosθ+j·sinθ.

Nonostante queste modifiche, lo standard IEEE 802.11b prevede comunque l'utilizzo della tecnica di spreading DSSS che utilizza la sequenza di Barker a 11 chip che abbiamo già visto in 4.9.2, cosicchè i dispositivi realizzati secondo lo standard IEEE 802.11b sono compatibili e quindi possono comunicare con quelli realizzati secondo lo standard IEEE 802.11.

Bande operative

Non sono state specificate modifiche alle frequenze centrali che caratterizzano i canali disponibili per la realizzazione di WLAN IEEE 802.11b. Nello standard IEEE 802.11b tuttavia, è stata aumentata a 30 MHz (contro i 25 MHz dello standard IEEE 802.11) la distanza minima tra due canali consecutivi qualora si dovesse utilizzare tali canali per allocare due diverse WLAN nella stessa area. Questo permette ancora di allocare fino a 3 WLAN con canali operativi non sovrapposti nella banda ISM 2.4GHz.

In Europa (tranne per Francia e Spagna) abbiamo le seguenti possibilità⁸⁵:

Formato dei pacchetti PLCP

Lo standard specifica due diversi tipi di PLCP Preamble e PLCP Header:

• Long Preamble e Long Header, obbligatori e necessari per l'interoperabilità con i dispositivi realizzati secondo lo standard IEEE 802.11
• Short Preamble e Short Header, opzionali.

L'utilizzo dello Short Preamble e dello Short Header è utile per ridurre l'overhead e quindi migliorare il throughput totale della rete. Lo Short Preamble viene trasmesso usando la modulazione DBPSK e la solita sequenza di Barker per lo spreading a 1Mbps. Lo Short Header viene trasmesso usando la modulazione DQPSK e la solita sequenza di Barker a 2Mbps. La PSDU viene trasmessa a 2, 5.5 oppure 11 Mbps.

Part 2
Confronto tra i protocolli IEEE802.11 e Bluetooth

Chapter 5
Confronto tra i protocolli a livello MAC

Bluetooth e IEEE 802.11 sono due protocolli che definiscono un livello fisico e un livello MAC (Media Access Control) per comunicazioni wireless a breve raggio (da pochi metri a 100 m) e a basso consumo di potenza (da meno di un mW a 100 mW). Bluetooth è orientato a connessioni fra dispositivi vicini, come sostituto dei cavi per trasporto dati, mentre IEEE 802.11 è orientato a connessioni fra computer, come estesione o sostituto delle LAN cablate. In questo capitolo ci proponiamo di confrontare le caratteristiche principali di questi due protocolli.

5.1  Creazione delle reti

Analizziamo ora le prestazioni dei protocolli Bluetooth, IEEE 802.11 e la sua evoluzione IEEE 802.11b, relativamente alla loro capacità di creare delle reti operative ed efficienti. Si noti che, da questo punto in poi, la sigla IEEE 802.11 è relativa a caratteristiche comuni alla versione IEEE 802.11b, mentre verrà usata espressamente la sigla IEEE 802.11b quando necessario. Inoltre, data l' irrilevante presenza sul mercato di dispositivi IEEE 802.11 con implementazione Frequency Hopping, faremo riferimento ai dispositivi IEEE 802.11 con implementazione Direct Sequence e Hi-Rate Direct Sequence ovvero IEEE 802.11b. Verrà esclusa dalla trattazione anche l' implementazione del livello fisico IEEE 802.11 IR (infrarosso).

5.1.1  Massima capacità

Se facciamo riferimento al ``blocco costruttivo di base'' della topologia di rete per i due protocolli, ovvero la BSS (Basic Service Set) per IEEE 802.11 e la Piconet per Bluetooth, osserviamo che la capacità in termini di numero di dispositivi che possono appartenere ad uno stesso blocco base è limitata ad 8 (1 Master e 7 Slave attivi) per Bluetooth, mentre è virtualmente illimitata per IEEE 802.11. Per estendere il numero degli appartenenti ad una piconet, in Bluetooth si può sfruttare la modalità Park, che consente di ``parcheggiare'' degli slave dando loro la possibilità di entrare nella piconet se il master lo consente. In ogni caso, questi slave in modalità park non possono partecipare attivamente alla piconet, ovvero ricevere e scambiare dati.

Entrambi i protocolli prevedono la possibilità di creare una struttura di rete più complessa a partire dai singoli blocchi base:

• ESS (Extended Service Set) per IEEE 802.11: una ESS è costituita da un certo numero di BSS interconnesse tramite un sistema di distribuzione (DS), che può essere una rete LAN cablata oppure un sistema wireless, anche un altro sistema IEEE 802.11. Le stazioni wireless possono essere mobili e spostarsi da una BSS ad un altra, all'interno della stessa ESS, mantenendo la connessione alla rete. Il sistema di distribuzione si occupa del trasporto dei dati tra BSS diverse. In ogni BSS vi sarà una particolare stazione delegata a tenere i contatti con il DS: se la BSS è di tipo ``con infrastruttura'' tale stazione verrà indicata con il nome di Access Point (AP).
• Scatternet per Bluetooth: un certo numero di piconet Bluetooth possono essere connesse a formare una scatternet. Un dispositivo Bluetooth può agire da slave in più di una piconet, cambiando i propri parametri relativi alla sequenza di hopping e dividendo il proprio tempo di operatività tra le piconet di cui fa parte, mentre può essere master in una sola piconet per volta.

Introduciamo il concetto di capacità spaziale, definita come il rapporto tra la velocità di trasferimento dati aggregata e l' unità di superficie; questo concetto è molto usato e si possono trovare dei riferimenti in
http://www.ubiq.com/hypertext/weiser/NomadicInteractive
Possiamo quindi osservare che:

• Bluetooth, a fronte di una portata radio limitata a circa 10m, consente di allocare in questo spazio fino a 10 diverse Piconet[6], ognuna con una velocità di trasferimento dati di circa 700 kbps⁸⁶.
• IEEE 802.11b, a fronte di una portata radio limitata a circa 100m, consente di allocare in questo spazio fino a 3 diverse BSS in assenza d'interferenze mutue, ognuna con una velocità di trasferimento di circa 11Mbps⁸⁷.
• E' opportuno osservare che, per quel che riguarda i sistemi che usano la tecnica Frequency Hopping Spread Spectrum (FHSS), come Bluetooth e IEEE 802.11 nella implementazione del livello fisico FHSS, un qualsiasi limite all' allocazione nella stessa area di più reti wireless è più pratico che teorico. Infatti, secondo le regole della tecnica Frequency Hopping, ogni dispositivo di una rete trasmette e riceve seguendo una specifica sequenza di canali radio, la sequenza di hopping appunto; quindi il limite teorico all' allocazione di più reti nella stessa area è da ricercarsi nell' algoritmo di generazione delle sequenze di hopping, che, di solito permette la creazione di un gran numero delle suddette sequenze.

Quindi la capacità spaziale del protocollo IEEE 802.11 (in questo caso IEEE802.11b) è pari a circa 1000 [(bits)/(sec·m²)], contro i circa 22000 [(bits)/(sec·m²)] realizzati dal protocollo Bluetooth. Questa disparità è legata soprattutto al rapporto 1/100 tra le aree di copertura che abbiamo considerato per i due protocolli: accade che il protocollo Bluetooth può allocare un maggior numero di reti indipendenti (10 contro 3) in una area 100 volte più piccola di quella considerata per il protocollo IEEE 802.11b e, similmente a quanto accade nelle reti cellulari, la somma delle capacità aggregate delle singole reti aumenta.

5.1.2  Velocità di creazione delle reti

Un altro parametro significativo per il confronto tra i due protocolli presi in esame è la velocità di creazione delle reti, ovvero la velocità con la quale vengono stabilite le connessioni tra due o più dispositivi appartenenti alla stessa piconet (per Bluetooth) o alla stessa BSS (per IEEE 802.11).

*  Il protocollo Bluetooth

mette a disposizione le procedure di Inquiry e Page, per la scoperta dei dispositivi presenti nell'area d'azione e la creazione delle reti.

   *  Procedura di Inquiry

viene usata periodicamente da un dispositivo Bluetooth Master che vuole scoprire gli indirizzi MAC di eventuali altri dispositivi Bluetooth Slave che si trovino nel suo raggio d'azione.

Esiste la possibilità di realizzare dei dispositivi con indirizzi MAC conosciuti a priori⁸⁸, per i quali non è necessaria la procedura di Inquiry. In questo caso è sufficiente la procedura di Page per creare la piconet e quindi stabilire le connessioni.

   *  Procedura di Page

La procedura di Page viene usata da un dispositivo Bluetooth Master per inserire uno specifico dispositivo Slave nella piconet, sfruttando le informazioni sugli indirizzi MAC e sui clock delle unità, raccolte durante la procedura di Inquiry o comunque già noti.

Per creare una piconet con il massimo numero di dispositivi ammissibili, nell' ipotesi di assenza di interferenze esterne alla rete, è necessario un tempo medio di circa 5 secondi per la fase di Inquiry più circa altri 0.64 secondi per ognuna delle fasi di page (una per ognuno dei sette slave).

*  Il protocollo IEEE 802.11

prevede le procedure di Scan, Autenticazione e Associazione.

   *  Procedura di Scan

La procedura di Scan può essere effettuata in modalità Passiva o Attiva, e serve a conoscere gli indirizzi MAC ed altri parametri relativi alla sincronizzazione corrispondenti a stazioni IEEE 802.11 che si trovano nel raggio d'azione del terminale.

Il tempo medio di scoperta dei dispositivi con la modalità di scan passivo è pari a 50ms moltiplicato per il numero di canali che si intende osservare. Il valore 50ms rappresenta la metà del valore tipicamente assegnato al parametro BeaconPeriod (valore minimo: 1 Time Unit=1024μs). Secondo questa modalità infatti, la stazione si mette in ascolto su un certo numero di canali, tra quelli previsti dalle regolamentazioni nazionali, in attesa di ricevere dei frame di tipo Beacon. Tale frame viene trasmesso periodicamente dall' AP se è presente una rete con infrastruttura, mentre viene trasmesso periodicamente da una stazione eletta con uno schema distribuito se è presente una rete ad hoc (Indipendent Basic Service Set o IBSS).

Usando la procedura di scan attivo invece, la stazione deve prima guadagnare l'accesso al mezzo secondo il metodo CSMA/CA per inviare un frame di tipo Probe Request, dopodichè deve attendere l'accesso al mezzo e l'invio del frame Probe Response dalle stazioni che hanno ricevuto il Probe Request. In questo caso, il tempo di scoperta minimo, in assenza di interferenze esterne alla rete e considerando una rete lontana dalla saturazione, è pari al tempo necessario a trasmettere un frame Probe Request, più un intervallo DIFS (DCF Inter-Frame Space), più il tempo necessario a trasmettere un frame Probe Response, il totale moltiplicato per il numero di canali che si vuole osservare. Possiamo riassumere i suddetti tempi nella tabella seguente:

Se stiamo realizzando una rete ad hoc, la procedura di Scan è sufficiente. Anche l'autenticazione tra due stazioni in modalità ad hoc può essere effettuata ma non è richiesto esplicitamente dallo standard.

Se invece la stazione volesse aggiungersi ad una rete con infrastruttura, una volta scoperto l'Access Point con la procedura di Scan, è richiesta l'Autenticazione tra la stazione e L'Access Point (AP), cui segue l'Associazione della stazione con l'Access Point. Una volta effettuata l'associazione con l'AP, la stazione può comunicare con stazioni in altre BSS di cui l'AP è a conoscenza (vedi 5.2), può comunicare con il metodo Point Coordination Function (PCF) (vedi 5.4), può comunicare con stazioni fuori dalla sua portata ma visibili all'AP.

   *  Procedura di Autenticazione

Può essere effettuata in due modi:

• Open System Authentication è il metodo che non prevede alcuna identificazione della stazione. In pratica, una stazione che richiede l'autenticazione con questo metodo, viene autenticata dalla stazione destinataria della richiesta se essa ha scelto lo stesso metodo OSA come metodo d'autenticazione. Questa procedura richiede lo scambio di due frame tra le stazioni coinvolte.
• Shared Key Authentication prevede che una stazione venga autenticata da un'altra stazione solo se la prima possiede la stessa chiave segreta della seconda. La chiave segreta comune a più stazioni autenticate tra loro dev'essere distribuita tramite un canale diverso da un canale IEEE 802.11. L'utilizzo di questo metodo è possibile solo se le stazioni implementano il protocollo WEP (Wired Equivalent Privacy). Questa procedura prevede lo scambio di quattro frame fra le due stazioni coinvolte.

   *  Procedura di Associazione

Prevede l'invio, sempre secondo le regole CSMA/CA, del frame Association Request dalla stazione verso l'Access Point, il quale dovrà rispondere con il frame Association Response. Ancora una volta, i tempi di questa operazione di associazione sono quelli relativi all'invio di un frame ed alla ricezione di una risposta: pertanto possono essere applicate le stesse considerazioni e gli stessi risultati visti per la procedura di scan attivo.

5.1.3  Conclusioni

Riassumiamo nella tabella seguente quanto visto nella sezione 5.1:

5.2  Topologie di rete

*  Bluetooth

è uno standard per comunicazioni wireless a corto raggio e a basso costo, che opera nella banda ISM 2.4 GHz. Due o più dispositivi Bluetooth che condividono lo stesso canale trasmissivo⁸⁹ formano una Piconet.

All'interno di una piconet un dispositivo Bluetooth può assumere solo uno dei due ruoli: Master o Slave. Ciascuna piconet può contenere solo un master (e ce ne dev'essere sempre uno), fino a 7 slave attivi contemporaneamente e fino a 255 in modalità Park. Un qualsiasi dispositivo Bluetooth può divenire master in una piconet. La topologia piconet non ha problemi di routing o di contesa per l'accesso al mezzo perchè le comunicazioni vengono gestite dal master. D'altra parte però, due slave non possono comunicare direttamente tra di loro.

Due o più piconet possono essere interconnesse a formare una cosiddetta Scatternet.

La connessione tra due piconet è rappresentata da un dispositivo Bluetooth membro di entrambe le piconet; lo standard prevede che un dispositivo Bluetooth possa essere slave in più piconet, ma master in una sola piconet. La partecipazione di un dispositivo in più piconet è gestita dallo stesso dispositivo, secondo uno schema a divisione di tempo.

Il concetto di Scatternet è riconducibile al concetto di ``rete wireless ad hoc multi hop''.

*  IEEE802.11

Le specifiche IEEE 802.11 rappresentano uno standard per la realizzazione di wireless LAN operanti nella banda ISM 2.4 GHz. Lo standard prevede sia la comunicazione diretta (peer-to-peer) tra i terminali, che la comunicazione tra i terminali e le base station dette Access Point (AP).

   *  Topologia con infrastruttura

La configurazione tipica di una rete realizzata con dispositivi IEEE 802.11 è quella cosiddetta ``con infrastruttura''.

Si possono identificare delle celle base, dette BSS (Basic Service Set) nelle quali i terminali si associano con un AP ed il traffico tra le stazioni associate fluisce attraverso l'Access Point stesso (i terminali associati con l'Access Point non comunicano direttamente tra di loro). In una BSS può esistere solo un Access Point. Diverse BSS possono essere interconnesse tramite un Distibution System (DS), a formare un cosiddetto ESS (Extended Service Set). Viene definito inoltre il Portale, ovvero un'entità che collega il Distribution System con altre infrastrutture di rete integrate, ad esempio LAN Ethernet. Si osservi che:

• le BSS possono sovrapporsi parzialmente
• le BSS possono essere disgiunte nello spazio
• possono essere collocate nella stessa area più ESS o anche reti con topologia ad hoc Indipendent BSS (IBSS)

La figura seguente illustra la famiglia degli standard IEEE 802 e la loro relazione con i livelli dello stack OSI/ISO:

Lo standard IEEE 802.11 contiene le definizioni del livello MAC e del livello fisico, e specifica dei Servizi grazie ai quali si può implementare un sistema di distribuzione e quindi una rete ESS, la quale apparirà come un'unica BSS dal livello LLC (Logical Link Control) dei terminali associati con un AP in una qualunque BSS. I seguenti servizi (Distribution System Services) sono definiti per la realizzazione di una topologia ESS:

• Associazione è il servizio con il quale le stazioni di una BSS si associano ad un Access Point allo scopo di usufruire del Distribution System. Grazie all'associazione, il Distribution System realizza una mappa delle stazioni associate con i vari Access Point della ESS.
• Disassociazione è il servizio invocato per terminare un'associazione.
• Riassociazione è un servizio invocato per spostare l'associazione di una stazione da un Access Point ad un altro, oppure per cambiare dei parametri relativi ad un'associazione.
• Distribuzione è il servizio che si occupa di trasportare i messaggi attraverso l'AP della BSS di appartenenza. Dev'essere usato per ogni comunicazione da parte di una stazione associata con un Access Point.
• Integrazione se il servizio di Distribuzione suddetto determina che il destinatario finale di un messaggio è un membro di una LAN integrata, allora il punto d'uscita del messaggio dal Distribution System è un Portale anzichè un Access Point e viene invocato il servizio di integrazione dopo il servizio di distribuzione.

Sono definiti inoltre i servizi SS (Station Services):

• Autenticazione è usato da tutte le stazioni per stabilire la propria identità nei confronti delle stazioni con cui si vuole comunicare⁹⁰. Nel caso di topologia con infrastruttura, l'autenticazione è un prerequisito per l'associazione e viene effettuata nei confronti dell'AP.
• Deautenticazione è un servizio invocato per terminare un'autenticazione. Nel caso di topologia con infrastruttura, la deautenticazione comporta la disassociazione.
• Privacy è il servizio che permette la cifratura dei messaggi trasmessi.
• Trasporto dei pacchetti ogni stazione dev'essere in grado di accedere al mezzo per inviare e ricevere pacchetti. Questo servizio è usato dalle stazioni associate con una Access Point per comunicare con l'Access Point e per comunicare fra stazioni non associate con un Access Point (in modalità ad hoc).

Facciamo un esempio per chiarire meglio la topologia ESS e come viene utilizzata. Osserviamo la figura 5.3

I terminali STA1 e STA2, come si vede dall'uguale colore delle antenne, sono associati all'AP presente nella BSS1, così come i terminali STA4 e STA5 sono associati all'AP della BSS2. Le BSS 1 e 2, interconnesse dal DS formano una ESS (in rosso). La STA3 viceversa si trova nell'area di copertura dell'AP della BSS1 ma non è associata con esso. Dunque:

• la STA3, non essendo associata con l'AP, non può usare il sistema di distribuzione per comunicare con terminali fuori dal suo raggio d'azione.
• Una qualunque altra stazione delle BSS 1 e 2 può comunicare con le altre usando il servizio di Distribuzione. Consideriamo un messaggio che dev'essere inviato dalla STA1 alla STA4. Il messaggio viene ricevuto dall'AP della BSS1, il quale lo inoltra al DS. Il DS si occupa di determinare l'AP che serve il terminale STA4 e di inoltrargli il messaggio del terminale STA1. Infine l'AP della BSS2 accede al mezzo per inviare il messaggio al terminale STA4.

Possiamo a questo punto osservare che:

• la struttura interna del sistema di distribuzione non è specificata nello standard. Può essere una comune infrastruttura LAN Ethernet, come anche un altro sistema wireless. Tutto quello che lo standard fa è definire i servizi che abbiamo citato e che devono essere supportati dal DS.
• l'accesso al mezzo all'interno delle BSS è tipicamente distribuito (DCF); tuttavia la topologia con infrastruttura e quindi la presenza di un AP consente l'implementazione del metodo PCF (point Coordination Function), che prevede il controllo centralizzato dell'accesso delle stazioni al mezzo da parte dell'AP.
• la topologia ESS (Access Point e Distribution System) fornisce un supporto per la transizione dei terminali mobili da una BSS ad un altra all'interno della stessa ESS. E' prevista infatti la procedura di Riassociazione con la quale si può implementare un sistema di roaming.

   *  Topologia ad hoc

Come abbiamo detto, lo standard IEEE 802.11 consente a due o più terminali di comunicare direttamente, senza la presenza di alcuna infrastruttura di rete.

Possiamo osservare che:

• l'unico metodo d'accesso disponibile è quello con acceso al mezzo distribuito (DCF) (Distributed Coordination Function), che segue le regole del protocollo CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Non è disponibile l'accesso controllato centralizzato (PCF).
• non esiste un Distribution System, quindi i servizi di Associazione, Disassociazione, Riassociazione, Distribuzione ed Integrazione non sono disponibili.
• una IBSS può avere un numero qualsiasi di partecipanti.
• è possibile realizzare delle reti ad hoc di tipo multi hop ma, a differenza di Bluetooth, che come abbiamo visto prevede il concetto di Scatternet, un terminale non può appartenere a più di una IBSS.

Conclusioni  

• Le topologie rappresentate dalla piconet Bluetooth e dalla BSS con infrastruttura IEEE 802.11 presentano numerose analogie. In entrambi i casi, il traffico è gestito da un'entità centralizzata (master in Bluetooth e Access Point in IEEE 802.11), con la differenza che nella piconet Bluetooth il master regola anche l'accesso degli slave al canale mentre questa funzione⁹¹ è opzionale in un Access Point IEEE 802.11. Con questa topologia dunque il routing dei pacchetti all'interno della singola cella base è effettuato attraverso il master per Bluetooth ed attraverso l'Access Point per IEEE 802.11.
  Per quanto riguarda la capacità delle due topologie, il numero massimo di unità gestite è 7 slave attivi nella piconet Bluetooth contro i 2007 terminali IEEE 802.11 gestibili da un singolo Access Point, mentre il raggio di copertura delle reti è 10 m per una piconet Bluetooth contro 150-300 m per una BSS IEEE 802.11.
  Un Access Point IEEE 802.11 è in grado, per come è definito nello standard, di comunicare e di far comunicare le stazioni ad esso associate con una rete esterna. Analogamente, un dispositivo Bluetooth può essere realizzato seguendo le linee guida tracciate nel LAN Access Profile e nel PAN (Personal Area Network) Profile.
• Anche la scatternet Bluetooth e la topologia ad hoc IBSS fornita da IEEE 802.11 presentano alcune analogie. Sono entrambe reti ad hoc multihop, con topologia variabile dinamicamente, sebbene la scatternet sia costituita da sottostrutture, le piconet, mentre invece una rete ad hoc IEEE 802.11 non ha sottostrutture.
  In entrambe, per ottenere una connettività globale fra le stazioni è necessario un sistema di indirizzamento globale ed un meccanismo di routing.
• mentre nel protocollo IEEE 802.11 esiste un sistema di indirizzamento globale perchè i dispositivi vengono identificati da un indirizzo MAC 802 (LAN), per il protocollo Bluetooth, occorre realizzare un sistema di indirizzamento globale ad un livello superiore al MAC, ad esempio a livello IP.
• per quanto riguarda il routing, entrambi gli standard non specificano alcun meccanismo per il routing dei pacchetti all'interno delle scatternet Bluettooth o delle reti ad hoc IEEE 802.11. Esiste un problema relativo al routing comune ad entrambe le topologie, a causa della loro dinamicità: la rottura dei link visto come evento molto più probabile che nel caso di reti cablate. La rottura dei link potrebbe essere ad esempio dovuta alla mobilità dei terminali della rete o alla comparsa di ostacoli che blocchino i segnali radio. Tuttavia:
• per il protocollo IEEE 802.11, immediatamente sotto il livello di routing abbiamo la struttura finale della rete, la rete ad hoc appunto. La rottura dei link in questo caso non risulta in un cambiamento della struttura della rete ad hoc.
• per il protocollo Bluetooth la scatternet non è l'unica struttura sottostante il livello di routing, poichè una scatternet è costituita da piconet. La rottura dei link provoca, in generale, la terminazione di alcune piconet e la creazione di altre, con un conseguente cambiamento non solo dei percorsi tra due nodi (routing) ma anche della struttura stessa della scatternet.
• la topologia ESS non ha un concetto analogo nel protocollo Bluetooth, a meno che non si realizzi una struttura nella quale due o più piconet Bluetooth, realizzate secondo i profile LAN Access o PAN, vengano interconnesse da una rete esterna, ad esempio una LAN cablata.

5.3  Comunicazione all'interno delle reti

Ci proponiamo in questa sezione un confronto tra gli standard Bluetooth e IEEE 802.11 riguardo alle caratteristiche delle comunicazioni tra le stazioni appartenenti ad una stessa cella base. In Bluetooth la cella base è la piconet, in IEEE 802.11 è il Basic Service Set (BSS).

5.3.1  Banda radio

Entrambi i protocolli utilizzano la banda ISM (Industrial Scientific Medical) 2.4 GHz. La banda si estende da 2.4 GHz a 2.4835 GHz. Sono disponibili dunque 83.5 MHz.

5.3.2  Utilizzo della banda, tecniche di modulazione e trasmissione RF

*  Bluetooth

I dispositivi Bluetooth utilizzano la tecnica FHSS (Frequency Hopping Spread Spectrum). Vengono definiti 79 canali⁹² (frequenze di hopping), di ampiezza 1 MHz ciascuno. La comunicazione avviene utilizzando i suddetti canali con una sequenza pseudocasuale, diversa da piconet a piconet, generata a partire dall'indirizzo Bluetooth del master della piconet. Tutti gli slave della stessa piconet conoscono tale sequenza e sono sincronizzati con essa. Il canale operativo viene cambiato in base a questa sequenza 1600 volte al secondo (1600 hops/s), creando così una sequenza di slot ciascuno di durata pari a 625μs. Il master iniza le proprie trasmissioni negli slot di indice pari, gli slave iniziano le loro trasmissioni negli slot di indice dispari. Un messaggio può durare da 1 a 5 slot consecutivi. Per trasmettere i messaggi multislot, viene utilizzata per tutti gli slot la frequenza di hopping corrispondente alla frequenza dello slot in cui inizia il messaggio. Per modulare il segnale sul canale di hop viene utilizzato lo schema di modulazione GFSK (Gaussian shaped Frequency Shift Keying). Ogni canale ha una velocità di modulazione dati pari a 1 Msimbolo/s che, con la modulazione GFSK, corrisponde ad una velocità di trasferimento dati pari a 1 Mbps.

*  IEEE 802.11

i dispositivi IEEE 802.11 utilizzano la tecnica DSSS (Direct Sequence Spread Spectrum)⁹³. La banda disponibile viene suddivisa in 14 canali⁹⁴, parzialmente sovrapposti, ciascuno di ampiezza pari a 22 MHz. Tutti i terminali appartenenti ad una stessa BSS (con infrastruttura o ad hoc) utilizzano sempre lo stesso canale per le comunicazioni. Per codificare il flusso dei dati trasmessi si usano due tecniche:

• sequenza di Barker: è la tecnica specificata nello standard IEEE 802.11, il simbolo trasmesso è rappresentato da una sequenza di 11 chip che codifica ogni singolo bit d'informazione. La velocità di modulazione è 1 Msimbolo/s. Le tecniche di modulazione utilizzate sono la BPSK, con la quale ogni simbolo codifica 1 bit d'informazione e quindi si ottiene una velocità di trasferimento pari a 1 Mbps, e la QPSK, con la quale ogni simbolo codifica 2 bit d'informazione e quindi si ottiene una velocità di trasferimento pari a 2 Mbps.
• lo standard IEEE 802.11b, su cui si basano i dispositivi oggi in commercio, usa invece la tecnica CCK (Complementary Code Keying): 16 bit trasmessi sul canale codificano 4 o 8 bit d'informazione. Viene usata una velocità di modulazione pari a 1.375 Msimboli/s con la tecnica QPSK. Quindi, si ottiene una velocità di trasferimento pari a 5.5 Mbps quando il simbolo, o codice CCK, codifica 4 bit d'informazione, mentre si ottiene una velocità di trasferimento pari a 11 Mbps quando il simbolo codifica 8 bit d'informazione. Tutti i dispositivi conformi allo standard IEEE 802.11b sono interoperabili con i dispositivi IEEE 802.11.

5.3.3  Potenza di trasmissione

Lo standard Bluetooth impone dei limiti alla potenza di emissione radio dei dispositivi, limiti che possono essere riassunti nella seguente tabella:

Lo standard IEEE 802.11 prevede che:

• sia previsto almeno un livello di potenza con EIRP (Equivalent Isotropic Radiated Power) pari a 10 mW;
• per i dispositivi con livelli di potenza massima superiori a 100 mW EIRP, sia previsto almeno un livello di potenza pari a 100 mW EIRP (o ad un livello inferiore).

5.3.4  Pacchettizzazione e throughput

*  Bluetooth

Lo standard Bluetooth, come si può vedere dalle tabelle 3.6 e 3.7, prevede una differenziazione dei pacchetti in base sostanzialmente a:

• tipo di link che si vuole realizzare, ovvero asincrono (ACL⁹⁵) o sincrono (SCO⁹⁶)
• livello di protezione contro gli errori

I pacchetti ACL sono tutti protetti da un CRC (Cyclic Redundancy Check) a 16 bit⁹⁷, mentre tale protezione non è prevista per i pacchetti SCO. E' previsto per alcuni pacchetti ACL e SCO anche un metodo di correzione FEC (Forward Error Correction) con rapporto 1/3 (ogni bit d'informazione viene replicato 3 volte) e 2/3 (si usa un 15/10 shortened Hamming code, cioè vengono aggiunti 5 bit di parità ogni 10 bit d'informazione). Un link SCO utilizza sempre pacchetti monoslot e la dimensione dei pacchetti è fissa; esso fornisce un throughput simmetrico di 64 kb/s e la quantità d'informazione trasportabile con un pacchetto va da 10 byte (pacchetto HV1, nessun CRC, 1/3 FEC) a 30 byte (pacchetto HV3, nessun CRC, nessun FEC). Un link ACL prevede dei pacchetti estesi su 1, 3 o 5 slot. La dimensione del payload (il contenuto informativo vero e proprio) dipende dal tipo di pacchetto, e può variare da 17 byte (pacchetto DM1, CRC, FEC 2/3) fino a 339 byte (pacchetto DH5, CRC, nessun FEC). Un link di tipo ACL consente diversi bit rate asimmetrici, fino ad una differenza massima di 723.2 kbps in una direzione e 57.6 kbps nell'altra.

*  IEEE 802.11

La dimensione del payload varia da 0 a 2304 byte. L'intero frame IEEE 802.11, header e payload, viene protetto da un CRC32. Non è previsto alcun FEC. Un dispositivo IEEE 802.11b è capace di trasmettere ad una velocità pari a 11 Mbps lordi.

5.3.5  Conclusioni

• La tecnica FHSS adottata da Bluetooth e la tecnica DSSS usata da IEEE 802.11b possono essere cosi confrontate:
• il sistema FHSS adottato da Bluetooth è meno sensibile del sistema DSSS IEEE 802.11b alle interferenze a banda stretta che influenzano solo uno o un piccolo numero di frequenze di hop. Infatti entrambi i protocolli prevedono la ritrasmissione dei pacchetti che non vengono ricevuti correttamente. IEEE 802.11 usa la cosiddetta time diversity per eseguire le ritrasmissioni, ovvero un pacchetto non ricevuto correttamente viene trasmesso in seguito ma utilizzando la stessa banda di frequenze. Dunque, se la perdita del pacchetto fosse stata causata da un'interferenza che permane in quella banda quando si tenta di ritrasmetterlo, il pacchetto sarebbe perso ancora una volta. D'altra parte Bluetooth usa la cosiddetta frequency diversity, ovvero la ritrasmissione di un pacchetto perso avviene utilizzando un altro canale di hop, evitando l'interferenza che aveva causato la perdita del pacchetto.
• la tecnica FHSS usata da Bluetooth offre una maggiore sicurezza della tecnica DSSS usata da IEEE 802.11 riguardo ai tentativi di decodifica del segnale da parte di stazioni non autorizzate in ascolto nella banda radio ISM.
• il protocollo IEEE 802.11b prevede l'aggiustamento dinamico della velocità di trasferimento dati in base alla qualità del segnale sul canale trasmissivo; la scelta di uno dei 4 data rate possibili viene effettuata dinamicamente dal livello fisico (PHY) e quindi in maniera trasparente ai livelli superiori del protocollo, compreso il MAC.
  Qualcosa di simile si può realizzare anche con i dispositivi Bluetooth, che permettono di cambiare dinamicamente il tipo di pacchetti (tra quelli visti in 3.6) in base alla qualità della ricezione di un singolo link. Tuttavia, questa procedura è gestita a livello Link Manager.
• il protocollo IEEE 802.11b offre un throughput maggiore del protocollo Bluetooth a livello del singolo link tra due stazioni, essenzialmente perchè la velocità di trasmissione sul canale è di 1Mbps per Bluetooth contro i 22 Mbps per IEEE 802.11. Se consideriamo le due topologie base dei protocolli, la piconet e la BSS (con infrastruttura oppure ad hoc) notiamo che l'accesso al mezzo sincrono e controllato realizzato nella piconet Bluetooth consente un throughput meno sensibile al carico della rete di quello realizzato utilizzando il metodo Distributed Coordination Function (DCF) del protocollo IEEE802.11b. In quest'ultimo caso, al crescere del traffico nella rete la banda disponibile è ridotta dalle collisioni che avvengono per guadagnare l'accesso al mezzo condiviso.

5.4  QoS

Il termine QoS (Quality of Service) si riferisce ad un'ampia gamma di parametri che si riferiscono alle capacità che una rete ha di fornire risultati predicibili in maniera deterministica o statistica; tali parametri comprendono: disponibilità dei servizi, banda, ritardo, tasso d'errore.

*  Bluetooth

offre come abbiamo visto due tipi diversi di link:

• Asincrono orientato al pacchetto (ACL)
• Sincrono orientato alla connessione (SCO)

Il link SCO viene tipicamente utilizzato per il trasporto di traffico real-time come, ad esempio, traffico audio o video. Tale link prevede che il master riservi degli slot utilizzabili solo per il traffico SCO. Uno slave può realizzare fino a 3 link SCO con lo stesso master oppure 2 con master diversi. I pacchetti di un link SCO non vengono mai ritrasmessi, non sono protetti da un CRC ma è previsto solo un algoritmo FEC (1/3 o 2/3). La banda di un link SCO è sempre 64kbps. Osserviamo la seguente tabella che riporta i data rate tipici di alcuni sistemi audio:

Bluetooth utilizza i link SCO per realizzare un sistema audio adeguato alla trasmissione della voce e di musica a media qualità.

Per quel che riguarda un link SCO possiamo dunque osservare che:

• fornisce una banda ed un ritardo garantiti, a meno delle interruzioni causate dai messaggi LMP (Link Manager Protocol) di tipo broadcast, che hanno precedenza sui link SCO;
• fornisce solo una banda di tipo simmetrico e costante: alcune applicazioni (tipo streaming) spesso richiedono una banda asimmetrica e variabile;
• la trasmissione non è affidabile: non sono infatti previste ritrasmissioni e per di più le capacità di correzione degli errori fornite dalla protezione FEC sono limitate agli errori su uno o due bit, per cui sono inefficaci per treni di errori. Le interferenze con WLAN IEEE 802.11 o forni a microonde causano spesso treni di errori (errori burst);
• i messaggi LMP (Link Manager Protocol) di tipo broadcast hanno precedenza sul traffico SCO.

Il link ACL viene tipicamente utilizzato per traffico dati senza particolari richieste temporali e di banda. Gli slave possono inviare solo un pacchetto alla volta al master secondo uno schema round robin. Tra due dispositivi Bluetooth qualsiasi può esistere solo un link di tipo ACL. Il link ACL può offrire una banda simmetrica oppure asimmetrica. La banda disponibile su un link ACL è legata al tipo di pacchetti utilizzati per quel particolare link ed alla frequenza con la quale il dispositivo viene interrogato. I pacchetti ACL sono protetti da un CRC16 e come opzione è prevista anche la protezione FEC 2/3. E' prevista la ritrasmissione dei pacchetti ACL secondo uno schema ARQ (Automatic Repeat Request).
Per quel che riguarda un link ACL possiamo dunque dire che:

• si può ottenere una certa affidabilità anche in caso di treni di errori, grazie al meccanismo di ritrasmissione dei pacchetti con timeout configurabile: si può scegliere di non effettuare affatto le ritrasmissioni, di effettuare infinite ritrasmissioni (reliable link) oppure si può configurare un valore intermedio di ritrasmissioni;
• è possibile supportare applicazioni che richiedono una banda asimmetrica e variabile;
• gli slot riservati al traffico SCO hanno priorità sul traffico ACL, il che riduce la banda disponibile per un link ACL in presenza di link SCO;
• anche i messaggi LMP hanno priorità sui pacchetti ACL;
• l'utilizzo dei Low Power Modes (Hold, Sniff e Park) influisce sulla banda e sul ritardo delle comunicazioni che avvengono su un link ACL. Tali modalità infatti riguardano solo i link ACL e non i link SCO che vengono comunque garantiti;
• siccome uno slave può attivare un singolo link ACL, tutte le applicazioni di livello superiore che lo utilizzano devono condividerne le caratteristiche, come la quantità di ridondanza FEC ed il timeout di ritrasmissione.

Il protocollo Bluetooth fornisce una configurazione QoS dei link ACL, i quali vengono adattati, quando possibile, alle richieste dei livelli superiori dello stack Bluetooth. I parametri che possono essere configurati sono:

• Type of QoS: da scegliere tra nessuno, Best Effort e Guaranteed. Best effort è il servizio standard.
• Token Rate: il data rate garantito ad una applicazione su quel link.
• Token rate bucket size: è una misura di quanto spazio (buffer) verrà riservato per i dati ricevuti. I link che realizzano applicazioni con trasferimenti burst avranno bisogno di uno spazio maggiore dei link che realizzano applicazioni con flussi di traffico continui.
• Peak bandwidth: il data rate massimo al quale le applicazioni possono mandare pacchetti uno di seguito all'altro.
• Latency: il ritardo massimo tra l'istante in cui un'applicazione invia un bit e l'istante in cui tale bit viene trasmesso sul mezzo radio per la prima volta (la latenza reale può dunque essere più elevata a causa delle ritrasmissioni).
• Delay variation: la differenza tra il più grande ed il più piccolo ritardo che un pacchetto può presentare. Questo parametro avrà effetto sulla scelta delle dimensioni del buffer necessario a ricomporre un flusso continuo di dati.

Quando il QoS non è configurato, il dispositivo Bluetooth usa i seguenti valori (default):

• Tipo di servizio: Best Effort
• Token Rate: non specificato
• Token Bucket Size: nessun bisogno
• Peak BW: sconosciuto
• Latency: non importa
• Delay variation: non importa

L'uso di questi parametri è implementato tramite primitive che interrogano il master. Se il master accetta la richiesta di QoS, configura il link ACL con lo slave impostando i due parametri:

• Poll Interval: intervallo massimo tra due interrogazioni consecutive dello slave
• N_BC : numero di ritrasmissioni dei pacchetti broadcast. Questi ultimi non possono essere confermati (ACK) e quindi vanno ritrasmessi più volte per aumentare l'affidabilità.

Inoltre il Link Manager può comunicare ai livelli superiori dello stack le violazioni dei parametri QoS richiesti.

*  IEEE 802.11

offre il metodo d'accesso al mezzo detto Point Coordination Function (PCF), alternativo al Distributed Coordination Function (DCF). L'utilizzo di questo metodo d'accesso è limitato alla topologia con infrastruttura e prevede che una stazione detta Point Coordinator (PC), che di solito coincide con l'Access Point, regoli l'accesso al mezzo delle stazioni che richiedono di far parte di una polling list, interrogandole con uno schema round robin e garantendo loro l'accesso al mezzo. In ogni caso, una parte del canale dev'essere comunque dedicata all'accesso con contesa. Viene definito infatti un intervallo temporale detto superframe, composto da un Contention Free Period (CFP) durante il quale vige il metodo PCF, ed un periodo, Contention Period (CP), durante il quale vige il metodo DCF. Il CP deve durare abbastanza da permettere almeno l'invio di un frame.

Il metodo d'accesso PCF presenta le seguenti caratteristiche:

• La dimensione temporale di un periodo CFP può venire ridotta da un residuo di traffico DCF.⁹⁸Dunque, non è garantita un'effettiva allocazione temporale delle risorse del canale, poichè gli istanti di inizio dei periodi CFP non vengono necessariamente preservati.
• Una stazione interrogata dal PC può trasmettere solo un frame, di dimensione variabile tra 0 e 2304 byte. All'inizio di un CFP non è nota la quantità totale dei dati che tutte le stazione della polling list devono inviare. A causa della variabilità dei payload dei frame delle stazioni interrogate e del tempo necessario a trasmettere tali frame, il PC potrebbe non riuscire ad interrogare tutte le stazione della polling list entro il CFP. Le stazioni che rimangono escluse, dovranno ritardare ulteriormente le loro trasmissioni, e quindi viene introdotto del ritardo che potrebbe non essere accettabile per applicazioni time-bounded.

*  Conclusioni

• Il problema del supporto QoS a livello MAC non è stato affrontato dallo standard IEEE 802.11 fino ad ora. Sono attualmente allo studio del Task Group IEEE 802.11e diverse modifiche al MAC IEEE 802.11 che offrano supporto per applicazioni che richiedono un certo QoS.
• I link Bluetooth di tipo sincrono (SCO) non hanno analogo nel protocollo IEEE 802.11. Tali link consentono la realizzazione di applicazioni voce (telefonia, audio a bassa qualità) direttamente sfruttando delle caratteristiche del MAC, senza richiedere complicate funzioni a livelli superiori.
• Confrontiamo il metodo d'accesso PCF IEEE 802.11 ed i link Bluetooth di tipo asincrono (ACL).
  In entrambi i casi, un'unità centrale stabilisce l'accesso al mezzo delle altre stazioni della rete secondo un certo ordine. Uno slave Bluetooth può richiedere la soddisfazione dei parametri QoS fondamentali (banda, ritardo, variabilità del ritardo) sul link ACL. Ogni slave può avere una sola connessione ACL , quindi diverse applicazioni, anche con diverse richieste QoS, dovranno condividerla. La negoziazione dei parametri QoS è effettuata in Bluetooth secondo segnalazioni definite dal Link Manager.
  Non esiste invece alcun tipo di analoga segnalazione QoS per le stazioni IEEE 802.11. Una stazione associata con un Access Point che opera come Point Coordinator può richiedere di essere inserita nella polling list, ma non è garantito che le sue richieste verranno soddisfatte per i problemi che abbiamo citato riguardo la gestione del periodo Contention Free.

Chapter 6
Confronto costi e consumi

In questo capitolo ci proponiamo di confrontare due soluzioni wireless attualmente sul mercato, una per realizzare dispositivi IEEE 802.11b ed una per realizzare dispositivi Bluetooth. Il confronto si focalizzerà principalmente sul consumo di potenza e sul costo dei dispositivi.

6.1  Intersil PRISM per IEEE 802.11b

La Intersil Corp. (http://www.intersil.com) rappresenta attualmente uno dei più grossi produttori di hardware per la realizzazione di dispositivi IEEE 802.11⁹⁹, in tutte le sue versioni da IEEE 802.11b fino a IEEE 802.11a e IEEE802.11g. D'altra parte, essa ha raccolto l'eredità della Harris Semiconductor che, insieme a Lucent Technologies, propose le modifiche allo standard IEEE 802.11 che portarono nel 1999 alla nascita dell'attuale IEEE 802.11b.

6.1.1  Caratteristiche dell' hardware

Attualmente la Intersil offre la soluzione PRISM v3.0, per la realizzazione di dispositivi compatibili con lo standard IEEE 802.11. Il chipset PRISM 3 realizza sia il livello fisico (RF) che il livello MAC compatibili con lo standard IEEE 802.11b.
Nella figura 6.1 possiamo osservare una schematizzazione del sistema PRISM 3:

Tale sistema è composto da:

• un processore Baseband/MAC (ISL3871) con le seguenti caratteristiche:
• Interfaccia USB 1.1.
• Firmware che realizza tutte le funzioni previste dallo standard IEEE 802.11b e aggiornabile.
• Scan attivo autonomo, attivabile tramite un comando dall'host.
• Processore DSSS in banda base completo.
• Modulazioni DBPSK, DQPSK.
• Codifiche CCK (codifica usata per ottenere gli 11mbps) e Sequenza di Barker (per la compatibilità con i dispositivi IEEE 802.11 a 1 e 2 Mbps).
• Convertitori integrati A/D e D/A per AGC e controllo adattivo della potenza di trasmissione.
• Un amplificatore RF (ISL3984)
• Un VCO (Voltage Controlled Oscillator) (ISL3084)
• Un chip che implementa il livello radio (ISL3684)

6.1.2  Cosa offre lo standard IEEE 802.11 per la riduzione del consumo di potenza

Un dispositivo IEEE 802.11, in un istante qualsiasi, può trovarsi in uno dei seguenti due stati:

• Awake: la stazione è completamente operativa
• Doze: la stazione non riceve né trasmette ed il consumo di potenza è ridotto.

Conseguentemente abbiamo due modalità di Power Management:

• Active Mode (AM)
• Power Save Mode (PS)

La gestione delle stazioni in PS è ovviamente diversa a seconda della topologia della nostra rete IEEE 802.11:

*  Topologia con infrastruttura

Una stazione in AM che vuole entrare in PS, deve effettuare con successo uno scambio di pacchetti con l'Access Point cui è associata (ovvero deve ricevere un Acknowledgement), modificando il bit dedicato al Power Management contenuto nell'header dei pacchetti. In questa topologia infatti, l'Access Point si occupa di archiviare tutto il traffico destinato alle stazioni della rete che si trovano in PS.
L'Access Point costruisce la mappa virtuale delle stazioni in PS e del traffico ad esse destinato e comunica tale mappa tramite l'elemento TIM (Traffic Indication Map) contenuto in ogni Beacon che esso invia periodicamente. La modalità PS delle stazioni prevede che, ad intervalli regolari e configurabili, le stazioni stesse rientrino nello stato AM per ricevere i Beacon inviati dall'Access Point e quindi sapere se quest'ultimo ha del traffico bufferizzato per loro. Nel caso una stazione non rilevi dal TIM che l'Access Point ha del traffico indirizzato a se stessa, può tornare nello stato PS, fino al prossimo istante prescelto per l'ascolto del beacon. Nel caso contrario invece, la stazione può richiedere l'invio del traffico bufferizzato nell'Access Point, inviandogli un frame di tipo PS-Poll cui l'Access Point risponde appena possibile inviando il traffico bufferizzato per quella stazione.
Una stazione che vuole rientrare in Active Mode dalla modalità Power Save, deve effettuare l'operazione detta Clear Channel Assesment (CCA) per rilevare la presenza di eventuali trasmissioni in corso sul canale ed, in caso ve ne siano, ritardare il tentativo d'accesso al mezzo con le modalità previste dal MAC.

*  Topologia ad hoc

In questa topologia le stazioni possono comunque utilizzare la modalità Power Save ma, visto che non esiste un Access Point, tutte le stazioni devono occuparsi di bufferizzare il traffico di tutte le stazioni che si trovano in Power Save. Viene definita un finestra temporale (ATIM Window), durante la quale tutte le stazioni in Power Save si portano nello stato Awake per ricevere dei frame particolari, gli ATIM (ad hoc TIM). Le stazioni che hanno del traffico bufferizzato per qualche altra stazione in Power Save, durante l'ATIM Window accedono al mezzo per inviare frame di tipo ATIM direttamente indirizzate alle stazioni che devono ricevere il traffico bufferizzato. Se queste stazioni ricevono correttamente il frame ATIM, rimangono nello stato Awake anche dopo la fine della ATIM Window, per ricevere il traffico ad esse destinate; in caso contrario le stazioni possono tornare nello stato Power Save fino alla prossima finestra ATIM.
Possiamo osservare che:

• le stazioni che vogliono entrare in Power Save non hanno una stazione referente analoga all'Access Point cui comunicare tale cambiamento di stato. Dunque lo stato istantaneo di una stazione, Awake o Doze, può essere solo stimato da tutte le altre stazioni della rete ad hoc, ad esempio in base alla storia delle precedenti trasmissioni. Lo standard non specifica alcun metodo per la stima dello stato Power Management delle stazioni in una rete con topologia ad hoc;
• l'invio e la ricezione dei frame ATIM durante la finestra ATIM Window avviene secondo le regole del metodo Distributed Coordination Function (DCF), ovvero secondo il metodo d'accesso CSMA/CA. A seconda del traffico presente sul mezzo trasmissivo, potrebbe anche non essere possibile, per una stazione con del traffico bufferizzato per un'altra stazione in Power Save, riuscire a mandare il frame ATIM, oppure potrebbe non essere possibile, per la stazione che deve ricevere il traffico, mandare un frame ACK verso la stazione che ha bufferizzato il traffico, impedendo di fatto la trasmissione del suddetto traffico dopo la finestra ATIM.

Quindi, in definitiva, lo standard IEEE 802.11 specifica un solo stato a basso consumo di potenza, lo stato Doze, e dà la possibilità di configurare i tempi in cui una stazione rimarrà nello stato Doze (tramite il parametro ListenInterval, che specifica l'intervallo di tempo che intercorre tra l'ascolto consecutivo di due beacon).

6.1.3  Cosa offrono i chipset PRISM per la riduzione del consumo di potenza

I chipset della famiglia PRISM sono stati largamente impiegati per la realizzazione di WNIC (wireless network interface card), che possiamo trovare in diversi form factor: PCI, PCMCIA, e ultimamente anche in dispositivi USB e CompactFlash, quest'ultime utilizzate nei computer palmari. La figura 6.2 illustra un diagramma di stato per un WNIC IEEE 802.11:

Negli stati transmit e receive la radio funziona a piena potenza e la scheda wireless trasmette e riceve attivamente. Nello stato idle la radio è funzionante, ovvero il dispositivo è in ascolto sul mezzo trasmissivo, ma in questo stato il dispositivo non passa alcun dato che riceve ai livelli superiori, ovvero al software che gestisce le comunicazioni tramite la scheda wireless. Nello stato sleep anche la radio viene spenta, mentre altri dispositivi, quali i clock di riferimento, rimangono accesi. Infine nello stato off, il dispositivo è completamente spento. Alcuni degli stati illustrati in figura 6.2 sono invisibili da parte del software che gestisce la scheda wireless. Ad esempio, a livello del sistema operativo, gli stati transmit, receive e idle sono visti come un unico stato on.

Chipset PRISM di prima generazione

I chipset PRISM di prima generazione, come si può vedere nel documento [3] del 1997, offrono diverse modalità Power Save che sarà il MAC a selezionare in base agli intervalli tra due periodi consecutivi di Awake.

La seguente tabella riassume tali modalità ed i relativi consumi, relativamente ad una scheda PCMCIA: