Uno Strumento Simulativo per Architetture VoIP per Dispositivi Mobili Multihomed

Transcript

1 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

2 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.

3 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.

4 Strumenti Simulatore: OMNeT++. La scelta del simulatore più adatto al nostro scopo é ricaduta su OMNeT++ ( 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.

5 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++

6 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 )

7 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.

8 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).

9 Alcuni Risultati (1) omnetpp.ini CLIENT SERVER Scenario Classico: Client: Dimensione messaggi: 10 KB Frequenza messaggi: 0.01 s Banda: 54 Mbps (Wireless-G) SCALARI Totale Bytes Totale Pacchetti VETTORI Input (bytes/s) Output (bytes/s) Latenza Pacchetti (s) Latenza ACK (s) Round Trip Time (PKT+ACK) (s) Inviati Ricevuti Inviati Ricevuti 29,173, , ,360 29,173,760 2,877 2,877 2,877 2,877 Media Scarto medio Media Scarto medio example1.ini CLIENT SERVER Traffico ridotto: Client: Dimensione messaggi: 1 KB Frequenza messaggi: 0.05 s Banda: 54 Mbps (Wireless-G) SCALARI Totale Bytes Totale Pacchetti VETTORI Input (bytes/s) Output (bytes/s) Latenza Pacchetti (s) Latenza ACK (s) Round Trip Time (PKT+ACK) (s) Inviati Ricevuti Inviati Ricevuti 582, , , , Media Scarto medio Media Scarto medio

10 Alcuni Risultati (2) example2.ini CLIENT SERVER Banda disponibile minore: Client: Dimensione messaggi: 10 KB Frequenza messaggi: 0.01 s Banda: 11 Mbps (Wireless-B) SCALARI Totale Bytes Totale Pacchetti VETTORI Input (bytes/s) Output (bytes/s) Latenza Pacchetti (s) Latenza ACK (s) Round Trip Time (PKT+ACK) (s) Inviati Ricevuti Inviati Ricevuti 29,173, , ,360 21,258,240 2,877 2,104 2,104 2,104 Media Scarto medio Media Scarto medio Traffico intenso: SCALARI example3.ini CLIENT SERVER Inviati Ricevuti Inviati Ricevuti 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 Totale Bytes Totale Pacchetti VETTORI Input (bytes/s) Output (bytes/s) Latenza Pacchetti (s) Latenza ACK (s) Round Trip Time (PKT+ACK) (s) Media Scarto medio Media Scarto medio