Mobile Ad-hoc Networks for Collaborative and Mission-critical Mobile Scenarios: a Practical Study

Size: px
Start display at page:

Download "Mobile Ad-hoc Networks for Collaborative and Mission-critical Mobile Scenarios: a Practical Study"

Transcription

1 Mobile Ad-hoc Networks for Collaborative and Mission-critical Mobile Scenarios: a Practical Study Faculty of engineering Master Degree in Computer Engineering Chair of Advanced Software Design Gianluca Bertelli

2 Studio e Sperimentazione di Reti Ad-hoc Mobili in Scenari di Emergenza Facoltà di Ingegneria Laurea Specialistica in Ingegneria Informatica Tesi di Laurea in Progettazione del Software II Candidato Gianluca Bertelli Relatore Ing. Massimo Mecella Correlatore Ing. Massimiliano de Leoni A/A 2006/2007

3 Mobile Ad-hoc Networks for Collaborative and Mission-critical Mobile Scenarios: a Practical Study Faculty of engineering Master Degree in Computer Engineering Chair of Advanced Software Design Candidate Gianluca Bertelli Supervisor Ing. Massimo Mecella Assistant supervisor Ing. Massimiliano de Leoni A/A 2006/2007

4 Gianluca Bertelli Via Giovanni XXIII n Crevalcore (BO) web:

5 Ai miei genitori...

6 Contents 1 Introduction The WORKPAD Project Ad-hoc Routing MANET General Concepts Protocols Classification Topology-based Protocols Survey AODV - Ad-hoc On-demand Distance-Vector DYMO - Dynamic MANET On-demand DSR - Dynamic Source Routing OLSR - Optimized Link-State Routing DSDV - Destination Sequenced Distance-Vector ZRP - Zone Routing Protocol Choice of a Protocol OLSR General Functioning Core Functions Packet and Messages Packet Processing and Forwarding Messages HELLO TC MID Tables

7 Duplicate Set Link Set Neighbor Set Hop Neighbor Set MPR Set MPR Selector Set Topology Set Interface Association Set MPR Routing Auxiliary Functions Messages HNA Tables Association Set Link Layer Notification Link Hysteresis Redundant Topology Information MPR Redundancy IPv6 Considerations Parameters Security Consideration Protocols Implementations NOLSR NRLOLSRD OLSR per PocketPC OLSRD OOLSR/NOAOLSR/MOLSR QOLYESTER Choosed Implementation The NRL Implementation NRL ProtoLib Class Design

8 4.3 NRLOLSRD Class Design Usage Wireless Medium Overview of Standard Ad-hoc Problems Hidden Terminal RTS/CTS Exposed Terminal Chain Topology Medium Sharing Wireless Medium Tests Throughput Medium Sharing From Laboratory Tests To On-field Results Conclusion MANET Testing Techniques for Measurement Simulation vs. Emulation Testbed Environment Performance of Chain Topology PDA Emulators PDA Mixed Conclusion Tuning of the Protocol Conclusion Tests With Moving Devices OCTOPUS Overhead Conclusion Conclusion 94 A Tools 99

9 B OCTOPUS 100 Bibliography 103

10 Extended Abstract Una rete MANET (Mobile Ad-hoc NETwork) è una rete peer-to-peer di nodi mobili, essi sono in grado di comunicare tra di loro senza nessuna infrastruttura. I nodi possono comunicare con i rispettivi vicini (ovvero i nodi nel proprio raggio trasmissivo) direttamente con collegamenti wireless. I nodi che non sono direttamente visibili possono essere raggiunti usando i nodi intermedi come ponte per l instradamento dei pacchetti. Vista l assenza dell infrastruttura, questo tipo di reti sono adatte in tutti quegli scenari in cui è necessario dispiegare velocemente una rete, in luoghi in cui la presenza di punti di accesso fissi non è garantita. Esempio sono le applicazioni militari, e più recentemente, i sistemi cooperativi per la gestione di scenari di emergenza. In questi scenari, o più in generale in scenari di collaborazione mobile distribuita, il livello di comunicazione gioca un ruolo importante. Per questa ragione, se si vuole che il sistema cooperativo sia veramente funzionante su MANET, dobbiamo essere sicuri che lo strato di comunicazione delle MANET sia robusto ed affidabile. Inoltre occorre conoscere quale è la Qualità di Servizio che tale strato di comunicazione è realmente in gado di fornire. Infatti se non fosse considerata l effettiva Qualità di Servizio misurata sui dispositivi reali ma si considerasse solamente quella ottenuta attraverso simulazione, potremmo ottenere un sistema di coordinazione che funziona in teoria ma non nella realtà delle cose. Una prima parte del lavoro descritto in questa tesi è stata di studiare i protocolli di Routing su MANET. In molti casi, in una MANET, i nodi possono essere notebook (ultra-mobili) o PDA. Lo standard de-facto per i PDA è Windows Mobile, vista la maggiore disponibilità di questo sistema operativo nei dispositvi presenti in commercio. La maggioranza delle implementazioni di protocolli di MANET per dispositivi mobili, funzionano solamente su sistemi basati su Linux.

11 La parte più significativa di questo lavoro è stata quella di scegliere tra le differenti implementazioni quella che più si avvicina alle nostre esigenze (principalmente quella di funzionare su palmari basati su Windows Mobile) e di verificarne la Qualità di Servizio. In particolare in questo lavoro ci si è concentrati sul throughput massimo ottenibile end-to-end tra due nodi che desiderano comunicare e sul tempo necessario a ricostruire le rotte quando alcuni nodi abbandonano la MANET oppure vi entrano. Queste misure sono state calcolate sia in uno scenario statico dove i nodi non sono in movimento, sia in uno scenario dinamico dove i nodi si muovono attorno. Delle poche implementazioni che funzionano sul sistema Windows Mobile, è stato scelto il progetto della US Naval Research Laboratory 1. Non sono stati condotti test attraverso simulazioni, come altri molti studi hanno fatto, perchè non restituiscono risultati realistici. Invece è stato usato un emulatore del canale wireless. Indubbiamente i test sul campo sarebbero stati la soluzione migliore, ma essi richiedono che più persone si muovano in una determinata area, e la ripetibilità del test è compromessa. L emulazione invece è un trade-off accettabile, in cui la mobilità è emulata ma i dispositivi e la comunicazione tra loro è reale. I dispositivi hanno risieduto tutti dentro lo stesso laboratorio e questo ha generato una maggiore interferenza rispetto a quanto ottenibile sul campo. Questo aspetto è stato studiato a fondo, ed è stata trovata la relazione tra i risultati ottenuti in laboratorio e quelli sul campo. Questo lavoro è confluito in un articolo scientifico accettato ad un workshop internazionale [43] Protocolli di Routing e Implementazioni I protocolli di routing, specialmente in una MANET dove i nodi hanno propietà di mobilità, possono essere suddivisi in: topology-based position-based 1

12 I protocolli basati sulla posizione richiedono informazioni sulla posizione fisica di ogni nodo, queste informazioni devono essere acquisite tramite un servizio di localizzazione (es: il GPS). Nonostante solo recentemente, questi servizi di localizzazione sono diventati facilmente disponibili sui PDA, la comunità scientifica ha da tempo definito protocolli di questo tipo. I protocolli basati sulla topologia usano le informazioni sui collegamenti esistenti tra i nodi della rete. Questi protocolli possono essere classificati ulteriormente in base al momento in cui calcolano le rotte: proattivi reattivi ibridi Un approccio proattivo al routing nelle MANET cerca di mantenere aggiornata costantemente la topologia sottostante. L intera rete dovrebbe essere nota, in teoria, a tutti i nodi. Questo risulta in un costante overhead di traffico di routing ma non produce ritardi in fase di invio. Protocolli di esempio sono OLSR e DSDV. I protocolli reattivi cercano di costruire le rotte solamente al momento del bisogno. Se un nodo vuole iniziare una comunicazione con un altro nodo, del quale non conosce la direzione, il protocollo cerca prima di costruire il percorso. DSR, ADOV e DYMO sono tutti protocolli reattivi. I protocolli ibridi come ZRP usano una tecnica mista, usufruendo sia dei protocolli reattivi sia di quelli proattivi. Di tutti questi protocolli esistono molte implementazioni, principalmente per laptop, poche di esse sono in grado di eseguire sui PDA. I protocolli che richiedono equipaggiamenti speciali sul PDA o sul campo sono stati scartati in questo studio, in quanto lo scopo della tesi è quello di utilizzare dispositivi di facile reperibilità, e di operare in scenari di emergenza dove non esistono infrastrutture. Si è notato che i protocolli reattivi in generale forniscono prestazioni peggiori rispetto ai proattivi in termini di reattività, anche se questi ultimi consumano più banda. Durante una prima fase di ricerca, diverse implementazioni sono state analizzate. Un implementazione funzionante di AODV è WINAODV, DYMO è il progetto

13 più recente ed ancora nella fase di standardizzazione, un implementazione per PDA ancora non esiste. Sono disponibili tre implementazioni funzionanti di OLSR. Il progetto OLSRD ha una forte comunità alle spalle e può essere esteso tramite dei plug-in. OLSRD for Windows 2000 and PocketPc è un porting sui dispositivi mobili della versione laptop di OLSR. Mentre questi due progetti non sembrano funzionare correttamente sull ultima versione di Windows CE (Windows Mobile 6), l implementazione di NRL (US Naval Research Laboratory) non ha mostrato problemi nell eseguire su questo sistema. Essa inoltre offre funzionanlità di QoS, appare come un progetto maturo, e funziona su Unix/Windows/WinCE e sui software simulatori più diffusi. Emulazione e Simulazione Sia l emulazione che la simulazione forniscono un ambiente che permette di effettuare molti esperimenti in maniera più semplice rispetto alle prove sul campo. Entrambi non si escludono a vicenda. La simulazione può essere utilizzata nelle fasi iniziali: permette di testare l algoritmo e valutare le prestazioni prima di implementarlo per i disposiviti reali. La simulazione non vuole riprodurre tutte le caratteristiche dell hardware o del software reale, altrimenti ogni aspetto riprodotto dovrebbe mantenere le stesse prestazioni di quello originale. Anche se il codice per testare un algoritmo all interno di un simulatore è di facile e veloce scrittura, esso deve poi essere scartato e riscritto completamente quando si vuole passare ai dispositivi reali. L approccio degli emulatori è differente: durante l emulazione, la maggioranza dei componenti software e hardware sono reali. Tutti gli emulatori condividono la stessa idea: i sistemi software non si devono preoccupare del fatto che stanno eseguendo su un livello emulato (totalmente o parzialmente). Il software in grado di eseguire su di un emulatore può essere trasferito sul sistema reale senza nessun cambiamento. Dall altra parte, le performance possono risultare peggiori.

14 In questa tesi è stato utlizzato l emulatore OCTOPUS, esso mantiente una mappa virtuale dei nodi e delle loro posizioni. Ogni nodo virtuale è legato ad un dispositivo reale. Durante gli esperimenti, tutti i dispositivi sono stati collegati in una vera MANET. Un computer dualcore ospitava l emulatore. Durante l emulazione quando un dispositivo costruiva la rotta verso un nodo, esso mandava in broadcast pacchetti che erano poi catturati da OCTOPUS, che li smistava a tutti i vicini virtuali, in accordo con la mappa del momento. Ogni nodo non era a conoscenza del fatto che era un vicino virtuale, l algoritmo di routing non è mai stato modificato per il funzionamento nell ambiente emulato. Dopo la costruzione delle rotte le comunicazioni non passano piu tramite OCTOPUS ma sono tutti collegamenti diretti. La maggiore differenza con la realtà è proprio il fatto che le richieste di rotte passano attraverso OCTOPUS, ma siccome le richieste di pacchetti sono molto esigue rispetto ai dati di normale traffico, la percentuale di perdita di banda è irrilevante. L emulatore OCTOPUS permette agli utenti di modificare interattivamente la topologia, permettendo di scatenare eventi che non erano noti prima dell inizio dell emulazione. Altri emulatori permettono di definire un meccanismo simile ma in modo batch, prima dell inizio dell emulazione. L implementazione NRLOLSRD NRLOLSRD è un implementazione di OLSR orientata alla ricerca, fatta da NRL (US Naval Research Laboratory). Scritta in C++ seguendo il paradigma della programmazione ad oggetti, si basa su di un altro progetto: ProtoLib. ProtoLib è una libreria che permette di sviluppare applicazioni di rete, portabili tra più sistemi (Unix/Windows/CE) nonche tra più simulatori. Fornisce un interfaccia indipendente dal sistema, così NRLOLSRD non effettua nessuna chiamata di sistema. T imers, Sockets e la gestione della tabella di routing sono tutte effettuate attraverso la libreria ProtoLib. La parte di codice principale di NRLOLSRD è usata su tutti i sistemi, solamente il componente di rete dipende dal sistema sottostante. Effettuare il porting di NRLOLSRD su di un nuovo sistema si traduce semplicemente in

15 una redifinizione di alcuni componenti di ProtoLib. Per eseguire su di un dispositivo basato su Windows CE, ProtoLib utilizza il componente software RawEther che è in grado di gestire i messaggi raw e fornisce un accesso semplificato alla scheda di rete. NRLOLSRD ha alcune opzioni non standard da riga di comando, utilizzate per scopi di ricerca; ad esempio shortest path first route calculations, opzioni fuzzy e slowdown... etc.. Testing della MANET Durante la fase di test tutti i dispositivi sono nella stessa stanza, o più precisamente all interno dello stesso raggio di trasmissione, quindi si crea un contesto di condivisione della banda. Un dispositivo conforme allo standard non può ricevere o trasmettere contemporaneamente, anche se sta ricevendo un pacchetto a cui non è interessato (non è il destinatario). Se più dispositivi risiedono nella stessa area trasmissiva allora solamente uno alla volta può trasmettere dati. In una semplice topologia come la catena in cui ogni nodo è distante dal successivo esattamente quanto il raggio di trasmissione, i pacchetti viaggiano attraverso i nodi intermedi verso quello di destinazione (5.2). I pacchetti di ogni singola connessione interferiscono tra di loro durante il percorso lungo la catena, forzando il meccanismo di contesa del protocollo MAC. La topologia a catena è il componente base di tutte le altre configurazioni, ed è afflitta dai generici problemi di una rete ad-hoc (terminali nascosti ed esposti). Dal laboratorio al campo reale Una volta ottenuti i risultati dei test effettuati in laboratorio, abbiamo trovato in questo lavoro una relazione che permette di derivare da questi i probabili risultati ottenibili sul campo. Sia Q field (n) il throughput per una rete di (n + 1) nodi messi in una catena a 1,..., a n 1. Si assumi anche che ogni nodo a i sia alla massima distanza di copertura Wi-Fi dal nodo precedente a i 1 e successivo a i+1. Inoltre da altri studi teorici, si è visto che Q field (n) = α n β dove β 1.

16 Lemma. Considerando le assunzioni di cui sopra, il throughput di una catena di (n + 1) nodi ottenibile sul campo è: Q field (n) = Q lab (n) Conv(n) dove: Conv(n) = ( n 3 + 1) β 2 Gli strumenti e il laboratorio Gli strumenti utilizzati sono tutti dispositivi, disponibili facilmente sul mercato, compatibili con lo standard b. In particolare essi sono ipaq 5550 e ASUS P527, i primi con la vecchia versione di Windows CE, gli altri con l ultima versione disponibile (Windows Mobile 6). Sono stati utilizzati inoltre laptop con Windows XP, sui quali era in esecuzione l emulatore per PDA distribuito da Microsoft. É stata costruita una reale rete MANET, tutti i dispositivi non avevano attivate le funzioni di protezione del canale wireless e nemmeno le propietà di RTC/CTS. Una ulteriore macchina è stata utilizzata per eseguire l emulatore, ed è stata impostata come gateway per tutta la sottorete. Ogni dispositivo esegue la versione del protocollo idonea al propio sistema operativo. Sono stati effettuati tre tipi di test: prestazioni configurazione del protocollo test di movimento Prestazioni. Lo scopo di questo esperimento è quello di verifcare il massimo throughput ottenibile da una catena di nodi. Per misurare questo valore è stata costruita un applicazione specifica in.net (Compact Framework 2.0). Tramite il paradigma client/server, essa trasferisce un file dalla testa alla coda della catena, usando TCP/IP, e restituisce il tempo trascorso per l intera operazione. Tutti i dispositivi utilizzano il protocollo di routing con tutti i settaggi standard e un HELLO_INTERVALL pari a 0,5 secondi. L indirizzo di broadcast è impostato su OCTOPUS emula la topologia a catena e cattura tutti i pacchetti inviati all indirizzo di broadcast sopra menzionato. Ogni nodo conosce solo i due nodi vicini, cosi come specificato nella mappa

17 virtuale di OCTOPUS, e quindi manda continuamente messaggi in broadcast dichiarando solamente questi due nodi nel suo vicinato. Quando un dispositivo vuole comunicare con un altro nodo, il primo manda al secondo i pacchetti direttamente, se è possibile, altrimenti attraverso la rotta impostata dal protocollo. Il test è stato eseguito per cinque volte, sia con dispositivi reali che emulati. Le figure 6.2 e 6.1 riportano il risultato dei test. L andamento è conforme con quanto asserito in In particolare i test hanno mostrato che il valore di β della funzione Conv(n) è uguale a 1,21. La curva rossa mostra il risultato atteso sul campo, calcolato attraverso l equazione precedente. Chiaramente nel caso reale, dove i dispositivi non sono tutti quanti sotto lo stesso raggio trasmissivo, le prestazioni ricadranno all interno dell area compresa tra le due curve. Configurazione del protocollo. Ci sono molti parametri di NRLOSRD che possono essere modificati, solo alcuni di essi hanno però un forte impatto sulle prestazioni del sistema. Il focus del test è sul parametro HELLO_INTERVAL che è il più importante valore perchè influenza la reattività alla mobilità e l overhead del protocollo. L incremento o il decremento di questo parametro affligge la topologia vista da ogni nodo, e quindi di conseguenza la reattività dell intera rete. Ogni topologia di movimento può essere considerata come un incrocio di catene di nodi, quindi è sufficiente studiare una singola catena. Per questo test lo scenario è quello rappresentato in figura 5.4: i nodi nella catena sono fissi e stabili, ogni nodo conosce solo i due dispositivi vicini. Al tempo t il nodo 1 entra nel range del nodo 2, è stato misurato il tempo che intercorre tra t e il primo messaggio applicativo del nodo 6 ricevuto dal nodo 1. Per effettuare questo test è stata costruita un applicazione client/server che continuamente invia datagrammi UDP dal nodo 6 al nodo 1. Questo metodo introduce un piccolo ritardo che può essere ignorato. La misura ottenuta è stata chiamata FPT (First Packet Time) e può essere suddivisa in: F P T = 2 chain_time + build_route_time

18 dove compaiono il tempo di percorrenza della catena e il tempo necessario per calcolare la nuova rotta. Per ottenere il tempo esatto è stato usato uno sniffer di rete, su di un laptop, gli altri dispositivi della catena invece sono PDA. La tabella 6.5 mostra l andamento del valore FPT al decrescere del parametro HELLO_INTERVAL. Ogni valore riportato è la media di otto tentativi. I valori decrescono linearmente eccetto nell ultimo punto, dove l intervallo è settato su 0,1 secondi. Questo risultato è dovuto al sovraccarico della cpu del dispositivo mobile e l impossibilità di riuscire a seguire in tempo reale il traffico di rete. Questo valore dipende largamente dalla configurazione hardware del dispositivo, RAM e CPU, quindi con palmari più potenti esso può essere più basso. Tutti questi valori sono stati considerati per un singolo carico di lavoro, in uno scenario reale dove il traffico è denso e ci sono più carichi di lavoro contemporanei, è importante considerare un intervallo che permetta una veloce reattività (minore FPT) ma non sovraccarichi i dispositivi. Test di movimento. Questo tipo di test è necessario per stabilire se NRLOL- SRD sarà utilizzabile in campo reale. Nella realtà è importante non perdere le comunicazioni, nonostante la mobilità dei nodi. Nella realtà in uno scenario di emergenza, all interno di una squadra di soccorso i membri devono potersi muovere liberamente, e le comunicazioni non devono mai interrompersi, nonostante il continuo cambiamento di topologia. Per simulare questo scenario, sono state testate le tre topologie in figura 6.4, dove la linea tratteggiata mostra il movimento dei nodi. Le topologie sono state progettate in modo che ogni nodo sia sempre connesso con almeno un altro nodo, ed il nodo in movimento non esca mai dal raggio della MANET. Eśtata costruita un applicazione per Windows CE, per permettere di inviare continuamente pacchetti TCP/IP di 1000 bytes tra due nodi. Sono stati utilizzati sia dispositivi reali che emulati, per costruire topologie con un numero maggiore di nodi. Il test è stato eseguito per cinque volte, ed ogni topologia ha una durata di 300 secondi. I risultati sono stati confortanti, per ogni topologia e per ogni esecuzione la comunicazione non è mai caduta, e nessun pacchetto è andato perso. Il risultato dipende da tre fattori: l utilizzo del protocollo TCP/IP, la topologia

