Ontwikkeling van zelf-lerende sensornetwerken door middel van artificiële intelligentie

Transcriptie

1 Faculteit Ingenieurswetenschappen en architectuur Vakgroep Informatietechnologie Voorzitter: Prof. dr. ir. D. DE ZUTTER Ontwikkeling van zelf-lerende sensornetwerken door middel van artificiële intelligentie door Gustav JANSSENS Promotoren: Prof. dr. ir. I. MOERMAN, dr. ir. E. DE POORTER Scriptiebegeleider: M. ROVCANIN Scriptie ingediend tot het behalen van de academische graad van Master of Science in de ingenieurswetenschappen: elektrotechniek: informatie- en communicatietechnologie Academiejaar

2 Voorwoord Draadloze sensornetwerken bestaan uit een netwerk van autonome sensornodes, die verschillende metingen kunnen uitvoeren, en de data op een coöperatieve manier kunnen doorsturen naar een centraal punt; de sink. Deze netwerken zijn een zeer recente topic van onderzoek, met vele interessante mogelijkheden. Eerst werd deze technologie actief gesponsord voor militaire doeleinden, hoofdzakelijk verkenning en bewaking. Heden ten dage worden deze netwerken ook gebruikt in vele commerciële en industriële toepassingen, zoals het monitoren van natuurgebieden (voorkomen van bosbranden e.d.), het opvolgen van patiënten, controle van luchtkwaliteit, monitoren van voorraad,... Deze veelvoud van mogelijke toepassingen maakt het een zeer interessant en actief onderzoeksgebied. Het was dan ook zeer interessant voor mij om mijn scriptie over dit onderzoeksdomein te kunnen schrijven. Ik hoop dat ik met dit werk mijn steentje heb kunnen bijdragen aan het dichterbij brengen van goedkopere en beter functionerende sensornetwerken. Ik wil dan ook mijn promotor, dr. ir. Eli De Poorter bedanken voor de intense begeleiding, en de persoonlijke opvolging van de uiteindelijke invulling en implementatie van de thesis. Ook zou ik graag Prof. dr. ir. Ingrid Moerman bedanken voor het voorstellen van dit onderwerp, en de initiële begeleiding. Verder zou ik graag Milos Rovcanin bedanken voor de samenwerking en het gebruik van een deel van zijn software. Zonder hem zou de implementatie nog een heel stuk verder af staan. Verder wil ik ook nog de vele mensen bedanken die de tijd namen om mijn scriptie na te lezen; Kaat, Mathias, pa en ma, bedankt voor jullie geduld en tijd! Verder wil ik nog specifiek mijn ouders bedanken, om mij alle mogelijkheden te geven die mij de persoon gemaakt hebben die ik nu ben. Ten slotte wil ik nog de mensen bedanken die hier niet specifiek vermeld zijn, maar die mij toch op de een of andere manier gesteund hebben. Bedankt. Gustav Janssens, juni 2013

3 Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Gustav Janssens, juni 2013

4 Ontwikkeling van zelf-lerende sensornetwerken door middel van artificiële intelligentie door Gustav JANSSENS Scriptie ingediend tot het behalen van de academische graad van Master of Science in de ingenieurswetenschappen: elektrotechniek: informatie- en communicatietechnologie Academiejaar Promotoren: Prof. dr. ir. I. MOERMAN, dr. ir. E. DE POORTER Scriptiebegeleider: M. ROVCANIN Faculteit Ingenieurswetenschappen en architectuur Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. dr. ir. D. DE ZUTTER Samenvatting In dit werk proberen we de kostprijs van het opzetten en onderhouden van sensornetwerken te verminderen door het netwerk zelf-lerend te maken. Hiertoe implementeren we een zelf-lerend algoritme m.b.v. reinforcement learning en LSPI, dat parameters optimaliseert van bestaande MAC en routeringsprotocollen. Vervolgens wordt dit getest in softwaresimulaties met motes die het Contiki besturingssysteem draaien. Trefwoorden Sensornetwerk, artificiële intelligentie, reinforcement learning, LSPI, Contiki, ContikiMAC, RPL

5 Lijst van afkortingen MAC IP 6LoWPAN OS UDGM RPL CoAP CCA RDC LLN ROLL DODAG DAG ETX URI RL LSPI TCP UDP Cf Er SLIP XML Media Access and Control Internet Protocol IPv6 over Low power Wireless Personal Area Networks Operating System Unit Disk Graph Medium Ripple Routing Protocol Constrained Application Protocol Clear Channel Assessment Radio Duty Cycle Low power and Lossy Network Routing over Low power and Lossy [networks] Destination Oriented Directed Acyclic Graph Directed Acyclic Graph Expected Transmission Count Uniform Resource Identifier Reinforcement Learning Least Squares Policy Iteration Transmission Control Protocol User Datagram Protocol Californium Erbium Serial Line Interface Protocol Extensible Markup Language

