Changes between Version 10 and Version 11 of Protocollo
- Timestamp:
- Nov 9, 2006, 10:01:49 AM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Protocollo
v10 v11 1 1 = Analisi dello standard IEEE 802.11 = 2 2 [[PageOutline(1-6,Indice dei contenuti)]] 3 3 4 == Descrizione funzionale del sottolivello MAC == 4 5 Sommario degli argomenti presenti: … … 15 16 L'accesso al mezzo di trasmissione comune e' regolato da una strategia che e' 16 17 detta CSMA/CA (i.e. ''carrier sense multiple access with collision avoidance'') 17 che intende minimizzare le probabilita' di collisione. 18 che intende minimizzare le probabilita' di collisione. Due modalita' di 19 coordinamento, una [wiki:Studio#Coordinamentodistribuito 18 20 19 21 La funzionalita' di coordinamento distribuito (Distributed Coordination Function 20 o, piu' brevemente, DCF) che si fa carico della cosae' pertanto componente22 o, piu' brevemente, DCF) si fa carico della cosa ed e' pertanto componente 21 23 necessario di ogni stazione, sia che essa operi all'interno di reti configurate 22 24 in modalita' ''infrastracture'' che ''ad-hoc''. E' inoltre presente un metodo di … … 28 30 seguito da un periodo di contesa (Contention Period o CP). 29 31 30 ==== DCF ==== 32 ==== Coordinamento distribuito (DCF) ==== 33 31 34 ===== CSMA/CA e il meccanismo RTS/CTS ===== 32 ,,20061018-2031 SoujaK,,[[BR]] 33 Il concetto chiave su cui si basa il protocollo di comunicazione CSMA/CA e' la 34 distribuzione di informazioni di prenotazione del mezzo trasmissivo. I noti 35 frame RTS e CTS contengono infatti un campo (Duration/ID) che contiene il tempo 36 durante il quale il mezzo e' riservato per l'invio del frame (o del frammento) e 37 per la ricezione dell'ACK. Le STA esterne alla comunicazione imparano, tramite 38 questo meccanismo, che il canale e' occupato per tale lasso di tempo evitando le 39 collisioni, anche le STA sono all'interno del raggio d'azione del ricevente, ma 40 non del trasmittente (problema del nodo esposto). E' importante precisare che il 41 meccanismo RTS/CTS non e' obbligatorio: deve essere evitato per trasmissioni 42 multicast o broadcast (chi risponderebbe con il CTS?). Inoltre puo' essere 43 evitato nel caso di frame piccoli (al fine di limitare l'overhead che si 44 introduce): la soglia e' definita nell'attributo dot11RTSThreshold. 35 ,,20061027-1950 SoujaK,,[[BR]] 36 Il concetto chiave attraverso il quale il protocollo interpreta il meccanismo di 37 comunicazione CSMA/CA e' la distribuzione di informazioni di prenotazione del 38 mezzo trasmissivo. Ogni comunicazione fra un nodo sorgente e un nodo 39 destinazione deve cominciare con lo scambio di due frame RTS (request to send) e 40 CTS (clear to send) dalla seguente semantica: "richiesta di invio" e "pronto 41 alla ricezione". Tali frame RTS e CTS contengono un campo (Duration/ID) che 42 contiene il tempo durante il quale il mezzo e' riservato per l'invio del frame 43 (o del frammento) e per la ricezione dell'ACK. Le STA esterne alla comunicazione 44 imparano, tramite questo meccanismo, che il canale e' occupato per tale lasso di 45 tempo evitando le collisioni. La doppia presenza delle informazioni in questione 46 nei due versi della comunicazione (sia nei frame RTS che in CTS, ad esempio) 47 permette di ragiungere tutte le STA interessate, scongiurando alcuni problemi, 48 come quello del nodo esposto). E' importante precisare che il meccanismo RTS/CTS 49 non e' obbligatorio: deve essere evitato per trasmissioni multicast o broadcast 50 (chi risponderebbe con il CTS?). Inoltre puo' essere evitato nel caso di frame 51 piccoli (al fine di limitare l'overhead che si introduce): la soglia e' definita 52 nell'attributo MAC denominato `dot11RTSThreshold`. 45 53 46 54 ===== ''Carrier-sense'' virtuale e il NAV ===== … … 55 63 necessari alle fasi della comunicazione: la trasmissione dei vari frame di dati, 56 64 degli [wiki:Studio#Acknoledgment acknoledgment] e l'attesa dei vari 57 [wiki:Studio#InterframespaceIFSspaceIFS IFS]. 58 Le citate informazioni necessarie alle stazioni estranee alla comunicazione sono 59 o prefissate dallo standard (la durata di invio di un ACK o i tempi inter-frame) 60 oppure sono comunicate dalle stazioni interne alla comunicazione. Il campo 61 Duration/ID e' quindi presente sia nella coppia iniziale < RTS e CTS > che nelle 62 successive coppie < PDU e ACK > diverse dalla prima; esso contiene la distanza63 temporale al termine dellacomunicazione, i.e. il primo acknoledgment.65 [wiki:Studio#InterframespaceIFSspaceIFS IFS]. Le citate informazioni necessarie 66 alle stazioni estranee alla comunicazione sono o prefissate dallo standard (la 67 durata di invio di un ACK o i tempi inter-frame) oppure sono comunicate dalle 68 stazioni interne alla comunicazione. Il campo Duration/ID e' quindi presente sia 69 nella coppia iniziale < RTS e CTS > che nelle successive coppie < PDU e ACK > 70 diverse dalla prima; esso contiene la distanza temporale al termine della 71 comunicazione, i.e. il primo acknoledgment. 64 72 65 73 ===== Acknoledgment ===== … … 68 76 ricevente ha il compito di confermare alla STA trasmittente la corretta 69 77 ricezione del frame (solo in caso di frame unicast, come e' facile intuire). Il 70 trasmittente attende il frame ACK per un periodo di tempo fissato da 71 ACKTimeout e poi conclude che la trasmissione e' fallita. Lo stesso succede 72 qualora esso riceva altro che non sia un ACK. Si noti che la mancata ricezione 73 dell'ACK puo' indistinguibilmente indicare anche un errore durante la 74 trasmissione dellostesso acknoledgment.78 trasmittente attende il frame ACK per un periodo di tempo fissato da ACKTimeout 79 e poi conclude che la trasmissione e' fallita. Lo stesso succede qualora esso 80 riceva altro che non sia un ACK. Si noti che la mancata ricezione dell'ACK puo' 81 indistinguibilmente indicare anche un errore durante la trasmissione dello 82 stesso acknoledgment. 75 83 76 84 ===== Interframe space (IFS) ===== … … 94 102 4. EIFS (extented interframe space): 95 103 usato quando il PHY indica al MAC che l'ultimo frame MAC non e' stato 96 ricevuto cor ettamente e che il campo FCS non e' utilizzabile;104 ricevuto correttamente e che il campo FCS non e' utilizzabile; 97 105 98 106 ===== Random backoff time ===== … … 158 166 totalmente fuori posto.'' 159 167 {{{ 160 Il periodo di inattivita' che le STA si autoimpongono e' detto CW (contention window) 161 e viene ripetuto ogni volta che si presenti una collisione. Viene inoltre incrementato 162 a fronte di ogni collisione con andamento esponenziale (per scongiurare il pericolo 163 di fino al raggiungimento di un valore massimo prestabilito. 168 Il periodo di inattivita' che le STA si autoimpongono e' detto CW (contention 169 window) e viene ripetuto ogni volta che si presenti una collisione. Viene 170 inoltre incrementato a fronte di ogni collisione con andamento esponenziale (per 171 scongiurare il pericolo di fino al raggiungimento di un valore massimo 172 prestabilito. 164 173 }}} 165 174 … … 254 263 (e.g. PHY-TXStart.{request,...}). 255 264 256 ,,gnappo:,, ''chiarire meglio tutte le primitive con il loro significato. Sara' utile 265 ,,gnappo:,, ''chiarire meglio tutte le primitive con il loro significato. Sara' 266 utile 257 267 nella comprensione delle specifiche del livello PHY (ad esempio DSSS).'' 258 268 … … 385 395 (8-chip complementary code keying, aka CCK) che vengono spediti alla stessa 386 396 frequenza del DSSS (11 MHz), ottimizzando cosi l'uso della banda del canale. 387 2. sono state aggiunte delle funzionalita' opzionali per aumentare il bandwith, 388 che sono utilizzabili solo se l'hardware e' abbastanza recente da supportarle. [[BR]] 389 Le funzionalità sono le seguenti: 390 * sostituzione del CCK con il packet binary convolutional coding (HR/DSSS/PBCC); 397 2. sono state aggiunte delle funzionalita' opzionali per aumentare il 398 bandwith, 399 che sono utilizzabili solo se l'hardware e' abbastanza recente da 400 supportarle. [[BR]] 401 Le funzionalità sono le seguenti: 402 * sostituzione del CCK con il packet binary convolutional coding 403 (HR/DSSS/PBCC); 391 404 * HR/DSSS/short, ovvero possibilita' di ridurre il preambolo PLCP 392 per aumentare significantemente il transfer data rate, limitando cosi pero' la 393 possibilita' di coesistenza con il DSSS a sole alcune particolari circostanze; 405 per aumentare significantemente il transfer data rate, limitando cosi 406 pero' la 407 possibilita' di coesistenza con il DSSS a sole alcune particolari 408 circostanze; 394 409 * inserimento del Channel Agility, ovvero una particolare implementazione 395 che consente di superare diversi problemi dovuti all'assegnamento di un canale statico, 396 senza dover aggiungere alla totale implementazione il costo di questa funzionalita'.[[BR]] 397 398 Purtroppo l'IEEE non ha concesso le specifiche inerenti all'evoluzione della modulazione nella versione 399 802.11g, quindi non ci e' concesso sapere i miglioramenti che hanno portato poi il protocollo a 410 che consente di superare diversi problemi dovuti all'assegnamento di un 411 canale statico, 412 senza dover aggiungere alla totale implementazione il costo di questa 413 funzionalita'.[[BR]] 414 415 Purtroppo l'IEEE non ha concesso le specifiche inerenti all'evoluzione della 416 modulazione nella versione 417 802.11g, quindi non ci e' concesso sapere i miglioramenti che hanno portato poi 418 il protocollo a 400 419 supportare velocita' di circa 54 Mbps.[[BR]] 401 Parlandone con il Dott. Bononi, si e' arrivati ad ipotizzare che lo sviluppo sempre + veloce della 402 tecnologia abbia portato ad un'alta precisione e sensibilita' di ricezione/trasmissione che quindi, 403 ha portato ad un'aumento dei simboli (in modulazione un simbolo e' un particolare segnale che identifica 404 una serie di bit) e ad una diminuzione dei bit adibiti al controllo di errori, cosi aumentandone di molto 420 Parlandone con il Dott. Bononi, si e' arrivati ad ipotizzare che lo sviluppo 421 sempre + veloce della 422 tecnologia abbia portato ad un'alta precisione e sensibilita' di 423 ricezione/trasmissione che quindi, 424 ha portato ad un'aumento dei simboli (in modulazione un simbolo e' un 425 particolare segnale che identifica 426 una serie di bit) e ad una diminuzione dei bit adibiti al controllo di errori, 427 cosi aumentandone di molto 405 428 il bit rate potenziale.[[BR]] 406 Rimaniamo comunque nella ricerca di specifiche piu' recentemente rilasciate, lasciando quest'ultima parte 429 Rimaniamo comunque nella ricerca di specifiche piu' recentemente rilasciate, 430 lasciando quest'ultima parte 407 431 di paragrafo come "prossima ad essere aggiornata". 408 432 409 433 == Management del sottolivello MAC == 410 434 411 Uno degli aspetti pi ù importanti, per quanto riguarda la connessione di più412 hosts ad una rete wireless, èsicuramente il meccanismo di sincronizzazione, il435 Uno degli aspetti più importanti, per quanto riguarda la connessione di più 436 hosts ad una rete wireless, Ú sicuramente il meccanismo di sincronizzazione, il 413 437 quale deve esistere per permettere la comunicazione all'interno della rete. 414 Per permettere ci òogni nodo ha al suo interno un TSF (Timing Synchronization438 Per permettere ciò ogni nodo ha al suo interno un TSF (Timing Synchronization 415 439 Function) che funge da orologio per tutti i nodi. 416 La sincronizzazione èpresente sia nei BSS che nei IBSS e avviene in maniere440 La sincronizzazione Ú presente sia nei BSS che nei IBSS e avviene in maniere 417 441 differenti. 418 442 … … 426 450 ad ogni nodo della rete e riceve beacons da tutti gli altri. 427 451 Decide poi autonomamente se settare il proprio timer col valore ricevuto o se 428 scartare il beacon perchè il valore del timetamp all'interno è più vecchio del 452 scartare il beacon perchÚ il valore del timetamp all'interno Ú più vecchio 453 del 429 454 valore del proprio timer. 430 455 431 Il mantenimento della sincronizzazione èdato da un algoritmo:456 Il mantenimento della sincronizzazione Ú dato da un algoritmo: 432 457 ogni nodo mantiene un timer TSF in modulo 2^64^ microsecondi e si aspetta di 433 ricevere un beacon ad intervalli regolari (definiti come ''aBeaconPeriod'', che è 458 ricevere un beacon ad intervalli regolari (definiti come ''aBeaconPeriod'', che 459 Ú 434 460 un parametro del nodo). 435 461 Un nodo che vuole inviare un beacon deve settare il valore del timestamp, che 436 èdato dalla somma tra il valore del TSF al tempo della trasmissione del primo462 Ú dato dalla somma tra il valore del TSF al tempo della trasmissione del primo 437 463 bit del timestamp su PHY e dal tempo di ritardo per la trasmissione (passaggio 438 464 dall'interfaccia MAC-PHY a PHY). … … 440 466 === Acquisizione della sincronizzazione mediante scansione === 441 467 442 Ogni stazione (o nodo) pu ò operare attraverso due modalitàdi scansione:443 la modalit à passiva o la modalitàattiva.444 In modalit àdi scansione passiva la stazione sta in ascolto su tutti i canali468 Ogni stazione (o nodo) può operare attraverso due modalità di scansione: 469 la modalità passiva o la modalità attiva. 470 In modalità di scansione passiva la stazione sta in ascolto su tutti i canali 445 471 e aspetta di ricevere dei beacon in cui il valore SSID sia uguale al valore 446 472 SSID dell'ESS di cui la stazione vuole entrare a fare parte. Una volta ritornati … … 448 474 un BSS, acquisendo tutti i parametri del BSS (timer di sincronizzazione, 449 475 parametri di PHY, BSSID, parametri di trasmissione dei beacon...). 450 La modalit àdi scansione attiva invece si basa sul concetto di Probe Request e476 La modalità di scansione attiva invece si basa sul concetto di Probe Request e 451 477 Probe Response: praticamente una stazione invia un Probe Request e si mette in 452 ascolto di un Probe Response; quando il Probe Response conterr àil SSID cercato453 dalla stazione allora avr à inizio la sincronizzazione e la stazione entreràa454 far parte di un BSS. L'algoritmo di scansione èal cap 11.1.3.2.2 (pag 127 di478 ascolto di un Probe Response; quando il Probe Response conterrà il SSID cercato 479 dalla stazione allora avrà inizio la sincronizzazione e la stazione entrerà a 480 far parte di un BSS. L'algoritmo di scansione Ú al cap 11.1.3.2.2 (pag 127 di 455 481 ieee 802.11-1999). 456 482 … … 462 488 Una volta effettuata l'autenticazione su un AP, la stazione invia una richiesta 463 489 di associazione all'AP e attende la risposta;in caso di risposta affermativa 464 la stazione sarà fisicamente associata all'AP e potrà avviare la comunicazione, 465 in caso contrario la stazione non si potrà associare. 466 Analogamente quando una stazione vorrà riassociarsi ad un AP invierà allo stesso 467 una richiesta di riassociazione e attederà la risposta dall'AP. 490 la stazione sarà fisicamente associata all'AP e potrà avviare la 491 comunicazione, 492 in caso contrario la stazione non si potrà associare. 493 Analogamente quando una stazione vorrà riassociarsi ad un AP invierà allo 494 stesso 495 una richiesta di riassociazione e attederà la risposta dall'AP. 468 496 Naturalmente quando un AP riceve una richiesta di associazione controlla che la 469 stazione che ha inviato tale richiesta sia autenticata su s èstesso; in caso470 affermativo l'AP invier àuna risposta (positiva o negativa) alla stazione.497 stazione che ha inviato tale richiesta sia autenticata su sÚ stesso; in caso 498 affermativo l'AP invierà una risposta (positiva o negativa) alla stazione. 471 499 472 500 === Power Management === … … 475 503 preventivamente l'AP al quale sono associate, accondando la richiesta di cambio 476 504 al campo Frame Control del frame inviato all'AP. 477 L'AP deve tener traccia di tutte le stazione che operano in modalit àpower save505 L'AP deve tener traccia di tutte le stazione che operano in modalità power save 478 506 in quanto la trasmisisone dei dati a tali stazioni deve avvenire in modo 479 differente rispetto alle stazioni che non operano in tale modalit à;infatti un480 AP non pu ò trasmettere i dati in maniera arbitraria alle stazioni in modalità507 differente rispetto alle stazioni che non operano in tale modalità ;infatti un 508 AP non può trasmettere i dati in maniera arbitraria alle stazioni in modalità 481 509 power save ma deve bufferizzarli e trasmetterli in periodi precisi. 482 510 Tutte le stazioni che ricevono dati bufferizzati dall'AP sono riunite nel … … 484 512 generati dall'AP stesso.Ogni stazione per sapere se i dati ricevuti sono stati 485 513 bufferizzati per lei deve ricevere e interpretare il TIM associato al beacon ( 486 per fare ci òogni stazione si mette peridicamente in ascolto di beacon,e quindi514 per fare ciò ogni stazione si mette peridicamente in ascolto di beacon,e quindi 487 515 in ascolto per ricevere eventuali TIM,secondo opportune funzioni). 488 In un BSS ogni stazione (in modalit àpower save) per sapere se dei dati sono516 In un BSS ogni stazione (in modalità power save) per sapere se dei dati sono 489 517 stati correttamente bufferizzati invia un PS-Poll frame all'AP, il quale 490 risponder ào inviando direttamente i dati bufferizzati o acknowleggiando la518 risponderà o inviando direttamente i dati bufferizzati o acknowleggiando la 491 519 richiesta e inviando i dati successivamente. 492 520 493 Ogni stazione pu ò lavorare in due modalità:521 Ogni stazione può lavorare in due modalità : 494 522 * awake 495 523 * doze 496 524 497 Nella modalit à awake la stazione lavora a piena potenza e puòricevere frames498 in qualsiasi momento; è detta anche modalitàattiva.499 Nella modalit àdoze la stazione lavora in power save e riceve frames attraverso525 Nella modalità awake la stazione lavora a piena potenza e può ricevere frames 526 in qualsiasi momento;Ú detta anche modalità attiva. 527 Nella modalità doze la stazione lavora in power save e riceve frames attraverso 500 528 il meccanismo sopra descritto. 501 Naturalmente le stazioni possono passare da una modalit àall'altra,ma possono529 Naturalmente le stazioni possono passare da una modalità all'altra,ma possono 502 530 farlo solo alla fine di uno scambio di dati informando l'AP del cambio. 503 531 … … 507 535 trasmettere i dati;quando i dati sono bufferizzati e pronti per essere spediti 508 536 ad una stazione in power save ci deve essere un annuncio tra tutte le stazioni 509 affinch èl'operazione si possa effettuare.510 Tale annuncio èdato tramite l'invio di un ATIM (Ad hoc TIM) quando tutte le511 stazioni dell' IBSS sono in modalit àawake.537 affinchÚ l'operazione si possa effettuare. 538 Tale annuncio Ú dato tramite l'invio di un ATIM (Ad hoc TIM) quando tutte le 539 stazioni dell' IBSS sono in modalità awake. 512 540 Quando i dati devono essere transmessi la stazione trasmittente invia prima 513 un frame ATIM nel ATIM Window (che èun periodo nel quale vengono inviati solo514 frame ATIM o beacon) e aspetta l'ack di quel frame;se ci ònon avviene la541 un frame ATIM nel ATIM Window (che Ú un periodo nel quale vengono inviati solo 542 frame ATIM o beacon) e aspetta l'ack di quel frame;se ciò non avviene la 515 543 stazione attiva la procedura di ritrassmisione dell'ATIM. 516 544 Una stazione che acknowleggia l'ATIM durante l'ATIM Window deve rimanere nella 517 modalit à awake e aspettare l'annuncio.Una volta che avviane l'ack ed èpassato518 l'ATIM Window,i dati possono essere trasmessi dalla stazione in modalit à545 modalità awake e aspettare l'annuncio.Una volta che avviane l'ack ed Ú passato 546 l'ATIM Window,i dati possono essere trasmessi dalla stazione in modalità 519 547 power save. 520 548 … … 523 551 ,,20061014-1305 Roma,,[[BR]] 524 552 Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi 525 è praticamente una serie di richieste tra il client e l'AP affinchèla526 connessione venga instaurata; nota importante èche il client prima di553 Ú praticamente una serie di richieste tra il client e l'AP affinchÚ la 554 connessione venga instaurata; nota importante Ú che il client prima di 527 555 collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP 528 556 manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova 529 connessione. Naturalmente vi sono gi àdelle primitive implementate atte a557 connessione. Naturalmente vi sono già delle primitive implementate atte a 530 558 svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che 531 559 per le reinstaurazione). 532 560 Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro 533 (es che fece anche il seminarista se non ricordo male) e per fare ci òsi561 (es che fece anche il seminarista se non ricordo male) e per fare ciò si 534 562 inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte 535 comunque c' èl'AP che controlla tutta la sincronizzazione ed egli stesso manda536 pancette ai client conessi a lui; quindi vi èuna doppia sincronizzazione: una563 comunque c'Ú l'AP che controlla tutta la sincronizzazione ed egli stesso manda 564 pancette ai client conessi a lui; quindi vi Ú una doppia sincronizzazione: una 537 565 tra AP e client e una tra client e client (cap 11 del documento ieee 802.11).
