Performance en diagnostiek mo- nitor voor heterogene ad hoc netwerken

Bachelor Informatica

Performance en diagnostiek

mo-nitor voor heterogene ad hoc

netwerken

Erik Landkroon

17 augustus 2016

Inf

orma

tica

—

Universiteit

v

an

Ams

terd

am

Samenvatting

Ad hoc netwerk zijn zelf organiserende netwerken zonder centrale sturing. Het is niet noodzakelijk dat alle nodes direct met elkaar verbonden zijn binnen een ad hoc netwerk, doordat er gecommuniceerd kan worden tussen de nodes door middel van (multi-)hopping. Een (heterogeen) ad hoc netwerk heeft verschillende karakteristieken die invloed hebben op hoe het netwerk zich gedraagt [8].

In deze scriptie is onderzocht of de karakteristieken van een heterogeen ad hoc netwerk te visualiseren zijn door middel van een monitor systeem. Deze karakteristieken moeten zo worden weergegeven dat deze interpreteerbaar zijn, waardoor het gedrag van het ad hoc netwerk geanalyseerd kan worden.

Hiervoor is onderzocht hoe de karakteristieken van het ad hoc netwerk en de individu-ele nodes gemeten kunnen worden. Tevens is er onderzocht hoe de verzamelde gegevens van de individuele nodes en het ad hoc netwerk gevisualiseerd kunnen worden zodat de karakteristieken van het ad hoc netwerk interpreteerbaar zijn. Er wordt gefocust op vijf ka-rakteristieken (structuur, in- en ouput, performance, CPU load en node status), aangezien deze worden gezien als de vooraanstaande karakteristieken van het ad hoc netwerk.

Om de karakteristieken van het ad hoc netwerk en de individuele nodes te meten en te visualiseren wordt er gebruik gemaakt van twee processen, het monitor node proces (MNP) en het monitor visualisatie proces (MVP). Het MNP is een gedistribueerd proces dat ge¨ımplementeerd is op elke node in het netwerk. Dit proces verzamelt de informatie van de nodes en verstuurd deze telkens na een interval naar het MVP. Het MVP verwerkt en visualiseert de gegevens die verzameld zijn door het MNP. Het MNP en het MVP commu-niceren door middel van een communicatie laag.

Tevens is er gekeken of de visualisatie van de karakteristieken interpreteerbaar zijn zodat er uitspraken gedaan kunnen worden over het gedrag. Dit is gedaan door middel van drie experimenten. Het resultaat hiervan is dat zowel de data flow binnen het netwerk als de werking van een gedistribueerd algoritme, dat wordt uitgevoerd binnen het ad hoc netwerk, afgeleid kunnen worden door middel van de visualisatie van de karakteristieken van het ad hoc netwerk.

Bovendien is onderzocht wat de invloed van een dergelijk monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk. Hiervoor is de overhead gemeten dat het monitor systeem veroorzaakt op de performance van de nodes en dus het gehele ad hoc netwerk. Dit is gemeten voor netwerken met verschillende aantallen nodes. Het resultaat hiervan is dat het monitor systeem voor een overhead zorgt tussen de 15.5 en 17.2 procent ongeacht het aantal nodes binnen het ad hoc netwerk.

Inhoudsopgave

3 Specificaties van de monitor 13 4 Implementatie 15 4.1 Communicatie protocols (TCP en UDP) . . . 15

4.2 Test platform . . . 16

4.2.1 Communicatie (test platform) . . . 17

4.2.2 Routing . . . 17

4.2.3 Netwerk discovery . . . 19

4.3 Monitor systeem . . . 19

4.3.1 Monitor node proces . . . 19

4.3.2 Communicatie (monitor systeem) . . . 21

4.3.3 Monitor visualisatie proces (MVP) . . . 22

4.3.4 Grafisch user interface(GUI) . . . 23

5 Experimenten 29 5.1 Visualisatie . . . 29

5.1.1 Experiment 1: Pakket-tracing(IO) . . . 29

5.1.2 Experiment 2: Performance en IO . . . 30

5.1.3 Experiment 3: Wave equation . . . 32

5.2 Invloed op de performance van het netwerk . . . 34

6 Future work 37 6.1 Invloed overige karakteristieken . . . 37

6.2 Invloed overige schaalbaarheidsfactoren . . . 37

7 Conclusie 39

HOOFDSTUK 1

Introductie

Draadloze netwerken worden steeds belangrijker. Tegenwoordig beschikken de meeste apparaten zoals laptops en mobiele telefoons over de technologie om draadloos te kunnen communiceren. Al deze apparaten zouden gebruikt kunnen worden als nodes binnen een (mobile) ad hoc netwerk.

Ad hoc netwerken zijn zelf organiserende netwerken en worden voor verschillende toepassin-gen gebruikt [5] [8]. Een ad hoc netwerk kan bijvoorbeeld worden gebruikt om gedistribueerde algoritmes uit te voeren. Ook kan het bijvoorbeeld worden gebruikt om gegevens te verzamelen (sensor ad hoc netwerken). Een ander voorbeeld is het verzamelen van gegevens van voertuigen om zo een infrastructuur beter in kaart te brengen (vehicular ad hoc netwerken) [1].

Een van de eigenschappen van een ad hoc netwerk is dat ze geen centrale sturing hebben en dat het netwerk constant kan veranderen [8]. Dit zou kunnen komen doordat nodes verplaatsen binnen het netwerk, of dat nodes zich toevoegen aan het netwerk of het netwerk verlaten. Bo-vendien hoeven nodes niet direct met elkaar verbonden te zijn om met elkaar te communiceren (zie figuur 1.1). Er kan dan door middel van (multi-) hopping data worden verstuurd tussen de nodes.

Het doel van deze scriptie is om te onderzoeken of de karakteristieken van een heterogeen ad hoc netwerk te visualiseren zijn door middel van een monitor systeem. Deze karakteristieken moeten zo worden weergegeven dat deze interpreteerbaar zijn, waardoor het gedrag van het ad hoc netwerk geanalyseerd kan worden.

Hiervoor moet worden onderzocht hoe de karakteristieken van het ad hoc netwerk en de individuele nodes gemeten kunnen worden. Tevens moet er worden onderzocht hoe de verzamelde gegevens van de individuele nodes en het ad hoc netwerk gevisualiseerd kunnen worden zodat deze interpreteerbaar zijn. Daarnaast moet worden onderzocht wat de invloed van een dergelijk monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk.

Een (heterogeen) ad hoc netwerk heeft verschillende karakteristieken die invloed hebben op hoe het netwerk zich gedraagt [8]. In deze scriptie wordt er gefocust op de volgende vijf karak-teristieken: structuur, in- en ouput, performance, CPU load en node status.

• De structuur van het netwerk heeft invloed op het gedrag van het ad hoc netwerk doordat bijvoorbeeld een ’fully connected network’ meestal het aantal hops wat nodig is om een pakket tussen twee nodes te versturen verlaagt. Terwijl in een ’sparsely connected network’ er meestal meer hops nodig zijn om een pakket tussen twee nodes te versturen. Dit heeft invloed op bijvoorbeeld de overdrachtssnelheid van pakketten binnen het netwerk.

• De in- en output van het ad hoc netwerk heeft invloed op het gedrag doordat als een verbinding wordt overbelast met in- en output, dit er voor kan zorgen dat pakketten er langer over doen om de bestemming te bereiken.

• De performance van de nodes hebben invloed op het gedrag doordat bijvoorbeeld bij het uitvoeren van bijvoorbeeld een gedistribueerd algoritme, waarin berekeningen worden ge-daan, de performance van de nodes een rol speelt. In het geval dat er een of meerdere nodes in het netwerk zitten die een lagere performance hebben dan de andere nodes, kan dit de performance van het volledige netwerk verminderen.

Figuur 1.1: Voorbeeld van de structuur van een ad hoc netwerk

• De CPU load van een node heeft invloed op het gedrag doordat als bijvoorbeeld een node wordt overbelast met taken, kan dat de performance van die node en dus het gehele ad hoc netwerk negatief be¨ınvloeden.

• De status van een node heeft invloed op het gedrag doordat als een node bijvoorbeeld uitvalt, kan deze geen taken meer uitvoeren en heeft dat invloed op het ad hoc netwerk.

HOOFDSTUK 2

Gerelateerd werk

Voor het monitoren van de karakteristieken van ad hoc netwerk bestaan al enkele monitor sys-temen. Voor het onderzoek worden vier bestaande monitor systemen namelijk ViTAN, INSpect, VIVAGr en ViSim met elkaar vergeleken.

2.1

ViTAN

ViTAN is een tool om connectiviteit en de verbindings kwaliteit te visualiseren tussen nodes in ad hoc netwerken [7]. ViTAN gebruikt de locatie (gespecificeerd door de Cartesiaanse co¨ordinaten) en de verbindings kwaliteit tussen de nodes als input. ViTAN meet niet zelf de connectiviteit en verbindings kwaliteit van het ad hoc netwerk, maar gebruikt de verzamelde gegevens van andere tools of simulaties. Om de gegevens uit te wisselen wordt een communicatie interface gebruikt. Dit zorgt er voor dat ViTAN gebruikt kan worden door een wijde selectie van applicaties. ViTAN is getest op een link-level simulatie voor IEEE802.11a van de University of Ferrara [7].