6 Development of self-learning wireless sensor networks using artificial intelligence Gustav Janssens Supervisor(s): Ingrid Moerman, Eli De Poorter, Milos Rovcanin Abstract This article tries to reduce the price of setting up and maintaining sensor networks by implementing a self-learning algorithm. Parameters of existing MAC and routing protocols are optimised using Reinforcement Learning and LSPI. This is tested in software simulation, using Cooja and the Contiki OS. Keywords Sensor network, artificial intelligence, reinforcement learning, LSPI, Contiki, ContikiMAC, RPL I. INTRODUCTION THE cost of setting up and maintaining wireless sensor networks is currently very high, due to the high amount of manual design and maintenance that is required. This article presents a method to allow the network to tune specific parameters in existing network protocols, thus decreasing the amount of manual work that needs to be done. This also allows the network to adapt to a changing environment, without manually reconfiguring the parameters. In this abstract, we will present a Negotiation Engine, which uses Reinforcement Learning and LSPI[1] to optimise 2 parameters, each having 2 discrete values. We will then test this in Cooja, which is a cross-level network simulator for the Contiki operating system[2]. A. OS and protocols II. DESIGN CHOICES As mentioned before, we will optimise 2 parameters from existing protocols in the Contiki OS. We have selected Contiki- MAC[3], a very efficient RDC protocol, and RPL[4], a distance vector IPv6 routing protocol. In ContikiMAC, we will optimise the wake-up frequency (8Hz or 16Hz), and in RPL we will optimise ETX ALPHA, which controls the ratio in which previous measurements are considered for the current link quality (65% or 90% weight for current measurement). Getters and setters for these parameters are implemented in the source code. We will use CoAP (Constrained Application Protocol) to distribute the values of these parameters to the sensornodes, by running an Er CoAP server[5] on each node, and implementing a CoAP client in the Negotiation Engine. B. Artificial Intelligence The Negotiation Engine will utilise Reinforcement Learning, and more specifically, the LSPI method[1]. Its incentives (or basis functions) are: total radio-off time and packet delivery ratio. The user is able to set goals for these functions. These goals are then compared to measurements gathered during an episode to calculate a reward (using an exponentially rising function that tapers off when the goal is exceeded). The state that yields the highest expected future reward is then chosen. The possible states are as follows: State 0: Wake-up frequency 8Hz, ETX ALPHA 90; State 1: Wake-up frequency 16Hz, ETX ALPHA 90; State 2: Wake-up frequency 16Hz, ETX ALPHA 65; State 3: Wake-up frequency 8Hz, ETX ALPHA 65. C. Cooja scenario We will test this Negotiation Engine using a Cooja scenario with Contiki motes, using an UDGM (Unit Disk Graph Medium) radio model with distance loss. Twelve udp-senders send UDP packets to an udp-sink in an RPL network, using ContikiMAC. These packets contain a sequence number and RDC information, to be used in the calculation of rewards. We also implement a border router functionality in the udp-sink, to send information to a separate server (or the host of the Cooja simulation), which runs the Negotiation Engine. An episode can, for example, last until approximately 200 packets are received in the sink. A simplified overview of the setup is shown in Fig. 1. Notice that the approach is very modular, and several parts are interchangeable. The setup can easily be modified to use different scenarios, parameters, and even methods. The Negotiation Engine itself is also built out of different parts (not shown in Fig. 1), such as a main logic loop, a function that handles measurement gathering, main LSPI logic,... This means that changing one detail of the implementation does not necessitate a complete rework of the implementation. Fig. 1. Simplified overview of the complete setup. UDP-senders send UDP packets in an RPL network to the UDP-sink. Measurements are sent by the UDP-sink to the server running the Negotiation Engine. A CoAP client is used by the Negotiation Engine to change parameters in the UDP-senders, by querying the CoAP servers A. Basic scenario III. EVALUATION NEGOTIATION ENGINE To evaluate the choices of discrete values, we first test each incentive separately; only rewarding long radio-off times or high

7 throughputs. We see that for long radio-off times, we consistently pick a wake-up frequency of 8Hz, alternating between states 0 and 3. For a high throughput, we alternate between states 0 and 1, for an ETX ALPHA value of 90. We then allocate even attention to both incentives, with goals of 1% RDC and 95% throughput (about 10.5 packets lost on average in an episode of 200 received packets). We see that states 0 and 1 are picked about evenly (in a test run with 212 episodes, states 0 and 1 are picked 71 and 80 times, respectively). To evaluate this choice, we compare the results with a static choice of state 1 and state 3 (respectively the most and least chosen state). These results are shown in table I. The algorithm strikes a compromise between both extremes, to meet the incentives we specified. This test run was executed with a random exploration of 30%, which impacts the performance for a static scenario (no random exploration is needed, the environment does not change over time). Without random exploration, we can achieve averages of 1.32% RDC and only 2.43 lost packets (in a test run with 240 episodes). as well, due to more frequent RPL path changes. We will test this hypothesis in a scenario with 350 episodes. In the first 153 episodes of the scenario, we will run the basic scenario as outlined previously. In episodes , the nodes will become mobile, with random movement (between -1 and +1 meter per second) for 40 seconds. This pattern will then be repeated. In the first half of the scenario, state 0 is preferred, with better performance in both RDC and packet loss. In the second half, state 1 becomes more and more interesting, and is being picked often (69 times vs. 93 times for state 0). State 3 shows much worse performance, however, and is seldomly being picked. The chosen states as a function of the episode (episodes ) are shown in Fig. 2. TABLE I RESULTS (AVERAGE RDC AND AVERAGE AMOUNT OF PACKETS LOST) FOR TEST RUNS WITH THE ALGORITHM RUNNING, AND WITH STATIC STATES 1 AND 3 RDC Lost packets Algorithm 1.34% 9.88 State % 1.97 State % B. Negotiation Engine overhead To disseminate the state in the network, we need to implement updating periods, during which the CoAP PUT requests are sent to each node. In the current implementation, the UDP traffic is still being sent, along with the CoAP messages. After each node has sent an ACK of the state update, the Negotiation Engine waits 6 minutes before measurements are resumed. To estimate the overhead of such a period, we will look at its average RDC and at the average throughput of the UDP traffic in a test run with 486 episodes, using the same settings as before. As a measure of energy consumption, we first look at the average RDC during an update period. We measure an average increase of % extra radio-on time, which is anincrease of only 0.07% relative to the RDC in measurement periods. We can thus assume that the impact on the lifetime is limited. However, most of the overhead cost is situated in the interference generated by the extra traffic. The throughput of UDP packets lowers to 88.08%, compared to an average of 94.62% during measurements periods. The usecase will have to take this into account, either by limiting or halting normal traffic during updateperiods, or by limiting random exploration (which limits the amount of updateperiods). Fig. 2. State as a function of episode, episodes Episode 154 is marked. IV. CONCLUSION The simulations show that the implementation is able to strike a balance between incentives given by the developer, by changing the parameters of MAC and routingprotocols at runtime. The system is also able to adapt to changing circumstances. There are many tests that can still be performed however, such as testing the implementation in hardware, testing other scenarios, other parameters and other protocols. The Negotiation Engine itself can also be improved, for example to allow more discrete values. Still, the simulation results are promising, and the overhead cost is not prohibitive. With further work, the implementation as it is presented in this thesis could aid in the development of a fully autonomous self-learning sensornetwork. REFERENCES [1] Lagoudakis, M. G. and Parr, R. (2001). Model-free least squares policy iteration. Technical report, Advances in Neural Information Processing Systems. [2] consulted on 18/05/2013 [3] Dunkels, A. (2011). The contikimac radio duty cycling protocol. [4] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, J., and Alexander, R. (2012). RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. RFC 6550 (Proposed Standard). [5] Kovatsch, M., Duquennoy, S., and Dunkels, A. (2011). A low-power coap for contiki. In Proceedings of the 8th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2011), Valencia, Spain. C. Other scenarios To test a more volatile scenario, we will simulate mobile nodes. Mobile nodes should value a lower ETX ALPHA higher

