| 21 | | ,,20061018-1512 SoujaK,,[[BR]] |
| 22 | | L'accesso al mezzo di trasmissione comune e' regolato da una strategia che e' |
| 23 | | detta CSMA/CA (i.e. ''carrier sense multiple access with collision avoidance'') |
| 24 | | che intende minimizzare le probabilita' di collisione. |
| 25 | | |
| 26 | | La funzionalita' di |
| 27 | | [wiki:Protocollo#CoordinamentodistribuitoDCF Coordinamento distribuito] |
| 28 | | (Distributed Coordination Function o, piu' brevemente, DCF) si fa carico della |
| 29 | | cosa ed e' pertanto componente necessario di ogni stazione, sia che essa operi |
| 30 | | all'interno di reti configurate in modalita' ''infrastracture'' che ''ad-hoc''. |
| 31 | | E' inoltre presente un metodo di accesso opzionale, detto |
| 32 | | [wiki:Protocollo#CoordinamentocentralizzatoPCF coordinamento centralizzato] |
| 33 | | che si basa su un coordinatore centrale detto PC (i.e. ''Point Coordinator'') |
| 34 | | che risiede nell'AP del BSS. Poiche' DCF e PCF devono poter coesistere ed |
| 35 | | operare in maniera concorrente all'interno di una BSS, i due metodi di accesso |
| 36 | | si alterneranno, con un periodo in cui l'accesso e' prestabilito e il mezzo |
| 37 | | libero dalla contesa (''Contention-Free Period'' o CFP) seguito da un periodo di |
| 38 | | contesa (''Contention Period'' o CP). |
| | 21 | ,,20061207-1902 SoujaK,,[[BR]] |
| | 22 | L'accesso al mezzo di trasmissione comune deve essere regolato, poiche', per |
| | 23 | sua intrinseca natura non puo` essere utilizzato per trasmissioni simultanee |
| | 24 | sulle stesse frequenze. Per questo motivo il livello MAC comprende funzionalita' |
| | 25 | in grado di farsi carico della coordinazione delle varie stazioni che operano |
| | 26 | sul medesimo canale trasmissivo. Si tratta della |
| | 27 | [wiki:Protocollo#CoordinamentodistribuitoDCF funzione di coordinamento distribuito] |
| | 28 | (piu' brevemente DCF), un componente evidentemente necessario ad ogni stazione, |
| | 29 | in qualsiasi modalita' essa operi, ''infrastracture'' come ''ad-hoc''. |
| | 30 | [[BR]] |
| | 31 | E' inoltre presente un metodo di accesso opzionale, basato sulla |
| | 32 | [wiki:Protocollo#CoordinamentocentralizzatoPCF funzione di coordinamento centralizzato] |
| | 33 | (detto anche PCF) che fa uso di un coordinatore centrale detto PC (i.e. ''Point |
| | 34 | Coordinator'') che risiede nell'AP del BSS. |
| | 35 | |
| | 36 | DCF e PCF devono poter coesistere ed operare in maniera concorrente all'interno |
| | 37 | di una BSS, quindi i due metodi di accesso al mezzo si alterneranno, con un |
| | 38 | periodo in cui l'accesso e' prestabilito e il mezzo libero dalla contesa |
| | 39 | (''Contention-Free Period'' o CFP) in cui il coordinamento e' centralizzato, |
| | 40 | seguito da un periodo di contesa (''Contention Period'' o CP), in cui il |
| | 41 | coordinamento e' distribuito. |
| 170 | | ,,SoujaK: da fare :(,, |
| | 167 | ,,20061207-1931 SoujaK,,[[BR]] |
| | 168 | La PCF fornisce un metodo di trasmissione dei ''frame'' che e' libero dalla |
| | 169 | contesa (e quindi anche dagli sprechi di tempo che essa comporta), grazie alle |
| | 170 | regole imposte dal PC residente nell' ''access-point''. Ogni stazione deve |
| | 171 | sottostare obbligatoriamente ai dettami del coordinatore impostando |
| | 172 | adeguatamente il loro NAV [###todolink] all'inizio di ogni periodo da esso |
| | 173 | regolato, i.e. CFP. Durante questi periodi, essendo la comunicazione |
| | 174 | strettamente regolata dal PC, le comunicazioni non necessitano dello scambio |
| | 175 | iniziale dei ''frame'' RTS/CTS. Questa e' una possibilita' offerta soltanto |
| | 176 | alle stazioni che implementano PCF, una funzionalita', ricordiamolo, opzionale. |
| | 177 | |
| | 178 | Affinche' il coordinatore possa conoscere quali stazioni sono accessibili in |
| | 179 | maniera ottimale durante i CFP, invia un apposito ''poll'', a cui risponderanno |
| | 180 | soltanto le stazioni dotate di tale caratteristica. Questo ''CF-poll'' e' |
| | 181 | inoltre la chiave di volta su cui questa modalita' di cooordinamento si fonda; |
| | 182 | infatti le stazioni ''CF-pollable'' hanno occasione di spedire secondo una |
| | 183 | strategia di ''piggyback'', una (e una sola) MPDU assieme all' ''ackowledgment''. |
| | 184 | Se tale invio fallisce il ''frame'' non potra' essere ritrasmesso subito, ma la |
| | 185 | stazione interessata dovra' attendere il prossimo segnale di ''poll'' dal |
| | 186 | coordinatore, o il prossimo periodo di contesa. Il PC, invece ha la |
| | 187 | possibilita' di operare ritrasmissioni di frame non confermati (di cui, cioe', |
| | 188 | non ha ricevuto l'ACK) dopo un periodo di ''backoff'' di lunghezza temporale |
| | 189 | pari a PIFS [###todolink]. |
| | 190 | |
| | 191 | ===== Struttura e tempistiche con PCF ===== |
| | 192 | ,,20061207-1931 SoujaK,,[[BR]] |
| | 193 | Come gia' anticipato i periodi liberi dalla contesa (CFP), in cui la |
| | 194 | trasmissione e' coordinata da PCF, si alternano temporalmente a periodi di |
| | 195 | contesa (CP) in cui il coordinamento e' gestito secondo DCF. I CFP hanno inizio |
| | 196 | dopo un ''frame Beacon'' contenente un apposito DTIM (Delivery Traffic |
| | 197 | Indication Message, messaggio di indicazione sul traffico della consegna) e |
| | 198 | avranno luogo con frequenze ben definite. Queste frequenze sono espresse come |
| | 199 | quantita' di intervalli DTIM, e sono comunicate dal PC alle altre stazioni |
| | 200 | tramite un campo appartenente ai ''frame Beacon'', nel set dei parametri |
| | 201 | dedicati a CF. |
| | 202 | |
| | 203 | La durata dei CFP e' invece di appannaggio del coordinatore che ha liberta' di |
| | 204 | scelta, purche' essa sia dichiarata preventivamente nel parametro |
| | 205 | ''CFP-MaxDuration'', appartenente al set precedentemente citato. Non e' inoltre |
| | 206 | necessario che la durata del CFP sia multipla dell'intervallo di trasmissione |
| | 207 | dei Beacon, dal momento che essi contengono anche un campo "''CFPDurRemaining''" |
| | 208 | che (come il nome suggerisce) indica il tempo rimanente alla fine del periodo |
| | 209 | libero dalla contesa, espresso in TU [###todolink?]. In ogni caso la durata |
| | 210 | del CFP e' al piu' pari al valore inizialmente dichiarato dal PC, quindi va |
| | 211 | precisato che, qualora la trasmissione dei ''frame Beacon'' iniziale venga |
| | 212 | ritardata (rispettto al TBTT [###todolink]) a causa dell'alto carico del mezzo |
| | 213 | trasmissivo, il CFP puo' essere terminato anticipatamente di una quantita' di |
| | 214 | tempo pari al ritardo. |
| | 215 | |
| | 216 | ===== Procedura di accesso del PCF ===== |
| | 217 | ,,20061207-1931 SoujaK,,[[BR]] |
| | 218 | Il protocollo di trasmissione libero da contesa e' basato su uno schema di |
| | 219 | ''polling'' attuato dal coordinatore che opera nel' ''access-point'' del BSS. |
| | 220 | Durante questo lasso di tempo il PC prima prende il controllo del canale, e poi |
| | 221 | si assicura di mantenterlo. Prima di ogni sua trasmissione, infatti, attende |
| | 222 | per intervalli di tempo minori rispetto a quelli di ogni stazione operante |
| | 223 | tramite DCF. In generale tutte le stazioni diverse dal PC che sono presenti nel |
| | 224 | BSS setteranno il loro NAV in acordo con il valore del parametro |
| | 225 | ''CFPMaxDuration'' comunicato dal coordinatore. Per minimizzare il numero di |
| | 226 | trasmissioni sono definite dallo standard precisi sequenze con cui concatenare |
| | 227 | le informazioni aggregate tramite la pratica del ''piggyback''. |
| | 228 | |
| | 229 | ====== Accesso fondamentale ====== |
| | 230 | ###todo |
| | 231 | ====== Uso del NAV ====== |
| | 232 | ###todo |
| | 233 | ===== Procedura di traferimento ===== |
| | 234 | ###todo |