Analisi dello standard IEEE 802.11

Descrizione funzionale del sottolivello MAC

Sommario degli argomenti presenti:

• DCF
• PCF
• Frammentazione
• Deframmentazione
• Supporto ad ampiezze di banda multiple
• Sequenze consentite per lo scambio di frame
• Restrizioni aggiuntive per limitare il riordino o lo scarto di MSDU

Coordinamento per la trasmissione

_{20061018-1512 SoujaK}
L'accesso al mezzo di trasmissione comune e' regolato da una strategia che e' detta CSMA/CA (i.e. carrier sense multiple access with collision avoidance) che intende minimizzare le probabilita' di collisione.

La funzionalita' di coordinamento distribuito (Distributed Coordination Function o, piu' brevemente, DCF) che si fa carico della cosa e' pertanto componente necessario di ogni stazione, sia che essa operi all'interno di reti configurate in modalita' infrastracture che ad-hoc. E' inoltre presente un metodo di accesso opzionale che si basa su un coordinatore centrale detto PC (i.e. Point Coordinator) che risiede nell'AP del BSS. Poiche' DCF e PCF devono poter coesistere ed operare in maniera concorrente all'interno di una BSS, i due metodi di accesso si alterneranno, con un periodo in cui l'accesso e' prestabilito e il mezzo libero dalla contesa (Contention-Free Period o CFP) seguito da un periodo di contesa (Contention Period o CP).

DCF

CSMA/CA e il meccanismo RTS/CTS

_{20061018-2031 SoujaK}
Il concetto chiave su cui si basa il protocollo di comunicazione CSMA/CA e' la distribuzione di informazioni di prenotazione del mezzo trasmissivo. I noti frame RTS e CTS contengono infatti 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, anche le STA sono all'interno del raggio d'azione del ricevente, ma non del trasmittente (problema 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 dot11RTSThreshold.

Carrier-sense virtuale e il NAV

_{20061027-0416 SoujaK}
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 acknoledgment e l'attesa dei vari 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 e CTS > che nelle successive coppie < PDU e ACK > diverse dalla prima; esso contiene la distanza temporale al termine della comunicazione, i.e. il primo acknoledgment.

Acknoledgment

_{20061027-0445 SoujaK}
La strategia usata e' l'acknoledgment 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 acknoledgment.

Interframe space (IFS)

_{20061019-0849 SoujaK}
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 corettamente e che il campo FCS non e' utilizzabile;

Random backoff time

_{20061025-1233 SoujaK}
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.
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 pseudocasuale le cui variazioni devono osclillare 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}
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, contentente il numero della sequenza e quello del frammento. Ogni STA mantiene dunque una cache delle tuple <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.

PCF