ViTAN maakt van de connectiviteit en verbindings kwaliteit van de nodes een netwerk graaf. Deze graaf kan gebruikt worden om het netwerk te analyseren. Door middel van de breedte van de lijn die getekend wordt voor de verbinding tussen twee nodes in de graaf, wordt er in de graaf aangegeven wat de kwaliteit van een verbinding is. Ook wordt er gebruik gemaakt van kleuren om het bereik van de nodes weer te geven. ViTAN is ook in staat om een energieconsumptie plot te maken.

Het doel van ViTAN is om op een simpele manier de netwerk graaf te visualiseren van het ad hoc netwerk, zodat de structuur van het netwerk geanalyseerd kan worden [7]. ViTAN geeft echter niets weer over de andere karakteristieken van het netwerk zoals IO en performance.

2.2

INSpect

INSpect maakt gebruik van de network simulator 2 (NS-2) [9]. NS-2 is een populaire en krachtige tool voor het simuleren van netwerken [6] [9]. Ondanks dat NS-2 origineel was bedoeld voor het simuleren van bedrade netwerken, is het uitgebreid zodat het ook ondersteuning biedt voor draadloze netwerken, inclusief mobile ad hoc networks (MANET).

INSpect is een tool om NS-2 simulaties van draadloze netwerken te visualiseren, door middel van de trace-files van de NS-2 simulatie. INSpect gebruikt de locaties van de nodes (gespecificeerd door de Cartesiaanse co¨ordinaten) om een netwerk graaf te maken. In deze netwerk graaf is ook de beweging te zien van de nodes gedurende de simulatie.

In de netwerk graaf wordt echter niet de links tussen de nodes weergegeven, aangezien de simulatie er vanuit gaat dat deze verbonden is met alle nodes die in range zijn. In plaats daar van geeft INSpect de overdracht van data weer binnen het netwerk. Dit wordt gedaan door een link te maken tussen nodes waar tussen data is verstuurd. Hierdoor geeft INSpect duidelijk weer wat de route is die een data pakket heeft afgelegd.

INSpect geeft voornamelijk de data overdracht weer binnen een ad hoc netwerk en kan hier-door goed gebruikt worden voor het analyseren van routing protocollen binnen ad hoc netwerken [9].

2.3

VIVAGr

In een vehicular ad hoc network(VANET) is er communicatie tussen voertuigen onderling en tus-sen voertuigen en infrastructuur. VANETs kunnen gebruik worden om informatie te verzamelen over infrastructuren en het gedrag van de voertuigen binnen deze infrastructuren. VIVAGr is een real time visualisatie tool voor vehicular ad hoc networks(VANET). VIVAGr kan gebruikt worden om antwoorden te kunnen geven op meerdere kernvragen over de vorm en het gedrag van VANETs [14].

VIVAGr is een grafisch geori¨enteerde tool die het mogelijk maakt om de karakteristieken van VANETs te analyseren. Dit wordt gedaan door het importeren van trace-files die worden gegenereerd door de nodes in het netwerk. Deze trace files bevatten informatie over de nodes en het netwerk op een gegeven moment. Daarnaast worden omgeving parameters zoals draadloos bereik, topologie, penetratie ratio, signaal verspreiding, mobiliteit modellen, ervaren interferentie en road-maps gebruikt. Van al deze gegevens wordt een real-time network graaf gemaakt die de mobiliteit patronen van de voertuigen laat zien binnen een omgeving. VIVAGr kan hierdoor visualiseren hoe topologie karakteristieken van VANETs veranderen over tijd bij verschillende mobiliteit patronen [14]. Deze visualisatie kan vervolgens gebruikt worden om het VANET te analyseren.

2.4

ViSim

ViSim is net als INSpect een tool om NS-2 simulaties van mobile ad hoc networks(MANET) te visualiseren door middel van de trace-files van de NS-2 simulatie [13] [6]. ViSim gebruikt de locatie en het bereik van de nodes om een netwerk graaf weer te geven. In de netwerk graaf wordt door middel van een cirkel aangegeven wat het bereik is van een node. Hierdoor kan er gezien worden welke nodes er binnen bereik zijn van elkaar en dus een connectie tussen gemaakt kan worden. ViSim geeft verder informatie weer over de throughput, goodput en routing load van de simulatie. Ook kan er een plot worden weergegeven van de throughput over tijd.

ViSim is bedoelt om routing protocols van ad hoc netwerken te simuleren en analyseren [13]. Ook biedt het de mogelijkheid om routing protocols onderling te vergelijken.

2.5

Vergelijking

In tabel 2.1 is een overzicht te zien van de vergelijking van de bovenstaande tools. Zoals te zien is focussen deze tools voornamelijk op de structuur van het netwerk. INSpect en ViSim maken beide gebruikt van NS-2 simulaties en bieden geen ondersteuning om werkelijke ad hoc netwerken te visualiseren. ViSim en INSpect zijn daarnaast ook voornamelijk gefocust om routing protocollen te analyseren en te vergelijken waardoor ook de in- en output van het netwerk wordt gemeten. VIVAGr is een tool die speciaal gemaakt is voor vehicular ad hoc netwerken en kan hierdoor niet ge¨ımplementeerd worden op bijvoorbeeld een MANET. ViTAN daarentegen biedt wel ondersteuning om data te gebruiken van werkelijke ad hoc netwerken, doordat deze niet zelf de metingen doet, maar de informatie over de nodes van andere tools kan ontvangen via een communicatie interface. Deze tool geeft echter alleen een visualisatie weer van de structuur van het netwerk. Verder geeft geen van deze tools informatie over de performance, CPU load en status van de nodes. Geen van de bovengenoemde tools visualiseert zowel de structuur, in- en output, performance en CPU load.

Tabel 2.1: Vergelijking tools

Netwerk type Structuur In- en output Performance CPU load ViTAN

Simulatie en Ad Hoc (MANET, VANET en sensor netwerk)

Ja Nee Nee Nee

INSpect Simulatie Ja Ja Nee Nee

VIVAGr VANET Ja Nee Nee Nee

HOOFDSTUK 3

Specificaties van de monitor

Zoals aangegeven wordt er in deze scriptie gefocust op de structuur, in- en output, performance, CPU load en node status van het het ad hoc netwerk. Om deze karakteristieken te kunnen visualiseren moet er eerst informatie over deze karakteristieken worden verzameld. Deze gegevens kunnen worden verzameld door metingen te doen op de nodes binnen het netwerk. Deze metingen kunnen worden gedaan door middel van een proces. Vervolgens moeten de gemeten gegevens worden samengebracht zodat deze verwerkt en gevisualiseerd kunnen worden tot een visualisatie van het gehele netwerk. Dit betekent dat de nodes de gemeten gegevens moeten versturen naar een proces die de verwerking en visualisatie doet.

Om bovenstaande goed te kunnen ondersteunen is gekozen om een modulair monitor systeem te implementeren. Dit monitor systeem bestaat uit twee delen, een monitor node proces(MNP) en een monitor visualisatie proces(MVP). Om de communicatie tussen deze twee soorten processen mogelijk te maken, is een aparte communicatie laag nodig. Deze communicatie laag staat los van de communicatie laag van het ad hoc netwerk en zal alleen worden gebruikt om te communiceren tussen de monitor processen. Het is hierdoor noodzakelijk dat elke node in het bereik is van het monitor visualisatie proces, zodat het monitor node proces van de node kan communiceren met het monitor visualisatie proces.

Het monitor node proces is een gedistribueerd proces dat op elke node binnen het netwerk ge¨ımplementeerd moet worden. Dit proces verzameld de gegevens over de structuur, in- en output, performance, CPU load, status en taak van de node. Een taak binnen het ad hoc netwerk is een taak die door het gehele netwerk wordt uitgevoerd, iedere node voert vervolgens een deel van deze taak uit. Een taak kan bijvoorbeeld een gedistribueerd algoritme zijn. De gegevens worden gemeten en vervolgens verstuurt naar het monitor visualisatie proces op een interval (zie sectie 4.3.1). In bijlage A is de lijst met gegevens te zien die door het monitor node proces gemeten worden.

Het monitor visualisatie proces ontvangt de informatie van de monitor node processen en verwerkt deze. Bij het verwerken worden alle metingen van de nodes samengevoegd zodat er een compleet overzicht ontstaat over de structuur, in- en output, performance, CPU load en status van het netwerk. Vervolgens wordt hiervan een visualisatie. Op deze visualisatie moet een graaf zichtbaar zijn waarin de structuur en data flow van het netwerk en de statussen van de nodes zichtbaar is. Daarnaast moeten er een grafiek over tijd van de performance en een grafiek over tijd van de in- en output van de nodes zichtbaar zijn. Ook moet er informatie worden weergegeven over de taak van het ad hoc netwerk.

HOOFDSTUK 4

Implementatie

Voor de ontwikkeling van het monitor systeem is een test platform nodig. Dit test platform zal gebruikt worden om het monitor systeem op te ontwikkelen en om experimenten op de monitor uit te voeren. Het test platform is een ad hoc netwerk dat beschikt over een communicatie, routing en netwerk discovery protocol. Om experimenten op de monitor uit te kunnen voeren moet het ook mogelijk zijn om gedistribueerde algoritmes op het test platform te implementeren. Het test platform bestaat dus feitelijk uit een combinatie van hardware en software.

