= Analisi dello standard IEEE 802.11 = [[PageOutline(1-6,Indice dei contenuti)]] == Descrizione generale == === Descrizione generale dell'architettura === ,,20061120 SoujaK,, [[BR]] 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,, [[BR]] 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. [[BR]] 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.[[BR]] 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,, [[BR]] 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,, [[BR]] 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,, [[BR]] 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,, [[BR]] 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 [wiki:Protocollo#Acquisizionedellasincronizzazionemediantescansione scansione]. ==== Riassociazione ==== ,,20070216-1320 SoujaK,, [[BR]] 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,, [[BR]] 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,, [[BR]] 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 ''[wiki:Protocollo#AutenticazioneOpenSystem Open System]'', che permette autenticazione a qualsiasi STA, e l'autenticazione a chiave condivisa ([wiki:Protocollo#AutenticazioneSharedKey Shared Key]) unitamente all' [wiki:Protocollo#AlgoritmoWiredEquivalentPrivacyWEP 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,, [[BR]] 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,, [[BR]] 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,, [[BR]] 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, [wiki:Protocollo#AlgoritmoWiredEquivalentPrivacyWEP 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,, [[BR]] 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,,[[BR]] 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,,[[BR]] 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 [wiki:Protocollo#CoordinamentodistribuitoDCF coordinamento distribuito] (piu' brevemente DCF), un componente evidentemente necessario ad ogni stazione, in qualsiasi modalita' essa operi, ''infrastracture'' come ''ad-hoc''. [[BR]] E' inoltre presente un metodo di accesso opzionale, basato sulla funzione di [wiki:Protocollo#CoordinamentocentralizzatoPCF 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. ,,gnappo: ''non e' chiara dove sia la concorrenza tra PCF e DCF. Probabilmente ci si puo' limitare a parlare di coesistenza.'',, ==== Coordinamento distribuito (DCF) ==== ===== CSMA/CA e il meccanismo RTS/CTS ===== ,,20061027-1950 SoujaK,,[[BR]] 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,,[[BR]] 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 [wiki:Protocollo#Acknowledgment acknowledgment] e l'attesa dei vari [wiki:Protocollo#InterframespaceIFSspaceIFS 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 e CTS > che nelle successive coppie < PDU e ACK > diverse dalla prima; esso contiene la distanza temporale al termine della comunicazione, i.e. il primo acknowledgment. ===== Acknowledgment ===== ,,20061027-0445 SoujaK,,[[BR]] 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,,[[BR]] 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,,[[BR]] 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.[[BR]] 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,,[[BR]] 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 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,,[[BR]] 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 [###todolink] 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''.[[BR]] 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 [###todolink]. ===== Struttura e tempistiche con PCF ===== ,,20061210-1817 SoujaK,,[[BR]] 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 [###todolink?]. 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 [###todolink]) 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,,[[BR]] 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,,[[BR]] 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,,[[BR]] 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 ===== ###todosection == 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 medium a PHY service), 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 [http://www.xt3.it/reti0506/MIB-D6.2.txt 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 PHY entity; * CHARACTERISTICS.confirm: viene sollevata dalla PHY entity successivamente ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative della PHY entity; * DSSSTESTMODE.request: utile per entrare in modalita' test in una PHY DSSS entity; * DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una PHY DSSS entity. === 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,,[[BR]] 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,, [[BR]] 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. [[BR]] 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. [[BR]] 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. [[BR]] 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. [[BR]] 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''. [[BR]] Alcune informazioni sulle tempistiche riguardanti i canali: * 224''u''s 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,, [[BR]] 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,, [[BR]] 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. [[BR]] 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,, [[BR]] 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,, [[BR]] 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 la primitiva PHY-RXEND.indicate(NoError) sara' sollevata. 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,, [[BR]] 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. [[BR]] Il ricevitore, utilizzando la stessa ''chip sequence'', sara' in grado di ricostruire il segnale originale. [[BR]] 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,, [[BR]] 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. [[BR]] Le sostanziali differenze con il suo predecessore sono molteplici: 1. si sono riuniti i [http://en.wikipedia.org/wiki/Chip_rate "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. [[BR]] 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'. [[BR]] 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.[[BR]] 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.[[BR]] 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,, [[BR]] 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,, [[BR]] 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,, [[BR]] 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,, [[BR]] 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. [[BR]] 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,, [[BR]] 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,, [[BR]] Come gia' affermato in precedenza, questo campo contiene l'effettivo ''data-load''. === FCS === ,,20061111-1735 gnappo,, [[BR]] 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,, [[BR]] 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. [[BR]] 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);[[BR]] ,,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 2^64^ 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,,[[BR]] 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. [[BR]],,20061109-1424 SoujaK: ''Il pezzo seguente e' da chiarire'',,[[BR]] 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,,[[BR]] 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. [[BR]],,SoujaK: ''a quanto ne so, MIB denota l'insieme di attributi di un sottolivello e non il nome di questo specifico attributo'',,[[BR]] 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 prametri neccesari. * prima di spedire il secondo frame la stazione rispondente utilizza WEP per generare una stringa di ottetti che sono utilizzati come ''challenge''. [[BR]],,SoujaK: ''il concetto di ''challenge'' non e' spiegato'',, [[BR]] * 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,,[[BR]] 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 prefige 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 qunato e' implementabile sia via hardware che via software * esportabilita' * opzionabilita' in quanto WEP e' un' opzione di 802.11. === Come funziona WEP === ,,20061117-0955 roma,,[[BR]] 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 dei 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,,[[BR]] 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).