19 e la velocità di movimento. É evidente che ci sono più momenti in cui il nodo in movimento non ha la rotta verso il nodo destinario perchè sta entrando o uscendo dal raggio di un nodo, e quindi sta calcolando la nuova tabella di routing. Durante questi periodi la connessione TCP è in stato di attesa, incorrono ritrasmissioni, ed inizia un conto alla rovescia. Se il nodo riesce a calcolare la nuova rotta prima del timeout, allora la connessione viene risvegliata e può continuare. Per non incorrere nel timeout TCP, la velocità del movimento è un fattore cruciale: un nodo troppo veloce non può stabilire e mantenere aperta la comunicazione. Sulle topologie studiate la massima velocità raggiungibile per non incorrere nel timeout è stata di circa 18 m/s, una velocità abbastanza elevata. Linee Guida e Conclusioni Le esperienze ottenute in questa tesi sono di estrema utilità per ricercatori, ingegneri, e chiunque voglia usare delle reti MANET nei propri scenari/sistemi/applicazioni. In particolare la figura 6.2 permette di valutare le prestazioni massime che una rete di dispositivi reali può fornire; sulla base delle precedenti discussioni, qualsiasi topologia fornisce delle prestazioni che ricadono nell area del grafico compresa tra le due curve. Questo risultato è molto importante durante la fase di progettazione di applicazioni e middleware al di sopra delle reti MANET di PDA. Analogamente, i risultati del test di configurazione dei parametri aiutano la progettazione di applicazioni per contesti molto dinamici, dove bisogna tener conto della banda sprecata con l overhead, della reattività della rete, e della configurazione dei dispositivi. Il test sul movimento dei nodi, permette di affermare che sarà possibile costruire una rete MANET affidabile con nodi in movimento al suo interno, ma solamente a certe condizioni. Se un nodo si sposta, ad esempio sopra di un veicolo, raggiungendo una velocità superiore ai 65 km/h, non è garantita la buona riuscita delle sue comunicazioni. Si può concludere che nonostante questa tesi abbia prodotto e testato un af-

20 fidabile e robusto strato di rete, ulteriore ricerca e sviluppo sono necessari per superare i problemi attuali.

21 Chapter 1 Introduction A Mobile Ad hoc NETwork (MANET) is a peer-to-peer network of mobile nodes capable to communicate with each other without an underlying infrastructure. Nodes can communicate with their own neighbors (i.e., nodes in radio-range) directly by wireless links. Anyway, non-neighboring nodes can equally communicate by using other intermediate nodes as relays which forward packets toward destinations. The lack of a fixed infrastructure makes this kind of network suitable in all scenarios where it is needed to deploy quickly a network but the presence of access points is not guaranteed. Examples are military applications, and more recently, cooperative systems for emergency management or pervasive healthcare, as well as many other scenarios, which require highly dynamic node mobility. In any scenario of distributed and mobile collaboration on MANETs, we believe that the communication layer is very important. In order to design and deploy a really-working coordination system, we need to provide at low level a MANET communication layer that is robust and reliable. Moreover, we need to know what Quality of Service (QoS, e.g, the throughput) such MANET communication layer can really furnish. Indeed, if we did not consider actual provided QoS but we base on only simulated/theoretically-calculated values, we would build up coordination systems that are not really working. In most of MANET scenarios (such as emergency management ones), nodes may be both (ultra-mobile) laptop and PDAs. Since we believe that de-facto PDA standard is Windows Mobile (due to the widespread availability of this operating system on commercial devices), we argue that it would be worthy to

22 1.1 The WORKPAD Project 3 perform QoS evaluation of possible MANET communication layers on such an operating system. But currently many of available MANET implementations for PDAs are running only on Linux-based hacked PDAs and not at all on Windows Mobile. The aim of this graduate thesis is to design and deploy a really working communication module for MANETs of PDAs. Moreover, to know what Quality of Service such communication layer can really attain. 1.1 The WORKPAD Project The results obtained in this thesis will be immediately used in Europeanfunded project WORKPAD. The WORKPAD project aims at providing a service oriented software and communication infrastructure supporting operators on response and short-term recovery phases. It advocates the use of a 2-level infrastructure based on the following considerations. In complex emergency scenarios, different teams, belonging to different organizations, need to collaborate. Each team member is equipped with handheld devices (PDAs) and communication technologies, and should carry on specific tasks. In such a way, we can see the whole team as carrying on a process, and the different teams (of the different organizations) collaborate through the interleaving of all the different processes. In turn, each team is supported by some back-end service providers, and, in order to coordinate between teams, the different service providers need to cooperate at an inter-organizational level. Thus, WORPKPAD distinguishes between back-end and front-end communities, which both are organized as peer-to-peer (P2P) networks, where each member can both request and provide advanced services to other members within the community. The conceptual architecture at the WORKPAD front-end consists of three layers named, Data Storages and Connection Management, Front-end Middleware and User Applications. Each layer consists of several components. Although the architecture shows various components at the front-end, not all

23 1.1 The WORKPAD Project 4 components have been deployed in every front-end device. Instead, the deployment of these components has been customized, depending on the capability of devices and the role of the team member who controls the device. Team leader and generic nodes are equipped with PDAs. Data Storage and Communication Layer It includes the MANET communication module implementing MANET multi-hop communication and Lightweight Storages for data and knowledge storing (in a local or distributed fashion). Current operating systems do not allow communication among non-neighboring wireless peers. The coordinator device, in addition, holds a further module named Communication Front-end/Backend to handle connections with back-end (by means of UMTS, etc. and switching to TETRA when needed). Front-end Middleware It is used to adaptively control processes to be conducted during emergency managements. This component has to manage processes in an adaptive manner on the basis of contextual information. It includes also geo-data and information retrieved from back-end and updated by the front-end teams. Middleware layer at generic nodes are really simpler, as it consists only of specific modules whose purpose is interacting with coordinator counterparts. As required, all the front-end system is deployed on the MANET, in order to be able to run also in disconnected mode and/or requiring low bandwidth for accessing, when needed, to the back end. User Applications Specific services offered by the devices are deployed in the basis of the capabilities and skills of the corresponding team member This work realized the communication module of the Data Storage and Communication Layer, and provided the basic block of the entire front-end. More information can be found in [8].

24 If someone wants a sheep, then that means that he exists. Antoine de Saint-Exupery

25 Chapter 2 Ad-hoc Routing 2.1 MANET Wireless networks is an emerging new technology that will allow users to access information and services electronically, regardless of their geographic position. Wireless networks can be classified in two types: infrastructured networks and infrastructureless (ad-hoc) networks. Infrastructured networks have fixed and wired gateways (called base station). A mobile host communicates with a base station (or access point) which is whithin its communication radius. The mobile unit can move geographically while it is communicating. When it goes out of range of one base station, it connects with new base station and starts communicating through it. This is called handoff. In contrast to infrastructure based networks, in MANETs (Mobile Ad-hoc NETworks) all nodes are mobile and can be connected dynamically in an arbitrary manner. Ad-hoc netwoks can work without any pre-existing infrastructure. All nodes of these networks behave as routers and take part in discovery and maintenance of routes to other nodes in the network. Ad-hoc networks are becoming important in consideration of their flexibility and easy portability in various environments. MANETs are very useful in emergency search-andrescue operations, meetings or conventions where people wish to share information quickly, and data acquisition operations in inhospitable terrain.

26 2.2 General Concepts General Concepts In order to enable communication between any two nodes, a routing protocol is employed. The abstract task of the routing protocol is to discover the topology (and, if the network is dynamic, continuing changes to the topology) to ensure that each node is able to acquire a recent image of the network for constructing routes. MANETs have several particular features that limit the achievable performance of data communications, such as node mobility, radio link problems, energy constrained operation and the lack of infrastructure itself. A key element that influences the network efficiency is the routing protocol. Ideally, a MANET routing protocol should be able to provide optimal routes quickly, even in the case of link failures in an active path, with minimum impact on data latency, available bandwidth and device power consumption for any data traffic pattern. Because the conventional routing protocols do not meet our demands, we need a new routing protocol. These are some of the features that are desiderable: Distribuited operation: the protocol should be distribuited and not dependent on a centralized controlling node Loop free: to avoid any waste of bandwidth or CPU consumption Unidirectional link support: the radio environment can cause the formation of a unidirectional links Security: we need some sort of a preventive security measures Power aware: the node in a MANET can be a laptop or thin clients, such as PDAs, that are very limited in battery power 2.3 Protocols Classification Routing protocols can be divided into different classes based on several criteria. First of all, we can divide the protocols in link-state, distancevector or source-routing. This is a classification based on the selecting process of the forwarding path. Distance-vector routing protocol uses distance or hop count as its primary metric for determining the best forwarding path. Normally these kind of protocols use a variant of the Bellman-Ford algorithm to find the path, every

27 2.3 Protocols Classification 8 node knows only its neighbors and nodes reachable by them. Link-state protocols track the status and connection type of each link and produce a calculated metric. Link-state protocols know whether a link is up or down and how fast it is and calculate a cost to get there. Linkstate protocols will take a path which has more hops, but that uses a faster medium, instead of a path using a slower medium with fewer hops. These protocols use the Dijkstra algorithm to find the route and each node knows the entire network. Source routing means that each packet must carry the complete path. The routing decision is therefore made at the source. The advantage with this approach is that it is very easy to avoid routing loops. The disadvantage is that each requires a slight overhead. Distance-vector protocols each router periodically sends to his neighbors how far is the destination the next hop to get there install routes directly in tables Link-state protocols each router sends information about links to which it is attached the state of these links, which is flooded throughout the network every router calculates its routing table Link-state protocols are also known as table-driven, instead the distancevector protocols are also called event-driven. Routing protocols, specially in a MANET where the node has a mobility property, can be divided in Topology-based Position-based (or Geographical) Topology-based protocols use information about the existent link beetween each node in the network, instead, the position-based routing need information about the real physic position of a node; this information have to be acquired with a localization service. Localization is an external service such as sensor grid or GPS. For the purpose of this project this kind of protocols are not the right choice, because we want to work in an emergency scenarious, where probably there isn t a localization service already configured and

28 2.4 Topology-based 9 ready to work. In addition we want to use a common device like PDA, without a special hardware on board. Figure 2.1: ad-hoc routing classification 2.4 Topology-based A different classification can be done by the time of route calculation : Proactive

29 2.5 Protocols Survey 10 Reactive Hybrid A proactive approach to MANET routing seeks to maintain a constantly updated topology understanding. The whole network should, in theory, be known to all nodes. This results in a constant overhead of routing traffic, but no initial delay in communication. Reactive protocols seek to set up routes on-demand. If a node wants to initiate a communication with a node to which it has no route, the routing protocol will try to establish such a route. The idea of hybrid protocols is using both proactive and reactive approaches, each one with a different scope. The network is divided into smaller groups (or clusters). Then, a proactive paradigm is used to collect information about nodes within the cluster, while a reactive paradigm is used for communications with nodes in distant clusters. 2.5 Protocols Survey AODV - Ad-hoc On-demand Distance-Vector AODV is an ad-hoc routing protocol for discovering routes between hosts, potentially over multiple hops, as they are needed, and only for the duration that they are needed. It is designed to take into account the problems of the limited transmission range and node mobility, and hence a continually changing network topology, which is found in mobile ad-hoc networks. The protocol ensures that routing loops do not occur, and it also attempts to find the shortest route possible. When a node needs to send a message to another node that is not its direct neighbor, it broadcasts a route request (RREQ) message to initiate the discovery of a route. The RREQ message contains several important bits of information: the source IP address, the destination IP address, the lifespan of the message and a sequence number which uniquely identifies messages from this source. When the neighbors of the node, which initiated the Route Request, receive the message, they can do one of two the following things: if they know a route to the destination they can unicast a route reply (RREP) message back to the source node. Each node along the path that

30 2.5.1 AODV - Ad-hoc On-demand Distance-Vector 11 the Route Request was propagated updates its routing table to mark the node from which it received the Route Reply as the next hop for the new route. rebroadcast the route request to their neighbors If no reply is received within a specified amount of time, the source node issues a new route request. Each mobile node in the network maintains a route table entry for each destination of interest in its route table. Each entry contains the following info: destination next hop number of hops destination sequence number active neighbors for this route expiration time The other useful information contained in the entries along with source and destination sequence numbers is called soft-state information associated to the route entry. The info about the active neighbors for this route is maintained so that all active source nodes can be notified when a link along a path to the destination breaks. Advantages: minimal space complexity maximum utilization of the bandwidth simple loop-free routes coping up with dynamic topology and broken links loop-free routes highly scalable Disadvantages: no reuse of routing info no support for high throughput routing metrics high route discovery latency (specially for large network)

31 2.5.2 DSR - Dynamic Source Routing 12 DYMO - Dynamic MANET On-demand The DYMO routing protocol is successor to AODV protocol and shares many of its benefits. It is, however, slightly easier to implement and designed with future enhancements in mind. DYMO can work as both a proactive and as a reactive routing protocol. It operates very similarly to AODV, but requires only the most basic route discovery and maintenance procedures. Most of the optimizations available in AODV should be applicable to DYMO as well. It is still in the standardization stage. The DYMO routing protocol is designed for stub or disconnected MANETs. DYMO handles a wide variety of mobility patterns by dynamically determining routes on-demand. DYMO also handles a wide variety of traffic patterns. In networks with a large number of routers, DYMO is best suited for sparse traffic scenarios where routers forward packets to with only a small portion of the other DYMO routers, due to the reactive nature of route discovery and route maintenance. DYMO is applicable to memory constrained devices, since minimal routing state is maintained in each DYMO router. Only routing information related to active sources and destinations is maintained, in contrast to other more proactive routing protocols that require routing information to all routers within the routing region be maintained. DYMO only utilizes bidirectional links DSR - Dynamic Source Routing DSR is a reactive ad-hoc routing protocol. It utilises source routing, in which a sender constructs a source route in the packets header containing the address of each hop through which the packet should be forwarded. A key advantage of source routing is that intermediate hops do not need to maintain routing information in order to route the packets they receive, since the packets themselves already contain all the necessary routing information. Mobile hosts participating in the network maintain a route cache, in which they cache source routes that they have learned. Caching of negative information in the form of unreliable links is also supported via a temporary black-listing mechanism. Entries in the cache have a certain expiration period, after which the

32 2.5.2 DSR - Dynamic Source Routing 13 entry is deleted. DSR contains 2 phases: route discovery (find a path) route maintenance (maintain a path) Route discovery and route maintenance only answer on request. If a node has in its route cache a route to the destination node, this route is immediately used. If not, the initiator node sends a route request (RREQ) packet by flooding the network. If a node is the target of the route discovery process, it returns a route reply (RREP) message to the initiator. The RREP contains a list of the best path from the initiator to the target. In DSR every node is responsible for confirming that the next hop in the source route receives the packet. Also each packet is only forwarded once by a node. If a packet can t be received by a node, it is retransmitted up to some maximum number of times until a confirmation is received from the next hop. Only if retransmission results then in a failure, a route error (RERR) message is sent to the initiator. After sending a RERR message, a node may attempt to salvage the data packet that caused the error rather than discarding it. To attempt to salvage a packet, the node sending a RERR searches its own route cache for a route from itself to the destination. If such a route is found, the node may salvage the packet by replacing the original source route on the packet with the route from its route cache. When salvaging a packet in this way, the packet is also marked as having been salvaged, to prevent a single packet being salvaged multiple times. DSR does not currently support true multicast routing, but does support an approximation of this that is sufficient in many network contexts.dsr supports the controlled flooding of a data packet to all nodes in the ad-hoc network that are within some specified number of hops of the originator. Advantages: bandwidth saving (beacon-less) on demand performs well in static and low-mobility environments Disadvantages: it does not locally repair a broken link

33 2.5.3 OLSR - Optimized Link-State Routing 14 cache information could result inconsistencies sometimes the connection setup delay is higher than in table-driven protocols flooding the network can cause collusions poor performance with fast node mobility poor performance in a large network (more than 200 nodes) no multicast routing OLSR - Optimized Link-State Routing OSLR is a proactive routing protocol for ad-hoc networks that is derived by the link-state protocol. With respect to link-state it reduces the size of the signalling packets and minimize the flooding of its control traffic. To do this OLSR uses only selected nodes, called multi point relays (MPRs), to broadcast signalling messagges in the networks. The protocol is designed to work in a complete distribuited manner and thus does not depend upon any central entity. OLSR uses two kinds of the control message: HELLO and TC (Topology Control). HELLO messages are sent periodically and are used for finding the information about the link status and the host s neighbors. With the information contained in a HELLO message, each node can select a set of nodes that act as its MPR. TC messages are used for broadcasting information about own advertised neighbors. Hello messages are sent only one hop away but the TC messages are broadcasted throughout the entire network. The TC messages are broadcasted periodically and only the MPR hosts can forward the TC messages. The next chapter contains a detailed explanation of the protocol DSDV - Destination Sequenced Distance-Vector The DSDV routing protocol is a proactive routing protocol which is a modification of conventional Bellman-Ford routing algorithm. This protocol adds a new attribute, sequence number, to each route table entry at each node. Each node in the network maintains routing table for the transmission of the packets and also for the connectivity to different stations in the network. These stations list for all the available destinations, and the number of hops required to reach each destination in the routing table. The routing entry is tagged with a sequence number which is originated by the destination station.

34 2.5.4 DSDV - Destination Sequenced Distance-Vector 15 In order to maintain the consistency, each station transmits and updates its routing table periodically. The data broadcast by each node will contain its new sequence number and the following information for each new route: the destination address the number of hops required to reach the destination the new sequence number, originally stamped by the destination The routing tables will contain the sequence number created by the transmitter and hence the most new destination sequence number is preferred as the basis for making forwarding decisions. The broken link may be detected by the layer 2 protocol, which may be described as infinity. When the route is broken in a network, then immediately that metric is assigned an infinity metric there by determining that there is no hop and the sequence number is updated. Sequence numbers originating from the mobile hosts are defined to be even number and the sequence numbers generated to indicate infinity metrics are odd numbers. The broadcasting of the information in the DSDV protocol is of two types namely: full dump and incremental dump. Full dump broadcasting will carry all the routing information while the incremental dump will carry only information that has changed since last full dump. Irrespective of the two types, broadcasting is done in network protocol data units (NPDU). Full dump requires multiple NPDU s while incremental requires only one NPDU to fit in all the information. When an information packet is received from a node, it compares the sequence number with the available sequence number for that entry. If the sequence number is larger, then it will update the routing information with the new sequence number else if the information arrives with the same sequence number it looks for the metric entry and if the number of hops is less than the previous entry the new information is updated (if information is same or metric is more then it will discard the information). Advantages are: loop free paths Count to infinity problem is reduced

35 2.5.5 ZRP - Zone Routing Protocol 16 it avoids extra traffic with incremental updates instead of full dump updates DSDV maintains only the best path instead of maintaining multiple paths to every destination Disadvantages: wastage of bandwidth due to unnecessary advertising of routing information even if there is no change in the network topology. it does not support multi path Routing it is difficult to determine a time delay for the advertisement of routes it is difficult to maintain the routing table s advertisement for larger network ZRP - Zone Routing Protocol The Zone Routing Protocol, as its name could suggest, is based on the concept of zones. A routing zone is defined for each node separately, and the zones of neighboring nodes overlap. The size of a zone is not determined by geographical measurement, as one might expect, but is given by a radius of length, where ϕ is the number of hops to the perimeter of the zone. The nodes on the perimeter of the zone (i.e. with a hop count equal to ϕ ) are referred to as peripheral node, nodes with hop count less than ϕ are interior nodes. Obviously a node needs to first know about it is neighbors before it can construct a routing zone and determine it s peripheral nodes. In order to learn about it s direct neighbors, a node may use the media access control (MAC) protocols directly. Alternatively, it may require a Neighbor Discovery Protocol (NDP). Such a NDP typically relies on the transmission of hello beacons by each node. If a node receives a response to such a message, it may note that it has a direct point-to-point connection with this neighbor. The NDP is free to select nodes on various criteria, such as signal strength or frequency/delay of beacons etc. Once the local routing information has been collected, the node periodically broadcasts discovery messages in order to keep its map of neighbors up to date. The ZRP protocol is a framework composed by different components: Intrazone Routing Protocol (IARP)

36 2.5.5 ZRP - Zone Routing Protocol 17 Interzone Routing Protocol (IERP) Broadcasting Routing Protocol (BRP) The IARP protocol is used by a node to communicate with the interior nodes of it is zone and as such is limited by the zones radius (the number of hops from the node to it s peripheral nodes). This protocol is responsible for determining the routes to the peripheral nodes and is commonly a proactive protocol. Communication between the different zones is guarded by the Interzone Routing Protocol (IERP) and provides routing capabilities among peripheral nodes only. Route queries within the IERP are issued on demand, that is only when a request for a route is made. The delay caused by the route discovery is minimized through the use of bordercasting, an approach in which the node does not submit the query to all local nodes, but only to it is peripheral nodes. Furthermore, a node does not send a query back to the nodes the request came from, even if they are peripheral nodes. The Bordercast Resolution Protocol, or BRP, is used in the ZRP to direct the route requests initiated by the global reactive IERP to the peripheral nodes, thus removing redundant queries and maximizing efficiency. In doing so, it utilizes the map provided by the local pro-active IARP to construct a bordercast tree. Unlike IARP and IERP, it is not so much a routing protocol, as it is packet delivery service. The BRP keeps track of which nodes a query has been delivered to, so that it can prune the bordercast tree of nodes that have already received (and relayed) the query. When a node receives a query packet for a node that does not lie within it is local routing zone, it constructs a bordercast tree so that it can forward the packet to it s neighbors. These nodes, upon receiving the packet, reconstruct the bordercast tree so that they can determine whether or not it belongs to the tree of the sender. Each component works independently on the other and they may use different technologies in order to maximize efficiency in their particular area. For example, a reactive protocol such as AODV might be used as the IARP, while the IERP is most commonly a pro-active protocol such as OLSR. Advantages are: it is locally proactive and globally reactive

