[[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__