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

Timestamp:

Mar 24, 2007, 8:59:34 PM (18 years ago)

Author:

soujak

Comment:

Creazione della nuova pagina.

IEEE802.11/FunzionamentoDiMAC

@@ +1 @@
+[[PageOutline(1-6)]]
+
+= Funzionamento di MAC =
+
+== Coordinamento per la trasmissione ==
+
+L'accesso al mezzo di trasmissione comune dev'essere in qualche modo regolato,
+evitando trasmissioni simultanee che interferirebbero vicendevolmente. Per
+questo motivo il livello MAC comprende funzionalita' che gestiscono la
+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), una componente evidentemente
+necessaria ad ogni stazione, in qualsiasi modalita' essa operi,
+''infrastracture'' in un BSS, o ''ad-hoc'' in un IBSS.[[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 appunto 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 fra periodi
+in cui l'accesso e' prestabilito dal PC e il mezzo libero dalla contesa
+(''Contention-Free Period'' o CFP), e periodi di contesa del mezzo (''Contention
+Period'' o CP), in cui il coordinamento e' distribuito.
+
+=== Coordinamento distribuito (DCF) ===
+
+==== CSMA/CA e il meccanismo RTS/CTS ====
+
+Il concetto chiave attraverso il quale il protocollo interpreta il meccanismo di
+comunicazione di tipo CSMA/CA (''carrier sense multiple access with collision
+avoidance'') 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 indica la durata temporale nella quale il mezzo sara' impegnato per l'invio
+del frame (o del frammento) e per la successiva ricezione dell'ACK.
+
+Le STA esterne alla comunicazione apprendono, tramite questo meccanismo, che il
+canale e' occupato per quel lasso di tempo, evitando cosi' ogni collisione. La
+doppia presenza delle informazioni in questione, in entrambe le direzioni
+della comunicazione (sia nei frame RTS che in CTS, ad esempio), permette di
+raggiungere tutte le STA interessate, scongiurando alcuni problemi di
+visibilita' (come quello del nodo esposto).
+
+E' importante precisare che il meccanismo RTS/CTS va evitato per trasmissioni
+''multicast'' o ''broadcast'' (chi risponderebbe, infatti, con il corrispondente
+CTS?). Puo' inoltre essere evitato anche nel caso di frame di dimensioni
+ridotte (al fine di limitare l' ''overhead'' introdotto): la soglia e' definita
+nell'attributo MAC denominato `dot11RTSThreshold`.
+
+==== ''Carrier-sense'' virtuale e il NAV ====
+
+La funzionalita' di ''carrier-sense'' 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. In quest'ultimo caso, pero', il meccanismo e' da
+considerarsi virtuale, giacche', invece di analizzare direttamente mezzo,
+utilizza il vettore di allocazione della rete (''Network Allocation Vector'' o
+NAV).
+
+Ogni STA, pertanto, ha il compito di tenere traccia nel NAV delle "prenotazioni"
+altrui indicanti la futura indisponibilita' del mezzo in modo da posticipare
+opportunamente le proprie trasmissioni. Il calcolo del tempo di attesa
+corrisponde al tempo totale richiesto dalle trasmissioni annunciate dallo
+scambio RTS/CTS, cioe' la somma dei tempi necessari ad ognuna delle fasi della
+comunicazione : la trasmissione dei ''frame'' di dati e dei relativi ''
+[IEEE802.11/DefinizioneDeiServiziMAC#Acknowledgment acknowledgment]
+'' unitamente ai tempi degli
+[wiki:IEEE802.11/DefinizioneDeiServiziMAC#InterframespaceIFSspaceIFS IFS].
+
+Le informazioni in questione sono contentute proprio nel campo `Duration/ID` che
+si ricorda essere presente sia nella coppia iniziale <RTS, CTS> che nelle
+successive coppie <PDU, ACK>; tale campo contiene la distanza temporale dal
+termine della comunicazione, i.e. il primo ''acknowledgment''.
+
+Le citate informazioni necessarie alle stazioni estranee alla comunicazione sono
+prefissate dallo standard (come la durata di invio di un ACK o i tempi
+''inter-frame'') oppure scelte direttamente dalle stazioni interessate alla
+comunicazione.
+
+==== ''Acknowledgment'' ====
+
+La strategia usata per la notifica di ricezione e' l' ''acknowledgment''
+positivo, il che significa che la STA ricevente ha il compito di confermare alla
+STA trasmittente la corretta ricezione del frame (fatte le dovute eccezioni per
+i ''frame'' non ''unicast'').
+
+Il trasmittente attende il ''frame'' ACK per un periodo di tempo, fissato nel
+parametro `ACKTimeout`, allo scadere del quale conclude che la trasmissione e'
+fallita. Lo stesso esito si ha quando il trasmittente in attesa di ACK riceva
+qualcosa di inaspettato. In questi casi il trasmittente provvedera' alla
+ritrasmissione del ''frame'' secondo le procedure di accesso al mezzo stabilite
+dal protocollo. Si noti che la mancata ricezione dell'ACK puo'
+indistinguibilmente indicare non solo errori legate alla trasmissione dei dati,
+ma anche  nello stesso ''acknowledgment''.
+
+==== ''Interframe space'' (IFS) ====
+
+Lo standard stabilisce diversi tempi di attesa da rispettare dopo le
+trasmissioni, quindi le stazioni dovranno procrastinare le proprie trasmissioni
+per un periodo di tempo legato al tipo di ''frame'' da inviare. Il meccanismo
+''carrier-sense'' virtuale stabilira' quindi che il mezzo trasmissivo e' da
+considerarsi libero solo dopo tali attese.
+
+La differenziazione dei 4 differenti IFS consente di stabilire le priorita' fra
+tipologie di ''frame'':
+ 1. SIFS (''short interframe space''):
+    usato per ''frame'' ACK, CTS, ''frame'' di una trasmissione frammentata
+    (eccetto il primo) e per le risposte al ''polling'' del PCF;
+ 2. PIFS (PCF ''interframe space''):
+    usato solo dai PC in regime di PCF, in modo da assicurarsi l'accesso al
+    mezzo trasmissivo all'inizio del CFP da loro regolato;
+ 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]]
+Come spiegato precedentemente, ogni STA che intenda trasmettere un qualche
+messaggio e' anzitutto tenuta ad aspettare che il mezzo trasmissivo risulti
+libero (attraverso il meccanismo di ''
+[wiki:CollegamentoMancante carrier-sense]
+'' virtuale). A quel punto, pero', tutte le stazioni in attesa dovranno
+ritardare ulteriormente la propria trasmissione per un periodo detto di
+''backoff''. La durata di questo periodo e' espressa come un numero casuale di
+quanti di tempo (dal valore `aSlotTime` presente in PHY). L'intero
+pseudo-casuale e' tenuto ad essere uniformemente distribuito fra 0 e CW, un
+altro parametro definito come intero compreso nell'intervallo di estremi
+`CWmin` e `CWmax`(definiti in PHY).
+
+Il periodo di ''backoff'' denota quindi il tempo per il quale e' fatto obbligo
+ad ogni STA di posticipare le trasmissioni, nonostante ne abbia opportunita'.
+Cosi' facendo, la stazione che ha "estratto" il valore del tempo di attesa
+minimo sara' quella che si aggiudichera' l'accesso al canale. Quando esso
+risultera' nuovamente libero, le stazioni ancora in attesa non dovranno
+ricalcolare un nuovo ''backoff'', ma utilizzeranno il tempo di posticipo
+rimanente.
+
+La scelta della durata del ''backoff'' possiede, pertanto, componenti casuali al
+fine di minimizzare le collisioni tra le varie STA in attesa di trasmissioni in
+quel dato istante. Ogni qual volta che una STA riesca a portare a termine con
+successo una trasmissione, la sua CW viene ripristinata al valore minimo, cioe'
+`CWmin`.
+
+La CW (''contention window'') rappresenta concettualmente il periodo di contesa
+del mezzo, nel quale ogni STA tenta di cominciare le proprie comunicazioni. La
+durata della CW viene inoltre aumentata con andamento esponenziale a fronte di
+ogni collisione, al fine di ridurre progressivamente le probabilita' di questi
+eventi. Un cosi' alto andamento di crescita della lunghezza della ''contention
+window'' rende piu' flessibili e scalabili le procedure di accesso al mezzo,
+aumentando la sua capacita' di adeguarsi repentinamente a condizioni di alto
+carico.
+
+==== Frame duplicati ====
+
+Poiche' MAC include procedure di conferma di trasmissione (ACK) e procedure di
+ritrasmissione in caso di fallimenti, esiste la possibilita' che un determinato
+''frame'' venga ricevuto piu' di una volta. La stazione ricevente deve rendersi
+conto di tale duplicazione e scartare i successivi doppioni. A tal fine e' stato
+inserito un campo di controllo di sequenza all'interno dei ''frame'' dati e in
+quelli di gestione, entrambi contenenti un numero identificativo. Ogni STA
+mantiene dunque un registro delle triple <indirizzo, numero di sequenza,
+numero di frammento> che permette di identificare agilmente i ''frame''
+duplicati. Il numero di sequenza e' un numero naturale progressivo che mira ad
+essere unico fra i vari ''frame'': qualora capitasse il contrario, il ''frame''
+valido erroneamente scartato verrebbe comunque ritrasmesso dalla sorgente. Va
+precisato che la stazione destinataria di un ''frame'' duplicato, sebbene eviti
+di inoltrarlo al livello LLC, e' comunque tenuta a notificarne la ricezione con
+il relativo ACK.
+
+=== Coordinamento centralizzato (PCF) ===
+
+La PCF fornisce un metodo accesso al mezzo trasmissivo che e' libero dalla
+contesa (e quindi anche dagli sprechi di tempo che essa comporta), grazie alle
+regole imposte da un coordinatore centrale (''point coordinator'' o 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. Il coordinatore e' in grado di
+discriminare tali stazioni inviando un ''frame'' `CF-poll` al quale
+risponderanno soltanto le stazioni che supportano PCF.
+
+Inoltre, il gia' menzionato `CF-poll` e' la chiave di volta su cui questa
+modalita' di coordinamento si fonda, poiche' tutte le trasmissioni sono
+veicolate tramite questo meccanismo. Le stazioni ''CF-pollable'' hanno infatti
+occasione di spedire, tramite strategia di ''piggyback'', una (e una sola)
+MPDU assieme all' ''acknowledgment'' del ''poll'' ricevuto.
+
+Se l'invio della MPDU 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] o al successivo turno di ''polling''
+della medesima STA.
+
+==== Struttura e tempistiche con PCF ====
+
+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 in maniera distribuita (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;
+va infatti 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 ====
+
+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 lo standard definisce minuziosamente le sequenze di ''frame''
+concatenabili tramite ''piggyback''.
+
+===== Accesso di base al mezzo =====
+
+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
+[wiki:CollegamentoMancante piu' avanti]. Le STA riceventi che non siano di tipo
+''CF-Pollable'' segnaleranno il successo della ricezione con il ''frame'' ACK,
+piuttosto che con il ''CF-ACK'' eventualmente aggregato.
+
+===== Uso del NAV =====
+
+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' tenuta a pre-impostare il proprio
+NAV, essendo a conoscenza sia della frequenza dei CFP, dettata dal TBTT
+(''target beacon trasmission time''), sia della durata, grazie al 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 sempre 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 ====
+
+La trasmissione dei ''frame'' sotto regime di coordinamento centralizzato
+consiste di trasmissioni provenienti dal coordinatore centrale alternate a
+trasmissioni destinate al medesimo coordinatore. Il coordinatore (i.e. l'AP)
+ha modo di controllare l'ordine delle trasmissioni durante il CFP, poiche' esso
+controlla le varie STA alle quali e' permesso trasmettere in un dato momento.
+
+===== Trasferimenti da e verso il PC =====
+
+Il PC trasmette i propri ''frame''nel tempo che intercorre fra il ''beacon''
+all'inizio del CFP e il ''frame'' `CF-End`, attendendo ogni volta per un SIFS. 
+Fa eccezione il caso in cui il PC aspetti invano un ''frame'' da una STA,
+poiche' il coordinatore prolunghera' l'attesa fino ad un PIFS, per poi
+continuare con la successiva trasmissione. Il che permette al PC di mantenere il
+controllo del mezzo anche quando e' condiviso da piu' BSS sovrapposti.
+
+Segue un elenco dei tipi di ''frame'' che un PC puo' spedire alle STA, assieme
+ad una sommaria spiegazione dei casi d'uso.
+ * '''Dati'''
+   Spedizione di dati dal PC quando la STA destinataria non viene interrogata
+   e non ci sono ''frame'' precedenti da confermare tramite ACK.
+ * '''Dati + CF-ACK'''
+   Spedizione di dati dal PC quando la STA destinataria non viene interrogata
+   e il PC necessita di confermare un precedente ''frame'' ricevuto da una
+   stazione ''CF-pollable'' un SIFS prima dell'inizio di questa trasmissione.
+ * '''Dati + CF-poll'''
+   Spedizione di dati dal PC quando la STA destinataria e' la prossima stazione
+   a cui si permette di trasmettere durante il CFP e non ci sono ''frame''
+   precedenti da confermare tramite ACK.
+ * '''Dati + CF-ACK + CF-poll'''
+   Spedizione di dati dal PC quando la STA destinataria e' la prossima stazione
+   a cui si permette di trasmettere durante il CFP e il PC necessita di
+   confermare un precedente ''frame'' ricevuto da una stazione ''CF-pollable''
+   un SIFS prima dell'inizio di questa trasmissione.
+ * '''CF-poll'''
+   Nessuna spedizione di dati da parte del PC ma la STA destinataria e' la
+   prossima stazione a cui si permette di trasmettere durante il CFP e non ci
+   sono ''frame'' precedenti da confermare tramite ACK.
+ * '''CF-ACK + CF-poll'''
+   Nessuna spedizione di dati da parte del PC ma la STA destinataria e' la
+   prossima stazione a cui si permette di trasmettere durante il CFP e il PC
+   necessita di confermare un precedente ''frame'' ricevuto da una stazione
+   ''CF-pollable'' un SIFS prima dell'inizio di questa trasmissione.
+ * '''CF-ACK '''
+   Nessuna spedizione di dati o interrogazione da parte del PC ma esso
+   necessita di confermare un precedente ''frame'' ricevuto da una stazione
+   ''CF-pollable'' un SIFS prima dell'inizio di questa trasmissione (utile
+   quando la prossima trasmissione e' un ''frame'' di gestione.
+ * '''''Frame di gestione'''''
+
+Ogni volta che una STA ''CF-Pollable'' riceve un ''frame'' a lei diretto avra'
+la possibilita' di inviare un ''frame'' dati dopo l'eventuale ''poll'' del PC.
+Le trasmissioni effettuate dalle STA in risposta ai ''poll'' non devono seguire
+le regole di allocazione del mezzo settando il NAV: in quel caso il vettore
+andra' ignorato (non azzerato).[[BR]]
+Le stazioni che invece non sono ''CF-Pollable'' che ricevono ''frame'' dall'AP
+durante il CFP rispondono tramite il consueto ''frame'' ACK (senza resettare il
+proprio NAV).
+
+Una stazione di tipo ''CF-Pollable'' e' tenuta a rispondere sempre ai ''poll''
+ricevuti dal PC, anche quando non ha dati in attesa di essere trasmessi; in tal
+caso inviera' un ''Null frame'' o, qualora abbia appena ricevuto una
+trasmissione dal PC, un semplice frame ''CF-ACK''.
+
+===== Sovrapposizione di BSS =====
+
+Poiche' la funzionalita' di coordinamento centralizzato funziona senza le
+finestre di contesa imposte dal meccanismo [wiki:CollegamentoMancante CSMA/CA],
+ogni PC assumera' di avere uso esclusivo del WM. Sussiste pertanto il rischio di
+collisioni ripetute qualora sul medesimo canale fisico si sovrapponessero piu'
+BSS ad infrastruttura, specialmente se con caratteristiche simili (intervallo
+dei ''beacon'' e tasso dei CFP). Per minimizzare la perdita di ''frame'',
+quindi, ogni PC e' tenuto ad osservare un ritardo, prima di iniziare il proprio
+CFP, piu' lungo di un periodo DIFS, aggiungendo un ''backoff'' pseudo-casuale.
+Questo ''backoff'' puo' essere usato, volendo, anche prima delle ritrasmissioni
+di ''frame'' persi.
+
+In caso di sovrapposizione di BSS a carico particolarmente alto, e' possibile
+sfruttare un ulteriore mecccanismo di protezione dalle collisioni, utilizzando
+il parametro `aMediumOccupancyLimit` che permette di autolimitare i tempi di
+uso continuativo del canale di una singola STA, come forma di galateo del
+mezzo trasmissivo.
+
+===== Il limite `CFPMaxDuration` =====
+
+Questo limite dovrebbe essere impostato in modo tale da permettere la
+coesistenza di traffico in regime CFP e CP. Lo standard impone un valore minimo
+e un valore massimo tali da permettere almeno uno scambio di ''frame'' in ognuno
+dei due periodi.
+
+===== Regole d'uso dei CFP =====
+
+Quando una STA ''pollable'' riceve un ''poll'' dal coordinatore centrale, essa
+ha l'occasione di spedire un ''frame'' di dati ad una destinazione qualsiasi;
+tale ''frame'' sara' comunque diretto a al PC, anche se non e' indirizzato ad
+esso. Quest'ultimo dovra' confermare la ricezione, dopo aver atteso per un SIFS,
+tramite un CF-ACK. Una STA che non abbia dati da inviare, rispondera' al ''poll'
+' con un ''frame Null'', dopo un periodo SIFS. Qualora, invece, la STA non abbia
+abbastanza tempo per l'invio di tutti i dati in attesa, rispondera' settando il
+bit "dati in attesa" (''more data''), per permettere al PC di distinguere le STA
+senza dati in attesa dalle STA che non hanno tempo a sufficienza.
+
+===== Lista di ''polling'' =====
+
+Come accennato precedentemente, i PC che supportano l'uso del CFP mantengono
+una lista di ''polling'' da usare durante la selezione delle STA che
+dovranno ricevere il ''CF-poll'' durante i periodi liberi da contesa.
+
+La lista di ''polling'' e' un costrutto logico interno all'AP, utilizzato per
+permettergli di interrogare ogni STA, a prescindere dalla presenza di dati a
+loro indirizzati. Lo standard impone che sia implementata una qualche tecnica
+elementare di gestione di questa lista, lasciando quindi la possibilita' di
+implementazioni piu' avanzate.
+
+Qualora un PC supporti l'uso del CFP per soli ''frame'' in uscita, esso non
+avra' bisogno delle liste di ''polling'' e non dovra' nemmeno generare ''frame''
+contenenti ''CF-poll''. In generale, le informazioni che descrivono la modalita'
+di supporto al CF da parte del PC sono comunicate attraverso il campo
+`Capability Information` presente nei ''beacon'' e nei ''frame'' di gestione
+inviati dall'AP.
+
+====== Processamento della lista di ''polling'' ======
+
+Durante il CFP il PC dovrebbe inviare un ''CF-Poll'' ad un sottoinsieme delle
+STA presenti in lista, in ordine crescente di AID, ma e' tenuto ad inviarne
+almeno uno ad almeno una STA. Se tutte le STA sono state interrogate e il CFP
+non e' ancora terminato, il PC puo' sfruttare il tempo a disposizione per
+l'invio di ''frame'' (di dati o di gestione) a qualunque STA. La strategia
+''piggyback'' applicata agli ''acknowledgment'' permette di incrementare
+notevolmente l'efficenza, quindi lo standard ne incoraggia l'uso.
+
+====== Aggiornamento della lista di ''polling'' ======
+
+Una STA ha modo di indicare la sua capacita' di rispondere alle interrogazioni
+dei ''CF-poll'' tramite il sottocampo `CF-pollable` presente nel campo
+`Capability Information`, all'interno dei ''frame'' di richiesta di associazione
+e riassociazione.
+
+Nel caso in cui una STA ''CF-pollable'' non desideri essere inserita nella lista
+di ''polling'', dovra' settare il sottocampo `CF-pollable` falso e quello
+`CF-poll request` vero. Questo potrebbe essere utile per permettere ad una STA
+in modalita' ''power save'' di sfruttare il tempo a sua disposizione solo per la
+ricezione di ''burst'' di dati: svegliandosi solo durante il CFP ha infatti la
+possibilita' di ricevere tutta in una volta la mole di dati bufferizzata dal PC.
+La richiesta di riassociazione puo' essere usata per comunicare all'AP i
+cambiamenti di volonta' in merito all'inserimento nella lista di ''polling''.
+
+=== Frammentazione ===
+
+Il livello MAC puo' decidere di frammentare (risp. riassemblare) MSDU o MMPDU a
+lui diretti dai livelli inferiori (superiori) e dispone di meccanismi appositi
+per gestire efficientemente la ritrasmissione dei frammenti.
+
+La lunghezza (i.e. il numero di ottetti) dei vari frammenti MPDU dovrebbe essere
+uguale, eccezion fatta per l'ultimo, eventualmente piu' piccolo. Inoltre i
+frammenti, devono sempre essere formati da un numero pari di ottetti, ancora una
+volta escludendo l'ultimo che puo' anche essere dispari. La specifica politica
+di divisione in frammenti e' lasciata alla discrezione dell'implementatore.
+
+MAC offre inoltre la possibilita' di impostare la soglia oltre la quale la MSDU
+o la MMPDU da spedire deve essere frammentata, in modo tale da poter bilanciare
+l' ''overhead'' dovuto alla frammentazione con i benefici che ne derivano. Tale
+parametro, denominato `aFragmentationThreshold`, e' presente nel MIB.
+
+Particolare attenzione deve essere rivolta alla frammentazione in congiunzione
+con il servizio
+[wiki:IEEE802.11/AutenticazioneEPrivacy#FunzionamentodiWEP WEP],
+poiche' esso viene applicato ai dati gia' frammentati, espandendo la
+lunghezza dell'MPDU con l'aggiunta di due sottocampi nel corpo del ''frame'':
+l' ''IV'' e l' ''ICV''.
+
+Una volta trasmesso il frammento per la prima volta, la lunghezza del suo corpo
+deve rimanere tale durante tutto il tempo di vita (lungo il tragitto di
+consegna), ed e' quindi vietata ogni manipolazione da parte delle STA
+intermedie, anche quando esse potrebbero portare dei vantaggi (accesso al
+mezzo).
+
+Come accennato nella sezione dedicata alla gestione dei
+[wiki:IEEE802.11/FunzionamentoDiMAC#Frameduplicati frame duplicati], ogni
+''frame'' contiene un numero identificativo della MSDU o della MMPDU, presente
+nel campo di controllo della sequenza (''sequence number''). I frammenti
+appartenenti alla medesima unita' di dati contengono lo stesso numero di
+sequenza, ma sono distinguibili tramite un numero naturale progressivo del
+frammento (''fragment number''). I frammenti vengono inviati in ordine crescente
+rispetto al loro numero identificativo ed ognuno di essi (eccettuato l'ultimo)
+ha il [wiki:IEEE802.11/FormatoDeiFrameMAC#Framecontrol campo] "ulteriori
+frammenti" (''more fragments'') asserito.
+
+La STA sorgente deve mantenere un timer di trasmissione di MSDU, per ogni
+MSDU trasmessa. L'attributo `aMaxTrasmitMSDULifetime` specifica il tempo
+massimo concesso per trasmettere una MSDU. Il timer parte con il primo tentativo
+di trasmissione del primo frammento. Se il timer supera
+''aMaxTrasmitMSDULifetime'', tutti i restanti frammenti saranno scartati dalla
+STA sorgente e non ci saranno tentativi di completare la trasmissione.
+
+=== Riassemblaggio ===
+
+Come e' stato appena descritto, ogni frammento contiene, all'interno
+dell'intestazione del ''frame'', le informazioni necessarie al riassemblaggio
+dei frammenti dell'MSDU o dell'MMPDU. La STA destinazione ricostruisce quindi
+l'MSDU combinando i frammenti in ordine di ''fragment number''. Il bit ''more
+fragments'' presente nei singoli frammenti indica alla stazione destinataria che
+l'MSDU frammentata non e' stata ancora ricevuta nella sua completezza. Appena la
+STA riceve il frammento con tale bit impostato a zero, capisce che non ci sono
+piu' frammenti da ricevere.
+
+Come e' facile intuire, il riassemblaggio di dati cifrati puo' avvenire solo
+dopo che sono stati decifrati.
+
+Tutte le STA devono poter gestire almeno tre MSDU concorrenti, nella fase di
+ricezione e in quella di riassemblaggio (nel caso il ricevente sia il
+destinatario) o di inoltro (nel caso di STA intermedie). Si tenga presente che
+la gestione contemporanea di piu' di tre sequenze di frammenti potrebbe
+comportare un aumento del carico del ricevente e, quindi, un notevole aumento
+anche dei tempi di trasmissione delle MSDU.
+
+La scadenza del timer di trasmissione di una MSDU comporta infatti la
+ritrasmissione dell'intera sequenza in cui essa e' scomposta. La STA
+destinazione deve mantenere a sua volta un timer di ricezione per ogni MSDU in
+arrivo; la trasmissione di ogni frammento ricevuto dopo la scadenza del timer
+(`aMaxReceiveLifetime`) deve essere confermato tramite ACK, nonostante il
+''frame'' venga scartato.
+
+=== Supporto al ''multi-rate'' ===
+
+Alcuni entita' fisiche consentono l'uso di differenti velocita' di trasferimento
+dei dati e implementano anche adeguati meccanismi che ne gestiscano il cambio
+dinamico. L'obiettivo e' quello usare una velocita' trasmissiva adeguata alla
+qualita' del segnale, giacche' poche trasmissioni a bassa velocita' potrebbero
+richiedere meno tempo rispetto a numerosi tentativi effettuati alla massima
+velocita'.
+
+L'algoritmo di scelta del ''data-rate'', va oltre gli scopi dello
+standard, ma per garantire coesistenza e interoperabilita' fra livelli PHY
+''multi-rate'' lo standard definisce l'insieme di regole precise riportato di
+seguito.
+
+ * Tutti i frame di controllo devono essere trasmessi ad una delle velocita'
+   obbligatorie del BSS (fissate nel parametro `BSSBasicRateSet`), o ad una
+   delle velocita' rese disponibili dallo specifico PHY, sempre compatibilmente
+   con l'insieme delle STA destinatarie.
+ * Tutti i ''frame'' ''broadcast'' e ''multicast'' devono essere trasmessi ad
+   una delle velocita' presenti nell'insieme `BSSBasicRateSet`.
+ * Gli MPDU dati o di gestione con un'indirizzo ''unicast'' devono essere
+   mandati ad una delle velocita' supportate, eventualmente quella selezionata
+   dall'algoritmo di cambio dinamico di velocita'. Il ''data-rate''
+   effettivamente utilizzato e' disponibile, espresso in unita' di 500 Kb/s, nel
+   parametro `MACCurrentRate`, e concorre al calcolo del campo ''duration'' dei
+   ''frame''.
+ * In nessuna circostanza una STA deve trasmettere ad una velocita' piu' alta
+   del massimo dichiarato durante la fase di sincronizzazione con il BSS,
+   tramite il parametro `OperationalRateSet` della primitiva
+   `MLME-JOIN.request`.