Het monitor systeem en het test platform hebben allebei een communicatie laag nodig. Dit zijn twee verschillende communicatie lagen en staan los van elkaar (zie figuur 4.1). De communi-catie laag van het test platform wordt namelijk gebruikt om te communiceren tussen de processen van een gedistribueerde taak. Terwijl de communicatie laag van het monitor systeem gebruikt wordt om te communiceren tussen de monitor node processen en het monitor visualisatie proces.

4.1

Communicatie protocols (TCP en UDP)

Het test platform en het monitor systeem hebben beide een communicatie laag. Beide com-municatie lagen hebben comcom-municatie protocollen nodig, om pakketten te versturen over de communicatie lagen. Voor de communicatie protocollen van de communicatie lagen kan het TCP of het UDP protocol worden gebruikt [11] [12].

Het TCP protocol zorgt voor error vrije data overdracht[11]. Dit houd in dat er wordt gezorgd dat alle pakketten volledig aankomen bij de ontvanger. Voor ieder pakket dat wordt ontvangen door de client of server wordt een acknowledgement (ACK) pakket teruggestuurd om te bevestigen dat het pakket is ontvangen. Als na het sturen van een pakket geen ACK pakket wordt ontvangen, weet de verzender dat het pakket niet of beschadigt is aangekomen en dus opnieuw gestuurd moet worden.

Bij het maken van een TCP verbinding tussen de client en server, moet als eerste een ver-binding worden ge¨ınitialiseerd. Dit wordt gedaan door vanaf de client een SYN pakket te sturen naar de server. Vervolgens stuurt de server een SYN-ACK pakket terug naar de client. Als laatste bevestigt de client dit pakket te hebben ontvangen door nog een ACK pakket terug te sturen naar de server. Het SYN pakket zorgt ervoor dat de ’sequence’ (SEQ) nummers worden gesynchroniseerd tussen de client en de server. Het SEQ nummer is een identificatie nummer van het pakket, voor ieder pakket dat wordt verstuurd wordt het SEQ nummer met ´e´en verhoogt. Het SEQ nummer is nodig om in het ACK pakket aan te geven welk pakket is ontvangen en om een beschadigt of verloren pakket opnieuw op te kunnen vragen. Na het initialiseren van de verbinding kunnen de data pakketten worden verstuurd. Voor ieder data pakket dat wordt ont-vangen, wordt ook de ’checksum’ van het pakket gecontroleerd. Als hier een fout in zit wordt het data pakket opnieuw opgevraagd. Als alle data is verstuurd wordt de TCP verbinding verbroken tussen de client en server. Dit wordt gedaan door een FIN pakket te sturen.

Bij een UDP verbinding hoeft er niet eerst een connectie te worden ge¨ınitialiseerd tussen de client en de server. In plaats daarvan stuurt de client direct het data pakket naar de server.

Figuur 4.1: Ad hoc netwerk met monitor systeem. De zwarte hele pijlen tussen de nodes zijn de communicatie tussen de nodes onderling (Bluetooth). De oranje gestippelde pijlen zijn de communicatie tussen de monitor node processen en het monitor visualisatie proces (WiFi).

Er wordt niet gecontroleerd of het verstuurde data pakket is aangekomen bij de server. Als een data pakket is aangekomen bij de server wordt de ’checksum’ van het pakket gecontroleerd. Het pakket wordt echter niet opnieuw aangevraagd als hier een fout in zit.

Het voordeel van een TCP verbinding is dat er garantie wordt gegeven dat alle pakketten (in de juiste volgorde) aankomen bij de server. Het nadeel is echter dat het initialiseren van de verbinding en het opnieuw sturen van verdwenen of beschadigde pakketten voor overhead zorgt. Bij een UDP verbinding wordt deze garantie niet gegeven, pakketten kunnen in een andere volgorde of zelfs helemaal niet aan komen. Daar in tegen hoeft er bij een UDP verbinding niet eerst een connectie te worden ge¨ınitialiseerd of pakketten opnieuw te worden verstuurd. Dit zorgt er voor dat een UDP verbinding sneller is dan een TCP verbinding.

In sectie 4.2.1 wordt beschreven welk communicatie protocol gebruikt wordt voor de commu-nicatie tussen de nodes in het test platform. In sectie 4.3.2 wordt beschreven welk commucommu-nicatie protocol gebruikt wordt om te communiceren tussen het monitor node proces en het monitor visualisatie proces van het monitor systeem.

4.2

Test platform

Om het monitor systeem te ontwikkelen is een test platform nodig. Dit test platform moet gebruikt kunnen worden om experimenten uit te voeren op het ad hoc netwerk. Het test platform is een ad hoc netwerk waar gedistribueerde algoritmes op uitgevoerd kunnen worden. Door deze gedistribueerde algoritmes uit te voeren kan er worden onderzocht of de karakteristieken van het netwerk interpreteerbaar zijn op de grafisch user interface van de monitor.

Om een gedistribueerd algoritme uit te kunnen voeren op een ad hoc netwerk moet het netwerk beschikken over een communicatie laag en een routing protocol, zodat er gecommuniceerd kan worden tussen de nodes in het netwerk. Ook moeten de nodes weten hoeveel nodes er in het netwerk zitten en wat hiervan de adressen zijn. Hiervoor wordt een netwerk discovery protocol gebruikt.

Figuur 4.2: DSR: een route-request pakket wordt vanaf A verstuurd om de route naar F op te vragen

4.2.1

Communicatie (test platform)

Zoals aangegeven is er een communicatie laag nodig om te communiceren tussen de nodes on-derling. Voor het test platform wordt gebruik gemaakt van Android devices, deze beschikken (vrijwel) allemaal over WiFi en Bluetooth. De ondersteuning binnen het Android platform voor meerdere concurrent connecties is uitgebreider voor Bluetooth dan voor WiFi. Om deze reden is dan ook Bluetooth gekozen als communicatie laag voor het ad hoc netwerk omdat concurrent connecties een essentieel onderdeel zijn voor een ad hoc netwerk.

Om pakketten te versturen tussen de nodes over de communicatie laag is een communicatie protocol nodig. Hierbij is het belangrijk dat alle pakketten aankomen bij de ontvanger. Voor het communicatie protocol kan TCP of UDP worden gebruikt. Zoals aangegeven in sectie 4.1 zorgt het TCP protocol voor een error vrije data overdracht. Het UDP protocol biedt niet deze garantie. Hierom wordt voor de communicatie tussen de nodes het TCP protocol gebruikt.

4.2.2

Routing

Om data te kunnen versturen tussen nodes binnen het ad hoc netwerk is het soms nodig om deze data via een of meerdere hops naar de bestemming te sturen. Dit komt dan omdat de node niet direct verbonden is met de node waarnaar het pakket verstuurd moet worden. Om het pakket via (multi-) hopping naar de bestemming te sturen moet er een route worden bepaald waarover het pakket wordt gestuurd. Om deze route te bepalen is er een routing algoritme nodig. Een routing algoritme bepaald de route die een pakket neemt.

In het test ad hoc netwerk wordt er gebruik gemaakt van het direct source routing(DSR) algoritme [2]. Dit algoritme stuurt eerst door middel van een broadcast een route-request pakket naar de nodes. Bij een broadcast stuurt een node het pakket naar alle nodes waarmee deze verbonden is, vervolgens sturen deze nodes het pakket ook door naar alle nodes waarmee ze verbonden zijn. Als een node het pakket voor de tweede keer ontvangt, dan verstuurd deze het pakket niet nog een keer. In de pakketten wordt bijgehouden welke route ze hebben afgelegd. In figuur 4.2, is te zien hoe node ’A’ een route-request stuurt naar node ’F’ door middel van een broadcast. Als node ’F’ het pakket heeft ontvangen, stuurt deze via dezelfde route die het pakket heeft afgelegd, een reply-pakket terug naar node ’A’ (zie figuur 4.3). Als node ’A’, het reply-pakket binnen krijgt, slaat deze de route die het pakket heeft genomen op. Vervolgens als node ’A’ een data pakket wilt versturen naar node ’F’, voegt deze de route toe aan het data pakket(zie figuur 4.4). Als een data pakket wordt verstuurd naar een node, maar de route die is meegegeven niet meer klopt, wordt er een error-pakket teruggestuurd naar de node. Vervolgens stuurt de node dan opnieuw een route-request pakket om de nieuwe route te verkrijgen.

Figuur 4.3: DSR: een reply-pakket wordt vanaf F naar A verstuurd via de route die het route-request pakket heeft afgelegd

Figuur 4.4: DSR: een data pakket wordt vanaf A naar F verstuurd via de route die A heeft opgeslagen

4.2.3

Netwerk discovery

Een node binnen het ad hoc netwerk weet standaard alleen met welke nodes die direct verbonden is. De node weet niet hoeveel nodes er totaal in het netwerk zitten en wat de adressen zijn van deze nodes. Om deze informatie beschikbaar te maken voor de nodes wordt het neighbourhood discovery protocol (NHDP) gebruikt. Het neighbourhood discovery protocol zorgt er voor dat nodes weten welke nodes er nog meer in het netwerk zitten [4].

Iedere node in het netwerk stuurt een periodiek HELLO-pakket naar alle nodes waarmee deze direct is verbonden. Dit pakket bevat alle nodes waarvan de node het bestaan af weet. Als een node een HELLO-pakket ontvangt, voegt de node de nog niet bekende nodes toe aan de lijst van bestaande nodes.

4.3

Monitor systeem

