source: doc/AssociazioneMultipla.tex @ 3

Last change on this file since 3 was 2, checked in by gnappo, 18 years ago

Concluso Scenario.Implementazioni, iniziato CasoReale.

File size: 14.9 KB
RevLine 
[1]1\documentclass[a4paper,10pt]{article}
2
3\usepackage[italian]{babel}
4\usepackage[T1]{fontenc}
5\usepackage[utf8]{inputenc}
6\usepackage[pdftex,bookmarks,colorlinks,linkcolor=red,urlcolor=blue]{hyperref}
7
8% testo colorato
9%\usepackage{color}
10% riferimenti incrociati dinamici
11%\usepackage{varioref}
12
13% SoujaK
14 %\usepackage[pdftex,pdftitle={},pdfauthor={},pdfpagemode=FullScreen,
15 %plainpages=false,pdfpagelabels,urlcolor=blue,linkcolor=red,citecolor=green,
16 %bookmarks=false]{hyperref}
17
18\title{Associazione multipla simultanea\\ di un \textit{client} 802.11}
19\author{Andrea Rappini, Alessio Romagnoli,\\Marco Solieri, Andrea Simeone}
20
21\begin{document}
22
23\maketitle
24
25\begin{abstract}
26La diffusione di reti wireless è in forte crescita a causa della sua comodità e
27della diffusa disponibilità di connessioni ad Internet con ampie larghezze di
28banda. Sfruttare contemporaneamente la connessione alla molteplicità di reti
29spesso presente permetterebbe un utilizzo migliore di tali risorse, migliorando
30il \textit{throughput} e incrementandone l'affidabilità.
31
32Lo studio intende quindi analizzare le effettive possibilità di realizzazione di
33un'estensione delle comuni implementazioni dello standard IEEE 802.11 che
34permetta al singolo \textit{client} in ambiente GNU/Linux l'associazione
35simultanea a
36differenti reti wireless.
37\end{abstract}
38
39% \newpage
40\section{Introduzione}
41\label{sec:intro}
42
43\subsection{Oggetto}
44\label{sec:oggetto}
45Lo studio di fattibilità si interroga sulle possibilità realizzative di
46connessione di un singolo \textit{client} 802.11 a diverse reti, partecipando a
47piè BSS
48(cioè l'insieme di nodi costituenti una rete wireless).
49
50Nel presente documento si intende dapprima introdurre il lettore allo scenario
51nel quale è stato condotto lo studio, evidenziandone gli aspetti salienti che
52riguardano lo standard IEEE 802.11 e le sue interpretazioni. In un secondo
53momento si presenteranno non solo proposte risolutive, ma anche spunti
54accessori.
55
56\subsection{Scopi}
57\label{sec:scopi}
58L'intento più evidente è quello di aumentare la connettività del
59\textit{client},
60permettendogli connessioni simultanee a reti altrimenti isolate ed eventualmente
61consentendo al \textit{client} di agire in qualità di ponte. Qualora i punti di
62accesso
63resi contemporaneamente utilizzabili riferiscano (più o meno direttamente)
64alla medesima rete, allora la molteplicità si traduce in ridondanza e,
65conseguentemente, in affidabilità. I più coraggiosi potranno sfruttare
66multi-connettività in oggetto come punto di partenza per la realizzazione di
67politiche di gestione al fine di massimizzare il \textit{throughput} aggregato.
68
69\subsection{Obiettivi supplementari}
70\label{sec:obiettivi}
71I criteri con i quali si sono prese le svariate decisioni che hanno
72caratterizzato lo studio e che si concretizzano nelle soluzioni proposte hanno
73risentito dei seguenti obiettivi supplementari:
74\begin{description}
75\item[\textit{overhead} minimo]
76abbattere i costi introdotti dalla gestione simultanea delle connessioni
77multiple;
78\item[perdite minime] ridurre o eliminare ogni possibile perdita di dati in
79ricezione causata dalla temporanea assenza su un BSS (cfr.
80sezione~\ref{sec:mezzotrasmissivo});
81\item[portabilità] essere quanto più indipendente dalle specifiche piattaforme
82\textit{hardware}/\textit{firmware}, pur rimanendo legata all'ambiente
83GNU/Linux;
84\item[facilità implementativa] ridurre gli sforzi per l'effettiva messa in
85opera;
86\item[trasparenza] virtualizzare le interfacce di rete associate ad ogni
87connessione per minimizzare l'impatto.
88\end{description}
89
90\section{Scenario}
91\label{sec:scenario}
92
93\subsection{Caratteristiche del mezzo trasmissivo}
94\label{sec:mezzotrasmissivo}
95Il mezzo trasmissivo utilizzato nelle comunicazioni di reti senza fili è, per
96sua natura, disponibile e condiviso da ogni utilizzatore, pertanto lo standard
97IEEE 802.11 ne sancisce il partizionamento in diversi spettri di frequenza
98denominati canali. In tal modo si permette la coesistenza di reti wireless
99distinte in aree limitrofe o addirittura sovrapposte grazie all'uso di canali
100differenti.
101
102\label{salti}
103Lo studio ha pertanto tenuto presente la necessità da parte del \textit{client}
104di effettuare salti periodici di canale per poter raggiungere ogni BSS a cui
105desideri partecipare.
106
107\subsection{Standard IEEE 802.11}
108\label{sec:80211}
109\subsubsection{Accesso alla rete}
110\label{sec:accessoallarete}
111Affinché una stazione mobile possa partecipare ad una rete wireless, le è fatto
112obbligo di annunciare la sua presenza attraverso una procedura detta di
113\textbf{associazione}. Questo legame unisce una stazione ad uno ed un solo BSS e
114garantisce che la stazione possa effettuare trasmissioni dirette ad ognuno dei
115nodi appartenente all'intera rete e viceversa.\\
116Lo studio intende proprio scardinare l'univocità del rapporto fra stazione
117e BSS che lo standard impone esplicitamente.
118
119A causa della natura condivisa del mezzo trasmissivo, l'accesso alla rete
120sarebbe aperto a qualunque stazione richieda di associarsi. IEEE ha quindi
121elaborato una strategia di regolazione dell'accesso  richiedendo la mutua
122identificazione di entrambi gli estremi di ogni comunicazione. Tale procedura,
123definita \textbf{autenticazione}, risulta pertanto essere un prerequisito della
124stessa associazione.
125Il processo può diventare oneroso in termini di tempo a causa dei \textit{frame}
126da scambiare e dell'elaborazione necessaria (si pensi ai calcoli crittografici
127coinvolti), quindi ne viene permessa l'invocazione anche in maniera indipendente
128dal servizio di associazione. Così facendo lo standard permette di mantenere
129questo carico lontano dai momenti in cui il tempo è un fattore
130critico\footnotemark, sfruttando la \textbf{preautenticazione}.
131\footnotetext{Infatti, se la STA è in movimento fra due BSS e se
132l'autenticazione cade prima che la stessa STA possa riassociarsi con il
133successivo AP, la procedura potrebbe richiedere tempi considerevoli che
134andrebbero a degradare pesantemente le prestazioni.}
135Da quanto detto risulta quindi evidente che, a differenza dell'associazione,
136una stazione può essere autenticata presso molteplici altre stazioni.
137
138\subsubsection{Risparmio energetico}
139\label{sec:risparmioenergetico}
140Lo standard prevede la possibilità di utilizzare l'\textit{hardware} in maniera
141efficiente rispetto ai consumi energetici, dal momento che i dispositivi
142portatili alimentati a batteria sono tutt'altro che rari.
143Le stazioni che supportano tale funzionalità hanno la facoltà di
144``addormentarsi'' durante i periodi di inattività. In questi momenti, gli
145eventuali dati ad esse destinati vengono conservati dal BSS\footnotemark per un
146invio successivo, essendo esso stato precedentemente avvisato dello stato delle
147stazioni in questione.
148I BSS, quindi, annunciano periodicamente la presenza delle trasmissioni in
149attesa, indicandone i destinatari con un messaggio chiamato TIM che è presente
150all'interno di alcuni dei \textit{beacon}. Conseguentemente le stazioni in
151risparmio energetico sono tenute a risvegliarsi in corrispondenza di questi
152intervalli regolari, per poi richiedere l'invio tramite un apposito tipo di
153\textit{frame} (il \texttt{PS-Poll}).
154\footnotetext{In realtà sarebbe doveroso fare una distinzione fra le reti
155infrastrutturate e quelle indipendenti (o \textit{ad hoc}), nelle quali la
156conservazione dei dati è appannaggio, rispettivamente, dell'\textit{access
157point} e del nodo trasmittente.}
158
159\subsubsection{Vincoli temporali}
160\label{sec:vincolitemporali}
161Come già anticipato precedentemente (nella sezione \ref{salti}), il
162\textit{client} avrà l'illusione di essere contemporaneamente associato ai BSS
163di interesse tramite continui salti fra di essi; per questo motivo risulta
164importante chiarire quali siano i vincoli temporali che lo standard gli impone.
165La padronanza di queste informazioni è di grande rilevanza, sia perché dovranno
166essere rispettate dal \textit{client} anche in seguito alle modifiche che
167verranno proposte nel presente studio, sia perché potranno essere tenute
168presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni.
169
170L'accesso al mezzo trasmissivo, a causa della sua stessa natura condivisa, è
171regolato da convenzioni stabilite dallo standard che consentono una
172ripartizione equa di questa risorsa.
173
174Tali regolamentazioni di natura temporale si fondano sulla reciproca
175sincronizzazione delle stazioni che condividono il mezzo fisico, raggiunta
176tramite il mantenimento di un \textbf{orologio} comune al BSS\footnotemark di
177appartenenza.
178Il valore su cui accordarsi viene distribuito all'interno di un \textit{frame}
179di gestione, il \textit{\textbf{beacon}}, inviato ad intervalli regolari e
180prefissati. Se già ora si intuisce che l'eventuale perdita di questi messaggi
181periodici durante i salti va minimizzata, ancor di più se ne comprende
182l'importanza a fronte della presenza di ulteriori informazioni di grande
183interesse per i fini preposti.
184
185Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma
186anche degli annunci di inizio dei periodi liberi da contesa presenti nelle reti
187infrastrutturate, lassi di tempo durante i quali l'accesso al mezzo è
188coordinato da un gestore centrale. Esso risiede tipicamente
189nell'\textit{access-point} e provvede a coordinare le comunicazioni in maniera
190spesso più efficiente rispetto a quando il coordinamento è distribuito.
191
192\footnotetext{Ancora una volta è necessaria una distinzione fra le reti
193infrastrutturate e le reti \textit{ad hoc}: il valore comune su cui accordarsi è
194dettato rispettivamente dall'\textit{access point} e dall'intero BSS in maniera
195distribuita.}
196
197In aggiunta a quanto detto, il client non potrà trascurare le \textbf{scadenze}
198temporali oltre le quali i rapporti di autenticazione e associazione con i BSS
199vengono a cadere.
200
201\subsection{\textit{Wireless Extensions}}
202\label{sec:wext}
203La portabilità in ambienti GNU/Linux è stata ricercata usando come punto di
204riferimento le Linux Wireless Extensions (per brevità \texttt{wext}). Il
205progetto intende mettere ordine in uno scenario spesso dominato
206dall'eterogeneità, proponendo delle interfacce unificate per i driver di
207sistema delle varie soluzioni \textit{hardware} disponibili. Nel momento in cui
208si scrive sono ancora pochi i driver che si sono completamente uniformati a
209questo insieme di interfacce, ma questa scelta è stata dettata dalla speranza
210che esse diventino presto lo standard \textit{de facto}.
211
212Accanto alle API di programmazione sono stati sviluppati anche gli
213\textit{Wireless Tools}, comodi strumenti per l'utente che intendono
214offrire le medesime possibilità attraverso un'interfaccia a riga di comando.
215
216\subsection{Implementazioni}
217\label{sec:implementazioni}
218
219\subsubsection{Architettura}
220\label{sec:architettura}
221Lo standard IEEE 802.11 definisce due strati di rete che sono riconducibili,
222facendo riferimento al modello ISO/OSI, al livello fisico e a quello MAC
223(\textit{Medium Access Control}), implementati dai produttori tramite
224l'accoppiata \textit{hardware}/\textit{firmware}. MAC viene solitamente
225realizzato così a basso livello per rispondere alle esigenze di velocità
226e precisione temporale di cui si accennava in \ref{sec:vincolitemporali}.
227È importante sottolineare, quindi, che qualunque idea risolutiva dello
228studio in questione non potrà prescindere dalle modalità di interazione
229(interfacce e impostazioni) consentite dalla specifica implementazione di MAC.
230Questo discorso diventa tanto più importante quanto la soluzione perseguita si
231discosta dalla rigidità dello standard.
232
233La revisione 802.11i, che estende lo standard migliorando la sicurezza da esso
234offerta, definisce nuove funzionalità per il livello MAC che possono invece
235essere tranquillamente implementate all'esterno del \textit{firmware}.
236
[2]237\subsubsection{Libertà d'azione}
238\label{sec:libertàdazione}
[1]239Le più diffuse implementazioni di 802.11 sono però quantomai lontane dalle
240libertà di azione sperabili poiché il \textit{firmware} risulta essere
241scarsamente programmabile, consentendo poco più delle interazioni necessarie al
242normale funzionamento. Esempi di soluzioni \textit{chipset} che siano
243controcorrente, e pertanto interessanti, vengono riportati da
244\refname{guidadefinitiva}: Atheros\footnotemark e Broadcom.
245\footnotetext{L'unico (dei due) provato dagli autori, con driver
246\texttt{MADWiFi}.}
247
248A complicare ulteriormente la situazione intervengono le limitazioni imposte
249dalle autorità delle comunicazioni di molti Paesi (si pensi all'FCC
250statunitense), che richiedono la distribuzione dei trasmettitori radio
251con \textit{firmware} in forma necessariamente binaria per scongiurare
252violazioni dei limiti di utilizzo delle frequenze.
253
254
255\subsubsection{Interpretazione dello standard}
256\label{sec:interpretazionedellostandard}
257
[2]258Nemmeno le più fedeli realizzazioni di 802.11 supportano la
259preautenticazione (\refname{guidadefinitiva}), quindi i servizi di
260autenticazione e associazione risultano indissolubilmente legati, vanificando
261ogni possibilità di realizzare autenticazione multipla.
262Di conseguenza, il superamento di questo limite, vincolante per realizzare
263associazione multipla simultanea, sarà, in tutta la sua complessità, compito
264dell'implementatore della soluzione proposta in \ref{manca}.
265
266Un'altra eventuale limitazione dovuta all'interpretazione dello standard
267può derivare dalla libertà concessa riguardo la stessa implementazione del
268supporto alla gestione energetica.
269
[1]270\subsection{Caso reale}
271\label{sec:casoreale}
272
[2]273Le schede \texttt{Atheros} costituiscono una realtà attraente per i fini dello
274studio, in particolare per ciò che concerne le libertà d'azione concesse di cui
275al \ref{sec:libertàdazione}.
276Il driver \texttt{MADWiFi} è in grado sfruttare in maniera interessante le
277potenzialità offerte da questo \textit{chipset}, offrendo funzionalità non
278troppo distanti dagli scopi del presente.
279
280\subsubsection{Il chipset Atheros}
281\label{sec:atheros}
282
283I \textit{chipset} \texttt{Atheros} equipaggiano i dispositivi 802.11 di alcuni
284fra i maggiori produttori di \textit{hardware} per la connettività, come
285\texttt{Linksys}, \texttt{NETGEAR} o \texttt{D-Link}.
286
287Il suo \textit{firmware} consente un grado di interazione di estensione
288incomparabile, esponendo un'interfaccia in grado di offrire controllo anche su
289dettagli generalmente offuscati.
290
291Proprio per questa ragione la sua distribuzione è vincolata alla presenza di un
292sovrastrato (reso disponibile in sola forma binaria) atto a limitare
293l'interfaccia al fine di impedire utilizzi non conformi alle vigenti
294regolamentazioni sugli apparecchi radio. Tale componente, denominato
295\texttt{HAL} (\textit{Hardware Abstraction Layer}), interviene limitando le
296radiofrequenze operative del dispositivo, continuando a concedere le libertà
297auspicate.
298
299\subsubsection{Il driver MADWifi}
300\label{sec:madwifi}
301
302%        * MADWiFi
303% :        * possibilita` offerte (modalita` multipla eterogenea)
304% .        * interfaccia verso l'alto
305
[1]306\section{Soluzioni}
307\label{sec:soluzioni}
308
309\section{Ottimizzazioni ulteriori per le scelte di swinging}
310\label{sec:ottimizzazioni}
311
312\section{Bibliografia}
313\label{sec:bibliografia}
314
315\section{Ringraziamenti}
316\label{sec:ringraziamenti}
317
318\end{document}
Note: See TracBrowser for help on using the repository browser.