_{SoujaK: da fare :(}

Gestione degli strati

I due livelli (data link e fisico) su cui lo standard e' definito possiedono un insieme di operazioni primitive proprie, ma le loro definizioni sono lungi dal poter essere considerate vere e proprie interfacce: si tratta delle "MAC layer management entities" (MLME) e delle "PHY layer management entities" (PLME). E' assai importante notare, specialmente ai fini dello studio in oggetto, che lo strato MAC non oscura il sottostante PHY, ma permette alla "station management entity" (SME) di interagire direttamente con esso. Le varie entita' hanno la possibilita' di comunicare fra loro secondo le specifiche dello standard, attraverso i SAP (service access point). Tale concetto intende aggregare l'insieme di chiamate che una determinata entita' espone alle altre per realizzare forme di comunicazione o invocazione.

_{20061104-1752 gnappo:} direi che il seguente paragrafo riquadrato e' totalmente fuori posto.

Il periodo di inattivita' che le STA si autoimpongono 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.

  __||________________________
 |      |      |              |
 | MAC  | MLME =              |
 |      |      |              |
 |--||--|--||--| Station      |
 |      |      | Managemement |
 | PLPC | PLME | Entity       |
 |      |      |              |
 |--||--|      =              |
 |      |      |              |
 | PMD  |      |              |
 |______|______|______________|

In generale il livello MAC, come ovvio, deve essere il piu' possibile indipendente da quello fisico anche se a volte e' necessario che il livello MAC gestisca stati opportuni del livello fisico.

Il livello PHY viene suddiviso nella seguente maniera:

• PLCP (Physical Layer Convergence Procedure): funzioni di convergenza del livello fisico (adattamento del medium a PHY service), che realizzano una traduzione al fine di rendere l'interfaccia comune;
• PMD (Physical Medium Dependent): insieme di funzioni fortemente dipendenti dallo specifico dispositivo wireless (ad esempio richieste di trasmissione o ricezione di dati).

Anche in questo caso le relazioni con l'esterno sono gestite da appositi moduli SAP: uno specifico per la porzione PLCP (PLCP-SAP) e un altro relativo al sottostrato PMD (PMD-SAP).

Primitive di gestione generica

Le informazioni specifiche per la gestione di ogni strato sono incapsulate all'interno di cio' che viene definita Management Information Base (MIB) che puo' essere visto come un componente di ogni livello. In accordo con questo, ogni Management Entity possiede specifiche primitive di GET e SET in grado di operare sugli attributi della relativa MIB. Informazioni dettagliate sugli attributi dei vari MIB sono presenti nel ​documento ufficiale

Interfaccia di MAC: MLME SAP

• POWERMGT: richieste al modulo che gestisce il risparmio energetico
• SCAN: scansione della rete alla ricerca di BSS disponibili
• JOIN: sincronizzazione con un BSS
• AUTHENTICATE: autenticazione con un BSS
• DEAUTHENTICATE: deautenticazione con un BSS
• ASSOCIATE: associazione fra una STA e un AP
• REASSOCIATE: associazione fra una STA e un altro AP
• DEASSOCIATE: disassociazione fra una STA e un AP
• RESET: azzeramento
• START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete ad-hoc)

_{20061019-0920 SoujaK:} La revisione g del documento non introduce nessun cambiamento alle interfacce del SAP legato al livello MAC. Viene piuttosto esteso il livello PHY al fine di supportare larghezze di banda maggiori e differenti modulazioni del segnale.

Interfaccia di PHY: PLME SAP

