[[PageOutline]] = IEEE 802.11 - Gestione del livello MAC = Uno degli aspetti piu' importanti, per quanto riguarda la connessione di piu' STA ad una rete wireless, e' sicuramente il meccanismo di sincronizzazione fra di esse, indispensabile per permettere la comunicazione all'interno della rete. A tal fine, ogni nodo possiede la funzione di sincronizzazione (''Timing Synchronization Function'' TSF), basata su un orologio interno in microsecondi (con valori espressi modulo 2^64^). Questa funzione e' presente sia nei BSS a infrastruttura che nei IBSS ma avviene in maniere differenti. In un '''BSS ad infrastruttura''' la sincronizzazione viene gestita dall'AP, che inizializza un orologio TSF, comunicandone il valore ad ogni nodo della rete attraverso i ''beacon''. Ogni STA che riceve il ''beacon'' deve sincronizzare il proprio orologio con il valore ricevuto. In un '''IBSS''', invece, ogni nodo partecipa alla sincronizzazione mediante l'utilizzo di un algoritmo distribuito che si fonda parimenti sullo scambio reciproco di ''beacon''. Ogni STA decide autonomamente se regolare il proprio orologio al valore ricevuto o se ignorarlo (quando il ''timestamp'' e' meno recente del proprio). Il ''[wiki:CollegamentoMancante beacon interval]'' e' fissato nel momento della creazione della rete, dalla STA che la inizializza. Ogni STA, indipendentemente dalle distinzioni fatte fin ora, si aspetta di ricevere ''beacon'' ad intervalli regolari (di lunghezza definita dal parametro `aBeaconPeriod`). Un nodo che voglia inviare un ''beacon'' dovra' calcolare il valore del ''timestamp'' senza trascurare le latenze dovute alle procedure trasmissive, sommando il valore dell'orologio TSF (rilevato nel momento dell'inoltro a PHY del primo bit del ''timestamp'') con il tempo di ritardo introdotto dal passaggio dall'interfaccia MAC-PHY al livello fisico (i.e. l'antenna). == Acquisizione della sincronizzazione mediante scansione == Ogni stazione, per sincronizzarsi con un BSS, ha a disposizione due modalita' di scansione: la modalita' passiva e la modalita' attiva. In modalita' di '''scansione passiva''' la stazione ascolta progressivamente ogni canale, aspettando di ricevere dei ''beacon'' nei quali il valore SSID sia uguale a quello dell'ESS di cui vuole entrare a fare parte. Dopodiche' la stazione (attraverso opportune funzioni) entra a far parte di quel BSS, acquisendone tutti i parametri: ''timer'' di sincronizzazione, parametri di PHY, BSSID, parametri di trasmissione dei ''beacon''. La modalita' di '''scansione attiva''' invece si basa sullo scambio di ''frame'' di tipo ''probe request'' e ''probe response''. La STA che voglia entrare a far parte di un BSS, inviera' un ''frame'' di richiesta (''probe request'') richiedendo esplicitamente le informazioni desiderate. Si sincronizzera' non appena ricevera' il corrispondente ''frame'' di risposta (''probe response''). == Associazione e riassociazione di una stazione con un AP == La procedura utilizzata per gestire il processo di associazione e riassociazione consta, come e' facile intuire, di un dialogo fra la STA che desideri effettuare l'operazione e l'AP che offre il relativo servizio. Tale conversazione puo' essere descritta attraverso la sequenza di invocazioni delle funzioni relative al SAP delle entita' di gestione (le SME) delle sue STA coinvolte. * Dapprima la SME della STA richiede l'invio di una richiesta di associazione (risp. riassociazione) all'AP scelto, tramite la primitiva `MLME-ASSOCIATE.request` (`MLME-REASSOCIATE.request`). * Una volta che l'AP riceve la richiesta di associazione (riassociazione) risponde con una conferma d'associazione contenente il relativo ID se la STA e' autenticata, oppure con una notifica di deautenticazione. * Una volta che il livello MAC della STA riceve la risposta alla richiesta di associazione (riassociazione) dell'AP in questione notifica l'esito alla SME tramite la `MLME-ASSOCIATE.confirm` (`MLME-REASSOCIATE.confirm`), contenente l'eventuale ragione del fallimento. * L'AP provvedera' poi ad informare il DS dell'avvenuta associazione (riassociazione), invocando la `MLME-ASSOCIATE.indication` (`MLME-REASSOCIATE.indication`). == Gestione energetica == Lo standard prevede la possibilita' di utilizzare l'hardware in maniera efficiente rispetto ai consumi energetici, dal momento che non e' affatto infrequente l'uso di dispositivi portatili alimentati a batteria. Il principio di base su cui fonda e' di limitare la potenza dissipata nei momenti in cui essa non sia necessaria. Una STA e' tenuta ad effettuare il cambio del proprio stato di gestione energetica (''power management'') informando preventivamente ogni potenziale trasmettitore (ad esempio l'AP di una BSS ad infrastruttura). I potenziali trasmettitori, dal canto loro, devono tener traccia di tutte le stazioni che operano in modalita' di risparmio energetico, poiche' la trasmissione dei dati verso questo insieme di STA deve avvenire in maniera differente rispetto alla consuetudine. Infatti una STA in modalita' di risparmio energetico puo' alternare il proprio stato fra: * '''veglia''' (''awake'') la stazione lavora a piena potenza e puo' ricevere frame in qualsiasi momento; e' detta anche modalita' attiva; * '''riposo''' (''doze'') la stazione lavora in risparmio energetico e riceve ''frame'' attraverso il meccanismo che sara' descritto a breve. Naturalmente le stazioni possono passare da uno stato all'altro, a seconda delle loro necessita', ma sono tenute ad informare adeguatamente i potenziali trasmettitori durante un generico scambio di ''frame''. Il campo ''power management'' indica appunto lo stato corrente della STA trasmittente. Le STA che intendano comunicare con una STA in stato di riposo sono pertanto tenute a accumulare i dati ad essa diretti procrastinandone l'invio fino al successivo risveglio. === Gestione energetica in un BSS ad infrastruttura === Le stazioni in modalita' di gestione energetica che non abbiano dati da inviare cercano di limitare lo stato di veglia solo nei momenti di effettiva ricezione di dati. Lo stato di veglia minimo coincidera' con i momenti di trasmissione dei ''beacon'' da parte dell'AP, poiche' in tali ''frame'' e' contenuta la '''TIM''' (''Traffic Indication Map''), contenente gli AID delle STA per le quali esso possiede ''frame'' in attesa di consegna. Una STA appena riattivatasi che trovera' il proprio AID (''association ID'') nella TIM richiedera' esplicitamente l'invio dei ''frame'' a lei diretti inviando all'AP il ''frame PS-poll''. L'AP potra' quindi procedere alla trasmissione desiderata oppure ritardarla ulteriormente. I TIM sono differenziati a seconda del tipo di trasmissione in attesa: ''unicast'' oppure ''multicast''/''broadcast''. I primi vengono definiti propriamente '''TIM''' e sono presenti in ogni ''beacon''; i secondi sono denominati '''DTIM''' (''Delivery Traffic Indication Message'') e vengono inviati ad intervalli regolari (i ''DTIMPeriod'') multipli del ''beacon interval''. Ad esempio, un valore del ''DTIMPeriod'' pari a tre indichera' che ogni tre ''beacon'', esso conterra' il DTIM. Il DTIM, dal momento che riguarda trasmissioni ''multicast'' o ''broadcast'' non necessita del ''PS-poll'' da parte delle stazioni interessate: l'AP e' tenuto ad inviare i ''frame'' in attesa subito dopo il ''beacon'' in questione. === Gestione energetica in un BSS indipendente === In un IBSS le stazioni devono essere tutte sincronizzate al fine di poter trasmettere i dati secondo una strategia similare a quella vista per i BSS ad infrastruttura. I dati da inviare vengono conservati e, una volta pronti per essere spediti ad una stazione in ''power save'', si spedisce un messaggio di annuncio, chiamato ATIM (''Ad-hoc'' TIM), all'interno del ''beacon''. Tali annunci possono aver bisogno, a causa della natura distribuita della rete, di tempi piu' lunghi rispetto a reti centralizzate. Viene quindi definita una finestra temporale, denominata ''ATIM window'' dedicata allo scambio di ATIM. Com'e' facile intuire le STA in modalita' di gestione energetica sono tenute a rimanere sveglie durante quel lasso di tempo. I ''frame'' ATIM seguono le stesse regole del coordinamento distribuito, richiedendo quindi conferma di ricezione tramite l'usuale ACK, con l'eccezione per trasmissioni ''multicast'' o ''broadcast''. L'effettiva trasmissione dei dati in attesa potra' avvenire soltanto dopo la ricezione di tale ACK; la stazione destinataria avra' la possibilita' di tornare in modalita' di risparmio energetico ad avvenuta ricezione dei ''frame'' attesi.