37 2.6 Choice of a Protocol 18 Figure 2.2: ZRP, structure scalable Disadvantages are: require an implementation of two routing protocol too complex to be optimized and set up quickly 2.6 Choice of a Protocol The choice was made considering the environments like the WORKPAD s one where a group of 10 people works in a limited range. After studying available protocols and the results stemming from previous studies, the chosen for this project was OLSR. Hybrid protocols are not suitable because too complex; in particular ZRP uses 2 different routing protocols inside and a third one for broadcast. In theory reactive protocols are the most suitable for dynamics environments, although, generally speaking, they have worse performance than proactive ones in term of reactiveness to changes in the topology. In an emergency scenario, time has an important role, the reactive protocols build the routes on-demand so an initial delay occurs before the start of the communication. This time can be not tollerated in our scenario.

38 2.6 Choice of a Protocol 19 Among proactive protocols, OLSR has been chosen mainly because it is a linkstate type protocol that guarantees better preformances and a better network control than distance-vector protocol.

39 When I took office, only high energy physicists had ever heard of what is called the Worldwide Web... Now even my cat has its own page. Bill Clinton

40 Chapter 3 OLSR 3.1 General Functioning The OLSR protocol is descried in RFC 3626, written by the Network Working Group in october The Optimized Link State Routing Protocol (OLSR ) is developed for mobile ad-hoc networks. It operates as a table driven, proactive protocol so it exchanges topology information with other nodes of the network regularly and the routes are always up to date. The OLSR is an optimization of a pure link state protocol. The topological changes cause the flooding of the informations to all available hosts in the network, to reduce the possible overhead protocol uses Multipoint Relays (MPRs). The idea of MPRs is to reduce flooding of broadcasts by reducing redundant retransmissions in the same region, more details about MPR can be found later in the specific section. The protocol is particularly suited for large and dense networks, as the optimization done using MPRs works well in this context. The larger and more dense a network, the more optimization can be achieved as compared to the classic link state algorithm. OLSR uses two kinds of the control message: HELLO and TC (Topology Control). HELLO messages are sent periodically and are used for finding the information about the link status and the host s neighbours. By the information contained in a HELLO message, each node can select a set of nodes that

41 3.1 General Functioning 22 act as its MPR. TC messages are used for broadcasting information about own advertised neighbours. Hello messages are sent only one hop away but the TC messages are broadcasted throughout the entire network. The TC messages are broadcasted periodically and only the MPRs hosts can forward such messages. The link in the ad-hoc network can be either unidirectional or bidirectional so the host must know this information about the neighbours. When the first host receives the HELLO message from the second host, it sets the second host status to asymmetric in the routing table. When the first host sends a HELLO message and includes that, it has the link to the second host as asymmetric, the second host set first host status to symmetric in own routing table. Finally, when second host send again HELLO message, where the status of the link for the first host is indicated as symmetric, then first host changes the status from asymmetric to symmetric. In the end both hosts knows that their neighbour is alive and the corresponding link is bidirectional. OLSR is designed to work in a completely distributed manner and does not depend on any central entity. The protocol does not require reliable transmission of control messages: each node sends control messages periodically, and can therefore sustain a reasonable loss of some such messages. Such losses occur frequently in radio networks due to collisions or other transmission problems. Also, OLSR does not require sequenced delivery of messages. OLSR does not need any changes to the format of IP packets. Thus any existing IP stack can be used as is: the protocol only interacts with routing table management. OLSR is modularized into a core of functionality, which is always required for the protocol to operate, and a set of auxiliary functions. The core specifies, in its own right, a protocol able to provide routing in a stand-alone MANET. Auxiliary function provides additional functionality, which may be applicable in specific scenarios. OLSR itself does not perform packet forwarding. Rather, it maintains the routing table in the underlying operating system, which is assumed to be forwarding packets as specified in RFC 1812.

42 3.2 Core Functions Core Functions The core functionality of OLSR specifies the behavior of a node equipped with OLSR interfaces participating in the MANET and running OLSR as routing protocol. This includes: packet format and forwarding link sensing neighbor detection topology diffusion route calculation MPR computation Packet and Messages OLSR communicates using a unified packet format for all data related to the protocol. The purpose of this is to facilitate extensibility of the protocol without breaking backwards compatibility. This also provides an easy way of piggybacking different types of information into a single transmission. Each packet encapsulates one or more messages. The messages share a common header format, which enables nodes to correctly accept and retransmit messages of an unknown type. Messages can be flooded onto the entire network, or flooding can be limited to nodes within a diameter (in terms of number of hops) from the originator of the message. Thus transmitting a message to the neighborhood of a node is just a special case of flooding. Packets in OLSR are communicated using UDP. Port 698 has been assigned by IANA for exclusive usage by the OLSR protocol. The basic layout of any packet in OLSR is as follows (omitting IP and UDP headers): packet header packet length: the length in bytes of the packet packet sequence number (PSN): must be incremented by one each time a new OLSR packet is trasmitted message header message type: this field indicates which type of message is to be found in the message part. Message types in the range of are reserved

43 3.2.1 Packet and Messages 24 Figure 3.1: OLSR packet vtime: this field indicates for how long time after reception a node must consider the information contained in the message as valid, unless a more recent update to the information is received. The formula used to compute the validity time in seconds is: validity_time = c (1 + a 16 ) 2b where a is the integer represented by the four highest bits of vtime field and b the integer represented by the four lowest bits. The proposed constant for the scaling factor c is 1 16 seconds message size: this gives the size of this message, counted in bytes and measured from the beginning of the message type field and until the beginning of the next message type field (or, if there are no following messages, until the end of the packet) originator address: this field contains the main address of the node, which has originally generated this message. field must never be changed in retransmissions The originator address

44 3.2.1 Packet and Messages 25 time to live (TTL): this field contains the maximum number of hops a message will be transmitted. Before a message is retransmitted, this field must be decremented by 1. Thus, by setting this field, the originator of a message can limit the flooding radius hop count: contains the number of hops a message has attained. Before a message is retransmitted, this counter must be incremented by 1. Initially, this is set to 0 by the originator of the message message sequence number: while generating a message, the originator node will assign a unique identification number to each message. The sequence number is increased by 1 for each message originating from the node. Message sequence numbers are used to ensure that a given message is not retransmitted more than once by any node Packet Processing and Forwarding It should be noted that processing and forwarding messages are two different actions, conditioned by different rules. Processing relates to using the content of the messages, while forwarding is related to retransmitting the same message for other nodes of the network. Upon receiving a basic packet, the host should perfom the algorithm described in 3.2: The required message types for the core functionality of OLSR are: HELLO: is used to perform link sensing, neighbor detection and MPR signaling TC: is needed for topology declaration (advertisement of link states) MID: to declaring the presence of multiple interfaces on a node As a basic implementation requirement, synchronization of control messages should be avoided. As a consequence, OLSR control messages should be emitted such that they avoid synchronization. To avoid such synchronizations, the following simple strategy for emitting control messages is proposed. A node should add an amoun of jitter to the interval at which messages are generated. The jitter must be a random value selected from the interval [0,MAXJITTER]. Jitter should also be introduced when forwarding messages.

45 3.2.2 Messages 26 Figure 3.2: packet processing algorithm Messages HELLO This kind of message is excanghed for link sensing, neighborhood detection and MPR selection signalling tasks. To accommodate for future extensions, an approach similar to the overall packet format is taken. Figure 3.3 shows the proposed format of a HELLO message. This is sent as the data-portion of the general packet format described previously, with the message type field set to HELLO_MESSAGE, the time to live set to 1 and vtime set accordingly to the value of NEIGHB_HOLD_TIME parameter.

46 3.2.2 Messages 27 Figure 3.3: HELLO message Fields description: reserved: this field must be set to "0" htime: this field specifies the HELLO emission interval used by the node on this particular interface, the time before the transmission of the next HELLO. The formula used to compute the emission interval time in seconds is: HELLO_emission_interval = c (1 + a 16 ) 2b where a is the integer represented by the four highest bits of htime field and b the integer represented by the four lowest bits. The proposed constant for the scaling factor c is 1 16 seconds. This field is set such that it corresponds to the value of the node s HELLO_INTERVAL parameter willingness: this field specifies the willingness of a node to carry and forward traffic for other nodes. A node with willingness WILL_NEVER must never be selected as MPR by any node. A node with willingness WILL_- ALWAYS must always be selected as MPR. By default, a node should advertise a willingness of WILL_DEFAULT link code: this field specifies information about the link between the interface of the sender and the following list of neighbor interfaces. It also specifies information about the status of the neighbor. If the link code value is less than or equal to 15, then it must be interpreted as holding

47 3.2.2 Messages 28 two different fields, of two bits each, like in the Figure 3.4. Figure 3.4: link code The following four link types are required by OLSR : UNSPEC_LINK: indicating that no specific information about the links is given ASYM_LINK: indicating that the links are asymmetric (i.e.,the neighbor interface is heard ) SYM_LINK: indicating that the links are symmetric with the interface LOST_LINK: indicating that the links have been lost The following three neighbor types are required by OLSR : SYM_NEIGH: indicating that the neighbors have at least one symmetrical link with this node MPR_NEIGH: indicating that the neighbors have at least one symmetrical link and have been selected as MPR by the sender NOT_NEIGH: indicating that the nodes are either no longer or have not yet become symmetric neighbors link message size: the size of the link message, counted in bytes and measured from the beginning of this field and until the next link code field (or,if there are no more link types, until the end of the message) neighbor interface address: the address of an interface of a neighbor node A node must perform link sensing on each interface, in order to detect links between the interface and neighbor interfaces. Furthermore, a node must advertise its entire symmetric 1-hop neighborhood on each interface in order to perform neighbor detection. HELLO messages must never be forwarded. A HELLO message can be partial (e.g., due to message size limitations, imposed by the network), the rule being the following, on each interface: each link and each neighbor node must be cited at least once within a predetermined refreshing period (REFRESH_INTERVAL). To keep track of fast con-

48 3.2.2 Messages 29 Figure 3.5: On receiving HELLO message, basic algorithm nectivity changes, a HELLO message must be sent at least every HELLO_IN- TERVAL period, smaller than or equal to REFRESH_INTERVAL. Upon receiving a HELLO message, a node should calcolate its MPRs and update its tables link set, neighbor set and 2-hop neighbor set, following the algorithm described in Figure 3.5. TC In order to exchange the topological information the host that were selected as MPR need to sent the Topology Control (TC) message. The TC messages are broadcasted throughout the network and only MPR are allowed to forward

49 3.2.2 Messages 30 Figure 3.6: TC message TC messages. Routes are constructed through advertised links and links with neighbors. A TC message is sent by a node in the network to accomplish the topology discovery task; such messages are periodic in order to provide sufficient information to enable routing. The proposed format of a TC message is shown in Figure 3.6. This is sent as the data-portion of the general message format with the message type set to TC_MESSAGE. The time to live should be set to 255 (maximum value) to diffuse the message into the entire network and vtime set accordingly to the value of TOP_HOLD_TIME parameter. Fields description: advertised neighbor sequence number (ANSN): A sequence number is associated with the advertised neighbor set. Every time a node detects a change in its advertised neighbor set, it increments this sequence number. advertised neighbor main address: this field contains the main address of a neighbor node. All main addresses of the advertised neighbors of the originator node are put in the TC message. If the maximum allowed message size (as imposed by the network) is reached while there are still advertised neighbor addresses which have not been inserted into the TC message, more TC messages will be generated. reserved: this field is reserved, and must be set to "0" In order to build the topology information base, each node, which has been selected as MPR, broadcasts TC messages. TC messages are flooded to all nodes in the network and take advantage of MPR mechanism. MPRs enable a better scalability in the distribution of topology information. When the advertised link set of a node becomes empty, this node should still send (empty) TC

50 3.2.2 Messages 31 Figure 3.7: MID message messages during the a duration equal to the validity time of its previously emitted TC message, in order to invalidate the previous TC messages. The list of addresses can be partial in each TC message but parsing of all TC messages describing the advertised link set of a node must be complete within a certain refreshing period (TC_INTERVAL). MID For single OLSR interface nodes, the relationship between an OLSR interface address and the corresponding main address is trivial: the main address is the OLSR interface address. For multiple OLSR interface nodes, the relationship between OLSR interface addresses and main addresses is defined through the exchange of Multiple Interface Declaration (MID) messages. Each node with multiple interfaces must announce, periodically, information describing its interface configuration to other nodes in the network. This is accomplished through flooding a MID message to all nodes in the network through the MPR flooding mechanism. The Figure 3.7 shows the format of this message. This is sent as the dataportion of the general packet format, with the message type set to MID_MES- SAGE. The time to live should be set to 255 (maximum value) to diffuse the message into the entire network and vtime set accordingly to the value of MID_HOLD_TIME parameter. OLSR interface address field contains the address of an OLSR interface of the node, excluding the nodes main address (which already indicated in the originator address field of the packet). Each node in the network maintains interface information about the other nodes in the network. These informations is used for routing table calculations. Specifically, multiple interface declaration associates multiple inter-

51 3.2.3 Tables 32 faces to a node (and to a main address) through populating the interface association table in each node. A node which has only a single interface address participating in the MANET must not generate any MID message. The list of addresses can be partial in each MID message but parsing of all MID messages describing the interface set from a node must be complete within a certain refreshing period (MID_INTERVAL) Tables Duplicate Set Upon receiving a basic packet, a node examines each of the message headers. Based on the value of the message type field, the node can determine the fate of the message. A node may receive the same message several times. Thus, to avoid re-processing of some messages which were already received and processed, each node maintains a duplicate set. In this set, the node records information about the most recently received messages where duplicate processing of a message is to be avoided. For such a message, a node records a duplicate tuple : (D_addr, D_seq_num, D_retransmitted, D_if ace_list, D_time) where D_addr is the originator address of the message, D_seq_num is the message sequence number of the message, D_retransmitted is a boolean indicating whether the message has been already retransmitted, D_iface_list is a list of the addresses of the interfaces on which the message has been received and D_time specifies the time at which a tuple expires and must be removed (DUP_HOLD_TIME + current time). Link Set The link set table is populated with information on links to neighbor nodes. The process of populating this set is denoted link sensing and is performed using HELLO message exchange, updating a local link information base in each node. Each node should detect the links between itself and neighbor nodes. Uncertainties over radio propagation may make some links unidirectional.

52 3.2.3 Tables 33 Consequently, all links must be checked in both directions in order to be considered valid. A link is described by a pair of interfaces: a local and a remote interface. For the purpose of link sensing, each neighbor node (more specifically, the link to each neighbor) has an associated status of either symmetric or asymmetric. Symmetric indicates, that the link to that neighbor node has been verified to be bi-directional, i.e., it is possible to transmit data in both directions. Asymmetric indicates that HELLO messages from the node have been heard however it is not confirmed that this node is also able to receive messages. A node records a set of link tuple : (L_local_if ace_addr, L_neig_if ace_addr, L_SY M_time, L_ASY M_time, L_time) where L_local_iface_addr is the interface address of the local node, L_neig_- iface_addr is the interface address of the neighbor node, L_SYM_time is the time until which the link is considered symmetric, L_ASYM_time is the time until which the neighbor interface is considered heard, and L_time specifies the time at which this record expires and must be removed. This information is used when declaring the neighbor interfaces in the HELLO messages. L_- SYM_time is used to decide the Link Type declared for the neighbor interface. If L_SYM_time is not expired, the link must be declared symmetric. If L_SYM_- time is expired, the link must be declared asymmetric. If both time values are expired, the link must be declared lost. Neighbor Set A node records a set of neighbor tuple (N_neighbor_main_addr, N_status, N_willingness) N_neighbor_main_addr is the main address of a neighbor, N_status specifies if the node is NOT_SYM or SYM. N_willingness in an integer between 0 and 7, and specifies the node s willingness to carry traffic on behalf of other nodes. The link set keeps the information about the links, while the neighbor set keeps the information about the neighbors. There is a clear association between those two sets, since a node is a neighbor of another node if and only if there is at least one link between the two nodes.

53 3.2.3 Tables 34 2-Hop Neighbor Set The 2-hop neighbor set table describes the set of nodes which have a symmetric link to a symmetric neighbor. This information set is maintained through periodic exchange of HELLO messages. A node records a set of "2-hop tuple": (N_neighbor_main_addr, N_2hop_addr, N_time) describing symmetric links between its neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr is the main address of a neighbor, N_- 2hop_addr is the main address of a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and N_time specifies the time at which the tuple expires and must be removed. MPR Set A node maintains a set of neighbors which are selected as MPR. Their main addresses are listed in the MPR set. MPR Selector Set A node records a set of MPR selector tuple : (M S_main_addr, M S_time) describing the neighbors which have selected this node as a MPR. MS_main_- addr is the main address of a node, which has selected this node as MPR. MS_time specifies the time at which the tuple expires and must be removed. Topology Set Each node in the network maintains topology information about the network. This information is acquired from TC messages and is used for routing table calculations. Thus, for each destination in the network, exists at least one topology tuple : (T _dest_addr, T _last_addr, T _seq, T _time) T_dest_addr is the main address of a node, which may be reached in one hop from the node with the main address T_last_addr. Typically,T_last_addr is a MPR of T_dest_addr. T_seq is a sequence number, and T_time specifies the time at which this tuple expires and must be removed.

54 3.2.4 MPR 35 Interface Association Set For each destination in the network, is recorded one interface association tuple : (I_if ace_addr, I_main_addr, I_time) I_iface_addr is an interface address of a node, I_main_addr is the main address of this node. I_time specifies the time at which this tuple expires and must be removed MPR MPRs are used to flood control messages from a node into the network while reducing the number of retransmissions that will occur in a region. Thus, the concept of MPR is an optimization of a classical flooding mechanism. Each node in the network selects, independently, its own set of MPRs among its symmetric 1-hop neighborhood. The MPR set must be calculated by a node in such a way that it, through the neighbors in the MPR set, can reach all symmetric strict 2-hop neighbors. This means that the union of the symmetric 1-hop neighborhoods of the MPR nodes contains the symmetric strict 2-hop neighborhood. MPR set recalculation should occur when changes are detected in the symmetric neighborhood or in the symmetric strict 2-hop neighborhood. Differences with the classic flooding are shown in 3.8. MPRs are computed per interface, the union of the MPR sets of each interface make up the MPR set for the node. While it is not essential that the MPR set is minimal, it is essential that all strict 2-hop neighbors can be reached through the selected MPR nodes. A node should select an MPR set such that any strict 2-hop neighbor is covered by at least one MPR node. Keeping the MPR set small ensures that the overhead of the protocol is kept at a minimum. The MPR set can coincide with the entire symmetric neighbor set. This could be the case at network initialization (and will correspond to classic linkstate routing). The symmetric links with MPRs are advertised with link lype MPR_NEIGH instead of SYM_NEIGH in HELLO messages. Proposed algorithm for selecting multipoint relay set:

55 3.2.4 MPR 36 Function ComputeMPR foreach n_tuple in neighbor_set_table do node = n_tuple.getnode(); end if n_tuple.n_willingness == WILL_ALWAIS then MPR_set.add(node); continue; //add to the MPR set those nodes in N, which are the only //nodes to provide reachability to a node in 2hop_neighbor_set_table if 2hop_neighbor_set_table.reachExclusiveNode(node) == true then MPR_set.add(node); while exist 2-hop neighbor node which is not covered do MPR_temp = null; end foreach n_tuple in neighbor_set_table do //reachability: the number of nodes at 2-hop distance which are not yet covered by at end //least one node in the MPR set, and which are reachable through this 1-hop neighbor if node.reachability() > 0 then MPR_temp.add(node); node = SelectBestNode(MPR_temp); MPR_set.add(node); Optimize(); Function SelectBestNode //Return the node with highest willingness, in case of multiple choice //select the node which provides reachability to the maximum number of //nodes in 2hop_neighbor_set_table. In case of multiple nodes providing //the same amount of reachability, select the node as MPR whose D(y) is greater nodes.selecthighestwillingness(); nodes.selecthighestreachability(); // The degree of a 1-hop neighbor node y, is defined as the number of symmetric //neighbors of node y, ecluding all the members of neighbor_set_table and //excluding the node performing the computation return nodes.selectmaxdegree(); Function Optimize //process each node, in the MPR set in increasing order of willingness. If all //nodes in 2hop_neighbor_set_table are still covered by at least one node in the MPR //set excluding node y, and if willingness of node y is smaller than WILL_ALWAYS, //then node y may be removed from the MPR set. MPR_set.orderByWilligness(); foreach 2n_tuple in 2hop_neighbor_set_table do node = 2n_tuple.getNode(); end if node.willingness < WILL_ALWAIS then MPR_set.remove(node); if!mpr_set.coverall2hopnodes() then MPR_set.add(node);

56 3.2.5 Routing 37 Figure 3.8: classic flooding (a) and MPR flooding mechanism (b) Routing Each node maintains a routing table which allows it to route data, destined for the other nodes in the network. The routing table is based on the information contained in the link set table and the topology set table. Therefore, if any of these sets are changed, the routing table is recalculated to update the route information about each destination in the network.