De monitor bestaat uit twee delen, een monitor node proces en een monitor visualisatie proces (zie figuur 4.1). Het monitor node proces is een gedistribueerd proces wat wordt ge¨ımplementeerd op elke node in het netwerk. Dit proces is verantwoordelijk voor het verzamelen en meten van de gegevens van de nodes. Omdat het monitor node proces op elke node in het netwerk ge¨ımplementeerd moet worden, zou het kunnen dat deze moet worden aangepast, zodat deze compatibel is met het besturingssysteem van de node.

Het monitor visualisatie proces verwerkt en visualiseert de gegevens die verzameld zijn door de monitor node processen. Het monitor visualisatie proces heeft drie taken, het ontvangen van de node informatie pakketten, het verwerken van de node informatie pakketten naar een netwerk informatie object en het visualiseren van het netwerk informatie object op een grafisch user interface.

Het monitor node proces en het monitor visualisatie proces communiceren onderling via een communicatie laag. Deze communicatie laag wordt gebruikt om data te versturen tussen de processen. Dit is een andere communicatie laag dan de communicatie laag van het test platform. Zoals eerder aangegeven is het noodzakelijk dat alle monitor node processen direct verbonden zijn met het monitor visualisatie proces. Dit zorgt er voor dat het bereik van de communicatie laag de maximale afstand bepaald tussen een node en het monitor visualisatie proces. Hierom is er gekozen om voor de communicatie laag van het monitor systeem WiFi te gebruiken. Wifi wordt net als Bluetooth door de (meeste) Android telefoons ondersteund, daarnaast heeft WiFi een groter bereik dan Bluetooth.

4.3.1

Monitor node proces

Bij het uitvoeren van een meting verzamelt het monitor node proces de gegevens van de node en voegt deze toe aan een node informatie pakket. De gegevens over de verbindingen, de status, het proces en de taak kunnen verkregen worden door deze op te vragen aan de node. De gegevens over de performance, CPU load en in- en output op het tijdstip van de meting moet worden berekend door het monitor node proces.

Het aantal bytes wat een node heeft verstuurd kan worden berekend door het totaal aantal verstuurde bytes op twee tijdstippen te meten. Het verschil tussen het aantal verstuurde bytes tussen deze twee tijdstippen is het aantal bytes wat over deze periode is gestuurd. Door dit aantal te delen door het verschil in secondes tussen de twee metingen kan het aantal bytes dat is verstuurd per seconden worden berekend. Hetzelfde kan worden gedaan voor het aantal ontvangen bytes. Door het aantal ontvangen en verstuurde bytes per seconden bij elkaar op te tellen kan het totaal aantal bytes per seconden worden berekend die door de in- en output van een node is verwerkt.

Om de data flow weer te kunnen geven binnen het netwerk moet er voor iedere verbinding tussen de nodes worden bijgehouden hoeveel data er verstuurd is. Hierbij is het belangrijk dat ook de richting van verstuurde data wordt bijgehouden. Het is tevens mogelijk dat er beide richtingen tegelijk data wordt verstuurd, hierdoor is het noodzakelijk om voor beide richtingen apart bij te houden hoeveel data er is verstuurd.

Figuur 4.5: Performance grafiek van het aantal duizend ’clock cycles’per seconden wat de CPU is bezig geweest met het uitvoeren van de applicatie.

Figuur 4.6: Performance grafiek van een node gemeten door middel van de relatieve performance meet methode.

De performance van de node kan op twee manieren worden berekend. De eerste methode is door te berekenen hoeveel ’clock cycles’ per seconden de CPU van een node heeft besteed aan het uitvoeren van de applicatie in een bepaalde tijdsperiode. Het nadeel hiervan is dat niet alleen het aantal ’clock cycles’ wordt meegerekend dat de CPU bezig was met het algoritme, maar ook het aantal ’clock cycles’ wat de CPU bezig was met het versturen en ontvangen van data en het in stand houden van het ad hoc netwerk. Dit zorgt ervoor dat er ruis ontstaat in de performance meting. De performance grafiek die ontstaat door deze methode is te zien in figuur 4.5, hierin is het aantal duizend ’clock cycles’ per seconden weergegeven.

De tweede manier is het berekenen van de relatieve performance van het algoritme dat wordt uitgevoerd op een nodes. Deze performance wordt gemeten door bij te houden hoe vaak een bepaalde operatie van een algoritme wordt uitgevoerd. Een voordeel hiervan is dat er geen ruis ontstaat door de in- en output en het in standhouden van het netwerk, maar alleen de performance van de node t.a.v. het algoritme wordt weergegeven. De performance grafiek die ontstaat door deze methode is te zien in figuur 4.6. Het nadeel is dat deze methode niet op alle algoritmes kan worden ge¨ımplementeerd, maar alleen op algoritmes die een herhalende operatie hebben.

Zoals te zien is zijn de grafieken van de twee methodes ongeveer hetzelfde. Op het tijdstip 22:06:50 wordt bij de tweede methode de performance 0, omdat de node bezig is met in- en output. Bij de eerste methode wordt op het tijdstip 22:06:50 de performance niet 0, aangezien deze methode ook het aantal ’clock cycles’ per seconden laat zien die de CPU bezig is met in-en output.

Om de CPU load te berekenen van de node wordt er net als de eerste methode van het meten van de performance gekeken naar het aantal ’clock cycles’ wat de CPU bezig is met het uitvoeren

Net als de in- en output worden de performance en CPU load gemeten over een interval. De formule die hiervoor wordt gebruikt is formule 4.1. De variabelen t1 en t2 zijn de tijdstippen in secondes van de metingen, waardet1 en waardet2 zijn de waardes op de tijdstippen. Eerst

wordt het verschil in waarde berekent tussen de tijdstippen. Vervolgens wordt dit gedeeld door het verschil in tijd.

waarde∆

∆t =

waardet2− waardet1

t2 − t1 (4.1)

Als alle gegevens gemeten zijn door het monitor node proces en deze zijn toegevoegd aan een node informatie pakket, wordt er een time-stamp toegevoegd aan het node informatie pakket. De time-stamp geeft het tijdstip aan wanneer de meting gedaan is. Vervolgens wordt het node informatie pakket over de communicatie laag naar het monitor visualisatie pakket gestuurd. De metingen worden periodiek gedaan door het monitor node proces.

De grote van het interval van de metingen heeft invloed op de precisie van de grafieken en de overhead op de nodes. De overhead op de node en het monitor systeem wordt groter bij een kleiner interval doordat er meer metingen per seconden worden gedaan en verstuurd worden. Hierdoor geldt hoe kleiner het interval, hoe gedetailleerder de grafieken en hoe hoger de overhead op de node en het monitor systeem. Ook is de interval grootte afhankelijk van de taak die ge¨ımplementeerd is. Dit komt doordat het per taak kan verschillen wat de precisie van de metingen moeten zijn om een uitspraak te kunnen doen over de visualisatie van het ad hoc netwerk en de daarop ge¨ımplementeerde taak. Bij het kiezen van een interval grootte moet er dus een afweging worden gemaakt tussen precisie en performance, dit kan het beste worden gedaan door ’trial-and-error’. Voor de interval grootte die wordt gebruikt voor experimenten is gekeken naar intervallen met een grootte van 100, 200, 500 en 1000 milliseconden. De interval grootte van 500 milliseconden gaf de beste visualisatie van de geteste intervallen en is daarom ook gebruikt voor de experimenten.

4.3.2

Communicatie (monitor systeem)

Omdat het belangrijker is dat node informatie pakketten zo snel mogelijk aankomen bij het monitor visualisatie proces, dan dat alle node informatie pakketten aankomen, wordt het UDP protocol gebruikt om de node informatie te versturen. Doordat het sturen van node informatie pakketten door het UDP protocol sneller is dan het TCP protocol, kunnen de node informatie pakketten ook op een kleiner interval worden gestuurd.

Bij het maken van de node informatie pakketten wordt een time-stamp toegevoegd die de tijd aangeeft wanneer de meting is gedaan. Deze time-stamp is nodig voor het monitor visualisatie proces om de node informatie op het juiste tijdstip te visualiseren (zie sectie 4.3.3). Het probleem is echter dat de tijd van het monitor visualisatie proces en die van de nodes niet synchroon loopt. Dit kan een paar milliseconden zijn, maar kan ook enkele seconden tot minuten zijn. Hierdoor kan het monitor visualisatie proces de metingen van de nodes op een bepaald tijdstip niet combineren tot een netwerk informatie object van een bepaald tijdstip, doordat de time-stamps van de metingen van elkaar verschillen.

Er moet dus voor worden gezorgd dat de tijd van het monitor visualisatie proces en die van de nodes synchroon lopen. Hiervoor kan het Precision Time Protocol (PTP) [10] gebruikt worden. Het Precision Time Protocol is een protocol om de tijd tussen twee nodes/apparaten te synchroniseren. Zoals te zien is in figuur 4.7, stuurt apparaat ’A’ een pakket met daarin de tijd dat dit pakket is verstuurd, dit is T1. Apparaat ’B’ ontvangt vervolgens dit pakket en onthoud

de tijd waarop deze het pakket heeft ontvangen, dit is T10. Vervolgens stuurt apparaat ’B’ naar

apparaat ’A’ een pakket met daarin T1en T10, en voegt hieraan de tijd toe dat dit pakket wordt

verstuurd, dit is T2. Vervolgens ontvangt apparaat ’A’ dit pakket en slaat de tijd dat dit pakket

