A quanti e’ capitato di acquistare con entusiasmo un sistema wireless 802.11b “con velocita’ di trasmissione di 11Mbps”? Di aprire la confezione con altrettanto entusiasmo, per effettuare una veloce installazione di prova?

E di queste persone, quante, presa la briga di effettuare prove di throughput, sono rimaste deluse una volta constatato come in effetti il throughput reale sia in realta’ molto piu’ basso, diciamo dai 4 ai 5,5 Mbps in media?

Purtroppo molti hanno delle false aspettative in termini di performance misurabili ottenibili dai sistemi 802.11b.

Questo articolo si vuole focalizzare sui motivi per cui gli 11 Mbps dichiarati su tutte le brochure informative dei vari produttori non sono raggiungibili.

Si vedra’ pertanto il funzionamento del protocollo 802.11b, scendendo nel dettaglio quanto basta per i nostri propositi, cercando comunque di mantenere la trattazione ad alto livello, per poter rendere questo documento fruibile ad un pubblico anche non tecnico. Si fara’ pertanto uso di frequenti paragoni e metafore.

Vedremo anche altri fattori legati alle misure di throughput, che non sono strettamente legate al protocollo 802.11b.

E’ bene comunque non essere fraintesi: la tecnologia wireless 802.11 rimane comunque validissima, in forte espansione e che rappresentara’, a detta anche dei maggiori analisti, un mercato in fortissima crescita sia dal punto di vista dei volumi di vendita sia dal punto di vista delle applicazioni: potremmo dire, in una frase, che il futuro e’ wireless!

Le prestazioni reali inferiori agli 11 Mbps infatti non rappresentano un ostacolo a questa tecnologia, se non psicologico, poiche’ per la maggior parte delle applicazioni per cui lo si vorrebbe utilizzare e’ sufficientemente performante. Non dimentichiamoci poi gli standard 802.11g e 802.11a con performance a 54 Mbps (il primo e’ in arrivo, il secondo e’ gia’ una realta’ sul mercato americano e in alcune nazioni europee), ma di questo parleremo in un altro articolo specifico.

2 Misurabilita’ delle performance

Prima di tutto una premessa: e’ importante sottolineare come non sia per niente scontato fare misure di performance attendibili con sistemi empirici spesso improvvisati: due PC agli estremi di una connessione wireless, e un trasferimento FTP di file.

Questa potrebbe non essere una misurazione attendibile, poiche’ la velocita’ di trasferimento e’ influenzata da diversi fattori oltre che dalla semplice linea di trasmissione: per esempio le schede di rete sui PC, la bonta’ dei driver di tali schede di rete, il sistema operativo in uso, e non da ultimo lo stato di deframmentazione del disco rigido, che viene spesso trascurato ma che puo’ cambiare anche di molto i risultati.

3 Perche’ non trasferiamo a 11 Mbps?

La risposta a questa domanda e’ data da molteplici fattori:

-          overhead dei protocolli di comunicazione (effetto comune a tutti i sistemi di trasmissione);

-          protocollo 802.11b;

-          situazione di rete congestionata (legato al punto 2);

-          interferenza

-          particolari servizi abilitati come l’encryption

-          cammini multipli

3.1 Overhead dei protocolli di comunicazione [pagebreak]

Questo effetto e’ presente in tutti i protocolli di comunicazione.

Per spiegare questo fenomeno pensiamo, semplificando molto, a quello che succede quando un utente invia una mail a un altro utente, per esempio utilizzando una rete Ethernet (trascuriamo la presenza di server di posta, supponiamo una trasmissione diretta tra i due client, anche se sappiamo che tale situazione non e’ reale).

La seguente trattazione risultera’ scontata per i lettori piu’ tecnici, o magari noiosa per i meno tecnici, ma come si dice, non si puo’ accontentare tutti...

Ebbene, i due utenti (figura 1) vedono solo i caratteri digitati sulla tastiera, ma dal momento che il mittente preme il tasto “invia mail”, una serie di operazioni vengono eseguite dal suo computer in modo automatico, che portano a trasformare in segnale elettrico sul cavo Ethernet (prendendo l’esempio di questo mezzo trasmissivo) la mail inviata.

Figura 1 : un utente invia una mail ad un altro utente, situazione semplificata