57 3.2.5 Routing 38 The route entries are recorded in the routing table in the following format: (R_dest_addr, R_next_addr, R_dist, R_if ace_addr) Such entry specifies that the node identified by R_dest_addr is estimated to be R_dist hops away from the local node, that the symmetric neighbor node with interface address R_next_addr is the next hop node in the route to R_- dest_addr, and that this symmetric neighbor node is reachable through the local interface with the address R_iface_addr. Entries are recorded in the routing table for each destination in the network for which a route is known. All the destinations, for which a route is broken or only partially known, are not recorded in the table. More precisely, the routing table is updated when a change is detected in either: the link set the neighbor set the 2-hop neighbor set the topology set the interface association set More precisely, the routing table is recalculated in case of neighbor appearance or loss, when a 2-hop tuple is created or removed, when a topology tuple is created or removed or when multiple interface association information changes. The update of this routing information does not generate or trigger any messages to be transmitted, neither in the network, nor in the 1-hop neighborhood. To construct the routing table of node X, a shortest path algorithm is run on the directed graph containing the arcs X Y where Y is any symmetric neighbor of X, the arcs Y Z where Y is a neighbor node with willingness different of WILL_NEVER and there exists an entry in the 2-hop neighbor set with Y as N_neighbor_main_addr and Z as N_2hop_addr, and the arcs U V, where there exists an entry in the topology set with V as T_dest_addr and U as T_last_addr. The following procedure is given as an example to calculate (or recalculate) the routing table:

58 3.2.5 Routing 39 Function CreateRoutingTable begin //r_t is the routing table r_t.clear(); //starting with symmetric neighbors (h=1) foreach n_t in neighbor_set_table do end if n_t.n_status == SYM then node = n_t.getnode(); bool added_main_address = false; foreach l_t in link_set_table.select_links(node) do //for each associated link tuple of the neighbor end if l_t.l_time >= current_time then //not exipred information dest_addr = l_t.l_neighbor_iface_addr; next_addr = l_t.l_neighbor_iface_addr; iface_addr = l_t.l_local_iface_addr; r_t.add_route(dest_addr,next_addr,1,iface_addr); last_l_t = l_t; if node.ismainaddress(l_t.l_neighbor_iface_addr) then added_main_address=true; if!added_main_address then r_t.add_route(node.main_address,last_l_t.l_neighbor_iface_addr,1, //2-hop neighbor (h=2) last_l_t.l_local_iface_addr); foreach 2n_t in 2hop_neighbor_set_table do parent = 2n_t.getParentNode(); end if parent.willingness!= WILL_NEVER then dest_addr = 2n_t.N_neighbor_main_addr; next_addr = r_t.getnexthopaddr(n_neighbor_main_addr); iface_addr = r_t.getifaceaddr(n_neighbor_main_addr); r_t.add_route(dest_addr, next_addr,2,iface_addr); no_route_found=false; for h=2;no_route_found==false;h++ do end end end foreach t_t in topology_set_table do end if!r_t.containsdest(t_t.t_dest_addr,h) AND r_t.containsdest(t_t.t_last_addr,h) then //not exist route to destination but its reacheable in h hops dest_addr = t_t.t_dest_addr; //here next_addr can be calculated in other ways next_addr = r_t.getnexthopaddr(t_t.t_last_addr); iface_addr = r_t.getifaceaddr(t_t.t_last_addr); r_t.add_route(dest_addr,next_addr,h,iface_addr); else no_route_found = true; //multiple interface foreach i_t in interface_association_set_table do if r_t.containsdest(i_t.i_main_addr) AND!r_t.containsDest(i_t.I_iface_addr) then route = r_t.getroute(i_t.i_main_addr); dest_addr = i_t.i_iface_addr; next_addr = route.r_next_addr; iface_addr = route.r_iface_addr); r_t.add_route(dest_addr,next_addr,route.r_dist,iface_addr);

59 3.3 Auxiliary Functions Auxiliary Functions Messages HNA A node may be equipped with multiple interfaces, some of which do not participate in the OLSR MANET. These non OLSR interfaces may be point to point connections to other singular hosts or may connect to separate networks. In order to provide connectivity from the OLSR MANET interface(s) to these non OLSR interface(s), a node should be able to inject external route information to the OLSR MANET. The routing information for the OLSR MANET can be extracted from the topology set table or directly from the routing table of OLSR, and should be injected onto the non OLSR interfaces following whatever mechanism (routing protocol, static configuration etc.) is provided on these interfaces. An example of such a situation could be where a node is equipped with a fixed network (e.g., an Ethernet) connecting to a larger network as well as a wireless network interface running OLSR. Notice that this is a different case from that of multiple interfaces, where all the interfaces are participating in the MANET through running OLSR. In order to provide this capability of injecting external routing information into an OLSR MANET, a node with such non-manet interfaces periodically issues a Host and Network Association (HNA) message, containing sufficient information for the recipients to construct an appropriate routing table. The proposed format of an HNA message is shown in Figure 3.9. This kind of messagge is sent as the data part of the general packet format with the message type set to HNA_MESSAGE, the time to live field set to 255 and vtime set accordingly to the value of HNA_HOLD_TIME. Fields: network address: the network address of the associated network netmask: the netmask, corresponding to the network address immediately above.

60 3.3.2 Tables 41 Figure 3.9: HNA message Tables Association Set Each node maintains information concerning which nodes may act as gateways to associated hosts and networks by recording association tuple : (A_gateway_addr, A_network_addr, A_netmask, A_time) where A_gateway_addr is the address of an OLSR interface of the gateway, A_network_addr and A_netmask specify the network address and netmask of a network, reachable through this gateway, and A_time specifies the time at which this tuple expires and hence must be removed. It should be noticed, that the HNA message can be considered as a generalized version of the TC message. In the TC message, no netmask is required, since all reachability is announced on a per-host basis. In HNA messages, announcing reachability to an address sequence through a network and netmask address is typically preferred over announcing reachability to individual host addresses. An important difference between TC and HNA messages is, that a TC message may have a canceling effect on previous information (if the ANSN is incremented), whereas information in HNA messages is removed only upon expiration. HNA messages should be transmitted periodically every HNA_INTERVAL Link Layer Notification OLSR is designed not to impose or expect any specific information from the link layer. However if link layer information describing connectivity to neigh-

61 3.3.4 Link Hysteresis 42 boring nodes is available (i.e., loss of connectivity such as through absence of a link layer acknowledgment), this information is used in addition to the information from the HELLO messages to maintain the neighbor set and the MPR selector set. Each link tuple in the local link set should, in addition to what is described 3.2.3, include a L_LOST_LINK_time field. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending Link Hysteresis Established links should be as reliable as possible to avoid data packet loss. This implies that link sensing should be robust against bursty loss or transient connectivity between nodes. Hence, to enhance the robustness of the link sensing mechanism, the following implementation recommendations should be considered. Each link tuple in the local link set should, in addition, include a L_link_pending field, a L_link_quality field, and a L_LOST_LINK_time field. L_link_pending is a boolean value specifying if the link is considered pending (i.e., the link is not considered established). L_link_quality is a dimensionless number between 0 and 1 describing the quality of the link. L_- LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending. The link quality value is compared with two threshold in order to set the correct value of the L_link_pending field (HYST_THRESH- OLD_LOW, HYST_THRESHOLD_HIGH). If some measure of the signal/noise level on a received message is available, then it can be used as estimation of the link quality value, after normalization. If no signal/noise information or other link quality information is available from the link layer, the following formula can be used to compute the quality of the link: L_link_quality = (1 HY ST _SCALIN G) L_link_quality+HOST _SCALIN G When an OLSR packet is lost, the instability rule is applied: L l ink q uality = (1 HY ST _SCALING) L_link_quality The loss of OLSR packet is detected by tracking the missing PSN on a per interface basis and by long period of silence from a node.

62 3.3.5 Redundant Topology Information Redundant Topology Information In order to provide redundancy to topology information base, the advertised link set of a node may contain links to neighbor nodes which are not in MPR selector set of the node. The advertised link set may contain links to the whole neighbor set of the node. The minimal set of links that any node must advertise in its TC messages is the links to its MPR selectors. The advertised link set can be built according to the following rule based on a local parameter called TC_REDUNDANCY parameter. The parameter T_REDUNDANCY specifies, for the local node, the amount of information that may be included in the TC messages. The parameter should be interpreted as follows: if the TC_REDUNDANCY parameter of the node is 0, then the advertised link set of the node is limited to the MPR selector set if the TC_REDUNDANCY parameter of the node is 1, then the advertised link set of the node is the union of its MPR set and its MPR selector set if the TC_REDUNDANCY parameter of the node is 2, then the advertised link set of the node is the full neighbor link set. A node with willingness equal to WILL_NEVER should have TC_REDUNDANCY also equal to zero MPR Redundancy MPR redundancy specifies the ability for a node to select redundant MPRs. Normally a node should select its MPR set to be as small as possible, in order to reduce protocol overhead. The criteria for selecting MPRs is, that all strict 2-hop nodes must be reachable through, at least, one MPR node. Redundancy of the MPR set affects the overhead through affecting the amount of links being advertised, the amount of nodes advertising links and the efficiency of the MPR flooding mechanism. On the other hand, redundancy in the MPR set ensures that reachability for a node is advertised by more nodes, thus additional links are diffused to the network. There are situations in which overhead can be traded off for other benefits. For example, a node may decide to increase its MPR coverage if it observes many changes in its neighbor set caused by mobility, while otherwise keeping

63 3.3.7 IPv6 Considerations 44 a low MPR coverage. The MPR coverage is defined by a single local parameter (MPR_COVERAGE), specifying by how many MPR nodes any strict 2-hop node should be covered. MPR_COVERAGE equal to 1 specifies that the overhead of the protocol is kept at a minimum and causes the MPR selection to operate normally. MPR_COVERAGE equal to m ensures that, if possible, a node selects its MPR set such that all strict 2-hop nodes for an interface are reachable through at least m MPR nodes on that interface. MPR_COVER- AGE can assume any integer value greater than 0. Notice that the coverage parameter can be tuned locally without affecting the consistency of the protocol. For example, nodes in a network may operate with different values of MPR_COVERAGE IPv6 Considerations All the operations and parameters described in this document used by OLSR for IP version 4 are the same as those used by OLSR for IP version 6. To operate with IP version 6, the only required change is to replace the IPv4 addresses with IPv6 address. The minimum packet and message sizes (under which there is rejection) should be adjusted accordingly, considering the greater size of IPv6 addresses. 3.4 Parameters Emission intervals HELLO_INTERVAL REFRESH_INTERVAL TC_INTERVAL MID_INTERVAL HNA_INTERVAL 2 seconds 2 seconds 5 seconds TC_INTERVAL TC_INTERVAL 3.5 Security Consideration Currently, OLSR does not specify any special security measures. As a proactive routing protocol, OLSR makes a target for various attacks. In OLSR, each

64 3.5 Security Consideration 45 Holding time NEIGHB_HOLD_TIME TOP_HOLD_TIME DUP_HOLD_TIME MID_HOLD_TIME HNA_HOLD_TIME 3 x REFRESH_INTERVAL 3 x REFRESH_INTERVAL 3 x TC_INTERVAL 3 x MID_INTERVAL 3 x HNA_INTERVAL Message types HELLO_MESSAGE 1 TC_MESSAGE 2 MID_MESSAGE 3 HNA_MESSAGE 4 Link types UNSPEC_LINK 0 ASYM_LINK 1 SYM_LINK 2 LOST_LINK 3 Neighbor types NOT_NEIGH 0 SYM_NEIGH 1 MPR_NEIGH 2 Link hysteresis HYST_THRESHOLD_HIGH 0.8 HYST_THRESHOLD_LOW 0.3 HYST_SCALING 0.5 Willingness WILL_NEVER 0 WILL_LOW 1 WILL_DEFAULT 3 WILL_HIGH 6 WILL_ALWAYS 7

65 3.6 Protocols Implementations 46 Misc. constants TC_REDUNDANCY 0 MPR_COVERAGE 1 MAXJITTER HELLO_INTERVAL / 4 node is injecting topological information into the network through transmitting HELLO messages and, for some nodes, TC messages. If some nodes for some reason, malicious or malfunction, inject invalid control traffic, network integrity may be compromised. Authentication of the originator node for control messages and on the individual links announced in the control messages, may be used as a countermeasure. In general, digital signatures and other required security information may be transmitted as a separate OLSR message type, thereby allowing that secured and unsecured nodes can coexist in the same network, if desired. 3.6 Protocols Implementations A lot of implementations of OLSR are available on Internet. These implementations are, mainly the output of research projects. Some of them share a common code, derived from the original INRIA implementation. Indeed IN- RIA was the first research group that realized a first implementation on the OLSR protocol. Due the low level of control that OLSR requires, most of the implementations are written in C/C++ language, that allows to get easy kernel access and good performances. The main property required by an implementation is the compatibility with the standard described in the RFC If two different implementations are both compliant with the RFC, hence they are interoperable. For this project the implementation must work under a PDA equipped with the Windows CE operative system. Most of the implementation are only for research demonstration, hence they can work only on a network simulator software. Only a few researches have produced a Windows implementation, which are normally all developed under a UNIX system. Some implementations run on PDA but only with a UNIX-like system on board; UNIX-like PDAs

66 3.6.1 NOLSR 47 are not the de-facto standard. Indeed, almost every PDA comes with Windows we aim at it. To find the best implementation for this project, the following metrics was used to evaluate all the possibilities: source code: the availability of the code is the main key because it is necessary to modify and build a custom executable aliveness: only alive projects are considered, while, not working or dismissed implementations are discarded windows platform: for this project is necessary to work at least on the Windows operative system, for an easy porting on the mobile platform windows mobile platform: if working on windows CE platform, no porting is necessary After a long search over Internet following implementations have been found: 1. NOLSR 2. NRLOLSRD 3. OLSR per PocketPC 4. OLSRD 5. OOLSR/NOAOLSR/SMOLSR-MOLSR 6. QOLSR/QOLYESTER NOLSR Simple implementation of the protocol, it is compliant with the RFC and works under the Windows operative system. The source code is available but the project seems to be dead; no changes of code have happened since the year This work does not provide any possibility to be extended for a mobile environment. No documentation is available. It uses only IPv4 and does not work on a PDA device NRLOLSRD NRLOLSRD is a research oriented OLSR implementation, evolved from OLSR draft version 3. It is built on top of the NRL ProtoLib library for system portability. ProtoLib works with UNIX, Windows, WinCE, OpenZaurus, ns-2, Opnet; it can also works with IPv6. It provides a system independent interface, so NRLOLSRD does not make any direct system calls to the device operating

67 3.6.3 OLSR per PocketPC 48 system. Timers, socket calls, route table management, address handling are all managed through ProtoLib calls. To work with Windows CE, ProtoLib uses the RawEther component to handle raw message and get access to the network interface card. NRLOLSRD has non-standard command line options for research purposes, such as shortest path first route calculations, fuzzy and slowdown options, etc.. It can be extended with the multicast features, and a GUI interface gives the possibility to view the node s topology on the top of the field map. NRLOL- SRD is a mature project used in many military scenarios. The source code is freely available form the website 1, but for the mobile branch of the project the required componet RawEther is a commercial product OLSR per PocketPC It is the porting of the laptop OLSR version to mobile devices. It is a university project that works on Windows system and also on Windows CE platform, the source code can be downloaded freely 2. It is written on top of the PICA library. PICA is a multi-platform intuitive API for designers of communication protocols. The aim was to accelerate the prototyping phase to provide users with a stable solution whose source code can compile directly on distinct platforms. The PICA library is an adaptation layer between the users and the kernel space and it is based on Winpcap 3. It use IPv4 only and no multicast features are present. The project is, unfortunatly closed OLSRD This implementation is the most used over the Internet, it has a community behind that continually patch and extend the protocol. It is released with a free license and the source code can be downloaded from the community site 4. It is extendible by a plug-ins (dynamically linked libraries); various plug-ins add new features that are not present in the basic RFC recomendation (e.g

68 3.6.5 OOLSR/NOAOLSR/MOLSR 49 node powerstatus, multicast). OLSRD works with many operative systems and you can find the specific version for UNIX, Windows and Mac OS X. This is a university research project 5. This implementation works well on PDA, but only with a UNIX system, hence a off-the-shelf device has to be re-setted and hacked to work with it. A not deep tested version of OLSRD for Windows CE devices can be found. This version seems to work, but it is in a dead status. OLSRD supports IPv4 and IPv OOLSR/NOAOLSR/MOLSR The INRIA 6 group was the first releaser of the OLSR protocol. The first release was a simple code written in C with the procedural programming paradigm. Now this group has released the newer version that is rewritten with the object oriented paradigm. This version takes the name of OOLSR. OOLSR is the starting point for most of other independent implementations because it contains the basic algorithm to perform the OLSR tasks. OOLSR is freely available with the source code; it supports Linux and Windows. Current release can also be run in NS 2 (network simulator). It supports IPv4 and IPv6. A mobile version exist and it is the porting of the original code to the mobile environment. NOAOLSR is an extension to the original code of INRIA. It adds the auto configuration mechanism to the OLSR protocol. NOAOLSR it is written on top of the OOLSR code, so it shares the same basic algorithm. The auto configuration is quite simple: each node selects a random address, verifies the uniqueness in the network and, if there is no conflict, the node assigns the address to its network interface. Each node is also responsible for the address assignment to a new entering node. To do its jobs, it has to change some OLSR pieces, (e.g. message format) and hence the implemenation loses the interoperability. The same research group added to the OOLSR implementation the capability to work in a multicast mode. This new project is called MOLSR. MOLSR stands for Multicast OLSR. It is a source tree based protocol. It maintains one multicast tree per tuple (source, multicast group). Data is dis- 5 UniK - 6 http//:www.inria.fr

69 3.6.6 QOLYESTER 50 seminated through out the multicast trees to reach all the nodes that have joined a specific multicast group. The data forwarding itself is done by a second daemon called MDFP (Multicast Data Forwarding Protocol). MDFP is a forwarding protocol that enables a point to multipoint data transfer. Multicast packets are captured and encapsulated in order to be forwarded inside the multicast tree. This last two implementation works only on Linux system and are not in-line with the lastest OOLSR code, that represents a different develop branch QOLYESTER It is an implementation of the QOLSR protocol, that is an extended version of OLSR. The goal is to introduce metrics like capacity, delay, jitter, cost, loss probability, etc, in routing consideration. Almost no additional control traffic is generated (only augmented HELLO and TC messages). The source code is freely available on the project website 7. The current implementation works only under UNIX operative system, and is not working as well as other OLSR implementations, the implementations is a little bit far to achive its goal; but the project is still alive and a team is working on. No mobile version are present for this work SOURCE LIVE WINDOWS MOBILE Table 3.1: approach comparision of the olsr implementations Choosed Implementation After a deep comparison of the previous properties, table shows the results. The choice falls on the NRLOLSRD implementation as the starting point 7

70 3.6.7 Choosed Implementation 51 for this project. There are 4 implementations that work on a PDA devices. But after an intensive test on real devices equipped with Windows CE operative system (Windows Mobile 6), we found that NRLOLSRD is the only working fine. The other 3 implementations work only in older version of Windows CE. The NRLOLSRD project has all the properties required and currently it seems to be used on the real field from a trusted group, the U.S. Naval Research Laboratory. Therefore the project is still under the spot light and has a qualified support team behind. This implementation is not only for research purposes, but some real military projects are based on it as well. This implementations is fully configurable and works with other implementation because is interoperable. Another successful key is the possibility to compile the code for different platforms, which gives the opportunity to test the performance of different devices (e.g. PDA / Windows) running the same algorithm.

71 Nothing is really work unless you would rather be doing something else James M. Barrie

72 Chapter 4 The NRL Implementation 4.1 NRL The Networks and Communication Systems Branch of the Information Technology Division (ITD) at the U.S. Naval Research Laboratory (NRL) conducts research and development in the area of military networks and communication systems. NRL is the corporate research laboratory for the Navy and Marine Corps and conducts a broad program of scientific research, technology and advanced development. The basic researches of NRL are in Dynamic Routing Protocols and Energy-Efficient Networking areas. The NRLOSRD is one of the projects developed and tested from this laboratory. The NRLOLSRD project is built on top of the ProtoLib library (4.1) that allows to run the implementation on various platforms, such as Windows, Unix and also on a simulator software, without changing the source code. The ProtoLib project provides the abstraction needed to be independent from the platform. Therefore the NRLOLSRD software does not need to know on where it is running, it doesn t use direct system calls. Timers, socket calls, route table management, address handling are all managed through ProtoLib calls. The ProtoLib layer, instead, must be platform dependent in some points. Extern components are used to capture the packets on the network; for the Windows CE system the only one available in the market is the RawEther component. To port the OLSR implementation on a new platform only a few changes have to be made at the ProtoLib layer, deriving the specific classes from the new environment.

73 4.2 ProtoLib 54 On top of the NRLOLSRD demon many projects can be plugged-in, such as the Simple Multicast Forwarding (SMF) that provides the multicast extension to the OLSR protocol. A ProtoLib-based project can communicate with other processes on the same system with the pipe mechanism, so a plug-in or independent project can exchange information and remotely control the behavior of the algorithm. Figure 4.1: NRL - main structure 4.2 ProtoLib The Protean Protocol Prototyping Library (ProtoLib) is a cross-platform C/C++ library that allows applications to be built while supporting a variety of platforms including Linux, Windows, WinCE, MacOS, FreeBSD, Solaris, etc as well as the simulation environments of NS2 and Opnet. ProtoLib is not so much a library as it is a toolkit. While ProtoLib provides an overall framework for developing working protocol implementations, applications, and simulation modules, the individual classes are designed for use as stand-alone com-