was ontvangen op, dit is T₂0. Nu kan apparaat ’A’ de tijd offset berekenen wat apparaat ’A’ en ’B’ van elkaar verschillen met de formule uit 4.2.

of f set = T

0

1− T1− T20+ T2

2 (4.2)

Doordat het bij het Precision Time Protocol belangrijk is dat alle pakketten aankomen, wordt hiervoor een nieuw kanaal (naast het UDP kanaal voor de node informatie pakketten) geopend

Figuur 4.7: Precision Time Protocol(PTP): Synchronisatie mechanisme

tussen de node en het monitor visualisatie proces. Dit kanaal gebruikt het TCP protocol, zodat er wordt gecontroleerd of alle pakketten aankomen. Dit kanaal wordt vervolgens weer gesloten als de synchronisatie voltooid is, omdat de synchronisatie maar een keer per node gedaan hoeft te worden.

4.3.3

Monitor visualisatie proces (MVP)

Het Monitor visualisatie proces (MVP) is verantwoordelijk voor het ontvangen van de node in-formatie pakketten van de monitor node processen(MNP) en deze te verwerken zodat er een overzicht kan worden gemaakt van het volledige netwerk (netwerk informatie object). Het mo-nitor visualisatie proces moet twee server sockets hebben, een UDP (voor de node informatie pakketten) en TCP (voor de tijd synchronisatie). Ook moet het monitor visualisatie proces buf-fers kunnen aanmaken voor het bufferen van de node informatie pakketten. Verder moet er een http web server aanwezig zijn om het grafisch user interface te kunnen weergeven (zie sectie 4.3.4). Python biedt ondersteuning voor al deze eisen. Ook is python besturingssysteem onafhankelijk, waardoor het monitor visualisatie proces op verschillende besturingssystemen ge¨ımplementeerd kan worden. Verder is python een veel gebruikte programmeer taal onder onderzoekers. Het monitor visualisatie proces is dan ook geschreven in python.

De UDP server socket krijgt de node informatie pakketten binnen van de nodes. Het monitor visualisatie proces maakt een buffer aan voor iedere node waarvan deze een node informatie pakket binnen krijgt en voegt het pakket toe aan deze buffer. Als er al een buffer bestaat voor de node, wordt er geen nieuwe buffer aangemaakt, maar wordt alleen het pakket aan de bestaande buffer toegevoegd. De buffers hebben een maximale grootte. Als dit maximum is bereikt wordt het oudste pakket uit de buffer verwijderd, zodat er plaats is voor een nieuw pakket. De node informatie pakketten worden op volgorde in de buffer geplaatst, dit wordt gedaan door te kijken naar de time-stamp (tijd waarop de meting is gedaan) van het pakket.

Vervolgens verwerkt het monitor visualisatie proces al deze losse node informatie pakketten tot een informatie object van het hele netwerk. Dit netwerk informatie object bevat alle infor-matie van het netwerk op een bepaald tijdstip en wordt gebruikt om de karakteristieken van het netwerk te visualiseren. Het netwerk informatie object van een bepaald tijdstip wordt gemaakt door voor iedere node het informatie pakket dat gemeten is op het tijdstip uit de buffer te halen

er echter niet voor dat de metingen van de monitor node processen synchroon lopen. Hierdoor worden de metingen niet op (precies) hetzelfde tijdstip gedaan. Er moet dus voor een tijdstip worden bepaald welk node informatie pakket van iedere node bij het tijdstip hoort, ondanks dat de metingen niet op precies hetzelfde tijdstip gedaan zijn.

Om dit probleem op te lossen wordt er gebruik gemaakt van een timeslot. Een timeslot heeft een bepaalde grootte, deze grootte geeft de tijdsperiode aan waarin er in de buffer van de node moet worden gezocht naar pakketten. Zoals te zien is in figuur 4.8 wordt er een tijdstip (T1) gekozen waarvan het netwerk informatie object moet worden berekend. Vervolgens worden alle pakketten gepakt die tussen de periode zitten van het tijdstip en het tijdstip min de timeslot grootte (tijdslot van T1). Als er een of meer pakketten zijn gevonden die in deze periode vallen, wordt het meest recente pakket gepakt (pakket op tijd T1). Als er geen pakketten zijn gevonden betekent het dat er voor dat tijdstip geen informatie pakket is van de node.

Figuur 4.8: Het pakket op T1 wordt gezocht in de buffer door middel van een tijdslot. Doordat de node informatie pakketten worden opgeslagen in de buffers van de nodes, is het ook mogelijk om een netwerk informatie object van een eerder tijdstip te berekenen door middel van de timeslots in plaats van alleen die van het huidige tijdstip. Dit kan worden gedaan zoals te zien is in figuur 4.9. Dit biedt de mogelijkheid om niet alleen de real-time node informatie te visualiseren, maar ook die van bijvoorbeeld twintig seconde terug. Hierdoor kan er een terug-spoel functie worden toegevoegd aan het monitor systeem waardoor er meerdere keren een stuk van de virtualisatie kan worden weergegeven (zie sectie 4.3.4 voor meer informatie).

Figuur 4.9: Het pakket op T2 wordt gezocht in de buffer door middel van een tijdslot.

4.3.4

Grafisch user interface(GUI)

Nadat de data verwerkt is door het monitor visualisatie proces tot een netwerk informatie object, kunnen de karakteristieken van het netwerk worden gevisualiseerd. Om dit grafisch weer te geven

Figuur 4.10: Overzicht van de grafisch user interface van de monitor

wordt een interactief grafisch user interface (GUI) ge¨ımplementeerd. Een optie is om de GUI te implementeren in het monitor visualisatie proces, door een van de GUI libaries van python te gebruiken. Echter het nadeel hiervan is dat als er een fout optreedt in de grafisch user interface, dit er voor kan zorgen dat ook de rest van het monitor visualisatie proces niet meer functioneert. Een ander nadeel is dat de GUI dan alleen zichtbaar is op het apparaat waarop het monitor visualisatie proces ge¨ımplementeerd is.

Een andere optie is om de GUI als web applicatie te implementeren. Hierdoor is het mogelijk om de GUI weer te geven in een web browser. Dit kan worden gedaan door in het monitor visualisatie proces een web service te hosten die het mogelijk maakt om vanuit een web browser de user interface te openen. Vervolgens wordt de netwerk informatie op een interval door de GUI opgevraagd aan het monitor visualisatie proces via de web service. Het voordeel hiervan is dat als er een fout optreedt bij de GUI, het monitor visualisatie proces gewoon blijft werken. Ook kan er hierdoor vanaf andere apparaten worden gekeken naar het GUI, in plaats van alleen vanaf het apparaat waarop het monitor visualisatie proces is ge¨ımplementeerd. Het nadeel is dat doordat de netwerk informatie verstuurd moet worden naar de GUI, hierdoor een vertraging kan ontstaan.

Omdat het gebruik van een GUI door middel van een webserver het mogelijk maakt om op andere apparaten de GUI te bekijken en bij een fout in de GUI het monitor visualisatie proces blijft werken, is er voor gekozen om een GUI te maken door middel van een web service.

Op de GUI moeten de karakteristieken van het netwerk gevisualiseerd worden zo dat deze interpreteerbaar zijn. Door middel van de visualisatie moeten er uitspraken gedaan kunnen worden over het gedrag van het netwerk. De GUI is te zien in figuur 4.10.

Op de GUI wordt de structuur van het netwerk gevisualiseerd. Alle nodes en de verbindingen tussen de nodes zijn hierop zichtbaar 4.11. De kleur van de node geeft de status aan van de node. De verschillende statussen van de nodes en de bijbehorende kleur en uitleg zijn te zien in tabel 4.1.

Doordat er per verbinding wordt bijgehouden hoeveel data er is verstuurd en ontvangen, kan ook de data ’flow’ binnen het netwerk visueel worden weergegeven. De kleur van de verbindingen tussen de nodes kunnen oranje of groen zijn. Als de verbinding oranje is betekent het dat er geen data wordt verstuurd over de verbinding. Als de kleur groen is betekent het dat er data wordt verstuurd over de verbinding. Als er over een verbinding data wordt verstuurd, wordt er door middel van een pijltje aangegeven welke node er data verstuurd. Het kan ook voorkomen dat beide nodes tegelijk data versturen over een verbinding. In figuur 4.12 is zichtbaar hoe er op de verbinding wordt aangegeven of er data wordt verstuurd en welke node de data verstuurd.

Figuur 4.11: Weergaven van de structuur van het netwerk op het grafisch user interface

Status Kleur Beschrijving

Idle Oranje De node is niet actief

Starting Licht groen De node is aan het voorbereiden om te beginnen met processen Processing Groen De node is aan het processen

Waiting Rood De node is aan het wachten op een andere node Unknown Blauw De status van de node is niet bekend

Tabel 4.1: Statussen van de nodes met de bijbehorende kleur en beschrijving

Figuur 4.12: In voorbeeld A wordt er geen data verstuurd tussen de nodes. In voorbeeld B stuurt C0:EE:FB:35:07:1E data naar 00:90:A2:9B:17:9B. in voorbeeld C stuurt 00:90:A2:9B:17:9B data naar C0:EE:FB:35:07:1E. In voorbeeld D sturen 00:90:A2:9B:17:9B en C0:EE:FB:35:07:1E tege-lijk data naar elkaar.

