Changes between Version 31 and Version 32 of Protocollo


Ignore:
Timestamp:
Dec 18, 2006, 3:58:39 PM (18 years ago)
Author:
soujak
Comment:

Aggiornata la sezione dedicata a PCF

Legend:

Unmodified
Added
Removed
Modified

  • Protocollo

    v31 v32  
    168168
    169169==== Coordinamento centralizzato (PCF) ====
    170 ,,20061207-1931 SoujaK,,[[BR]]
     170,,20061210-1651 SoujaK,,[[BR]]
    171171La PCF fornisce un metodo di trasmissione dei ''frame'' che e' libero dalla
    172172contesa (e quindi anche dagli sprechi di tempo che essa comporta), grazie alle
    173173regole imposte dal PC residente nell' ''access-point''. Ogni stazione deve
    174174sottostare obbligatoriamente ai dettami del coordinatore impostando
    175 adeguatamente il loro NAV [###todolink] all'inizio di ogni periodo da esso
    176 regolato, i.e. CFP. Durante questi periodi, essendo la comunicazione
    177 strettamente regolata dal PC, le comunicazioni non necessitano dello scambio
    178 iniziale dei ''frame'' RTS/CTS. Questa e' una possibilita' offerta soltanto
    179 alle stazioni che implementano PCF, una funzionalita', ricordiamolo, opzionale.
     175adeguatamente il proprio NAV [###todolink] all'inizio di ogni CFP. Durante
     176questi periodi, essendo la comunicazione strettamente regolata dal PC, le
     177comunicazioni non necessitano dello scambio iniziale dei ''frame'' RTS/CTS.
     178Questa e' una possibilita' offerta soltanto alle stazioni che implementano PCF,
     179una funzionalita', ricordiamolo, opzionale.
    180180
    181181Affinche' il coordinatore possa conoscere quali stazioni sono accessibili in
    … …  
    184184inoltre la chiave di volta su cui questa modalita' di cooordinamento si fonda;
    185185infatti le stazioni ''CF-pollable'' hanno occasione di spedire secondo una
    186 strategia di ''piggyback'', una (e una sola) MPDU assieme all' ''ackowledgment''.
     186strategia di ''piggyback'', una (e una sola) MPDU assieme all'
     187''acknowledgment''.[[BR]]
    187188Se tale invio fallisce il ''frame'' non potra' essere ritrasmesso subito, ma la
    188189stazione interessata dovra' attendere il prossimo segnale di ''poll'' dal
    … …  
    193194
    194195===== Struttura e tempistiche con PCF =====
    195 ,,20061207-1931 SoujaK,,[[BR]]
     196,,20061210-1817 SoujaK,,[[BR]]
    196197Come gia' anticipato i periodi liberi dalla contesa (CFP), in cui la
    197198trasmissione e' coordinata da PCF, si alternano temporalmente a periodi di
    … …  
    218219
    219220===== Procedura di accesso del PCF =====
    220 ,,20061207-1931 SoujaK,,[[BR]]
     221,,20061210-1931 SoujaK,,[[BR]]
    221222Il protocollo di trasmissione libero da contesa e' basato su uno schema di
    222223''polling'' attuato dal coordinatore che opera nel' ''access-point'' del BSS.
    … …  
    225226per intervalli di tempo minori rispetto a quelli di ogni stazione operante
    226227tramite DCF. In generale tutte le stazioni diverse dal PC che sono presenti nel
    227 BSS setteranno il loro NAV in accordo con il valore del parametro
     228BSS setteranno il loro NAV in acordo con il valore del parametro
    228229''CFPMaxDuration'' comunicato dal coordinatore. Per minimizzare il numero di
    229230trasmissioni sono definite dallo standard precisi sequenze con cui concatenare
    230231le informazioni aggregate tramite la pratica del ''piggyback''.
    231232
    232 ====== Accesso fondamentale ======
    233 ###todo
     233====== Accesso di base al mezzo ======
     234,,20061211-1508 SoujaK,,[[BR]]
     235All'inizio nominale di ogni CFP il PC controlla che il mezzo trasmissivo sia
     236inutilizzato per un periodo lungo PIFS. Dopodiche' puo' trasmettere un ''frame
     237Beacon'' contenente il set di parametri dedicati al CF settati in maniera
     238opportuna unitamente ad un elemento DTIM.
     239
     240Dopo la trasmissione iniziale il coordinatore e' tenuto ad attendere almeno per
     241un periodo SIFS, poi puo' cominciare a tramettere un ''frame'' di dati, un
     242''frame'' di tipo ''CF-Poll'', un ''frame'' contenente dati assieme al
     243''CF-Poll'' opppure un ''frame CF-End''. Nel caso in cui il CFP sia di durata
     244nulla, perche' il PC non ha accumulato ne' traffico ne' ''poll'', esso inviera'
     245subito dopo il ''beacon'' il ''frame CF-End''.
     246
     247Le stazioni che ricevono ''frame'' senza errori sono tenute a rispondere dopo un
     248periodo SIFS, in accordo con le procedure che descriveremo piu' avanti
     249[###todolink]. Le STA riceventi che non siano di tipo ''CF-Pollable'',
     250segnaleranno il successo della ricezione con un classico ''frame'' ACK.
     251
    234252====== Uso del NAV ======
    235 ###todo
     253,,20061218-1449 SoujaK,,[[BR]]
     254Le modalita' di gestione del NAV durante i periodi liberi da contesa sono state
     255pensate per consentire la sovrapposizione di piu' BSS di tipo infrastruttura.
     256Ogni stazione (fatta eccezione per il PC) e' tenuto a preimpostare il  il
     257proprio NAV con frequenza dettata dal TBTT (''target beacon trasmission time'')
     258e con il valore del parametro CFPMaxDuration contenuto nei ''frame beacon''. Le
     259varie STA potranno settare in maniera piu' accurata il NAV soltanto in seguito,
     260utilizzando il parametro CFPDurRemaining presente nei ''frame beacon''. E'
     261fondamentale notare che, al fine di gestire la sovrapposizione delle BSS le
     262stazioni diverse dal PC prenderanno in considerazione anche i ''beacon''
     263provenienti da BSS diverse dalla propria.
     264
    236265===== Procedura di traferimento =====
    237 ###todo
     266###todosection
     267
    238268
    239269== Gestione degli strati ==