In generale si hanno disposizione tutti i getter e i setter necessari per manipolare tutti gli attributi del MIB (normati nell'aggiunta Annex D). Inoltre, si hanno a disposizione le seguenti primitive:

• RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato di ricezione;
• CHARACTERISTICS.request: ritorna le caratteristiche operative della PHY entity;
• CHARACTERISTICS.confirm: viene sollevata dalla PHY entity successivamente ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative della PHY entity;
• DSSSTESTMODE.request: utile per entrare in modalita' test in una PHY DSSS entity;
• DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una PHY DSSS entity.

Interfaccia di PHY: PHY SAP

Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire un meccanismo indipendente dalla PHY entity per trasferire MPDU fra le STA. Anche in questa sezione, i servizi vengono definiti in maniera puramente astratta, in modo da non forzare a particolari implementazioni delle interfacce.

Le primitive tra MAC e PHY si possono dividere in due categorie:

• primitive per il supporto d'interazioni punto-a-punto a livello MAC (primitiva PHY-DATA.{request, confirm, receive, indication}).
• primitive con significato locale per agevolare l'interazione tra sottolivelli (e.g. PHY-TXStart.{request,...}).

_gnappo: chiarire meglio tutte le primitive con il loro significato. Sara' utile nella comprensione delle specifiche del livello PHY (ad esempio DSSS).

Specifiche per il livello fisico

FHSS

_{20061104-1743 gnappo}
FHSS (Frequency Hopping Spread Spectrum) e' una specifica del livello PHY, presente nella prima versione dello standard. L'obiettivo primo da perseguire, come gia' chiarito nei paragrafi precedenti, e' l'indipendenza del livello MAC dal livello PHY. E' per questo motivo che, nel documento, vengono ratificate adeguate funzioni di convergenza al mezzo trasmissivo oltre alle usuali funzioni dipendenti dal medium.
La caratteristica saliente di questa specifica e' rappresentata dal fatto che la trasmissione non avviene sempre alla stessa frequenza (canale), ma si effettuano i cosiddetti hopping, cioe' dei salti di frequenza pseudo-casuali (ovviamente dettati da uno specifico algoritmo). In questo modo si massimizza il throughput della rete e si minimizzano le interferenze.
Per l'Europa, lo standard definisce il range delle frequenze operative da 2.400 GHz a 2.4835 GHz per un totale di 79 canali differenti.
I data-rate supportati sono:

• 1 Mbit/s: utilizzando la modulazione GFSK
• 2 Mbit/s: utilizzando la modulazione 4GFSK. L'header PLCP viene comunque trasmesso ad 1 Mbit/s.
  

E' importante sottolineare come la sequenza di salto dei canali sia in realta' dettata dal livello MAC: ogni beacon e ogni frame Probe Response contengono le informazioni necessarie per la sincronizzazione e per la determinazione del pattern di hopping.

OFDM

_{20061028-???? gnappo}
OFDM (Ortogonal Division Frequency Multiplexing) viene introdotto con la revisione a dello standard 802.11. I data-rate forniti sono: 6, 9, 12, 18, 24, 36, 48 e 54 Mbit/s. Solamente i 6, 12 e 24 Mbit/s sono, tuttavia, obbligatori. La banda di frequenze nella quale OFDM opera e' quella dei 5 GHz. Essenzialmente con OFDM si tentano di inviare piu' stream di bit in parallelo. Lo spettro delle frequenze viene suddiviso in piu' sottocanali, in ognuno dei quali viene impiegato uno schema di modulazione standard (e.g. fase) per la trasmissione. La scelta dei sottocanali e' operata in modo tale da eliminare interferenze tra gli stessi (sono ortogonali l'uno all'altro). Rimane, comunque, uno standard poco utilizzato sia a causa delle sue incompatibilita' (802.11b e 802.11g) sia per le caratteristiche operative (in molti paesi la banda dei 5Ghz e' tuttora riservata).

DSSS

_{20061021-???? gnappo}
DSSS (Direct Sequence Spread Spectrum) e' un'altra specifica del livello fisico che permette di raggiungere in linea teorica un capacita' trasmissiva pari a 11Mbit/s (802.11b). Attraverso opportune tecniche e' possibile fornire bitrate inferiori (in tal modo si ottiene compatibilita' all'indietro). Come descritto precedentemente, anche in questa occasione avremo opportune funzioni di convergenza atte a garantire l'indipendenza di MAC rispetto alla specifica implementazione di PHY.
Il PPDU e', naturalmente, differente rispetto a quello definito per FHSS (nel seguito troverete qualche dettaglio). Interessante osservare che il preambolo e l'header del frame sono trasmessi, diversamente dal resto, ad un 1Mbit/s per assicurarsi che l'interlocutore capisca effettivamente questa parte essenziale della comunicazione. L'effettivo invio del payload (MPDU) potra' essere compiuto con modulazioni diverse opportunamente specificate nell'header (campo SIGNAL).

Algoritmo di trasmissione

_{20061021-???? gnappo}
Per trasmettere i dati, PHY-TXSTART.request dev'essere abilitata per portare PHY nello stato di trasmettitore (precedentemente su ricevitore). Il canale su cui trasmettere e' regolato via PLME. Se il canale risulta libero (PHY-CCA.indicate) allora MAC puo' procedere all'effettivo invio invocando la primitiva PHY-TXSTART.request (PHY-SAP) passando i parametri necessari (DATARATE, TX_ANTENNA, TXPWR_LEVEL). Una volta terminato l'invio del preambolo, attraverso una serie di chiamate PHY-DATA.request(DATA) verrano scambiati i dati tra MAC e PHY. Al termine della trasmissione l'entita' fisica ritornera' allo stato di ricevitore.

Algoritmo di ricezione

