Studio di fattibilita': associazione multipla simultanea

Abstract

La diffusione di reti wireless e' in forte crescita ed e' stimolato dalla facile disponibilita' di connessioni ad Internet con ampie larghezze di banda anche in ambienti domestici. Non e' infatti raro, specialmente se si abita in una citta' densamente popolata, trovarsi nel raggio di copertura di piu' di una rete wireless. Sfruttare contemporaneamente la connessione alla molteplicita' di reti permetterebbe uno sfruttamento migliore delle risorse disponibili (miglioramento del throughput) e un incremento di affidabilita' (grazie alla ridondanza).
Lo studio intende analizzare le effettive possibilita' di realizzazione di un estensione delle comuni realizzazioni di IEEE 802.11 che permetta al singolo client l'associazione simultanea a differenti reti wireless. Gli scenari che saranno oggetto della ricerca dovranno essere i piu' svariati: le reti potrebbero utilizzare canali diversi o addirittura essere di natura diversa: ad-hoc o ad infrastruttura.

Precisare il concetto di simultaneita' facendo riferimento alla strategia di swinging

Introduzione

Come risulta evidente, l'avvio e l'approccio di questo studio dipende in maniera forte dagli aspetti architetturali del protocollo 802.11. La questione non entra in gioco soltanto nel definire una bozza di implementazione, ma, ancor prima, nel comprendere a livello ideale quali siano le strade da intraprendere per una realizzazione.

Dalle conoscenze iniziali dell'intero gruppo di lavoro e' risultato evidente che la ricerca non poteva perseguire una soluzione che lavorasse al di sopra del livello di astrazione creato dal driver del dispositivo. In questo tipo di scenario si renderebbe necessaria la ri-associazione ad ogni cambio di canale, una operazione che richiede tempi che sono definibili lunghi (o biblici se si considera anche la fase di autenticazione) se comparati ai tempi di trasmissione dei dati. Il che significa che operare anche soltanto una doppia associazione produrrebbe prestazioni inferiori rispetto ad una associazione singola.

Se come riferimento si prende lo stack ISO/OSI, da quanto detto risulta evidente che la ricerca sara' orientata al di sotto del livello Network, nei meandri dello stack IEEE 802.11. Dal momento che la conoscenza dell'argomento e' qualificabile come limitata agli aspetti piu' didattici, risulta evidente che prima di poter proseguire in maniera sensata, si e' ritenuto necessario approfondire la materia. Nei primi tempi si e' quindi cercato di acquisire l'indispensabile padronanza dell'architettura del protocollo e delle interfacce offerte dal livello MAC e da quello PHY.

Wiki

Le potenzialita' offerte dal wiki sono apparse essere un valido appoggio al carattere collaborativo del progetto. Specialmente nelle fasi iniziali di analisi dello standard, ha permesso la divisione degli argomenti e facilitato lo studio stesso e la successiva condivisione delle conoscenze.

---

Analisi dello standard IEEE 802.11

Descrizione funzionale del sottolivello MAC

Sommario degli argomenti presenti:

• DCF
• PCF
• Frammentazione
• Deframmentazione
• Supporto ad ampiezze di banda multiple
• Sequenze consentite per lo scambio di frame
• Restrizioni aggiuntive per limitare il riordino o lo scarto di MSDU

Coordinamento per la trasmissione

_{20061018-1512 SoujaK}
L'accesso al mezzo di trasmissione comune e' regolato da una strategia che e' detta CSMA/CA (i.e. carrier sense multiple access with collision avoidance) che intende minimizzare le probabilita' di collisione.