8 INHOUDSOPGAVE i Inhoudsopgave 1 Inleiding Probleemstelling Doelstelling Literatuurstudie Algemene ontwerpkeuzes Protocolkeuzes MAC-protocol Routeringsprotocol Internet of things en het sensornetwerk Internet of things Besturingssysteem ContikiMAC Ripple routing protocol (RPL) Constrained Application Protocol (CoAP) Zelf-lerend Algoritme Type artificiële intelligentie Reinforcement Learning en Q-learning Least Squares Policy Iteration (LSPI) Ontwerp en implementatie Opstelling basisscenario Inleiding Parameter getter-setters Erbium CoAP Server

9 INHOUDSOPGAVE ii Basisscenario: rpl-collect Aanpassingen rpl-collect Border router Negotiation Engine Inleiding RL-LSPI implementatie Negotiation Engine logica Verzamelen van metingen Cf CoAP Client Verwerken gegevens Integratie onderdelen Verloop test run Uitbreidingsmogelijkheden Evaluatie Negotiation Engine Testen basisscenario Basisalgoritme RDC Basisalgoritme Throughput Volledig basisscenario Kost CoAP update periode Besluit Testen geavanceerde scenario s Mogelijke scenario s Scenario met interferentie Verhogen packet sending rate Scenario met mobiele nodes Variërende scenario s Inleiding Variërend scenario met mobiliteit Conclusie en verder onderzoek Bereikte doelstellingen Verder onderzoek

10 INHOUDSOPGAVE iii Real-life scenario Verdere testmogelijkheden Uitbreidingen Negotiation Engine Conclusie

11 INLEIDING 1 Hoofdstuk 1 Inleiding 1.1 Probleemstelling Een draadloos sensornetwerk bestaat uit een potentieel groot aantal sensornodes die verspreid zijn over een oppervlak om er metingen uit te voeren. De vergaarde metingen worden verzameld in een sink. Sensornodes zijn goedkope, onbetrouwbare en energiebeperkte devices die voor een zo lang mogelijke tijd autonoom moeten functioneren. Dit leidt tot een heel aantal uitdagingen. Het opzetten van een draadloos sensornetwerk vereist heel wat tijd, en is dus zeer duur. De protocolkeuzes en instellingen zijn immers sterk afhankelijk van vele parameters, zoals vereisten op vlak van levensduur, betrouwbaarheid, de omgeving, de densiteit van de nodes, mobiliteit van de nodes,... Deze parameters kunnen ook veranderen in de tijd, en de performantie van het netwerk kan hierdoor verminderen. Voorbeelden hiervan zijn veranderende interferentie, het wegvallen van nodes, veranderende vereisten in trafiek,... Vaak leidt dit tot een (dure) manuele herconfiguratie van het netwerk. Draadloze sensornetwerken zijn nog niet courant in gebruik door de hoge complexiteit, en dus ook kostprijs, van het opzetten en onderhouden ervan. Het doel van de thesis is om deze complexiteit te verminderen door het sensornetwerk zelf-lerend te maken, zodat er minder manuele configuratie nodig is.

12 1.2 Doelstelling Doelstelling Draadloze sensornetwerken kennen een zeer breed toepassingsdomein. Voorbeelden van toepassingen zijn[4]: militaire verkenning en bewaking, bosbrand detectie, patiënt monitoring en tracking, environmental control, inventory control,... Elk ontwerp van een sensornetwerk dient rekening te houden met de karakteristieken van de omgeving en de vereistes van de toepassing. Sensornodes in een rurale omgeving zullen een volledig verschillend stralingspatroon vertonen t.o.v. nodes in een haven, waar het metaal van de containers voor zeer veel interferentie kan zorgen. Een sensornetwerk voor militaire toepassingen zal veel striktere vereistes stellen t.o.v. betrouwbaarheid, daar waar sensornodes voor bosbranddetectie eerder rekening zullen houden met energie-efficiëntie,... De ontwerper van het sensornetwerk moet dus een aantal ontwerpkeuzes maken, op basis van de geschatte performantie van de verschillende keuzes. Hierbij dient hij rekening te houden met de eigenschappen van de omgeving, en de vereistes van de toepassing. Een volgende ontwerpstap bestaat erin om het netwerk (indien mogelijk) te simuleren, om de performantie ervan beter in te schatten. Als deze simulaties voldoen aan de specificaties, kan het netwerk ontplooid worden. Vaak dient er na deze stap nog verdere tuning te gebeuren, aangezien de resultaten in simulaties nagenoeg altijd verschillen van de werkelijkheid. De ontwerper dient dus na de ontplooiing verdere metingen uit te voeren, om ontwerpkeuzes te tunen, of indien nodig, andere keuzes te maken. Het doel van de thesis is aldus om het ontwerp te vereenvoudigen door het sensornetwerk zelflerend te maken. De ontwerper dient dan enkel de specificaties van de usecase te vertalen naar een set van incentives die bruikbaar zijn door het zelf-lerend netwerk. Door gebruik te maken van feedback uit de omgeving, kan het netwerk bij het opstarten intelligente keuzes maken, zonder dat de ontwerper hier actief bij betrokken moet worden. Dit proces van continu optimaliseren kan bovendien voortgezet worden in de tijd, zodat het netwerk zich automatisch aanpast aan de veranderende omgeving. Zo kan het netwerk bv. autonoom reageren op verslechterende transmissiekarakteristieken van de omgeving door een deel van de energie-efficiëntie op te geven (door bv. het vermogen van de radio op te drijven, of door het slaapschema aan te passen). Zo kan het netwerk zelf een trade-off realiseren tussen de verschillende incentives, die bepaald zijn door de usecase.

13 1.2 Doelstelling 3 Ook kan de gebruiker van het netwerk gemakkelijk de performantie van het netwerk finetunen door de incentives aan te passen. Een voorbeeld hiervan zou zijn dat de gebruiker minder pakketverlies wil, en bereid is om hiervoor toegevingen te doen in andere incentives. Het zelf-lerend maken van het sensornetwerk leidt aldus niet alleen tot een significante kostendaling door de vermindering van de bijdrage van de ontwerper, maar ook tot een algemenere verhoging van de adaptibiliteit en de flexibiliteit.

