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 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.
E' inoltre presente un metodo di accesso opzionale, basato sulla funzione di 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 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}
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 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 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 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 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 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 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 framenel 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).
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 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 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 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 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.