grafiek laat zien hoeveel bytes er totaal is verstuurd en ontvangen per seconden door iedere node in het netwerk. De grafiek is te zien in figuur 4.13, in deze grafiek is het aantal verstuurde en ontvangen bytes per seconden bij elkaar opgeteld. Door een node te selecteren wordt alleen de in-en output van de geselecteerde node getoond. Ook wordt dan apart het aantal verstuurde in-en ont-vangen bytes per seconden van de node weergegeven, in plaats van het totaal. De gedetailleerde grafiek van een node is te zien in figuur 4.14.

Naast de in- en output grafiek is er ook een performance grafiek. Deze laat de performance van de nodes zien. De performance grafiek is te zien in figuur 4.15. Net als bij de in- en output grafiek kan een node geselecteerd worden om te zorgen dat alleen de performance van de geselecteerde node wordt weergegeven (zie figuur 4.16). Door op de toggle (links boven) te klikken kan er worden gewisseld tussen de CPU performance en de CPU load. Op de CPU load grafiek is te zien voor hoeveel procent de applicatie gebruikt van de CPU van de node. De grafiek van de CPU load van een node is te zien in figuur 4.17.

Figuur 4.13: In- en output grafiek van de nodes. Deze grafiek laat het totaal aantal bytes (verstuurd plus ontvangen) per seconden zien van de nodes.

Figuur 4.14: In- en output grafiek van een node. In deze grafiek wordt het aantal verstuurde en ontvangen bytes per seconden los weergegeven.

Op de linkerkant van het scherm wordt de taak informatie van het netwerk weergegeven. Als er een node geselecteerd wordt, veranderd deze informatie in de node informatie van de geselecteerde node. Hierop is de proces informatie te zien. Ook is hier te zien of en op welke nodes de node aan het wachten is.

Boven aan de GUI is een ’slider’ te zien, deze staat standaard op de waarde 0. De ’slider’ geeft aan met hoeveel seconde vertraging de netwerk informatie wordt gevisualiseerd. Als de ’slider’ op 0 staat wordt de real-time netwerk informatie gevisualiseerd. Door de ’slider’ te verplaatsen naar bijvoorbeeld de waarde 10, wordt de netwerk informatie met een vertraging van 10 seconde gevisualiseerd. Dit geeft de mogelijkheid om de visualisatie van het netwerk terug te spoelen.

Figuur 4.15: Performance grafiek van de nodes. De performance is gemeten door middel van de relatieve performance meet methode.

Figuur 4.16: Performance grafiek van een geselecteerde node. De performance is gemeten door middel van de relatieve performance meet methode.

HOOFDSTUK 5

Experimenten

De karakteristieken van het ad hoc netwerk moeten zo worden weergegeven op de monitor, zodat deze ge¨ınterpreteerd kunnen worden en er uitspraken gedaan kunnen worden over het gedrag van het netwerk. Om te onderzoeken of het monitor systeem aan deze eis voldoet worden er verschillende experimenten uitgevoerd. De experimenten onderzoeken de visualisatie van de karakteristieken van het netwerk.

Voor het meten van de karakteristieken van het netwerk wordt een monitor node proces gebruikt op iedere node. Dit proces zal voor extra overhead zorgen op de nodes. Er wordt hierom onderzocht wat de invloed van het monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk. Dit wordt gedaan voor ad hoc netwerken met verschillende aantallen nodes. Ook wordt er gekeken of het monitor systeem schaalbaar is voor grotere aantallen nodes.

5.1

Visualisatie

Er worden verschillende experimenten uitgevoerd om te onderzoeken of de visualisatie van het netwerk de karakteristieken zo weergeeft zodat deze interpreteerbaar zijn en er uitspraken ge-daan kunnen worden over het gedrag van het netwerk. Voor de experimenten wordt er gebruik gemaakt van gedistribueerde (benchmark) algoritmes. De visualisatie van de karakteristieken van het netwerk wordt vergeleken met de werking van het algoritme. Ook wordt er gekeken of de visualisatie van het netwerk overeen komt met de verwachte visualisatie.

5.1.1

Experiment 1: Pakket-tracing(IO)

Het Pakket-tracing experiment onderzoekt of de route van een pakket dat verstuurd wordt van een node naar een andere node gevolgd kan worden door middel van de visualisatie. Het kun-nen zien van de route die een pakket aflegt kan worden gebruikt voor het onderzoeken van de werking en het gedrag van een routing algoritme. Dit kan bijvoorbeeld worden gebruikt bij het implementeren of ontwikkelen van een routing algoritme op het ad hoc netwerk.

Om dit te onderzoeken wordt vanaf een node naar een andere node een data pakket verstuurd. In figuur 5.1 is de structuur te zien van het ad hoc netwerk tijdens het experiment. Er wordt vanaf node ’A’ een pakket gestuurd naar node ’F’. Het pakket moet door middel van hopping worden verstuurd doordat node ’A’ en node ’F’ niet direct met elkaar verbonden zijn. Vervolgens wordt er gekeken of de route die het pakket heeft afgelegd te herleiden is door middel van de visualisatie.

Om te zien wat de route van een pakket is wordt er gebruik gemaakt van de visuele weergaven van de data ’flow’ binnen het netwerk. In figuur 5.2 is de visualisatie te zien van het versturen van het pakket van node ’A’ naar node ’F’. Zoals te zien is wordt het pakket vanaf ’A’ naar ’C’ gestuurd. Vervolgens van ’C’ naar ’D’. Daarna van ’D’ naar ’E’. En als laatst van ’E’ naar ’F’. Door het groen worden van de verbindingen en de pijl die de richting aan geeft, kan er worden gezien welke route het pakket neemt.

Figuur 5.1: Structuur van het netwerk tijdens het experiment

Figuur 5.2: Structuur van het netwerk met daarop de verbindingen tussen de nodes. De kleur van de verbinding laat zien of er data wordt verstuurd over de verbinding. Het pijltje geeft aan in welke richting de data wordt verstuurd.

5.1.2

Experiment 2: Performance en IO

In dit experiment wordt een gedistribueerd benchmark algoritme uitgevoerd op het test platform. De node waarop het benchmark algoritme wordt gestart maakt voor iedere node een verzameling van getallen aan en stuurt deze naar de nodes. Ook worden de nodes opeenvolgend genummerd. Vervolgens voeren de nodes dezelfde berekening uit op alle waardes in de verzameling van getal-len. Wanneer een node hiermee klaar is wordt de verzameling naar de node gestuurd met het opeenvolgende nummer. De node die het hoogste nummer heeft stuurt de verzameling naar de node met het laagste nummer. De verzamelingen worden dus in een cirkel rond gestuurd.

Wan-constant is (omdat dezelfde berekening wordt gedaan op alle waardes). Wanneer de node klaar is met het uitvoeren van de berekeningen zou de performance van de node 0 moeten worden en het aantal bytes dat verstuurd wordt per seconden zou omhoog moeten gaan, tot de node klaar is met het versturen van de verzameling. Wanneer de nieuwe verzameling is ontvangen kan de node weer verder gaan met het uitvoeren van de berekeningen, de performance grafiek hoort dus omhoog te gaan. Dit zou N aantal keer herhaald moeten worden.

Het kan voorkomen dat een node de nieuwe verzameling heeft ontvangen voordat deze klaar is met het uitvoeren van de berekeningen op de oude verzameling. Hierdoor wordt er verwacht dat de performance dan niet naar 0 zal gaan wanneer deze klaar is met het uitvoeren van de berekeningen op de oude verzameling. Dit is echter alleen het geval wanneer de nieuwe verzameling al volledig is ontvangen voordat de node klaar is met de oude verzameling.

In figuur 5.3 zijn de IO en de performance grafiek van een node te zien tijdens het uitvoeren van het algoritme. In de performance grafiek is te zien dat tijdens het uitvoeren van het algoritme de performance ongeveer constant is. Ook is te zien dat wanneer een node klaar is met het uitvoeren van de berekeningen, de verzameling verstuurd wordt en de performance naar 0 gaat. Nadat de node de nieuwe verzameling heeft ontvangen gaat de performance weer om hoog. In het figuur is ook te zien dat dit proces meerdere keren wordt herhaald. In figuur 5.4 is te zien dat wanneer de nieuwe verzameling is ontvangen voordat de node klaar was met de oude verzameling, de performance niet naar 0 gaat.

Figuur 5.3: Performance en IO grafiek van een node tijdens het experiment

De verwachting en de daadwerkelijke visualisatie komen overeen met elkaar. Ook kan het gedrag van het algoritme worden afgeleid door middel van de visualisatie. Zo kan er op basis van de visualisatie geconcludeerd worden dat een node moet wachten tot de nieuwe verzameling is ontvangen, wanneer deze klaar is met het uitvoeren van de berekeningen op de oude verzameling. Ook is te zien dat wanneer een node klaar is met het uitvoeren van berekeningen, de verzameling wordt verstuurd naar een andere node in het netwerk.

Figuur 5.4: Performance en IO grafiek van een node tijdens het experiment

5.1.3

Experiment 3: Wave equation

In het wave equation experiment wordt er onderzocht of het gedrag en de werking van de ge-distribueerde 1-dimensionale wave equation kan worden afgeleid door middel van de visualisatie. De 1-dimensionale wave equation berekent de beweging van een golf over tijd. Voor de golf wordt er gebruik gemaakt van een discrete golf, dit betekent dat de golf wordt uitgedrukt als een array van (amplitude) waardes (zie figuur 5.5). De uiterste punten aan beide kanten van de wave zijn altijd 0. Om de nieuwe waardes van de golf te berekenen wordt formule 5.1 gebruikt. Zoals te zien is in de formule, wordt er gebruik gemaakt van de huidige waardes en de vorige waardes van de golf om de waardes van de volgende tijdstap te berekenen. Om een waarde te berekenen wordt er ook gebruik gemaakt van de waardes rechts en links van deze waarde.

