Changes between Version 1 and Version 2 of IEEE802.11/GestioneDeiSottolivelli
- Timestamp:
- Mar 19, 2007, 5:26:48 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
IEEE802.11/GestioneDeiSottolivelli
v1 v2 1 1 [[PageOutline(1-6)]] 2 <revisionato> 3 2 4 = IEEE 802.11 - Gestione dei sottolivelli = 3 5 … … 6 8 dal poter essere considerate vere e proprie interfacce: si tratta delle "''MAC 7 9 layer management entities''" (MLME) e delle "''PHY layer management entities''" 8 (PLME). 10 (PLME).[[BR]] 9 11 E' assai importante notare, specialmente ai fini dello studio in oggetto, che lo 10 strato MAC non oscura il sottostante PHY, ma permette alla " station management11 entity " (SME) di interagire direttamente con esso. Le varie entita' hanno la12 strato MAC non oscura il sottostante PHY, ma permette alla "''station management 13 entity''" (SME) di interagire direttamente con esso. Le varie entita' hanno la 12 14 possibilita' di comunicare fra loro secondo le specifiche dello standard, 13 15 attraverso i SAP (''service access point''). Tale concetto intende aggregare 14 l'insieme di chiamate che una determinata entita' 16 l'insieme di chiamate che una determinata entita' espone alle altre per 15 17 realizzare forme di comunicazione o invocazione. 16 18 17 19 {{{ 18 __||________________________ 19 | | | | 20 | MAC | MLME = | 21 | | | | 22 |--||--|--||--| Station | 23 | | | Managemement | 24 | PLPC | PLME | Entity | 25 | | | | 26 |--||--| = | 27 | | | | 28 | PMD | | | 29 |______|______|______________| 20 __|MAC SAP|______________________________________ 21 | ' ' | | | 22 | | ------------ | 23 | [MAC] | [MLME] SME-MLME SAP | 24 | | ------------ | 25 | . . | . . | | 26 |--|PLCP SAP|--|--|MLME-PLME SAP|--| | 27 | ' ' | ' ' | [SME] | 28 | [PLCP] | | | 29 | . . | [PLME] | | 30 |--|PMD SAP|---| ------------ | 31 | ' ' | SME-PLME SAP | 32 | [PMD] | ------------ | 33 |______________|___________________|______________| 30 34 }}} 31 35 … … 34 38 gestisca stati opportuni del livello fisico. 35 39 36 Il livello PHY viene suddiviso nella seguente maniera:40 Il livello PHY e' pertanto strutturato nella seguente maniera: 37 41 * PLCP (''Physical Layer Convergence Procedure''): funzioni di convergenza del 38 livello fisico (adattamento del mezzo ai servizi PHY), che realizzano una39 traduzione al fine di rendere l'interfacciacomune;42 livello fisico, che realizzano una traduzione per far si` che dispositivi 43 fisici anche piuttosto differenti possano offrire un'interfaccia PHY comune; 40 44 * PMD (''Physical Medium Dependent''): insieme di funzioni fortemente 41 45 dipendenti dallo specifico dispositivo wireless (ad esempio richieste di 42 46 trasmissione o ricezione di dati). 43 47 44 Anche in questo caso le relazioni con l'esternosono gestite da appositi48 Anche in questo caso le relazioni fra sottolivelli sono gestite da appositi 45 49 moduli SAP: uno specifico per la porzione PLCP (PLCP-SAP) e un altro relativo al 46 50 sottostrato PMD (PMD-SAP). … … 49 53 50 54 Le informazioni specifiche per la gestione di ogni strato sono incapsulate 51 all'interno di cio' che viene definita ''Management Information Base'' (MIB) che 52 puo' essere visto come un componente di ogni livello. In accordo con questo, 53 ogni ''Management Entity'' possiede specifiche primitive di `GET` e `SET` in 54 grado di operare sugli attributi della relativa MIB. Informazioni dettagliate 55 sugli attributi dei vari MIB sono presenti nel 55 all'interno di cio' che viene definita la ''Management Information Base'' (MIB) 56 di quel livello. Quindi ogni ''Management Entity'' possiede specifiche primitive 57 di `GET` e `SET` in grado di operare sugli attributi della relativa MIB. 58 Informazioni dettagliate sugli attributi dei vari MIB sono presenti nel relativo 56 59 [http://www.xt3.it/reti0506/MIB-D6.2.txt documento ufficiale] 57 60 58 61 == Interfaccia di MAC: MLME SAP == 59 62 60 * POWERMGT: richieste al modulo che gestisce il risparmio energetico61 * SCAN: scansione della rete alla ricerca di BSS disponibili62 * JOIN: sincronizzazione con un BSS63 * AUTHENTICATE: autenticazione con un BSS64 * DEAUTHENTICATE: deautenticazione con un BSS65 * ASSOCIATE: associazione fra una STA e un AP66 * REASSOCIATE: associazione fra una STA e un altro AP67 * DEASSOCIATE: dissociazione fra una STA e un AP68 * RESET: azzeramento69 * START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete63 * `POWERMGT`: richieste al modulo che gestisce il risparmio energetico 64 * `SCAN`: scansione della rete alla ricerca di BSS disponibili 65 * `JOIN`: sincronizzazione con un BSS 66 * `AUTHENTICATE`: autenticazione con un BSS 67 * `DEAUTHENTICATE`: deautenticazione con un BSS 68 * `ASSOCIATE`: associazione fra una STA e un AP 69 * `REASSOCIATE`: associazione fra una STA e un altro AP 70 * `DEASSOCIATE`: dissociazione fra una STA e un AP 71 * `RESET`: azzeramento 72 * `START`: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete 70 73 ''ad-hoc'') 71 72 ,,20061019-0920 SoujaK: La revisione G del documento non introduce nessun73 cambiamento alle interfacce del SAP legato al livello MAC. Viene piuttosto74 esteso il livello PHY al fine di supportare larghezze di banda maggiori e75 differenti modulazioni del segnale.'',,76 74 77 75 == Interfaccia di PHY: PLME SAP == 78 76 79 In generale si hanno disposizione tutti i getter e i setternecessari per80 manipolare tutti gli attributidel MIB (normati nell'aggiunta `Annex D`).77 In generale si hanno a disposizione tutti i `getter` e i `setter` necessari per 78 manipolare ogni attributo del MIB (normati nell'aggiunta `Annex D`). 81 79 Inoltre, si hanno a disposizione le seguenti primitive: 82 * RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato83 di ricezione;84 * CHARACTERISTICS.request: ritornale caratteristiche operative della80 * `RESET.request`: forza il reset del livello PHY, reinizializzandolo allo 81 stato di ascolto sul mezzo trasmissivo; 82 * `CHARACTERISTICS.request`: richiede le caratteristiche operative della 85 83 entita' PHY; 86 * CHARACTERISTICS.confirm: viene sollevata dal'entita' PHY successivamente87 ad una CHARACTERISTICS.request . Fornisce le caratteristiche operative88 dell'entita' PHY ;89 * DSSSTESTMODE.request: utile per entrare in modalita' test in una entita' PHY90 di tipo DSSS;91 * DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una84 * `CHARACTERISTICS.confirm`: viene sollevata dall'entita' PHY successivamente 85 ad una CHARACTERISTICS.request (fornisce le caratteristiche operative 86 dell'entita' PHY); 87 * `DSSSTESTMODE.request`: utile per entrare in modalita' test in una entita' 88 PHY di tipo DSSS; 89 * `DSSSTESTOUTPUT.request`: opzionale, testa i segnali di output di una 92 90 entita' PHY di tipo DSSS. 93 91 94 92 == Interfaccia di PHY: PHY SAP == 95 93 96 Come gia' 94 Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono 97 95 separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire un 98 meccanismo indipendente dalla PHY entityper trasferire MPDU fra le STA.96 meccanismo indipendente dalla entita' PHY per trasferire MPDU fra le STA. 99 97 Anche in questa sezione, i servizi vengono definiti in maniera puramente 100 98 astratta, in modo da non forzare a particolari implementazioni delle interfacce. 101 99 102 100 Le primitive tra MAC e PHY si possono dividere in due categorie: 103 * primitive per il supporto d'interazioni punto- a-punto a livello MAC104 (primitiva PHY-DATA.{request, confirm, receive, indication}).105 * primitive con significato locale per agevolare l'interazione tra sottolivelli106 (e.g. PHY-TXStart.{request,...}).101 * primitive per il supporto d'interazioni punto-punto a livello MAC (cioe' 102 trasferimento di MPDU) 103 * primitive con significato locale per agevolare l'interazione tra 104 sottolivelli (cfr. SAP). 107 105 108 ,,20061211-2200 gnappo,,[[BR]] 109 L'unica primitiva per il supporto dell'interazione ''peer-to-peer'' e' 110 PHY-DATA alla quale sono associati i seguenti significati: 111 * PHY-DATA.request(DATA): trasferisce un ottetto di dati alla ''PHY 112 entity'' successivamente ad una confermata richiesta di trasmissione 113 (PHY-TXSTART.confirm). Quando la ''PHY entity'' ricevera' l'ottetto di 114 dati indichera' l'avvenuta ricezione attraverso la primitiva 115 PHY-DATA.confirm. 116 * PHY-DATA.indication: trasferisce un ottetto di dati dal livello fisico 117 al livello MAC. 118 * PHY-DATA.confirm: come gia' accennato, viene sollevata dalla ''PHY 119 entity'' per confermare l'avvenuta ricezione dei dati dalla ''MAC entity''. 106 L'unica primitiva per il supporto dell'interazione punto-punto fra entita' 107 paritetiche di livello MAC e' PHY-DATA, utilizzata sia per la trasmissione 108 (`request`+`confirm`), che per la ricezione (`indication`). 120 109 121 Le altre primitive sono: 122 * PHY-TXSTART.request(TXVECTOR): permette al sottolivello MAC di 123 richiedere all'entita' fisica di cominciare la trasmissione di un MPDU. 124 Come dato in ingresso, prende un vettore contenente parametri sia del 125 sottolivello PLCP che di PHY. 126 * PHY-TXSTART.confirm: viene sollevata dal sottolivello PHY per 127 confermare, alla ''MAC entity'', l'avvenuto inizio di trasmissione. In 128 questo modo, l'entita' fisica, si dichiara disponibile a ricevere dati 129 attraverso PHY-DATA.request(DATA). 130 * PHY-TXEND.request: e' invocata dalla ''MAC entity'' per forzare il 131 completamento della trasmissione del MPDU corrente. Viene generata 132 conseguentemente all'ultima chiamata PHY-DATA.confirm per l'MPDU 133 corrente. 134 * PHY-TXEND.confirm: utilizzata dal sottolivello fisico per notificare 135 all'entita' MAC il completamento della trasmissione. Il recepimento di questa 136 primitiva da parte della ''MAC entity'' fornisce il riferimento temporale per 137 il protocollo di ''backoff''. 138 * PHY-CCARESET.request: viene richiesta dalla ''MAC entity'' per ottenere 139 un reset dell'automa a stati finiti per il ''Clear Channel Assessment'' 140 (valutazione del canale libero). E' generata dalla ''MAC entity'' allo 141 scadere del ''NAV timer''. 142 * PHY-CCAREST.confirm: sollevata dall'entita' fisica per confermare 143 l'avvenuto ''reset'' dell'automa di cui al punto precedente. 144 * PHY-CCAREST.indication: questa primitiva ritorna, all'entita' MAC, lo 110 * `PHY-DATA.request(DATA)`: richiede il trasferimento di un ottetto di dati 111 alla ''PHY entity'' (solo se in modalita' di trasmissione, dopo una 112 PHY-TXSTART.confirm) 113 * `PHY-DATA.confirm`: sollevata dalla entita' PHY per confermare l'avvenuta 114 ricezione dei dati dalla ''MAC entity'' (risposta alla PHY-DATA.request) 115 * `PHY-DATA.indication`: notifica l'avventuto trasferimento di un ottetto di 116 dati dal livello fisico al livello MAC 117 118 Le primitive del livello PHY sono: 119 * `PHY-TXSTART.request(TXVECTOR)`: permette al sottolivello MAC di 120 richiedere all'entita' fisica di cominciare la trasmissione di una MPDU, 121 spostandosi, come e' ovvio, in modalita' trasmettitore. Prende in input un 122 vettore contenente parametri sia del sottolivello PLCP che di PHY. 123 * `PHY-TXSTART.confirm`: viene sollevata dal sottolivello PHY per 124 confermare alla ''MAC entity'' l'avvenuto inizio di trasmissione (i.e. le 125 intestazioni PLCP). In questo modo, l'entita' fisica, si dichiara disponibile 126 a ricevere dati attraverso PHY-DATA.request(DATA). 127 * `PHY-TXEND.request`: e' invocata dalla entita' MAC per forzare il 128 completamento della trasmissione della MPDU corrente. Viene generata 129 conseguentemente all'ultima chiamata PHY-DATA.confirm per l'MPDU corrente. 130 * `PHY-TXEND.confirm`: utilizzata dal sottolivello fisico per notificare 131 all'entita' MAC il completamento della trasmissione. (La ricezione di 132 questa conferma da parte della ''MAC entity'' costituisce il riferimento 133 temporale necessario per il [wiki:CollegamentoMancante ''backoff''].) 134 * `PHY-CCARESET.request`: viene richiesta dalla ''MAC entity'' per ottenere 135 un azzeramento dell'automa a stati finiti utilizzato per il ''Clear Channel 136 Assessment''(valutazione del canale libero). E' generata dalla ''MAC entity'' 137 allo scadere del ''NAV timer''. 138 * `PHY-CCARESET.confirm`: sollevata dall'entita' fisica per confermare 139 l'azzeramento dell'automa di cui al punto precedente. 140 * `PHY-CCARESET.indication`: questa primitiva ritorna all'entita' MAC lo 145 141 stato del canale (''idle'' oppure ''busy''). Viene generata ogni qualvolta 146 si ha una transizione del canale da libero a occupato eviceversa.147 * PHY-RXSTART.indication: sollevata dal livello fisico per informare il142 si ha una transizione del canale da libero a occupato oppure il viceversa. 143 * `PHY-RXSTART.indication`: sollevata dal livello fisico per informare il 148 144 livello MAC che e' stato ricevuto un SFD e un'intestazione PLCP valida (e 149 145 che quindi avra' inizio la ricezione di un ''frame''). 150 * PHY-RXEND.indication: grazie a questa primitiva l'entita' fisica151 comunica all'entita' MAC la fine della ricezione di un MPDU ed indica152 eventuali errori occorsi.146 * `PHY-RXEND.indication`: grazie a questa primitiva l'entita' fisica 147 comunica all'entita' MAC la fine della ricezione di una MPDU, indicando 148 eventuali errori.