Tali operazioni vengono definite in differenti step logici, chiamati livelli, che vengono poi riferiti ad un modello standard, che e’ il famoso modello ISO/OSI a 7 livelli (dal livello applicazione, giu’ fino al livello fisico).

Il computer del mittente prende cosi’ la mail appena scritta dall’utente, la tratta eseguendo le varie operazioni definite nei 7 livelli ISO/OSI, a scendere fino ad arrivare al livello 1; l’operazione di quest’ultimo livello e’ di “mettere i bit sul cavo”. Alla fine di questi processi il computer ha trasformato in segnale elettrico sul cavo la mail originale.

Il computer destinatario della mail ripercorrera’ in senso inverso i 7 passi del modello ISO/OSI partendo dal segnale elettrico ricevuto sul cavo, sino a ricostruire, a livello applicazione, la mail arrivata, rendendola cosi’ disponibile sul monitor all’utente (figura 2).

Figura 2: stack ISO/OSI

Senza scendere nel dettaglio dello stack ISO/OSI (o di quello TCP/IP, che e’ quello correntemente usato) perche’ non rientra negli argomenti della nostra trattazione, a noi basti pensare come ogni livello introduca degli overhead.

Infatti, tornando alla mail di partenza, essa e’ come una lettera da spedire: viene imbustata indicando sulla busta l’indirizzo del destinatario e passata al livello sottostante, il quale aggiunge la propria busta, con un proprio indirizzo tipico di quel livello (indirizzata al pari livello del destinatario, dunque un indirizzo logico differente dal precedente) e passata a sua volta al livello sottostante. Queste operazioni continuano per la maggior parte dei livelli (per semplicita’ diciamo tutti i livelli), ogni volta aggiungendo una busta sempre piu’ esterna, con l’indirizzo tipico di quel livello, fino a raggiungere il livello fisico, che trasforma in segnale elettrico la sequenza di bit risultante.

Il risultato e’ che il messaggio originale e’ stato imbustato diverse volte, e poiche’ ogni busta (con il proprio indirizzo) rappresenta un overhead, il messaggio riginale e’ contornato da una serie di informazioni utili solo alla sua trasmisisone, ma non facenti parte del messaggio stesso.

Tradotto in ambito networking, si ha il livello applicativo che, opportunamente frammentato, viene imbustato in vari livelli sottostanti: si avra’ cosi’ una frame Ethernet (la busta piu’ esterna,con il proprio indirizzo Ethernet) che contiene un pacchetto IP (con il proprio indirizzo IP) che contiene un datagram di livello 4 (con la porta TCP o UDP) ecc, che contiene infine la mail originale (o meglio, una sua porzione, perche’ e’ chiaro che una mail di media lunghezza non potrebbe mai essere contenuta interamente in una frame, ma verra’ frammentata).

Ne risulta che per spedire N byte di mail devo spedire N+M byte effettivi sul cavo, cioe’ 8x(N+M) bit, dove M e’ l’overhead di trasmissione.

Per chi ha avuto la pazienza di seguire questo escursus (troppo semplice o troppo nosioso a seconda dei casi), risultera’ allora chiara la differenza tra “velocita’ di accesso” (i nostri 11 Mbps) e throughput effettivo, che risulta essere l’informazione utile trasmessa all’interno delle nostre buste (il file trasmesso con l’FTP nel nostro esempio). Se pensiamo a tutto questo sistema di buste come a delle matriosca, il file FTP e’ il vero contenuto della bambolina piu’ piccola, l’ultima, quella piu’ interna, mentre tutte le altre bamboline sono l’overhead, non sono informazione utile.

Tale effetto e’ presente in tutti i sistemi di comunicazione: anche in una linea dedicata da 2 Mbps, per esempio, non si avra’ un throughput di 2 Mbps! Sara’ minore, a causa degli overhead introdotti dal protocollo di trasmissione, diversi a seconda del sistema stesso di trasmissione: l’overhead di una linea dedicata (a sua volta di diversi tipi) sara’ differente dal quello dell’Ethernet, da quello del Token Ring, da quello dell’802.11b e cosi’ via.

3.2 Protocollo 802.11b

Dopo aver visto un effetto di riduzione del throughput comune a tutti i sistemi di trasmissione, vediamone ora uno presente solo in quei sistemi di trasmissione che sono a condivisione di accesso, come l’Ethernet, e, appunto, l’802.11b.

