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} |
---|
26 | La diffusione di reti wireless è in forte crescita a causa della sua comodità e |
---|
27 | della diffusa disponibilità di connessioni ad Internet con ampie larghezze di |
---|
28 | banda. Sfruttare contemporaneamente la connessione alla molteplicità di reti |
---|
29 | spesso presente permetterebbe un utilizzo migliore di tali risorse, migliorando |
---|
30 | il \textit{throughput} e incrementandone l'affidabilità. |
---|
31 | |
---|
32 | Lo studio intende quindi analizzare le effettive possibilità di realizzazione di |
---|
33 | un'estensione delle comuni implementazioni dello standard IEEE 802.11 che |
---|
34 | permetta al singolo \textit{client} in ambiente GNU/Linux l'associazione |
---|
35 | simultanea a |
---|
36 | differenti reti wireless. |
---|
37 | \end{abstract} |
---|
38 | |
---|
39 | % \newpage |
---|
40 | \section{Introduzione} |
---|
41 | \label{sec:intro} |
---|
42 | |
---|
43 | \subsection{Oggetto} |
---|
44 | \label{sec:oggetto} |
---|
45 | Lo studio di fattibilità si interroga sulle possibilità realizzative di |
---|
46 | connessione di un singolo \textit{client} 802.11 a diverse reti, partecipando a |
---|
47 | piè BSS |
---|
48 | (cioè l'insieme di nodi costituenti una rete wireless). |
---|
49 | |
---|
50 | Nel presente documento si intende dapprima introdurre il lettore allo scenario |
---|
51 | nel quale è stato condotto lo studio, evidenziandone gli aspetti salienti che |
---|
52 | riguardano lo standard IEEE 802.11 e le sue interpretazioni. In un secondo |
---|
53 | momento si presenteranno non solo proposte risolutive, ma anche spunti |
---|
54 | accessori. |
---|
55 | |
---|
56 | \subsection{Scopi} |
---|
57 | \label{sec:scopi} |
---|
58 | L'intento più evidente è quello di aumentare la connettività del |
---|
59 | \textit{client}, |
---|
60 | permettendogli connessioni simultanee a reti altrimenti isolate ed eventualmente |
---|
61 | consentendo al \textit{client} di agire in qualità di ponte. Qualora i punti di |
---|
62 | accesso |
---|
63 | resi contemporaneamente utilizzabili riferiscano (più o meno direttamente) |
---|
64 | alla medesima rete, allora la molteplicità si traduce in ridondanza e, |
---|
65 | conseguentemente, in affidabilità. I più coraggiosi potranno sfruttare |
---|
66 | multi-connettività in oggetto come punto di partenza per la realizzazione di |
---|
67 | politiche di gestione al fine di massimizzare il \textit{throughput} aggregato. |
---|
68 | |
---|
69 | \subsection{Obiettivi supplementari} |
---|
70 | \label{sec:obiettivi} |
---|
71 | I criteri con i quali si sono prese le svariate decisioni che hanno |
---|
72 | caratterizzato lo studio e che si concretizzano nelle soluzioni proposte hanno |
---|
73 | risentito dei seguenti obiettivi supplementari: |
---|
74 | \begin{description} |
---|
75 | \item[\textit{overhead} minimo] |
---|
76 | abbattere i costi introdotti dalla gestione simultanea delle connessioni |
---|
77 | multiple; |
---|
78 | \item[perdite minime] ridurre o eliminare ogni possibile perdita di dati in |
---|
79 | ricezione causata dalla temporanea assenza su un BSS (cfr. |
---|
80 | sezione~\ref{sec:mezzotrasmissivo}); |
---|
81 | \item[portabilità] essere quanto più indipendente dalle specifiche piattaforme |
---|
82 | \textit{hardware}/\textit{firmware}, pur rimanendo legata all'ambiente |
---|
83 | GNU/Linux; |
---|
84 | \item[facilità implementativa] ridurre gli sforzi per l'effettiva messa in |
---|
85 | opera; |
---|
86 | \item[trasparenza] virtualizzare le interfacce di rete associate ad ogni |
---|
87 | connessione 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} |
---|
95 | Il mezzo trasmissivo utilizzato nelle comunicazioni di reti senza fili è, per |
---|
96 | sua natura, disponibile e condiviso da ogni utilizzatore, pertanto lo standard |
---|
97 | IEEE 802.11 ne sancisce il partizionamento in diversi spettri di frequenza |
---|
98 | denominati canali. In tal modo si permette la coesistenza di reti wireless |
---|
99 | distinte in aree limitrofe o addirittura sovrapposte grazie all'uso di canali |
---|
100 | differenti. |
---|
101 | |
---|
102 | \label{salti} |
---|
103 | Lo studio ha pertanto tenuto presente la necessità da parte del \textit{client} |
---|
104 | di effettuare salti periodici di canale per poter raggiungere ogni BSS a cui |
---|
105 | desideri partecipare. |
---|
106 | |
---|
107 | \subsection{Standard IEEE 802.11} |
---|
108 | \label{sec:80211} |
---|
109 | \subsubsection{Accesso alla rete} |
---|
110 | \label{sec:accessoallarete} |
---|
111 | Affinché una stazione mobile possa partecipare ad una rete wireless, le è fatto |
---|
112 | obbligo 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 |
---|
114 | garantisce che la stazione possa effettuare trasmissioni dirette ad ognuno dei |
---|
115 | nodi appartenente all'intera rete e viceversa.\\ |
---|
116 | Lo studio intende proprio scardinare l'univocità del rapporto fra stazione |
---|
117 | e BSS che lo standard impone esplicitamente. |
---|
118 | |
---|
119 | A causa della natura condivisa del mezzo trasmissivo, l'accesso alla rete |
---|
120 | sarebbe aperto a qualunque stazione richieda di associarsi. IEEE ha quindi |
---|
121 | elaborato una strategia di regolazione dell'accesso richiedendo la mutua |
---|
122 | identificazione di entrambi gli estremi di ogni comunicazione. Tale procedura, |
---|
123 | definita \textbf{autenticazione}, risulta pertanto essere un prerequisito della |
---|
124 | stessa associazione. |
---|
125 | Il processo può diventare oneroso in termini di tempo a causa dei \textit{frame} |
---|
126 | da scambiare e dell'elaborazione necessaria (si pensi ai calcoli crittografici |
---|
127 | coinvolti), quindi ne viene permessa l'invocazione anche in maniera indipendente |
---|
128 | dal servizio di associazione. Così facendo lo standard permette di mantenere |
---|
129 | questo carico lontano dai momenti in cui il tempo è un fattore |
---|
130 | critico\footnotemark, sfruttando la \textbf{preautenticazione}. |
---|
131 | \footnotetext{Infatti, se la STA è in movimento fra due BSS e se |
---|
132 | l'autenticazione cade prima che la stessa STA possa riassociarsi con il |
---|
133 | successivo AP, la procedura potrebbe richiedere tempi considerevoli che |
---|
134 | andrebbero a degradare pesantemente le prestazioni.} |
---|
135 | Da quanto detto risulta quindi evidente che, a differenza dell'associazione, |
---|
136 | una stazione può essere autenticata presso molteplici altre stazioni. |
---|
137 | |
---|
138 | \subsubsection{Risparmio energetico} |
---|
139 | \label{sec:risparmioenergetico} |
---|
140 | Lo standard prevede la possibilità di utilizzare l'\textit{hardware} in maniera |
---|
141 | efficiente rispetto ai consumi energetici, dal momento che i dispositivi |
---|
142 | portatili alimentati a batteria sono tutt'altro che rari. |
---|
143 | Le stazioni che supportano tale funzionalità hanno la facoltà di |
---|
144 | ``addormentarsi'' durante i periodi di inattività. In questi momenti, gli |
---|
145 | eventuali dati ad esse destinati vengono conservati dal BSS\footnotemark per un |
---|
146 | invio successivo, essendo esso stato precedentemente avvisato dello stato delle |
---|
147 | stazioni in questione. |
---|
148 | I BSS, quindi, annunciano periodicamente la presenza delle trasmissioni in |
---|
149 | attesa, indicandone i destinatari con un messaggio chiamato TIM che è presente |
---|
150 | all'interno di alcuni dei \textit{beacon}. Conseguentemente le stazioni in |
---|
151 | risparmio energetico sono tenute a risvegliarsi in corrispondenza di questi |
---|
152 | intervalli 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 |
---|
155 | infrastrutturate e quelle indipendenti (o \textit{ad hoc}), nelle quali la |
---|
156 | conservazione dei dati è appannaggio, rispettivamente, dell'\textit{access |
---|
157 | point} e del nodo trasmittente.} |
---|
158 | |
---|
159 | \subsubsection{Vincoli temporali} |
---|
160 | \label{sec:vincolitemporali} |
---|
161 | Come già anticipato precedentemente (nella sezione \ref{salti}), il |
---|
162 | \textit{client} avrà l'illusione di essere contemporaneamente associato ai BSS |
---|
163 | di interesse tramite continui salti fra di essi; per questo motivo risulta |
---|
164 | importante chiarire quali siano i vincoli temporali che lo standard gli impone. |
---|
165 | La padronanza di queste informazioni è di grande rilevanza, sia perché dovranno |
---|
166 | essere rispettate dal \textit{client} anche in seguito alle modifiche che |
---|
167 | verranno proposte nel presente studio, sia perché potranno essere tenute |
---|
168 | presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni. |
---|
169 | |
---|
170 | L'accesso al mezzo trasmissivo, a causa della sua stessa natura condivisa, è |
---|
171 | regolato da convenzioni stabilite dallo standard che consentono una |
---|
172 | ripartizione equa di questa risorsa. |
---|
173 | |
---|
174 | Tali regolamentazioni di natura temporale si fondano sulla reciproca |
---|
175 | sincronizzazione delle stazioni che condividono il mezzo fisico, raggiunta |
---|
176 | tramite il mantenimento di un \textbf{orologio} comune al BSS\footnotemark di |
---|
177 | appartenenza. |
---|
178 | Il valore su cui accordarsi viene distribuito all'interno di un \textit{frame} |
---|
179 | di gestione, il \textit{\textbf{beacon}}, inviato ad intervalli regolari e |
---|
180 | prefissati. Se già ora si intuisce che l'eventuale perdita di questi messaggi |
---|
181 | periodici durante i salti va minimizzata, ancor di più se ne comprende |
---|
182 | l'importanza a fronte della presenza di ulteriori informazioni di grande |
---|
183 | interesse per i fini preposti. |
---|
184 | |
---|
185 | Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma |
---|
186 | anche degli annunci di inizio dei periodi liberi da contesa presenti nelle reti |
---|
187 | infrastrutturate, lassi di tempo durante i quali l'accesso al mezzo è |
---|
188 | coordinato da un gestore centrale. Esso risiede tipicamente |
---|
189 | nell'\textit{access-point} e provvede a coordinare le comunicazioni in maniera |
---|
190 | spesso più efficiente rispetto a quando il coordinamento è distribuito. |
---|
191 | |
---|
192 | \footnotetext{Ancora una volta è necessaria una distinzione fra le reti |
---|
193 | infrastrutturate e le reti \textit{ad hoc}: il valore comune su cui accordarsi è |
---|
194 | dettato rispettivamente dall'\textit{access point} e dall'intero BSS in maniera |
---|
195 | distribuita.} |
---|
196 | |
---|
197 | In aggiunta a quanto detto, il client non potrà trascurare le \textbf{scadenze} |
---|
198 | temporali oltre le quali i rapporti di autenticazione e associazione con i BSS |
---|
199 | vengono a cadere. |
---|
200 | |
---|
201 | \subsection{\textit{Wireless Extensions}} |
---|
202 | \label{sec:wext} |
---|
203 | La portabilità in ambienti GNU/Linux è stata ricercata usando come punto di |
---|
204 | riferimento le Linux Wireless Extensions (per brevità \texttt{wext}). Il |
---|
205 | progetto intende mettere ordine in uno scenario spesso dominato |
---|
206 | dall'eterogeneità, proponendo delle interfacce unificate per i driver di |
---|
207 | sistema delle varie soluzioni \textit{hardware} disponibili. Nel momento in cui |
---|
208 | si scrive sono ancora pochi i driver che si sono completamente uniformati a |
---|
209 | questo insieme di interfacce, ma questa scelta è stata dettata dalla speranza |
---|
210 | che esse diventino presto lo standard \textit{de facto}. |
---|
211 | |
---|
212 | Accanto alle API di programmazione sono stati sviluppati anche gli |
---|
213 | \textit{Wireless Tools}, comodi strumenti per l'utente che intendono |
---|
214 | offrire 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} |
---|
221 | Lo standard IEEE 802.11 definisce due strati di rete che sono riconducibili, |
---|
222 | facendo riferimento al modello ISO/OSI, al livello fisico e a quello MAC |
---|
223 | (\textit{Medium Access Control}), implementati dai produttori tramite |
---|
224 | l'accoppiata \textit{hardware}/\textit{firmware}. MAC viene solitamente |
---|
225 | realizzato così a basso livello per rispondere alle esigenze di velocità |
---|
226 | e precisione temporale di cui si accennava in \ref{sec:vincolitemporali}. |
---|
227 | È importante sottolineare, quindi, che qualunque idea risolutiva dello |
---|
228 | studio in questione non potrà prescindere dalle modalità di interazione |
---|
229 | (interfacce e impostazioni) consentite dalla specifica implementazione di MAC. |
---|
230 | Questo discorso diventa tanto più importante quanto la soluzione perseguita si |
---|
231 | discosta dalla rigidità dello standard. |
---|
232 | |
---|
233 | La revisione 802.11i, che estende lo standard migliorando la sicurezza da esso |
---|
234 | offerta, definisce nuove funzionalità per il livello MAC che possono invece |
---|
235 | essere tranquillamente implementate all'esterno del \textit{firmware}. |
---|
236 | |
---|
237 | \subsubsection{Limitazioni} |
---|
238 | \label{sec:limitazioni} |
---|
239 | Le più diffuse implementazioni di 802.11 sono però quantomai lontane dalle |
---|
240 | libertà di azione sperabili poiché il \textit{firmware} risulta essere |
---|
241 | scarsamente programmabile, consentendo poco più delle interazioni necessarie al |
---|
242 | normale funzionamento. Esempi di soluzioni \textit{chipset} che siano |
---|
243 | controcorrente, 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 | |
---|
248 | A complicare ulteriormente la situazione intervengono le limitazioni imposte |
---|
249 | dalle autorità delle comunicazioni di molti Paesi (si pensi all'FCC |
---|
250 | statunitense), che richiedono la distribuzione dei trasmettitori radio |
---|
251 | con \textit{firmware} in forma necessariamente binaria per scongiurare |
---|
252 | violazioni dei limiti di utilizzo delle frequenze. |
---|
253 | |
---|
254 | |
---|
255 | \subsubsection{Interpretazione dello standard} |
---|
256 | \label{sec:interpretazionedellostandard} |
---|
257 | % distanza dallo standard |
---|
258 | % | preautenticazione non implementata da alcuno, probabile assenza di |
---|
259 | % strutture per supportare autenticazione multipla |
---|
260 | % . powersaving opzionale |
---|
261 | |
---|
262 | \subsection{Caso reale} |
---|
263 | \label{sec:casoreale} |
---|
264 | |
---|
265 | \section{Soluzioni} |
---|
266 | \label{sec:soluzioni} |
---|
267 | |
---|
268 | \section{Ottimizzazioni ulteriori per le scelte di swinging} |
---|
269 | \label{sec:ottimizzazioni} |
---|
270 | |
---|
271 | \section{Bibliografia} |
---|
272 | \label{sec:bibliografia} |
---|
273 | |
---|
274 | \section{Ringraziamenti} |
---|
275 | \label{sec:ringraziamenti} |
---|
276 | |
---|
277 | \end{document} |
---|