Changes between Version 20 and Version 21 of Studio

Timestamp:

Nov 4, 2006, 3:43:28 PM (19 years ago)

Author:

gnappo

Comment:

Resa a se stante la pagina di analisi di 802.11.

Studio

@@ -50 +50 @@
 analisi dello standard, ha permesso la divisione degli argomenti e facilitato lo
 studio stesso e la successiva condivisione delle conoscenze.
-
-----
-
-= 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,,[[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).
-