Facciamolo addentrandoci nello specifico del protocollo 802.11b (niente paura per i lettori meno tecnici).

Ebbene, l’802.11b si basa su CSMA /Carrier Sense Multiple Access), come l’Ethernet, cioe’ l’idea di base e’ che il mezzo (il cavo Ethernet o l’etere nel caso wireless) va condiviso fra i vari client. Se tutti trasmettono insieme, inviando i propri bit (sotto forma di segnale elettrico) sul cavo (od onda elettromagnetica nell’etere) si crea una collisione, e la trasmissione non va a buon fine. Si deve pertanto gestire (o evitare, come vedremo) tale eventualita’ di collisione.

Un primo meccanismo e’ appunto il CSMA, cioe’ prima di trasmettere si ascolta il mezzo per sentire se e’ gia’ impegnato da qualcun altro. Se e’ gia’ impegnato si attende per un certo tempo prima di riprovare, se invece e’ libero si inizia a trasmettere.

Qua le strade dell’Ethernet e dell’802.11b si separano, comportandosi da questo momento in avanti in modo differente. Nell’Ethernet infatti il client trasmette si’ come detto quando sente il cavo libero, ma potrebbe accadere di trasmettere contemporaneamente ad un altro client, che pure aveva acoltato il mezzo sentendolo libero. In tal caso si crea una collisione, che viene rilevata da entrambi i client (punto fondamentale come vedremo, a differenza del wireless), i quali cosi’ attendono un tempo casuale prima di riprovare a trasmettere. Questo sitema prende il nome di CSMA/CD (Carrier Sense Multiple Access with Collision Detection), cioe’ si sente la collisione e si attendende un tempo casuale prima di riprovare.

Sfortunatamente, nell’etere non e’ possibile sentire la collisione, per cui un tale sistema non e’ applicabile, e’ necessario averne un altro, che eviti le collisioni. Tale sistema si chiama CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) e vediamo di spiegarlo in poche parole.

Siamo rimasti al client che sente il mezzo libero e che quindi trasmette. Bene, ma per evitare una collisione dovuta a una contemporaneita’ di trasmissione, un client prima di inziare l’effettiva trasmissione manda un pacchetto di richiesta di permesso all’access point (RTS- Request  To Send), il quale eventualmente risponde con un CTS (Clear To Send).

E’ necessario che ci sia un’entita’ che faccia da arbitro (l’access point appunto), sia per evitare collisioni dovute alla contemporaneita’ di trasmissione, sia per ovviare a un altro possibile problema tipico delle reti wireless che potrebbe pure portare a collisioni: il problema del nodo nascosto (Hidden Node Problem, figura 3).

Figura 3: Hidden Node Problem

Il problema del nodo nascosto consiste in due client sufficientemente distanti da non essere in grado di “sentirsi”, ma che entrambi comunicano con un access point (per esempio sono diamentralmente opposti a tale access point). Entrambi sentirebbero il mezzo libero, ma se trasmettessero, creerebbero una collisione, nei pressi dell’access point. Il sistema basato su RTS/CTS risolve anche questo problema.

Molti avranno sentito parlare di particolari configurazioni wireless di tipo peer-to-peer, dove non esiste un access point, e si staranno chiedendo: ma come puo’ funzionare allora? La risposta e’ semplice: uno dei client funziona da arbitro del mezzo, in pratica da access point, dal punto di vista logico. L’elezione dell’arbitro dipende poi dalle varie implementazioni, solitamente e’ quel client che per primo accede alla rete, per esempio all’atto dell’accensione.

Risulta dunque evidente come il sistema di gestione del mezzo 802.11b appena descritto (CSMA/CA) introduca un traffico aggiuntivo che riduce il throughput, in maniera tanto piu’ pesante quanti piu’ client ci sono sulla rete wireless, poiche’:

-          tanti piu’ client ci sono tanti piu’ pacchetti di controllo vengono trasmessi sulla rete;

-          tanti piu’ client ci sono tanto piu’ dovro’ dividere la banda disponibile fra tutti. In altre parole, l’access point dara’ slot di trasmissione ora a uno ora all’altro, dividendo la banda disponibile tra tutti.

3.3 Situazione di rete congestionata