La funzionalita' di coordinamento distribuito (Distributed Coordination Function o, piu' brevemente, DCF) che si fa carico della cosa e' pertanto componente necessario di ogni stazione, sia che essa operi all'interno di reti configurate in modalita' infrastracture che ad-hoc. E' inoltre presente un metodo di accesso opzionale che si basa su un coordinatore centrale detto PC (i.e. Point Coordinator) che risiede nell'AP del BSS. Poiche' DCF e PCF devono poter coesistere ed operare in maniera concorrente all'interno di una BSS, i due metodi di accesso si alterneranno, con un periodo in cui l'accesso e' prestabilito e il mezzo libero dalla contesa (Contention-Free Period o CFP) seguito da un periodo di contesa (Contention Period o CP).

DCF

Meccanismo RTS/CTS

_{20061018-2031 SoujaK}
Il concetto chiave su cui si basa il protocollo di comunicazione CSMA/CA e' la distribuzione di informazioni di prenotazione del mezzo trasmissivo. I noti frame RTS e CTS contengono infatti un campo (Duration/ID) che contiene il tempo durante il quale il mezzo e' riservato per l'invio del frame (o del frammento) e per la ricezione dell'ACK. Le STA esterne alla comunicazione imparano, tramite questo meccanismo, che il canale e' occupato per tale lasso di tempo evitando le collisioni, anche le STA sono all'interno del raggio d'azione del ricevente, ma non del trasmittente (problema del nodo esposto). E' importante precisare che il meccanismo RTS/CTS non e' obbligatorio: deve essere evitato per trasmissioni multicast o broadcast (chi risponderebbe con il CTS?). Inoltre puo' essere evitato nel caso di frame piccoli (al fine di limitare l'overhead che si introduce): la soglia e' definita nell'attributo dot11RTSThreshold.

Meccanismo carrier-sense

_{20061018-2039 SoujaK}
La funzionalita' permette di capire lo stato del mezzo trasmissivo (occupato o libero) ed e' presente non solo nel sottostrato PHY, come e' ovvio, ma anche in MAC. Qui il meccanismo e' da considerarsi virtuale, nel senso che interroga il Network Allocation Vector. Il NAV tiene traccia delle prenotazioni effettuate tramite il meccanismo RTS/CTS che indicano la futura indisponibilita' del canale. Le informazioni di prenotazione sono reperibili anche nelle intestazioni di ogni frame inviato durante i CP.

Acknoledgment

_{20061018-2045 SoujaK}
La strategia usata e' l'acknoledgment positivo, il che significa che la STA ricevente ha il compito di confermare alla STA trasmittente la corretta ricezione del frame. Si noti che la mancata ricezione dell'ACK puo' indistinguibilmente indicare un errore durante la trasmissione del frame di dati o dell'ACK stesso.

Interframe space (IFS)

_{20061019-0849 SoujaK}
Lo standard stabilisce la lunghezza di tempo che deve intercorrere fra le trasmissioni dei vari frame; lo scopo e' quello di fornire informazioni precise alle stazioni. Queste ultime, attraverso il meccanismo carrier-sense, attendono infatti di poter considerare libero il mezzo trasmissivo a seconda dei periodi di inattivita' rilevati.

A seconda della situazione viene usato uno dei seguenti 4 periodi:

1. SIFS (short interframe space): usato per frame ACK, CTS, per frame (eccetto il primo) di una trasmissione frammentata, per le risposte al polling del PCF;
2. PIFS (PCF interframe space): usato solo dalle STA che, sotto un PCF, tentano di avere accesso al mezzo trasmissivo all'inizio del CFP;
3. DIFS (DCF interframe space): usato sotto DCF dalle STA per i frame dati (MPDU) o per i frame di gestione (MMPDU);
4. EIFS (extented interframe space): usato quando il PHY indica al MAC che l'ultimo frame MAC non e' stato ricevuto corettamente e che il campo FCS non e' utilizzabile;

Random backoff time

_{20061019-0912 SoujaK}
In seguito al rilevamento di inattivita' del mezzo trasmissivo (secondo le politiche appena descritte), ogni STA e' tenuta a ritardare ulteriormente la propria trasmissione per un tempo variabile e casuale. Cosi' facendo si evita che tutte le STA in attesa collidano nel momento in cui contemporaneamente effettuino ulteriori tentativi di trasmissione. L'algoritmo e la tecnica in generale e' descritta esaustivamente nelle specifiche, a cui pertanto rimando, qualora si cerchino infomazioni piu' dettagliate.

DCF

Gestione degli strati

I due livelli (data link e fisico) su cui lo standard e' definito possiedono un insieme di operazioni primitive proprie, ma le loro definizioni sono lungi dal poter essere considerate vere e proprie interfacce: si tratta delle "MAC layer management entities" (MLME) e delle "PHY layer management entities" (PLME). E' assai importante notare, specialmente ai fini dello studio in oggetto, che lo strato MAC non oscura il sottostante PHY, ma permette alla "station management entity" (SME) di interagire direttamente con esso. Le varie entita' hanno la possibilita' di comunicare fra loro secondo le specifiche dello standard, attraverso i SAP (service access point). Tale concetto intende aggregare l'insieme di chiamate che una determinata entita' espone alle altre per realizzare forme di comunicazione o invocazione. Il periodo di inattivita' che le STA si autoimpongono e' detto CW (contention window) e viene ripetuto ogni volta che si presenti una collisione. Viene inoltre incrementato a fronte di ogni collisione con andamento esponenziale (per scongiurare il pericolo di fino al raggiungimento di un valore massimo prestabilito.

  __||________________________
 |      |      |              |
 | MAC  | MLME =              |
 |      |      |              |
 |--||--|--||--| Station      |
 |      |      | Managemement |
 | PLPC | PLME | Entity       |
 |      |      |              |
 |--||--|      =              |
 |      |      |              |
 | PMD  |      |              |
 |______|______|______________|

In generale il livello MAC, come ovvio, deve essere il piu' possibile indipendente da quello fisico anche se a volte e' necessario che il livello MAC gestisca stati opportuni del livello fisico.

Il livello PHY viene suddiviso nella seguente maniera:

• PLCP (Physical Layer Convergence Procedure): funzioni di convergenza del livello fisico (adattamento del medium a PHY service), che realizzano una traduzione al fine di rendere l'interfaccia comune;
• PMD (Physical Medium Dependent): insieme di funzioni fortemente dipendenti dallo specifico dispositivo wireless (ad esempio richieste di trasmissione o ricezione di dati).

Anche in questo caso le relazioni con l'esterno sono gestite da appositi moduli SAP: uno specifico per la porzione PLCP (PMD-SAP) e un altro relativo al sottostrato PMD (PMD-SAP).

Primitive di gestione generica

Le informazioni specifiche per la gestione di ogni strato sono incapsulate all'interno di cio' che viene definita Management Information Base (MIB) che puo' essere visto come un componente di ogni livello. In accordo con questo, ogni Management Entity possiede specifiche primitive di GET e SET in grado di operare sugli attributi della relativa MIB. Informazioni dettagliate sugli attributi dei vari MIB sono presenti nel ​documento ufficiale

Interfaccia di MAC: MLME SAP

• POWERMGT: richieste al modulo che gestisce il risparmio energetico
• SCAN: scansione della rete alla ricerca di BSS disponibili
• JOIN: sincronizzazione con un BSS
• AUTHENTICATE: autenticazione con un BSS
• DEAUTHENTICATE: deautenticazione con un BSS
• ASSOCIATE: associazione fra una STA e un AP
• REASSOCIATE: associazione fra una STA e un altro AP
• DEASSOCIATE: disassociazione fra una STA e un AP
• RESET: azzeramento
• START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete ad-hoc)

_{20061019-0920 SoujaK:} La revisione g del documento non introduce nessun cambiamento alle interfacce del SAP legato al livello MAC. Viene piuttosto esteso il livello PHY al fine di supportare larghezze di banda maggiori e differenti modulazioni del segnale.

Interfaccia di PHY: PLME SAP

In generale si hanno disposizione tutti i getter e i setter necessari per manipolare tutti gli attributi del MIB (normati nell'aggiunta Annex D). Inoltre, si hanno a disposizione le seguenti primitive:

• RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato di ricezione;
• CHARACTERISTICS.request: ritorna le caratteristiche operative della PHY entity;
• CHARACTERISTICS.confirm: viene sollevata dalla PHY entity successivamente ad una CHARACTERISTICS.request. Fornisce le caratteristiche operative della PHY entity;
• DSSSTESTMODE.request: utile per entrare in modalita' test in una PHY DSSS entity;
• DSSSTESTOUTPUT.request: opzionale, testa i segnali di output di una PHY DSSS entity.

Interfaccia di PHY: PHY SAP

Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire il meccanismo per trasferire MPDU fra le STA, stando al di sopra del livello PMD. Anche in questa sezione, i servizi vengono definiti in maniera puramente astratta, in modo da non forzare a particolari implementazioni delle interfacce.

Le primitive tra MAC e PHY si possono dividere in due categorie:

• primitive per il supporto d'interazioni punto-a-punto a livello MAC (primitiva PHY-DATA.{request, confirm, receive, indication}).
• primitive con significato locale per agevolare l'interazione tra sottolivelli (e.g. PHY-TXStart.{request,...}).

gnappo:_{chiarire meglio tutte le primitive con il loro significato. Sara' utile nella comprensione delle specifiche del livello PHY (ad esempio DSSS).}

FHSS (Frequency Hopping Spread Spectrum)

Si tratta di una specifica del livello PHY. Vengono in generale definite un sacco di primitive che vanno dal controllo del consumo energetico del medium, alla trasmissione, al CS/CCA. Frequency hopping: il salto delle frequenze (channel) e' fatto alfine di ottenere un maggior throughput della rete (non si impegna mai una stessa frequenza per "troppo" tempo). Questo hopping deve avvenire entro un tempo limite di 224us.

gnappo:_{fa schifo! pensero' io stesso a migliorare}

DSSS

20061021-???? gnappo
DSSS (Direct Sequence Spread Spectrum) e' un'altra specifica del livello fisico che permette di raggiungere in linea teorica un capacita' trasmissiva pari a 11Mbit/s (802.11b). Attraverso opportune tecniche e' possibile fornire bitrate inferiori (in tal modo si ottiene compatibilita' all'indietro). Come per FHSS l'importante e' garantire l'indipendenza di MAC rispetto ad una specifica implementazione di PHY. Anche in questa occasione, avremo opportune funzioni di convergenza atte a garantirci questa proprieta'. Il PPDU e' differente (e arricchito) rispetto a quello definito per FHSS (nel seguito troverete qualche dettaglio). Interessante osservare che il preambolo e l'header del frame sono trasmessi, diversamente dal resto, ad un 1Mbit/s per assicurarsi che l'interlocutore capisca effettivamente questa parte essenziale della comunicazione. L'effettivo invio del payload (MPDU) potra' essere compiuto con modulazioni diverse opportunamente specificate nell'header (campo SIGNAL).

Algoritmo di trasmissione

20061021-???? gnappo
Per trasmettere i dati, PHY-TXSTART.request dev'essere abilitata per portare PHY nello stato di trasmettitore (precedentemente su ricevitore). Il canale su cui trasmettere e' regolato via PLME. Se il canale risulta libero (PHY-CCA.indicate) allora MAC puo' procedere all'effettivo invio invocando la primitiva PHY-TXSTART.request (PHY-SAP) passando i parametri necessari (DATARATE, TX_ANTENNA, TXPWR_LEVEL). Una volta terminato l'invio del preambolo, attraverso una serie di chiamate PHY-DATA.request(DATA) verrano scambiati i dati tra MAC e PHY. Al termine della trasmissione l'entita' fisica ritornera' allo stato di ricevitore.

Algoritmo di ricezione

20061021-???? gnappo
Per quanto riguarda la ricezione e' necessario che l'entita' fisica sia nello stato di ricevitore (quindi PHY-TXSTART disabilitato). Attraverso la PLME e' possibile scegliere il canale su cui ascoltare ed il metodo di CCA (Clear Channel Assessment). Altri parametri (come per la trasmissione) sono passati attraverso PHY-SAP. Non appena il dispositivo ha rilevato attivita' sul canale sul quale e' in ascolto, PHY invoca la primitiva PHY-CCA.indicate con la quale informa MAC che il canale e' BUSY. Dopodiche' PHY va alla ricerca di un delimitatore di inizio frame e procede alla lettura dell'header. Se la lettura va a buon fine (i.e. formato riconosciuto, niente errori su CRC) allora viene chiamata la primitiva PHY-RXSTART.indicate per mettere a conoscenza di MAC di informazioni contenute nell'header (i.e. campo SIGNAL, lunghezza del MPDU, RX_ANTENNA, RSSI, SQ, campo SERVICE). I dati successivamente ricevuti saranno assemblati e presentati a MAC attraverso la primitiva PHY-DATA.indicate(DATA). Al termine dell'intera ricezione lo stato del ricevitore ritornera' IDLE e la primitiva PHY-RXEND.indicate(NoError) sara' sollevata. Se la ricezione non andasse a buon fine, PHY informerebbe MAC attraverso la primitiva PHY-RXEND.indicate della causa dell'errore (e.g. CarrierLost).

Note

Per quanto riguarda questioni di tempistiche ed altre informazioni dettagliate (MIB attributes) rimando alle specifiche ieee, capitolo 15.

Specifiche della modulazione HR/DSSS _{(802.11b & g)}

20061022-2130 Zeratul
High Rate Direct Sequence Spread Spectrum (HR/DSSS) e' l'evoluzione della "semplice" DSSS che consente di portare la bandwith massima a 5.5 o 11 Mbps (nell'802.11g si arrivera' anche a ~54 Mbps). Gli header e preamboli PLCP sono gli stessi della DSSS, in questo modo e' possibile la coesistenza di entrambe le modulazioni in una stessa connessione.
Le sostanziali differenze con il suo predecessore sono molteplici:

1) si sono riuniti i ​chips

in gruppi da 8 formando cosi chiavi a codice complementario (8-chip complementary code keying, aka CCK) che vengono spediti alla stessa frequenza del DSSS (11 MHz), ottimizzando cosi l'uso della banda del canale.

2) sono state aggiunte delle funzionalita' opzionali per aumentare il bandwith,

che sono utilizzabili solo se l'hardware e' abbastanza recente da supportarle. Le funzionalità sono le seguenti:

• sostituzione del CCK con il packet binary convolutional coding

(HR/DSSS/PBCC);

• HR/DSSS/short, ovvero possibilita' di ridurre il preambolo PLCP

per aumentare significantemente il transfer data rate, limitando cosi pero' la possibilita' di coesistenza con il DSSS a sole alcune particolari circostanze;

• inserimento del Channel Agility, ovvero una particolare implementazione

che consente di superare diversi problemi dovuti all'assegnamento di un canale statico, senza dover aggiungere alla totale implementazione il costo di questa funzionalita'.

Appunti vari

_{20061014-1305 Roma}
Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi è praticamente una serie di richieste tra il client e l'AP affinchè la connessione venga instaurata; nota importante è che il client prima di collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova connessione. Naturalmente vi sono già delle primitive implementate atte a svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che per le reinstaurazione). Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro (es che fece anche il seminarista se non ricordo male) e per fare ciò si inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda pancette ai client conessi a lui; quindi vi è una doppia sincronizzazione: una tra AP e client e una tra client e client (cap 11 del documento ieee 802.11).