14 LITERATUURSTUDIE 4 Hoofdstuk 2 Literatuurstudie 2.1 Algemene ontwerpkeuzes Het netwerk kan op enkele niveaus zelf-lerend gemaakt worden. Een aantal pistes zijn: het kiezen tussen verschillende protocollen, het aanpassen van parameters in deze protocollen, tot het afstemmen van protocolkeuzes tussen verschillende netwerken, teneinde de onderlinge interferentie te minimaliseren[23]. Voor deze thesis werd gekozen voor het optimaliseren van parameters in een welgekozen MAC en routeringsprotocol. In eerste instantie wordt de scope ook beperkt tot het optimaliseren van twee verschillende parameters (zowel in een MAC als in een routeringsprotocol), met elk twee toegelaten discrete waardes. Het algoritme wordt echter zo opgesteld dat zowel het aantal geïmplementeerde parameters als het aantal discrete waardes gemakkelijk uitgebreid kan worden. Het zelf-lerend algoritme kan centraal of gedistribueerd geïmplementeerd worden, elk met specifieke voor- en nadelen. Het grote voordeel van een gedistribueerd algoritme is schaalbaarheid, hetgeen een belangrijk punt is, gelet op de potentiële grootte van sensornetwerken. Echter, de architectuur van het doorsnee sensornetwerk, waarin een sinknode data verzamelt van de sensornodes (Figuur 2.1)[4], suggereert reeds een centrale aanpak. Deze sinknode is typisch ook niet zo beperkt in energievoorziening en rekencapaciteit. Omwille van deze redenen wordt gekozen voor een gecentraliseerde artificiële intelligentie, waarin de sinknode feedback verzamelt van de sensornodes, en op basis hiervan een beslissing neemt voor nieuwe parameterwaardes. Deze waardes worden vervolgens weer verdeeld over het netwerk.

15 2.2 Protocolkeuzes 5 Figuur 2.1: Typische architectuur van een draadloos netwerk. De artificiële intelligentie zou in dit voorbeeld kunnen gedraaid worden op de task manager node, waarbij de sink fungeert als bottleneck voor de trafiek afkomstig van zowel de feedback als de configuratie 2.2 Protocolkeuzes Omdat de keuze van het protocol op voorhand vast ligt, is het belangrijk om te kiezen voor performante en breed inzetbare protocollen voor zowel MAC als routering MAC-protocol De hoofdfunctie van het MAC-protocol is om zoveel mogelijk energie te besparen, om zo de levensduur van het netwerk te verhogen. Voor deze thesis moet het protocol ook gemakkelijk aanpasbaar zijn zodat de tradeoff tussen energie-efficiëntie en bandbreedte/end-to-end latency gemakkelijk gemaakt kan worden. Een veelgebruikt concept is een slaapschema, waarbij de sensornode slechts periodisch de radio aanschakelt. Een voor de hand liggende parameter om aan te passen is de lengte van dit wake-up interval, waarbij een langere wake-up een hogere bandbreedte en een lagere end-to-end latency garandeert, ten koste van de levensduur van de node. In de literatuur zijn er veel voorstellen voor deze protocollen beschikbaar, zoals B-MAC[7], X-MAC[5] en WiseMAC[6]. Het principe van WiseMAC wordt geïllustreerd in (Figuur 2.2)[8]. Het is evident dat het verhogen van de wake-up frequency de end-to-end latency zal verminderen, en dat het verlengen van de wake-up periode de maximale bandbreedte verhoogt. Een gelijkaardig idee is uitgewerkt in ZeroCal[19], een MAC-protocol dat de lengte van het slaapritme automatisch aanpast at runtime. Een cruciaal verschil is echter dat dit protocol het

16 2.2 Protocolkeuzes 6 opstellen van een energiemodel vereist, waar een algoritme op basis van artificiële intelligentie kan functioneren in een model-vrije omgeving, indien het zelf-lerend algoritme goed gekozen is (zie sectie 2.4). Figuur 2.2: WiseMAC slaapschema: de zender stuurt een korte preamble uit zodat de bestemmeling de radio op standby houdt. Het veranderen van dit schema heeft invloed op de energie-efficiëntie enerzijds, en op de end-to-end latency en bandbreedte anderzijds Routeringsprotocol De keuze van routeringsprotocol is sterk afhankelijk van de architectuur van het sensornetwerk. Aangezien de keuze gemaakt is om te werken met een gecentraliseerd algoritme, dienen we een protocol te kiezen dat geoptimaliseerd is voor het versturen van data van en naar een centrale sink. Daarom wordt geopteerd voor een protocol dat hierarchisch geïnspireerd is. In hierarchische protocollen wordt de schaalbaarheid gerealiseerd door verschillende clusters te definieren, waarbij er in de cluster wordt gerouteerd via multi-hop communicatie. Elk clusterhoofd zou dan de artificiële intelligentie kunnen implementeren, en de optimale configuratie bepalen voor de cluster.

17 2.3 Internet of things en het sensornetwerk Internet of things en het sensornetwerk Internet of things In deze thesis wordt de filosofie van het Internet of things gevolgd, waarin het sensornetwerk gezien wordt als extensie van het internet. Elke node is individueel aanspreekbaar via een IPv6 adres, zodat er met elke node individueel kan geïnterageerd worden. Het besturingssysteem voor de sensornodes moet deze filosofie ondersteunen. Meer bepaald moet 6LoWPAN[9] (IPv6 over Low power Wireless Personal Area Network) en IPv6 ondersteund worden. 6LoWPAN maakt het mogelijk om IPv6 pakketten te versturen over netwerken die gebruik maken van de IEEE standaard (definieert de physical layer en MAC voor low-rate personal area networks, of LR-WPANs). 6LoWPAN definieert de encapsulatie van de pakketten en de headercompressietechnieken die dit mogelijk maakt. De vertaling naar gecomprimeerde IPv6 headers en adressen en vice versa gebeurt dan in de border router, zodat het sensornetwerk transparant is t.o.v. de rest van het internet. Deze werkwijze neemt meer geheugen in beslag en verbruikt ook meer energie, maar biedt wel de voordelen van een IP gebaseerd sensornetwerk. Zo is het mogelijk om de parameters van elke node apart op te vragen en te wijzigen via eenvoudige HTTP GET en PUT / POST commando s (zie sectie 2.3.5). De technologische evolutie verzekert ook steeds krachtigere sensornodes, met meer geheugen en rekenkracht, zodat de nadelen minder en minder opwegen tegen de voordelen Besturingssysteem Op basis van deze vereisten wordt er gekozen voor ContikiOS[1], een open source OS dat specifiek ontwikkeld werd voor sensornodes in het Internet of Things. De volledige broncode is in C geschreven, en is vrij beschikbaar. Ook is er ondersteuning voorzien voor IPv6 en enkele recente standaarden waarvan gebruik zal gemaakt worden in deze thesis, nl. 6LoWPAN, RPL en CoAP. Verder draait er standaard een zeer efficiënt MAC-protocol dat gebruik maakt van een periodisch wake-up interval, met enkele verbeteringen, zoals verder besproken zal worden. Contiki wordt specifiek ontwikkeld voor sensornodes, en ondersteunt dus ook een heel aantal recente MCU s/socs, zoals de TI MSP430, gebruikt in o.a. de Tmote Sky, en de TI MSP430x, gebruikt in o.a. de Zolertia Z1[2].