74 4.2.1 Class Design 55 ponents when possible. Although ProtoLib is principally for research purposes, the code has been constructed to provide robust, inefficient performance and adaptability to real applications. In some cases, the code consists of data structures, etc useful in protocol implementations and, in other cases, provides common, cross-platform interfaces to system services and functions (e.g., sockets, timers, routing tables, etc). Currently ProtoLib supports most Unix platforms (including MacOS X) and WIN32 platforms. The most recent version also supports building ProtoLib-based code for the ns-2 and OPNET simulation environments. Some code is also provided to allow code based on ProtoLib to be used in a wxwidgets application. ProtoLib is mainly a console application but for some prototype network applications, the wxwidgets project provides a graphical user interface (GUI). The wxwidgets 1 project is a cross-platform graphical user interface toolkit for creating applications using the C++ programming language Class Design Some class diagrams of the core of the project follow; each class shows only the most important methods and attributes. The first diagram (4.2) shows the main classes shared from the entire project s components. The second one shows the tree structure that is behind the route table. The last diagram shows the socket architecture and the proxy mechanism. Each diagram shows only the main relationship between the classes: methods and attributes are not visible due the complexity and the short space available on this paper. The documentation of the project isn t yet available, a short description of the main classes follow: ProtoApp provides a base class for implementing ProtoLib-based commandline applications. Is the main class of the final executable, process the command line parameters and it starts all the subsystem. A background command is included for Win32 to launch the app without a terminal window ProtoAddress network address container class with support for IPv4, IPv6, ETH, and "SIM" address types. Also includes functions for name/address resolution 1

75 4.2.1 Class Design 56 Figure 4.2: Protolib - common classes ProtoSocket network socket container class that provides consistent interface for use of operating system (or simulation environment) transport sockets. Provides support for synchronous notification to Listeners. A

76 4.2.1 Class Design 57 Figure 4.3: Protolib - the route table is a tree structure Figure 4.4: Protolib - packets

77 4.2.1 Class Design 58 Figure 4.5: Protolib - the socket architecture ProtoSocket may be instantiated as either a UDP or TCP socket ProtoTimer this is a generic timer class which will notify a Listener upon timeout ProtoTimerMgr this class manages ProtoTimer instances when they are activated ProtoDispatcher this class provides a core around which Unix and Win32 applications using ProtoLib can be implemented. It is Run() method provides a main loop which uses system call on Unix and on Win32 to wait for messages. It is planned to eventually provide some built-in support for threading in the future ProtoTree flexible implementation of a Patricia tree data structure. Includes a ProtoTree::Item which may be derived from or used as a container for whatever data structures and application may require ProtoAddress class based on the ProtoTree to store routing table information. Uses the ProtoAddress class to store network routing addresses ProtoRouteMgr base class used to provide a common interface to system (or other external) router tables. Implementations for Linux, BSD (incl. MacOS), and Win32/WinCE are included

78 4.3 NRLOLSRD 59 ProtoPkt base class for a suite of network protocol packet/message building/- parsing classes that provide methods for setting/getting protocol field values to/from a buffer ProtoPktIP classes are provided for building/parsing IPv4 and IPv6 packets to/from a buffer space ProtoPktUDP base UDP packet ProtoPktRTP Useful for building/parsing Real-Time Protocol (RTP), RFC3550, messages ManetMsg class that implements the general packet format being developed by the IETF MANET working group ProtoPipe socket-like mechanism (with both datagram and stream support) useful for interprocess communications ProtoCap interface class for raw MAC-layer packet capture. platform dependent ProtoChannel base class for hooking into asynchronous I/O. This class is 4.3 NRLOLSRD The NRL implementation is largely based on the OLSR protocol specification (RFC 3626), but the current version does not support the MID message features. The NRLOLSRD code base has several additional options and features, including: support for IPv6 operational in Windows, MacOS, Linux, and various embedded PDA systems full link state topology can be distributed including non-mpr cross links a willingness attribute for localized MPR activation support for several MPR selection protocols (Classical flooding, NS-MPR, S-MPR, MPR-CDS, and E-CDS) several run-time parameters available experimental features such as fuzzy-sighted routing and support for Simplified Multicast Forwarding

79 4.3.1 Class Design 60 This implementation is not only for research purposes, but some real military projects are based on it as well. This implementation is fully configurable and works with other implementations because it is interoperable. It is written in C++ and as described above it can run without any changes on various platforms. The source code can compile under UNIX and Windows as well. It has a strong system of debugging that allows the user to catch all the network activities and to trace the topology changes. NRLOLSRD intercepts packets on the broadcast address through the ProtoLib calls, this behavior is provided from the extern sniffer components (platformdependent). At runtime the implementation listens on port 698 (UDP) for packets sent to the broadcast address specified: all the intercepted packects are processed, discarded if they are a duplicated, or forwarded if they are not OLSR messages. NRLOLSRD is perfectly transparent to the whole system: in fact, high level applications, designed to work in usual network, do not need any changes for being executed in MANETs with NRLOLSRD Class Design The first diagram (4.6) shows the basic classes needed to build the protocol implementation. The diagram 4.7 shows the classes that are created for the porting of the protocol on a Windows CE system. The main classes are: NrlolsrApp derives from the ProtoLib::ProtoApp class, is the entry point of the project, it handles the routing table object, its platform dependent Nrlolsr it is the main object, it owns many queues to coordinate the entire system, it manages the flooding type and the olsr packets NbrQueue prioritized FIFO queue, used to hold the neighboors informations List_ generic container of objects OlsrMessage represent the generic OLSR message, contains methods for packing/unpacking, it has specific methods to set the type of message HelloMessage it models the structure of the HELLO message, contains all the fields required by the standard TCMessage it models the structure of the TC message, contains all the fields required by the standard

80 4.3.2 Usage 61 HNAMessage it models the structure of the HNA message, contains all the fields required by the standard OlsrPacket it is a container of OLSR messages Win32RouteMgr it derives from the ProtoLib::ProtoRouteMgr, it is the Windows implementation of the base class, it manages the routing table RawEtherCap it derives from the ProtoLib::ProtoCap, it is the Windows CE implementation of the packets capturing mechanism, it uses the commercial component RawEther to build raw packets and to access to the NIC features Usage NRLOLSRD has many configurable parameters that can be specified from the command line. Follow a short brief of them: backgound: to run without any GUI -i: is device name of interface that olsr is to run on -d: debug level -l: is file location/name that debugging information is logged -b: set broadcast address network -w: willingness value -hna: Auto will look interfaces not defined by -i interfacename and advertize network routes -hi: Hello interval in seconds -hj: Hello jitter -ht: all hello message sent with this option will be of at least size HelloPadding. Padding of all zeros will be added to the end of all messages -tci: TC interval in seconds -tcj: TC jitter -ipv6 -ipv4 -hnai: HNA interval in seconds -hnaj: HNA jitter -hys: enable and set hysteresis values -qos: QoS value to mark OLSR packets with -fuzzy: will turn on fuzzy sighted flooding for TC and HNA messages

81 4.3.2 Usage 62 -slowdown: TC intervals will be doubled after 3 successive sent tcs with the same addresses -fastreroute: will re calculate the routing table when changes which may effect routing are detected -shortesthop: normal operation of route calculation using shortest hop paths -spf: shortest path first route calculation using spf information sent around in modified TC messages -minmax: route calculations will result in paths which have the maximum minimum link metric -unicast: unicast routing option -flooding: broadcast packets which are forwarding on port 699 will be treated as multicast packets. Many different flooding mechanism are available -unicast: unicast routing option For an extended description of all parameters see the readme file included with the source code of the implementation.

82 4.3.2 Usage 63 Figure 4.6: OLSRD - common classes

83 4.3.2 Usage 64 Figure 4.7: OLSRD - WinCE specific implementation

84 Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Rick Cook

85 Chapter 5 Wireless Medium 5.1 Overview of Standard IEEE is a standard for wireless systems. It specifies both the MAC layer and the Physical Layer for access point based networks and ad-hoc networks. The standard supports Direct Sequence Spread Spectrum (DSSS) in the 2.4 GHz band with bit rates of 1, 2, 5.5 and , 125 MBits/sec. The MAC layer offers two different types of service: contention service provided by the Distributed Coordination Function (DCF) contention-free service implemented by the Point Coordination Function (PCF) The DCF provides the basic access method of the MAC protocol and is based on a Carrier Sense Multiple Access with Collision Avoidance (CS- MA/CA) scheme. The PCF is implemented on top of the DCF and is based on a polling scheme. It uses a Point Coordinator that cyclically polls stations, giving them the opportunity to transmit. Since the PCF can not be adopted in ad-hoc mode, it will not be considered hereafter. According to the DCF, before transmitting a data frame, a station must sense the channel to determine whether any other station is transmitting. If the medium is found to be idle for an interval longer than the Distributed InterFrame Space (DIFS), the station continues with its transmission (see Fig-

86 5.1 Overview of Standard ure 5.1). On the other hand (i.e., if the medium is busy), the transmission is deferred until the end of the ongoing transmission. A random interval, henceforth referred to as the backoff time, is then selected, which is used to initialize the backoff timer. The backoff timer is decreased for as long as the channel is sensed as idle, stopped when a transmission is detected on the channel, and reactivated when the channel is sensed as idle again for more than a DIFS. The station is enabled to transmit its frame when the backoff timer reaches zero. Figure 5.1: DCF Obviously, it may happen that two or more stations start transmitting simultaneously and a collision occurs. In the CSMA/CA scheme, stations are not able to detect a collision by hearing their own transmissions (as in the CSMA/CD protocol used in wired LANs). Therefore, an immediate positive acknowledgement scheme is employed to ascertain the successful reception of a frame. Specifically, upon reception of a data frame, the destination station initiates the transmission of an acknowledgement frame (ACK) after a time interval called Short InterFrame Space (SIFS). The SIFS is shorter than the DIFS in order to give priority to the receiving station over other possible stations waiting for transmission. If the ACK is not received by the source station, the data frame is presumed to have been lost, and a retransmission is scheduled.//

87 5.2 Ad-hoc Problems 68 There are three types of ranges related to packet transmission in the IEEE MAC scheme: transmission range, inside which nodes are able to receive or overhear the packet transmission; carrier sensing range, inside which nodes are able to sense the signal, even though correct packet reception may not be available interference range, inside which any new transmission may interfere with the packet reception. It is generally assumed that the transmission range is smaller than the carrier sensing range and the interference range. Generally carrier sensing range is about two times the transmission ones. When a receiver is within the transmission range of two transmitters that are transmitting simultaneously, the packets are assumed to interfere with each other, leading to a collision at the receiver, so that no packet is received successfully. Carrier sensing can reduce the number of packet collisions. the carrier sensing range is a tunable parameter that can significantly affect the MAC performance in multihop ad-hoc networks. It balances the trade-off between the amount of spatial frequency reuse and the likelihood of packet collision. However, the IEEE specification does not give a welldefined carrier sensing range. 5.2 Ad-hoc Problems In wireless ad-hoc network that relies upon a carrier-sensing random access protocol, like the IEEE DCF protocol, the wireless medium characteristics generate complex and critical phenomena such as the hidden terminal and exposed terminal problems Hidden Terminal Besides the collisions of packets among nodes inside a carrier sensing range, the hidden terminal problem further increases the chance of link-failure declarations. Consider Figure 5.2. When node 4 sends a packet to node 5, node 2 senses the channel to be busy while node 1 senses the channel to be idle,

88 5.2.1 Hidden Terminal 69 Figure 5.2: hidden-terminal scenarios since node 4 is inside the carriersensing range of node 2 but outside that of node 1. Once node 1 senses the channel as idle, it may count down its back-off contention window until zero and transmit a packet to node 2. If the transmission from node 4 is still in progress, node 2 will continue to sense the channel as busy, and it will not receive the packet from node 1. As a result, node 2 will not return an ACK to node 1. Node 1 may then time out and double the contention window size for retransmission later. Meanwhile, node 4 transmits the packet successfully and is not aware of the collision at node 2. When transmitting the next packet, node 4 will use the minimum contention window size. The hidden terminal scenario favors node 4, and the chance of collision at node 2 can not be reduced even though node 1 backs off before the next retry. The hidden terminal problem increases the chance of multiple retries by node 1, making the wrong declaration of link failures and therefore rerouting instability more likely. Note that the negative effect of a hidden terminal is much more than that of a contending terminal within the carrier-sensing range. This is because the carrier-sensing capability in the CSMA protocol breaks down with respect to the hidden terminal, making collisions much more likely.

89 5.2.1 Hidden Terminal 70 RTS/CTS The hidden terminal problem can be alleviated by extending the DCF basic mechanism by a virtual carrier sensing mechanism that is based on two control frames: Request To Send (RTS) Clear To Send (CTS) According to this mechanism, before transmitting a data frame, the station sends a short control frame, named RTS, to the receiving station announcing the upcoming frame transmission (see Figure 5.3). Upon receiving the RTS frame, the destination station replies by a CTS frame to indicate that it is ready to receive the data frame. Both the RTS and CTS frames contain the total duration of the transmission, i.e., the overall time interval needed to transmit the data frame and the related ACK. This information can be read by any listening station that uses this information to set up a timer called Network Allocation Vector (NAV). While the NAV timer is greater than zero the station must refrain from accessing the wireless medium. Figure 5.3: RTS/CTS mechanism The RTS/CTS mechanism in is designed to solve the hidden terminal problem. However, using RTS/CTS in multi-hop networks does not eliminate the problem. The effectiveness of RTS/CTS mechanism is based on the assumption that transmissions by mutually hidden terminals are to a common receiver. Before the transmission of a hidden terminal begins, the receiver will forewarn other hidden terminals to prevent them from transmitting. This

90 5.2.2 Exposed Terminal 71 assumption may not hold in a multi-hop network. Consider the scenario in Figure 5.2 again. The RTS transmitted by node 4 will cause a CTS to be returned by node 5. However, this CTS cannot be received by node 1. Therefore, node 1 may still transmit a packet to node 2 while the transmission of node 4 is in progress. The hidden terminal effect as described in the previous subsection cannot be eliminated. In [4] was argued that when the carrier-sensing range is larger than two times of the transmission range, RTS/CTS is no longer needed Exposed Terminal Figure 5.4: exposed-terminal scenarios As shown in Figure 5.4, the transmission from C to D has been going on when B wants to send data to A. Since B senses that the medium is busy, it will defer this transmission. But in fact, the transmission from B to A will not affect the transmission from C to D. Under such a situation, potential concurrent transmission (B A) is prohibited because B is exposed to the ongoin transmission. Although the exposed terminal problem does not cause collision, it degrades the network throughput.

91 5.3 Chain Topology Chain Topology In this static topology (Figure 5.2) packets travel along a chain of intermediate nodes towards the destinations. The successive packets of a single greedy connection interfere with each other as they move down the chain, forcing contention in the MAC protocol. This kind of topology is the basic block of many others configurations and it is affected by both ad-hoc problems. Node 0 is the source and 6 is the sink and the distance between each node is equal to the transmission range. Let s assume for the moment that the carrier sensing range is equal to the transmission range; so nodes that are not neighbors do not interfere with each other. Nodes 0 and 1 cannot transmit at the same time because node 1 cannot receive and transmit simultaneously. Nodes 0 and 2 cannot transmit at the same time because node 1 cannot correctly hear 0 if 2 is sending. Nodes 0 and 3 can, with the above assumption, send at the same time. This leads to a channel utilization of 1 3. However, if one assumes that carrier sensing range is greater than the transmission range, the situation is worse. Hence, in Figure 5.2, packet transmissions of node 3 will interfere with the packets sent from 0 to 1, preventing 1 from correctly receiving or sending data. In this case the channel utilization is 1 4. This is the upper bound value of the throughput, that a device can reach in this kind topology. 5.4 Medium Sharing A compliant device can t receive and or transmit simultaneously. multiple devices are in the same transmission range, only one at time is able to transmit data. This brings to the conclusion that the whole bandwidth is shared between all the devices in the same transmission range. So the portion of bandwidth for each device is function of the number of hosts (n), and it follows the law: 1 n 1 This is the upper bound value of the throughput, that a device can reach when is in a sharing medium context. If

92 5.5 Wireless Medium Tests 73 Laboratory experiments confirm this formula. If the node exceeds the upper value the percentage of packets lost grows, while if each node has a limited speed, no packet is lost. 5.5 Wireless Medium Tests In order to test the laboratory enviroments, and to garentee the correctness of subsequent tests on the MANET, a study of the basic wireless performance is necessary. The devices used are all off-the-shelf, certified for the standard. The choice falls on b that is the most spread and reliable technology available on the market Throughput The measurement of net throughput is done by timing a large file transfer, with a FTP, between one server and one client. The b can reach the 1, 2, 5.5, 11 MBits/sec of bit rates; for all the tests the devices are configured to go at the maximum bit rate. TCP and UDP, the two most important transport protocol were tested. The TCP transfer reaches the maximum value of 4,95 MBits/sec, instead the UDP has as 5,35 MBits/sec as the maximum value. The values collected are quite close but as predicted the UDP protocol can reach a higher bi trate. This two values are more or less 50% off the nominal bit rate, the loss is due to the overhead introduced for the communication. Z These results compared with other test results available in Internet confirm that the devices are conform to the b standard and they work properly Medium Sharing The scenario is quite simple: one couple of PC is transferring a file with a TCP session. After 30 seconds another couple of PC start a different TCP session and stops after 30 seconds. No restriction or transfer limits are applied to the PCs.

93 5.5.3 From Laboratory Tests To On-field Results 74 Figure 5.5: medium sharing In 5.5 is reported the transfer throughput collected from the first couple. As you can see from the chart, the speed is cut off, more or less, of 50% when the second couple starts the new session, and for the entire length of time. The same test is ran with one more couple and reports an interesting result: sometimes only two couples can complete successfully the transfer session, while the third one is not able to communicate and has to wait for the channel. With a few more couples the test reports more failures than successes. If each couple is limited in the bandiwith speed, following the law of the medium sharing, then every couple can terminate its session successfully. Z The conclusion is that the wireless medium access mechanism, in an adhoc mode, isn t able to coordinate all the devices in the transmission range. Every device has to moderate itself the throughput to not saturate the entire network From Laboratory Tests To On-field Results Let Q field (n) be the throughput in laboratory for a chain of n links (i.e., n + 1 nodes). Computing Q lab (n), which is from the corresponding virtual chain. It is virtual, since topology is kept by OCTOPUS, where all the communication happens inside the laboratory, where there is an higher interference.

94 5.5.3 From Laboratory Tests To On-field Results 75 So exists a theoretical function Conv(n), such that: Q field (n) = Conv(n) Q lab (n) (5.1) The following assumptions are taken: 1. Every node is placed at a maximum coverage distance from the previous and the next node in the chain, such as in Figure 5.2. Every node is able to communicate only with the previous and the next, whereas it can interfere also with any other node located at a distance less or equal to the double of maximum coverage distance. 2. The first node in the chain wishes to communicate with the last one (e.g, by sending a file). The message is split into several packets, which pass one by one through all intermediate nodes in the chain. 3. Time is divided in slots. In the beginning of each slot all nodes, beside the last, try to send to the following in the chain a packet that they are in charge of. 4. Communications happen on the TCP/IP stack. Hence, every node that has not delivered a packet has to transmit it again. Theorem. 1 Let s consider a chain formed by (n 1) nodes connected through n links. On the basis of assumptions above, function Conv(n) = ( n 3 + 1) β 2, for some β. Proof. From the first assumption, it be said that, if the i-th node successes in transmitting, then (i 1)-th, (i 2)-th, (i + 1)-th and (i + 2)-th cannot. D n is the event of delivering a packet in a chain of n links and Sn i is the event of delivering at the i-th attempt. T i,n is the probabilistic event of delivering a packet in a network of n links (i.e.,n + 1 nodes) after i retransmissions 2. Of course, for all n the probability of delivering after one attempt is the same as the probability of deliver a packet: P (T 1,n ) = P (D n ). Conversely, probability P (T 2,n ) is equal to the probability of not delivering at the first P ( Sn) 1 and of delivering at the second attempt P (Sn): 2 P (T 2,n ) = P (Sn 2 Sn) 1 = P (Sn) 2 P ( Sn S 1 n) 2 (5.2) 1 denotes the truncation to the closest lower integer 2 Please note this is different with respect to Sn, i since T i,n implies deliver did not success up to the i 1-th attempt

95 5.5.3 From Laboratory Tests To On-field Results 76 Since, for all i, events S i n are independent and P (Si n) = P (D n ), Equation 5.2 becomes: P (T 2,n ) = P (S 2 n) P ( S 1 n) = P (D n ) (1 P (D n )) In general, the probability of delivering a packet to the destination node after i retransmissions is: P (T i,n ) = P (S i n) P ( S (i 1) n )... P ( S 1 n) = = P (D n ) (1 P (D n )) i 1 (5.3) Provided that, the average number of retransmissions, according to Equation 5.3 is: T n = i=1 P (T i,n) = = i=1 P (D n) (1 P (D n )) i 1 = 1 P (D n) (5.4) In laboratory, all nodes are in the same radio range. Therefore, independently on the nodes number, P (Dn lab ) = 1 n (5.5) On the field, we have to distinguish, basing on links number n. Up to 2 links (i.e., 3 nodes), all nodes interfere and, hence, just one node out of 2 or 3 can deliver a packet in a time slot. So, P (D field 1 ) = 1 and P (D field 2 ) = 1/2. For links n = 3, 4, 5, two nodes success: P (Dn field ) = 2/n. For links n = 6, 7, 8, there are 3 nodes delivering: P (Dn field ) = 3/n. Hence, in general: P (Dn field ) = n (5.6) n By applying Equations 5.5 and 5.6 to Equation 5.4, it can be derived the number of retransmission needed for delivering a packet:. T field (n) = n n 3 + 1T lab (n) = n. (5.7) Fixing the number of packets to be delivered, it can be defined a function f that expresses the throughput in function of the number of sent packets. In a chain of n links if you want to deliver a single packet from the first to the last node in the chain, then you have altogether to send the number n of links times the expected value for each link T n. Therefore: Q lab (n) = f(t lab (n) n) = f(n 2 ) Q field (n) = f(t field (5.8) n (n) n) = f( 2 n +1) 3

