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:
- 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;
- PIFS (PCF interframe space): usato solo dalle STA che, sotto un PCF, tentano di avere accesso al mezzo trasmissivo all'inizio del CFP;
- DIFS (DCF interframe space): usato sotto DCF dalle STA per i frame dati (MPDU) o per i frame di gestione (MMPDU);
- 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