_{20061021-???? gnappo}
Per quanto riguarda la ricezione e' necessario che l'entita' fisica sia nello stato di ricevitore (quindi PHY-TXSTART disabilitato). Attraverso la PLME e' possibile scegliere il canale su cui ascoltare ed il metodo di CCA (Clear Channel Assessment). Altri parametri (come per la trasmissione) sono passati attraverso PHY-SAP. Non appena il dispositivo ha rilevato attivita' sul canale sul quale e' in ascolto, PHY invoca la primitiva PHY-CCA.indicate con la quale informa MAC che il canale e' BUSY. Dopodiche' PHY va alla ricerca di un delimitatore di inizio frame e procede alla lettura dell'header. Se la lettura va a buon fine (i.e. formato riconosciuto, niente errori su CRC) allora viene chiamata la primitiva PHY-RXSTART.indicate per mettere a conoscenza di MAC di informazioni contenute nell'header (i.e. campo SIGNAL, lunghezza del MPDU, RX_ANTENNA, RSSI, SQ, campo SERVICE). I dati successivamente ricevuti saranno assemblati e presentati a MAC attraverso la primitiva PHY-DATA.indicate(DATA). Al termine dell'intera ricezione lo stato del ricevitore ritornera' IDLE e la primitiva PHY-RXEND.indicate(NoError) sara' sollevata. Se la ricezione non andasse a buon fine, PHY informerebbe MAC attraverso la primitiva PHY-RXEND.indicate della causa dell'errore (e.g. CarrierLost).

Note

Per quanto riguarda questioni di tempistiche ed altre informazioni dettagliate (MIB attributes) rimando alle specifiche ieee, capitolo 15.

HR/DSSS (802.11b/802.11g)

_{20061022-2130 Zeratul}
High Rate Direct Sequence Spread Spectrum (HR/DSSS) e' l'evoluzione della "semplice" DSSS che consente di portare la bandwith massima a 5.5 o 11 Mbps (nell'802.11g si arrivera' anche a ~ 54 Mbps). Gli header e preamboli PLCP sono gli stessi della DSSS, in questo modo e' possibile la coesistenza di entrambe le modulazioni in una stessa connessione.

Le sostanziali differenze con il suo predecessore sono molteplici:

1. si sono riuniti i ​chips in gruppi da 8 formando cosi chiavi a codice complementario (8-chip complementary code keying, aka CCK) che vengono spediti alla stessa frequenza del DSSS (11 MHz), ottimizzando cosi l'uso della banda del canale.
2. sono state aggiunte delle funzionalita' opzionali per aumentare il bandwith, che sono utilizzabili solo se l'hardware e' abbastanza recente da supportarle.
   Le funzionalità sono le seguenti:
   • sostituzione del CCK con il packet binary convolutional coding (HR/DSSS/PBCC);
   • HR/DSSS/short, ovvero possibilita' di ridurre il preambolo PLCP per aumentare significantemente il transfer data rate, limitando cosi pero' la possibilita' di coesistenza con il DSSS a sole alcune particolari circostanze;
   • inserimento del Channel Agility, ovvero una particolare implementazione che consente di superare diversi problemi dovuti all'assegnamento di un canale statico, senza dover aggiungere alla totale implementazione il costo di questa funzionalita'.
     

