Changes between Version 37 and Version 38 of Protocollo


Ignore:
Timestamp:
Feb 16, 2007, 8:09:20 PM (18 years ago)
Author:
soujak
Comment:

Ancora qualche correzione qua e la'

Legend:

Unmodified
Added
Removed
Modified

  • Protocollo

    v37 v38  
    253253di tramite, che puo' pertanto essere visto come a lui sottostante. Il trasporto
    254254delle MSDU viene effettuato con trasmissioni ''connectionless'' di tipo
    255 best-effort, non ci sono quindi garanzie ne' sulla effettiva consegna dei
     255''best-effort'', non ci sono quindi garanzie ne' sulla effettiva consegna dei
    256256frame, ne', tantomeno, sull'ordine di arrivo degli stessi. Comunicazioni ad
    257257indirizzamento di tipo ''broadcast'' o ''multicast'' possono quindi, a causa
    … …  
    281281coordinamento e' distribuito.
    282282
    283 ,,gnappo: ''non e' chiara dove sia la concorrenza tra PCF e DCF. Probabilmente
    284 ci si puo' limitare a parlare di coesistenza.'',,
    285 
    286283==== Coordinamento distribuito (DCF) ====
    287 
    288284===== CSMA/CA e il meccanismo RTS/CTS =====
    289285,,20061027-1950 SoujaK,,[[BR]]
    … …  
    312308libero) ed e' presente non solo nel sottostrato PHY, come e' ovvio, ma anche in
    313309MAC. Qui in MAC il meccanismo e' da considerarsi virtuale, nel senso che
    314 interroga il Network Allocation Vector. Ogni STA ha il compito di tenere traccia
    315 nel NAV delle "prenotazioni" effettuate da altri che indicano la futura
     310interroga il ''Network Allocation Vector''. Ogni STA ha il compito di tenere
     311traccia nel NAV delle "prenotazioni" effettuate da altri che indicano la futura
    316312indisponibilita'  del canale e, se necessario, rimandare i tentativi di
    317313trasmissione. Il calcolo di questa durata non e' altro che la somma dei tempi
    318314necessari alle fasi della comunicazione: la trasmissione dei vari frame di dati,
    319 degli [wiki:Protocollo#Acknowledgment acknowledgment] e l'attesa dei vari
     315degli ''[wiki:Protocollo#Acknowledgment acknowledgment]'' e l'attesa dei vari
    320316[wiki:Protocollo#InterframespaceIFSspaceIFS IFS]. Le citate informazioni
    321317necessarie alle stazioni estranee alla comunicazione sono o prefissate dallo
    322318standard (la durata di invio di un ACK o i tempi ''inter-frame'') oppure sono
    323 comunicate dalle stazioni interne alla comunicazione. Il campo Duration/ID e'
    324 quindi presente sia nella coppia iniziale < RTS e CTS > che nelle successive
    325 coppie < PDU e ACK > diverse dalla prima; esso contiene la distanza temporale al
    326 termine della comunicazione, i.e. il primo acknowledgment.
    327 
    328 ===== Acknowledgment =====
     319comunicate dalle stazioni interne alla comunicazione. Il campo `Duration/ID` e'
     320quindi presente sia nella coppia iniziale < RTS , CTS > che nelle successive
     321coppie < PDU , ACK > diverse dalla prima; esso contiene la distanza temporale al
     322termine della comunicazione, i.e. il primo ''acknowledgment''.
     323
     324===== ''Acknowledgment'' =====
    329325,,20061027-0445 SoujaK,,[[BR]]
    330326La strategia usata e' l'acknowledgment positivo, il che significa che la STA
    331327ricevente ha il compito di confermare alla STA trasmittente la corretta
    332328ricezione del frame (solo in caso di frame unicast, come e' facile intuire). Il
    333 trasmittente attende il frame ACK per un periodo di tempo fissato da ACKTimeout
    334 e poi conclude che la trasmissione e' fallita. Lo stesso succede qualora esso
    335 riceva altro che non sia un ACK. Si noti che la mancata ricezione dell'ACK puo'
    336 indistinguibilmente indicare anche un errore durante la trasmissione dello
    337 stesso ''acknowledgment''.
    338 
    339 ===== Interframe space (IFS) =====
     329trasmittente attende il frame ACK per un periodo di tempo fissato da
     330`ACKTimeout` e poi conclude che la trasmissione e' fallita. Lo stesso succede
     331qualora esso riceva altro che non sia un ACK. Si noti che la mancata ricezione
     332dell'ACK puo' indistinguibilmente indicare anche un errore durante la
     333trasmissione dello stesso ''acknowledgment''.
     334
     335===== ''Interframe space'' (IFS) =====
    340336,,20061019-0849 SoujaK,,[[BR]]
    341337Lo standard stabilisce la lunghezza di tempo che deve intercorrere fra le
    … …  
    346342
    347343A seconda della situazione viene usato uno dei seguenti 4 periodi:
    348  1. SIFS (short interframe space):
     344 1. SIFS (''short interframe space''):
    349345    usato per frame ACK, CTS, per frame (eccetto il primo) di una
    350346    trasmissione frammentata, per le risposte al ''polling'' del PCF;
    351  2. PIFS (PCF interframe space):
     347 2. PIFS (PCF ''interframe space''):
    352348    usato solo dalle STA che, sotto un PCF, tentano di avere accesso al mezzo
    353349    trasmissivo all'inizio del CFP;
    354  3. DIFS (DCF interframe space):
    355     usato sotto DCF dalle STA per i frame dati (MPDU) o per i frame di gestione
    356     (MMPDU);
    357  4. EIFS (extented interframe space):
    358     usato quando il PHY indica al MAC che l'ultimo frame MAC non e' stato
     350 3. DIFS (DCF ''interframe space''):
     351    usato sotto DCF dalle STA per i frame dati (MPDU) o per i ''frame'' di
     352    gestione (MMPDU);
     353 4. EIFS (''extented interframe space''):
     354    usato quando il PHY indica al MAC che l'ultimo ''frame'' MAC non e' stato
    359355    ricevuto correttamente e che il campo FCS non e' utilizzabile;
    360356
    … …  
    363359In seguito al rilevamento di inattivita'  del mezzo trasmissivo (secondo le
    364360politiche appena descritte), ogni STA e' tenuta a ritardare ulteriormente la
    365 propria trasmissione per un periodo di backoff di durata casuale, a meno che non
    366 sia gia'  stato impostato il relativo timer. L'intento e' quello di evitare che
    367 tutte le STA in attesa collidano nel momento in cui contemporaneamente
     361propria trasmissione per un periodo di ''backoff'' di durata casuale, a meno che
     362non sia gia' stato impostato il relativo timer. L'intento e' quello di evitare
     363che tutte le STA in attesa collidano nel momento in cui contemporaneamente
    368364effettuino tentativi di trasmissione.[[BR]]
    369365Il periodo di inattivita' che le STA si auto-impongono e' detto CW (''contention
    … …  
    381377SLRC) non andati a buon fine: questi vengono inizializzati a 0 e vengono
    382378incrementati con l'andamento andamento esponenziale del 2 ogni volta che la
    383 comunicazione fallisce. Supponendo CWmin e CWmax settati rispettivamente a 7 e a
    384 255, un esempio di incremento esponenziale e' dato dalla sequenza 7, 15, 31, 63,
    385 127, 255, 255. Un cosi' alto andamento di crescita del periodo di backoff rende
    386 piu' stabile il protocollo, aumentando la sua capacita'  di adeguarsi
     379comunicazione fallisce. Supponendo `CWmin` e `CWmax` settati rispettivamente a 7
     380e a 255, un esempio di incremento esponenziale e' dato dalla sequenza 7, 15, 31,
     38163, 127, 255, 255. Un cosi' alto andamento di crescita del periodo di backoff
     382rende piu' stabile il protocollo, aumentando la sua capacita'  di adeguarsi
    387383repentinamente a condizioni di alto carico per poi saperle sopportare con
    388384maggiore facilita' .
    … …  
    401397inserito un campo di controllo di sequenza all'interno nei frame dati e in
    402398quelli di gestione, contenente il numero della sequenza e quello del frammento.
    403 Ogni STA mantiene dunque una cache delle triple <indirizzo, numero di sequenza,
    404 numero di frammento> che permette di identificare agilmente i frame duplicati.
     399Ogni STA mantiene dunque una cache delle triple <indirizzo , numero di sequenza
     400, numero di frammento> che permette di identificare agilmente i frame duplicati.
    405401Il numero di sequenza e' un intero progressivo che __tende__ ad essere unico fra
    406402i vari frame: qualora (sfortunatamente) capitasse il contrario, il frame valido
    … …  
    413409regole imposte dal PC residente nell' ''access-point''. Ogni stazione deve
    414410sottostare obbligatoriamente ai dettami del coordinatore impostando
    415 adeguatamente il proprio NAV [###todolink] all'inizio di ogni CFP. Durante
    416 questi periodi, essendo la comunicazione strettamente regolata dal PC, le
    417 comunicazioni non necessitano dello scambio iniziale dei ''frame'' RTS/CTS.
     411adeguatamente il proprio [wiki:CollegamentoMancante NAV] all'inizio di ogni CFP.
     412Durante questi periodi, essendo la comunicazione strettamente regolata dal PC,
     413le comunicazioni non necessitano dello scambio iniziale dei ''frame'' RTS/CTS.
    418414Questa e' una possibilita' offerta soltanto alle stazioni che implementano PCF,
    419415una funzionalita', ricordiamolo, opzionale.
    … …  
    431427possibilita' di operare ritrasmissioni di frame non confermati (di cui, cioe',
    432428non ha ricevuto l'ACK) dopo un periodo di ''backoff'' di lunghezza temporale
    433 pari a PIFS [###todolink].
     429pari a [wiki:CollegamentoMancante PIFS].
    434430
    435431===== Struttura e tempistiche con PCF =====
    … …  
    451447dei Beacon, dal momento che essi contengono anche un campo "''CFPDurRemaining''"
    452448che (come il nome suggerisce) indica il tempo rimanente alla fine del periodo
    453 libero dalla contesa, espresso in TU [###todolink?]. In ogni caso la durata
    454 del CFP e' al piu' pari al valore inizialmente dichiarato dal PC, quindi va
    455 precisato che, qualora la trasmissione dei ''frame Beacon'' iniziale venga
    456 ritardata (rispetto al TBTT [###todolink]) a causa dell'alto carico del mezzo
    457 trasmissivo, il CFP puo' essere terminato anticipatamente di una quantita' di
    458 tempo pari al ritardo.
     449libero dalla contesa, espresso in [wiki:CollegamentoMancante TU]. In ogni caso
     450la durata del CFP e' al piu' pari al valore inizialmente dichiarato dal PC,
     451quindi va precisato che, qualora la trasmissione dei ''frame Beacon'' iniziale
     452venga ritardata (rispetto al [wiki:CollegamentoMancante TBTT]) a causa dell'alto
     453carico del mezzo trasmissivo, il CFP puo' essere terminato anticipatamente di
     454una quantita' di tempo pari al ritardo.
    459455
    460456===== Procedura di accesso del PCF =====
    … …  
    496492Ogni stazione (fatta eccezione per il PC) e' tenuto a preimpostare il  il
    497493proprio NAV con frequenza dettata dal TBTT (''target beacon trasmission time'')
    498 e con il valore del parametro CFPMaxDuration contenuto nei ''frame beacon''. Le
    499 varie STA potranno settare in maniera piu' accurata il NAV soltanto in seguito,
    500 utilizzando il parametro CFPDurRemaining presente nei ''frame beacon''. E'
    501 fondamentale notare che, al fine di gestire la sovrapposizione delle BSS le
     494e con il valore del parametro `CFPMaxDuration` contenuto nei ''frame beacon''.
     495Le varie STA potranno settare in maniera piu' accurata il NAV soltanto in
     496seguito, utilizzando il parametro CFPDurRemaining presente nei ''frame beacon''.
     497E' fondamentale notare che, al fine di gestire la sovrapposizione delle BSS le
    502498stazioni diverse dal PC prenderanno in considerazione anche i ''beacon''
    503499provenienti da BSS diverse dalla propria.
    504500
    505501===== Procedura di trasferimento =====
    506 ###todosection
    507 
     502__DA FARE__
     503
     504----
    508505
    509506== Gestione degli strati ==
    … …  
    536533}}}
    537534
    538 
    539535In generale il livello MAC, come ovvio, deve essere il piu' possibile
    540536indipendente da quello fisico anche se a volte e' necessario che il livello MAC
    … …  
    542538
    543539Il livello PHY viene suddiviso nella seguente maniera:
    544  * PLCP (Physical Layer Convergence Procedure): funzioni di convergenza del
    545    livello fisico (adattamento del medium a PHY service), che realizzano una
     540 * PLCP (''Physical Layer Convergence Procedure''): funzioni di convergenza del
     541   livello fisico (adattamento del mezzo ai servizi PHY), che realizzano una
    546542   traduzione al fine di rendere l'interfaccia comune;
    547  * PMD (Physical Medium Dependent): insieme di funzioni fortemente dipendenti
    548    dallo specifico dispositivo wireless (ad esempio richieste di trasmissione o
    549    ricezione di dati).
     543 * PMD (''Physical Medium Dependent''): insieme di funzioni fortemente
     544   dipendenti dallo specifico dispositivo wireless (ad esempio richieste di
     545   trasmissione o ricezione di dati).
    550546
    551547Anche in questo caso le relazioni con l'esterno sono gestite da appositi
    … …  
    555551=== Primitive di gestione generica ===
    556552Le informazioni specifiche per la gestione di ogni strato sono incapsulate
    557 all'interno di cio' che viene definita Management Information Base (MIB) che
     553all'interno di cio' che viene definita ''Management Information Base'' (MIB) che
    558554puo' essere visto come un componente di ogni livello. In accordo con questo,
    559 ogni Management Entity possiede specifiche primitive di GET e SET in
     555ogni ''Management Entity'' possiede specifiche primitive di `GET` e `SET` in
    560556grado di operare sugli attributi della relativa MIB. Informazioni dettagliate
    561557sugli attributi dei vari MIB sono presenti nel
    … …  
    573569 * RESET: azzeramento
    574570 * START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete
    575    ad-hoc)
     571   ''ad-hoc'')
    576572
    577573  ,,20061019-0920 SoujaK: La revisione G del documento non introduce nessun
    … …  
    586582 * RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato
    587583   di ricezione;
    588  * CHARACTERISTICS.request: ritorna le caratteristiche operative della PHY
    589    entity;
    590  * CHARACTERISTICS.confirm: viene sollevata dalla PHY entity successivamente
     584 * CHARACTERISTICS.request: ritorna le caratteristiche operative della
     585   entita' PHY;
     586 * CHARACTERISTICS.confirm: viene sollevata dal'entita' PHY successivamente
    591587   ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative
    592    della PHY entity;
    593  * DSSSTESTMODE.request: utile per entrare in modalita'  test in una PHY DSSS
    594    entity;
    595  * DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una PHY
    596    DSSS entity.
    597 
     588   dell'entita' PHY;
     589 * DSSSTESTMODE.request: utile per entrare in modalita' test in una entita' PHY
     590   di tipo DSSS;
     591 * DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una
     592   entita' PHY di tipo DSSS.
    598593
    599594=== Interfaccia di PHY: PHY SAP ===
    … …  
    656651   eventuali errori occorsi.
    657652
     653----
     654
    658655== Specifiche per il livello PHY ==
    659656=== FHSS ===
    … …  
    679676dettata dal livello MAC: ogni beacon e ogni frame ''Probe Response'' contengono
    680677le informazioni necessarie per la sincronizzazione e per la determinazione del
    681 pattern di ''hopping''. [[BR]]
     678pattern di ''hopping''.
    682679
    683680Alcune informazioni sulle tempistiche riguardanti i canali:
    … …  
    686683 * 19ms e' il tempo consigliato di permanenza sul canale.
    687684
    688 
    689685=== OFDM ===
    690 ,,20061028-???? gnappo,, [[BR]]
     686,,20061028 gnappo,, [[BR]]
    691687OFDM (Ortogonal Division Frequency Multiplexing) viene introdotto con la
    692688revisione a dello standard 802.11. I data-rate forniti sono: 6, 9, 12, 18,
    … …  
    705701
    706702=== DSSS ===
    707 ,,20061021-???? gnappo,, [[BR]]
     703,,20061021 gnappo,, [[BR]]
    708704DSSS (Direct Sequence Spread Spectrum) e' un'altra specifica del livello fisico
    709705che permette di raggiungere in linea teorica un capacita'  trasmissiva pari a
    … …  
    717713l'header del frame sono trasmessi, diversamente dal resto, ad un 1Mbit/s per
    718714assicurarsi che l'interlocutore capisca effettivamente questa parte essenziale
    719 della comunicazione. L'effettivo invio del payload (MPDU) potra'  essere
    720 compiuto con modulazioni diverse opportunamente specificate nell'header (campo
    721 SIGNAL).
     715della comunicazione. L'effettivo invio del ''payload'' (MPDU) potra'  essere
     716compiuto con modulazioni diverse opportunamente specificate nell' ''header''
     717(campo SIGNAL).
    722718
    723719==== Algoritmo di trasmissione ====
    724 ,,20061021-???? gnappo,, [[BR]]
     720,,20061021 gnappo,, [[BR]]
    725721Per trasmettere i dati, PHY-TXSTART.request dev'essere abilitata per portare PHY
    726722nello stato di trasmettitore (precedentemente su ricevitore). Il canale su cui
    … …  
    734730
    735731==== Algoritmo di ricezione ====
    736 ,,20061021-???? gnappo,, [[BR]]
    737 Per quanto riguarda la ricezione e' necessario che l'entita' fisica sia nello
     732,,20061021 gnappo,, [[BR]]
     733Per quanto riguarda la ricezione, e' necessario che l'entita' fisica sia nello
    738734stato di ricevitore (quindi PHY-TXSTART disabilitato). Attraverso la PLME e'
    739 possibile scegliere il canale su cui ascoltare ed il metodo di CCA (Clear
    740 Channel Assessment). Altri parametri (come per la trasmissione) sono passati
     735possibile scegliere il canale su cui ascoltare ed il metodo di CCA (''Clear
     736Channel Assessment''). Altri parametri (come per la trasmissione) sono passati
    741737attraverso PHY-SAP.
    742 Non appena il dispositivo ha rilevato attivita'  sul canale sul quale e' in
     738Non appena il dispositivo ha rilevato attivita' sul canale sul quale e' in
    743739ascolto, PHY invoca la primitiva PHY-CCA.indicate con la quale informa MAC che
    744740il canale e' BUSY. Dopodiche' PHY va alla ricerca di un delimitatore di inizio
    … …  
    749745campo SERVICE). I dati successivamente ricevuti saranno assemblati e
    750746presentati a MAC attraverso la primitiva PHY-DATA.indicate(DATA). Al termine
    751 dell'intera ricezione lo stato del ricevitore ritornera'  IDLE e la primitiva
    752 PHY-RXEND.indicate(NoError) sara'  sollevata.
    753 Se la ricezione non andasse a buon fine, PHY informerebbe MAC attraverso la
    754 primitiva PHY-RXEND.indicate della causa dell'errore (e.g. !CarrierLost).
     747dell'intera ricezione lo stato del ricevitore ritornera' IDLE e sara'
     748sollevata la primitiva PHY-RXEND.indicate(NoError). Se la ricezione non andasse
     749a buon fine, PHY informerebbe MAC attraverso la primitiva PHY-RXEND.indicate
     750della causa dell'errore (e.g. !CarrierLost).
    755751
    756752==== Note sulla modulazione ====
    … …  
    812808Rimaniamo comunque nella ricerca di specifiche piu' recentemente rilasciate,
    813809lasciando quest'ultima parte di paragrafo come "prossima ad essere aggiornata".
     810
     811----
    814812
    815813== Formato dei frame MAC ==
    … …  
    909907tutti i campi del ''MAC header'' e sul ''frame body''.
    910908
    911 
    912909=== Alcune note sui frame di management ===
    913910,,20061111-1735 gnappo,, [[BR]]
    … …  
    939936 * ''deauthentication'': ragione della richiesta di disautenticazione.
    940937
     938----
     939
    941940== Management del sottolivello MAC ==
    942 
    943941Uno degli aspetti piu' importanti, per quanto riguarda la connessione di piu'
    944942host ad una rete wireless, e' sicuramente il meccanismo di sincronizzazione, il
    … …  
    968966
    969967=== Acquisizione della sincronizzazione mediante scansione ===
    970 
    971968Ogni stazione (o nodo) puo' operare attraverso due modalita' di scansione: la
    972969modalita' passiva o la modalita' attiva. In modalita' di scansione passiva la
    … …  
    988985
    989986=== Associazione e riassociazione di una stazione con un AP ===
    990 
    991987L'associazione tra una stazione e un AP avviene in due fasi:
    992988 * autenticazione
    … …  
    10351031
    10361032=== ''Power Management'' in un IBSS ===
    1037 
    10381033In un IBSS le stazioni devono essere tutte sincronizzate al fine di poter
    10391034trasmettere i dati; quando i dati sono bufferizzati e pronti per essere spediti
    … …  
    11591154   segreta da esso.
    11601155
     1156----
    11611157
    11621158== Appunti vari ==