wiki:Protocollo

Analisi dello standard IEEE 802.11

Indice dei contenuti

  1. Analisi dello standard IEEE 802.11
    1. Descrizione generale
      1. Descrizione generale dell'architettura
      2. Componenti dell'architettura
      3. Interfacce dei servizi logici
      4. Servizi per la distribuzione dei messaggi
        1. Distribuzione
        2. Integrazione
      5. Servizi a supporto del servizio di distribuzione
        1. Tipologie di mobilita'
        2. Associazione
        3. Riassociazione
        4. Dissociazione
      6. Servizi per il controllo di accesso e di confidenzialita'
        1. Autenticazione
        2. Preautenticazione
        3. Deautenticazione
        4. Privacy
      7. Relazioni fra i servizi
    2. Definizione dei servizi MAC
      1. Coordinamento per la trasmissione
        1. Coordinamento distribuito (DCF)
          1. CSMA/CA e il meccanismo RTS/CTS
          2. Carrier-sense virtuale e il NAV
          3. Acknowledgment
          4. Interframe space (IFS)
          5. Random backoff time
          6. Frame duplicati
        2. Coordinamento centralizzato (PCF)
          1. Struttura e tempistiche con PCF
          2. Procedura di accesso del PCF
            1. Accesso di base al mezzo
            2. Uso del NAV
          3. Procedura di trasferimento
    3. Gestione degli strati
      1. Primitive di gestione generica
      2. Interfaccia di MAC: MLME SAP
      3. Interfaccia di PHY: PLME SAP
      4. Interfaccia di PHY: PHY SAP
    4. Specifiche per il livello PHY
      1. FHSS
      2. OFDM
      3. DSSS
        1. Algoritmo di trasmissione
        2. Algoritmo di ricezione
        3. Note sulla modulazione
        4. Note
      4. HR/DSSS (802.11b/802.11g)
    5. Formato dei frame MAC
      1. Frame Control
      2. Duration/ID
      3. Address
      4. Sequence number
      5. Frame Body
      6. FCS
      7. Alcune note sui frame di management
    6. Management del sottolivello MAC
      1. Acquisizione della sincronizzazione mediante scansione
      2. Associazione e riassociazione di una stazione con un AP
      3. Power Management
      4. Power Management in un IBSS
    7. Autenticazione e privacy
      1. Autenticazione Open System
      2. Autenticazione Shared Key
      3. Algoritmo Wired Equivalent Privacy (WEP)
      4. Come funziona WEP
    8. Appunti vari

Descrizione generale

Descrizione generale dell'architettura

20061120 SoujaK
Le specifiche di questo standard sono formalizzate tramite una visione architetturale che ne semplifica la visione ma che non vuole in alcun modo rappresentare alcuna concreta implementazione.

Componenti dell'architettura

20070215-1651 SoujaK
L'architettura di IEEE 802.11 e' costituita da una serie di componenti che interagiscono al fine di creare una rete locale senza fili in grado di supportare la mobilita' delle stazioni in maniera trasparente ai livelli superiori.

Il basic service set (BSS) e' il componente di base di una rete locale; si tratta di un gruppo di stazioni all'interno di un'area di copertura all'interno della quale le stazioni possono rimanere in comunicazione fra loro.

L'independent basic service set (IBSS) e' il tipo piu' elementare di rete senza fili che si possa realizzare, dal momento che sono sufficienti due stazioni. Questa modalita', che non necessita di pianificazione e che ha durata limitata alle necessita' e' spesso chiamata rete ad hoc.

L'associazione fra una stazione (STA) e un BSS avviene in maniera dinamica non appena essa si attiva o entra nell'area del BSS.

Quando una serie di BSS si interconnettono fra loro creando una rete piu' estesa, si parla di 'distribution system' (DS). Il mezzo trasmissivo utilizzato dal sistema di distribuzione e' logicamente distinto dal mezzo trasmissivo senza fili, poiche' hanno scopi distinti e vengono implementati da componenti differenti dell'architettura.
Il DS fornisce i servizi logici necessari ai dipositivi mobili per poter gestire la mappatura dell'indirizzamento e l'integrazione. Un AP e' una stazione in grado di fornire, grazie a tali servizi aggiuntivi, l'accesso al sistema di distribuzione.

Il DS e i vari BSS permettono la creazione di reti senza fili di complessita' e dimensioni arbitrarie; faremo riferimento ad essa come a extended service set. Il concetto chiave e' che questo genere di reti appare al livello LLC come una rete IBSS: una stazione puo' muoversi da un BSS ad un altro in maniera totalmente trasparente ai livelli superiori. Conseguentemente la locazione fisica dei BSS non necessita di alcuna attenzione, essendo possibili lunghe distanze come sovrapposizioni.

Qualora si desideri l'integrazione di una architettura IEEE 802.11 con una LAN tradizionale, e' stato introdotto un ultimo componente logico: il portale. Esso e' connesso direttamente al sistema di distribuzione e veicola le comunicazioni fra le due tipologie di reti.

Interfacce dei servizi logici

Le definizioni legate al sistema di distribuzione non lo legano a nessuna tecnologia particolare, come l'uso di LAN via cavo secondo lo standard IEEE 802, ne' specificano dettagli implementativi. Vengono piuttosto definiti i servizi che sono associati ad ogni componente dell'architettura e che vengono utilizzati dal sottolivello MAC.
Questi sono divisi in due categorie.

Servizi delle stazioni (SS)

  • Autenticazione
  • Deautenticazione
  • Privacy
  • Consegna delle MSDU (service data unit)

Servizi del sistema di distribuzione (DSS)

  • Associazione
  • Dissociazione
  • Distribuzione
  • Integrazione
  • Riassociazione

Servizi per la distribuzione dei messaggi

Distribuzione

20070215-1912 SoujaK
E' il servizio primario invocato concettualmente da ogni messaggio di dati proveniente da o destinato a una STA attiva all'interno del ESS.

Se ne illustra il funzionamento tramite un esempio. Si supponga che una stazione mittente invii il messaggio per la stazione destinataria; il messaggi o viene in realta' ricevuto dall' access point di ingresso al sistema di distribuzione. Quest'ultimo, attraverso il DS, lo fa avere all'AP di uscita, che a sua volta lo invia alla effettiva destinazione della comunicazione.

Si noti che qualora le due stazioni agli estremi della comunicazione appartengano al medesimo BSS, gli AP di entrata e di uscita vengono a coincidere; in queste situazioni il passaggio attraverso il mezzo fisico del DS non e' obbligatorio.

La scelta dell'AP di uscita dipende, chiaramente dal sistema di distribuzione, ma non vengono specificate le modalita' con la quale il messaggio venga effettivamente propagato al suo interno.

Integrazione

20070215-1936 SoujaK
Quando viene chiesto al sistema di distribuzione una consegna di un messaggio destinato ad una LAN integrata alla rete, il punto d'uscita dal DS e' un portale. In questo scenario i messaggi distribuiti al portale fanno si che il sistema di distribuzione invochi il servizio di integrazione.

Questo servizio e' responsabile di ogni azione necessaria alla consegna dal DSM al mezzo trasmissivo della LAN integrata o viceversa (una traduzione dello spazio di indirizzamento, ad esempio). I dettagli implementativi non sono, al solito, fra gli scopi dello standard.

Servizi a supporto del servizio di distribuzione

Tipologie di mobilita'

20070216-1304 SoujaK
La mobilita' delle stazioni all'interno della rete e' suddivisa in tre tipologie:

  1. Nessuna transizione: la stazione e' ferma o si sposta all'interno del raggio d'azione delle stazioni vicine.
  2. Transizione di BSS: la stazione si sposta da un BSS facente parte di un ESS ad un altro BSS dello stesso ESS.
  3. Transizione di ESS: la stazione si sposta da un BSS di un ESS ad un altro BSS di un altro ESS. In questo caso la connessione con i livelli superiori non viene garantita dallo standard IEEE 802.11.

Associazione