Ai,t+1 = 2 ∗ Ai,t− Ai,t−1+ 0.15 ∗ (Ai−1,t− (2 ∗ Ai,t− Ai+1,t)) (5.1)

De 1-dimensionale wave equation kan worden gedistribueerd over verschillende nodes. Iedere node berekent dan een deel van de golf. Doordat de waardes rechts en links nodig zijn van een waarde om de nieuwe waarde te berekenen, ontstaat er overlap tussen de verschillende stukken van de golf. Dit komt doordat de nodes waardes nodig hebben die door een andere node worden berekend (Zie figuur 5.6). Na iedere tijdstap moeten deze rand waardes worden gesynchroniseerd tussen de verschillende nodes voordat deze verder kunnen met het berekenen van de nieuwe tijdstap. De beweging van de wave zal over N tijdstappen worden berekend.

De verwachting is dat in de visualisatie van de performance grafiek er pieken en dalen zijn. Wanneer er een piek is in de performance grafiek, berekent de node de nieuwe waardes van de golf. Wanneer de rand waardes worden gesynchroniseerd tussen de nodes, zal er een dal zijn doordat de performance 0 zal worden omdat de nodes moeten wachten tot de rand waardes ontvangen zijn. Tijdens het dal in de performance grafiek zal de in- en output grafiek omhoog

Figuur 5.5: Voorbeeld van een discrete golf

Figuur 5.6: Voorbeeld van een wave die over drie stukken wordt verdeeld. Zoals te zien is zitten er tussen twee delen rand waardes die gesynchroniseerd moeten worden tussen de tijdstappen.

dalen ontstaan door het synchroniseren van de randen tussen de nodes. Dit is te zien doordat als er een dal in de performance grafiek is, er een piek in de IO grafiek ontstaat. Echter, wordt de performance niet altijd 0 tijdens het synchroniseren van de randen. Dit is te verklaren doordat de performance over een interval wordt gemeten. Hierdoor kan het zijn dat de performance voor maar een deel van de meting 0 was en er dus alleen een dal ontstaat.

Figuur 5.7: Performance en IO grafiek van het netwerk tijdens het experiment

5.2

Invloed op de performance van het netwerk

Het monitor node proces is ge¨ımplementeerd op elke node in het netwerk om de karakteristieken te verzamelen van de node en het netwerk. Om de gegevens van de node te verzamelen moet het monitor node proces gebruik maken van de CPU van de node. Ook moet de node informatie verstuurd worden naar het monitor visualisatie proces, hiervoor gebruikt het monitor node proces ook de CPU en de in- en output van de node. Het monitor node proces zorgt dus voor extra overhead op de node. Doordat het monitor systeem een aparte communicatie laag heeft, zal deze geen extra overhead geven op de communicatie laag van het test platform.

In dit experiment wordt onderzocht hoeveel het monitor node proces de performance van de node be¨ınvloed en dus de performance van het gehele netwerk. Ook wordt er onderzocht of er een verband zit tussen de invloed van het monitor node proces op de performance en het aantal nodes in het netwerk.

Om de invloed op de performance van het netwerk te meten wordt de wave equation (zie sectie 5.1.3) uitgevoerd op het ad hoc netwerk. Dit wordt gedaan met en zonder monitor systeem. Het verschil in executie tijd is de overhead die het monitor systeem veroorzaakt in het netwerk. Dit experiment wordt uitgevoerd op netwerken met verschillende aantallen nodes om te zien of er een verband is tussen de overhead die het monitor systeem veroorzaakt en het aantal nodes in

manier wordt uitgevoerd. Verder wordt het algoritme 10 keer uitgevoerd om een gemiddelde executie tijd te kunnen berekenen.

Voor de instellingen van het experiment wordt gebruik gemaakt van een meet interval van 500 milliseconden (voor het monitor systeem). Er wordt een array grootte van 200000 elementen gebruikt en de wave wordt over een periode van 300 tijdstappen berekent. De array grootte en het aantal tijdstappen zijn zo gekozen om te zorgen dat zowel de performance en in- en output van de nodes worden belast tijdens het experiment.

De executie tijden met en zonder monitor systeem zijn te zien in figuur 5.8. Zoals in de grafiek te zien is, zorgt het monitor systeem voor overhead op de performance van het ad hoc netwerk. In figuur 5.9 is het percentage overhead te zien van het monitor systeem. De overhead bevindt zich ongeveer tussen de 15.5 en 17.2 procent voor het gebruikte meet interval ongeacht het aantal nodes binnen het netwerk.

Figuur 5.8: Gemiddelde executie tijd van de wave equation met een interval van 500 millisecon-den, een array grootte van 200000 en 300 tijdstappen

Dit is te verklaren doordat het monitor node proces een gedistribueerd proces is dat op elke node is ge¨ımplementeerd. Hierdoor belast het monitor node proces iedere node ongeveer even zwaar, ongeacht het aantal nodes in het netwerk. Doordat het UDP protocol wordt gebruikt, hoeft het monitor node proces niet te controleren of het pakket is aangekomen bij het monitor visualisatie proces. Hierdoor kan het monitor node proces de node informatie versturen naar het monitor visualisatie proces, zonder dat het monitor node proces hoeft te wachten op een reactie van het monitor visualisatie proces.

De overhead die het monitor systeem veroorzaakt op de performance van het netwerk is bij benadering constant bij verschillende aantallen nodes binnen het netwerk, dus er kan geconclu-deerd worden dat het monitor systeem schaalbaar is. Dit moet echter nog geverifieerd worden wanneer nog rekening wordt gehouden met een uitgebreidere set factoren. In sectie 6.2 wordt hierop dieper ingegaan.

Figuur 5.9: Percentage overhead van de monitor met een interval van 500 milliseconden, een array grootte van 200000 en 300 tijdstappen

HOOFDSTUK 6

Future work

6.1

Invloed overige karakteristieken

Naast structuur, in- en output, performance, CPU load en node status zijn er ook andere ka-rakteristieken die invloed hebben op het gedrag van een heterogeen ad hoc netwerk. Deze zijn echter niet behandeld doordat deze buiten de scope van dit project vallen. Dit zijn bijvoorbeeld de verbindings kwaliteit, node kwaliteit en de (geografische) co¨ordinaten.

Niet alle verbindingen binnen het ad hoc netwerk hebben namelijk dezelfde kwaliteit. Ver-bindingen tussen nodes die verder uit elkaar staan of waartussen meer obstakels staan, zijn vaak van slechtere kwaliteit dan verbindingen tussen nodes die dicht bij elkaar staan of waar geen obstakels tussen zitten. De verbindings kwaliteit heeft bijvoorbeeld invloed op het gedrag van het ad hoc netwerk doordat wanneer een verbinding tussen twee nodes een slechte kwaliteit heeft, er hoogstwaarschijnlijk minder data per seconden over verstuurd kan worden dan over een verbinding met een goede kwaliteit. Dit kan effect hebben op de in- en output van het hele netwerk.

Doordat bij heterogene ad hoc netwerken de nodes verschillende hardware specificaties kunnen hebben zijn niet alle nodes van dezelfde kwaliteit. Een node met betere hardware specificaties is van een hogere kwaliteit dan een node met slechtere hardware. De node kwaliteit kan bijvoorbeeld invloed hebben op de performance van een node. Een node met een hogere node kwaliteit zal waarschijnlijk een hogere maximale performance hebben dan een node met een lagere node kwaliteit.

De netwerk graaf van het ad hoc netwerk wordt gegenereerd door middel van de informatie over de nodes en de informatie over de verbindingen. Van deze graaf wordt een visuele weergaven gemaakt waarin de nodes en de verbindingen te zien zijn. De locatie van de nodes op deze visuele weergaven komen echter niet overeen met de werkelijke (geografische) locatie van de nodes. Door de (geografische) co¨ordinaten te meten van de nodes, kan ervoor worden gezorgd dat de locaties van de nodes op de visualisatie overeen komen met de werkelijke (geografische) locaties. Hierdoor kan bijvoorbeeld worden gezien wat de afstand is tussen de nodes. Dit kan helpen met het analyseren van het gedrag van het ad hoc netwerk.

6.2

Invloed overige schaalbaarheidsfactoren

In de experimenten is onderzocht wat de invloed van het monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk. Dit is gemeten met netwerken met verschillende aantallen nodes. Het resultaat hiervan is dat de overhead die de monitor veroorzaakt op de performance van het ad hoc netwerk tussen de 15.5 en 17.2 procent is, ongeacht het aantal nodes in het netwerk.

Dit zorgt ervoor dat de overhead die wordt veroorzaakt op de performance van de nodes geen beperking is voor de schaalbaarheid van het monitor systeem. Er zijn echter andere factoren die

ook invloed hebben op de schaalbaarheid van het monitor systeem voor grotere hoeveelheden nodes.

