| 104 | | MAC. Qui il meccanismo e' da considerarsi virtuale, nel senso che interroga il |
| 105 | | Network Allocation Vector. Il NAV tiene traccia delle prenotazioni effettuate |
| 106 | | tramite il meccanismo RTS/CTS che indicano la futura indisponibilita' del |
| 107 | | canale. Le informazioni di prenotazione sono reperibili anche nelle |
| 108 | | intestazioni di ogni frame inviato durante i CP. |
| | 104 | MAC. Qui in MAC il meccanismo e' da considerarsi virtuale, nel senso che |
| | 105 | interroga il Network Allocation Vector. Ogni STA ha il compito di tenere traccia |
| | 106 | nel NAV delle "prenotazioni" effettuate da altri che indicano la futura |
| | 107 | indisponibilita' del canale e, se necessario, rimandare i tentativi di |
| | 108 | trasmissione. Il calcolo di questa durata non e' altro che la somma dei tempi |
| | 109 | necessari alle fasi della comunicazione: la trasmissione dei vari frame di dati, |
| | 110 | degli [wiki:Studio#Acknoledgment acknoledgment] e l'attesa dei vari |
| | 111 | [wiki:Studio#InterframespaceIFSspaceIFS IFS]. |
| | 112 | Le citate informazioni necessarie alle stazioni estranee alla comunicazione sono |
| | 113 | o prefissate dallo standard (la durata di invio di un ACK o i tempi inter-frame) |
| | 114 | oppure sono comunicate dalle stazioni interne alla comunicazione. Il campo |
| | 115 | Duration/ID e' quindi presente sia nella coppia iniziale < RTS e CTS > che nelle |
| | 116 | successive coppie < PDU e ACK > diverse dalla prima; esso contiene la distanza |
| | 117 | temporale al termine della comunicazione, i.e. il primo acknoledgment. |
| 144 | | propria trasmissione per un tempo variabile e casuale. Cosi' facendo si evita |
| 145 | | che tutte le STA in attesa collidano nel momento in cui contemporaneamente |
| 146 | | effettuino ulteriori tentativi di trasmissione. L'algoritmo e la tecnica in |
| 147 | | generale e' descritta esaustivamente nelle specifiche, a cui pertanto rimando, |
| 148 | | qualora si cerchino infomazioni piu' dettagliate. |
| 149 | | |
| 150 | | |
| 151 | | ==== DCF ==== |
| | 156 | propria trasmissione per un periodo di backoff di durata casuale, a meno che non |
| | 157 | sia gia' stato impostato il relativo timer. L'intento e' quello di evitare che |
| | 158 | tutte le STA in attesa collidano nel momento in cui contemporaneamente |
| | 159 | effettuino tentativi di trasmissione.[[BR]] |
| | 160 | Il periodo di backoff e' espresso come quantita' casuale di quanti di tempo (dal |
| | 161 | valore `aSlotTime` presente in PHY). Questa quantita' di slot e' mantenuta in un |
| | 162 | intero pseudocasuale le cui variazioni devono osclillare in maniera |
| | 163 | uniforme fra 0 e CW, un altro parametro definito come intero compreso |
| | 164 | nell'intervallo di estremi `aCWmin` e `aCWmax`(definiti in PHY). Ogni STA |
| | 165 | mantiene inoltre una coppia di contatori dei tentativi di trasmissione (SSRC e |
| | 166 | SLRC) non andati a buon fine: questi vengono inizializzati a 0 e vengono |
| | 167 | incrementati con l'andamento andamento esponenziale del 2 ogni volta che la |
| | 168 | comunicazione fallisce. Supponendo CWmin e CWmax settati rispettivamente a 7 e a |
| | 169 | 255, un esempio di incremento esponenziale e' dato dalla sequenza 7, 15, 31, 63, |
| | 170 | 127, 255, 255. Un cosi' alto andamento di crescita del periodo di backoff rende |
| | 171 | piu' stabile il protocollo, aumentando la sua capacita' di adeguarsi |
| | 172 | repentinamente a condizioni di alto carico per poi saperle sopportare con |
| | 173 | maggiore facilita'.[[BR]] |
| | 174 | I contatori prima citati vengono poi resettati (azzerati) al verificarsi di |
| | 175 | determinati eventi interpretabili come comunicazione ben riuscita (e.g la |
| | 176 | ricezione di un ACK): i due contatori si differenziano proprio su questo |
| | 177 | particolare, ma non e' il caso di approfondire ulteriormente. |
| | 178 | |
| | 179 | ===== Frame duplicati ===== |
| | 180 | ,,20061027-0536 SoujaK,,[[BR]] |
| | 181 | Dal momento che le procedure di conferma di trasmissione e di ritrasmissione |
| | 182 | sono incorporati all'interno del protocollo, esiste la possibilita' che un |
| | 183 | determinato frame venga ricevuto piu' di una volta. La stazione ricevente deve |
| | 184 | rendersi conto della duplicazione e scartare i doppioni. E' stato pertanto |
| | 185 | inserito un campo di controllo di sequenza all'interno nei frame dati e in |
| | 186 | quelli di gestione, contentente il numero della sequenza e quello del frammento. |
| | 187 | Ogni STA mantiene dunque una cache delle tuple <indirizzo, numero |
| | 188 | di sequenza, numero di frammento> che permette di identificare agilmente i |
| | 189 | frame duplicati. Il numero di sequenza e' un intero progressivo che __tende__ ad |
| | 190 | essere unico fra i vari frame: qualora (sfortunatamente) capitasse il contrario, |
| | 191 | il frame valido erroneamente scartato verrebbe presto ritrasmesso dalla |
| | 192 | sorgente. |
| | 193 | |
| | 194 | ==== PCF ==== |
| | 195 | ,,SoujaK: da fare :(,, |
