Changes between Initial Version and Version 1 of Studio

Timestamp:

Oct 18, 2006, 7:09:57 PM (19 years ago)

Author:

soujak

Comment:

Lo studio condotto fin'ora ha una pagina tutta sua.

Studio

@@ +1 @@
+= Studio di fattibilita': associazione multipla simultanea =
+== Introduzione ==
+
+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-... ####### 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,,
+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).