18 2.3 Internet of things en het sensornetwerk 8 Contiki biedt ook een simulator aan, Cooja[12], dat toelaat om het volledig netwerk te simuleren in software. Deze simulator ondersteunt vele platformen, zoals de Tmote Sky en de Zolertia Z1. Dit laat de ontwikkelaar toe om netwerken op een grote schaal te simuleren, of om enkele nodes in hoog detail te emuleren. In deze thesis zal er van deze laatste optie gebruik gemaakt worden, om zo het concept in software te evalueren. Als radio medium wordt het zogenaamde UDGM (Unit Disk Graph Medium) met afstandsverlies gebruikt, om zo interferentie in rekening te kunnen brengen ContikiMAC ContikiMAC[10] is een radio duty cycling MAC protocol, dat nodes toelaat om te communiceren, en toch voor het grootste deel van de tijd de radio uit te zetten. Het is geïnspireerd op bestaande duty cycling protocollen, zoals besproken werd in sectie De radio samplet periodisch het medium d.m.v. CCA s (Clear Channel Assessments), die heel vermogensefficiënt zijn. Indien er activiteit op het medium gedetecteerd wordt, zal de node de radio aangeschakeld houden voor de tijd nodig om het pakket te ontvangen. Zo wordt het merendeel van de verzendkost naar de zender verschoven. Dit principe wordt geïllustreerd in Figuur 2.3[10]. Door de vele optimalisaties die ingebouwd zijn in ContikiMAC, vertoont dit protocol een veel hogere energie-efficiëntie dan bijvoorbeeld X-MAC (Figuur 2.4[10]). Dit protocol wordt standaard gebruikt in Contiki 2.6. Figuur 2.3: ContikiMAC werking: De ontvanger samplet het medium periodisch d.m.v. CCA s, en blijft wakker indien een transmissie gedetecteerd wordt. Na het ontvangen van het volgend pakket verstuurt de ontvanger een link layer ACK. De zender verstuurt het pakket dus tot er een link layer ACK ontvangen wordt van de ontvanger.

19 2.3 Internet of things en het sensornetwerk 9 Figuur 2.4: Vergelijking Radio Duty Cycle (RDC) performantie van X-MAC en ContikiMAC i.f.v. de channel check rate (wake-up frequency). ContikiMAC vertoont een merkbaar lagere RDC voor elke wake-up frequency, en is dus ook energie-efficiënter Ripple routing protocol (RPL) De sterke opkomst van IP smart object networks heeft ook op het vlak van routing voor een heel aantal uitdagingen gezorgd. Deze netwerken (LLNs, Low power and Lossy Networks) zijn potentieel erg groot, vertonen vaak veel interferentie, de nodes zijn vaak weinig betrouwbaar en beperkt in energie,... Het IETF richtte daarom een taskforce op, ROLL (Routing over Low power and Lossy) Networks[27], die als doel had om een IPv6 gebaseerde routing oplossing te vinden voor LLNs. Het resultaat van deze taskforce is het Ripple routing protocol (RPL)[26]. RPL is een distance vector IPv6 routing protocol, geoptimaliseerd voor LLNs. Het construeert een gerichte graaf (DODAG, Destination Oriented Directed Acyclic Graph), op basis van enkele metrieken, zoals paden met de beste ETX (Expected Transmission Count) waarde, of beste latency met nog steeds een aanvaardbaar energieverbruik. Aangezien de intentie van RPL nauw aansluit bij het Internet of things, wordt dit protocol standaard ondersteund in Contiki 2.6 als ContikiRPL[28]. Een voorbeeld van een DAG in Contiki wordt getoond in Figuur 2.5. In dit protocol zijn er een aantal parameters die vooraf ingesteld worden. Zo wordt de ETX waarde berekend op basis van zowel huidige als vorige metingen van de linkkwaliteit. De precieze

20 2.3 Internet of things en het sensornetwerk 10 ratio tussen deze metingen hangt af van netwerk tot netwerk. Zo zal een ontwerper voor een netwerk met mobiele nodes minder rekening willen houden met vorige metingen. In statische netwerken kan het aangewezen zijn om net meer rekening te houden met vorige metingen. Zo kan een kortstondige interferentie op het ogenblik van de ETX meting leiden tot een slechte ETX, en het pad kan onterecht gedropt worden. Door het netwerk zelf te laten bepalen welke ratio er optimaal is op dat bepaald moment, dient de ontwerper dit niet zelf meer in te stellen. Ook kan het netwerk deze ratio nog aanpassen indien de omgeving verandert, zonder dat er manueel onderhoud aan te pas moet komen. Figuur 2.5: Een voorbeeld van een RPL netwerk in Contiki met 1 sink node (RPL root), en 24 andere nodes. De ETX waardes zijn in blauw vermeld bij elke link Constrained Application Protocol (CoAP) Aangezien we opteren voor een gecentraliseerd algoritme, hebben we een methode nodig om te interageren met de nodes. Meer bepaald willen we de parameters kunnen opvragen en wijzigen in nodes. Gezien de filosofie van het Internet of things, dient deze methode zo algemeen mogelijk te zijn.