96 5.5.4 Conclusion 77 From the laboratory experiments as well as from other theoretical results: it can state f(n 2 ) = α n β. By considering it and equations 5.8, the following holds: Q lab (n) f(n 2 ) = Q field(n) n f( Q ( n field(n) = Q 2 lab (n) n +1) 3 + 1) β 2. (5.9) Conclusion In an ad-hoc network the throughput depends on many factors, like: radio interference building and materials human presence and movements node mobility distance and transmitting power hidden/exposed terminal topology medium sharing Only the last three factors have been considered in our testing, because they are the only ones that can be studied and replicated in laboratory. Our testing refers to the scenarios where all experiments have happen in laboratory where interference is much higher. So, throughput obtained is quite lower than the actual on the spot. Nevertheless, we have found a relashionship between laboratory and on-the-spot thruoghput. Therefore we can derive the supposed on-the-spot.

97 The human brain starts working the moment you are born and never stops until you stand up to speak in public. George Jessel

98 Chapter 6 MANET Testing 6.1 Techniques for Measurement Accurate Wireless Local Area Networks (WLANs) measurements have been proven more elusive than the measurements for wired LANs due to the unique characteristics of the wireless medium. Measurements over a single wireless hop, can vary depending on the hop distance, cross and contending traffic, building structure and even human motion within a measurement testbed. We focus on b standard wich is the technology most spread. These tests are all made in a real-world environment, they are not results of simulations, but all the data are caught from real devices. The tests proposed are of three kind: performance of chain topology tuning of the protocol tests with moving devices All tests, except where specified, have been conducted supported by an emulator of the wireless medium namely OCTOPUS, which allows to create the topology without changing the settings in firewalls or in the device s configuration. See appendix B for more details about OCTOPUS. By OCTOPUS you can put all the devices in the same room, although each device belives to be in a different topology and comunicates only with the neighbors set in the emulator. Every test follows the law of throughput described in Section 5.5.2, due the interference problem and the medium sharing. Since all the devices are static the results are not affected by the mobility and

99 6.2 Simulation vs. Emulation 80 distance problems, so the value presented should be taken as upper bound. The wireless channel testing can be found in Chapter 5, where we came up that environment and devices used are compliant with the standard Simulation vs. Emulation MANET field testing may be expensive both in terms of resources and time: several persons are required to deploy in a wide area and this might need time (and, thus, cost) to prepare them. Moreover, no specific theoretical movement models are usable; it is very hard to control all input parameters and get tangible results as output. In summary, field testings do not provide a controlled environment and it should be used only as a final user validation of the system. Both simulation and emulation provide a more controllable environment which enables to perform experiments at a cheaper cost with respect to field tests. Simulator and emulator does not exclude each other. Simulation can be used at earlier stage: it enables to test algorithms and evaluate their performance before starting to actually implement on real hardware or devices. Simulations are not intended to replicate all features of real hardware or software components, although every reproduced aspect has to keep the same performance levels of the one that is simulated. Even if application code written on top of the simulators can be quickly written and performances easily evaluated, it must be thrown out and rewritten when developers want to migrate to real architectures. At higher bandwidth wireless network simulator s results may not evaluate the routing protocol correctly, and different simulators can give different results. The emulators approach is quite different: during emulation, some software or hardware pieces are not real, whereas others are exactly the ones of real systems. All emulators share the same idea: software systems are not aware about working on an emulated layer (at all or partially). On the other hand, performance levels can be worse. Anyway, software running on emulators can be deployed on real systems with very few or no changes.

100 6.3 Testbed Environment Testbed Environment The environment is composed of personal computers running Microsoft Windows XP (SP2) and real PDA devices. Table 6.3 reports the configuration of every device. The first step is to build an ad-hoc network at b related frequency, all the devices are connected without any encryption and RTS/CTS ability turned off. One pc runs the OCTOPUS emulator and is the default gateway for the subnet mask on each device, so that every node sends his packets to the OCTOPUS machine. Each device runs an OLSR protocol implementation specific for its operating system (Windows CE or XP). DESCRIPTION PC, XP prof. (SP2), 1024 RAM, (2)Intel P4 3.0 GHz PC, XP prof. (SP2), 1024 RAM, (2)Intel P4 3.0 GHz PC, XP prof. (SP2), RAM, (2)Intel P3 1.0 GHz TabletPC, XP prof. (SP2), 1024 RAM, PM 1.1 GHz PC, XP prof. (SP2), 512 RAM, Intel P4 3.0 GHz PC, XP prof. (SP2), 512 RAM, Intel P4 3.0 GHz PDA, ASUS P527, Windows Mobile 6, 64 RAM, 200 MHz PDA, ASUS P527, Windows Mobile 6, 64 RAM, 200 MHz PDA, ASUS P527, Windows Mobile 6, 64 RAM, 200 MHz PDA, ipaq h5500 Windows CE 4.2, 128 RAM, 400 MHz PDA, ipaq h5500 Windows CE 4.2, 128 RAM, 400 MHz Table 6.1: devices used for the tests 6.4 Performance of Chain Topology The aim of this test is to get the maximum transfer rate on a string of nodes. To obtain the measurement an application for Windows CE was built (.NET Compact Framework 2.0): it is a classic client/server architecture that uses TCP protocol to transfer a file between two hosts and reports the elapsed time. All the devices use OLSR routing protocol with the default settings and HELLO_INTERVAL set to 0.5, except where specified.

101 6.4.1 PDA Emulators 82 All the devices are in the same room, and use OLSR protocol with the broadcast address set to The OCTOPUS machine emulates the chain topology and grabs all the packets sent to Each host knows only the two neighboring nodes like in the OCTOPUS configuration, therefore it sends periodic HELLO messages to the broadcast address declaring only these two hosts as neighbors. When a node wants to comunicate to another node it sends packets directly to it, if this is in his neighbourhood, otherwise it sents packets following the routing path. The sender node never sends application packets to OCTOPUS and, vice versa, the OCTOPUS machine is not be able to know that any two nodes are communicating with each other. The test was ran five times for each configuration, both for real and the emulated devices. Each value reported is the mean value on five attempts PDA Emulators Only desktop machines running the PDA emulator with the Windows Mobile 5 image loaded, are used in this test. The results are reported table 6.2. NODE THROUGHPUT (KBytes/sec) Table 6.2: emulator testing result PDA All the devices used are the real PocketPC, the transfer results are reported in table Mixed In this kind of test are used both real and emulated PDA to build a longer chain, the results are showed in table

102 6.4.4 Conclusion 83 NODE THROUGHPUT (KBytes/sec) Table 6.3: results from real PDA NODE THROUGHPUT (KBytes/sec) Table 6.4: results from a string of real and emulated devices Conclusion The result of the first two tests is showed in 6.1. The chart shows the ideal line and the real data collected. Except from the first result, the emulated line is below the real one. If we carried on with other devices probably the results will align on the same value, because the performance does not depend on the devices but rather the topology. The mean percentage value of difference between the two lines is 22%. The blue curve in Figure 6.2 represents the results of mixed tests. The laboratory testing trend is compliant with what we are arguing in Section Specifically, we found through interpolation that α = 385 and β = The red curve shows the predicted on-field performance according to equation 5.9. It is clear that in the real field, where the devices aren t on the same transmission range, the throughput falls in the chart region between the two curves. Z The values confim the medium sharing theory, they follow the same trend. The conclusion is that the emulator software does not provide the same performance of the real devices

103 6.5 Tuning of the Protocol 84 Figure 6.1: comparison between real and emulated devices Figure 6.2: real trend and theoric predicted performances 6.5 Tuning of the Protocol We can tune OLSR by changing many parameters, but only few of them significantly impact on the protocol efficency. Detailed view of all parameters can be found in Chapter 3. The focus here is on HELLO_INTERVAL, that is the most important value because it influences the mobility reactivity and the overhead of the protocol. The aim of the test is to investigate how increasing or decreasing this parameter affects the topology knowledge of a node, and, hence, the reactivity of the network to topology changes. All real devices are in the same room, and OCTOPUS is used to emulate the chain topology. Ev-

104 6.5.1 Conclusion 85 ery mobility pattern can be considered, instance by instance, as a crossing of chain of nodes; so the single chain can be considered as the building block. Like in previous tests the result of this experiment can be considered as the upper bound, in other words the lowest value can be considered as the maximum value that can be reached by the MANET. It is likely that this value will not be reached because in the real field there are some factors that influence the response time, i.e. the distance of the nodes, but it is important to know that a MANET with OLSR cannot go faster than this value. The scenarios is quite simple (Figure 6.3): the nodes in the chain are fixed and stable; each node knows only two neighbors; at time t node E enters in the range of node D ; we take the time elapsed between t and the first application message received by E. To do this a client/server application that continually sends UDP message from head node to tail node has benn built, this can introduce a small delta time that can be ignored. Calling this time FPT (First Packet Time) it can be broken down in: F P T = 2 chain_time + build_route_time chain_time is the time used by the packet to travel along all the chain and to come back, build_route_time is the fraction of time that is necessary for the head node to build the new routing table and choose the correct path for the packet. This value is the minimum time that a node has to wait, after his entering in the trasmission range, before it is able to receive the first application message by the furthest node of the chain. To catch the exact time, in this test, the head node and the entering node are a personal computer instead of a PDA device, so it easy to use a network sniffer software. The mobility emulation is provided by the OCTOPUS machine. The results can be found in the table 6.5. Each reported value is the mean value on eight runs Conclusion As one can immagine, the FPT value decreases as the HELLO_INTERVAL time, but it is not so linear. These values are collected from real devices and hence this is the whole time, the real mimimun time, that five devices spend to build one single route and to estabilish one single communication.

105 6.6 Tests With Moving Devices 86 HELLO_INTERVAL FPT 4 sec 18.7 sec 2 sec 6.6 sec 1 sec 4.5 sec 0.5 sec 3.5 sec 0.1 sec 8.5 sec Table 6.5: First Packet Time Each value depends on the cpu speed, and the single PDA status; with powerful devices the results can be better. While the 0.1 interval theorically should give a faster response, in a real field this interval gives a slower response. This result is due the inability of the device s cpu to follow the network load. All these values have to be considered for one single traffic flow, so in a real scenarios where the traffic si very high and there are multiple flows, it is important to choose an interval value that allows fast topology reactivity and that does not overload the devices. Between the value of 0.5 and 1 there are only 1 second of difference, for greater value the FPT is too high and it cannot be used in a real environment. Z Considering only the time to build the route and to estabilish the communication any value between 0.5 and 1 are suitable Figure 6.3: chain topology for the test 6.6 Tests With Moving Devices This kind of test is necessary to determine whether or not the implementation is suitable for the real environment. In a real field it is important not to break

106 6.6 Tests With Moving Devices 87 the communication when nodes are moving. If a team member is transmitting information to another team member and one of them is moving, without going out of MANET, all the data must be delivered successfully. To replicate this scenarios three simple topologies are investigated: such as in Figure 6.4, there the dashed lines shows the running path. The following assumptions hold: the moving node is always connected at least to one node there exists always a connection between the moving node and any static node Under these assumptions, to ensure that the connection is still alive during the test time, a Windows CE application is used. It sends continually a TCP packets of 1000 Bytes between the node S and the node D, registering on both side the bytes sent/received. OCTOPUS is used to create the virtual topology and to performe the movements, all the devices are in the laboratory room. To reach an higer number of nodes, five real PDAs and five emulated PDAs are used to performe the test. The test has been running five times for each topology and each run lasted 300 seconds. Results are good enough: for each topology and for each run communication was always alive. It is clear that sometimes the nodes movement has caused changes in the overall topology. These changes have invalidated the route previously computed, making impossible to communicate with destination D. In these cases, for a certain period, communication is impossible, unitl new routes are computed according to the new topology. During this time TCP connection has been in a waiting state, where retransmission have occurred. If all intermediate nodes in the path from S to D compute the route before the TCP timeout expires, the communication can go on. It is important to note that with UDP is not the same, because no retransmission technique is foreseen. For the investigated topologies such a threshold is on average 18 m/s, which is a good result. Z We found that there is a upper ceiling for the nodes speed beyond which TCP connection gets interupted. Therefore we should always keep below this

107 6.7 OCTOPUS Overhead 88 threshold in order to maintain the connection. Figure 6.4: dynamic test 6.7 OCTOPUS Overhead Due to its design the emulator introduces an overhead. This factor might, can affect the results of the tests. An accurate study of the interference 1 of OCTOPUS with the MANET is necessary to determine the correctness of the tests. The study consist in finding the usage of bandwidth (for protocol s control signalling) with and without the OCTOPUS presence. OCTOPUS grabs all the packets sent to the virtual broadcast address, and it uses the real broadcast address to delivery the intercepted packets. As the regards the OLSR protocol, OCTOPUS is transparent for the direct communication; since each node communicates with the destination one via other nodes, nothing going throught OCTOPUS. But OCTOPUS, grabbing 1 not radio interference but bandwidth using interference

108 6.7 OCTOPUS Overhead 89 the broadcast messages, provides the emulated topology vision. In the real case each node sends periodically HELLO messages to the broadcast address, so the number of messages in a second depends only from the number of hosts and the HELLO_INTERVAL. With OCTOPUS, instead, the number of messages increases, because when the emulator grabs a message, it creates one copy of the message for every neighbor. This greater number can affect the throughput because there is a larger use of the bandwidth, which is subtracted to the delivery of actual application data packets. In this case the bandwidth is shared between all the hosts, and all the hosts argue for the medium access. The number of the messages sent in one second, assuming that every node has set the same HELLO_INTERVAL, analitically is: M = n t H = (n 1) U = M H where M is the number of messages sent in one second; n is the number of nodes; t is the HELLO_INTERVAL value expressed in seconds; H is the overhead intruduced by one single packet, it contains the whole network layers s bytes and it depends on the number of neighbors. At last the U value represents the bandwidth usage expressed in bytes/seconds. In the emulation case the first formula changes in: M = n t + n (n 1) t because OCTOPUS, for each grabbed packet, creates a new messages for every node in the test, except the sender one. In Table 6.7 some values calcolated with these two formulas are reported, as well as the percentage of usage compared to the wireless bandwidth, that is considered as nominal value of 11 Mbits/sec. These values are also verified with real devices, with the support of a network sniffer, over runs of the OLSR protocol at least 30-seconds long. The collected data and the analytical data are very close: the relative error between the two values are under the 0.5%. This little gap is due to the jitter in the trasmission interval.

109 6.7 OCTOPUS Overhead 90 REAL OCTOPUS n t M U M U % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % # sec # bytes/sec # bytes/sec Table 6.6: OLSR bandwidth usage, with and without OCTOPUS

110 6.7.1 Conclusion Conclusion For all the tests done, where the number of devices is less than of 10 and the HELLO_INTERVAL is set to 0.5 second, the OCTOPUS overhead can be ignored, because it is a small percentage compared to the entire bandwidth. So during tests, the OCTOPUS machine is transparent and the test results aren t affected by its presence. OCTOPUS cannot be used where the refresh interval is too small or the number of machines is too high. Chart 6.5 that shows the trend of the bandwidth usage respects these two parameters in both cases. From the results table, it is possible to affirm that the smallest interval time does not use too much bandwidth, but it is important to consider the medium access meccanish of wireless medium. It doesn t guarantee the sequential access to all contending interfaces, but it can suffer of starvation for some hosts. So the probabilty to access the medium is inversly propotional to the number of nodes. All MANET performaces are affected by this problem. With the OCTOPUS emulator this aspect is the most relevant. HELLO_INTERVAL influences also the period of TC messages, that aren t taken into consideration in this investigation, because they are present only when the node has a mobility property and because the number of the TC messages is always a fraction of the HELLO messages quantity. Z This brings us to the consideration that it is not advisable to choose a low HELLO_INTERVAL value; the mean solution is the right choice, so any value between 0.5 and 1.5 are the best trade-off between bandwidth usage and medium contending

111 6.7.1 Conclusion MESSAGES HELLO INTERVALL NODES Figure 6.5: number of OLSR messages trend

112 Gravitation cannot be held responsible for people falling in love. How on earth can you explain in terms of chemistry and physics so important a biological phenomenon as first love? Put your hand on a stove for a minute and it seems like an hour. Sit with that special girl for an hour and it seems like a minute. That s relativity. Albert Einstein

113 Chapter 7 Conclusion In this graduate thesis we studied and performed a test of different implementations of a network layer, which allows the communication among mobile devices that are all part of a MANET where there exists no infrastructure or centralized server. The work outcomes will be exploited within the European project WORKPAD that aims to support governmental organisations in the coordination of emergency services, which operate in wreaked areas (e.g. during the rescue operations in the aftermath of a natural catastrophe). Therefore the whole work has been carried out following this project s guidelines. The construction of a network layer has been done through the implementation of a reliable routing protocol. After a careful study of the available protocols, we chose OLSR, as it complies better with WORKPAD requirements. Once OLSR has been studied and analyzed in detail, we searched for protocol implementations. Each implementation has been studied and tested; many turned out not to be working, nor maintained or, simply, not respecting some of the project requirements. After carrying out a preliminary test on the few suitable implementations, we have chosen to use NRLOLSRD. The construction of a stand-alone executable for mobile devices has been an important part of this work. Despite the availability of sources for Windows Mobile, we spent long time programming and adapting the code to the lastest Windows Mobile version. NRLOLSRD is perfectly transparent to the whole system: in fact, high level

114 95 applications, designed to work in a usual network, do not need any changes for being executed in MANETs with NRLOLSRD. This is due to the fact that it operates at a low level, directly changing the system routing table. After creating the network layer, we tried to study the medium wireless and, then, subsequently the algorithm to discover the minimum and maximum performances of the system. From the study of the wireless channel, we can affirm that it is subject to some problems which, sometimes, are not avoidable. By taking into account the Wi- Fi and MANET characteristics, we performed some tests in order to find what the throughput is expected to be in real settings. Knowing the performance level that MANET can provide is very important when developing applications for MANET. Indeed, if we created an application relying on high bandwidths without considering the actual throughput, we would obtain something that is theorically functioning but not practically working. The MANET testing has been carried out with common sense/valuation method, after making sure that all the devices performed according to the standard. One of the most valuable contribute is that we did not test by utilizing simulations (as many other approaches do) but emulation. Simulation returns outcomes which can differ significantly from acctual results. Clearly, on-thefield tests would be best but they require many people moving around in large areas so that experiment repeatability would be compromised. We found a trade-off by using emulation. In our emulated testing phase, PDAs have been actually exchanging packets on the spot. The emulator is, hence, a good tradeoff. The first performance tests, besides confirming the theoretic trend of the throughput, also underline the slowness of the emulators compared to real devices. The test of tuning the protocol showed which minimum refresh interval should be used in order to update delivery routes when underlying MANET topology changes; nevertheless a too low refresh is not suitable, as the devices would use too much CPU percentage. The test with moving nodes guarantees us that the MANET layer is properly working when devices are moving continuously and, hence, topology is frequently changing.

115 96 Results presented in this thesis should be used as a toolkit for researchers, engineers and practitioners willing to use MANETs in their scenarios/systems/applications. Throughput. Section 6.4 allows to carefully take into account the throughput that a MANET of real devices can nowadays support. Figure 6.2 shows the minimum and maximum throughput one should expected when working on MANET. The result is very important when designing applications and middleware on top of MANETs of PDAs. An optimized use of the bandwidth should be carefully designed at application level to cope with limited throughput. Reactivity. Results of Section 6.5 help in designing applications in very dynamic MANETs (a lot of devices entering and exiting), which require very frequent exchanges of messages, thus overloading the bandwidth. Instead applications adopting greater values of HELLO_INTERVAL appear less reactive to changes. Speed. Results of Section 6.6, allow to state that it is possible to build up reliable MANETs, where nodes are moving around with a maximum speed of approximately 65 km/h or less. The results, at the current stage, show that any settings where nodes are cars moving on highway, are not working at all. Indeed, the maximum speed, for which MANET connections are seen to always stay up poses serious doubts about the using of OLSR in VANETs. As a conclusion we may argue that more research and development are needed on engineered algorithms for MANETs of real mobile devices (e.g., PDAs). The implementations currently available have left out an important category of devices (for which MANETs are really interesting and useful), which require specific studies and developments for their strong performance constraints.

116 Thanks I would like to thank Thomas F. Divine and PCAUSA for providing RAWETHER forwince, and Justin Dean of US Naval Research Laboratory for the time and the support provided.

117 Ringraziamenti Non è possibile ringraziare in queste poche righe, tutti quelli che mi hanno dato una mano per arrivare a questo giorno. In questi tre anni a Roma ho passato momenti alti e bassi, ma è stata la mia più bella esperienza, la rifarei senza nessun cambiamento. A malincuore ormai la mia permanenza in questa città è agli sgoccioli, ma ricorderò per sempre con affetto ogni secondo trascorso e vissuto al suo interno. I primi ringraziamenti vanno sicuramente a Daniele e Simone con i quali ho condiviso in tutto e per tutto gli ultimi due anni. Ringrazio Luca che oltre a sopportarmi a lezione, mi ha fatto conoscere tanti altri amici: Giuseppe, Giorgio, Claudio e Pierfrancesco. Un saluto particolare lo riservo a tutti quanti hanno passato, come me, l ultimo anno tra i corridoi del dipartimento: Marco, Lorenzo, Matteo e Carlo. Non posso esimermi dal ringraziare Alessandro e Mattia, con i quali ho passato splendide serate e indimenticabili momenti. Infine voglio esprimere la mia riconoscenza a Corrado, che in due anni mi ha fatto conoscere e vivere Roma, in tutto il suo splendore. Desidero inoltre ringraziare calorosamente l ing. Massimo Mecella e l ing. Massimiliano de Leoni, oltre che per il supporto nello sviluppo della tesi, per avermi fatto trovare un ambiente divertente, sereno e stimolante; nonchè per aver riposto grande fiducia nella mia persona. Gianluca Bertelli

