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


Ignore:
Timestamp:
Mar 19, 2007, 5:26:48 PM (18 years ago)
Author:
soujak
Comment:

Aggiornamento dopo le due settimane di revisioni.

Legend:

Unmodified
Added
Removed
Modified
  • IEEE802.11/GestioneDeiSottolivelli

    v1 v2  
    11[[PageOutline(1-6)]]
     2<revisionato>
     3
    24= IEEE 802.11 - Gestione dei sottolivelli =
    35
     
    68dal poter essere considerate vere e proprie interfacce: si tratta delle "''MAC
    79layer management entities''" (MLME) e delle "''PHY layer management entities''"
    8 (PLME).
     10(PLME).[[BR]]
    911E' assai importante notare, specialmente ai fini dello studio in oggetto, che lo
    10 strato MAC non oscura il sottostante PHY, ma permette alla "station management
    11 entity" (SME) di interagire direttamente con esso. Le varie entita'  hanno la
     12strato MAC non oscura il sottostante PHY, ma permette alla "''station management
     13entity''" (SME) di interagire direttamente con esso. Le varie entita'  hanno la
    1214possibilita'  di comunicare fra loro secondo le specifiche dello standard,
    1315attraverso i SAP (''service access point''). Tale concetto intende aggregare
    14 l'insieme di chiamate che una determinata entita'  espone alle altre per
     16l'insieme di chiamate che una determinata entita' espone alle altre per
    1517realizzare forme di comunicazione o invocazione.
    1618
    1719{{{
    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 |______________|___________________|______________|
    3034}}}
    3135
     
    3438gestisca stati opportuni del livello fisico.
    3539
    36 Il livello PHY viene suddiviso nella seguente maniera:
     40Il livello PHY e' pertanto strutturato nella seguente maniera:
    3741 * PLCP (''Physical Layer Convergence Procedure''): funzioni di convergenza del
    38    livello fisico (adattamento del mezzo ai servizi PHY), che realizzano una
    39    traduzione al fine di rendere l'interfaccia comune;
     42   livello fisico, che realizzano una traduzione per far si` che dispositivi
     43   fisici anche piuttosto differenti possano offrire un'interfaccia PHY comune;
    4044 * PMD (''Physical Medium Dependent''): insieme di funzioni fortemente
    4145   dipendenti dallo specifico dispositivo wireless (ad esempio richieste di
    4246   trasmissione o ricezione di dati).
    4347
    44 Anche in questo caso le relazioni con l'esterno sono gestite da appositi
     48Anche in questo caso le relazioni fra sottolivelli sono gestite da appositi
    4549moduli SAP: uno specifico per la porzione PLCP (PLCP-SAP) e un altro relativo al
    4650sottostrato PMD (PMD-SAP).
     
    4953
    5054Le 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
     55all'interno di cio' che viene definita la ''Management Information Base'' (MIB)
     56di quel livello. Quindi ogni ''Management Entity'' possiede specifiche primitive
     57di `GET` e `SET` in grado di operare sugli attributi della relativa MIB.
     58Informazioni dettagliate sugli attributi dei vari MIB sono presenti nel relativo
    5659[http://www.xt3.it/reti0506/MIB-D6.2.txt documento ufficiale]
    5760
    5861== Interfaccia di MAC: MLME SAP ==
    5962
    60  * POWERMGT: richieste al modulo che gestisce il risparmio energetico
    61  * SCAN: scansione della rete alla ricerca di BSS disponibili
    62  * JOIN: sincronizzazione con un BSS
    63  * AUTHENTICATE: autenticazione con un BSS
    64  * DEAUTHENTICATE: deautenticazione con un BSS
    65  * ASSOCIATE: associazione fra una STA e un AP
    66  * REASSOCIATE: associazione fra una STA e un altro AP
    67  * DEASSOCIATE: dissociazione fra una STA e un AP
    68  * RESET: azzeramento
    69  * START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete
     63 * `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
    7073   ''ad-hoc'')
    71 
    72   ,,20061019-0920 SoujaK: La revisione G del documento non introduce nessun
    73   cambiamento alle interfacce  del SAP legato al livello MAC. Viene piuttosto
    74   esteso il livello PHY al fine  di supportare larghezze di banda maggiori e
    75   differenti modulazioni del  segnale.'',,
    7674
    7775== Interfaccia di PHY: PLME SAP ==
    7876
    79 In generale si hanno disposizione tutti i getter e i setter necessari per
    80 manipolare tutti gli attributi del MIB (normati nell'aggiunta `Annex D`).
     77In generale si hanno a disposizione tutti i `getter` e i `setter` necessari per
     78manipolare ogni attributo del MIB (normati nell'aggiunta `Annex D`).
    8179Inoltre, si hanno a disposizione le seguenti primitive:
    82  * RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato
    83    di ricezione;
    84  * CHARACTERISTICS.request: ritorna le caratteristiche operative della
     80 * `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
    8583   entita' PHY;
    86  * CHARACTERISTICS.confirm: viene sollevata dal'entita' PHY successivamente
    87    ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative
    88    dell'entita' PHY;
    89  * DSSSTESTMODE.request: utile per entrare in modalita' test in una entita' PHY
    90    di tipo DSSS;
    91  * DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una
     84 * `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
    9290   entita' PHY di tipo DSSS.
    9391
    9492== Interfaccia di PHY: PHY SAP ==
    9593
    96 Come gia'  accennato in precedenza, le funzioni proprie dello strato PHY sono
     94Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono
    9795separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire un
    98 meccanismo indipendente dalla PHY entity per trasferire MPDU fra le STA.
     96meccanismo indipendente dalla entita' PHY per trasferire MPDU fra le STA.
    9997Anche in questa sezione, i servizi vengono definiti in maniera puramente
    10098astratta, in modo da non forzare a particolari implementazioni delle interfacce.
    10199
    102100Le primitive tra MAC e PHY si possono dividere in due categorie:
    103  * primitive per il supporto d'interazioni punto-a-punto a livello MAC
    104    (primitiva PHY-DATA.{request, confirm, receive, indication}).
    105  * primitive con significato locale per agevolare l'interazione tra sottolivelli
    106    (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).
    107105
    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''.
     106L'unica primitiva per il supporto dell'interazione punto-punto fra entita'
     107paritetiche di livello MAC e' PHY-DATA, utilizzata sia per la trasmissione
     108(`request`+`confirm`), che per la ricezione (`indication`).
    120109
    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
     118Le 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
    145141   stato del canale (''idle'' oppure ''busy''). Viene generata ogni qualvolta
    146    si ha una transizione del canale da libero a occupato e viceversa.
    147  * PHY-RXSTART.indication: sollevata dal livello fisico per informare il
     142   si ha una transizione del canale da libero a occupato oppure il viceversa.
     143 * `PHY-RXSTART.indication`: sollevata dal livello fisico per informare il
    148144   livello MAC che e' stato ricevuto un SFD e un'intestazione PLCP valida (e
    149145   che quindi avra' inizio la ricezione di un ''frame'').
    150  * PHY-RXEND.indication: grazie a questa primitiva l'entita' fisica
    151    comunica all'entita' MAC la fine della ricezione di un MPDU ed indica
    152    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.