Changes between Initial Version and Version 1 of IEEE802.11/DefinizioneDeiServiziMAC

Timestamp:

Feb 17, 2007, 5:40:07 PM (18 years ago)

Author:

soujak

Comment:

--

IEEE802.11/DefinizioneDeiServiziMAC

@@ +1 @@
+[[PageOutline(1-6)]]
+= IEEE 802.11 - 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:IEEE802.11/DefinizioneDeiServiziMAC#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:IEEE802.11/DefinizioneDeiServiziMAC#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.
+
+=== 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 ''[IEEE802.11/DefinizioneDeiServiziMAC#Acknowledgment acknowledgment]'' e
+l'attesa dei vari
+[wiki:IEEE802.11/DefinizioneDeiServiziMAC#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 , 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,,[[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 <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,,[[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 [wiki:CollegamentoMancante 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''.[[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 [wiki:CollegamentoMancante PIFS].
+
+==== 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 [wiki:CollegamentoMancante 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 [wiki:CollegamentoMancante 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,,[[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 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__