118 Appendix A Tools WIRESHARK - network sniffer IPERF/JPERF - network performance tester MICROSOFT VISUAL STUDIO IDE software MICROSOFT DEVICE EMULATOR PDA emulator NRLOLSR - OLSR implementation OCTOPUS - wireless emulator deleoni/octopus/index.htm OPENNETCF REGISTRY LIBRARY -.NET library

119 Appendix B OCTOPUS OCTOPUS is a emulator software intended to emulate small scale MANETs (maximum 20 nodes). It emulates only physical MAC layer, leaving the rest of the stack untouched. OCTOPUS keeps a map of virtual areas which users can show and design by a GUI. Such a GUI enables users to put in that map virtual nodes and bind each one to a different real device. Further, users can add possible existing obstacles in a real scenario: ruins, walls, buildings. Real devices are unaware about the emulator: when they deliver packets, they believe to send them to destination. Actually, packets are captured by the emulator, playing the role of a gateway. The emulator analyzes which are the sender and the receiver and, taking into account the distances of corresponding virtual nodes, the probability of losses, obstacles screening direct view, motion speed, decides whether to deliver each packet to the receiver. OCTOPUS takes the advantage that, in every moment, programmers can cut the emulator out and perform on field MANET testing or final deploy without any kind of change. OCTOPUS allows to include whichever kind of device, even PDAs or smart- Phones, and applications. OCTOPUS supports and handles possible obstacles, packet losses and enhanced movement models, like Voronoi.

120 Main features provided by OCTOPUS are described as follows: integrated graphical scenario editor: Emulation scenario setup is fully managed via GUI and there is no need to know or use any scripting language at all real time node mobility management: destinations which nodes want to reach, have to be defined at run-time, according to the behavior of client applications. Essentially, movements cannot be defined in a batch way before emulation starts; on the contrary, during emulations, nodes have to somehow inform emulator about their movements towards a given destination. This feature is implemented as a TCP server listening for special movement commands sent by software on board of devices packets losses: The emulation system supports user-defined packet loss policies, described by a customizable range based function. Also have support the rician fading model obstacle aware mobility model: Two movement models are available in OCTOPUS : Way-Point and Voronoi. The first one assumes nodes to move straight on the line joining starting and destination point. The latter is more realistic and it takes into account even possible obstacles along the path. broadcast address emulation: Since devices are connected through a real LAN, you cannot use the normal broadcast IP address, as it would send the packet to all peers in the network without considering routing table. This issue is resolved by adding a customizable virtual broadcast address instead of the usual one node follow feature: Once emulation is started, a node can move in emulated environment so to follow another node

121 Figure B.1: Octopus main window

Behavior Analysis of TCP Traffic in Mobile Ad Hoc Network using Reactive Routing Protocols

Behavior Analysis of TCP Traffic in Mobile Ad Hoc Network using Reactive Routing Protocols Behavior Analysis of TCP Traffic in Mobile Ad Hoc Network using Reactive Routing Protocols Purvi N. Ramanuj Department of Computer Engineering L.D. College of Engineering Ahmedabad Hiteishi M. Diwanji

More information

A Study of Internet Connectivity for Mobile Ad Hoc Networks in NS 2

A Study of Internet Connectivity for Mobile Ad Hoc Networks in NS 2 A Study of Internet Connectivity for Mobile Ad Hoc Networks in NS 2 Alex Ali Hamidian January 2003 Department of Communication Systems Lund Institute of Technology, Lund University Box 118 S-221 00 Lund

More information

Advanced Computer Networks

Advanced Computer Networks Introduction to Mobile Ad hoc Networks (MANETs) Advanced Computer Networks Outline Ad hoc networks Differences to other networks Applications Research areas Routing Other research areas Enabling Technologies

More information

COMPARATIVE ANALYSIS OF ON -DEMAND MOBILE AD-HOC NETWORK

COMPARATIVE ANALYSIS OF ON -DEMAND MOBILE AD-HOC NETWORK www.ijecs.in International Journal Of Engineering And Computer Science ISSN:2319-7242 Volume 2 Issue 5 May, 2013 Page No. 1680-1684 COMPARATIVE ANALYSIS OF ON -DEMAND MOBILE AD-HOC NETWORK ABSTRACT: Mr.Upendra

More information

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc (International Journal of Computer Science & Management Studies) Vol. 17, Issue 01 Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc Dr. Khalid Hamid Bilal Khartoum, Sudan dr.khalidbilal@hotmail.com

More information

Scenario based Performance Analysis of AODV and OLSR in Mobile Ad hoc Networks

Scenario based Performance Analysis of AODV and OLSR in Mobile Ad hoc Networks Scenario based Performance Analysis of AODV and OLSR in Mobile Ad hoc Networks Scenario based Performance Analysis of AODV and OLSR in Mobile Ad hoc Networks S. Gowrishankar, T.G. Basavaraju, M. Singh,

More information

CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING

CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING CHAPTER 6 CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING 6.1 INTRODUCTION The technical challenges in WMNs are load balancing, optimal routing, fairness, network auto-configuration and mobility

More information

PERFORMANCE ANALYSIS OF AD-HOC ON DEMAND DISTANCE VECTOR FOR MOBILE AD- HOC NETWORK

PERFORMANCE ANALYSIS OF AD-HOC ON DEMAND DISTANCE VECTOR FOR MOBILE AD- HOC NETWORK http:// PERFORMANCE ANALYSIS OF AD-HOC ON DEMAND DISTANCE VECTOR FOR MOBILE AD- HOC NETWORK Anjali Sahni 1, Ajay Kumar Yadav 2 1, 2 Department of Electronics and Communication Engineering, Mewar Institute,

More information

International Journal of Advanced Research in Computer Science and Software Engineering

International Journal of Advanced Research in Computer Science and Software Engineering Volume 2, Issue 9, September 2012 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Power Aware

More information

Simulation of Internet Connectivity for Mobile Ad Hoc Networks in Network Simulator-2

Simulation of Internet Connectivity for Mobile Ad Hoc Networks in Network Simulator-2 Simulation of Internet Connectivity for Mobile Ad Hoc Networks in Network Simulator-2 Sulaiman Khalifa Yakhlef, Ismail Shrena, Nasaraldian Ambark Shashoa Azzaytuna University, Faculty of Engineering Tarhuna

More information

Distribution: questo livello include le Base Station utilizzate per stabilire la connettività wireless con gli utenti finali.

Distribution: questo livello include le Base Station utilizzate per stabilire la connettività wireless con gli utenti finali. Il presente documento HLD definisce l architettura e le configurazioni necessarie per separare la rete di management dai servizi dati dedicati al traffico cliente, con l obiettivo di poter accedere agli

More information

Study of Network Characteristics Incorporating Different Routing Protocols

Study of Network Characteristics Incorporating Different Routing Protocols Study of Network Characteristics Incorporating Different Routing Protocols Sumitpal Kaur #, Hardeep S Ryait *, Manpreet Kaur # # M. Tech Student, Department of Electronics and Comm. Engineering, Punjab

More information

Fast and Secure Data Transmission by Using Hybrid Protocols in Mobile Ad Hoc Network

Fast and Secure Data Transmission by Using Hybrid Protocols in Mobile Ad Hoc Network Middle-East Journal of Scientific Research 15 (9): 1290-1294, 2013 ISSN 1990-9233 IDOSI Publications, 2013 DOI: 10.5829/idosi.mejsr.2013.15.9.11514 Fast and Secure Data Transmission by Using Hybrid Protocols

More information

A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks

A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks T.Chandrasekhar 1, J.S.Chakravarthi 2, K.Sravya 3 Professor, Dept. of Electronics and Communication Engg., GIET Engg.

More information

Routing in Mobile Ad Hoc Networks

Routing in Mobile Ad Hoc Networks 16 Routing in Mobile Ad Hoc Networks Fenglien Lee University of Guam Guam 96923, USA 1. Introduction A mobile ad hoc network (MANET), sometimes called a mobile mesh network, is a self- configuring network

More information

MASTER'S THESIS. Routing Protocols in Wireless Ad-hoc Networks - A Simulation Study. Tony Larsson, Nicklas Hedman. Civilingenjörsprogrammet

MASTER'S THESIS. Routing Protocols in Wireless Ad-hoc Networks - A Simulation Study. Tony Larsson, Nicklas Hedman. Civilingenjörsprogrammet 1998:362 MASTER'S THESIS Routing Protocols in Wireless Ad-hoc Networks - A Simulation Study Tony Larsson, Nicklas Hedman Civilingenjörsprogrammet 1998:362 ISSN: 1402-1617 ISRN: LTU-EX--98/362--SE Master

More information

Lecture 2.1 : The Distributed Bellman-Ford Algorithm. Lecture 2.2 : The Destination Sequenced Distance Vector (DSDV) protocol

Lecture 2.1 : The Distributed Bellman-Ford Algorithm. Lecture 2.2 : The Destination Sequenced Distance Vector (DSDV) protocol Lecture 2 : The DSDV Protocol Lecture 2.1 : The Distributed Bellman-Ford Algorithm Lecture 2.2 : The Destination Sequenced Distance Vector (DSDV) protocol The Routing Problem S S D D The routing problem

More information

Formal Measure of the Effect of MANET size over the Performance of Various Routing Protocols

Formal Measure of the Effect of MANET size over the Performance of Various Routing Protocols Formal Measure of the Effect of MANET size over the Performance of Various Routing Protocols Er. Pooja Kamboj Research Scholar, CSE Department Guru Nanak Dev Engineering College, Ludhiana (Punjab) Er.

More information

Nuovi domini di primo livello - Registra nuove estensioni con FabsWeb_HOST

Nuovi domini di primo livello - Registra nuove estensioni con FabsWeb_HOST Oltre 700 nuove estensioni per domini personalizzati Il conto alla rovescia è terminato! Finalmente più di 700 nuove estensioni di dominio gtld stanno per arrivare sul mercato e sono destinate a rivoluzionare

More information

Tecnologie e Protocolli per Internet 1 Introduzione al NAT Network Address Translation

Tecnologie e Protocolli per Internet 1 Introduzione al NAT Network Address Translation Tecnologie e Protocolli per Internet 1 Introduzione al NAT Network Address Translation Prof. Stefano Salsano e-mail: stefano.salsano@uniroma2.it AA2012/13 Blocco 10 Le slides di questo blocco sono tratte

More information

An Extended AODV Protocol to Support Mobility in Hybrid Networks

An Extended AODV Protocol to Support Mobility in Hybrid Networks An Extended AODV Protocol to Support Mobility in Hybrid Networks Sèmiyou A. Adédjouma* Polytechnic School of Abomey-Calavi (EPAC) University of Abomey-Calavi (UAC) Cotonou, Benin *semiyou.adedjouma {at}

More information

Virtual LANs. Tecnologie e Protocolli per Internet 1. Prof. Stefano Salsano e-mail: stefano.salsano@uniroma2.it. AA2011/12 Blocco 4 v2

Virtual LANs. Tecnologie e Protocolli per Internet 1. Prof. Stefano Salsano e-mail: stefano.salsano@uniroma2.it. AA2011/12 Blocco 4 v2 Tecnologie e Protocolli per Internet 1 Prof. Stefano Salsano e-mail: stefano.salsano@uniroma2.it AA2011/12 Blocco 4 v2 Virtual LANs Broadcast issues Switches: - did partition collision domains - bud DID

More information

EXTENDING NETWORK KNOWLEDGE: MAKING OLSR A QUALITY OF SERVICE CONDUCIVE PROTOCOL

EXTENDING NETWORK KNOWLEDGE: MAKING OLSR A QUALITY OF SERVICE CONDUCIVE PROTOCOL EXTENDING NETWORK KNOWLEDGE: MAKING OLSR A QUALITY OF SERVICE CONDUCIVE PROTOCOL by Pedro Eduardo Villanueva-Pena, Thomas Kunz Carleton University January, 2006 This report examines mechanisms to gradually

More information

A Survey on Reduction in Energy Consumption by Improved AODV on Mobile Ad Hoc Network

A Survey on Reduction in Energy Consumption by Improved AODV on Mobile Ad Hoc Network International Journal of Computer Sciences and Engineering Open Access Review Paper Volume-4, Issue-2 E-ISSN: 2347-2693 A Survey on Reduction in Energy Consumption by Improved AODV on Mobile Ad Hoc Network

More information

An Efficient QoS Routing Protocol for Mobile Ad-Hoc Networks *

An Efficient QoS Routing Protocol for Mobile Ad-Hoc Networks * An Efficient QoS Routing Protocol for Mobile Ad-Hoc Networks * Inwhee Joe College of Information and Communications Hanyang University Seoul, Korea iwj oeshanyang.ac.kr Abstract. To satisfy the user requirements

More information

SURVEY OF OPTIMISTIC POWER AWARE ROUTING PROTOCOLS IN MOBILE DATACENTER NETWORKS

SURVEY OF OPTIMISTIC POWER AWARE ROUTING PROTOCOLS IN MOBILE DATACENTER NETWORKS SURVEY OF OPTIMISTIC POWER AWARE ROUTING PROTOCOLS IN MOBILE DATACENTER NETWORKS Ganesan Veerappan 1 and C. Suresh Gnana Dhas 2 1 Research and Development Centre, Bharathiar University, Coimbatore, Tamil

More information

Keywords: DSDV and AODV Protocol

Keywords: DSDV and AODV Protocol Volume 3, Issue 12, December 2013 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Comparison

More information

Misurazione performance. Processing time. Performance. Throughput. Francesco Marchioni Mastertheboss.com Javaday IV Roma 30 gennaio 2010

Misurazione performance. Processing time. Performance. Throughput. Francesco Marchioni Mastertheboss.com Javaday IV Roma 30 gennaio 2010 Misurazione performance Processing time Performance Throughput Processing time Network Network DB Processing time Throughput Quantità di dati trasmessi x secondo Tuning Areas Tuning Java Virtual Machine

More information

VOICE COMMUNICATION OVER MOBILE AD-HOC NETWORKS

VOICE COMMUNICATION OVER MOBILE AD-HOC NETWORKS VOICE COMMUNICATION OVER MOBILE AD-HOC NETWORKS A thesis submitted in partial fulfillment of the requirements for the degree of Bachelor of Science in Engineering Department of Computer Science and Engineering

More information

SIMULATION STUDY OF BLACKHOLE ATTACK IN THE MOBILE AD HOC NETWORKS

SIMULATION STUDY OF BLACKHOLE ATTACK IN THE MOBILE AD HOC NETWORKS Journal of Engineering Science and Technology Vol. 4, No. 2 (2009) 243-250 School of Engineering, Taylor s University College SIMULATION STUDY OF BLACKHOLE ATTACK IN THE MOBILE AD HOC NETWORKS SHEENU SHARMA

More information

NetworkPathDiscoveryMechanismforFailuresinMobileAdhocNetworks

NetworkPathDiscoveryMechanismforFailuresinMobileAdhocNetworks Global Journal of Computer Science and Technology: E Network, Web & Security Volume 14 Issue 3 Version 1.0 Year 2014 Type: Double Blind Peer Reviewed International Research Journal Publisher: Global Journals

More information

User Manual ZMONITOR. Tool for managing parametric controllers

User Manual ZMONITOR. Tool for managing parametric controllers User Manual ZMONITOR Tool for managing parametric controllers INDICE 1. PRESENTATION... 4 MINIMUM SYSTEM REQUIREMENTS... 4 DEVICES TO BE MANAGED ZMONITOR... 5 2. INSTALLATION... 6 3. LANGUAGE... 8 4. MAIN

More information

LIST OF FIGURES. Figure No. Caption Page No.

LIST OF FIGURES. Figure No. Caption Page No. LIST OF FIGURES Figure No. Caption Page No. Figure 1.1 A Cellular Network.. 2 Figure 1.2 A Mobile Ad hoc Network... 2 Figure 1.3 Classifications of Threats. 10 Figure 1.4 Classification of Different QoS

More information

PERFORMANCE ANALYSIS OF AODV, DSDV AND AOMDV USING WIMAX IN NS-2

PERFORMANCE ANALYSIS OF AODV, DSDV AND AOMDV USING WIMAX IN NS-2 International Journal of Computer Engineering & Technology (IJCET) Volume 7, Issue 1, Jan-Feb 2016, pp. 01-08, Article ID: IJCET_07_01_001 Available online at http://www.iaeme.com/ijcet/issues.asp?jtype=ijcet&vtype=7&itype=1

More information

DESIGN AND DEVELOPMENT OF LOAD SHARING MULTIPATH ROUTING PROTCOL FOR MOBILE AD HOC NETWORKS

DESIGN AND DEVELOPMENT OF LOAD SHARING MULTIPATH ROUTING PROTCOL FOR MOBILE AD HOC NETWORKS DESIGN AND DEVELOPMENT OF LOAD SHARING MULTIPATH ROUTING PROTCOL FOR MOBILE AD HOC NETWORKS K.V. Narayanaswamy 1, C.H. Subbarao 2 1 Professor, Head Division of TLL, MSRUAS, Bangalore, INDIA, 2 Associate

More information

Delivering Messages in Disconnected Mobile Ad-Hoc Networks

Delivering Messages in Disconnected Mobile Ad-Hoc Networks Delivering Messages in Disconnected Mobile Ad-Hoc Networks by Ritesh Shah B.Engg., Rajiv Gandhi Technical University, 2001 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF

More information

Customer Specific Wireless Network Solutions Based on Standard IEEE 802.15.4

Customer Specific Wireless Network Solutions Based on Standard IEEE 802.15.4 Customer Specific Wireless Network Solutions Based on Standard IEEE 802.15.4 Michael Binhack, sentec Elektronik GmbH, Werner-von-Siemens-Str. 6, 98693 Ilmenau, Germany Gerald Kupris, Freescale Semiconductor

More information

Reti Informatiche. WireShark. www.wireshark.org

Reti Informatiche. WireShark. www.wireshark.org Reti Informatiche WireShark www.wireshark.org What is WireShark Wireshark is a network packet analyzer. A network packet analyzer will try to capture network packets and tries to display that packet data

More information

Keywords- manet, routing protocols, aodv, olsr, grp,data drop parameter.

Keywords- manet, routing protocols, aodv, olsr, grp,data drop parameter. Volume 5, Issue 3, March 2015 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Evaluation of

More information

Ad hoc On Demand Distance Vector (AODV) Routing Protocol

Ad hoc On Demand Distance Vector (AODV) Routing Protocol Ad hoc On Demand Distance Vector (AODV) Routing Protocol CS: 647 Advanced Topics in Wireless Networks Dr. Baruch Awerbuch & Dr. Amitabh Mishra Department of Computer Science Johns Hopkins 4-1 Reading Chapter

More information

Security and Scalability of MANET Routing Protocols in Homogeneous & Heterogeneous Networks

Security and Scalability of MANET Routing Protocols in Homogeneous & Heterogeneous Networks Security and Scalability of MANET Routing Protocols in Homogeneous & Heterogeneous Networks T.V.P. Sundararajan 1, Karthik 2, A. Shanmugam 3 1. Assistant Professor, Bannari Amman Institute Of Technology,

More information

Security for Ad Hoc Networks. Hang Zhao

Security for Ad Hoc Networks. Hang Zhao Security for Ad Hoc Networks Hang Zhao 1 Ad Hoc Networks Ad hoc -- a Latin phrase which means "for this [purpose]". An autonomous system of mobile hosts connected by wireless links, often called Mobile

More information

Security Threats in Mobile Ad Hoc Networks

Security Threats in Mobile Ad Hoc Networks Security Threats in Mobile Ad Hoc Networks Hande Bakiler, Aysel Şafak Department of Electrical & Electronics Engineering Baskent University Ankara, Turkey 21020013@baskent.edu.tr, asafak@baskent.edu.tr

More information

ROUTE MECHANISMS FOR WIRELESS ADHOC NETWORKS: -CLASSIFICATIONS AND COMPARISON ANALYSIS

ROUTE MECHANISMS FOR WIRELESS ADHOC NETWORKS: -CLASSIFICATIONS AND COMPARISON ANALYSIS International Journal of Science, Environment and Technology, Vol. 1, No 2, 2012, 72-79 ROUTE MECHANISMS FOR WIRELESS ADHOC NETWORKS: -CLASSIFICATIONS AND COMPARISON ANALYSIS Ramesh Kait 1, R. K. Chauhan

More information

How to renew S&S Video Italian version. 2009 IBM Corporation

