Uno Strumento Simulativo per Architetture VoIP per Dispositivi

Alma Mater Studiorum - Università di Bologna
Facoltà di Scienze Matematiche Fisiche e Naturali
Dipartimento di Scienze dell’Informazione
Uno Strumento Simulativo per Architetture
VoIP per Dispositivi Mobili Multihomed
Tesi di Laurea in Reti di Calcolatori
Presentata da:
Piero Murphy
Relatore:
Vittorio Ghini
Gli Obiettivi
In sede di tirocinio é stata ideata e definita una soluzione che consente a dispositivi mobili (palmari,
smart phones) di effettuare telefonate VoIP sfruttando contemporaneamente le molteplici connessioni
wireless disponibili e inviando il traffico dati tra queste parallelamente in modo da aumentare la banda
disponibile complessiva. La soluzione prevede l’utilizzo di due applicazioni (una sul dispositivo, una
su un server) che fungano da proxy tra le applicazioni client e server VoIP e inoltrino i dati su tutte le
connessioni Wi-Fi disponibili, in parallelo.
Lo scopo di questo lavoro di tesi é preparare un ambiente simulativo predisposto a valutare questa
architettura. Questo servirà:
• inizialmente, a valutare una serie di algoritmi di rete, quelli incaricati di inoltrare e bilanciare il
traffico dati sulle reti Wi-Fi, ideati da colleghi laureandi, per identificare il più efficiente ed idoneo;
• ad analizzare il comportamento dei programmi in varie situazioni: perdita di una connessione,
interferenze, connessioni lente o veloci, movimento rispetto agli access points;
• a raccogliere e analizzare i dati statistici di queste simulazioni;
• a simulare scenari particolari che sarebbero se non impossibili, sicuramente molto costosi da
ricreare in laboratorio.
Lo Scenario
Lo scenario prevede due applicazioni: un
Proxy Client, eseguito sul dispositivo mobile
(host) e un Proxy Server, eseguito sul server.
Queste si interfacciano con, rispetivamente, le
applicazioni VoIP client e server, ed inoltrano
il traffico dati tra loro in parallelo su tutte le
connessioni wireless disponibili utilizzando
socket UDP.
Entrambe le applicazioni hanno due
componenti: la Application Logic, che
elabora i dati di controllo VoIP e si interfaccia
con i protocolli VoIP, e la Networking Logic,
che gestisce le connessioni wireless e il
bilanciamento del traffico dati tra queste.
Strumenti
Simulatore: OMNeT++. La scelta del simulatore più adatto al nostro scopo é ricaduta su OMNeT++
(www.omnetpp.org), in particolar modo per la sua completezza, estendibilità, e buona organizzazione.
Framework: INET. Per la simulazione di network su OMNeT++ esistono due framework: INET e
Mobility; sebbene quest’ultimo sia particolarmente adatto alla simulazione di protocolli wireless
sperimentali, il primo risulta decisamente più completo; INET infatti implementa l’intero Network
Stack, dal livello fisico ai protocolli applicativi.
Problemi di INET: Una volta scelto l’ambiente di simulazione, e dopo un’analisi dello stesso, sono
state identificate le sue mancanze rispetto alle nostre necessità che dovevano essere risolte:
1. Per come é implementato il framework INET, non é possibile avere in un singolo host (il nostro
dispositivo mobile) molteplici interfacce wireless (ovvero può contenere una sola NIC WLAN).
Questa situazione é inaccettabile nel nostro contesto che, ricordiamo, parte dal presupposto che il
client possa collegarsi ad almeno due reti wireless contemporaneamente;
2. Il livello IP non consente alle applicazioni, come é d’altronde normale, di scegliere quale
interfaccia di rete utilizzare per inviare i dati. Nonostante questa sia da considerarsi una mancanza
del protocollo IP in se, e non della sua implementazione in INET, rimane comunque un problema da
risolvere.
Il primo punto é stato già affrontato in passato nell’ambito di un progetto di nome COCOS, e ha
portato a Modified INET, una versione di INET modificata, che aggiunge alcune funzionalità; il codice
riguardante il supporto a reti wireless molteplici é stato portato e adattato ai nostri bisogni.
Progettazione
Durante la fase di progettazione sono stati individuati e analizzati i principali obiettivi:
• Creazione e configurazione del network in OMNeT++, contenente un host mobile, due access
point (con relative connessioni wireless), un router e un server.
• Modificare INET in modo da consentire all’host di avere più di una interfaccia di rete wireless;
• Modificare il protocollo IP (in INET) per consentire la selezione, pacchetto per pacchetto,
dell’interfaccia di rete in uscita.
• Creare un’applicazione UDP che sfrutta queste modifiche, invia e riceve dati (configurabili in
grandezza e frequenza) e raccoglie dati statistici. Questa classe servirà inizialmente a valutare la
corretta implementazione delle modifiche, per poi diventare, con qualche estensione, il modulo che
consentirà alle nostre applicazioni di interfacciarsi con OMNeT++
Interfacce Wireless Multiple
Per simulare le reti wireless INET utilizza una
componente che chiama Controllo dei Canali
che gestisce tutti i dispositivi wireless (host e
access points), calcola e aggiorna le loro
posizioni e le reciproche distanze. Il problema
risiede in questo approccio: ChannelControl
contiene una tabella (un insieme) di Host,
ciascuno dei quali contiene (implicitamente)
una ed una sola interfaccia di rete wireless.
Con le modifiche apportate, l’approccio é
diventato: ChannelControl contiene una tabella
di Host, ciascuno dei quali contiene a sua volta
una tabella delle proprie interfacce wireless.
Questo ha portato alla modifica di 24 file, tra
C++ header files, C++ source files e Network
Description (NED) files. In particolare é stato
cambiato il codice riguardante controllo e
accesso ai canali wireless, la mobilità e i
moduli radio (IEEE 802.11)
Modifiche al Protocollo IP
Quando il protocollo IP riceve un pacchetto di dati da inviare sulla rete, utilizza una tabella, chiamata
Routing Table, per selezionare l’interfaccia di rete da utilizzare per spedirlo. La consultazione di questa
tabella si basa sull’indirizzo IP di destinazione, seguendo la logica che se vi sono interfacce di rete
molteplici, esse saranno connesse a reti separate (magari un’interfaccia per la rete privata, una per
internet). Nel nostro caso invece si possono inviare dati ad uno stesso destinatario attraverso più
interfacce. La ricerca non può più basarsi quindi sull’indirizzo del destinatario (che risulta ambiguo), e
si utilizzerà al suo posto l’indirizzo del mittente. Ad ogni interfaccia di rete é infatti assegnato un
indirizzo IP, che l’applicazione UDP potrà utilizzare per identificare una specifica interfaccia.
Il flusso esecutivo sarà quindi:
• l’applicazione, prima di inviare un pacchetto al livello trasporto (UDP nel nostro caso), vi
aggiunge come Source IP Address l’indirizzo IP relativo all’interfaccia che intende usare;
• il protocollo UDP esegue le sue mansioni invariate;
• il protocollo IP, al momento di decidere quale interfaccia di rete utilizzare e prima di utilizzare la
normale funzione di routing osserva se é stato definito il source address; quindi:
• se non é definito, esegue il codice originale utilizzando la funzione di routing per selezionare
l’interfaccia;
• se é definito, provvede a trovare l’interfaccia che possiede tale indirizzo IP e ad utilizzarla per
inviare i dati. Qualora l’indirizzo non fosse assegnato ad alcuna interfaccia, verrà segnalato un
errore e scartato il pacchetto.
Applicazione UDP Semplice
É stata creata una classe che implementa una semplice applicazione UDP che genera del traffico dati e
colleziona dati statistici.
Questa viene configurata attraverso alcuni parametri tra cui:
• porta UDP locale
• porta UDP e indirizzo/i IP di destinazione
• dimensione dei messaggi in byte
• frequenza dei messaggi in secondi
• utilizzo di acknowledgment (ACK).
Durante l’esecuzione raccoglie dati statistici scalari (valori) e vettoriali (valori sul tempo).
Gli valori scalari sono:
• totale di byte inviati
• totale di byte ricevuti
• numero di pacchetti inviati
• numero di pacchetti ricevuti;
mentre i valori vettoriali sono:
• byte al secondo in input
• byte/s in output
• latenza dei pacchetti (secondi trascorsi dalla spedizione alla ricezione)
• latenza degli ACK
• Round Trip Time (secondi dalla spedizione di un pacchetto alla ricezione del relativo ACK).
Alcuni Risultati (1)
omnetpp.ini
SCALARI
CLIENT
Inviati
Totale Bytes
Scenario Classico:
Totale Pacchetti
VETTORI
Client:
Dimensione messaggi: 10 KB
Frequenza messaggi: 0.01 s
Banda: 54 Mbps (Wireless-G)
Ricevuti
29,173,760
143,360
143,360
29,173,760
2,877
2,877
2,877
2,877
Scarto medio
Media
Scarto medio
1320.34
970681.37
210345.56
970681.37
210345.56
4766.89
1320.34
0.005
0.0026
0.0065
0.00031
Latenza ACK (s)
0.0039
0.00018
0.0016
0.0017
Round Trip Time (PKT+ACK) (s)
0.0069
0.00037
0.0066
0.0028
Output (bytes/s)
Latenza Pacchetti (s)
SCALARI
CLIENT
Inviati
Totale Bytes
Totale Pacchetti
Client:
Dimensione messaggi: 1 KB
Frequenza messaggi: 0.05 s
Banda: 54 Mbps (Wireless-G)
Inviati
4766.89
example1.ini
Traffico ridotto:
Ricevuti
Media
Input (bytes/s)
SERVER
VETTORI
Input (bytes/s)
SERVER
Ricevuti
Inviati
Ricevuti
582,656
143,360
143,360
582,656
597
597
597
597
Media
Scarto medio
Media
Scarto medio
4766.89
1320.34
19385.37
4274.34
19385.37
4274.34
4766.89
1320.34
Latenza Pacchetti (s)
0.0031
0.00029
0.00051
0.00019
Latenza ACK (s)
0.0021
0.022
0.00047
0.00028
Round Trip Time (PKT+ACK) (s)
0.0026
0.022
0.0035
0.00041
Output (bytes/s)
Alcuni Risultati (2)
example2.ini
SCALARI
Banda disponibile minore:
CLIENT
Inviati
Totale Bytes
Totale Pacchetti
Client:
Dimensione messaggi: 10 KB
Frequenza messaggi: 0.01 s
Banda: 11 Mbps (Wireless-B)
VETTORI
Output (bytes/s)
Latenza Pacchetti (s)
Latenza ACK (s)
Round Trip Time (PKT+ACK) (s)
example3.ini
Traffico intenso:
Client:
Dimensione messaggi: 10 KB
Frequenza messaggi: 0.01 s
Banda: 54 Mbps (Wireless-G)
Server:
Dimensione messaggi: 5 KB
Frequenza messaggi: 0.01 s
Ricevuti
SCALARI
143,360
21,258,240
2,877
2,104
2,104
2,104
Scarto medio
Media
Scarto medio
4766.89
1320.34
706206.89
162934.24
970681.37
210345.56
4766.89
1320.34
0.011
0.0035
0.014
0.0017
0.0014
0.0021
0.0066
0.0057
0.015
0.0028
0.017
0.0069
Inviati
Totale Pacchetti
Ricevuti
143,360
CLIENT
Totale Bytes
VETTORI
Inviati
29,173,760
Media
Input (bytes/s)
SERVER
SERVER
Ricevuti
Inviati
Ricevuti
29173760
14586880
14586880
28569600
5698
5639
5639
5635
Media
Scarto medio
Media
Scarto medio
Input (bytes/s)
485340.68
105190.58
950554.48
206839.11
Output (bytes/s)
970681.37
210345.56
485340.69
105172.78
Latenza Pacchetti (s)
0.0051
0.0026
0.0086
0.002
Latenza ACK (s)
0.0012
0.0019
0.0026
0.0026
Round Trip Time (PKT+ACK) (s)
0.0098
0.0033
0.0078
0.0037