Changes between Initial Version and Version 1 of Protocollo

Timestamp:

Nov 4, 2006, 3:43:10 PM (18 years ago)

Author:

gnappo

Comment:

Resa a se stante la pagina di analisi di 802.11.

Protocollo

@@ +1 @@
+= Analisi dello standard IEEE 802.11 =
+[[PageOutline(1-6,Indice dei contenuti)]]
+== 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,,[[BR]]
+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,,[[BR]]
+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,,[[BR]]
+La funzionalita' permette di capire lo stato del mezzo trasmissivo (occupato o
+libero) ed e' presente non solo nel sottostrato PHY, come e' ovvio, ma anche in
+MAC. Qui in MAC il meccanismo e' da considerarsi virtuale, nel senso che
+interroga il Network Allocation Vector. Ogni STA ha il compito di tenere traccia
+nel NAV delle "prenotazioni" effettuate da altri che indicano la futura
+indisponibilita' del canale e, se necessario, rimandare i tentativi di
+trasmissione. Il calcolo di questa durata non e' altro che la somma dei tempi
+necessari alle fasi della comunicazione: la trasmissione dei vari frame di dati,
+degli [wiki:Studio#Acknoledgment acknoledgment] e l'attesa dei vari
+[wiki:Studio#InterframespaceIFSspaceIFS IFS].
+Le citate informazioni necessarie alle stazioni estranee alla comunicazione sono
+o prefissate dallo standard (la durata di invio di un ACK o i tempi inter-frame)
+oppure sono comunicate dalle stazioni interne alla comunicazione. Il campo
+Duration/ID e' quindi presente sia nella coppia iniziale < RTS 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,,[[BR]]
+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,,[[BR]]
+Lo standard stabilisce la lunghezza di tempo che deve intercorrere fra le
+trasmissioni dei vari frame; lo scopo e' quello di fornire informazioni precise
+alle stazioni. Queste ultime, attraverso il meccanismo ''carrier-sense'',
+attendono infatti di poter considerare libero il mezzo trasmissivo a seconda
+dei periodi di inattivita' rilevati.
+
+A seconda della situazione viene usato uno dei seguenti 4 periodi:
+ 1. SIFS (short interframe space):
+    usato per frame ACK, CTS, per frame (eccetto il primo) di una
+    trasmissione frammentata, per le risposte al polling del PCF;
+ 2. PIFS (PCF interframe space):
+    usato solo dalle STA che, sotto un PCF, tentano di avere accesso al mezzo
+    trasmissivo all'inizio del CFP;
+ 3. DIFS (DCF interframe space):
+    usato sotto DCF dalle STA per i frame dati (MPDU) o per i frame di gestione
+    (MMPDU);
+ 4. EIFS (extented interframe space):
+    usato quando il PHY indica al MAC che l'ultimo frame MAC non e' stato
+    ricevuto corettamente e che il campo FCS non e' utilizzabile;
+
+===== Random backoff time =====
+,,20061025-1233 SoujaK,,[[BR]]
+In seguito al rilevamento di inattivita' del mezzo trasmissivo (secondo le
+politiche appena descritte), ogni STA e' tenuta a ritardare ulteriormente la
+propria trasmissione per un periodo di backoff di durata casuale, a meno che non
+sia gia' stato impostato il relativo timer. L'intento e' quello di evitare che
+tutte le STA in attesa collidano nel momento in cui contemporaneamente
+effettuino tentativi di trasmissione.[[BR]]
+Il periodo di 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'.[[BR]]
+I contatori prima citati vengono poi resettati (azzerati) al verificarsi di
+determinati eventi interpretabili come comunicazione ben riuscita (e.g la
+ricezione di un ACK): i due contatori si differenziano proprio su questo
+particolare, ma non e' il caso di approfondire ulteriormente.
+
+===== Frame duplicati =====
+,,20061027-0536 SoujaK,,[[BR]]
+Dal momento che le procedure di conferma di trasmissione e di ritrasmissione
+sono incorporati all'interno del protocollo, esiste la possibilita' che un
+determinato frame venga ricevuto piu' di una volta. La stazione ricevente deve
+rendersi conto della duplicazione e scartare i doppioni. E' stato pertanto
+inserito un campo di controllo di sequenza all'interno nei frame dati e in
+quelli di gestione, 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. 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
+[http://www.xt3.it/reti0506/MIB-D6.2.txt 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). ,,
+
+=== FHSS (Frequency Hopping Spread Spectrum) === 
+Si tratta di una specifica del livello PHY.
+Vengono in generale definite un sacco di primitive che vanno dal controllo
+del consumo energetico del medium, alla trasmissione, al CS/CCA.
+Frequency hopping: il salto delle frequenze (channel) e' fatto alfine di
+ottenere un maggior throughput della rete (non si impegna mai una stessa
+frequenza per "troppo" tempo). Questo hopping deve avvenire entro
+un tempo limite di 224us.
+
+gnappo:,,fa schifo! pensero' io stesso a migliorare,,
+
+=== DSSS ===
+20061021-???? gnappo [[BR]]
+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. [[BR]]
+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 [[BR]]
+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 [[BR]]
+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.
+
+=== Specifiche della modulazione HR/DSSS (802.11b/802.11g) ===
+20061022-2130 Zeratul [[BR]]
+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. [[BR]]
+
+Le sostanziali differenze con il suo predecessore sono molteplici:
+ 1. si sono riuniti i [http://en.wikipedia.org/wiki/Chip_rate "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. [[BR]]
+    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'.[[BR]]
+
+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.[[BR]]
+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.[[BR]]
+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^64^ 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,,[[BR]]
+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).