In una situazione di rete congestionata si comprende come le performance degradino notevolmente, soprattuto per effetto del fatto che la banda deve essere suddivisa fra piu’ utenti.

Un corretto dimensionamento del sistema e’ necessario per poter calibrare il numero di utenti adeguato per ogni access point (e dipende da tanti fattori, come il sistema operativo, e gli applicativi utilizzati).

3.4 Interferenza

I sistemi wireless possono essere interessati da un ulteriore fenomeno che ne potrebbe limitare il throughput: l’interferenza.

Infatti altri sistemi operanti alle stesse frequenza possono creare interferenza, facendo crescere il numero di errori (pacchetti danneggiati o incompleti) ricevuti dal client e dall’access point, o addirittura di pacchetti persi.

Piu’ in generale, qualsiasi segnale o rumore nella stessa banda di frequenza (e in tal caso entrano in gioco anche particolari apparecchiature elettromeccaniche in uso in ambienti industriali) possono creare interferenza.

Per tranquillizzare quei lettori che iniziano a preoccuparsi, va detto che per lo piu’ questi sono problemi teoricamente possibili, ma nella stragrande maggioranza dei casi non sono significativi, anche perche’ la particolare modulazione utilizzata (modulazione a spettro espanso a sequenza diretta – DSSS: Direct Sequence Spread Spectrum) e’ piuttosto robusto ai rumori e ai disturbi.

Avendo poi l’accortezza di acquistare un sistema di qualita’, il problema e’ mitigato anche dalla migliore ricezione dei dispositivi: per esempio un valore di -94 dbm a 1Mbps e’ ottimo, e significa che a 1Mbps il rapporto segnale rumore puo’ essere di -94dbm, cioe’ il rumore puo’ essere notevolmente piu’ intenso del segnale.

3.5 Particolari servizi abilitati

Un altro potenziale motivo di perdita di throughput e’ l’abilitazione di particolari “servizi” sui dispositivi wireless. Soprattutto l’encryption: se abilitiamo la cifratura dei pacchetti con chiave WEP da 128 bit, per esempio, i dispositivi wireless presentano un decadimento di prestazioni significativo, poiche’ tale operazione viene per lo piu’ effettuata in modalita’ software.

Pochi produttori, per non dire pochissimi, implementano la cifratura con un chip dedicato che riduce al minimo l’impatto dell’encryption sulle performance, grazie al fatto che le operazioni di cifratura vengono effettuate in hardware.

3.6 Cammini Multipli (Multipath Fading)

Il fenomeno dei cammini multipli (Mltipath Fading) consiste nell’avere il segnale diretto tra trasmittente e ricevente, piu’ una serie disegnali riflessi, per esempio dovuti a riflessioni, su particolari pareti, soffitti, armadietti metallici ecc.

Il dispositivo wireless deve essere in grado di discernere il segnale migliore. Questo potrebbe aggiungere lavoro al dispositivo, che quindi potrebbe diminuire il suo throughput, ma per lo piu’ si tratta di una eventualita’ piu’ teorica che reale, in quanto il fenomeno non degrada sensibilmente le prestazioni. Molto piu’ segnificativi agli effetti del throughput sono i fenomeni descritti in precedenza.

Per diminuire il fenomeno dei cammini multipli, comunque, alcuni sistemi wireless consentono di adottare due antenne, che lavorano in diversita’ di percorso.

4 Conclusione

Abbiamo visto quali possono essere i fattori principali per cui un sistema wireless non ha un effettivo throughput di 11 Mbps, alcuni dei quali presenti in tutti i protocolli di trasmissione, altri specifici all’802.11b. Abbiamo anche citato la congestione, l’interferenza, i cammini multipli e particolari servizi abilitati, come l’encryption.

Il throughput effettivo misurabile varia per i vari produttori dai 4 ai 5,5 o piu’ Mbps.

Da non dimenticare comunque come tali limiti non debbano essere visti necessariamente come delle limitazioni: ricordiamoci che anche acquistando una linea da 2 Mbps non avremo mai un throughput di 2 Mbps!

Il wireless e’ una realta’ in fortissima espansione, che secondo molti rappresentera’ grossi margini di crescita in futuro.

Semplicemente, per meglio utilizzarlo con efficienza, basta conoscerlo!