20070216-1312 SoujaK
Affinche' il DS sia in grado di consegnare un messaggio, esso deve conoscere a quale AP faccia riferimento la STA destinataria. Questa informazione e' fornita tramite il concetto di associazione ed e' necessaria alla mobilita' delle stazioni fra i BSS. Prima di poter trasmettere un messaggio ad un AP inoltre, ogni STA e' tenuta ad associarsi con esso.

Mentre un AP e' in grado di essere associato a piu' STA contemporaneamente, ogni STA puo' essere associata al piu' ad un solo AP. In questo modo il DS e' in grado di determinare univocamente l' access point che serve ogni stazione.

Il processo di associazione inizia sempre dalla stazione mobile, una volta che essa si accorge della sua presenza attiva. Per informazioni piu' dettagliate su come una STA apprende dell'esistenza di un AP si veda la sezione dedicata alla scansione.

Riassociazione

20070216-1320 SoujaK
L'associazione e' una condizione necessaria e sufficiente per permettere la consegna di messaggi fra stazioni fisse, ma per le stazioni mobili essa non basta. La riassociazione e' invocata proprio quando una STA effettua una transizione di BSS, informando il sistema di distribuzione.

L'associazione e' sempre iniziata dalla STA coinvolta e ed e' utilizzata non solo quando essa intende comunicare il cambio di AP, ma anche quando desidera notificare qualche cambio degli attributi legati all'associazione con lo stesso AP.

Dissociazione

20070216-1340 SoujaK
Il servizio di dissociazione viene invocato ogni volta che una associazione deve terminare, comunicando al DS di eliminare le informazioni relative alla associazione esistente. Come e' facile intuire, ogni successivo tentativo di comunicazione con la STA che si e' dissociata fallira'.