Een factor is het fysieke bereik van de communicatie laag van het monitor systeem, doordat alle nodes direct verbonden moeten zijn met het monitor visualisatie proces. Voor de implemen-tatie van dit project is WiFi gebruikt, wat een beperkt bereik heeft. Hierdoor kan het voorkomen dat wanneer het netwerk bestaat uit een groot aantal nodes, het netwerk zich verspreid over een groter vervlak waardoor niet alle nodes in het bereik zijn van het monitor visualisatie proces.

Om dit probleem op te lossen zou onderzocht kunnen worden hoe het monitor systeem zich gedraagt wanneer er meerdere ’verzamelpunten’ zijn waarnaar de node informatie pakketten toegestuurd kunnen worden. Deze ’verzamelpunten’ zouden dan alleen verantwoordelijk zijn voor het ontvangen van de node informatie pakketten van de nodes die in de buurt zijn en het doorsturen van deze pakketten naar het monitor visualisatie proces. Hierdoor kan het bereik van het monitor systeem vergroot worden door meer ’verzamelpunten’ toe te voegen.

Een andere oplossing die onderzocht zou kunnen worden is dat de nodes die niet in het bereik van het monitor visualisatie proces zijn, de node informatie pakketten naar nodes sturen die wel in het bereik van het monitor visualisatie proces zijn. De node informatie pakketten kunnen naar deze nodes verstuurd worden via de bestaande communicatie laag van het ad hoc netwerk. Vervolgens sturen de nodes die in het bereik zijn van het monitor visualisatie proces de pakketten door naar het monitor visualisatie proces.

Ook zou er onderzocht kunnen worden hoe het monitor systeem zich gedraagt wanneer de node informatie pakketten via mobiel internet(bijvoorbeeld 3G of 4G) naar het monitor visualisatie proces gestuurd worden.

Een andere factor die invloed heeft op de schaalbaarheid van het netwerk is het aantal node informatie pakketten die het monitor visualisatie proces kan verwerken. Wanneer het aantal nodes binnen het netwerk groeit, zal ook het aantal node informatie pakketten die het monitor visualisatie proces moet verwerken groeien. Er zou dus onderzocht kunnen worden wat het limiet is van het aantal node informatie pakketten die het monitor visualisatie proces kan verwerken en of dit verhoogt kan worden door bijvoorbeeld het monitor visualisatie proces te parallelliseren.

HOOFDSTUK 7

Conclusie

In dit onderzoek is aangetoond dat de karakteristieken van een (heterogeen) ad hoc netwerk, zodanig kunnen worden weergegeven, dat deze interpreteerbaar zijn. Dit is onderzocht door het ontwikkelen en implementeren van een monitor systeem op een test platform. Hiervoor is onderzocht hoe de karakteristieken van het ad hoc netwerk gemeten kunnen worden. Tevens is er onderzocht hoe de verzamelde gegevens over de karakteristieken van het ad hoc netwerk gevisualiseerd kunnen worden zodat deze interpreteerbaar zijn.

Hiervoor zijn twee verschillende processen nodig, het monitor node proces en het monitor visualisatie proces. Het monitor node proces is een gedistribueerd proces dat ge¨ımplementeerd is op elke node in het netwerk en wat de informatie verzameld van de nodes. Het monitor visualisatie proces verwerkt en visualiseert de gegevens die door de monitor node processen verzameld zijn. De visualisatie wordt weergegeven door middel van een interactieve grafisch user interface.

Op de grafische user interface worden de karakteristieken van het netwerk gevisualiseerd. Hierop is de structuur en de data flow van het netwerk te zien. Door middel van kleuren wordt de status van de nodes en de verbindingen weergegeven. Ook is te zien welke kant de data wordt verstuurd over een verbinding. Daarnaast zijn er ook een performance en IO grafiek te zien op de grafisch user interface. Deze grafieken laten de performance en IO zien van de nodes in het netwerk.

Door middel van de visualisatie van het netwerk, is het mogelijk om de data flow te zien binnen het netwerk. Hierdoor kunnen bijvoorbeeld pakketten gevolgd worden op de monitor. Dit kan gebruikt worden voor bijvoorbeeld het ontwikkelen en implementeren van een routing algoritme. Ook is het mogelijk om door middel van de performance en IO grafiek, het gedrag van een gedistribueerd algoritme te analyseren. Hierdoor kunnen er uitspraken gedaan worden over het gedrag en de werking van een gedistribueerd algoritme binnen het netwerk.

Ook is onderzocht wat de invloed is van het monitor systeem op de performance van de nodes en dus het gehele ad hoc netwerk. Doordat het monitor node proces een gedistribueerd proces is dat ge¨ımplementeerd is op elke node in het netwerk en metingen verricht, zorgt dit voor een overhead op de performance van de node. Doordat het monitor node proces op elke node apart ge¨ımplementeerd is, wordt de performance niet be¨ınvloed door het aantal nodes binnen het netwerk. Dit zorgt ervoor dat de overhead die het monitor systeem veroorzaakt tussen de 15.5 en 17.2 procent is voor het gebruikte meet interval ongeacht het aantal nodes binnen het netwerk.

De overhead die het monitor systeem veroorzaakt op de performance van het netwerk is bij be-nadering constant bij verschillende aantallen nodes binnen het netwerk, dus er kan geconcludeerd worden dat het monitor systeem schaalbaar is. Dit moet echter nog geverifieerd worden wanneer nog rekening wordt gehouden met een uitgebreidere set factoren. Een factor is het fysieke be-reik van het monitor visualisatie proces. Ook is de verwerkingscapaciteit van de pakketten van het monitor visualisatie proces een factor wat invloed kan hebben op de schaalbaarheid van het monitor systeem.

BIJLAGE A

Lijst van meetbare gegevens

Waarden Omschrijving

Status De status van de node

Taak De taak waarmee de node bezig is Progress De voortgang de taak

Payload De totale hoeveelheid werk van de taak Perfomance De performance van de node

CPU load De CPU load van de node

Bytes send Het aantal bytes dat de node heeft verstuurd sinds de laatste meting Bytes received Het aantal bytes dat de node heeft

ontvangen sinds de laatste meting Total bytes send Het totaal aantal bytes dat

de node heeft verstuurd Total bytes received Het totaal aantal bytes dat

de node heeft ontvangen Packages send Het aantal pakketten dat

de node heeft gestuurd Packages received Het aantal pakketten dat

de node heeft ontvangen

Connections

De verbindingen die de node heeft met andere nodes. Voor iedere verbinding wordt bijgehouden:

Met welke node de verbinding is.

Hoeveel data er over de verbinding is gestuurd sinds de laatste meting. Hoeveel data er over de verbinding is ontvangen sinds de laatste meting. Hoeveel data er totaal over de verbinding is gestuurd.

Bibliografie

[1] Saif Al-Sultan, Moath M Al-Doori, Ali H Al-Bayatti, and Hussien Zedan. A comprehensive survey on vehicular ad hoc network. Journal of network and computer applications, 37:380– 392, 2014.

[2] Josh Broch, David A Maltz, David B Johnson, Yih-Chun Hu, and Jorjeta Jetcheva. A performance comparison of multi-hop wireless ad hoc network routing protocols. In Pro-ceedings of the 4th annual ACM/IEEE international conference on Mobile computing and networking, pages 85–97. ACM, 1998.

[3] Timothy X Brown, Sheetalkumar Doshi, Sushant Jadhav, Daniel Henkel, and Roshan-George Thekkekunnel. A full scale wireless ad hoc network test bed. Proceedings of IS-ART05, pages 51–60, 2005.

[4] Thomas Heide Clausen, Justin W Dean, and Christopher Dearlove. Mobile ad hoc network (manet) neighborhood discovery protocol (nhdp). 2011.

[5] Marco Conti and Stefano Giordano. Mobile ad hoc networking: milestones, challenges, and new research directions. Communications Magazine, IEEE, 52(1):85–96, 2014.

[6] Kevin Fall and Kannan Varadhan. The network simulator (ns-2). URL: http://www. isi. edu/nsnam/ns, 2007.

[7] Frank HP Fitzek, P Seeling, M Reisslein, and M Zorzi. Visualization tool for ad hoc networks (vitan). Technical report, Technical Report 003-02, acticom, www. acticom. de, 2002. [8] Magnus Frodigh, Per Johansson, and Peter Larsson. Wireless ad hoc networking: the art

of networking without a network. Ericsson Review, 4(4):249, 2000.

[9] Stuart Kurkowski, Tracy Camp, Neil Mushell, and Michael Colagrosso. A visualization and analysis tool for ns-2 wireless simulations: inspect. In Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, 2005. 13th IEEE International Symposium on, pages 503–506. IEEE, 2005.

[10] David L Mills. Internet time synchronization: the network time protocol. Communications, IEEE Transactions on, 39(10):1482–1493, 1991.

[11] Jon Postel. Transmission control protocol. 1981.

[12] Jon Postel and User Datagram Protocol. Rfc 768. User datagram protocol, pages 1–3, 1980. [13] Nazmus Saquib, Md Sabbir Rahman Sakib, and Al-Sakib Khan Pathan. Visim: A user-friendly graphical simulation tool for performance analysis of manet routing protocols. Ma-thematical and Computer Modelling, 53(11):2204–2218, 2011.

[14] Emmanouil Spanakis, Christodoulos Efstathiades, George Pallis, and Marios D Dikaiakos. Real-time graph visualization tool for vehicular ad-hoc networks:(vivagr: Visualization tool of vanet graphs in real-time). In Computers and Communications (ISCC), 2011 IEEE Symposium on, pages 729–734. IEEE, 2011.