[[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 che nelle successive coppie ; 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 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`.