= Studio di fattibilita': associazione multipla simultanea = [[PageOutline(1-4,Indice)]] L'avvio e l'approccio di questo studio dipende in maniera forte dagli aspetti architetturali del protocollo 802.11. La questione non entra in gioco soltanto nel definire una bozza di implementazione, ma, ancor prima, nel comprendere quali siano le strade da intraprendere per una realizzazione a livello mentale. Dalle conoscenze iniziali dell'intero gruppo di lavoro e' risultato evidente che la ricerca non poteva perseguire una soluzione che lavorasse al di sopra di tutto lo stack IEEE 802.11. In questo tipo di scenario si renderebbe necessaria la ri-associazione ad ogni cambio di canale, una operazione che richiede tempi lunghi (o biblici, e' da considerare anche l'autenticazione), se comparati ai tempi di trasmissione dei dati. Se come riferimento si prende lo stack ISO/OSI, da quanto detto risulta evidente che la ricerca sara' orientata al di sotto del livello "network". Prima di poter proseguire in maniera sensata, si ritiene pertanto necessario approfondire la conoscenza dell'interfaccia offerta dal livello MAC e da quello PHY e come esse possano essere utilizzate. In aggiunta a questo e' da chiarire quanto forte sia la dipendenza fra il livello PHY e l'hardware del dispositivo sottostante. = Analisi dello standard IEEE 802.11 = == Descrizione funzionale del sottolivello MAC == * 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 L'accesso al mezzo di trasmissione comune (stiamo parlando dell'etere) e' regolato da una strategia che e' detta CSMA/CA, che sta per ''carrier sense multiple access with collision avoidance''. Il che significa che le varie stazioni comunicano in maniera tale da minimizzare le trasmissioni contemporanee che si annullerebbero vicendevolmente. La funzionalita' di coordinamento distribuito (Distributed Coordination Funtion o, piu' brevemente, DCF) che si fa carico della cosa e' pertanto componente necessario di ogni stazione, sia che essa operi in modalita' ''infrastracture'' che ''ad-hoc''. == 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. {{{ __||________________________ | | | | | 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 (PMD-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) === 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 il meccanismo per trasferire MPDU fra le STA, stando al di sopra del livello PMD. 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,...}). === Specifiche della modulazione FHSS === Si tratta attualmente della tecnologia piu' diffusa nelle trasmissioni radio. 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. == 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).