Changes between Initial Version and Version 1 of IEEE802.11/GestioneDeiSottolivelli

Timestamp:

Feb 17, 2007, 5:43:28 PM (18 years ago)

Author:

soujak

Comment:

Partizionamento di wiki:Protocollo (5/9)

IEEE802.11/GestioneDeiSottolivelli

@@ +1 @@
+[[PageOutline(1-6)]]
+= IEEE 802.11 - Gestione dei sottolivelli =
+
+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 mezzo ai servizi PHY), 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: dissociazione 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
+   entita' PHY;
+ * CHARACTERISTICS.confirm: viene sollevata dal'entita' PHY successivamente
+   ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative 
+   dell'entita' PHY;
+ * DSSSTESTMODE.request: utile per entrare in modalita' test in una entita' PHY
+   di tipo DSSS;
+ * DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una
+   entita' PHY di tipo DSSS.
+
+== 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,...}).
+
+,,20061211-2200 gnappo,,[[BR]]
+L'unica primitiva per il supporto dell'interazione ''peer-to-peer'' e'
+PHY-DATA alla quale sono associati i seguenti significati:
+ * PHY-DATA.request(DATA): trasferisce un ottetto di dati alla ''PHY
+   entity'' successivamente ad una confermata richiesta di trasmissione
+   (PHY-TXSTART.confirm). Quando la ''PHY entity'' ricevera' l'ottetto di
+   dati indichera' l'avvenuta ricezione attraverso la primitiva
+   PHY-DATA.confirm.
+ * PHY-DATA.indication: trasferisce un ottetto di dati dal livello fisico
+   al livello MAC.
+ * PHY-DATA.confirm: come gia' accennato, viene sollevata dalla ''PHY
+   entity'' per confermare l'avvenuta ricezione dei dati dalla ''MAC entity''.
+
+Le altre primitive sono:
+ * PHY-TXSTART.request(TXVECTOR): permette al sottolivello MAC di
+   richiedere all'entita' fisica di cominciare la trasmissione di un MPDU.
+   Come dato in ingresso, prende un vettore contenente parametri sia del
+   sottolivello PLCP che di PHY.
+ * PHY-TXSTART.confirm: viene sollevata dal sottolivello PHY per
+   confermare, alla ''MAC entity'', l'avvenuto inizio di trasmissione. In
+   questo modo, l'entita' fisica, si dichiara disponibile a ricevere dati
+   attraverso PHY-DATA.request(DATA).
+ * PHY-TXEND.request: e' invocata dalla ''MAC entity'' per forzare il
+   completamento della trasmissione del MPDU corrente. Viene generata
+   conseguentemente all'ultima chiamata PHY-DATA.confirm per l'MPDU
+   corrente.
+ * PHY-TXEND.confirm: utilizzata dal sottolivello fisico per notificare
+   all'entita' MAC il completamento della trasmissione. Il recepimento di questa
+   primitiva da parte della ''MAC entity'' fornisce il riferimento temporale per
+   il protocollo di ''backoff''.
+ * PHY-CCARESET.request: viene richiesta dalla ''MAC entity'' per ottenere
+   un reset dell'automa a stati finiti per il ''Clear Channel Assessment''
+   (valutazione del canale libero). E' generata dalla ''MAC entity'' allo
+   scadere del ''NAV timer''.
+ * PHY-CCAREST.confirm: sollevata dall'entita' fisica per confermare
+   l'avvenuto ''reset'' dell'automa di cui al punto precedente.
+ * PHY-CCAREST.indication: questa primitiva ritorna, all'entita' MAC, lo
+   stato del canale (''idle'' oppure ''busy''). Viene generata ogni qualvolta
+   si ha una transizione del canale da libero a occupato e viceversa.
+ * PHY-RXSTART.indication: sollevata dal livello fisico per informare il
+   livello MAC che e' stato ricevuto un SFD e un'intestazione PLCP valida (e
+   che quindi avra' inizio la ricezione di un ''frame'').
+ * PHY-RXEND.indication: grazie a questa primitiva l'entita' fisica
+   comunica all'entita' MAC la fine della ricezione di un MPDU ed indica
+   eventuali errori occorsi.