Purtroppo l'IEEE non ha concesso le specifiche inerenti all'evoluzione della modulazione nella versione 802.11g, quindi non ci e' concesso sapere i miglioramenti che hanno portato poi il protocollo a supportare velocita' di circa 54 Mbps.
Parlandone con il Dott. Bononi, si e' arrivati ad ipotizzare che lo sviluppo sempre + veloce della tecnologia abbia portato ad un'alta precisione e sensibilita' di ricezione/trasmissione che quindi, ha portato ad un'aumento dei simboli (in modulazione un simbolo e' un particolare segnale che identifica una serie di bit) e ad una diminuzione dei bit adibiti al controllo di errori, cosi aumentandone di molto il bit rate potenziale.
Rimaniamo comunque nella ricerca di specifiche piu' recentemente rilasciate, lasciando quest'ultima parte di paragrafo come "prossima ad essere aggiornata".

Management del sottolivello MAC

Uno degli aspetti più importanti, per quanto riguarda la connessione di più hosts ad una rete wireless, è sicuramente il meccanismo di sincronizzazione, il quale deve esistere per permettere la comunicazione all'interno della rete. Per permettere ciò ogni nodo ha al suo interno un TSF (Timing Synchronization Function) che funge da orologio per tutti i nodi. La sincronizzazione è presente sia nei BSS che nei IBSS e avviene in maniere differenti.

In un BSS la sincronizzazione viene mantenuta dall'AP, che inizializza il suo TSF interno e invia beacons a tutti i nodi della rete con all'interno il proprio timer. Ogni nodo che riceve il beacon deve sincronizzare il proprio timer con il valore del timestamp ricevuto.

In un IBSS invece ogni nodo partecipa allla sincronizzazione mediante l'utilizzo di un algoritmo distribuito; in pratica ogni nodo invia dei beacon ad ogni nodo della rete e riceve beacons da tutti gli altri. Decide poi autonomamente se settare il proprio timer col valore ricevuto o se scartare il beacon perchè il valore del timetamp all'interno è più vecchio del valore del proprio timer.

Il mantenimento della sincronizzazione è dato da un algoritmo: ogni nodo mantiene un timer TSF in modulo 2⁶⁴ microsecondi e si aspetta di ricevere un beacon ad intervalli regolari (definiti come aBeaconPeriod, che è un parametro del nodo). Un nodo che vuole inviare un beacon deve settare il valore del timestamp, che è dato dalla somma tra il valore del TSF al tempo della trasmissione del primo bit del timestamp su PHY e dal tempo di ritardo per la trasmissione (passaggio dall'interfaccia MAC-PHY a PHY).

Acquisizione della sincronizzazione mediante scansione

Ogni stazione (o nodo) può operare attraverso due modalità di scansione: la modalità passiva o la modalità attiva. In modalità di scansione passiva la stazione sta in ascolto su tutti i canali e aspetta di ricevere dei beacon in cui il valore SSID sia uguale al valore SSID dell'ESS di cui la stazione vuole entrare a fare parte. Una volta ritornati questi frames, la stazione (attraverso opportune funzioni) entra a far parte di un BSS, acquisendo tutti i parametri del BSS (timer di sincronizzazione, parametri di PHY, BSSID, parametri di trasmissione dei beacon...). La modalità di scansione attiva invece si basa sul concetto di Probe Request e Probe Response: praticamente una stazione invia un Probe Request e si mette in ascolto di un Probe Response; quando il Probe Response conterrà il SSID cercato dalla stazione allora avrà inizio la sincronizzazione e la stazione entrerà a far parte di un BSS. L'algoritmo di scansione è al cap 11.1.3.2.2 (pag 127 di ieee 802.11-1999).

Associazione e riassociazione di una stazione con un AP

L'associazione tra una stazione e un AP avviene in due fasi:

• autenticazione
• associazione

Una volta effettuata l'autenticazione su un AP, la stazione invia una richiesta di associazione all'AP e attende la risposta;in caso di risposta affermativa la stazione sarà fisicamente associata all'AP e potrà avviare la comunicazione, in caso contrario la stazione non si potrà associare. Analogamente quando una stazione vorrà riassociarsi ad un AP invierà allo stesso una richiesta di riassociazione e attederà la risposta dall'AP. Naturalmente quado un AP riceve una richiesta di associazione controlla che la stazione che ha inviato tale richiesta sia autenticata su sè stesso; in caso affermativo l'AP invierà una risposta (positiva o negativa) alla stazione.

Appunti vari

_{20061014-1305 Roma}
Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi è praticamente una serie di richieste tra il client e l'AP affinchè la connessione venga instaurata; nota importante è che il client prima di collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova connessione. Naturalmente vi sono già delle primitive implementate atte a svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che per le reinstaurazione). Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro (es che fece anche il seminarista se non ricordo male) e per fare ciò si inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda pancette ai client conessi a lui; quindi vi è una doppia sincronizzazione: una tra AP e client e una tra client e client (cap 11 del documento ieee 802.11).