How to renew S&S Video Italian version. 2009 IBM Corporation How to renew S&S Video Italian version A. Renewal Email Lasciate che vi illustri come rinnovare le vostre licenze software IBM con Passport Advantage Online. (Let me show you how to renew your IBM software

More information

Study And Comparison Of Mobile Ad-Hoc Networks Using Ant Colony Optimization

Study And Comparison Of Mobile Ad-Hoc Networks Using Ant Colony Optimization Study And Comparison Of Mobile Ad-Hoc Networks Using Ant Colony Optimization 1 Neha Ujala Tirkey, 2 Navendu Nitin, 3 Neelesh Agrawal, 4 Arvind Kumar Jaiswal 1 M. Tech student, 2&3 Assistant Professor,

More information

Corso: Supporting and Troubleshooting Windows 10 Codice PCSNET: MW10-3 Cod. Vendor: 10982 Durata: 5

Corso: Supporting and Troubleshooting Windows 10 Codice PCSNET: MW10-3 Cod. Vendor: 10982 Durata: 5 Corso: Supporting and Troubleshooting Windows 10 Codice PCSNET: MW10-3 Cod. Vendor: 10982 Durata: 5 Obiettivi Al termine del corso i partecipanti saranno in grado di: Descrivere i processi coinvolti nella

More information

Cloud Services: cosa sono e quali vantaggi portano alle aziende manifatturiere

Cloud Services: cosa sono e quali vantaggi portano alle aziende manifatturiere Cloud Services: cosa sono e quali vantaggi portano alle aziende manifatturiere Sergio Gimelli Sales Consulting Director Oracle Italy Fabbrica Futuro Verona, 27 Giugno 2013 1 2 Cosa è il Cloud? il Cloud

More information

Security in Ad Hoc Network

Security in Ad Hoc Network Security in Ad Hoc Network Bingwen He Joakim Hägglund Qing Gu Abstract Security in wireless network is becoming more and more important while the using of mobile equipments such as cellular phones or laptops

More information

Performance Analysis of Load Balancing in MANET using On-demand Multipath Routing Protocol

Performance Analysis of Load Balancing in MANET using On-demand Multipath Routing Protocol ISSN: 2278 1323 All Rights Reserved 2014 IJARCET 2106 Performance Analysis of Load Balancing in MANET using On-demand Multipath Routing Protocol Monika Malik, Partibha Yadav, Ajay Dureja Abstract A collection

More information

Level 1 Opportunistic Locks

Level 1 Opportunistic Locks Level 1 Opportunistic Locks Si intuisce che level 1 corrisponde concettualmente allo stato M di un dato in cache nel protocollo MESI A level 1 opportunistic lock on a file allows a client to read ahead

More information

PEER PRODUCTION+! OPEN INNOVATION!

PEER PRODUCTION+! OPEN INNOVATION! STEFANO MAFFEI! PEER PRODUCTION+! OPEN INNOVATION! A NEW DESIGN PARADIGM!! DESIGN SCHOOL _ POLITECNICO DI MILANO! Corso di Laurea Magistrale in Design _ Anno Accademico 2011/2012!! Cultori della materia:

More information

Step by Step Procedural Comparison of DSR, AODV and DSDV Routing protocol

Step by Step Procedural Comparison of DSR, AODV and DSDV Routing protocol th International Conference on Computer Engineering and Technology (ICCET ) IPCSIT vol. () () IACSIT Press, Singapore Step by Step Procedural Comparison of DSR, AODV and DSDV Routing protocol Amith Khandakar

More information

VoIP over MANET (VoMAN): QoS & Performance Analysis of Routing Protocols for Different Audio Codecs

VoIP over MANET (VoMAN): QoS & Performance Analysis of Routing Protocols for Different Audio Codecs VoIP over MANET (VoMAN): QoS & Performance Analysis of Routing Protocols for Different Audio Codecs Said El brak Mohammed Bouhorma Anouar A.Boudhir ABSTRACT Voice over IP (VoIP) has become a popular Internet

More information

Performance Evaluation of Aodv and Dsr Routing Protocols for Vbr Traffic for 150 Nodes in Manets

Performance Evaluation of Aodv and Dsr Routing Protocols for Vbr Traffic for 150 Nodes in Manets Performance Evaluation of Aodv and Dsr Routing Protocols for Vbr Traffic for 150 Nodes in Manets Gurpreet Singh, 1 Atinderpal Singh 2, 1, 2 Department of CSE & IT, BBSBEC, Fatehgarh Sahib, Punjab, India

More information

Comprehensive Evaluation of AODV, DSR, GRP, OLSR and TORA Routing Protocols with varying number of nodes and traffic applications over MANETs

Comprehensive Evaluation of AODV, DSR, GRP, OLSR and TORA Routing Protocols with varying number of nodes and traffic applications over MANETs IOSR Journal of Computer Engineering (IOSR-JCE) e-issn: 2278-0661, p- ISSN: 2278-8727Volume 9, Issue 3 (Mar. - Apr. 2013), PP 54-61 Comprehensive Evaluation of AODV, DSR, GRP, OLSR and TORA Routing Protocols

More information

Investigating the Performance of Routing Protocols Using Quantitative Metrics in Mobile Ad Hoc Networks

Investigating the Performance of Routing Protocols Using Quantitative Metrics in Mobile Ad Hoc Networks Investigating the Performance of Routing Protocols Using Quantitative Metrics in Mobile Ad Hoc Networks T. Jagadeepak 1, Dr. B. Prabhakara Rao 2, B. A. S. Roopa Devi 3 PG Student, Dept. of ECE, UCEK, JNTU,

More information

A Link-state QoS Routing Protocol for Ad Hoc Networks

A Link-state QoS Routing Protocol for Ad Hoc Networks A Link-state QoS Routing Protocol for Ad Hoc Networks Anelise Munaretto 1 Hakim Badis 2 Khaldoun Al Agha 2 Guy Pujolle 1 1 LIP6 Laboratory, University of Paris VI, 8, rue du Capitaine Scott, 75015, Paris,

More information

Congestion control in Mobile Ad-Hoc Networks (MANETs)

Congestion control in Mobile Ad-Hoc Networks (MANETs) Congestion control in Mobile Ad-Hoc Networks (MANETs) A REPORT SUBMITTED TO SADIA HAMID KAZI OF COMPUTER SCIENCE AND ENGINEERING DEPARTMENT OF BRAC UNIVERSITY IN FULFILLMENT OF THE REQUIREMENTS FOR THESIS

More information

INTERNATIONAL JOURNAL OF PURE AND APPLIED RESEARCH IN ENGINEERING AND TECHNOLOGY

INTERNATIONAL JOURNAL OF PURE AND APPLIED RESEARCH IN ENGINEERING AND TECHNOLOGY INTERNATIONAL JOURNAL OF PURE AND APPLIED RESEARCH IN ENGINEERING AND TECHNOLOGY A PATH FOR HORIZING YOUR INNOVATIVE WORK AN OVERVIEW OF MOBILE ADHOC NETWORK: INTRUSION DETECTION, TYPES OF ATTACKS AND

More information

Chi sono in quattro punti.

Chi sono in quattro punti. vsphere 5 Licensing Chi sono in quattro punti. Massimiliano Moschini Presales/Postsales and Trainer VMUG IT Board Member VCP, VSP VTSP,VCI, V http://it.linkedin.com/in/massimilianomoschini @maxmoschini

More information

PREPOSITION OF PLACE

PREPOSITION OF PLACE PREPOSITION OF PLACE UNDER = sotto OVER = sopra (senza contatto) IN = dentro ON = sopra (con contatto) IN FRONT OF = davanti BEHIND = dietro NEXT TO = a fianco BETWEEN = fra due cose AMONG = fra una moltitudine

More information

A Performance Comparison of Stability, Load-Balancing and Power-Aware Routing Protocols for Mobile Ad Hoc Networks

A Performance Comparison of Stability, Load-Balancing and Power-Aware Routing Protocols for Mobile Ad Hoc Networks A Performance Comparison of Stability, Load-Balancing and Power-Aware Routing Protocols for Mobile Ad Hoc Networks Natarajan Meghanathan 1 and Leslie C. Milton 2 1 Jackson State University, 1400 John Lynch

More information

Programmable Graphics Hardware

Programmable Graphics Hardware Programmable Graphics Hardware Alessandro Martinelli alessandro.martinelli@unipv.it 6 November 2011 Rendering Pipeline (6): Programmable Graphics Hardware Rendering Architecture First Rendering Pipeline

More information

ISSUES AND CHALLENGES OF QUALITY OF SERVICE IN MOBILE ADHOC NETWORK

ISSUES AND CHALLENGES OF QUALITY OF SERVICE IN MOBILE ADHOC NETWORK ISSUES AND CHALLENGES OF QUALITY OF SERVICE IN MOBILE ADHOC NETWORK Mukesh Kumar Student (Ph.D) Department of Computer Engineering The Technological Institute of Textile and Science, Bhiwani-127021, Haryana

More information

INTELLIGENT LOAD BALANCING IN MOBILE AD HOC NETWORKS. A Thesis by. Varun Khanna. Bachelor of Technology, Kurukshetra University, India, 2004

INTELLIGENT LOAD BALANCING IN MOBILE AD HOC NETWORKS. A Thesis by. Varun Khanna. Bachelor of Technology, Kurukshetra University, India, 2004 INTELLIGENT LOAD BALANCING IN MOBILE AD HOC NETWORKS A Thesis by Varun Khanna Bachelor of Technology, Kurukshetra University, India, 2004 Submitted to the Department of Electrical Engineering and Computer

More information

A Comprehensive Analysis on Route Discovery and Maintenance Features of DSDV, AODV and IERF Ad-hoc Routing Protocols

A Comprehensive Analysis on Route Discovery and Maintenance Features of DSDV, AODV and IERF Ad-hoc Routing Protocols International Journal of Computer Sciences and Engineering Open Access Research Paper Volume-4, Issue-2 E-ISSN: 2347-2693 A Comprehensive Analysis on Route Discovery and Maintenance Features of DSDV, AODV

More information

IJMIE Volume 2, Issue 7 ISSN: 2249-0558

IJMIE Volume 2, Issue 7 ISSN: 2249-0558 Evaluating Performance of Audio conferencing on Reactive Routing Protocols for MANET Alak Kumar Sarkar* Md. Ibrahim Abdullah* Md. Shamim Hossain* Ahsan-ul-Ambia* Abstract Mobile ad hoc network (MANET)

More information

A Performance Comparison of Routing Protocols for Large-Scale Wireless Mobile Ad Hoc Networks

A Performance Comparison of Routing Protocols for Large-Scale Wireless Mobile Ad Hoc Networks A Performance Comparison of Routing Protocols for Large-Scale Wireless Mobile Ad Hoc Networks Ioannis Broustis Gentian Jakllari Thomas Repantis Mart Molle Department of Computer Science & Engineering University

More information

DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks

DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks DSR: The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc Networks David B. Johnson David A. Maltz Josh Broch Computer Science Department Carnegie Mellon University Pittsburgh, PA 15213-3891

More information

Zone Routing Protocol (ZRP)

Zone Routing Protocol (ZRP) Zone Routing Protocol (ZRP) Nicklas Beijar Networking Laboratory, Helsinki University of Technology P.O. Box 3000, FIN-02015 HUT, Finland Nicklas.Beijar@hut.fi Abstract Routing protocols for mobile ad-hoc

More information

An Efficient AODV-Based Algorithm for Small Area MANETS

An Efficient AODV-Based Algorithm for Small Area MANETS An Efficient AODV-Based Algorithm for Small Area MANETS Jai Prakash Kumawat 1, Prakriti Trivedi 2 PG Student, Department of Computer Engineering & IT, Government Engineering College, Ajmer, India 1 Assistant

More information

Abstract. 1 Introduction. Aleksandr Huhtonen Helsinki University of Technology Telecommunication Software and Multimedia Laboratory ahuhtone@cc.hut.

Abstract. 1 Introduction. Aleksandr Huhtonen Helsinki University of Technology Telecommunication Software and Multimedia Laboratory ahuhtone@cc.hut. Comparing AODV and OLSR Routing Protocols Aleksandr Huhtonen Helsinki University of Technology Telecommunication Software and Multimedia Laboratory ahuhtone@cc.hut.fi Abstract An ad hoc wireless network

More information

INFORMATICA INDUSTRIALE

INFORMATICA INDUSTRIALE INFORMATICA INDUSTRIALE Lezione 5 Prof. Christian Forlani forlani@disco.unimib.it Device Structure: Peripherals» I/O» Parallel Slave Port (PSP)» Timer» Capture/Compare/PWM (CCP)» Serial Slave Port (SSP)»

More information

Performance of VoIP strategies for hybrid Mobile Ad Hoc Networks

Performance of VoIP strategies for hybrid Mobile Ad Hoc Networks Department of Computer Science Gonzalo Iglesias Aguiño Performance of VoIP strategies for hybrid Mobile Ad Hoc Networks Computer Networks D-level thesis (20p) Date: 061221 Supervisor: Andreas Kassler Examiner:

More information

International Journal of Wireless & Mobile Networks (IJWMN) Vol. 4, No. 2, April 2012

International Journal of Wireless & Mobile Networks (IJWMN) Vol. 4, No. 2, April 2012 PERFORMANCE EVALUATION OF DIFFERENT WIRELESS AD HOC ROUTING PROTOCOLS Niranjan Kumar Ray 1 and Ashok Kumar Turuk 2 Department of Computer Science and Engineering, National Institute of Technology Rourkela,

More information

Delay aware Reactive Routing Protocols for QoS in MANETs: a Review

Delay aware Reactive Routing Protocols for QoS in MANETs: a Review Delay aware Reactive Routing Protocols for QoS in MANETs: a Review Saad M. Adam*, Rosilah Hassan Network and Communication Technology Research Group, Faculty of Information Science and Technology, Universiti

More information

ITIL v3 - Overview. Claudio Tancini Marzo 2015 INTERNAL USE ONLY

ITIL v3 - Overview. Claudio Tancini Marzo 2015 INTERNAL USE ONLY ITIL v3 - Overview Claudio Tancini Marzo 2015 ITIL Da Wikipedia, l'enciclopedia libera. Information Technology Infrastructure Library (ITIL) è un insieme di linee guida ispirate dalla pratica (Best Practices)

More information

Achieving Energy Efficiency in MANETs by Using Load Balancing Approach

Achieving Energy Efficiency in MANETs by Using Load Balancing Approach International Journal of Computer Networks and Communications Security VOL. 3, NO. 3, MARCH 2015, 88 94 Available online at: www.ijcncs.org E-ISSN 2308-9830 (Online) / ISSN 2410-0595 (Print) Achieving

More information

SCADA / Smart Grid Security Who is really in control of our Control Systems?

SCADA / Smart Grid Security Who is really in control of our Control Systems? SCADA / Smart Grid Security Who is really in control of our Control Systems? Simone Riccetti Certified SCADA Security Architect Agenda Overview of Security landscape SCADA security problem How to protect

More information

PERFORMANCE OF MOBILE AD HOC NETWORKING ROUTING PROTOCOLS IN REALISTIC SCENARIOS

PERFORMANCE OF MOBILE AD HOC NETWORKING ROUTING PROTOCOLS IN REALISTIC SCENARIOS PERFORMANCE OF MOBILE AD HOC NETWORKING ROUTING PROTOCOLS IN REALISTIC SCENARIOS Julian Hsu, Sameer Bhatia, Mineo Takai, Rajive Bagrodia, Scalable Network Technologies, Inc., Culver City, CA, and Michael

More information

Load Balancing and Resource Reservation in Mobile Ad-Hoc Networks 1

Load Balancing and Resource Reservation in Mobile Ad-Hoc Networks 1 Load Balancing and Resource Reservation in Mobile Ad-Hoc Networks 1 Gautam Chakrabarti Sandeep Kulkarni Department of Computer Science and Engineering Michigan State University Abstract To ensure uninterrupted

More information

Design and Implementation of Ad-hoc Communication and Application on Mobile Phone Terminals

Design and Implementation of Ad-hoc Communication and Application on Mobile Phone Terminals Design and Implementation of Ad-hoc Communication and Application on Mobile Phone Terminals Yujin Noishiki Hidetoshi Yokota Akira Idoue KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino-Shi, Saitama,

More information

Lezione 10 Introduzione a OPNET

Lezione 10 Introduzione a OPNET Corso di A.A. 2007-2008 Lezione 10 Introduzione a OPNET Ing. Marco GALEAZZI 1 What is OPNET? Con il nome OPNET viene indicata una suite di prodotti software sviluppati e commercializzati da OPNET Technologies,

More information

Technologies and systems for business integration. www.xdatanet.com

Technologies and systems for business integration. www.xdatanet.com Technologies and systems for business integration www.xdatanet.com X DataNet, X software DataNet, builders software builders We have been We building, have been creating, building, and creating, developing

More information

LED Power. Power Supplies for constant current HI-POWER LEDs 350/700mA Alimentatori per LED in corrente costante HI-POWER 350/700mA 82206/700

LED Power. Power Supplies for constant current HI-POWER LEDs 350/700mA Alimentatori per LED in corrente costante HI-POWER 350/700mA 82206/700 LED Power The power supplies and accessories showed in this section are designed to achieve the best lighting and long lasting performances for LED fixtures. A particular attention has been dedicated to

More information

Wireless Mesh Networks under FreeBSD

Wireless Mesh Networks under FreeBSD Wireless Networks under FreeBSD Rui Paulo rpaulo@freebsd.org The FreeBSD Project AsiaBSDCon 2010 - Tokyo, Japan Abstract With the advent of low cost wireless chipsets, wireless mesh networks became much

More information

Corso: Mastering Microsoft Project 2010 Codice PCSNET: MSPJ-11 Cod. Vendor: 50413 Durata: 3

Corso: Mastering Microsoft Project 2010 Codice PCSNET: MSPJ-11 Cod. Vendor: 50413 Durata: 3 Corso: Mastering Microsoft Project 2010 Codice PCSNET: MSPJ-11 Cod. Vendor: 50413 Durata: 3 Obiettivi Comprendere la disciplina del project management in quanto si applica all'utilizzo di Project. Apprendere

More information

APC-Pro sa Computer Service

APC-Pro sa Computer Service Installing and Configuring Windows Server 2012 (20410A) Durata: 5 giorni Orario: 8:30 12:00 / 13:30-17.00 Costo per persona: CHF 1 900.-- (Min. 5 partecipanti) Obiettivi di formazione Al termine del corso

More information

Performance Comparison Of MANET Routing Protocols In Different Network Sizes

Performance Comparison Of MANET Routing Protocols In Different Network Sizes Performance Comparison Of MANET Routing Protocols In Different Network Sizes Computer Science Project David Oliver Jörg Institute of Computer Science and Applied Mathematics Computer Networks and Distributed

More information

Intelligent Agents for Routing on Mobile Ad-Hoc Networks

Intelligent Agents for Routing on Mobile Ad-Hoc Networks Intelligent Agents for Routing on Mobile Ad-Hoc Networks Y. Zhou Dalhousie University yzhou@cs.dal.ca A. N. Zincir-Heywood Dalhousie University zincir@cs.dal.ca Abstract This paper introduces a new agent-based

More information

Mobile Ad-Hoc Networks

Mobile Ad-Hoc Networks Mobile Ad-Hoc Networks Andreas Tønnesen andreto@olsr.org www.olsr.org www.unik.no Agenda A introduction to MANET Routing in MANETs Optimized LinkState Routing The UniK OLSR implementation Extensions to

More information

Simulation vs. Emulation: Evaluating Mobile Ad Hoc Network Routing Protocols

Simulation vs. Emulation: Evaluating Mobile Ad Hoc Network Routing Protocols Simulation vs. Emulation: Evaluating Mobile Ad Hoc Network Routing Protocols Furqan Haq and Thomas Kunz Systems and Computer Engineering Carleton University Ottawa, Ont., Canada K1S 5B haq_furqan@hotmail.com,

More information

Corso: Configuring and Administering Windows 7 Codice PCSNET: MSW7-8 Cod. Vendor: 50322 Durata: 5

Corso: Configuring and Administering Windows 7 Codice PCSNET: MSW7-8 Cod. Vendor: 50322 Durata: 5 Corso: Configuring and Administering Windows 7 Codice PCSNET: MSW7-8 Cod. Vendor: 50322 Durata: 5 Obiettivi Descrivere e scegliere le varie versioni di Windows 7 Eseguire una nuova installazione di Windows

More information

Internetworking e applicazioni

Internetworking e applicazioni Internetworking e applicazioni Scenario Singole LAN Singole WAN La maggior parte delle industrie hanno reti strutturate che combinano diverse LAN e WAN. La maggior parte delle reti internet utilizzano

More information

INVESTIRE IN BORSA CON I TREND PDF

INVESTIRE IN BORSA CON I TREND PDF INVESTIRE IN BORSA CON I TREND PDF ==> Download: INVESTIRE IN BORSA CON I TREND PDF INVESTIRE IN BORSA CON I TREND PDF - Are you searching for Investire In Borsa Con I Trend Books? Now, you will be happy

More information

UNIT 8:- Mobile Ad-Hoc Networks, Wireless Sensor Networks

UNIT 8:- Mobile Ad-Hoc Networks, Wireless Sensor Networks UNIT 8:- Mobile Ad-Hoc Networks, Wireless Sensor Networks a Mobile Ad hoc NETwork (MANET) is one that comes together as needed, not necessarily with any support from the existing infrastructure or any

More information

INFORMATICA INDUSTRIALE

INFORMATICA INDUSTRIALE INFORMATICA INDUSTRIALE Lezione 6 Prof. Christian Forlani forlani@disco.unimib.it Tutor: Stefano Brusamolino brusamolino@ira.disco.unimib.it Device Structure: Peripherals» I/O» Parallel Slave Port (PSP)»

More information

Lorenzo.barbieri@microsoft.com Blogs.msdn.com/vstsitalia. www.geniodelmale.info

Lorenzo.barbieri@microsoft.com Blogs.msdn.com/vstsitalia. www.geniodelmale.info Lorenzo.barbieri@microsoft.com Blogs.msdn.com/vstsitalia www.geniodelmale.info Visual Studio Team System, Professional e Standard Team Explorer si integra in VS2008/VS2005 Visual Studio.NET 2003, VS 6.0,

More information