IEEE 802.11 - 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 [IEEE802.11/DefinizioneDeiServiziMAC#Acknowledgment 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 trasmissivo

_{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 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