La dissociazione, a differenza degli altri servizi che coinvolgono l'associazione, non e' una richiesta ma una notifica (non puo' essere rifiutata) e puo' essere invocata da entrambi gli estremi dell'associazione (le STA come gli AP).

Servizi per il controllo di accesso e di confidenzialita'

Autenticazione

20070216-1352 SoujaK
Nelle reti locali cablate la sicurezza fornita dal mezzo fisico viene utilizzata per prevenire accessi non autorizzati; questo non e' evidentemente possibile nelle reti locali wireless. Il servizio di autenticazione permette di supplire a questa mancanza, obbligando le STA ad identificarsi prima di ogni comunicazione, ed e' disponibile sia nelle reti ESS che in quelle IBSS. Perche' due STA si possano dire autenticate e' necessario che si riconoscano mutuamente come tali.

Lo standard supporta diversi processi di autenticazione e permette future espansioni degli schemi attuali. Si noti che l'intento e' di fornire autenticazione fra stazioni IEEE 802.11 a livello di data link, cercando di raggiungere le garanzie offerte da una rete cablata. La MIB fornisce funzioni in grado si supportare gli schemi di autenticazione standardizzati.

Fra i metodi supportati (nella versione 802.11-1999) sono presenti l'autenticazione Open System, che permette autenticazione a qualsiasi STA, e l'autenticazione a chiave condivisa (Shared Key) unitamente all' algoritmo WEP. Quest'ultimo schema di autenticazione richiede la conoscenza di una chiave segreta che costituisce anche la chiave di cifratura dell'algoritmo WEP.

In ogni momento ogni STA puo' essere autenticata con molteplici altre STA.

Preautenticazione

20070216-1634 SoujaK
Poiche' il processo di autenticazione potrebbe risultare dispendioso in termini di tempo, si permette la sua invocazione anche in maniera indipendente dal servizio di associazione.

Se la STA e' in movimento fra due BSS, infatti, e se l'autenticazione cade prima che la stessa STA possa riassociarsi con il successivo AP (si ricordi che prima dell'associazione e' necessaria l'autenticazione), la procedura potrebbe richiedere tempi considerevoli che andrebbero a degradare pesantemente le prestazioni in questo scenario.

L'uso della preautenticazione mantiene l' overhead introdotto dalla autenticazione lontano dai momenti in cui il tempo e' un fattore critico.

Deautenticazione

20070216-1642 SoujaK
Il servizio di deautenticazione viene invocato ogni volta che una autenticazione esistente deve terminare. In un ESS, poiche' l'autenticazione e' un prerequisito per l'associazione, la deautenticazione causa una dissociazione.

La deautenticazione non e' una richiesta ma una notifica (non puo' essere rifiutata) e puo' essere invocata da entrambi gli estremi dell'autenticazione (le STA come gli AP).

Privacy

20070216-1649 SoujaK
Nelle reti cablate il traffico puo' essere ascoltato soltanto da dispositivi fisicamente connessi alla LAN. Il mezzo trasmissivo delle reti wireless e' invece condiviso e accessibile a chiunque, pertanto ogni stazione aderente allo standard IEEE 802.11 e' in grado di ascoltare il traffico che vi transita. L'integrazione di un solo collegamento wireless ad una LAN cablata rischia quindi di degradare in misura sensibile il livello di sicurezza offerto dalla cablatura.

Il servizio di privacy intende portare le LAN senza fili ad un livello equivalente a quello delle LAN cablate crittografando i messaggi in transito con un algoritmo opzionale di privacy chiamato, appunto, WEP.

La cifratura dei messaggi viene invocata solo per i frame dati e per alcuni frame legati alla gestione dell'autenticazione. Lo stato predefinito di privacy e' "in chiaro", in modo da dare modo alle stazioni di impostare servizi di autenticazione e privacy piu' sicuri.

Se la modalita' di privacy non e' comune ai due estremi della comunicazione (entrambi "in chiaro" o entrambi "in crittografia", lo scambio di frame sara' impossibile poiche' la destinazione, pur rispondendo con gli adeguati acknowledgment, non inoltrera' i messaggi al livello LLC.

Relazioni fra i servizi

20070216-1728 SoujaK
Ogni stazione mantiene due variabili di stato per ogni altra stazione con la quale e' in grado di comunicare: lo stato dell'autenticazione e lo stato dell'associazione, dando cosi' origine a tre stati possibili:

  1. Stato iniziale, non autenticata, non associata
  2. Autenticata ma non associata.
  3. Autenticata e associata.

Definizione dei servizi MAC

20061201-0930 SoujaK
Il livello MAC comunica con l'hardware utilizzando il livello PHY in qualita' di tramite, che puo' pertanto essere visto come a lui sottostante. Il trasporto delle MSDU viene effettuato con trasmissioni connectionless di tipo best-effort, non ci sono quindi garanzie ne' sulla effettiva consegna dei frame, ne', tantomeno, sull'ordine di arrivo degli stessi. Comunicazioni ad indirizzamento di tipo broadcast o multicast possono quindi, a causa della loro natura, essere soggette a diverse prestazioni e qualita' di servizio.

Coordinamento per la trasmissione

20061207-1902 SoujaK
L'accesso al mezzo di trasmissione comune deve essere regolato, poiche', per sua intrinseca natura non puo` essere utilizzato per trasmissioni simultanee sulle stesse frequenze. Per questo motivo il livello MAC comprende funzionalita' in grado di farsi carico della coordinazione delle varie stazioni che operano sul medesimo canale trasmissivo. Si tratta della funzione di coordinamento distribuito (piu' brevemente DCF), un componente evidentemente necessario ad ogni stazione, in qualsiasi modalita' essa operi, infrastracture come ad-hoc.
E' inoltre presente un metodo di accesso opzionale, basato sulla funzione di coordinamento centralizzato (detto anche PCF) che fa uso di un coordinatore centrale detto PC (i.e. Point Coordinator) che risiede nell'AP del BSS.

DCF e PCF devono poter coesistere ed operare in maniera concorrente all'interno di una BSS, quindi i due metodi di accesso al mezzo si alterneranno, con un periodo in cui l'accesso e' prestabilito e il mezzo libero dalla contesa (Contention-Free Period o CFP) in cui il coordinamento e' centralizzato, seguito da un periodo di contesa (Contention Period o CP), in cui il coordinamento e' distribuito.

Coordinamento distribuito (DCF)

CSMA/CA e il meccanismo RTS/CTS

20061027-1950 SoujaK
Il concetto chiave attraverso il quale il protocollo interpreta il meccanismo di comunicazione CSMA/CA e' la distribuzione di informazioni di prenotazione del mezzo trasmissivo. Ogni comunicazione fra un nodo sorgente e un nodo destinazione deve cominciare con lo scambio di due frame RTS (request to send) e CTS (clear to send) dalla seguente semantica: "richiesta di invio" e "pronto alla ricezione". Tali frame RTS e CTS contengono un campo (Duration/ID) che contiene il tempo durante il quale il mezzo e' riservato per l'invio del frame (o del frammento) e per la ricezione dell'ACK. Le STA esterne alla comunicazione imparano, tramite questo meccanismo, che il canale e' occupato per tale lasso di tempo evitando le collisioni. La doppia presenza delle informazioni in questione nei due versi della comunicazione (sia nei frame RTS che in CTS, ad esempio) permette di raggiungere tutte le STA interessate, scongiurando alcuni problemi, come quello del nodo esposto). E' importante precisare che il meccanismo RTS/CTS non e' obbligatorio: deve essere evitato per trasmissioni multicast o broadcast (chi risponderebbe con il CTS?). Inoltre puo' essere evitato nel caso di frame piccoli (al fine di limitare l'overhead che si introduce): la soglia e' definita nell'attributo MAC denominato dot11RTSThreshold.

Carrier-sense virtuale e il NAV

20061027-0416 SoujaK
La funzionalita' permette di capire lo stato del mezzo trasmissivo (occupato o libero) ed e' presente non solo nel sottostrato PHY, come e' ovvio, ma anche in MAC. Qui in MAC il meccanismo e' da considerarsi virtuale, nel senso che interroga il Network Allocation Vector. Ogni STA ha il compito di tenere traccia nel NAV delle "prenotazioni" effettuate da altri che indicano la futura indisponibilita' del canale e, se necessario, rimandare i tentativi di trasmissione. Il calcolo di questa durata non e' altro che la somma dei tempi necessari alle fasi della comunicazione: la trasmissione dei vari frame di dati, degli acknowledgment e l'attesa dei vari IFS. Le citate informazioni necessarie alle stazioni estranee alla comunicazione sono o prefissate dallo standard (la durata di invio di un ACK o i tempi inter-frame) oppure sono comunicate dalle stazioni interne alla comunicazione. Il campo Duration/ID e' quindi presente sia nella coppia iniziale < RTS , CTS > che nelle successive coppie < PDU , ACK > diverse dalla prima; esso contiene la distanza temporale al termine della comunicazione, i.e. il primo acknowledgment.

Acknowledgment

20061027-0445 SoujaK
La strategia usata e' l'acknowledgment positivo, il che significa che la STA ricevente ha il compito di confermare alla STA trasmittente la corretta ricezione del frame (solo in caso di frame unicast, come e' facile intuire). Il trasmittente attende il frame ACK per un periodo di tempo fissato da ACKTimeout e poi conclude che la trasmissione e' fallita. Lo stesso succede qualora esso riceva altro che non sia un ACK. Si noti che la mancata ricezione dell'ACK puo' indistinguibilmente indicare anche un errore durante la trasmissione dello stesso acknowledgment.

Interframe space (IFS)

20061019-0849 SoujaK
Lo standard stabilisce la lunghezza di tempo che deve intercorrere fra le trasmissioni dei vari frame; lo scopo e' quello di fornire informazioni precise alle stazioni. Queste ultime, attraverso il meccanismo carrier-sense, attendono infatti di poter considerare libero il mezzo trasmissivo a seconda dei periodi di inattivita' rilevati.

A seconda della situazione viene usato uno dei seguenti 4 periodi:

  1. SIFS (short interframe space): usato per frame ACK, CTS, per frame (eccetto il primo) di una trasmissione frammentata, per le risposte al polling del PCF;
  2. PIFS (PCF interframe space): usato solo dalle STA che, sotto un PCF, tentano di avere accesso al mezzo trasmissivo all'inizio del CFP;
  3. DIFS (DCF interframe space): usato sotto DCF dalle STA per i frame dati (MPDU) o per i frame di gestione (MMPDU);
  4. EIFS (extented interframe space): usato quando il PHY indica al MAC che l'ultimo frame MAC non e' stato ricevuto correttamente e che il campo FCS non e' utilizzabile;
Random backoff time

20061209-1941 SoujaK
In seguito al rilevamento di inattivita' del mezzo trasmissivo (secondo le politiche appena descritte), ogni STA e' tenuta a ritardare ulteriormente la propria trasmissione per un periodo di backoff di durata casuale, a meno che non sia gia' stato impostato il relativo timer. L'intento e' quello di evitare che tutte le STA in attesa collidano nel momento in cui contemporaneamente effettuino tentativi di trasmissione.
Il periodo di inattivita' che le STA si auto-impongono e' detto CW (contention window) e viene ripetuto ogni volta che si presenti una collisione. Viene inoltre incrementato a fronte di ogni collisione con andamento esponenziale (per scongiurare il pericolo di fino al raggiungimento di un valore massimo prestabilito.

Il periodo di backoff e' espresso come quantita' casuale di quanti di tempo (dal valore aSlotTime presente in PHY). Questa quantita' di slot e' mantenuta in un intero pseudo-casuale le cui variazioni devono oscillare in maniera uniforme fra 0 e CW, un altro parametro definito come intero compreso nell'intervallo di estremi aCWmin e aCWmax(definiti in PHY). Ogni STA mantiene inoltre una coppia di contatori dei tentativi di trasmissione (SSRC e SLRC) non andati a buon fine: questi vengono inizializzati a 0 e vengono incrementati con l'andamento andamento esponenziale del 2 ogni volta che la comunicazione fallisce. Supponendo CWmin e CWmax settati rispettivamente a 7 e a 255, un esempio di incremento esponenziale e' dato dalla sequenza 7, 15, 31, 63, 127, 255, 255. Un cosi' alto andamento di crescita del periodo di backoff rende piu' stabile il protocollo, aumentando la sua capacita' di adeguarsi repentinamente a condizioni di alto carico per poi saperle sopportare con maggiore facilita' .

I contatori prima citati vengono poi resettati (azzerati) al verificarsi di determinati eventi interpretabili come comunicazione ben riuscita (e.g la ricezione di un ACK): i due contatori si differenziano proprio su questo particolare, ma non e' il caso di approfondire ulteriormente.

Frame duplicati

20061027-0536 SoujaK
Dal momento che le procedure di conferma di trasmissione e di ritrasmissione sono incorporati all'interno del protocollo, esiste la possibilita' che un determinato frame venga ricevuto piu' di una volta. La stazione ricevente deve rendersi conto della duplicazione e scartare i doppioni. E' stato pertanto inserito un campo di controllo di sequenza all'interno nei frame dati e in quelli di gestione, contenente il numero della sequenza e quello del frammento. Ogni STA mantiene dunque una cache delle triple <indirizzo , numero di sequenza , numero di frammento> che permette di identificare agilmente i frame duplicati. Il numero di sequenza e' un intero progressivo che tende ad essere unico fra i vari frame: qualora (sfortunatamente) capitasse il contrario, il frame valido erroneamente scartato verrebbe presto ritrasmesso dalla sorgente.

Coordinamento centralizzato (PCF)

20061210-1651 SoujaK
La PCF fornisce un metodo di trasmissione dei frame che e' libero dalla contesa (e quindi anche dagli sprechi di tempo che essa comporta), grazie alle regole imposte dal PC residente nell' access-point. Ogni stazione deve sottostare obbligatoriamente ai dettami del coordinatore impostando adeguatamente il proprio NAV? all'inizio di ogni CFP. Durante questi periodi, essendo la comunicazione strettamente regolata dal PC, le comunicazioni non necessitano dello scambio iniziale dei frame RTS/CTS. Questa e' una possibilita' offerta soltanto alle stazioni che implementano PCF, una funzionalita', ricordiamolo, opzionale.

Affinche' il coordinatore possa conoscere quali stazioni sono accessibili in maniera ottimale durante i CFP, invia un apposito poll, a cui risponderanno soltanto le stazioni dotate di tale caratteristica. Questo CF-poll e' inoltre la chiave di volta su cui questa modalita' di coordinamento si fonda; infatti le stazioni CF-pollable hanno occasione di spedire secondo una strategia di piggyback, una (e una sola) MPDU assieme all' acknowledgment.
Se tale invio fallisce il frame non potra' essere ritrasmesso subito, ma la stazione interessata dovra' attendere il prossimo segnale di poll dal coordinatore, o il prossimo periodo di contesa. Il PC, invece ha la possibilita' di operare ritrasmissioni di frame non confermati (di cui, cioe', non ha ricevuto l'ACK) dopo un periodo di backoff di lunghezza temporale pari a PIFS?.

Struttura e tempistiche con PCF

20061210-1817 SoujaK
Come gia' anticipato i periodi liberi dalla contesa (CFP), in cui la trasmissione e' coordinata da PCF, si alternano temporalmente a periodi di contesa (CP) in cui il coordinamento e' gestito secondo DCF. I CFP hanno inizio dopo un frame Beacon contenente un apposito DTIM (Delivery Traffic Indication Message, messaggio di indicazione sul traffico della consegna) e avranno luogo con frequenze ben definite. Queste frequenze sono espresse come quantita' di intervalli DTIM, e sono comunicate dal PC alle altre stazioni tramite un campo appartenente ai frame Beacon, nel set dei parametri dedicati a CF.

La durata dei CFP e' invece di appannaggio del coordinatore che ha liberta' di scelta, purche' essa sia dichiarata preventivamente nel parametro CFP-MaxDuration, appartenente al set precedentemente citato. Non e' inoltre necessario che la durata del CFP sia multipla dell'intervallo di trasmissione dei Beacon, dal momento che essi contengono anche un campo "CFPDurRemaining" che (come il nome suggerisce) indica il tempo rimanente alla fine del periodo libero dalla contesa, espresso in TU?. In ogni caso la durata del CFP e' al piu' pari al valore inizialmente dichiarato dal PC, quindi va precisato che, qualora la trasmissione dei frame Beacon iniziale venga ritardata (rispetto al TBTT?) a causa dell'alto carico del mezzo trasmissivo, il CFP puo' essere terminato anticipatamente di una quantita' di tempo pari al ritardo.

Procedura di accesso del PCF

20061210-1931 SoujaK
Il protocollo di trasmissione libero da contesa e' basato su uno schema di polling attuato dal coordinatore che opera nel' access-point del BSS. Durante questo lasso di tempo il PC prima prende il controllo del canale, e poi si assicura di mantenerlo. Prima di ogni sua trasmissione, infatti, attende per intervalli di tempo minori rispetto a quelli di ogni stazione operante tramite DCF. In generale tutte le stazioni diverse dal PC che sono presenti nel BSS setteranno il loro NAV in accordo con il valore del parametro CFPMaxDuration comunicato dal coordinatore. Per minimizzare il numero di trasmissioni sono definite dallo standard precisi sequenze con cui concatenare le informazioni aggregate tramite la pratica del piggyback.

Accesso di base al mezzo

20061211-1508 SoujaK
All'inizio nominale di ogni CFP il PC controlla che il mezzo trasmissivo sia inutilizzato per un periodo lungo PIFS. Dopodiche' puo' trasmettere un frame Beacon contenente il set di parametri dedicati al CF settati in maniera opportuna unitamente ad un elemento DTIM.

Dopo la trasmissione iniziale il coordinatore e' tenuto ad attendere almeno per un periodo SIFS, poi puo' cominciare a tramettere un frame di dati, un frame di tipo CF-Poll, un frame contenente dati assieme al CF-Poll oppure un frame CF-End. Nel caso in cui il CFP sia di durata nulla, perche' il PC non ha accumulato ne' traffico ne' poll, esso inviera' subito dopo il beacon il frame CF-End.

Le stazioni che ricevono frame senza errori sono tenute a rispondere dopo un periodo SIFS, in accordo con le procedure che descriveremo piu' avanti ###todolink. Le STA riceventi che non siano di tipo CF-Pollable, segnaleranno il successo della ricezione con un classico frame ACK.

Uso del NAV

20061218-1449 SoujaK
Le modalita' di gestione del NAV durante i periodi liberi da contesa sono state pensate per consentire la sovrapposizione di piu' BSS di tipo infrastruttura. Ogni stazione (fatta eccezione per il PC) e' tenuto a preimpostare il il proprio NAV con frequenza dettata dal TBTT (target beacon trasmission time) e con il valore del parametro CFPMaxDuration contenuto nei frame beacon. Le varie STA potranno settare in maniera piu' accurata il NAV soltanto in seguito, utilizzando il parametro CFPDurRemaining presente nei frame beacon. E' fondamentale notare che, al fine di gestire la sovrapposizione delle BSS le stazioni diverse dal PC prenderanno in considerazione anche i beacon provenienti da BSS diverse dalla propria.

Procedura di trasferimento

DA FARE

Gestione degli strati

I due livelli (data link e fisico) su cui lo standard e' definito possiedono un insieme di operazioni primitive proprie, ma le loro definizioni sono lungi dal poter essere considerate vere e proprie interfacce: si tratta delle "MAC layer management entities" (MLME) e delle "PHY layer management entities" (PLME). E' assai importante notare, specialmente ai fini dello studio in oggetto, che lo strato MAC non oscura il sottostante PHY, ma permette alla "station management entity" (SME) di interagire direttamente con esso. Le varie entita' hanno la possibilita' di comunicare fra loro secondo le specifiche dello standard, attraverso i SAP (service access point). Tale concetto intende aggregare l'insieme di chiamate che una determinata entita' espone alle altre per realizzare forme di comunicazione o invocazione. 

  __||________________________
 |      |      |              |
 | MAC  | MLME =              |
 |      |      |              |
 |--||--|--||--| Station      |
 |      |      | Managemement |
 | PLPC | PLME | Entity       |
 |      |      |              |
 |--||--|      =              |
 |      |      |              |
 | PMD  |      |              |
 |______|______|______________|

In generale il livello MAC, come ovvio, deve essere il piu' possibile indipendente da quello fisico anche se a volte e' necessario che il livello MAC gestisca stati opportuni del livello fisico.

Il livello PHY viene suddiviso nella seguente maniera:

  • PLCP (Physical Layer Convergence Procedure): funzioni di convergenza del livello fisico (adattamento del mezzo ai servizi PHY), che realizzano una traduzione al fine di rendere l'interfaccia comune;
  • PMD (Physical Medium Dependent): insieme di funzioni fortemente dipendenti dallo specifico dispositivo wireless (ad esempio richieste di trasmissione o ricezione di dati).

Anche in questo caso le relazioni con l'esterno sono gestite da appositi moduli SAP: uno specifico per la porzione PLCP (PLCP-SAP) e un altro relativo al sottostrato PMD (PMD-SAP).

Primitive di gestione generica

Le informazioni specifiche per la gestione di ogni strato sono incapsulate all'interno di cio' che viene definita Management Information Base (MIB) che puo' essere visto come un componente di ogni livello. In accordo con questo, ogni Management Entity possiede specifiche primitive di GET e SET in grado di operare sugli attributi della relativa MIB. Informazioni dettagliate sugli attributi dei vari MIB sono presenti nel ​documento ufficiale

Interfaccia di MAC: MLME SAP

  • POWERMGT: richieste al modulo che gestisce il risparmio energetico
  • SCAN: scansione della rete alla ricerca di BSS disponibili
  • JOIN: sincronizzazione con un BSS
  • AUTHENTICATE: autenticazione con un BSS
  • DEAUTHENTICATE: deautenticazione con un BSS
  • ASSOCIATE: associazione fra una STA e un AP
  • REASSOCIATE: associazione fra una STA e un altro AP
  • DEASSOCIATE: dissociazione fra una STA e un AP
  • RESET: azzeramento
  • START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete ad-hoc)

20061019-0920 SoujaK: La revisione G del documento non introduce nessun cambiamento alle interfacce del SAP legato al livello MAC. Viene piuttosto esteso il livello PHY al fine di supportare larghezze di banda maggiori e differenti modulazioni del segnale.

Interfaccia di PHY: PLME SAP

In generale si hanno disposizione tutti i getter e i setter necessari per manipolare tutti gli attributi del MIB (normati nell'aggiunta Annex D). Inoltre, si hanno a disposizione le seguenti primitive:

  • RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato di ricezione;
  • CHARACTERISTICS.request: ritorna le caratteristiche operative della entita' PHY;
  • CHARACTERISTICS.confirm: viene sollevata dal'entita' PHY successivamente ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative dell'entita' PHY;
  • DSSSTESTMODE.request: utile per entrare in modalita' test in una entita' PHY di tipo DSSS;
  • DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una entita' PHY di tipo DSSS.

Interfaccia di PHY: PHY SAP

Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire un meccanismo indipendente dalla PHY entity per trasferire MPDU fra le STA. Anche in questa sezione, i servizi vengono definiti in maniera puramente astratta, in modo da non forzare a particolari implementazioni delle interfacce.

Le primitive tra MAC e PHY si possono dividere in due categorie:

  • primitive per il supporto d'interazioni punto-a-punto a livello MAC (primitiva PHY-DATA.{request, confirm, receive, indication}).
  • primitive con significato locale per agevolare l'interazione tra sottolivelli (e.g. PHY-TXStart.{request,...}).

20061211-2200 gnappo
L'unica primitiva per il supporto dell'interazione peer-to-peer e' PHY-DATA alla quale sono associati i seguenti significati:

  • PHY-DATA.request(DATA): trasferisce un ottetto di dati alla PHY entity successivamente ad una confermata richiesta di trasmissione (PHY-TXSTART.confirm). Quando la PHY entity ricevera' l'ottetto di dati indichera' l'avvenuta ricezione attraverso la primitiva PHY-DATA.confirm.
  • PHY-DATA.indication: trasferisce un ottetto di dati dal livello fisico al livello MAC.
  • PHY-DATA.confirm: come gia' accennato, viene sollevata dalla PHY entity per confermare l'avvenuta ricezione dei dati dalla MAC entity.

Le altre primitive sono:

  • PHY-TXSTART.request(TXVECTOR): permette al sottolivello MAC di richiedere all'entita' fisica di cominciare la trasmissione di un MPDU. Come dato in ingresso, prende un vettore contenente parametri sia del sottolivello PLCP che di PHY.
  • PHY-TXSTART.confirm: viene sollevata dal sottolivello PHY per confermare, alla MAC entity, l'avvenuto inizio di trasmissione. In questo modo, l'entita' fisica, si dichiara disponibile a ricevere dati attraverso PHY-DATA.request(DATA).
  • PHY-TXEND.request: e' invocata dalla MAC entity per forzare il completamento della trasmissione del MPDU corrente. Viene generata conseguentemente all'ultima chiamata PHY-DATA.confirm per l'MPDU corrente.
  • PHY-TXEND.confirm: utilizzata dal sottolivello fisico per notificare all'entita' MAC il completamento della trasmissione. Il recepimento di questa primitiva da parte della MAC entity fornisce il riferimento temporale per il protocollo di backoff.
  • PHY-CCARESET.request: viene richiesta dalla MAC entity per ottenere un reset dell'automa a stati finiti per il Clear Channel Assessment (valutazione del canale libero). E' generata dalla MAC entity allo scadere del NAV timer.
  • PHY-CCAREST.confirm: sollevata dall'entita' fisica per confermare l'avvenuto reset dell'automa di cui al punto precedente.
  • PHY-CCAREST.indication: questa primitiva ritorna, all'entita' MAC, lo stato del canale (idle oppure busy). Viene generata ogni qualvolta si ha una transizione del canale da libero a occupato e viceversa.
  • PHY-RXSTART.indication: sollevata dal livello fisico per informare il livello MAC che e' stato ricevuto un SFD e un'intestazione PLCP valida (e che quindi avra' inizio la ricezione di un frame).
  • PHY-RXEND.indication: grazie a questa primitiva l'entita' fisica comunica all'entita' MAC la fine della ricezione di un MPDU ed indica eventuali errori occorsi.

Specifiche per il livello PHY

FHSS

20061104-1743 gnappo
FHSS (Frequency Hopping Spread Spectrum) e' una specifica del livello PHY, presente nella prima versione dello standard. L'obiettivo primo da perseguire, come gia' chiarito nei paragrafi precedenti, e' l'indipendenza del livello MAC dal livello PHY. E' per questo motivo che, nel documento, vengono ratificate adeguate funzioni di convergenza al mezzo trasmissivo oltre alle usuali funzioni dipendenti dal medium.
La caratteristica saliente di questa specifica e' rappresentata dal fatto che la trasmissione non avviene sempre alla stessa frequenza (canale), ma si effettuano i cosiddetti hopping, cioe' dei salti di frequenza pseudo-casuali (ovviamente dettati da uno specifico algoritmo). In questo modo si massimizza il throughput della rete e si minimizzano le interferenze.
Per l'Europa, lo standard definisce il range delle frequenze operative da 2.400 GHz a 2.4835 GHz per un totale di 79 canali differenti.
I data-rate supportati sono:

  • 1 Mbit/s: utilizzando la modulazione GFSK
  • 2 Mbit/s: utilizzando la modulazione 4GFSK. L'header PLCP viene comunque trasmesso ad 1 Mbit/s.

E' importante sottolineare come la sequenza di salto dei canali sia in realta' dettata dal livello MAC: ogni beacon e ogni frame Probe Response contengono le informazioni necessarie per la sincronizzazione e per la determinazione del pattern di hopping.

Alcune informazioni sulle tempistiche riguardanti i canali:

  • 224us e' il tempo massimo concesso per switch su canale;
  • 400ms e' il tempo massimo di permanenza sul canale;
  • 19ms e' il tempo consigliato di permanenza sul canale.

OFDM

20061028 gnappo
OFDM (Ortogonal Division Frequency Multiplexing) viene introdotto con la revisione a dello standard 802.11. I data-rate forniti sono: 6, 9, 12, 18, 24, 36, 48 e 54 Mbit/s. Solamente i 6, 12 e 24 Mbit/s sono, tuttavia, obbligatori. La banda di frequenze nella quale OFDM opera e' quella dei 5 GHz. Essenzialmente con OFDM si tentano di inviare piu' stream di bit in parallelo. Lo spettro delle frequenze viene suddiviso in piu' sotto-canali, in ognuno dei quali viene impiegato uno schema di modulazione standard (e.g. fase) per la trasmissione. La scelta dei sotto-canali e' operata in modo tale da eliminare interferenze tra gli stessi (sono ortogonali l'uno all'altro). Rimane, comunque, uno standard poco utilizzato sia a causa delle sue incompatibilita' (802.11b e 802.11g) sia per le caratteristiche operative (in molti paesi la banda dei 5Ghz e' tuttora riservata).

DSSS

20061021 gnappo
DSSS (Direct Sequence Spread Spectrum) e' un'altra specifica del livello fisico che permette di raggiungere in linea teorica un capacita' trasmissiva pari a 11Mbit/s (802.11b). Attraverso opportune tecniche e' possibile fornire bitrate inferiori (in tal modo si ottiene compatibilita' all'indietro). Come descritto precedentemente, anche in questa occasione avremo opportune funzioni di convergenza atte a garantire l'indipendenza di MAC rispetto alla specifica implementazione di PHY.
Il PPDU e', naturalmente, differente rispetto a quello definito per FHSS (nel seguito troverete qualche dettaglio). Interessante osservare che il preambolo e l'header del frame sono trasmessi, diversamente dal resto, ad un 1Mbit/s per assicurarsi che l'interlocutore capisca effettivamente questa parte essenziale della comunicazione. L'effettivo invio del payload (MPDU) potra' essere compiuto con modulazioni diverse opportunamente specificate nell' header (campo SIGNAL).

Algoritmo di trasmissione

20061021 gnappo
Per trasmettere i dati, PHY-TXSTART.request dev'essere abilitata per portare PHY nello stato di trasmettitore (precedentemente su ricevitore). Il canale su cui trasmettere e' regolato via PLME. Se il canale risulta libero (PHY-CCA.indicate) allora MAC puo' procedere all'effettivo invio invocando la primitiva PHY-TXSTART.request (PHY-SAP) passando i parametri necessari (DATARATE, TX_ANTENNA, TXPWR_LEVEL). Una volta terminato l'invio del preambolo, attraverso una serie di chiamate PHY-DATA.request(DATA) verrano scambiati i dati tra MAC e PHY. Al termine della trasmissione l'entita' fisica ritornera' allo stato di ricevitore.

Algoritmo di ricezione

20061021 gnappo
Per quanto riguarda la ricezione, e' necessario che l'entita' fisica sia nello stato di ricevitore (quindi PHY-TXSTART disabilitato). Attraverso la PLME e' possibile scegliere il canale su cui ascoltare ed il metodo di CCA (Clear Channel Assessment). Altri parametri (come per la trasmissione) sono passati attraverso PHY-SAP. Non appena il dispositivo ha rilevato attivita' sul canale sul quale e' in ascolto, PHY invoca la primitiva PHY-CCA.indicate con la quale informa MAC che il canale e' BUSY. Dopodiche' PHY va alla ricerca di un delimitatore di inizio frame e procede alla lettura dell'header. Se la lettura va a buon fine (i.e. formato riconosciuto, niente errori su CRC) allora viene chiamata la primitiva PHY-RXSTART.indicate per mettere a conoscenza di MAC di informazioni contenute nell'header (i.e. campo SIGNAL, lunghezza del MPDU, RX_ANTENNA, RSSI, SQ, campo SERVICE). I dati successivamente ricevuti saranno assemblati e presentati a MAC attraverso la primitiva PHY-DATA.indicate(DATA). Al termine dell'intera ricezione lo stato del ricevitore ritornera' IDLE e sara' sollevata la primitiva PHY-RXEND.indicate(NoError). Se la ricezione non andasse a buon fine, PHY informerebbe MAC attraverso la primitiva PHY-RXEND.indicate della causa dell'errore (e.g. CarrierLost).

Note sulla modulazione

20061106-1100 gnappo
Il segnale da trasmettere viene convertito da flusso di bit in flusso di simboli, dove ogni simbolo rappresenta una stringa di bit (la cui lunghezza dipende dalle particolari tecniche di codifica). Tale flusso, verra' poi combinato con una sequenza di bit Pseudo-noise detta chip sequence, con frequenza maggiore rispetto a quella del segnale. In uscita, quindi, avremo un segnale che sara' diffuso su una banda di frequenze piu' larga.
Il ricevitore, utilizzando la stessa chip sequence, sara' in grado di ricostruire il segnale originale.
La banda a 2.4 GHz e' suddivisa in 14 canali ciascuno dei quali occupa 22 MHz.

Note

Per quanto riguarda questioni di tempistiche ed altre informazioni dettagliate (MIB attributes) rimando alle specifiche ieee, capitolo 15.

HR/DSSS (802.11b/802.11g)

20061022-2130 Zeratul
High Rate Direct Sequence Spread Spectrum (HR/DSSS) e' l'evoluzione della "semplice" DSSS che consente di portare la bandwith massima a 5.5 o 11 Mbps (nell'802.11g si arrivera' anche a circa 54 Mbps). Gli header e preamboli PLCP sono gli stessi della DSSS, in questo modo e' possibile la coesistenza di entrambe le modulazioni in una stessa connessione.

Le sostanziali differenze con il suo predecessore sono molteplici:

  1. si sono riuniti i ​chips in gruppi da 8 formando cosi chiavi a codice complementario (8-chip complementary code keying a.k.a. CCK) che vengono spediti alla stessa frequenza del DSSS (11 MHz), ottimizzando cosi l'uso della banda del canale;
  2. sono state aggiunte delle funzionalita' opzionali per aumentare il bandwith, che sono utilizzabili solo se l'hardware e' abbastanza recente da supportarle.
    Le funzionalita' sono le seguenti:
    • sostituzione del CCK con il packet binary convolutional coding (HR/DSSS/PBCC);
    • HR/DSSS/short, ovvero possibilita' di ridurre il preambolo PLCP per aumentare significantemente il transfer data rate, limitando cosi pero' la possibilita' di coesistenza con il DSSS a sole alcune particolari circostanze;
    • inserimento del Channel Agility, ovvero una particolare implementazione che consente di superare diversi problemi dovuti all'assegnamento di un canale statico, senza dover aggiungere alla totale implementazione il costo di questa funzionalita'.

Purtroppo l'IEEE non ha concesso le specifiche inerenti all'evoluzione della modulazione nella versione 802.11g, quindi non ci e' concesso sapere i miglioramenti che hanno portato poi il protocollo a supportare velocita' di circa 54 Mbps.
Parlandone con il Dott. Bononi, si e' arrivati ad ipotizzare che lo sviluppo sempre piu' veloce della tecnologia abbia portato ad un'alta precisione e sensibilita' di ricezione/trasmissione che abbia sua volta portato ad un'aumento dei simboli (in modulazione un simbolo e' un particolare segnale che identifica una serie di bit) e ad una diminuzione dei bit adibiti al controllo di errori, cosi aumentandone di molto il bit rate potenziale.
Rimaniamo comunque nella ricerca di specifiche piu' recentemente rilasciate, lasciando quest'ultima parte di paragrafo come "prossima ad essere aggiornata".

Formato dei frame MAC

20061111-1735 gnappo
Ciascun MAC frame e' composto dalle seguenti parti:

  1. un header che comprende informazioni sul controllo (del frame stesso), la durata, l'indirizzo e il controllo di sequenza del frame;
  2. il frame body contenente informazioni dipendenti dal tipo di frame in oggetto e di lunghezza variabile;
  3. un Frame Check Sequence, cioe' un codice di rilevazione d'errore.

gnappo: inserire qua "screenshot" formato frame. I paragrafi sottostanti ne illustrano i campi.

Frame Control

20061111-1735 gnappo
A seguire una disamina dei campi contenuti nel cosiddetto Frame Control:

  • campo di versione del protocollo (i.e. 802.11{a,b,g,...}): una stazione che riceve un frame di una versione di protocollo non supportata lo potra' scartare senza informare la stazione mittente o LLC;
  • campi di tipo e sottotipo: identificano il tipo di frame (controllo, dato o management). I sottotipi chiariscono nello specifico la funzionalita' del frame (e.g. un frame di management potrebbe essere un frame contente una richiesta di autenticazione oppure di associazione). Si rimanda alla tabella 1 per tutte le possibili combinazioni per i due campi.
  • Campo To DS: indica se il frame e' destinato al Distribution System (e.g. tutti i frame inviati dalle STA verso gli AP hanno questo flag asserito);
  • campo from DS: indica se il frame proviene dal Distribution System;
  • campo More Fragments: indica se il frame corrente ha altri frammenti a seguire;
  • campo Retry: e' asserito se il frame corrente e' una ritrasmissione di uno precedente aiutando cosi' il ricevitore nel processo di eliminazione di frame duplicati;
  • campo Power Management: indica se la stazione opera in active oppure power-save mode;
  • campo More Data: si tratta di un bit che se asserito, indica alla stazione in power-save che l'AP ha MSDU o MMPDU bufferizzati a lei diretti pronti per l'invio. Inoltre il bit puo' essere valido in una trasmissione tra STA CF-pollable e AP come risposta ad un CF-poll per indicare che la STA ha almeno un MSDU "bufferizzato" pronto per l'invio. Vale ancora 1 anche per le trasmissioni in broadcast dell'AP qualora abbia altri MSDU o MMPDU da inviare entro l'invio del prossimo beacon.
  • Campo WEP: indica se il frame body e' stato crittografato utilizzando WEP. Il campo e' significativo solo nei frame di tipo Management sottotipo Authentication e nei frame di tipo Data.
  • Campo Order: indica se il frame e' stato spedito utilizzando la classe di servizio StrictlyOrder

gnappo: che cos'e' la classe di servizio StrictlyOrder?

Duration/ID

20061111-1735 gnappo
Il campo Duration/ID ha due interpretazioni a seconda della situazione:

  1. in frame Power Save (PS)-Poll contiene l' association id (AID) della stazione trasmittente;
  2. per tutti gli altri frame contiene un valore di durata di impiego del mezzo trasmissivo. Ad esempio in un frame RTS il valore del campo Duration e' dato dalla somma del tempo di trasmissione dei dati pendenti, di un CTS, di un frame ACK e di tre SIFS. Per frame inviati durante il CFP il valore e' fissato a 32768.

Ogni volta che il contenuto del campo Duration/ID e' minore di 32768 ogni STA aggiorna il proprio NAV (Network Allocation Vector).

Address

20061111-1735 gnappo
Ci sono 4 campi address in un frame MAC utilizzati per identificare il BSSID, gli indirizzi della stazione sorgente, destinazione, trasmittente e ricevente. Alcuni frame potrebbero non contenere alcuni di questi sottocampi.
Gli indirizzi si suddividono in:

  • indirizzi individuali;
  • indirizzi di gruppo: multicast oppure broadcast.

Il BSSID denota univocamente ogni BSS. Per quanto riguarda le IBSS questo valore e' determinato da un algoritmo che genera numeri "random" con un'elevata probabilita' di esser unici.

Sequence number

20061111-1735 gnappo
Questo campo e' suddiviso in due sottocampi: un campo contenente il numero di sequenza di MSDU/MMPDU (modulo 4096) ed un altro per il conteggio dei frammenti di ciascun MSDU/MMPDU (eventualmente zero).

Frame Body

20061111-1735 gnappo
Come gia' affermato in precedenza, questo campo contiene l'effettivo data-load.

FCS

20061111-1735 gnappo
Campo contentente il codice di ridondanza ciclica (CRC) a 32 bit calcolato su tutti i campi del MAC header e sul frame body.

Alcune note sui frame di management

20061111-1735 gnappo
A differenziare il formato dei diversi frame di management e' solo il loro rispettivo corpo, diversamente fissato sul numero e tipo dei campi in esso contenuti.
A seguire un elenco dei frame di management e una sintetica descrizione del loro contenuto:

  • beacon: timestamp, beacon interval (rappresenta il numero di TU che intercorrono tra le trasmissioni dei beacon), informazioni sulle capacita' del nodo, parametri della rete (fisica) e dei servizi (se l'AP supporta PCF allora nei beacon saranno contenuti i parametri necessari alle STA);
  • disassociation: ragione della richiesta di dissociazione;
  • association request: informazioni sulle capacita' della STA, intervallo di ascolto (i.e. ogni quanto tempo la STA si "risveglia" per ascoltare i beacon dell'AP), SSID, rate supportati;
  • association response: informazioni sulle capacita' dell'AP, stato dell'associazione (valida oppure errore), identificativo dell'associazione, rate supportati;
  • reassociation response: come sopra;
  • probe request: SSID, rate supportati;
  • probe response: analogo al beacon;
  • authentication: numero identificante l'algoritmo di autenticazione, numero identificante lo step del processo di autenticazione, stato, challenge text (presente solo in particolari frame di autenticazione);
    gnappo: dove e quando e' utilizzato?
  • deauthentication: ragione della richiesta di disautenticazione.

Management del sottolivello MAC

Uno degli aspetti piu' importanti, per quanto riguarda la connessione di piu' host ad una rete wireless, e' sicuramente il meccanismo di sincronizzazione, il quale deve esistere per permettere la comunicazione all'interno della rete. Per permettere cio' ogni nodo ha al suo interno un TSF (Timing Synchronization Function) che funge da orologio per tutti i nodi. La sincronizzazione e' presente sia nei BSS che nei IBSS e avviene in maniere differenti.

In un BSS la sincronizzazione viene mantenuta dall'AP, che inizializza il suo TSF interno e invia beacons a tutti i nodi della rete con all'interno il proprio timer. Ogni nodo che riceve il beacon deve sincronizzare il proprio timer con il valore del timestamp ricevuto.

In un IBSS invece ogni nodo partecipa allla sincronizzazione mediante l'utilizzo di un algoritmo distribuito; in pratica ogni nodo invia dei beacon ad ogni nodo della rete e riceve beacons da tutti gli altri. Decide poi autonomamente se settare il proprio timer col valore ricevuto o se scartare il beacon perche' il valore del timetamp all'interno e' piu' vecchio del valore del proprio timer.

Il mantenimento della sincronizzazione e' dato da un algoritmo: ogni nodo mantiene un timer TSF in modulo 264 microsecondi e si aspetta di ricevere un beacon ad intervalli regolari (definiti come aBeaconPeriod, che e' un parametro del nodo). Un nodo che vuole inviare un beacon deve settare il valore del timestamp, che e' dato dalla somma tra il valore del TSF al tempo della trasmissione del primo bit del timestamp su PHY e dal tempo di ritardo per la trasmissione (passaggio dall'interfaccia MAC-PHY a PHY).

Acquisizione della sincronizzazione mediante scansione

Ogni stazione (o nodo) puo' operare attraverso due modalita' di scansione: la modalita' passiva o la modalita' attiva. In modalita' di scansione passiva la stazione sta in ascolto su tutti i canali e aspetta di ricevere dei beacon in cui il valore SSID sia uguale al valore SSID dell'ESS di cui la stazione vuole entrare a fare parte. Una volta ritornati questi frame, la stazione (attraverso opportune funzioni) entra a far parte di un BSS, acquisendo tutti i parametri del BSS (timer di sincronizzazione, parametri di PHY, BSSID, parametri di trasmissione dei beacon...).

La modalita' di scansione attiva invece si basa sullo scambio di frame di tipo Probe Request e Probe Response: praticamente una stazione invia una richiesta e si mette in ascolto di una risposta. Quando giunge il frame Probe Response contenente il SSID cercato dalla stazione ha poi inizio la sincronizzazione e da quel momento la stazione entra a far parte di un BSS. L'algoritmo di scansione e' descritto nel dettaglio nella sezione 11.1.3.2.2 (pag 127 di IEEE 802.11-1999).

Associazione e riassociazione di una stazione con un AP

L'associazione tra una stazione e un AP avviene in due fasi:

  • autenticazione
  • associazione

Una volta effettuata l'autenticazione su un AP, la stazione invia una richiesta di associazione all'AP e attende la risposta; in caso di risposta affermativa la stazione sara' fisicamente associata all'AP e potra' avviare la comunicazione, in caso contrario la stazione non si potra' associare. Analogamente quando una stazione vorra' riassociarsi ad un AP inviera' allo stesso una richiesta di riassociazione e attendera' la risposta dall'AP. Naturalmente, quando un AP riceve una richiesta di associazione controlla che la stazione che ha inviato tale richiesta sia autenticata presso di lui; in caso affermativo l'AP inviera' una risposta (positiva o negativa) alla stazione interessata.

Power Management

20061108-1512 Roma
Le stazione possono cambiare il proprio power management, informando preventivamente l'AP al quale sono associate, accondando la richiesta di cambio al campo Frame Control del frame inviato all'AP. L'AP deve tener traccia di tutte le stazione che operano in modalita' power save in quanto la trasmissione dei dati a tali stazioni deve avvenire in modo differente rispetto alle stazioni che non operano in tale modalita'; infatti un AP non puo' trasmettere i dati in maniera arbitraria alle stazioni in modalita' power save ma deve bufferizzarli per poi trasmetterli in momenti precisi.
20061109-1424 SoujaK: Il pezzo seguente e' da chiarire
Tutte le stazioni che ricevono dati bufferizzati dall'AP sono riunite nel TIM (Traffic Indication Map) il quale rappresenta un campo dei vari beacon generati dall'AP stesso. Ogni stazione per sapere se i dati ricevuti sono stati bufferizzati per lei deve ricevere e interpretare il TIM associato al beacon ( per fare cio' ogni stazione si mette peridicamente in ascolto di beacon, e quindi in ascolto per ricevere eventuali TIM, secondo opportune funzioni). In un BSS ogni stazione (in modalita' power save) per sapere se dei dati sono stati correttamente bufferizzati invia un frame di tipo PS-Poll all'AP, il quale rispondera' o inviando direttamente i dati bufferizzati o acknowledgiando la richiesta e inviando i dati successivamente. Ogni stazione puo' lavorare in due modalita':

  • awake
  • doze

Nella modalita' awake la stazione lavora a piena potenza e puo' ricevere frame in qualsiasi momento; e' detta anche modalita' attiva. Nella modalita' doze la stazione lavora in power save e riceve frame attraverso il meccanismo sopra descritto. Naturalmente le stazioni possono passare da una modalita' all'altra, ma possono farlo solo alla fine di uno scambio di dati informando l'AP del cambio.

Power Management in un IBSS

In un IBSS le stazioni devono essere tutte sincronizzate al fine di poter trasmettere i dati; quando i dati sono bufferizzati e pronti per essere spediti ad una stazione in power save ci deve essere un annuncio tra tutte le stazioni affinche' l'operazione si possa effettuare. Tale annuncio e' dato tramite l'invio di un ATIM (Ad hoc TIM) quando tutte le stazioni dell' IBSS sono in modalita' awake. Quando i dati devono essere trasmessi la stazione trasmittente invia prima un frame ATIM nel ATIM Window (che e' un periodo nel quale vengono inviati solo frame ATIM o beacon) e aspetta l'ACK di quel frame; se cio' non avviene la stazione attiva la procedura di ritrasmissione dell'ATIM. Una stazione che acknowledgi l'ATIM durante l'ATIM Window deve rimanere nella modalita' awake e aspettare l'annuncio. Una volta che avviane l'ACK ed e' passato l'ATIM Window, la stazione ricevente passa in modalita' power save e puo' ricevere i dati.

Autenticazione e privacy

20061114-1114 Roma
802.11 fornisce un servizio di autenticazione diviso in due sottotipi:

  • Open System
  • Shared Key

I due sottotipi svolgono un algoritmo di autenticazione e sono indicati nel corpo del frame che gestisce l'autenticazione;questi tipi di frames devono essere scambiati solo tra due nodi( una stazione e un AP in un BSS,tra due stazioni in un IBSS ) e non possono essere in broadcast.

Autenticazione Open System

L'autenticazione Open System e' basata sull'algoritmo di autenticazione piu' semplice tra quelli disponibili (detto anche algoritmo null). Ogni stazione che utilizza questo algoritmo puo' essere autenticata se l'authenticationType della stazione che gestisce le autenticazioni e' settato su Open System.

L'autenticazione Open System (o meglio l'algoritmo utilizzato da questo sottotipo) e' divisa in due sottosequenze; la prima determina l'identificazione della stazione e la richiesta di autenticazione, la seconda determina il risultato dell'autenticazione (se e' corretto le due stazioni sono mutuamente autenticate).

Autenticazione Shared Key

L'autenticazione Shared Key supporta l'autenticazione di stazioni se almeno una delle due stazioni conosce la chiave condivisa segreta, la quale e' parte fondamentale dell'algoritmo. L'algoritmo e' completato senza il bisogno di trasmettere la chiave segreta in chiaro ma servendosi del meccanismo WEP. Infatti questo meccanismo di autenticazione funziona solamente se il meccanismo WEP e' implementato e se l'algoritmo Shared Key e' implementato nelle stazioni che gia' implementano WEP.

La chiave segreta viene consegnata da una stazione all'altra mediante un canale sicuro che e' indipendente da 802.11;la chiave e' contenuta in un attributo write-only denominato MIB che viene spedito dal livello MAC.
SoujaK: a quanto ne so, MIB denota l'insieme di attributi di un sottolivello e non il nome di questo specifico attributo

Dato che l'attributo e' write-only il valore della chiave rimane all'interno di MAC. Durante il processo di autenticazione tra due stazioni vengono inviati un challenge e un encrypted challenge e questo processo e' diviso in quattro fasi (un frame inviato per ogni fase):

  • viene settato il primo frame con tutti i parametri neccesari.
  • prima di spedire il secondo frame la stazione rispondente utilizza WEP per generare una stringa di ottetti che sono utilizzati come challenge.
    SoujaK: il concetto di challenge non e' spiegato
  • il richiedente riceve il challenge dal secondo frame e lo copia nel terzo frame; a questo punto WEP (mediante la chiave segrete) cripta il terzo frame.
  • il rispondente riceve il terzo frame e lo decripta sempre mediante WEP; una volta decriptato il challenge lo confronta col proprio challenge (spedito nel secondo frame). Se sono uguali allora il rispondente mandata un frame di conferma e l'autenticazione e' avvenuta, altrimenti viene inviato un frame di insuccesso.

Algoritmo Wired Equivalent Privacy (WEP)

20061015-1550 Roma
WEP e' un particolare algoritmo utilizzato nelle reti wireless per proteggere gli utenti autorizzati da sniffing e da altri tipi di intrusioni. Il servizio fornito da WEP si prefigge l'obiettivo di provvedere alla sicurezza dei dati nella stessa maniera di come vengono protetti nei dispositivi interconnessi via cavo.

La sicurezza dei dati e' data da un gestore esterno che distribuisce i dati criptati e le chiavi per decriptarli. Le proprieta' di WEP sono:

  • grande stabilita', perche' e' molto difficile trovare la chiave giusta mediante un attacco brute-force e il motivo sta nella lunghezza della chiave e dalla frequenza di cambio di chiave.
  • auto-sincronizzazione, in quanto WEP e' in grado di autosincronizzarsi per ogni transazione che deve svolgere.
  • efficenza, in quanto e' implementabile sia via hardware che via software
  • esportabilita'
  • opzionabilita', in quanto WEP e' un' opzione di 802.11.

SoujaK: opzionabilita'?

Come funziona WEP

20061117-0955 roma
L'algoritmo WEP e' una sorta di libro codificato nel quale ogni blocco del testo in chiaro viene messo in XOR con una sequenza di chiave pseudo-casuale di lunghezza uguale alla lunghezza di tale blocco; tale sequenza e' generata da WEP.

La cifratura dei dati avviene nel modo seguente: vi e' una chiave segreta che viene distribuita tra tutte le stazioni cooperanti da un gestore esterno e tale chiave e' utilizzata da WEP sia per cifrare che per decifrare i dati (WEP e' un algoritmo simmetrico).

La chiave viene concatenata con un vettore di inizializzazione (IV) e diventa input per formare un PRNG (Pseudo Random Number Generator). PRNG, mette in output una nuova chiave composta da una sequenza di ottetti (pseudo-casuali) il cui numero e' uguale alla lunghezza dei dati da trasmettere piu' quattro (serve per Integrity Check Value o ICV). Ora i dati in chiaro vengono cifrati grazie alla concatenatura di essi con ICV e la chiave generata da PRNG. La stazione che inviera' il messaggio cifrato inviera' anche l'IV.

Vi sono dettagli importanti da tenere presente:

  • IV consente l'auto-sicronizzazione di WEP e allunga la vita della chiave segreta che deve essere aggiornata periodicamente.
  • Nonostante quello detto sopra la chiave segreta e' del tutto indipendete da IV e puo' rimanere fissa mentre IV cambia.
  • Ad ogni cambio di IV si possono generare nuove chiavi grazie a PRNG ed e' per questo che IV viene trasmesso insieme ai dati cifrati (in quanto consente sia la cifratura che la decifratira dei dati).
  • IV viene trasmesso in chiaro in quanto non si puo' risalire alla chiave segreta da esso.

Appunti vari

20061014-1305 Roma
Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi e' praticamente una serie di richieste tra il client e l'AP affinche' la connessione venga instaurata; nota importante e' che il client prima di collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova connessione. Naturalmente vi sono gia' delle primitive implementate atte a svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che per le reinstaurazione). Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro (es che fece anche il seminarista se non ricordo male) e per fare cio' si inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte comunque c'e' l'AP che controlla tutta la sincronizzazione ed egli stesso manda pancette ai client conessi a lui; quindi vi e' una doppia sincronizzazione: una tra AP e client e una tra client e client (cap 11 del documento ieee 802.11).

Last modified 18 years ago Last modified on Feb 16, 2007, 8:20:34 PM