21 2.4 Zelf-lerend Algoritme 11 Het Constrained Application Protocol (CoAP)[29] beantwoordt aan al deze specificaties. CoAP is een web transfer protocol, speciaal ontwikkeld voor LLNs. CoAP voorziet een method / response model tussen twee application end-points, met enkele belangrijke componenten zoals resource discovery, URIs (Uniform Resource Identifiers) en content types. Dit laat het protocol toe om gemakkelijk vertaald te worden naar HTTP, terwijl het nog steeds ontwikkeld is voor simpliciteit en lage overhead. Ook CoAP wordt ondersteund in Contiki 2.6[15]. Met behulp van CoAP zal het mogelijk worden om een getter / setter te schrijven voor beide parameters in het MAC- en routeringsprotocol, om zo een eenvoudig uitbreidbaar updatemechanisme te voorzien. Het gecentraliseerd algoritme kan dan gebruik maken van een CoAP client om de parameters op te vragen en te wijzigen. De volledige protocol stack bij het gebruik van CoAP wordt weergegeven in Figuur 2.6[15]. Figuur 2.6: De volledige protocol stack bij het gebruik van CoAP. 2.4 Zelf-lerend Algoritme Zoals eerder aangegeven in sectie 2.1, kiezen we hier voor een gecentraliseerd zelf-lerend algoritme. Hiervoor zijn er nog steeds enkele opties, die verder uiteengezet zullen worden. De vereistes voor dit algoritme zijn: een goede trade-off van huidige en toekomstige performantie, snel convergeren naar een (sub)optimale oplossing en model-vrije werking (geen vooropgesteld model van de omgeving vereist).

22 2.4 Zelf-lerend Algoritme Type artificiële intelligentie In het domein van machine learning is er al heel wat onderzoek gebeurd, en er bestaan vele methodes. Voorbeelden hiervan zijn Reinforcement Learning, Swarm Intelligence, genetisch geinspireerde algoritmes,... We kiezen hier voor Reinforcement Learning, aangezien er hiervoor efficiënte algoritmes bestaan die geen voorkennis vereisen van de omgeving, en die een goede trade-off kunnen maken tussen het leerproces en onmiddellijke efficiëntie Reinforcement Learning en Q-learning Reinforcement Learning is een verzamelterm voor biologisch geïnspireerde machine learning technieken, waarbij de kennis vergaard wordt door trial and error in de omgeving[13, 14]. Bij elke stap wordt er een bepaalde actie ondernomen, en worden de resulaten ervan op de omgeving bestudeerd. Door dit vele malen te herhalen, leert het algoritme uit ervaring welke acties optimaal zijn in de huidige omgeving. Hierbij dient het algoritme ook rekening te houden met de gevolgen van zijn keuzes op langere termijn. In deze methodes interageert een agent met een omgeving. Deze omgeving bestaat uit een discrete set van states S, een discrete set van acties A die bestaan uit state-overgangen a(s) naar alle mogelijke states s, en een scalaire reward function R(s, a). Deze functie geeft de reward weer vanuit de omgeving als reactie op de actie a die de agent genomen heeft in de state s. De policy π : S A van de agent wordt gedefinieerd als de actie die de agent zal ondernemen in de state s. Hierbij dient de agent een reward op lange termijn te maximaliseren. De policy die dit realiseert, noemen we de optimale policy π. Hierbij wordt overigens niet verondersteld dat eenzelfde actie ondernomen in eenzelfde state altijd leidt tot eenzelfde eindstate, of tot eenzelfde reward. We veronderstellen echter wel dat de probabiliteiten hierop constant blijven, m.a.w. dat de omgeving stationair is (de algoritmes werken echter wel in traag variërende niet-stationaire omgevingen, maar hier bestaat niet zoveel wiskundige achtergrond over[14]). Formeel kunnen we het probleem modelleren als een Markov beslissingsprobleem, dat bestaat uit[14]: een discrete set van states S een discrete set van acties A

23 2.4 Zelf-lerend Algoritme 13 een reward function R : S A R een state transition function T : S A Π(S), met Π(S) een probabiliteitsdistributie op de set van states S. Dit betekent dat T (s, a, s ) = P (s s, a) de probabiliteit is dat de actie a ondernomen in de state s leidt tot een transitie naar een nieuwe state s. Nu zijn er twee verschillende benaderingen om een optimale policy te bepalen. Er kan een model van de omgeving opgesteld worden, zodat de state transition function T (s, a, s ) en de reward function R(s, a) gekend zijn. Er bestaan echter ook technieken om een optimale policy te bepalen, zonder dat er een model gekend is op voorhand. Een van deze methodes is de zogenaamde Q-learning methode. Hierbij is de Q-functie Q (s, a) de verwachte totale gedisconteerde reward bij het nemen van actie a in state s, en waarbij vanaf dan de optimale policy π gevolgd wordt. Er kan aangetoond worden dat deze Q-functie als volgt geschreven kan worden (Bellman s equation)[21]: Q (s, a) = R(s, a) + γ s S T (s, a, s ) max a Q (s, a ) (2.1) De eerste term van Q (s, a) stelt de onmiddellijke reward voor, de tweede term is de gedisconteerde verwachte toekomstige reward, met disconteringsfactor γ. De optimale policy wordt dan gegeven door: π (s) = arg max a Q (s, a). De methodes in Q- learning zijn dan gericht op het accuraat schatten van deze Q waardes, waaruit we de optimale policy kunnen achterhalen. Om te vermijden dat het algoritme blijft kiezen voor een lokaal maximum, moeten we toelaten dat de agent nu en dan een mogelijk suboptimale actie onderneemt, zodat de ruimte van Q-waardes verkend wordt. Hiertoe gebruiken we een ɛ-greedy algoritme, waarbij de agent met een kans ɛ kiest voor een willekeurige actie, en met een kans 1 ɛ voor de actie met maximale Q-waarde. Deze factor ɛ noemen we ook de exploratiefactor Least Squares Policy Iteration (LSPI) Q-learning berekent dan deze Q-waardes deterministisch. Deze aanpak vertoont echter een aantal belangrijke nadelen in het geval van draadloze sensornetwerken. Een voorbeeld waar Q- learning toegepast werd op een routeringsprotocol (AdaR, Adaptive Routing[22]) toont enkele van deze nadelen aan:

24 2.4 Zelf-lerend Algoritme 14 Een groot aantal episodes moet doorlopen worden eer het algoritme convergeert naar de optimale oplossing. Hierdoor kunnen de kosten van het samplen van de omgeving (waarbij er suboptimale keuzes gemaakt worden) de baten van de optimale keuze overschrijden De prestatie van het algoritme is sterk afhankelijk van de initiële settings Het gebruiken van Q-learning kan leiden tot het breken van nodige convergentievoorwaarden voor het Markov beslissingsprobleem Om deze nadelen te omzeilen, maken we gebruik van de Least Squares Policy Iteration methode (LSPI)[17]. In deze methode wordt de Q-functie voor een gegeven policy π benaderd door een gewogen lineaire combinatie Q π van k basisfuncties, ook wel features genoemd: ˆQ π (s, a, w) = k φ i (s, a)w i = φ(s, a) T w (2.2) i=1 waarbij φ i (s, a) de i-de basisfunctie is, en w i haar gewicht in de approximatie. Deze k basisfuncties stellen dan de informatie voor die we bezitten over het state-action paar (s, a). De set van k basisfuncties φ i (s, a) die we kiezen is sterk afhankelijk van de doelstellingen in het netwerk, en moeten manueel opgesteld worden. Voorbeelden van deze features zijn: de residuele energie van een node, de packet delivery ratio, de totale afstand tot de sinks in aantal hops,... We kunnen dan vergelijking (2.1) herschrijven in matrixformaat, met behulp van de lineaire approximatie in vergelijking (2.2): Φw R + γp π Φw waarbij Φ een ( S A k) matrix is die de k basisfuncties bevat. Als we veronderstellen dat de kolommen van Φ lineair onafhankelijk zijn, dan bekomen we: Φ T (Φ γp π Φ)w π = Φ T R Dit betekent dat we de gewichten w van de lineaire approximaties ˆQ π (s, a) bekomen door het volgend lineair stelsel op te lossen: w = A 1 b waarbij A = Φ T (Φ γp π Φ) (2.3) b = Φ T R

25 2.4 Zelf-lerend Algoritme 15 Deze matrices A en b worden nu bekomen door samples (s, a, s, r) uit de omgeving te verzamelen, waarbij s de huidige state is, a de gekozen actie, s de nieuwe state, en r de resulterende reward. Als we een set D van L samples verzameld hebben, D = (s di, a di, s d i, r di i = 1, 2,..., L), dan kunnen we de matrices Φ, P π Φ en R als volgt bepalen: φ(s di, a di ) T ˆΦ = φ(s dl, a dl ) T φ(s d 1, π(s d 1 ) T P π Φ = φ(s d L, π(s d L ) T r d1 ˆR = r dl Het invullen van deze matrices Φ, P π Φ en R in het stelsel (2.3) levert dan de gewichten w op. LSPI is hier gepast omdat het algoritme sneller convergeert dan andere bekende algoritmes[17], omdat de samples heel nuttig gebruikt worden. Ook moeten er geen additionele parameters gezet worden, zoals een learning rate. De policy wordt geëvalueerd op basis van alle samples, en is dus insensitief t.o.v. beginsettings. Ook is de lineaire approximatie met basisfuncties hier heel geschikt, omdat we zo effectief een trade-off kunnen realiseren tussen verschillende doelen of features. De gewichten worden automatisch aangepast in het algoritme bij het verzamelen van nieuwe samples, zoals weergegeven in het stelsel (2.2).

26 ONTWERP EN IMPLEMENTATIE 16 Hoofdstuk 3 Ontwerp en implementatie 3.1 Opstelling basisscenario Inleiding In deze sectie wordt het basisscenario gecreëerd, onderdeel per onderdeel. Zoals eerder vermeld, dienen ContikiMAC en RPL gebruikt te worden in een scenario dat voldoende trafiek genereert om de performantie te beoordelen. De parameters dienen veranderbaar te zijn via CoAP, dit betekent dat elke node ook een CoAP server moet draaien. Informatie over de performantie van het netwerk dient ook beschikbaar te zijn voor de Negotiation Engine, het centraal draaiende LSPI algoritme. Deze Negotiation Engine zal worden gedraaid op een aparte server die in contact staat met de root van het RPL netwerk. Ook de communicatie tussen de Negotiation Engine enerzijds en het scenario anderzijds dient dus geïmplementeerd te worden. Ten slotte moet er aandacht besteed worden aan de algemeenheid van de oplossing, zodat het werk als basis kan dienen voor verdere verdieping en onderzoek. De uiteindelijke implementatie (met minder nodes, om het overzicht te bewaren) is te zien in Figuur 3.1. Deze figuur kan een handig overzicht geven bij dit hoofdstuk. UDP trafiek wordt gestuurd vanuit de udp-senders naar de udp-sink in het RPL netwerk. Informatie over de performantie van het netwerk wordt gestuurd vanuit de udp-sink naar de server waarop de Negotiation Engine draait. Ten slotte wordt CoAP gebruikt om de parameters in elke node op te vragen en te wijzigen.

27 3.1 Opstelling basisscenario 17 Figuur 3.1: Een overzicht van het basisscenario dat we zullen opstellen Parameter getter-setters Vooreerst kijken we naar de specifieke parameters die we initieel willen afstellen. Deze beinvloeden het slaapritme van ContikiMAC (zie ook sectie 2.3.3), en de ratio tussen nieuwe en oude metingen bij het berekenen van de ETX (Expected Transmission Count) waarde van RPL (sectie 2.3.4). Zoals aangeduid in Figuur 2.4[10], heeft de wake-up frequency (channel check rate) een grote invloed op de radio duty cycle, en dus ook op het energieverbruik en de performantie. Deze parameter kan geset worden in een scenario (voor alle nodes die deel uitmaken van dat scenario) m.b.v. de volgende lijn code: #define NETSTACK RDC CHANNEL CHECK RATE 8 Hiermee wordt de wake-up frequency op 8Hz gedefinieerd bij wijze van voorbeeld, zoals we kunnen afleiden uit de volgende lijn code in contikimac.c: #define CYCLE TIME (RTIMER ARCH SECOND / NETSTACK RDC CHANNEL CHECK RATE) Uiteraard willen we dit niet statisch definiëren voor alle nodes, maar kunnen opvragen en wijzigen per node afzonderlijk. Hiertoe wijzigen we de broncode voor het ContikiMAC protocol (/core/ net/mac/contikimac.c en /core/net/mac/contikimac.h). Meer bepaald wordt er een gettersetter gedefinieerd in contikimac.h: // Getter and S e t t e r f o r NETSTACK RDC CHANNEL CHECK RATE int NETSTACK RDC CHANNEL CHECK RATE2

28 3.1 Opstelling basisscenario 18 = NETSTACK RDC CHANNEL CHECK RATE; int getchannel CHECK RATE( ) { return NETSTACK RDC CHANNEL CHECK RATE2; } void setchannel CHECK RATE( int x ) { NETSTACK RDC CHANNEL CHECK RATE2 = x ; } Waarbij ook alle instanties van deze wake-up frequency in contikimac.c aangepast worden. Dit laat ons toe om de frequentie aan te passen at runtime, in elke node. De beginwaarde wordt nog steeds globaal gedefinieerd. We zullen als mogelijke wake-up frequencies 8Hz en 16Hz nemen. Voor het RPL protocol willen we de parameter aanpassen die de ratio bepaalt tussen de huidige waarde van de linkkwaliteit en vorige waardes. Deze waardes worden berekend in de broncode die het bijhouden van informatie van de buren regelt voor RPL: /core/net/neighbor-info.c: / Update the EWMA o f the ETX f o r the neighbor. / new metric = ( ( u i n t 1 6 t ) r e c o r d e d m e t r i c ETX ALPHA + ( u i n t 1 6 t ) p a c k e t m e t r i c (ETX SCALE ETX ALPHA) ) / ETX SCALE; Hierbij is ETX SCALE gedefinieerd op 100. Opnieuw definiëren we een eenvoudige gettersetter voor deze ETX ALPHA waarde. Deze getter-setter implementeren we in de broncode /core/net/neighbor-info.c: // Getter and S e t t e r f o r ETX ALPHA int ETX ALPHA2 = ETX ALPHA; int getetx ALPHA ( ) { return ETX ALPHA2; } void setetx ALPHA( int x ) { ETX ALPHA2 = x ;

29 3.1 Opstelling basisscenario 19 } Ook passen we elke instantie van ETX ALPHA aan naar ETX ALPHA2 in de broncode. Standaard krijgt deze parameter de waarde 90, m.b.v. de getter-setter kunnen we deze waarde laten variëren in het bereik [0,100]. We zullen als mogelijke waardes voor ETX ALPHA 90 en 65 nemen. We verwachten dat de waarde 65 betere prestaties zal voorleggen indien de nodes mobiel zijn, aangezien het pad sneller opnieuw gevormd kan worden Erbium CoAP Server Om de getter-setters extern op te roepen, dienen we een CoAP server te implementeren op elke node. De algemeenheid van CoAP laat ons toe om bv. een HTTP GET request te sturen naar een specifieke node (a.d.h.v. het IPv6 adres). De border router zou deze HTTP request dan kunnen vertalen naar een CoAP request, waarna deze behandeld kan worden in de node. De node genereert een CoAP response, die in de border router weer vertaald kan worden naar een HTTP response. Deze vertaling wordt ook beschreven in de CoAP drafts[29]. In deze implementatie werken we met een CoAP client (zie sectie 3.2.5). CoAP wordt in Contiki ondersteund met de Erbium (Er) REST engine[15], die de CoAP draft specificatie implementeert (versie 07)[29]. Dit laat ons toe om heel eenvoudig een getter-setter server te implementeren op elke node. Hiertoe vertrekken we van een voorbeeldscenario dat geïncludeerd is in de broncode: /examples/er-rest-example/. Dit bevat o.a. de broncode (er-example-server.c) voor een node die een Er server draait, met een aantal mogelijke resources (zoals een helloworld, leds toggle,... ). We implementeren twee extra resources, die ons toelaten om beide parameters op te vragen en te wijzigen. De resource die de getter-setter van ETX ALPHA afhandelt, wordt als volgt gedefinieerd: RESOURCE(ETX, METHOD GET METHOD POST METHOD PUT, params/etx ALPHA, t i t l e =\ ETX ALPHA value get or s e t \ ; r t =\ Text \ ) ; Hiermee wordt een resource ETX gecreëerd, die de zowel GET, POST als PUT requests behandelt. Het URI pad is params/etx ALPHA. In de handler voor deze resource dienen we nu onderscheid te maken tussen een GET en een PUT/POST request, om respectievelijk de getter of setter op te roepen. Hiervoor gebruiken we de method code[29] van de request, zie ook Tabel 3.1. Voor specifieke details van de handler verwijzen we naar de geïncludeerde broncode.

30 3.1 Opstelling basisscenario 20 We definiëren een analoge resource voor de wake-up frequency. We kunnen ook gemakkelijk nieuwe resources implementeren voor nieuwe parameters, indien de correcte getters en setters gedefinieerd zijn in de broncode van de betrokken protocollen (zie sectie 3.1.2). Code Methode 1 GET 2 POST 3 PUT 4 DELETE Tabel 3.1: Method codes en de corresponderende methode[29] Het serverproces dat de CoAP requests verwerkt en de ACKs of responses terugstuurt, kan dan gestart worden samen met andere processen (die bv. de reguliere trafiek zullen genereren) Basisscenario: rpl-collect De vereisten voor het scenario zijn: gebruik van IPv6, ContikiMAC, RPL en CoAP, een border router, regelmatige trafiek en een manier om de performantie te meten. Een van de voorbeelden in de broncode implementeert vele van deze functies: /examples/ipv6/rpl-collect/. Het basisscenario bestaat uit een RPL DAG met 1 udp-sink als root node en 24 udp-senders als leaf nodes (zie ook Figuur 2.5), waarbij de udp-senders periodisch UDP pakketten versturen naar de sink. Deze pakketten bevatten nuttige data, waarmee statistieken opgemaakt worden over het netwerk in een aparte Java applicatie, CollectView. Twee van deze statistieken kunnen we direct gebruiken als performantie-maatstaven voor elke node: het geschatte aantal verloren pakketten en de RDC. Een voorbeeld van de grafiek met RDC waardes is te zien in Figuur 3.2. We kunnen deze informatie in eerste instantie uitprinten vanuit CollectView naar tekstbestanden, en terug uitlezen bij het verzamelen van de meetgegevens. Ook kan de berekening rechtstreeks gemaakt worden, door de meetgegevens bij ontvangst van een UDP pakket te forwarden via de border router naar de Negotiation Engine. Omdat een schatting van het aantal verloren pakketten eenvoudig af te leiden valt uit de sequence numbers die meegegeven worden in de pakketten, zullen we deze statistiek zelf berekenen. De sink stuurt