Performatie van RPL met meerdere sinks in draadloze sensornetwerken

Performatie van RPL met meerdere sinks in draadloze sensornetwerken Niels Derdaele

Promotoren: prof. dr. ir. Ingrid Moerman, dr. ir. Eli De Poorter Begeleider: David Carels Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2012-2013

Performatie van RPL met meerdere sinks in draadloze sensornetwerken Niels Derdaele

Promotoren: prof. dr. ir. Ingrid Moerman, dr. ir. Eli De Poorter Begeleider: David Carels Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2012-2013

Voorwoord In de eerste plaats zou ik graag mijn promotor professor Moerman bedanken voor de mogelijkheid om deze thesis uit te kunnen voeren. Ook mijn co-promotor Eli De Poorter en begeleider David Carels wil ik bedanken voor hun constante feedback en motivatie tijdens het academiejaar en bij wie ik steeds terecht kon met vragen en problemen.

Mijn familie, en in het bijzonder mijn ouders, wil ik bedanken om mij de kans te geven deze studies te volgen en voor hun steun om ze tot een goed einde te brengen.

Verder wil ik mijn vrienden bedanken die van deze periode een fantastische ervaring hebben gemaakt. Zonder hun steun, feedback en de nodige ontspanning was deze periode ongetwijfeld een stuk moeilijker geweest.

Tot slot wil ik mijn vriendin Joke, die ik dankzij deze studies heb leren kennen, bedanken. Haar steun en luisterend oor heeft er zonder twijfel mede voor gezorgd dat deze thesis tot een goed einde gebracht kon worden.

Niels Derdaele, juni 2013

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

Niels Derdaele, juni 2013

Performatie van RPL met meerdere sinks in draadloze sensornetwerken door Niels DERDAELE Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: Computerwetenschappen Academiejaar 2012–2013 Promotoren: prof. dr. ir. I. MOERMAN, dr. ir. E. DE POORTER Begeleider: D. CARELS Faculteit Ingenieurswetenschappen en Architectuur Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. D. DE ZUTTER

Samenvatting In draadloze sensornetwerken zal de informatie typisch verzamelt worden door één sensor node, de sink. Wanneer gebruik gemaakt wordt van multi-hop routering en het gemiddeld aantal hops tot de sink hoog is kan dit negatieve gevolgen hebben voor het energieverbruik, de kans op pakketverlies, de latency, ... Men zou daarom kunnen opteren om het netwerk uit te breiden met extra sinks. Indien goed gepositioneerd, kunnen deze extra sinks ervoor zorgen dat het gemiddeld aantal hops tot de dichtstbijzijnde sink sterk daalt. Deze reductie van het gemiddeld aantal hops zal zorgen voor een betere performantie (minder energieverbruik, minder pakketverlies, lagere latency, ...) van het draadloos sensornetwerk. In deze thesis zal ondersteuning voor meerdere sinks toegevoegd worden aan het IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL). De correcte werking van de implementatie werd zowel getest in een simulatie omgeving als op een real-life testbed (iMinds w-iLab.t). Hierbij werden ook performantietesten uitgevoerd om het voordeel van het gebruik van meerdere sinks in draadloze sensornetwerken aan te tonen. Tot slot werd ook een basisondersteuning voor mobiliteit toegevoegd aan RPL. Aan de hand van simulatietesten werd nagegaan welke extra voordelen het gebruik van meerdere sinks biedt aan draadloze sensornetwerken waar mobiele nodes aanwezig zijn en waar RPL routering gebruikt wordt.

Trefwoorden RPL, meerdere sinks, mobiliteit, performantie

Performance of RPL using multiple sinks in wireless sensor networks Niels Derdaele Supervisor(s): prof. dr. ir. I. Moerman, dr. ir. E. De Poorter, D. Carels Abstract—Data acquisition in wireless sensor networks consisting of only a single sink will typically lead to scalability issues. A solution to this problem is the deployment of multiple sinks in the network. Due to the lack of support for multiple sinks in IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) such an approach is not possible in sensor networks using this routing protocol. In this thesis support was added for the deployment of multiple sinks in wireless sensor networks using RPL. The correct behaviour of the implementation was verified, by the use of performance tests, in both a simulation environment and a real-life testbed (iMinds w-iLab.t office testbed). The advantages of using multiple sinks in wireless sensor networks where mobile nodes are present was also investigated. Since support for mobile nodes is also lacking in RPL some basic mobility support was added to it. Keywords—RPL, multiple sinks, performance, mobility

I. I NTRODUCTION N wireless sensor networks (WSNs) there will typically be one sensor node, referred to as the sink, responsible for collecting the data from a number of data sources. As the size of the network grows the average number of hops between the data sources and the sink will become larger. This will most likely introduce more packet loss, a higher energy consumption and thus a decrease in the lifetime of the sensor nodes. A solution to this problem is to deploy multiple sinks in a wireless sensor network. To increase the performance of the wireless sensor network (in terms of packet loss, lifetime, ...) each sensor node communicates only with the closest sink. If the sinks are spread over different locations this will result in a reduction of the average number of hops (and thus an increase in performance).

I

II. RPL A. Overview IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [3] is a proactive, distance-vector routing protocol specifically designed for Low power and Lossy Networks (LLN). Some characteristics of LLNs are: high bit error rates, low bandwidth and instability. RPL forms a tree-like topology, called a Destination-Oriented Directed Acyclic Graph (DODAG). Directed Acyclic Graphs (DAG) have the property that all edges are oriented in such a way that no cycles exist. If all edges are contained in paths oriented towards a single node the DAG is called Destination-Oriented Since different applications have different needs RPL only specifies how to build a DODAG. The characteristics of the DODAG (eg. how a parent is chosen) are specified by an objective function. B. Objective Function The objective function defines how RPL selects and optimizes routes. In order to make a decision on which path is best, an objective function will use metrics and/or constraints.

A link metric that is often used is the Expected Transmission Count (ETX). The ETX value of a link is the expected number of transmissions that is required to successfully send a packet over that link. C. Topology Formation The DODAG is built using DODAG Information Object (DIO) messages (ICMPv6 messages defined in RPL). These messages are sent periodically (based on the stability) by RPL nodes to advertise a DODAG and its characteristics. Based on the rank of a RPL node (relative position in the DODAG) and its metric value a decision is made by the objective function whether or not to use the node as preferred parent. Since sending DIO messages will result in choosing a preferred parent, upwards traffic is possible. To enable downwards traffic an RPL node sends a Destination Advertisement Object (DAO) message (also an ICMPv6 message) to its preferred parent to advertise prefix reachability towards the leaves. Since the period between two DIO messages can become very large in stable networks, it’s also possible for a node to solicit for DIO messages by sending link-local multicast DODAG Information Solicitation (DIS) messages. III. M ULTI - SINK SUPPORT A. Virtual sink To support multiple sinks the concept of a virtual sink node is used (see figure 1). This means that the actual sinks will behave as if they were a single sink. In order for this to work there is a need for communication between the actual sinks (to sync their parameters, routing tables, ...). Since this communication is crucial, a wired network is used instead of the wireless medium. Virtual Sink Sink 2

Sink 1 1 4

2 3

6

5

Fig. 1. Example of a DODAG with two real sinks and one virtual sink

B. Communication between sinks using Serial Line IP In the implementation Serial Line IP is used for the communication between the sink and the device it is connected to (eg. an embedded pc). For the communication between the devices (here embedded PCs) any reliable network can be used (eg. Ethernet). The sinks do not communicate with each other directly but with a central application called the registrar. It’s the task of

the registrar to make sure the parameters (eg. the rank) of the different sinks are the same at all times in order to make them behave as being a single entity. Registrar Ethernet Serial Line IP

Sink 1

Ethernet Serial Line IP

Sink 2

Fig. 2. Example setup where the sinks are connected to embedded PCs with a serial line and where the embedded PCs communicate with each other using Ethernet

C. Anycast addressing Since the sensor nodes are not aware of the existence of multiple sinks they will send their information to the virtual sink. It’s the task of the different sinks to intercept this information and handle it themselves (as the virtual sink doesn’t physically exist). An easy solution for this is to assign an identical anycast address to all the sinks and use this as the address of the virtual sink. When a sensor node wants to contact the virtual sink it will use this anycast address which will make sure that one of the different sinks will process the data. IV. M OBILITY SUPPORT Since RPL does not support mobile nodes some changes to RPL where required, which will now be discussed. A. Immediate DIO When a mobile node is interested in new topology information it can send a DIS message to solicit for DIO messages from the nodes in its environment. By polling the environment regularly it’s possible for a mobile node to have up to date information concerning its surroundings. There is however a problem using this mechanism to poll the environment. In RPL the sending of DIO messages are regulated by a timer [1]. When a node receives a DIS message it will not immediately respond with a DIO message but instead it will reset its timer to the minimum allowed value and respond once the timer has expired. Since the default value for the minimum period is typically several seconds chances are that in this period new nodes are in the range of the mobile node, who will not send a DIO since they haven’t received a DIS. To avoid this problem a change was made to RPL such that DIO messages are immediately send upon receiving a DIS message (this change was also discussed in [2]).

energy consumption) as the fixed node will forward messages to a mobile node that is no longer in its range. To prevent a node from choosing a mobile node as parent, the mobile node will set its rank to infinite when sending a DIO message (it’s not allowed in RPL to choose a parent that has a higher rank than yourself) C. Changes to the objective function For mobile nodes packet loss can be an indication that the preferred parent is no longer in the range of the node. A new parameter called MAX LOST is introduced and specifies after how many successive lost packets the preferred parent is labelled as “out of range”. A node that is “out of range” can never be selected as the preferred parent (constraint). The only way this label (out of range) can be removed is by receiving a new DIO message from the node. Another indication is the last time we heard from a node. When we poll the environment each 10 seconds and we haven’t heard from some nodes (received a DIO) for over a minute we can most likely say that they are no longer in range. A variable MAX LAST HEARD SEC was added and specifies after how many seconds we label a node as “out of range”. V. R ESULTS To determine the advantages of using multiple sinks in a wireless sensor network some tests where performed in simulation and on iMinds w-iLab.t, a real-life testbed. A. The performance test All sensor nodes (except the sinks) run an application that periodically (each 50-70 seconds) sends a data packet to the closest sink. The data packet has an id (to determine the number of lost packets) and contains information about the node (rank, energy consumption, preferred parent, etx value to the preferred parent, ...). The information in the data packet makes it possible to determine the average energy consumption, the structure of the DODAG, the average number of hops, ... B. Simulation In the simulation setup 30 nodes where evenly placed (20 meter between two nodes) in a grid structure as shown in figure 3. At each side of the grid structure a sink was placed (thus four in total). The tranmission range of the nodes is 25m and the interference range is 35m. The links between two nodes have about 40-50% packet loss. The MAC protocol is allowed to sent a packet a second time in case no ACK was received the first time.

B. Mobile nodes are always leafs Without changes to RPL it would be possible for a fixed node to select the mobile node as its preferred parent once it comes in its range. Since the fixed nodes will not actively poll their environment they will not be aware of when the mobile node leaves their range. This could result in high packet losses (and a higher

Fig. 3. Simulation setup: nodes 2, 3, 4 and 5 are sinks

30%

Packets Lost(%)

20%

3

2 10% 1

0%

0 1

2

3

4

Number of sinks

3

40%

2

20%

1 0

0%

1

Fig. 4. Packet loss (bars) and average number of hops (line) in function of the number of sinks

# sinks

Avg. Energy (mW)

8 6 4

2,356

2

1,558

0 1

Avg. energy (mW)

2,5 2 1,5

1,418

1,262

1,095

1

0,958

0,5 0

1

2

Number of sinks

3

4

Fig. 5. Average energy consumption in function of the number of sinks (maximum and minimum energy consumption represented by the error bars)

C. Experimental: iMinds w-iLab.t office testbed The same tests, although on a different topology, as in simulation where run on a real-life testbed. As can be seen from the charts in figures 6 and 7 also here both the packet loss and energy consumption decreases as the number of sinks increases from one to two. The same conclusion, as those from the simulation test, apply here. D. Multi-sink and mobility In a last set of (simulation) tests the advantages of using multiple sinks in sensor networks with mobile nodes is determined.

# sinks 2

3

Fig. 7. Average energy consumption in function of the number of sinks (maximum and minimum energy consumption represented by the error bars)

The setup exists of a sensor network with 19 nodes, of which one is mobile and two sinks placed on different physical locations. The mobile node moves in along the nodes in the network. To limit the energy consumption the mobile nodes poll their environment each 10 seconds. In table I the results of the test can be found.

B.2 Energy consumption Just like the packet loss, also the average (and the maximum) energy consumption decreases as the number of sinks increases (see figure 5). This is also the result of the reduction in average number of hops because each node is now positioned closer to the sink. The reduction in maximum energy is in actually more important than the average energy consumption as this will increase the lifetime of the network.

2

Fig. 6. Packet loss (bars) and average number of hops (line) in function of the number of sinks

0

Average # of hops

4

4

60%

Average #hops

A (near) linear relationship between the average number of hops and the average packet loss is noticeable in the chart (figure 4). This was to be expected as each hop that needs to be taken will increase the chances of packet loss. Since the sinks are placed at four completely different positions collisions are less likely to happen when all four are activated. When using only one sink, all the data will flow in the same direction (eg. towards the top of the network), this will increase the chances of packet loss due to collision. By adding more sinks the data will flow in different directions and the chances of packet collision will be reduced. This is another reason to why the packet loss decreases as the number of sinks increases.

Packets Lost (%)

80%

B.1 Packet Loss

Packet loss Average energy consumption Average ETX preferred parent

one sink 19,61% 1,64mW 2,56

two sinks 11,76% 1,24mW 2,03

difference -40% -24,4% -20,7%

TABLE I R ESULTS OF THE MOBILITY TEST

Without making any changes to the parameters (polling period, loss ratio’s, ...) the addition of an extra sinks seems to decrease the packet loss significantly. This can be explained by having a look at how the mobile node chooses its preferred parent. The mobile node will always try to choose the node that is closest to the sink as preferred parent. However when the node moves away from the sink, it will choose parents in the opposite direction. Adding an additional sink to the network will make it more likely that the mobile node will move towards a sink and thus choose the parents in the same direction as his movement. This will result in lower packet loss as a new parent will be chosen before the current one is out of range. VI. C ONCLUSION The implementation of multiple sinks using the concept of a virtual sink allows for an easy deployment of additional sinks without having to changes how the non-sink nodes operate. The results show that the implementation works as expected and gives an idea about the performance gain that can be achieved by using multiple sinks in a wireless network (with mobile nodes). Depending on the characteristics of the network and the position of the sinks high performance gains can

be achieved when adding additional sinks to a wireless sensor network. ACKNOWLEDGMENTS I would like to thank prof. dr. ir. I. Moerman for the opportunity of conducting this research, and dr. ir. E. De Poorter and ir. D. Carels for their support and valuable feedback. R EFERENCES [1] P. Levis, T. Clausen, J. Hui, O. Gnawali, and J. Ko, “The trickle algorithm,” RFC 6206 (Proposed Standard), Mar. 2011. [2] Kevin C. Lee, Raghuram Sudhaakar, Jianxia Ning, Lillian Dai, Sateesh Addepalli, J. P. Vasseur, and Mario Gerla, “A comprehensive evaluation of rpl under mobility,” International Journal of Vehicular Technology, vol. 2012, 2012. [3] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander, “Rpl: Ipv6 routing protocol for low-power and lossy networks,” RFC 6550 (Proposed Standard), Mar. 2012.

LIJST VAN AFKORTINGEN

Lijst van afkortingen DAO Destination Advertisement Object. DIO DODAG Information Object. DIS DODAG Information Solicitation. DODAG Destination Oriented Directed Acyclic Graph. ETX Expected Transmission Count. LLN Low-power and Lossy Network. OF Objectief Functie. RPL IPv6 Routing Protocol for Low power and Lossy Networks. SLIP Serial Line IP. UDGM Unit Disk Graph Model.

i

INHOUDSOPGAVE

ii

Inhoudsopgave Lijst van afkortingen

i

1 Introductie

1

1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.3

Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2 Literatuurstudie 2.1

Draadloze sensornetwerken

5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.3

Routeringsprotocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Contiki OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.3

Meerdere sinks in draadloze sensornetwerken . . . . . . . . . . . . . . . . . . . .

11

3 IPv6 Routing Protocol for Low power and Lossy Networks

15

3.1

Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.2

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.3

Routeringssmetrieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.4

De objectief functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.5

RPL berichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.5.1

DODAG Information Object (DIO) . . . . . . . . . . . . . . . . . . . . .

19

3.5.2

Destination Advertisement Object (DAO) . . . . . . . . . . . . . . . . . .

19

3.5.3

DODAG Information Solicitation (DIS) . . . . . . . . . . . . . . . . . . .

20

Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.6.1

20

3.6

Rank van een node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INHOUDSOPGAVE

iii

3.6.2

Opbouw van de DODAG . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.6.3

Routeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.6.4

Herstelmechanismes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

Trickle timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.7.1

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.7.2

Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.8

Mobiliteit in RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.9

ContikiRPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.9.1

Aanwezige objectief functies . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.9.2

Expected Transmission Count . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.7

4 Concept voor ondersteuning voor meerdere sinks in ContikiRPL

34

4.1

Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.2

Ondersteunen van meerdere sinks in ContikiRPL . . . . . . . . . . . . . . . . . .

34

4.3

Routering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.3.1

Multipoint-to-point verkeer . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.3.2

Point-to-multipoint verkeer . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.3.3

Point-to-point verkeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5 Implementatie van de ondersteuning voor meerdere sinks 5.1

5.2

5.3

41

De virtuele sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.1.1

Anycast adressering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.1.2

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

Communicatie tussen de sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.2.1

Gecentraliseerd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.2.2

Serial Line IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.2.3

Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.2.4

Tunslip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.2.5

De communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

Aanpassingen aan ContikiRPL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.3.1

Initiële ETX waarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.3.2

Maximaal toegestane kost van een link . . . . . . . . . . . . . . . . . . . .

51

INHOUDSOPGAVE

iv

6 Performantie bij het gebruik van meerdere sinks

52

6.1

Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.2

Test applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.3

Gebruikte tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6.3.1

Collect-view applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6.3.2

COOJA simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

Simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6.4.1

Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6.4.2

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

Real-life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.5.1

Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.5.2

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

6.4

6.5

6.6

7 Mobiliteit en meerdere sinks

74

7.1

Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

7.2

Ondersteuning voor mobiliteit in ContikiRPL . . . . . . . . . . . . . . . . . . . .

74

7.3

Opstelling en Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

7.3.1

Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

7.3.2

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

7.4

Tracking van fietsen d.m.v. draadloze sensornetwerken . . . . . . . . . . . . . . .

82

7.5

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

8 Besluit

86

A Debugging Cooja simulation using GDB-MSP430 and Eclipse

87

Bibliografie

90

LIJST VAN FIGUREN

v

Lijst van figuren 1.1

Aantal geconnecteerde toestellen aan het internet [16] . . . . . . . . . . . . . . .

1

1.2

Netwerk voorzien van één sink tegenover netwerk voorzien van twee sinks . . . .

3

2.1

Enkele voorbeelden van sensor nodes [28] [35] [47] . . . . . . . . . . . . . . . . . .

5

2.2

Voorbeeld van een draadloos sensornetwerk die wordt ingezet om de activiteit van een vulkaan te meten [44] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3

De Tmote Sky [38] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.4

Hiërarchische routering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.5

Voorbeeld van een DODAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.6

Architectuur van Contiki besturingssysteem [17]

. . . . . . . . . . . . . . . . . .

10

2.7

Threading in Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.8

Een draadloos sensornetwerk bestaande uit drie clusters/sinks [32] . . . . . . . .

12

2.9

Resultaten uit [27]: gemiddeld energieverbruik en gemiddeld aantal hops in functie van het aantal sinks (de verschillende lijnen komen overeen met het gebruikte positioneringsalgoritme) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.10 Resultaten uit [32]: aantal nodes die door hun energievoorraad zitten (links) en aantal nodes die niet langer de sink kunnen contacteren (rechts) in functie van de tijd (en uitgevoerd met een verschillend aantal sinks) . . . . . . . . . . . . . . . .

13

3.1

Distace-vector vs. Link-state . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.2

DIO bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3

DAO bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.4

DIS bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.5

Node 4 kiest een node met lagere rank als ouder . . . . . . . . . . . . . . . . . .

21

3.6

Node 4 kiest een node met hogere rank als ouder . . . . . . . . . . . . . . . . . .

21

LIJST VAN FIGUREN

vi

3.7

Fysieke topologie van een netwerk . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.8

DIO bericht wordt verstuurd door de DODAG root . . . . . . . . . . . . . . . . .

22

3.9

DODAG na stap 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.10 DODAG na stap 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.11 Bekomen DODAG eens alle nodes zijn toegevoegd . . . . . . . . . . . . . . . . .

24

3.12 Multipoint-to-Point verkeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.13 Point-to-Multipoint verkeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.14 Point-to-Point verkeer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.1

Voorbeeld van een DODAG met een virtuele sink . . . . . . . . . . . . . . . . . .

35

4.2

Virtuele sink DODAG uit standpunt van niet-sink nodes . . . . . . . . . . . . . .

35

4.3

Sinks hebben enkel kennis van de sensoren in hun eigen deelboom . . . . . . . . .

37

4.4

Sensoren in andere deelboom contacteren door data te forwarden naar de correcte sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.5

Sensoren in andere deelboom contacteren door data te forwarden naar alle sinks

39

4.6

Sensoren in andere deelboom contacteren door data te forwarden naar een centrale eenheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.7

Point-to-point verbindingen in multisink netwerk . . . . . . . . . . . . . . . . . .

40

5.1

Anycast adressering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.2


44

5.3


45

5.4

Communicatie tijdens het opstarten van een sink . . . . . . . . . . . . . . . . . .

46

5.5

Communicatie voor het uitvoeren van een global repair . . . . . . . . . . . . . . .

47

5.6

Topologie opbouw met een initiële ETX waarde van 5 . . . . . . . . . . . . . . .

48

5.7

Topologie opbouw met een initiële ETX waarde van 1 . . . . . . . . . . . . . . .

50

6.1

Screenshot van de collect-view applicatie . . . . . . . . . . . . . . . . . . . . . . .

53

6.2

Collect-view: DODAG op fysieke topologie . . . . . . . . . . . . . . . . . . . . .

54

6.3

Unit Disk Graph Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.4

COOJA opstelling: gridstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.5

Verdeling van de nodes in functie van het aantal hops dat ze verwijderd zijn van de sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

LIJST VAN FIGUREN

6.6

vii

Percentage van pakketten dat verloren gaat in functie van het aantal hops dat moet genomen worden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.7

Gemiddeld energieverbruik in functie van de afstand tot de sink (aantal hops) (ontvangstratio=100%) (lineaire trendlijn) . . . . . . . . . . . . . . . . . . . . . .

6.8

58

59

Gemiddeld energieverbruik in functie van de afstand tot de sink (aantal hops) (ontvangstratio=50%)(lineaire trendlijn) . . . . . . . . . . . . . . . . . . . . . . .

60

DODAG bij gebruik van één sink . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.10 DODAG bij gebruik van vier sinks . . . . . . . . . . . . . . . . . . . . . . . . . .

62

6.11 Gemiddeld aantal hops in functie van aantal sinks . . . . . . . . . . . . . . . . .

63

6.12 Pakketverlies in functie van aantal sinks . . . . . . . . . . . . . . . . . . . . . . .

64

6.13 Pakketverlies en gemiddeld aantal hops in functie van aantal sinks . . . . . . . .

64

6.14 Energieverbruik in functie van aantal sinks

65

6.9

. . . . . . . . . . . . . . . . . . . . .

6.15 Opstelling real-life testen: communicatie tussen de sinks en de registrar d.m.v. SLIP en IP tunnels, en tussen de collector en de collect-view applicatie (draait op machine buiten het zuiderpoort netwerk) via een “VPN tunnel”.

. . . . . . .

66

6.16 Topologie real-life testen: nodes 89 en 57 zijn respectievelijk sink 1 en 2, de overige aangeduide nodes zijn allemaal zenders (18 nodes in totaal) . . . . . . . . . . . .

67

6.17 Percentage van pakketten dat verloren gaat in functie van het aantal hops dat moet genomen worden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

6.18 Gemiddeld energieverbruik in functie van de afstand tot de sink (aantal hops) . .

69

6.19 Gemiddeld ETX waarde van de voorkeursouder(s) (van een bepaalde node) in functie van de afstand tot de sink (aantal hops) . . . . . . . . . . . . . . . . . . .

70

6.20 Gemiddeld aantal hops in functie van aantal sinks . . . . . . . . . . . . . . . . .

71

6.21 Pakketverlies in functie van aantal sinks . . . . . . . . . . . . . . . . . . . . . . .

71

6.22 Pakketverlies en gemiddeld aantal hops in functie van aantal sinks . . . . . . . .

72

6.23 Energieverbruik in functie van aantal sinks

. . . . . . . . . . . . . . . . . . . . .

73

7.1

Mobiele node stuurt DIS op t1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

7.2

Mobiele node ontvangt DIO pas op t2 . . . . . . . . . . . . . . . . . . . . . . . .

76

7.3

Node 3 kiest mobiele node als voorkeursouder . . . . . . . . . . . . . . . . . . . .

77

7.4

Opstelling mobiliteitstest: nodes 2 en 3 (aangeduid met cirkel) zijn sinks, node 7 is een mobiele node, node 1 (volledig zwarte node onderaan) is de registrar. De afstand tussen de gridlijnen die weergegeven zijn op de figuur bedraagt 10m.

. .

79

LIJST VAN FIGUREN

7.5

Pad gevolgd door de mobiele node . . . . . . . . . . . . . . . . . . . . . . . . . .

7.6

Schematische voorstelling van de communicatie tussen de mobiele node en de

7.7

viii

80

databank server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

Screenshot van de webapplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

INTRODUCTIE

1

Hoofdstuk 1

Introductie De laatste jaren is het aantal toestellen dat met het internet connecteert spectaculair toegenomen. Sinds enkele jaren zijn er zelfs meer toestellen geconnecteerd met op het internet dan er mensen rondlopen op de aardbol. De trend lijkt ook niet te stoppen, zo zouden er tegen 2020 maar liefst 50 miljard toestellen aangesloten zijn op het internet (zie figuur 1.1). De reden van deze spectaculaire stijging is voornamelijk te wijten aan de opkomst van nanotechnologie en daarmee de sensor nodes.

Figuur 1.1: Aantal geconnecteerde toestellen aan het internet [16] Sensor nodes zijn kleine elektronische toestellen die in staat zijn informatie uit hun omgeving te registreren (denk hierbij aan zaken zoals temperatuur, luchtvochtigheid, ...). Een verzameling van sensor nodes die onderling met elkaar communiceren worden ook wel sensornetwerken genoemd. Deze sensornetwerken worden steeds vaker aangesloten op het internet om zo de informatie eenvoudig toegankelijk te maken. Omdat er ondertussen steeds meer autonome toestellen

1.1 Probleemstelling

2

(zoals o.a. deze sensor nodes) met het internet geconnecteerd zijn wordt er ook wel over “the Internet of Things (IoT)” [16] gesproken.

Vroeger communiceerden sensor nodes typisch over bekabelde netwerken, ondertussen heeft de opkomst van de steeds energiezuinigere radio’s ervoor gezorgd dat we een nieuw type van sensornetwerken zien opkomen: de zogenaamde draadloze sensornetwerken (Wireless Sensor Networks). In deze netwerken zullen de sensoren niet langer onderling communiceren over een bekabeld netwerk maar over het draadloos medium. De opkomst van deze draadloze sensornetwerken brengt veel nieuwe mogelijkheden met zich mee, waar het vroeger bijna onmogelijk kon zijn om op een snelle en eenvoudige manier afgelegen gebieden te monitoren door middel van sensoren is dit nu dankzij de opkomst draadloze sensornetwerken verre van onmogelijk. Het monitoren van ruimtes in historische gebouwen kon vroeger eveneens leiden tot grote problemen, het aanbrengen van aanpassingen aan historische gebouwen zal vaak aan banden worden gelegd, wat het voorzien van de nodige bekabeling voor de sensornetwerken aanzienlijk kan bemoeilijken of simpelweg onmogelijk maakt. Ook hier, en in tal van andere toepassingen, kunnen draadloze sensornetwerken een oplossing bieden.

Vooral de sterke beperkingen die aanwezig zijn bij sensoren (denk hierbij aan beperkte energievoorraad, beperkte rekencapaciteit, ...) maken deze communicatienetwerken sterk verschillend van de communicatienetwerken die zich vandaag de dag rondom ons bevinden. Er zijn dan ook nog veel uitdagingen op het gebied van draadloze sensornetwerken [23].

1.1

Probleemstelling

In draadloze sensornetwerken is meestal één node verantwoordelijk voor het verzamelen van alle informatie uit het netwerk (deze wordt benoemd als de sink ). Aangezien de communicatie verloopt over het draadloos medium kan vaak pakketverlies optreden. Bij draadloze sensornetwerken is het daarom nuttig om het aantal hops dat een pakket moet doorlopen zo laag mogelijk te houden. Bij iedere hop dient een pakket immers opnieuw uitgestuurd te worden en zal de kans op pakketverlies dus ook omhoog gaan. Merk ook op dat het grootste deel van de verbruikte energie afkomstig is van het versturen en ontvangen van data over de radio en dat ook omwille van deze reden het aantal te versturen pakketten liefst zo laag mogelijk gehouden wordt.

1.1 Probleemstelling

3

Men zou dus kunnen opteren om het zendvermogen zo hoog mogelijk in te stellen, en op die manier het aantal hops te minimaliseren. Er zijn echter twee nadelen verbonden met het verhogen van het zendvermogen. Ten eerste is het verband tussen de afstand die moet overbrugd worden en de hoeveelheid energie die daarvoor nodig is niet lineair. Vanaf een bepaalde afstand (afhankelijk van de hardware) is het beter om te opteren voor multi-hop routering in plaats van single hop routering [45]. Een ander nadeel is dat met het verhogen van het zendvermogen ook de grootte van het “collision domain” vergroot. Dit betekent dat het dus meer aannemelijk worden dat pakketten verloren gaan doordat sensoren op hetzelfde moment data versturen. Zeker bij toepassingen waar veel dataverkeer aanwezig is kan dit leiden tot een hogere pakketverlies.

Een andere oplossing is om het netwerk te voorzien van meerdere sinks en op die manier het gemiddeld aantal hops tot de (dichtstbijzijnde) sink te reduceren. sink

sink

sink

Figuur 1.2: Netwerk voorzien van één sink tegenover netwerk voorzien van twee sinks Naast een reductie van het gemiddeld aantal hops en dus het gemiddeld energieverbruik zal dit typisch ook resulteren in het verhogen van de levensduur van het netwerk. Het is immers zo dat sensoren die zich dichter bij een sink bevinden typisch meer informatie zullen moeten versturen dan sensoren die zicht verder bevinden en dat de energievoorraad van deze sensoren dus sneller uitgeput zal raken [3]. Men zou zelfs kunnen opteren om af te wisselen van sink naar welke de data verstuurd zal worden en zo proberen het energieverbruik in het netwerk meer te spreiden (m.a.w. er wordt op elk gegeven moment slechts een subset van de beschikbare sinks gebruikt).

Hoewel het gebruiken van meerdere sinks veel voordelen kan opleveren is het spijtig genoeg niet altijd op een even goede manier ondersteund in routeringsprotocollen die gebruikt worden in draadloze sensornetwerken.

1.2 Doelstelling

1.2

4

Doelstelling

Met de opkomst van IPv6 Routing Protocol for Low power and Lossy Networks (RPL), een routeringsprotocol dat steeds vaker gebruikt wordt in draadloze sensornetwerken, is het zeker interessant om eens na te gaan of het mogelijk is om het gebruik van meerdere sinks te ondersteunen zonder grote wijzigingen door te voeren aan het protocol. Het is de bedoeling om in deze thesis een oplossing te ontwikkelen voor het ondersteunen van meerdere sinks in RPL en de werking van deze oplossing zowel te testen in een simulatie omgeving als op echt hardware. Naast het ondersteunen van meerdere sinks zal ook ondersteuning voor mobiliteit in RPL worden uitgewerkt en zal nagegaan worden hoe het van meerdere sinks de kwaliteit van een netwerk waarin zich mobiele nodes bevinden kan verhogen.

1.3

Structuur

In deze laatste sectie van het hoofdstuk wordt een overzicht gegeven van de verdere opbouw van de thesis. • Hoofdstuk 2 omvat de literatuur studie omtrent draadloze sensornetwerken, contiki en ondersteuning van meerdere sinks • Aangezien ondersteuning voor meerdere sinks en mobiliteit toegevoegd wordt aan RPL, is een goede kennis van dit routeringsprotocol een vereiste. Er wordt dan ook een volledig hoofdstuk toegewijd aan de werking van dit protocol. • Hoofdstuk 4 beschrijft hoe de ondersteuning van meerdere sinks in (Contiki)RPL mogelijk gemaakt zal worden. In hoofdstuk 5 wordt de exacte implementatie van de ondersteuning voor meerdere sinks in ContikiRPL besproken • In hoofdstuk 6 worden de belangrijkste performantietesten met betrekking tot het gebruiken van meerdere sinks besproken. De bedoeling is om zowel aan te tonen dat de implementatie correct werkt als om een idee te geven welke performantie winsten verwacht kunnen worden wanneer extra sinks worden toegevoegd aan een draadloos sensor netwerk. • Hoofdstuk 7 bespreekt de aanpassingen die werden doorgevoerd om mobiliteitsondersteuning in RPL toe te voegen, als ook hoe het gebruik van meerdere sinks kan bijdragen tot een hogere performantie voor mobiele nodes.

LITERATUURSTUDIE

5

Hoofdstuk 2

Literatuurstudie 2.1 2.1.1

Draadloze sensornetwerken Inleiding

Draadloze sensornetwerken bestaan uit kleine, goedkope apparaten (ook wel “sensor nodes” genoemd) die draadloos met elkaar communiceren en in staat zijn hun omgeving te monitoren. Deze sensor nodes bestaan typisch uit een microprocessor, een (laag-vermogen) radio, een beperkte hoeveelheid geheugen, een beperkte energievoorraad (batterij/energy harvester) en een aantal sensoren die in staat zijn de omgeving op te meten (licht, temperatuur, ...). Door de nodes te voorzien van eenvoudige hardware (lichte processor, kleine hoeveelheid geheugen, ...) kunnen ze zeer goedkoop gefabriceerd worden.

Figuur 2.1: Enkele voorbeelden van sensor nodes [28] [35] [47] In draadloze sensornetwerken zal de informatie, afkomstig van de verschillende sensor nodes, typisch verzameld worden door een centrale applicatie die op een sink draait. Bij grote netwerken is het mogelijk dat niet langer rechtstreeks gecommuniceerd kan worden met deze sink. In dergelijke gevallen zal dan ook gebruik gemaakt worden van multi-hop routering om de data tot bij de sink te krijgen. Mede doordat bij draadloze sensornetwerken geen nood is aan een

2.1 Draadloze sensornetwerken

6

vaste infrastructuur zijn de toepassingen ervan wijdverspreid. Enkele toepassingsgebieden waar draadloze sensornetwerken worden ingezet zijn [18]: monitoren van milieu en leefomgeving, gezondheidszorg, beveiliging en automatisering van gebouwen (domotica), militaire operaties, ...

Figuur 2.2: Voorbeeld van een draadloos sensornetwerk die wordt ingezet om de activiteit van een vulkaan te meten [44] De sterke beperkingen van de sensor nodes en het gebruik van een medium waar vaak pakketverlies voorkomt zorgen voor veel uitdagingen bij het ontwerpen van draadloze sensornetwerken waar de nodes op een zo efficiënt mogelijk manier met elkaar kunnen communiceren [23].

2.1.2

Tmote Sky

De Tmote Sky is een draadloze sensormodule met een zeer laag vermogen die onder andere uitgerust is met licht-, vochtigheids- en temperatuursensoren. Het draadloos sensornetwerk iMinds w-iLab.t [29], waar gebruik van gemaakt werd in deze thesis, maakt gebruik van deze sensormodules.


7

Figuur 2.3: De Tmote Sky [38] Enkele kenmerken van de sensormodule [38]: • IEEE 802.15.4 Chipcon CC2420 radio module (2,4 Ghz, 250kbps) • Ge¨ıntegreerde antenne (bereik tot 25m binnen, 125m buiten) • 8MHz Texas Instruments MSP430 microcontroller met 10k RAM en 48k Flash • Ultra-Low Power (standby: 5-21 µA, idle/on: 54 µA-2.4mA, RX/TX: 19-23mA) • Ingebouwde sensoren (licht, vochtigheid en temperatuur) • USB-ondersteuning (zowel programmeren als datacollectie) • Tal van uitbreidmogelijkheden (I2C, UART, ADC, DAC, ...)

2.1.3

Routeringsprotocollen

Locatie-gebaseerde routering

Bij protocollen die gebruik maken van “Location-based rou-

ting” zullen de sensornodes aan de hand van hun fysieke locatie geadresseerd worden. In veel draadloze sensornetwerken zullen de locaties van de sensoren gekend zijn aangezien deze gebruikt kunnen worden om de afstand tussen twee sensoren te bepalen en zo een inschatting te maken van de nodige energie om gegevens te versturen [2]. Wanneer men de fysieke regio waar men data wenst te verzamelen kent, kan gebruik gemaakt worden van de locatie-informatie om de pakketten in de juiste richting te sturen om zo het energieverbruik zo laag mogelijk te


8

houden. Enkele voorbeelden van locatie-gebaseerde routeringsprotocollen [2] zijn: (Small) Minimum Energy Communication Network (SMECN/MECN), Geographic Adaptive Fidelity (GAF) en Geographic and Energy-Aware Routing (GEAR). Data-centrische routering Bij data-centrische routeringsprotocollen zullen nodes niet langer geadresseerd worden op basis van een uniek adres (bv. een IP-adres) maar wel op basis van de informatie die ze produceren of waarin ze ge¨ınteresseerd zijn. Iets wat ook kenmerkend is voor data-centrische routeringsprotocollen is dat niet langer één sensor verantwoordelijk is voor het beantwoorden van een aanvraag. Zo kunnen de verschillende sensoren die zich op het pad naar de sink bevinden aan de hand van lokale informatie de data bijwerken/aggregeren. Op die manier wordt de hoeveelheid informatie die verstuurd moet worden gereduceerd. Enkele van de vaak gebruikte data-centrisch routeringsprotocollen [2] zijn Directed Diffusion, Rumor Routing en Sensor Protocols for Information via Negotiation (SPIN). Hi¨ erarchische routering

Bij hiërarchische routeringsprotocollen zullen sensoren gegroepeerd

worden in clusters, met aan het hoofd daarvan een clusterhead. De clusterhead is verantwoordelijk voor de communicatie in de cluster en voor de communicatie tussen de clusterheads onderling. De clusterheads kunnen op hun beurt eveneens gegroepeerd worden in verschillende clusters en zo ontstaat een vorm van hiërarchie.

Figuur 2.4: Hiërarchische clustering in TEEN en APTEEN [2]

Boom-gebaseerde routering

Bij boom-gebaseerde routeringprotocollen wordt een boom-

structuur opgebouwd om routering in het netwerk mogelijk te maken. Dit betekent dat elke

2.2 Contiki OS

9

sensor node één ouder heeft en mogelijk meerdere kinderen. De routering verloopt simpelweg door in de boomstructuur het pad tussen twee sensor nodes te volgen. Boom-gebaseerde routeringsprotocollen zijn enigszins te vergelijk met hiërachische protocollen aangezien ook hier verschillende niveaus waar te nemen zijn. Enkele voorbeelden van boom-gebasseerde routeringsprotocollen zijn: Tree Based Routing Protocol (TBRP) [7] en IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [46].

Figuur 2.5: Voorbeeld van een DODAG In RPL wordt in plaats van een boom, een Destination-Oriented Directed Acyclic Graph (DODAG) opgebouwd. Dit is een boom-achtige structuur maar waarin het mogelijk is voor een node om meerdere ouders te hebben (zie figuur 2.5). Uit de verzameling van mogelijke ouders zal één voorkeursouder gekozen worden waardoor de routering zelf ook verloopt alsof een boom structuur werd opgebouwd. Meer informatie over RPL is terug te vinden in hoofdstuk 3.

2.2

Contiki OS

Contiki is een open source besturingssysteem voor het opzetten van netwerken met toestellen die sterke beperkingen hebben op de hoeveelheid beschikbaar geheugen [12] [13]. Het besturingssysteem focust zich voornamelijk op het ondersteunen van laag-vermogen draadloze sensortoestellen.

Aangezien het besturingssysteem zich focust op sensortoestellen is het zeer compact geschreven. Enkele kilobytes aan code (ROM) en een paar honderd bytes aan geheugen (RAM) zijn voldoende om het besturingssysteem te draaien. Desondanks deze lage vereisten wordt ondersteuning geboden voor multithreading en is een TCP/IP stack aanwezig.

2.2 Contiki OS

10

Figuur 2.6: Architectuur van Contiki besturingssysteem [17] Contiki bestaat uit een kern (de contiki core) waarop applicaties gedraaid kunnen worden. De kern zelf maakt gebruik van drivers om de hardware aan te spreken (zie figuur 2.6). Het besturingssysteem werd volledig ontwikkeld in C, net als alle applicaties die ervoor gebouwd worden. Dit, en het feit dat gebruik gemaakt wordt van drivers, zorgt ervoor dat het eenvoudig te porten is naar verschillende hardware toestellen.

Er is ondersteuning voor multi-threading aan de hand van de ProtoThreads bibliotheek [33]. Omdat een pure multi-threading omgeving veel geheugen vereist (er is een stack nodig per thread) en een pure event-driven omgeving niet geschikt is voor langdurige berekeningen (eens gestart kunnen ze immers niet onderbroken worden) werd gekozen voor een combinatie van beide omgevingen (zie figuur 2.7). De contiki core is event-driven en de meeste applicaties zullen rechtstreeks op deze core draaien zonder gebruik te maken van threading. Indien een applicatie voor het verwerken van een gebeurtenis een lange uitvoering nodig heeft kan gekozen worden om threading te gebruiken. De applicatie beslist dan om na een bepaalde tijd de thread tijdelijk te stoppen en de gebeurtenis op een later tijdstip verder te verwerken. Er wordt geen stack voorzien per thread en het is dan ook de taak van de applicatie om ervoor te zorgen dat de nodige gegevens op een correcte manier bewaard blijven alvorens de uitvoering van een thread gepauzeerd wordt.

2.3 Meerdere sinks in draadloze sensornetwerken

Handler

Kernel

Handler

Handler Event-Driven -De kern start de 'handler' wanneer een gebeurtenis zich voordoet -Als de 'handler' returnt kan een volgende gebeurtenis verwerkt worden

11

Event

Kernel

Thread

Event

Event Event-Driven met Threads (Contiki) -Indien een gebeurtenis zich voordoet die kan resulteren in een lange uitvoering kan gebruik gemaakt worden van threads -Deze threads kunnen tijdelijk gestopt worden om zo eerst andere gebeurtenissen te verwerken

Figuur 2.7: Threading in Contiki Met behulp van de Loader (zie figuur 2.6) is het mogelijk om applicaties dynamisch in te laden. Dit betekent dat een sensor node uitgebreid kan worden met nieuwe applicaties zonder dat deze volledig opnieuw geprogrammeerd hoeft te worden. De applicaties kunnen via verschillende methodes ingeladen worden: via het draadloos medium, vaste verbindingen (USB, UART), EEPROM geheugen, ...

Tot slot is er in Contiki een implementatie van het RPL routeringsprotocol aanwezig (ContikiRPL) [39]. Dit is het protocol dat gebruikt zal worden in het verdere verloop van deze thesis.

2.3

Meerdere sinks in draadloze sensornetwerken

Een groot deel van de verbruikte energie in multi-hop draadloze sensornetwerken is afkomstig van het forwarden van pakketten. Door het aantal hops naar de sink te reduceren kan het gemiddeld energieverbruik van de sensoren gereduceerd worden en de levensduur van het netwerk dus verhoogd worden.

Een manier om het aantal hops te reduceren is door het netwerk te voorzien van meerdere sinks (zie figuur 1.2). Hierbij zal het positioneren van de verschillende sinks uiteraard een belangrijke factor zijn in de uiteindelijke efficiëntie van het netwerk. Het bepalen van de optimale posities voor de sinks is een NP-compleet probleem en dus niet eenvoudig op te lossen voor grote sensornetwerken [24]. In de literatuur is veel informatie terug te vinden over hoe het bepalen


12

van de optimale posities kan gebeuren (al dan niet door middel van benadering). In [24] gebeurt de bepaling door het probleem te zien als een “flow” probleem. In de literatuur was al veel informatie te vinden omtrent het bepalen van een zo energie efficiënt mogelijk netwerk, waarin slechts één sink aanwezig is, door middel van flow problemen. De auteurs hebben hierop verder gebouwd en de studie uitgebreid naar netwerken voorzien van meerdere sinks. Ook in [6] gebeurt de bepaling van de posities van de sinks door het aan te pakken als een “maximal flow” probleem. Het doel in deze paper was vooral om een analytische methode te ontwikkelen die de effecten van de positionering van sinks op de “flows” in het netwerk nagaat. Aangezien een “maximal flow” probleem nog steeds NP-compleet is, werden drie heuristische algoritmes ontworpen (één “greedy” algoritme en twee die zoeken naar lokale optima). In [32] wordt het probleem van de positionering aangepakt door middel van clustering (zie figuur 2.8). Het aantal clusters komt overeen met het aantal sinks dat aanwezig is in het netwerk. Dit betekent dat het probleem neerkomt op het vinden van een efficiënt clusteringsalgoritme (hier werd al veel onderzoek naar gedaan in de literatuur). Eens de clusters gevonden, rest enkel nog het plaatsen van de sinks in de clusters. Een eenvoudige methode is om de sink in het midden van de cluster te plaatsen. Wanneer gebruik gemaakt wordt van multi-hop routering is het beter om de positie te bepalen aan de hand van metrieken die rekening houden met de totaal verbruikte energie om data te versturen naar de sink (wat sterk afhankelijk is van de afstanden tussen de verschillende hops).

Figuur 2.8: Een draadloos sensornetwerk bestaande uit drie clusters/sinks [32]


13

Hoewel in deze thesis niet zozeer gefocust zal worden naar het optimaal positioneren van sinks in draadloze sensornetwerken, zijn de resultaten met betrekking tot levensduur van het netwerk en gemiddeld energieverbruik die terug te vinden zijn in papers die dit probleem aanpakken zeker en vast interessant om een beter beeld te krijgen van het nut van meerdere sinks. Enkele ervan zullen we dan ook kort bespreken.

Figuur 2.9: Resultaten uit [27]: gemiddeld energieverbruik en gemiddeld aantal hops in functie van het aantal sinks (de verschillende lijnen komen overeen met het gebruikte positioneringsalgoritme) In figuur 2.9 zien we duidelijk een verband tussen het gemiddeld energieverbruik en het aantal sinks. We kunnen concluderen dat naarmate er sinks worden toegevoegd aan het netwerk het gemiddeld energieverbruik afneemt. Dit is voor een groot stuk te verklaren door het feit dat het gemiddeld aantal hops eveneens afneemt naarmate het aantal sinks stijgt.

Figuur 2.10: Resultaten uit [32]: aantal nodes die door hun energievoorraad zitten (links) en aantal nodes die niet langer de sink kunnen contacteren (rechts) in functie van de tijd (en uitgevoerd met een verschillend aantal sinks)


14

In figuur 2.10 wordt dan weer nagegaan wat de levensduur van het netwerk is in functie van het aantal sinks. Hiervoor wordt bepaald na hoeveel tijd (hier in dagen) de nodes zonder energie komen te zitten. Wanneer een node zonder energie valt betekent dit eveneens dat een groot aantal nodes die zich in de deelboom van deze node bevinden niet langer kunnen communiceren met de sink (enkel die nodes die een alternatief pad kunnen vormen naar de sink zijn nog operationeel). Het totaal aantal nodes dat niet langer kan communiceren met de sink wordt weergegeven in de rechter grafiek. Het valt onmiddellijk op dat bij het gebruik maken van een beperkt aantal sinks (bovenste lijnen) er vrij snel een zeer groot deel van het netwerk onbereikbaar wordt. Dit heeft vooral te maken met het feit dat nodes die zich dicht bij de sink bevinden typisch de grootste hoeveelheid energie zullen verbruiken. Aangezien deze nodes typisch een grote deelboom hebben zijn de gevolgen van het uitvallen van dergelijke nodes typisch veel groter dan bij nodes die zich eerder op de randen van het netwerk bevinden.

IPV6 ROUTING PROTOCOL FOR LOW POWER AND LOSSY NETWORKS

15

Hoofdstuk 3

IPv6 Routing Protocol for Low power and Lossy Networks 3.1

Introductie

Het vervolg van deze thesis concentreert zich voornamelijk op IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [46] en mogelijke uitbreidingen van RPL. Hiervoor is het noodzakelijk om de werking van dit protocol uitgebreider te bespreken/toe te lichten.

3.2

Overzicht

RPL is een routeringsprotocol dat speciaal ontworpen werd om gebruikt te worden in Low-power and Lossy Networks (LLNs). Enkele specifieke kenmerken van LLNs zijn hoge verliesratio’s, lage bandbreedte, instabiliteit en de mogelijk dat een bepaalde link gedurende een periode volledig onbruikbaar wordt. Voorbeelden van LLNs zijn draadloze netwerken en netwerken waar gebruik gemaakt wordt van Powerline communicatie. RPL werd ontwikkeld met het oog op vier verschillende scenario’s: urban networks, building automation, industrial automation en home automation. RPL is een distance-vector routeringsprotocol dat een graaf opbouwt waar paden worden gevormd van elke node naar de wortel. Hoewel link-state routeringsprotocollen krachtiger zijn, daar de volledige netwerktopologie gekend is in elke node (zie figuur 3.1), werd hier gekozen voor een distance-vector protocol. Een reden voor deze keuze is de zeer beperkte hoeveelheid geheugen en verwerkingscapaciteit van sensornodes.

3.3 Routeringssmetrieken

16

1 4

topologie onbekend voor node 9

3

1 1

5

2

2 6

8

7 1

4

4

2

1

1

2

3

7

2 3 6

1

1 4

1

8

1 5

2 9

9

Distance-Vector

Link-State

Figuur 3.1: Topologiekennis van node 9 Bij het ontwerpen van RPL is ervoor gekozen om een modulair routeringsprotocol te ontwikkelen waar de kerncomponenten beschreven worden in de specificatie en extra opties alleen gebruikt dienen te worden indien daar een nood aan is. Zo wordt in de specificatie van RPL bijvoorbeeld omschreven hoe een Destination Oriented Directed Acyclic Graph (DODAG) opgebouwd moet worden, maar de karakteristieken van deze DODAG zijn afhankelijk van de gebruikte Objectief Functie (OF) (zie sectie 3.4).

3.3

Routeringssmetrieken

Aan de hand van routeringssmetrieken wordt de kost van een pad bepaald. Ze worden typisch gebruikt in routeringsprotocollen om, bij de keuze tussen meerdere paden, het ene pad te kiezen over een ander. Er kan een onderscheid gemaakt worden tussen statische metrieken, waar aan de links/nodes een vaste waarde toegekend wordt (de maximale bandbreedte, de latency, ...) en dynamische metrieken, waar de waarde van de links/nodes wijzigt doorheen de levensduur van het netwerk (beschikbare bandbreedte, beschikbaar geheugen op node, ...). De huidige IP routeringsprotocollen (denk hierbij aan OSPF, IS-IS) maken voornamelijk gebruik van statische link metrieken [42]. Door het specifieke karakter van LLNs, zoals wisselende link kwaliteit op verschillende tijdstippen door interferentie, is er echter nood aan meer dynamische metrieken.

Eén van de belangrijke keuzes die dient gemaakt te worden bij het gebruiken van dynamische metrieken is hoe snel de metriek de werkelijke waarde van een link weergeeft. Wanneer we

3.3 Routeringssmetrieken

17

opteren om de werkelijke situatie zeer sterk te benaderen zullen we vaak zien dat dit zal leiden tot routeringsoscillatie. Stel bijvoorbeeld dat als metriek de link capaciteit gebruikt wordt en dat we ervoor opteren om steeds de werkelijk gebruikte linkcapaciteit zo sterk mogelijk te benaderen. In dit scenario zal een link die amper tot niet gebruikt wordt zeer aantrekkelijker zijn voor het routeringsprotocol, wanneer beslist wordt de link in gebruik te nemen (en dus een deel van het verkeer te herrouteren over deze link) zal de overblijvende capaciteit op de link dalen en zal deze dus ogenblikkelijk minder aantrekkelijk worden. Aangezien een stuk van het verkeer uit het netwerk geherrouteerd werd is het goed mogelijk dat ondertussen een andere link in het netwerk aantrekkelijker is, wat opnieuw kan leiden tot het herrouteren van het verkeer over deze link. Het gebruik van dit soort strategieën kan dus onder andere jitter en pakket herordening tot gevolg hebben. Ook zal bij het frequent wijzigen van de routeringstabellen veel meer informatie verspreidt moeten worden doorheen het netwerk wat we typisch zo veel mogelijk proberen te vermijden in LLNs. Om die reden kan het voordeliger zijn om ervoor te opteren geleidelijk aan de linkwaarde aan te passen (bv. door gebruik te maken van een gewogen gemiddelde), zo zullen korte wijzigingen een minder grote invloed hebben op de routeringsbeslissingen van het gebruikte protocol.

In huidige routeringsprotocollen is het eveneens zo dat de metrieken zo goed als altijd uitsluitend betrekking hebben op de links aangezien deze typisch de bottlenecks zijn in het Internet en niet zozeer de core routers. In LLNs is deze situatie echter anders, zo beschikken senornodes vaak over een beperkte hoeveelheid geheugen, zijn ze voorzien van een beperkte energievoorraad, ... Om deze redenen zal bij LLNs ook vaker gekozen worden om naast linkmetrieken (capaciteit, latency, ...) eveneens gebruik te maken van nodemetrieken (resterende energievoorraad, gebruikt geheugen, ...).

Voor de selectie van een bepaald pad kan naast metrieken ook gebruik gemaakt worden van constraints. Het verschil tussen beide aanpakken wordt ge¨ıllustreerd aan de hand van volgende voorbeelden. Bij metrieken zal voor een bepaalde parameter naar een zo gunstig mogelijke waarde gestreefd worden, zoals een zo laag mogelijk energieverbruik. Bij een constraint worden bepaalde vereisten aan een pad gesteld, zoals het uitsluiten van paden waarop er zich batterij gevoede nodes bevinden.

3.4 De objectief functie

3.4

18

De objectief functie

In RPL wordt gebruik gemaakt van een objectief functie om ouders te selecteren en routes te optimaliseren, deze zal dus bepalend zijn voor hoe de DODAG eruit ziet. Een objectief functie hoeft niet noodzakelijk ingewikkeld ineen te zitten, men zou bijvoorbeeld eenvoudig weg kunnen beslissen om die paden te kiezen waarvoor de som van de link kosten op het pad minimaal is (hierbij zal de objectief functie gebruik maken van een bepaalde metriek, bv. latency). Men hoeft zich eveneens niet te beperken tot één bepaalde metriek of “constraint”, het is perfect mogelijk om in de objectief functie een combinatie van metrieken en/of “constraints” op te nemen. In RPL is het mogelijk om meerdere objectief functies te gebruiken binnen eenzelfde netwerk aangezien verschillende types applicaties andere vereisten kunnen hebben voor het bepalen van de padkwaliteit. Voor elk van de gebruikte objectief functies zal een DODAG worden opgebouwd (zie sectie 3.6.2) en op die manier kan, afhankelijk van de te versturen data, een ander routeringspad gekozen worden. Stel bijvoorbeeld dat we een netwerk hebben dat bestaat uit zowel batterij gevoede sensoren als niet-batterij gevoede sensoren, waarin de kwaliteit van de links (bv. Bit Error Rate) tussen de sensoren sterk verschillend is en waar twee verschillende applicaties op draaien (alarmsysteem en telemetrie). Door in RPL gebruik te maken van twee verschillende objectief functies kunnen de eisen voor beide applicaties afzonderlijk afgestemd worden. De objectief functie die gebruikt wordt voor data met betrekking tot het alarmsysteem zal het pad kiezen met de laagste Bit Error Rate, ongeacht of er zich batterij gevoede sensoren op dit pad bevinden terwijl de objectief functie voor de telemetrie applicatie eerder zal proberen paden met batterij gevoede sensoren te vermijden.

De exacte implementatie van de objectief functie is niet vastgelegd in de RPL specificatie, deze keuze werd genomen om het protocol zo modulair mogelijk te houden. Op deze manier kan de topologie van het netwerk aangepast worden aan de specifieke noden van een applicatie. Dit maakt het mogelijk een netwerk te gebruiken waarop een grote diversiteit aan applicaties kan draaien.

3.5 RPL berichten

3.5

19

RPL berichten

In de RPL specificatie [46] worden drie nieuwe ICMPv6 berichten gedefinieerd: DODAG Information Object (DIO), Destination Advertisement Object (DAO) en DODAG Information Solicitation (DIS). De structuur en het nut van deze berichten zal nu kort worden toegelicht in de volgende secties.

3.5.1

DODAG Information Object (DIO)

DIO berichten worden door de RPL nodes (periodiek) verstuurd om informatie over een DODAG bekend te maken aan de omgeving. Ze worden gebruikt door de sensornodes om een DODAG op te bouwen en te onderhouden. De belangrijkste informatie die terug te vinden is in een DIO bericht is het id van de DODAG, de instance waartoe het bericht behoort, het versienummer van de DODAG en de rank van de node. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |Version Number | Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|0| MOP | Prf | DTSN | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+

Figuur 3.2: DIO bericht

3.5.2

Destination Advertisement Object (DAO)

Destination Advertisement Object (DAO) berichten worden gebruikt om prefix bereikbaarheid naar de bladeren toe bekend te maken, dit is noodzakelijk om verkeer in de down richting toe te staan (van de sink naar de bladeren). Een DAO bevat informatie over de prefix, een waarde die aangeeft hoe lang deze prefix geldig is (lifetime) en diepte/kost informatie die aangeeft hoe ver de bestemming gelegen is (deze informatie wordt meegegeven in de Options van een DAO bericht). Net als bij een DIO bericht worden ook hier de ids van de instance en de DODAG meegegeven in het bericht.

3.6 Topologie

20

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | Reserved | DAOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID* + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+

Figuur 3.3: DAO bericht

3.5.3

DODAG Information Solicitation (DIS)

Aangezien het versturen van DIO berichten periodiek gebeurt en het interval tussen twee DIO berichten hoog kan oplopen bij een stabiel netwerk (zie sectie 3.7), werd in RPL een mogelijkheid voorzien om expliciet aan de omgeving te vragen DIO berichten uit te sturen. Dit gebeurt door het versturen van een DIS bericht. Een DIS bericht zal typisch verstuurt worden door een node wanneer deze nog geen lid is van een DODAG en geen DIO bericht ontvangen werd binnen een vooraf ingestelde periode. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figuur 3.4: DIS bericht

3.6 3.6.1

Topologie Rank van een node

De relatieve positie van een node in een DODAG wordt aangegeven door de rank parameter en wordt gebruikt voor ouder selectie en “loop avoidance”. Wanneer de rank van node A kleiner is dan de rank van node B betekent dit dat A zich dichter bij de wortel bevindt dan B. In dergelijke situatie is het toegestaan voor B om A als ouder te kiezen aangezien er geen kans dat een lus gevormd wordt (zie figuur 3.5).

3.6 Topologie

21

1

1 2

2

3

7

3

7

4

4

5

6

5

6

Figuur 3.5: Node 4 kiest een node met lagere rank als ouder Het is echter niet toegestaan om een node met een hogere rank als ouder te kiezen aangezien dit mogelijk een lus kan introduceren (concreet gebeurt dit wanneer de node een ouder kiest uit zijn eigen deelboom, zie figuur 3.6). 1

1

2

2

3

7

7

4

6

3

5

4

6

5

Figuur 3.6: Node 4 kiest een node met hogere rank als ouder Tot slot dient de rank van een node minstens MinHopRankIncrease hoger te zijn dan de rank van zijn ouders. De waarde van deze parameter wordt gekozen door de DODAG wortel en wordt vermeld in de DIO berichten.

3.6.2

Opbouw van de DODAG

In deze sectie zal aan de hand van een voorbeeld besproken worden hoe een DODAG wordt opgebouwd. In figuur 3.7 wordt de fysieke topologie van het voorbeeldnetwerk weergegeven.

Stap 0: Vooraleer het opbouwen van de DODAG van start gaat dient een node gekozen te worden die zal fungeren als sink (DODAG wortel) van het netwerk. Deze wordt handmatig gekozen, bijvoorbeeld door de systeemadministrator, daar een sink typisch een speciale taak vervult in het netwerk.

3.6 Topologie

22

1 1

2 5

1

1

2

4

7

2 3 6

4 1

1

1

1

9

8 2

10

Figuur 3.7: Fysieke topologie van een netwerk Stap 1: De DODAG root (node 1) begint met link-local multicast DIO berichten te versturen (zie figuur 3.8). Dit gebeurt ofwel omdat de DIO timer verlopen is (trickle timer), ofwel omdat één van de omliggende nodes een DIS bericht heeft verstuurd.

1 2

Node 1 stuurt DIO bericht

4

7 5

6

8

9

10

Figuur 3.8: DIO bericht wordt verstuurd door de DODAG root Stap 2: De nodes die in het bereik liggen van de root (stel 2,4 en 7) ontvangen het bericht. Er wordt gecontroleerd of de rank van het bericht lager is dan hun eigen rank, indien dit het geval is dan wordt het DIO bericht verwerkt. Aangezien nodes 2,4 en 7 in het voorbeeld nog geen DIO ontvangen hebben is hun rank oneindig (initiële waarde) en zullen ze dus de DIO verwerken. Alle drie selecteren ze de zender van het bericht (node 1) als hun ouder en (her)berekenen ze hun eigen rank.

3.6 Topologie

23

1 2

4 7

5

6

8

9

10

Figuur 3.9: DODAG na stap 2 Stap 3: Aangezien de rank van de nodes 2,4 en 7 verandert zijn zullen ook zij link-local multicast DIO berichten uitsturen. Deze worden ontvangen door de nodes 1, 5, 6, 8 en 9 en net zoals in stap 2 zullen ouders geselecteerd worden. Merk op dat, in tegenstelling tot stap 2, nu DIOs ontvangen kunnen worden van verschillende nodes en dat er dus mogelijk een keuze dient gemaakt te worden tussen verschillende ouders. Deze keuze zal gebeuren aan de hand van de objectief functie die uit de verzameling van mogelijk ouders één voorkeursouder zal kiezen. Merk op dat dit niet noodzakelijk de ouder is waarvoor de metriekwaarde het laagst is. Zo kan een hysteresis ervoor zorgen dat gekozen wordt voor een ouder met een iets hogere metriekwaarde om zo fluctuaties te vermijden (zie sectie 3.9.1). Uit de fysieke topologie kunnen we afleiden dat node 8 een DIO bericht ontvangt van zowel 4 en 7 en node 6 van zowel 2 en 7. Stel nu dat de kost van een pad gelijk is aan de kosten van de deelpaden, dan zien we dat de totale kost van het pad 8-7-1 gelijk is aan de totale kost van het pad 8-4-1 en dus zal node 8 zowel 4 als 7 als ouder accepteren. Vergelijken we echter de totale kost van de paden 6-2-1 en 6-7-1, dan zien we dat het pad 6-2-1 een lager kost heeft en om die reden zal node 6 enkel node 2 accepteren als ouder.

3.6 Topologie

24

1 2

4 7

5

6

9

8 10

Figuur 3.10: DODAG na stap 3 Stap 4: Dit proces herhaalt zich tot wanneer alle nodes tot de DODAG behoren. Merk op dat DIO berichten gedurende de ganse levensduur van het netwerk blijven verstuurd worden, en dat de structuur van de DODAG dus kan wijzigen door bijvoorbeeld een wijziging in de kost van een bepaald pad. 1 2

4 7

5

6

8

9

10

Figuur 3.11: Bekomen DODAG eens alle nodes zijn toegevoegd

3.6.3

Routeren

In RPL wordt ondersteuning geboden voor Multipoint-to-Point(MP2P), Point-to-Multipoint (P2MP) en Point-to-Point verkeer. Welk verkeer tot welke categorie behoort en hoe het mogelijk gemaakt wordt om de verschillende categorieën te ondersteuning zal nu kort worden uitgelegd. Multipoint-to-Point

Hiertoe behoort verkeer in de opwaartse richting, m.a.w. van de bla-

deren naar de wortel. Voor dit type verkeer kan de DODAG structuur gebruikt worden. Dit betekent dat eens de DODAG werd opgebouwd zoals besproken in sectie 3.6.2 elke node datapakketten kan sturen naar de wortel. Door elke node zal uit de verzameling van zijn ouders één ouder gekozen worden waar het datapakket naartoe zal gestuurd worden, op deze manier

3.6 Topologie

25

zal het pakket stap voor stap dichter bij de wortel komen. 1 2

4 7

5

6

8

9

10

Figuur 3.12: Multipoint-to-Point verkeer

Point-to-Multipoint

Hiertoe behoort verkeer in de neerwaartse richting, m.a.w. van de

wortel naar de bladeren toe. Om dit type verkeer mogelijk te maken hebben de nodes nood aan extra informatie, aan de hand van de DIO berichten kan immers enkel achterhaald worden wie de ouders van een node zijn. De nodige informatie wordt verkregen aan de hand van DAO berichten. Zoals reeds vermeld worden deze gebruikt om prefix bereikbaarheid bekend te maken aan de ouders van een node. Wanneer de voorkeursouder van een node wijzigt zal naar de nieuwe ouder een DAO bericht worden gestuurd om deze hiervan op de hoogte te brengen. Op deze manier kan de ouder dus verkeer bestemd voor een node in zijn deelboom correct forwarden. Het versturen van DAO berichten hoeft niet ogenblikkelijk te gebeuren, men kan ervoor opteren om dit een tijd uit te stellen, om zo het aantal te versturen DAO berichten eventueel te reduceren (aggregeren van informatie in één bericht). Het is eveneens mogelijk om een ouder te laten weten dat een route niet langer beschikbaar is, hiervoor wordt een DAO bericht verstuurd waarbij de lifetime van de route op 0 wordt ingesteld. Dit soort berichten worden in RPL ook no-DAO berichten genoemd.

3.6 Topologie

26

1 2

4 7

6

5

9

8 10

Figuur 3.13: Point-to-Multipoint verkeer

Point-to-Point

Communicatie tussen twee sensoren die niet behoort tot één van bovenstaande

categorieën wordt Point-to-Point verkeer genoemd. Dit type verkeer zal typisch bestaan uit een combinatie van de data opwaarts en vervolgens neerwaarts te sturen. Zolang in de routeringstabellen geen informatie te vinden is over de bestemming van het pakket wordt het opwaarts verstuurd, eens informatie aanwezig is zal het in de neerwaartse richting worden verstuurd tot wanneer het pakket zijn bestemming bereikt. 1 2

4 7

6

5

8

9

10

Figuur 3.14: Point-to-Point verkeer In RPL is het eveneens mogelijk voor sensoren die in elkaars bereik liggen om rechtstreeks informatie naar elkaar te sturen zonder gebruik te maken van de DODAG.

3.6.4

Herstelmechanismes

Net zoals veel ander routeringsprotocollen beschikt RPL over een globaal herstelmechanisme, wat hier de volledige DODAG zal heropbouwen, en een lokaal herstelmechanisme dat zal proberen om snel een alternatief pad te vinden wanneer zich problemen voordoen op het huidig pad.

3.6 Topologie

a)

27

Global repair

Het globaal herstelmechanisme in RPL wordt global repair genoemd en kan enkel maar ge¨ınitieerd worden door de DODAG wortel. Men zou uiteraard een systeem kunnen ontwikkelen op de applicatielaag waardoor alle sensoren een global repair kunnen aanvragen. Wanneer de DODAG wortel het globaal herstelmechanisme opstart zal dit ervoor zorgen dat de volledige DODAG opnieuw opgebouwd wordt. Dit betekent dat het mechanisme niet enkel nuttig is als herstelmechanisme maar eveneens als heroptimalistie mechanisme. Het zou bijvoorbeeld interessant kunnen zijn om de DODAG opnieuw op te bouwen wanneer het fysieke netwerk gewijzigd werd. Om de nodes in het netwerken te informeren dat een global repair wordt uitgevoerd, wordt gebruik gemaakt van het versienummer dat aanwezig is in een DIO bericht (zie sectie 3.5.1). Wanneer een DODAG wordt opgebouwd zal elke node bijhouden wat het versienummer in de DIO berichten was die werden uitgestuurd om deze DODAG op te bouwen en te onderhouden. Indien een DIO bericht ontvangen wordt waarin het versienummer groter is dan het versienummer van de huidige DODAG betekent dit dat de sink het global repair mechanisme heeft opgestart. In dergelijke situatie zal de node zich terug naar de begintoestand begeven (alle ouders worden verwijderd, de rank wordt ingesteld op oneindig, de trickle timer wordt gereset,...) en zal het volledig mechanisme voor het opbouwen van de DODAG opnieuw doorlopen worden (zie sectie 3.6.2). Het enige dat een sink dus hoeft te doen om het globaal herstelmechanisme op te starten is een DIO bericht uitsturen met een groter versienummer dan de voorgaande DIO berichten. b)

Local repair

Het lokaal herstelmechanisme (of local repair ) wordt uitgevoerd wanneer zich een probleem voordoet met het huidige beste pad en geen alternatief pad gevonden kan worden. De bedoeling van het mechanisme is om nieuwe ouders te vinden en op die manier opnieuw een pad te hebben naar de DODAG wortel. Wanneer het mechanisme wordt opgestart zal de node een DIO bericht uitsturen waarin de rank op oneindig wordt ingesteld, dit heeft als doel de nodes in zijn deelboom te laten weten dat er niet langer een pad bestaat naar de DODAG wortel en dat ze dus een alternatief pad moeten zoeken (dit wordt ook de poison-and-wait rule genoemd). Hoewel een rank van oneindig wordt uitgestuurd zal de node wel zijn effectieve rank behouden, dit wordt gedaan omdat het mogelijk is dat de DIO berichten verloren gaan en dat op deze manier toch nog een lus zou kunnen gevormd worden wanneer de node een element uit zijn vroegere

3.7 Trickle timer

28

deelboom kiest als ouder.

Hoewel onder normale situaties het niet toegestaan is voor een node om een ouder te selecteren die een hoger rank heeft dan zichzelf, is dit tijdens het lokaal herstelmechanisme beperkt toegestaan. Zo mag een node een ouder kiezen met een rank van hoogstens MIN RANK NODE + DAGMaxRankIncrease, waar MIN RANK NODE staat voor de laagste rank die de node ooit gehad heeft en DAGMaxRankIncrease een paramater is die door de DODAG wortel wordt meegedeeld in de DIO berichten (deze regel wordt ook wel de max depth rule genoemd). Deze regel werd ingevoerd voor de situatie waarbij het poison DIO bericht (DIO bericht met rank oneindig) verloren gaat en de node een ouder zou kiezen uit zijn vorige deelboom. Stel bijvoorbeeld dat node A het lokaal herstelmechanisme opstart, dat deze node de ouder was van node B en node B het poison DIO bericht niet ontvangt. Wanneer node A nu node B kiest als ouder zal hij dus een rank adverteren van minstens rank(B) + MinHopRankIncrease, node B zal ge¨ınformeerd worden van deze nieuwe rank en zal op zijn beurt een rank uitsturen van minstens rank(A) + MinHopRankIncrease, waarop node A ook opnieuw zijn rank dient te verhogen (moet immers minstens MinHopRankIncrease groter zijn dan die van node B). Hierdoor zal het probleem pas opgelost raken wanneer één van beide nodes de oneindige rank toegekend krijgt. Door het invoeren van de max depth rule zal na een beperkt aantal keer van het verhogen van de rank niet meer voldaan worden aan de regel waardoor het niet langer toegestaan is voor één van de nodes om de andere als ouder te kiezen.

Door het beperkt toestaan van een node te kiezen met een hogere rank tijdens het uitvoeren van het lokaal herstelmechanisme is het dus mogelijk voor een node om een nieuwe ouder te vinden en op die manier een nieuw pad naar de DODAG wortel te bekomen.

3.7

Trickle timer

In sectie 3.5 werd reeds kort aangehaald dat de DIO berichten periodiek verstuurd worden. Om energie te besparen zal de periode waarmee dit gebeurd vergroten naarmate het netwerk stabieler wordt. Hiervoor wordt gebruik gemaakt van het Trickle algoritme [25] [26].

3.7 Trickle timer

3.7.1

29

Parameters

We kunnen drie parameters onderscheiden in dit algoritme: Minimum Interval Size (Imin), Maximum Interval Size (Imax) en de Redundancy Constant (K). Minimum Interval Size Deze parameter geeft de minimale intervaltijd aan, m.a.w. dit is de kleinst mogelijke periode tussen twee DIO berichten. In RPL wordt Imin als volgt bepaald: Imin = 2RP L DIO

IN T ERV AL M IN

(3.1)

met RPL DIO INTERVAL MIN een zelf in te stellen parameter. Maximum Interval Size

Deze parameter geeft de maximale intervaltijd aan, m.a.w. de

grootst mogelijk periode tussen twee DIO berichten. Eens deze periode bereikt wordt, zullen de DIO berichten aan een constant tempo verstuurd worden. De waarde van Imax wordt in RPL als volgt bepaald: Imax = Imin × 2RP L DIO

IN T ERV AL DOU BLIN GS

(3.2)

waarbij RPL DIO INTERVAL DOUBLINGS eveneens een zelf in te stellen parameter is. Redundancy Constant

Dit is een natuurlijk getal dat wordt gebruikt om eventuele trans-

missies tegen te gaan (zie hieronder).

3.7.2

Werking

Voor de werking van het algoritme worden naast de parameters Imin, Imax en K nog enkel variabelen gebruikt: de grootte van het huidig interval I, een tijdstip T dat in het huidig interval gelegen is en een teller C. Bij het opstarten van het algoritme worden I en C ingesteld op respectievelijk Imin en 0, en wordt aan T een random waarde uit [I/2,I] toegekend. Telkens een consistent DIO bericht ontvangen wordt, wordt de variabele C ge¨ıncrementeerd. Wanneer de timer verloopt (het tijdstip T werd bereikt) wordt C vergeleken met de Redundancy Constante K en zal een DIO bericht uitgestuurd worden indien C < K. Wanneer het interval I verlopen is en I is kleiner dan Imax, dan zal I verdubbeld worden, C opnieuw ingesteld worden op 0 en start het proces opnieuw. Doet zich een inconsistentie voor (bv. de node beweegt in de DODAG, er wordt een lus gevormd in de DODAG,...) dan zal de trickle timer gereset worden. Dit betekent dat I opnieuw ingesteld wordt op Imin, C op 0 en voor T een random waarde uit [I/2, I] gekozen wordt.

3.8 Mobiliteit in RPL

30

Naast een inconsistentie kan de trickle timer eveneens gerest worden door een externe gebeurtenis, een voorbeeld van een dergelijke gebeurtenis in RPL is het ontvangen van een DIS bericht.

Merk op dat het in RPL mogelijk is om de controle C < K uit te schakelen en dus te voorkomen dat het versturen DIO berichten onderdrukt kan worden.

Kort samengevat komt het er dus op neer dat zolang het netwerk consistent is, het interval tussen twee DIO berichten verdubbeld zal worden (tot maximaal Imax), treed een inconsistentie op, dan wordt het interval terug ingesteld op de minimaal toegestane waarde (Imin). Op deze manier wordt de overhead aan controlepakketten dus sterk gereduceerd bij stabiele netwerken.

3.8

Mobiliteit in RPL

In [1] werd een evaluatie gedaan van het gebruik van RPL in een “Vehicular Ad hoc Network” (VANET). Aangezien in RPL standaard geen ondersteuning is voor mobiliteit werden enkele aanpassingen aan RPL doorgevoerd om toch mobiele nodes te kunnen ondersteunen. Deze zullen nu kort besproken worden

Onmiddellijke “ETX probing” van een nieuwe buur: bij het ontdekken van een nieuwe buur wordt hiernaartoe onmiddellijk data gestuurd om op die manier de kwaliteit van de link (ETX waarde) te kunnen bepalen. Op deze manier kan een nieuwe buur vrij snel een “preferred parent’ worden. Loop avoidance and detection: door mobiliteit is het (sneller) mogelijk dat een node een buur kiest als parent maar de parent van deze buur is in feite de node zelf. Dit wordt in RPL niet volledig voorkomen (slechts gedeeltelijk door restricties op de rank). Daarom wordt aan de DIO berichten (berichten die worden verstuurd om je kenbaar te maken aan je omgeving) meegegeven wie de parent is. Wanneer een node vervolgens een bericht binnenkrijgt waarin staat dat hijzelf de parent is wordt dit bericht genegeerd. Onmiddellijke DIOs en DAOs bij nieuwe parent selectie: standaard wordt in RPL even gewacht vooraleer DIOs en DAOs te sturen (gebeurt normaal enkel na het aflopen van de trickle timers). Bij DAOs (neerwaartse berichten) wordt dit onder andere gedaan om meer route informatie te kunnen aggregeren. Het is logisch dat in een mobiele omgeving deze berichten zo snel mogelijk dienen verstuurd te worden.

3.9 ContikiRPL

31

Er werden vervolgens testen uitgevoerd in een simulatieplatform om zo de impact van bovenstaande aanpassingen na te gaan. Uit de resultaten is af te leiden dat het dankzij bovenstaande aanpassingen mogelijk is om met mobiele nodes te communiceren in een netwerk dat gebruik maakt van RPL. Merk wel op dat hier nog geen real-life testen werden uitgevoerd en dat het enkel gaat om simulatieresultaten. Tot slot wordt ook vermeld dat de oplossing nog niet optimaal is (er zijn bv. geen automatische aanpassingen van de parameters t.o.v. de snelheid van een wagen). Er is sprake van om dit in verder onderzoek wel mogelijk te maken.

3.9

ContikiRPL

Aangezien in deze thesis verder gebouwd zal worden op de RPL implementatie zoals deze aanwezig is in Contiki zullen in deze sectie de belangrijkste eigenschappen ervan aan bod komen.

3.9.1

Aanwezige objectief functies

Aangezien de gebruikte objectief functie bepalend is voor hoe de topologie van het netwerk er uiteindelijk uit ziet zullen we kort de aanwezige objectief functies in ContikiRPL bespreken. Er zijn twee verschillende objectief functies aanwezig: Objective Function Zero(OF0) [37] en de “Minimum Rank with Hysteresis Objective Function (MRHOF)” [20]. Objective Function Zero Dit is een zeer eenvoudige objectief functie die “Hop Count” gebruikt als metriek. Elke sensornode zal m.a.w. het pad met het minst aantal hops naar de sink selecteren als beste pad. Om dit mogelijk te maken zal elke node bij het uitsturen van een DIO bericht de rank instellen op de rank van zijn ouder + constante waarde. Concreet betekent dit dat een node die zich op vier hops van de sink bevindt als rank RAN K SIN K + 4 × Constante zal hebben. Wanneer de beste ouder moet gekozen worden zullen de ranks van de verschillende ouders vergeleken worden met elkaar, en zal de ouder met de laagste rank gekozen worden. Indien meerdere ouders dezelfde rank hebben zal een voorkeur gegeven worden aan die ouder met de beste linkkwaliteit (ETX waarde, zie hieronder). Om het constant wisselen van ouders bij kleine wijzigingen in de linkkwaliteit tegen te gaan moet een bepaalde drempelwaarde overschreden worden m.a.w. de linkkwaliteit moet minstens een vaste waarde (parameter MIN DIFFERENCE) beter zijn dan die van de huidige beste ouder.

3.9 ContikiRPL

32

Minimum Rank with Hysteresis Objective Function Bij het gebruik maken van deze objectief functie zal het pad met de beste kwaliteit gekozen worden. De kwaliteit van een pad wordt bepaald aan de hand van een zelf te kiezen metriek en zal typisch afgeleid worden uit de kwaliteiten van alle links/nodes op het pad (bv. door middel van een sommatie). Net zoals bij de vorige objectief functie zal het wisselen van ouders bij kleine wijzigingen in de kost van een pad worden tegengegaan door gebruik te maken van een drempelwaarde die moet overschreven worden alvorens gewisseld wordt van ouder. Het is eveneens mogelijk om aan te geven dat een link/node waarvoor de waarde van de gekozen metriek een bepaalde grens overschrijdt nooit genomen mag worden (parameter MAX LINK METRIC). Alsook kan een limiet worden opgelegd op de totale kost van een pad (parameter MAX PATH COST). Aangezien sommige metrieken (zoals de linkkwaliteit) in een korte periode zeer sterk kunnen verschillen wordt in de objectief functie gebruik gemaakt van een gewogen gewicht tussen de huidige waarde en de nieuwe waarde, op die manier kunnen wijzigingen in de metriekwaarde die van korte duur zijn worden opgevangen (door een groot aandeel van de huidige waarde te nemen en slecht een klein aandeel van de nieuwe waarde). Er zijn in ContikiRPL twee metrieken ondersteund in combinatie met deze objectief functie: de eerst is de “Expected Transmission Count (ETX)” van een link, de tweede is de resterende energiecapaciteit van een sensor. Aangezien bij de uitgevoerde testen gebruik gemaakt werd van de ETX waarde zal hier wat meer informatie over gegeven worden.

3.9.2

Expected Transmission Count

Deze metriek geeft aan hoeveel pakketten gemiddeld gezien verstuurd moeten worden over een link alvorens één pakket toekomt. De ETX waarde probeert m.a.w. de kwaliteit van een link te bepalen. Stel dat we ervoor kiezen om ETX te gebruiken als metriek in combinatie met de net besproken objectief functie (MRHOF), dan zal een node bij het uitsturen van een DIO bericht de rank instellen op de rank van zijn ouder + ETX waarde van de link naar de ouder × Constante. Concreet betekent dit dus dat de kwaliteit van alle links op het pad in rekening wordt genomen bij het berekenen van de rank. Wanneer een node dus de keuze heeft uit een pad bestaande uit twee links met ETX waardes 3 en 4, en uit een pad bestaande uit vier links met ETX waardes 2,2,1,1 zal gekozen worden voor het tweede pad.

3.9 ContikiRPL

33

Merk op dat gebruik maken van deze metriek om de link kwaliteit te bepalen een zeer conservatieve manier is, daar enkel gebruikte links getest worden. Een groot nadeel hiervan is dat niet afgeweken wordt van een bepaalde link zolang deze link niet (aanzienlijk) slechter wordt dan de gekende waardes van de omliggende links (deze waardes zullen typisch historische waardes zijn, daar de links al een tijd niet gebruikt werden). In ContikiRPL worden nieuwe links standaard de waarde 5 toegekend, dit betekent dus dat voor een ongebruikte link uitgegaan wordt dat minstens vijf pakketten verstuurd dienen te worden alvorens een pakket succesvol ontvangen wordt (uitgebreider besproken in sectie 5.3.1).

CONCEPT VOOR ONDERSTEUNING VOOR MEERDERE SINKS IN CONTIKIRPL

34

Hoofdstuk 4

Concept voor ondersteuning voor meerdere sinks in ContikiRPL 4.1

Introductie

Zoals reeds werd aangehaald kan het bij grote sensornetwerken nuttig zijn om het netwerk te voorzien van meerdere sinks, op die manier kan de levensduur van het netwerk immers aanzienlijk verhoogd worden. Naast de levensduur zullen extra sinks typisch ook een voordeel bieden t.o.v. delay en packet loss, aangezien typisch minder hops doorlopen moeten worden vooraleer de data arriveert aan de sink. Wanneer we kijken naar de RPL specificatie zien we echter dat er (momenteel) geen ondersteuning is voor meerdere sinks binnen één DODAG. Men zou dit echter wel kunnen simuleren door voor elke sink een DODAG op te bouwen en op die manier meerdere sinks te ondersteunen. Deze oplossing is ver van elegant en zal bovendien ook een groot deel extra geheugen vragen, aangezien informatie bijgehouden moet worden per DODAG waar de node deel van uitmaakt. Daarom werd dan ook een oplossing voor het ondersteunen van meerdere sinks binnen één DODAG uitgewerkt, deze zal in dit hoofdstuk besproken.

4.2

Ondersteunen van meerdere sinks in ContikiRPL

Om ondersteuning te bieden voor meerdere sinks binnen ContikiRPL werd gekozen om een “virtuele sink” in te voeren. Het idee is dat de sensornodes in het netwerk naar deze virtuele sink data zullen sturen en niet langer naar de “echte sinks”. Wanneer we het netwerk voorstellen

4.2 Ondersteunen van meerdere sinks in ContikiRPL

35

d.m.v. een DODAG wil dit zeggen dat de virtuele sink helemaal “bovenaan” de DODAG staat en dat de kinderen van deze top de “echte sinks” zijn. Het zal de taak zijn van de echte sinks om zich voor te doen als waren ze één en dezelfde “virtuele” node. Wanneer één van de nodes in het netwerk data verstuurd naar de virtuele sink zal deze sowieso via één van de echte sinks passeren (zie bijvoorbeeld figuur 4.1). Bij het binnenkrijgen van data bestemd voor de virtuele sink zal een echte sink deze data niet verder sturen (de virtuele sink bestaat immers niet) maar zal hij de data zelf afhandelen. Virtual Sink

Sink 2

Sink 1

1 2

5

4 3 6

Figuur 4.1: Voorbeeld van een DODAG met een virtuele sink Merk op dat door het gebruiken van een virtuele sink de overige sensoren zich niet bewust zijn van het feit dat er zich meerdere sinks bevinden in het netwerk (zie figuur 4.2). Dit heeft als grote voordeel dat er geen wijzigingen nodig zijn aan de niet-sink nodes. Sink

2

3

4

1

5

6

Figuur 4.2: Virtuele sink DODAG uit standpunt van niet-sink nodes Het gebruik maken van een virtuele node om meerdere sinks te ondersteunen wordt eveneens aangehaald in de RPL RFC [46] als een mogelijke manier om meerdere sinks te ondersteunen.

4.2 Ondersteunen van meerdere sinks in ContikiRPL

36

Er is echter geen uitwerking aanwezig van hoe dit in de praktijk mogelijk gemaakt kan worden (“out of scope for this specification”)

Om op deze manier meerdere sinks te ondersteunen is er een nood aan communicatie tussen de verschillende sinks. Het is immers de taak van deze sinks om zich voor te doen als de virtuele sink, dit betekent dus dat ze zich steeds in dezelfde toestand moeten bevinden (zelfde rank, ...). Concrete voorbeelden van communicatie tussen de sinks zijn bijvoorbeeld afspraken over de versie van de DODAG, (eventueel) de timing voor het uitsturen van DIO berichten, de routeringstabellen, ... Aangezien de communicatie tussen de sinks nodig is voor een goede werking van het netwerk is het belangrijk dat deze kan gebeuren over een “betrouwbaar kanaal”. Daarom is ervoor gekozen de communicatie niet te doen verlopen over het draadloos medium maar over een vast netwerk. Hoewel het in eerste instantie vreemd kan lijken dat de verschillende sinks moeten verbonden zijn via een betrouwbaar netwerk is dit in de praktijk vaak geen probleem. Sinks zullen immers vaak reeds verbonden zijn met één of ander betrouwbaar netwerk aangezien hun taak vaak is om data te verzamelen, (eventueel) te verwerken en vervolgens rapporteren aan bijvoorbeeld een databank, applicatie, ... Het is dan ook logisch dat wanneer we in dergelijke situaties extra sinks toevoegen aan ons draadloos sensornetwerk deze sinks eveneens toegang moeten hebben tot ditzelfde betrouwbaar netwerk. Merk op dat wanneer de sinks toch niet verbonden zouden zijn met een vast netwerk het nog steeds mogelijk zou zijn om hen toch te doen communiceren over het draadloos medium. We zullen dan wel rekening moeten houden met het feit dat bijvoorbeeld communicatie tussen de sinks een tijd onmogelijk kan zijn. Concreet zou dit willen zeggen dat in bepaalde situaties gewacht zou moeten worden tot alle sinks gecontacteerd zijn alvorens een bepaalde actie genomen kan worden. Hierbij denken we bijvoorbeeld aan een global repair, het uitvoeren van een global repair bestaat eruit het versienummer van de DODAG te verhogen en vervolgens een DIO uit te sturen met dit nieuw versienummer. Als dit worden uitgevoerd zonder eerst de overige sinks hiervan op de hoogte te brengen (m.a.w. ze weten niet af van het nieuwe versienummer) zouden deze een DIO bericht binnenkrijgen met een versienummer verschillend van hun versienummer en zou als gevolg door deze sinks eveneens een global repair worden opgestart (dit gebeurt immers wanneer een sink een mismatch ontdekt tussen het versienummer van een binnengekregen DIO bericht en het versienummer dat hij in zijn geheugen heeft staan). Dit betekent dus concreet

4.3 Routering

37

dat wanneer we over een draadloos medium zouden communiceren welk tijdelijk onbruikbaar raakt, de global repair zal moeten uitgesteld worden tot wanneer het draadloos medium terug bruikbaar is.

4.3

Routering

Het ondersteunen van meerdere sinks zoals voorgesteld in dit hoofdstuk zal ervoor zorgen dat er niet langer één fysieke sensor is die helemaal bovenaan de DODAG staat. Aangezien de sinks verantwoordelijk zijn voor het afhandelen van de data die bestemd is voor de virtuele sink betekent dit dat een sink in feite enkel kennis heeft van de sensoren die in zijn deelboom aanwezig zijn (zie figuur 4.3). Hoewel dit als nadeel heeft dat een sink typisch niet alle nodes rechtstreeks kan bereiken, is het voordeel dan weer dat alle sinks samen wel alle nodes kunnen bereiken en dat de routeringstabellen per sink kleiner zullen zijn. In grote netwerken is het mogelijk dat de routeringstabel van de sink niet langer volledig in zijn geheugen past, waardoor sommige nodes volledig onbereikbaar kunnen zijn. Door gebruik te maken van meerdere sinks worden deze routeringstabellen meer uitgespreid over de verschillende sinks. Sink 1

Sink 3

Sink 2

2 7

8

1 4 3

5

6

Figuur 4.3: Sinks hebben enkel kennis van de sensoren in hun eigen deelboom In de komende secties zal worden besproken welke invloed deze opsplitsing van routeringstabellen heeft op P2MP, MP2P en P2P verkeer.

4.3.1

Multipoint-to-point verkeer

Voor het contacteren van een sink is enkel nood aan opwaarts verkeer (zie vorige sectie). Aangezien elke node op zijn minst één sink kan bereiken door de data naar een van zijn ouders te sturen (zie figuur 4.1) is er geen probleem voor de ondersteuning van multipoint-to-point verkeer. Merk op dat, zoals reeds vermeld, het de taak is van de echte sinks om bij het ontvangen

4.3 Routering

38

van data die bestemd voor is de virtuele sink deze zelf af te handelen.

4.3.2

Point-to-multipoint verkeer

Aangezien een sink enkel de nodes die in zijn deelboom aanwezig zijn kan bereiken is het typisch niet mogelijk om, zonder aanpassingen, vanuit één sink alle nodes te bereiken (zo is het in figuur 4.3 voor sink 1 niet mogelijk om data te sturen naar node 4). In vele gevallen zal dit echter niet noodzakelijk een probleem zijn aangezien alle sinks samen wel alle nodes kunnen bereiken. Stel bijvoorbeeld dat we een applicatie hebben die periodiek informatie opvraagt aan de sensoren. Door ervoor te zorgen dat elke sink deze aanvragen doet zullen we uiteindelijk toch alle sensoren in het netwerk bereiken. Elke sink is m.a.w. verantwoordelijk voor de sensoren in zijn eigen deelboom.

Mocht het toch nodig zijn dat een sink sensoren in een andere deelboom rechtstreeks moet kunnen contacteren dan zal hiervoor communicatie tussen de sinks onderling vereist zijn. Aangezien er verschillende oplossingen mogelijk zijn zullen er hier enkele besproken worden (afhankelijk van de toepassing zou men dan kunnen kiezen voor de best passende oplossing). Pakket doorsturen naar de correcte sink Een eerste mogelijke oplossing is om de sinks, over het vast netwerk, te laten communiceren over hun routeringstabellen, m.a.w. we zorgen ervoor dat elke sink opnieuw alle sensoren in zijn routeringstabel heeft. Wanneer we deze aanpak gebruiken en dit toepassen op figuur 4.3 betekent dit dus dat sink 1 bijhoudt dat nodes 4 en 5 bereikbaar zijn via sink 2. Wanneer sink 1 nu node 5 contacteert zal dat gebeuren zoals weergegeven in figuur 4.4 Sink 1

Sink 3

Sink 2

2 7

1

8

4 3

5

6

Figuur 4.4: Sensoren in andere deelboom contacteren door data te forwarden naar de correcte sink Het nadeel van deze aanpak is dat het bij grote netwerken opnieuw mogelijk is dat er niet

4.3 Routering

39

voldoende plaats is in de routeringstabellen van de sinks voor alle sensoren. Pakket doorsturen naar alle sinks Een andere mogelijkheid om een sensor te contacteren die niet in de deelboom van een sink zit is om de data door te sturen naar alle sinks (eventueel via multicast). Op deze manier hoeft een sink niet voor alle sensoren een entry te hebben in zijn routeringstabel en blijven we dus het voordeel behouden van de gespreide routeringstabellen. Sink 1

Sink 3

Sink 2

2

1

8

7

5

4 3

6

Figuur 4.5: Sensoren in andere deelboom contacteren door data te forwarden naar alle sinks Het nadeel is uiteraard dat het pakket bij alle sinks toekomt in plaats van enkel bij de sink die de ontvanger kan bereiken. Pakket doorsturen naar centrale eenheid

Men zou er ook voor kunnen opteren om de

data eerst naar een centrale eenheid te sturen, waar wel voldoende geheugen aanwezig is voor het opslaan van grote routeringstabellen. Deze eenheid kan de data vervolgens direct doorsturen naar de correcte sink. Om dit mogelijk te maken zal communicatie nodig zijn tussen de sinks en de centrale eenheid voor het uitwisselen van de routeringstabellen. Men zou kunnen opteren voor dergelijke aanpak indien er toch al nood is aan een centrale eenheid voor bijvoorbeeld het verzamelen van de data. Centrale eenheid Sink 1

Sink 3

Sink 2

2 7

1 4

8 3

5

6

Figuur 4.6: Sensoren in andere deelboom contacteren door data te forwarden naar een centrale eenheid

4.3 Routering

40

Combinatie van bovenstaande methodes

Uiteraard zou men kunnen opteren voor een

combinatie van bovenstaande methodes, zo zou men bijvoorbeeld de eerste methode kunnen combineren met de tweede. Voor de sensoren waar een entry aanwezig is in de routeringstabel kan rechtstreeks de correctie sink gecontacteerd worden, indien geen entry aanwezig is (omdat er geen ruimte meer was om deze op te slaan) kunnen we de data multicasten naar alle sinks.

4.3.3

Point-to-point verkeer

Zoals gezien in sectie 3.6.3 is point-to-point communicatie typisch een combinatie van opwaarts en neerwaarts verkeer. Het is ook hier dus mogelijk dat een node wil communiceren met een node uit een andere deelboom. Mocht dit gebeuren zal de data dus opwaarts gaan tot aan de sink en vervolgens via één van de besproken methodes in vorige sectie de correcte deelboom bereiken (zie figuur 4.7). Sink 1

Sink 3

Sink 2

2 7

1

8

4 3

5

6

Figuur 4.7: Point-to-point verbindingen in multisink netwerk Merk op dat indien de nodes zich in verschillende deelbomen bevinden maar wel in elkaars bereik liggen het mogelijk is voor hen om rechtstreeks met elkaar te communiceren, zonder gebruik te maken van de DODAG (bijvoorbeeld nodes 4 en 6 in figuur 4.7).

IMPLEMENTATIE VAN DE ONDERSTEUNING VOOR MEERDERE SINKS

41

Hoofdstuk 5

Implementatie van de ondersteuning voor meerdere sinks In dit hoofdstuk zal meer in detail worden ingegaan op hoe de ondersteuning voor meerdere sinks exact werd ge¨ımplementeerd.

5.1

De virtuele sink

Zoals vermeld werd in 4.2 zullen de verschillende sinks zich voordoen als één en dezelfde virtuele sink en zal data die bestemd is voor deze virtuele sink afgehandeld moeten worden door een echte sink.

5.1.1

Anycast adressering

Om deze data afhandeling op een eenvoudige manier mogelijk te maken werd gekozen om gebruik te maken van anycast adressering [21]. Aan alle sinks wordt hetzelfde anycast adres toegewezen, wanneer een sensornode data wil sturen naar één van de sinks zal gebruik gemaakt worden van dit anycast adres. Voor het ontvangen van anycast data was echter wel een aanpassing aan Contiki noodzakelijk. Anycast pakketten werden immers standaard niet doorgegeven aan de applicatielaag, met als gevolg dat hoewel een pakket succesvol een sink bereikte de applicatie hier nooit van op de hoogte werd gesteld. Dit probleem viel bij het uitvoeren van de allereerste testen vrij snel op en door middel van een kleine aanpassing (naast controleren op unicast en multicast adressen eveneens controleren op anycast adressen) werd het probleem verholpen.

5.2 Communicatie tussen de sinks

42

Figuur 5.1: Anycast adressering

5.1.2

Parameters

Het is eveneens noodzakelijk dat de informatie die door de sinks uitgestuurd worden in een DIO bericht dezelfde is voor alle sinks. Parameters die voorkomen in deze berichten zijn (zie figuur 3.2): Grounded (heeft aan als een DODAG bv. geconnecteerd is met een ander IP netwerk), RPLInstanceId, DODAGId, DODAG rank en het DODAG sequentienummer. Met uitzondering van de laatste parameter, is er tussen de sinks onderling geen communicatie nodig met betrekking tot deze parameters aangezien deze niet meer kunnen wijzigen eens ze werden toegekend. De laatste parameter, het DODAG sequentienummer, kan wijzigen wanneer een sink een “global repair” uitvoert. Om die reden zullen de overige sinks gecontacteerd worden over de wijziging van deze parameter alvorens een “global repair” zal worden uitgevoerd. Aangezien enkel de sinks over de mogelijkheid beschikken om een “global repair” uit te voeren (en dus het sequentienummer te wijzigen) volstaat communicatie tussen de sinks onderling. Hoe deze communicatie exact verloopt wordt besproken in sectie 5.2.5.

5.2

Communicatie tussen de sinks

In sectie 4.2 werd uitgelegd waarom er een nood is aan communicatie tussen de verschillende sinks, in deze sectie zal besproken worden hoe deze communicatie ge¨ımplementeerd werd.


5.2.1

43

Gecentraliseerd

Voor de communicatie tussen de verschillende sinks werd gekozen om deze te laten gebeuren op een gecentraliseerde manier. Hiermee wordt bedoeld dat de sinks communiceren met elkaar zoals dit gebeurt in een client-server architectuur, m.a.w. er wordt één centrale node aangesteld die de communicatie tussen de verschillende sinks zal verzorgen. De sinks zullen dus bij een wijziging, van bijvoorbeeld het versienummer, de centrale node contacteren, welke de overige sinks zal contacteren. De keuze voor een gecentraliseerde aanpak werd gemaakt om verschillende redenen. Zo is er bij het gebruik van meerdere sinks vaak sowieso nood aan een bepaalde centrale eenheid die de data van de verschillende sinks verzamelt. Men zou deze eenheid dan eveneens kunnen gebruiken voor deze communicatie. Verder is een gecentraliseerde aanpak ook een stuk eenvoudiger te ontwerpen (bij een gedistribueerde aanpak zouden we bijvoorbeeld nood hebben aan een discovery methode zodat we weten welke sinks we allemaal moeten contacteren). Tot slot kunnen we met zeer weinig informatie deze communicatie tot stand brengen aangezien we enkel maar het adres van de centrale eenheid moeten kennen.

5.2.2

Serial Line IP

Aangezien de communicatie tussen de sinks onderling bij voorkeur gebeurd over een betrouwbaar netwerk, werd gekozen om gebruik te maken van Serial Line IP (SLIP)[34]. Het is een zeer eenvoudig protocol dat in feite niets meer doet dan “packet framing”. Het neemt als input een reeks van pakketten, voegt achteraan elk pakket een terminatie karakter toe, en stuurt dit over een seriële link. Indien het pakket reeds terminatie karakters bevatten dan worden deze aangeduid door ze te laten voorgaan door een “escape” karakter. De keuze voor SLIP werd gemaakt aangezien we werken met sensoren en deze typisch niet beschikken over bijvoorbeeld ethernet poorten, ze beschikken echter bijna allemaal wel over één of meerdere seriële poorten. De lage snelheid van seriële verbindingen (snelheden liggen typisch tussen de 2,4 en 115kb/s) is eveneens geen probleem aangezien geen grote hoeveelheden data dienen verstuurd te worden.

5.2.3

Opstelling

In figuur 5.2 wordt een schematische voorstelling gegeven van een opstelling waarbij de twee sinks communiceren met de “registrar” door middel van SLIP. Merk op dat in deze figuur bij de registrar twee verschillende SLIP verbindingen toekomen, concreet zou dit betekenen dat de


44

registrar dient te beschikken over evenveel seriële poorten als er sinks zijn. Sensoren zullen echter typisch maar beschikken over een beperkt aantal seriële poorten (vaak maar één of twee), hoewel multiplexen van meerdere seriële verbindingen over één fysieke kabel niet onmogelijk is [36], is het verre van eenvoudig en elegant.

Registrar

Serial Line IP

Serial Line IP

Sink 2 Sink 1

Figuur 5.2: Communicatie tussen de sinks De werkelijke opstelling zal er dan ook eerder uitzien zoals weergegeven in figuur 5.3. De sinks en de registrar zullen verbonden zijn met een toestel (bv. een embedded pc) dat beschikt over een ethernet kaart, en er zal enkel tussen het toestel en de sensornode gebruik gemaakt worden van SLIP communicatie. De verschillende toestellen zullen verbonden zijn via een vast netwerk om zo onderlinge communicatie mogelijk te maken. Door gebruik te maken van dergelijke opstelling is er per sink/registrar maar nood aan één seriële poort en is communicatie tussen de sinks en registrar mogelijk door de sequentie SLIP-Ethernet-SLIP. Merk op dat hoewel de registrar in deze opstelling weergegeven is als een sensornode dit niet strikt noodzakelijk is, men zou ook kunnen beslissen om deze te implementeren op het toestel zelf i.p.v. op een sensornode.


45

Registrar

Serial Line IP

Ethernet

Serial Line IP

Ethernet

Serial Line IP

Sink 2 Sink 1

Figuur 5.3: Communicatie tussen de sinks

5.2.4

Tunslip

In Contiki is er reeds ondersteuning voor SLIP communicatie. Er is eveneens een tool [40] aanwezig die het mogelijk maakt om op een eenvoudige manier te communiceren met toestellen die gebruik maken van SLIP. De tool (tunslip) maakt een SLIP tunnel aan tussen een fysieke seriële poort en een virtuele netwerkadapter. Deze virtuele netwerkadapter kan gebruikt worden alsof het een echte netwerkadapter is, we denken hierbij aan zaken zoals “traffic forwarding”, het analyseren van SLIP verkeer d.m.v. Wireshark, ... Door gebruik te maken van tunslip vereenvoudigt dit sterk de communicatie tussen een sink die gebruikt maakt van SLIP en overige apparaten die typisch geconnecteerd zijn met netwerkadapters, het enige wat we hoeven te doen is de routeringstabellen correct instellen. Wanneer we opnieuw kijken naar de opstelling die gegeven is in figuur 5.3 kan tunslip bijvoorbeeld gebruikt worden op de toestellen om op deze manier eenvoudig een brug te kunnen leggen tussen de seriële poort en de Ethernet adapter.


5.2.5

46

De communicatie

Aangezien op een client-server manier wordt gecommuniceerd, werden twee “applicaties” ontwikkeld binnen Contiki voor het ondersteunen van deze communicatie. De ene applicatie (server) zal bijhouden welke sinks allemaal aanwezig zijn in een DODAG, alsook enkele paramaters van deze DODAG (bijvoorbeeld het versienummer). Deze applicatie zal eveneens de sinks contacteren wanneer een parameter wijzigt (dit is bijvoorbeeld het geval wanneer een global repair wordt uitgevoerd). De node die deze applicatie gebruikt zullen we voortaan aanduiden met de registrar. De andere applicatie, die zal uitgevoerd worden door elke sink, maakt het mogelijk om te communiceren met deze registrar. a)

Registreren van een sink

Wanneer een sink opstart zal deze zich eerst registreren bij de registrar. De bedoeling van dit proces is om ervoor te zorgen dat de registrar weet dat deze sink aanwezig is in het netwerk en dus op de hoogte moet gehouden worden van parameter wijzigingen. Ook worden de huidige parameters doorgegeven zodat de sink kan beginnen met het uitsturen van DIO berichten.

Registrar

Sink 1

Sink 2

Register create DAG DAG created

Register DAG exists

Figuur 5.4: Communicatie tijdens het opstarten van een sink Zoals we zien in figuur 5.4 zal sink 1 aan de registrar laten weten dat hij opgestart is en informatie wil verkrijgen over een DODAG (wordt bepaald a.d.h.v. het DODAGId). Aangezien sink 1 de eerste sink is die zich registreert zal de registrar hierop antwoorden met een bericht dat aangeeft dat nog geen informatie aanwezig is voor de DODAG waarvoor de registratie werd aangevraagd en dat de sink zelf een DODAG mag opstarten. De sink zal beginnen met het uitsturen van DIO berichten en de gekozen parameters meedelen aan de registrar. Wanneer


47

een tweede sink zich nu registreert zal de registrar deze keer wel beschikken over informatie van de DODAG en zal hij deze informatie doorsturen naar de nieuwe sink. Deze zal vervolgens de ontvangen parameters correct instellen en ook beginnen met het uitsturen van DIO berichten. Afhankelijk van de gebruikte objectief functie kan eventueel geopteerd worden om telkens dat een nieuwe sink zich registreert eveneens een global repair uit te voeren (zie sectie hieronder) om op die manier ervoor te zorgen dat de DODAG volledig opnieuw opgebouwd wordt. In de uitgevoerde testen werd dit niet gedaan aangezien de gebruikte objectief functie (MRHOF) de ouders kiest aan de hand van hun rank, wat dus betekent dat wanneer een node zich dichter bij de tweede sink bevindt (en de kwaliteit van het pad naar deze sink is van dezelfde aard als de kwaliteit van het pad naar de eerste sink) de node sowieso zal wisselen van sink. b)

Uitvoeren van een global repair

Er werd reeds vermeld in hoofdstuk 4 dat wanneer een sink een global repair wil uitvoeren hij hier eerst de overige sinks van op de hoogte moet brengen. Registrar

Sink 1

Sink 2

aanvraag global repair nieuw versienummer

nieuw versienummer

start global repair

start global repair

Figuur 5.5: Communicatie voor het uitvoeren van een global repair In figuur 5.5 wordt de communicatie die nodig is om een global repair uit te voeren weergegeven. De sink die een global repair wenst uit te voeren zal de registrar hiervan op de hoogte brengen. Het uitvoeren van een global repair heeft als gevolg dat het versienummer van de DODAG verhoogd wordt. De registrar zal de overige sinks contacteren om het nieuw versienummer bekend te maken. Merk op dat hoewel de sinks reeds gecontacteerd werden over het nieuwe versienummer deze momenteel nog niet zal worden uitgestuurd in DIO berichten. Dit is om te voorkomen dat een sink al een DIO bericht zou binnenkrijgen met een nieuw versienummer alvorens hij op de hoogte werd gebracht van dit nieuw nummer (wat zou resulteren

5.3 Aanpassingen aan ContikiRPL

48

in een nieuwe global repair). Eens alle sinks gecontacteerd werden in verband met het nieuw versienummer zullen ze de toestemming krijgen van de registrar om dit nieuw nummer uit te sturen in de DIO berichten (en dus de global repair uit te voeren). Merk op dat het nog steeds mogelijk is dat een sink een DIO bericht binnenkrijgt met het nieuw versienummer alvorens hij op de hoogte werd gebracht van de toestemming dit nummer uit te sturen. Indien dergelijke situatie zich voordoet dan zal deze sink geen nieuwe global repair uitvoeren maar eveneens het nieuw versienummer beginnen uit te sturen (aangezien dit betekent dat een andere sink reeds de toestemming had gekregen).

5.3

Aanpassingen aan ContikiRPL

5.3.1

Initi¨ ele ETX waarde

In sectie 3.9.2 werd reeds vermeld dat voor nieuwe links de ETX waarde standaard op 5 wordt ingesteld. Er wordt dus vanuit gegaan dat gemiddeld gezien een pakket vijf keer dient verstuurd te worden alvorens het ontvangen wordt. Een mogelijk probleem dat kan optreden door het kiezen van een hoge initiële ETX waarde wordt weergegeven in figuur 5.6. 1 5

1

2

2

5

2

3

4

5

1

1

2

5 3

4

5

2

5 5

2

5 5

5

Werkelijke ETX waardes

4,6

2

1

1 4,5

4 3

4

5

Nodes 2, 3 en 4 kiezen node 1 als ouder (stap 2)

Initiële voorstelling (stap 1)

1 4,5

5 5

4,6

2

2

4 3

4

5

2

2

Node 5 kiest 2 als voorkeursouder (stap 4)

1 3

4

5 5

5 5

ETX waardes op moment dat node 5 DIO berichten ontvangt van 2 en 4 (stap 3)

3

4

5

5

5

5

5

Node 5 zal nooit node 4 als voorkeursouder kiezen (stap 5)

Figuur 5.6: Topologie opbouw met een initiële ETX waarde van 5 In de voorstelling linksboven worden de werkelijke ETX waardes van de links weergegeven,


49

en zoals vermeld wordt in Contiki geopteerd om alle links initieel de waarde 5 toe te kennen (stap 1). Stel nu dat we in de situatie terecht komen waar node 5 DIO berichten ontvangt van de nodes 2 en 4 (stap 3), we zien dat de kwaliteit van link 1-2 op dat moment beter is dan die van 1-4 zal node 5 dus kiezen om node 2 als voorkeursouder in te stellen (stap 4). Aangezien de link 4-5 niet gebruikt zal worden door node 5, zal de ETX waarde ook niet aangepast worden. Zolang de kwaliteit van het pad 1-2-5 niet slechter wordt (merk op dat eveneens een drempelwaarde overschreden moet worden, zie sectie 3.9.1) dan de kwaliteit van het pad 1-4-5 zal node 5 nooit gebruik maken van de link 4-5 hoewel deze mogelijk een stuk beter is (wat in het voorbeeld het geval is). Merk op dat wijzigingen in de kwaliteit van het pad 1-4-5 volledig afhangt van de kwaliteit van link 1-4 zolang link 4-5 niet gebruikt wordt. Een mogelijke oplossing voor dit probleem is om data te versturen over links die niet gebruikt worden om op die manier de kwaliteit van de links proberen te bepalen. Een andere mogelijk oplossing is om de ETX waarde initieel zeer laag in te stellen, dit wordt eveneens voorgesteld in [11], het voordeel hiervan zal nu kort besproken worden.

In [11] wordt voorgesteld om een nieuwe link initieel als perfect te bestempelen (m.a.w. ETX=1). Door op deze manier te werk te gaan, worden ongebruikte links typisch snel gekozen als beste link met als gevolg dat data verstuurd zal over deze link. Hierdoor zal de ETX waarde steeds dichter in de buurt komen van de werkelijke waarde (de snelheid waarmee dit gebeurd is afhankelijk van hoeveel de oude ETX waarde doorweegt tijdens het berekenen van het gewogen gemiddelde). Vanaf het moment dat de ETX waarde hoger is dan die van een andere ouder wordt opnieuw gewisseld van voorkeursouder. Door op deze manier te werk te gaan en dus geen onnodige data te versturen over niet gebruikte links kan het energieverbruik van de nodes lager gehouden worden. Het nadeel is dat in netwerken waar de ETX waardes van de links gedurende lange periodes sterk kan verschillen we opnieuw in een situatie kunnen terecht komen zoals besproken in het vorige voorbeeld en dat in het begin typisch vaak veranderd zal worden van voorkeursouder. In figuur 5.7 wordt het voorbeeld uit figuur 5.6 opnieuw overlopen maar deze keer met de aanpassing dat ongebruikte links de waarde 1 toegekend krijgen in plaats van 5. We zien opnieuw dat node 5 in stap 4 de link 2-5 kiest als beste link maar waar in het vorig voorbeeld nooit meer werd afgestapt van deze link is dit hier niet langer het geval. Op een bepaald moment zal de kwaliteit van het pad 1-2-5 slechter worden dan de kwaliteit van het pad 1-4-5 (stap 5) en zal


50

1 1

1

2

2

1

2

3

4

5

1

1

2

3

4

1

2

1

1

1

2

1 5

5

Werkelijke ETX waardes

1,3

2

1

1 1,2

1 3

4

1

Nodes 2, 3 en 4 kiezen node 1 als ouder (stap 2)

Initiële voorstelling (stap 1)

1 1,2

1,3

2

1,8

1 3

4

1

1

ETX waardes op moment dat node 5 DIO berichten ontvangt van 2 en 4 (stap 3)

1,8

1

Node 5 kiest 2 als voorkeursouder (stap 4)

De kwaliteit van het pad 1-2-5 is op een bepaald moment slechter dan van pad 1-4-5 (drempelwaarde = 1) (stap 5)

1 2

1

4

2

3

5

1 1,8

1

4

2

5

2

1,8

2

5

5

3

4

1

1

5

1

3

2

2

1 3

4

2 2

1 5

5

Node 5 zal veranderen van voorkeursouder (stap 6)

Node 4 blijft de voorkeursouder van Node 5 (stap 7)

Figuur 5.7: Topologie opbouw met een initiële ETX waarde van 1 dus veranderd worden van voorkeursouder (stap 6). Merk op dat een pad maar als slechter zal worden bestempeld eens de drempelwaarde is overschreden (zie stap 5). Vanaf nu zal het pad 1-4-5 gebruikt worden, wat eveneens het beste pad is van node 5 naar de sink. Hoewel het in dit voorbeeld niet voorkwam is het mogelijk dat eerst enkele keren heen en weer gesprongen wordt tussen de paden alvorens het netwerk zich stabiliseert (dit zou het geval geweest zijn indien de werkelijke ETX van pad 4-5 meer dan 3 bedroeg).

In de uitgevoerde testen werd de initiële ETX waarde voor een ongebruikte link eveneens ingesteld op 1 in plaats van de standaard waarde 5.


5.3.2

51

Maximaal toegestane kost van een link

In sectie 3.9.1 werd vermeld dat wanneer gebruik gemaakt wordt van de “Minimum Rank with Hysteresis Objective Function” ervoor gekozen kan worden om een link met een te hoge kost nooit te gebruiken (in te stellen via de parameter MAX LINK METRIC). Bij de uitgevoerde performantietesten werd echter een een kleine aanpassingen gemaakt aan de werking van deze parameter. In plaats van een node altijd te verbieden om een link met een te hoge kost te nemen, werd een aanpassing doorgevoerd zodat het toch toegestaan is dergelijke link te nemen indien geen alternatief pad gevonden kan worden. Deze aanpassing werd gemaakt omdat bij het uitvoeren van de eerste real-life testen bleek dat de ETX waarde van een link vaak niet in overeenstemming was met de werkelijke kwaliteit van een link. De reden hiervoor was dat in de real-life testen het vaak voorkwam dat de kwaliteit van een link in de ene richting veel beter was dan in de andere. Zoals reeds eerder vermeld staat de ETX waarde van een link voor het gemiddeld aantal keer dat een pakket verstuurd moet worden alvorens het succesvol ontvangen werd. In Contiki zal een pakket opnieuw verstuurd worden indien na een bepaalde periode nog geen Acknowledgement (ACK) pakket ontvangen werd (dit gebeurt op de MAC laag). Wanneer we communiceren over een link waar de kwaliteit sterk afhankelijk is van de richting waarin verstuurd wordt, is het mogelijk dat pakketten de ouder zo goed als altijd bereiken maar dat de ACK pakketten nooit ontvangen worden. Dergelijke situatie zal dan ook leiden tot het toekennen van een zeer hoge ETX waarde aan de link. Bij het uitvoeren van de real-life testen werd vastgesteld dat deze situatie zich soms voor bepaalde nodes voordeed bij al hun ouders en de node bijgevolg geen enkele ouder meer kon kiezen. Wanneer deze nodes zich op een belangrijk knooppunt in het netwerk bevinden is het mogelijk dat een groot deel van het netwerk op die manier onbereikbaar wordt. Door een node niet te verbieden een link met een te hoge ETX waarde te kiezen wanneer alle links een waarde hebben die groter is dan MAX LINK METRIC kan het probleem, dat hierboven besproken werd, enigszins verholpen worden (merk op dat dit typisch wel gepaard zal gaan met een hogere energieverbuik van deze node).

PERFORMANTIE BIJ HET GEBRUIK VAN MEERDERE SINKS

52

Hoofdstuk 6

Performantie bij het gebruik van meerdere sinks 6.1

Introductie

In dit hoofdstuk zullen de uitgevoerde performantietesten worden besproken. Deze werden zowel uitgevoerd in een simulatie omgeving als in een real-life omgeving. De opstelling die gebruikt werd voor simulatie alsook bijhorende resultaten zullen besproken worden in 6.4. Voor de reallife testen werd gebruik gemaakt van het iMinds w-iLab.t office testbed [29]. De opstelling en de resultaten van deze testen zijn terug te vinden in 6.5

6.2

Test applicatie

Om de performantie van het netwerk te testen werd gebruik gemaakt van een meegeleverde voorbeeldapplicatie in Contiki, rpl-collect genoemd. Alle nodes die de applicatie draaien sturen periodiek een data pakket naar de sink. Dit data pakket bevat informatie zoals de rank van de node, het aantal ouders, de voorkeursouder, de metriekwaarde naar de voorkeursouder, een volgnummer (om pakket loss te kunnen berekenen), de verbruikte energie (Low Power Mode, CPU, Transmit, Receive), ... Uit deze informatie is het mogelijk om een beeld te vormen van de DODAG structuur op een gegeven moment, informatie over de hoeveelheid packet loss, hoe de kwaliteit van de links doorheen de tijd wijzigt, ... De periode waarmee de data pakketten worden verstuurd bedraagt 50 seconden. Er werd eveneens met een random back-off periode van 20 seconden toegevoegd om ervoor te zorgen dat de pakketten niet allemaal op exact hetzelfde

6.3 Gebruikte tools

53

moment verstuurd worden. In de uitgevoerde performantietesten zal voornamelijk de invloed van het aantal gebruikte sinks op het gemiddeld aantal hops, het energieverbruik en de packet loss nagegaan worden.

6.3 6.3.1

Gebruikte tools Collect-view applicatie

Er is in Contiki een Java applicatie meegeleverd om de rpl-collect data pakketten te verwerken en de informatie eruit grafisch voor te stellen (denk hierbij aan het maken van grafieken, het visualiseren van de DODAG, ...) (zie figuur 6.1).

Figuur 6.1: Screenshot van de collect-view applicatie Voor deze thesis werden enkele aanpassingen gemaakt aan deze collect-view applicatie die nu kort besproken zullen worden. Communicatie over TCP/IP

De eerste aanpassing heeft betrekking op hoe de data de

applicatie bereikt. Wanneer we kijken in de meegeleverde code (rpl-collect) wordt gebruik gemaakt van een seriële poort om te communiceren met de applicatie. De sink zal m.a.w. de data verzamelen over het draadloos medium en deze vervolgens doorsturen naar de Java applicatie over een seriële verbinding. Aangezien gebruik gemaakt wordt van het SLIP protocol voor de

6.3 Gebruikte tools

54

communicatie tussen de sinks, kan de seriële poort niet langer gebruikt worden voor het contacteren van de Java applicatie. Om die reden werd ondersteuning voor TCP/IP toegevoegd aan de applicatie. Op deze manier kan de data verstuurd worden over de SLIP tunnel (m.b.v. tunslip) naar de machine waarop de applicatie draait. Ondersteuning voor meerdere sinks Aangezien de RPL standaard geen ondersteuning biedt voor meerdere sinks binnen één DODAG, is in deze applicatie ook geen ondersteuning aanwezig om data binnen te krijgen van verschillende bronnen. Bij het inbouwen van TCP/IP ondersteuning werden eveneens enkele aanpassingen doorgevoerd zodat het mogelijk is meerdere connecties op te zetten naar de applicatie. Op deze manier kunnen de sinks de applicatie rechtstreeks contacteren zonder dat er nood is aan een collector die de data van de verschillende sinks samenvoegt. Inladen van posities van de nodes De collect-view applicatie biedt ondersteuning voor het visualiseren van de DODAG, wat zeker en vast een groot hulpmiddel is om een beter inzicht te krijgen in hoe het netwerk zich gedraagt, om resultaten te kunnen verklaren en de implementatie te kunnen testen. Een nadeel echter is dat de posities van de nodes verloren gaan bij het afsluiten van de applicatie. Om deze reden werd er een exporteer en importeer functie ingebouwd om op een eenvoudige manier de posities van de sensornodes in te stellen.

Figuur 6.2: Collect-view: DODAG op fysieke topologie Voor de real-life testen opstelling op iMinds w-iLab.t werd eveneens een achtergrond afbeel-

6.3 Gebruikte tools

55

ding ingeladen zodat de DODAG visueel kon worden weergegeven op de fysieke topologie van het netwerk. Exporteren van de verwerkte gegevens

Om een eenvoudige verwerking van de gegevens

mogelijk te maken werd eveneens een functie toegevoegd om de data te exporteren naar een CSV bestand.

6.3.2

COOJA simulator

Voor de simulatieomgeving werd gebruikt gemaakt van de COOJA simulator [15] [30]. Eén van de zaken waarin de COOJA simulator zich onderscheid is de mogelijk om nodes op drie verschillende lagen te simuleren: de netwerk laag, de besturingssysteem laag en de machine instructie laag [31]. Het is eveneens de simulator die wordt meegeleverd met Contiki Unit Disk Graph Medium Als “link failure model” werd gebruik gemaakt van het “Unit Disk Graph Model (UDGM)” (zie figuur 6.3). In dit model wordt gebruik gemaakt van twee afstandsparameters: de transmissieafstand (de maximale afstand waarop een pakket nog kan ontvangen worden) en de interferentieafstand (de maximale afstand vanaf een bepaald node waar een verzonden pakket nog kan zorgen voor interferentie m.a.w. de grootte van “collision domain” van een node). De transmissie- en interferentieafstand worden bepaald door het zendvermogen van de nodes, in COOJA kunnen deze twee parameters afzonderlijk van elkaar worden ingesteld. Er wordt eveneens gebruik gemaakt van twee ratioparameters: de verzendratio (het percentage pakketten dat succesvol verzonden wordt) en de ontvangstratio (het percentage pakketten dat succesvol ontvangen wordt).

Figuur 6.3: Unit Disk Graph Model In UDGM zal de kans dat een pakket ontvangen wordt toenemen naarmate de afstand tussen

6.4 Simulatie

56

de nodes afneemt. De berekening van deze kans wordt weergegeven in de formule hieronder, waarbij D staat voor de afstand tussen de zender en ontvanger, R voor de transmissieafstand van de zender, RX voor de ontvangstratio en TX voor de verzendratio.

P(pakket onvangen) = T X × 1 − D2 /R2 × (1 − RX)

(6.1)

Uit formule (6.1) kunnen we afleiden dat de verzendratio (T X) zorgt voor een schaling van de kans, wat logisch is aangezien we een kans T X hebben dat een pakket verstuurd wordt. De kans op het succesvol ontvangen van een pakket het laagst is voor de nodes die zich exact op de maximale transmissieafstand bevinden. Wanneer we stellen dat T X = 1, is deze kans gelijk is aan RX. We zien eveneens dat naarmate de afstand tussen de nodes (D) verkleint, de kans op het succesvol ontvangen van een pakket vergroot.

6.4

Simulatie

6.4.1

Opstelling

De opstelling waarop performantietesten werden uitgevoerd is weergegeven in figuur 6.4. De opstelling bestaat uit één registrar (node 1), vier sinks (nodes 2-5) en dertig nodes (7-36) die periodiek data pakketten versturen zoals uitgelegd in sectie 6.2. De nodes die verantwoordelijk zijn voor het versturen van de pakketten werden in vijf rijen van zes nodes geplaatst en bevinden zich onderling op een afstand van 20 meter. Vervolgens werden vier sinks rond deze nodes geplaatst (telkens in het midden van de bijhorende zijde). De transmissieafstand van de sensornodes bedraagt 25 meter, de interferentieafstand 35 meter. Om de ontwikkelde ondersteuning voor meerdere sinks te testen en de invloed van het gebruik van meerdere sinks op de performantie van het netwerk na te gaan werden de performantietesten eerst uitgevoerd met één sink, vervolgens met twee, ... Het invoeren van extra sinks gebeurde aan de hand van hun id, hiermee wordt bedoeld dat eerst enkel sink 2 geactiveerd werd, vervolgens sinks 2 en 3, dan 2, 3 en 4 en tot slot sinks 2, 3, 4 en 5.

6.4 Simulatie

57

Figuur 6.4: COOJA opstelling: gridstructuur

6.4.2 a)

Resultaten

Invloed van het aantal te nemen hops

Uiteraard zal de afstand van een node (in termen van aantal hops) tot de dichtstbijzijnde sink een invloed uitoefenen op het gemiddeld aantal verloren pakketten en het totaal energieverbruik van de node. Er werden dan ook enkele testen uitgevoerd om hiervan een beter beeld te krijgen. In deze testen werd steeds gebruik gemaakt van één sink en de resultaten ervan zullen later nog worden gebruikt om de performantie winsten bij het gebruik van meerdere sinks te kunnen verklaren. 25%

AANTAL NODES (%)

20%

15%

10%

5%

0% 1-2

2-3

3-4

4-5

5-6

6-7

7-8

AANTAL HOPS

Figuur 6.5: Verdeling van de nodes in functie van het aantal hops dat ze verwijderd zijn van de sink

6.4 Simulatie

58

Verdeling van de nodes

In figuur 6.5 wordt de verdeling van de nodes in functies van het

gemiddeld aantal hops dat ze verwijderd zijn van de sink weergegeven. Pakketverlies

In figuur 6.6 wordt de kans op pakketverlies in functie van het aantal hops

weergegeven. Voor het uitvoeren van deze test werd het maximaal aantal transmissies van een pakket op één ingesteld en werd gekozen voor een ontvangstratio (RX) (zie sectie 6.3.2) van 50%. 100%

Verloren pakketten (%)

90% 80%

70% 60% 50% 40% 30% 20% 10% 0% 1

2

3

4

Aantal hops

5

6

7

8

Figuur 6.6: Percentage van pakketten dat verloren gaat in functie van het aantal hops dat moet genomen worden Naarmate het aantal hops stijgt zien we dat eveneens de kans op pakketverlies sterk toeneemt. Eens (gemiddeld gezien) meer dan vier hops genomen moeten worden, gaan al meer dan de helft van de data pakketten verloren. Een reductie van het gemiddeld aantal hops kan dus zeker bijdragen tot minder pakketverlies. Een andere mogelijkheid om het pakketverlies te reduceren is door het maximaal aantal transmissies (van een pakket) te verhogen. Energieverbruik

Ook het gemiddeld energieverbruik in functie van het gemiddeld aantal hops

(naar de sink) werd nagegaan. In eerste instantie werd de test uitgevoerd op een netwerk waar geen interferentie aanwezig is (m.a.w. ontvangstratio=100%). De bekomen resultaten hiervan zijn terug te vinden in figuur 6.7. Hier zien we duidelijk dat de sensor nodes die zich dichter bij de sink bevinden typisch ook meer energie zullen verbruiken. Dit is eenvoudig te verklaren door het feit dat deze sensoren verantwoordelijk zijn voor het forwarden van data die afkomstig

6.4 Simulatie

59

is van een groot aantal andere sensoren in het netwerk (m.a.w. ze hebben een grotere deelboom wanneer we kijken naar de DODAG). 1,2

Energieverbruik (mW)

1 0,8 0,6 0,4 0,2

0 0

1

2

3

4

5

6

7

Gemiddeld aantal hops Figuur 6.7: Gemiddeld energieverbruik in functie van de afstand tot de sink (aantal hops) (ontvangstratio=100%) (lineaire trendlijn) In bovenstaande resultaten werd uitgegaan dat geen interferentie optreedt in het draadloos medium, uiteraard is dit in fysieke draadloze sensornetwerk niet het geval. De ontvangstratio werd dan ook verlaagd tot 50% (m.a.w. de interferentie werd verhoogd) om zo een realistischer opstelling te verkrijgen. Wanneer we nu de resultaten bekijken zien we meer spreiding in het energieverbruik (zie figuur 6.8). Aangezien nu meer kans is op pakketverlies is het aannemelijker dat de trickle timer (vaker) gereset zullen worden (wegens het optreden van een inconsistentie door verloren gegaan controle pakketten, zie sectie 3.7). Dit zal ervoor zorgen dat, door RPL, meer controle berichten verstuurd worden (en dit resetten zal niet noodzakelijk bij alle nodes even vaak voorkomen). We zien wel nog steeds dat nodes die zich ver van de sink bevinden (meer dan 6 hops) gemiddeld gezien minder energie zullen verbruiken. Het is echter niet langer zo dat de nodes met het grootste energieverbruik zich voornamelijk dicht bij de sink bevinden. Aangezien het mogelijk is dat controle pakketten verloren gaan kan dit in bepaald situaties resulteren in lus vormingen in de DODAG. Indien dit gebeurd zullen extra controle pakketten (DIS en DIOs) uitgestuurd worden om deze lusvorming op te lossen (local repair). Vandaar dat vooral de nodes die zich eerder “in het midden” van het netwerk bevinden nu ook vaker zullen behoren tot de

6.4 Simulatie

60

grotere energieverbruikers (nodes in het begin en op het einde hebben immers minder kans om een lus te vormen). Uiteraard speelt de verhouding tussen applicatie data en controle data eveneens een grote rol in de bekomen grafiek. In de uitgevoerde testen is de hoeveelheid applicatie data vrij beperkt (tussen twee opeenvolgende pakketten zit ongeveer een minuut) wat betekent dat de controle data een grotere invloed zal hebben op het gemiddelde energieverbruik. Indien de totale hoeveelheid data die verstuurd wordt voornamelijk bestaat uit applicatie data zal het energieverbruik voornamelijk bepaald worden door het forwarden van deze datapakketten (wat dus betekent dat nodes die zich dichter bij de sink bevinden meer energie zullen verbruik dan nodes die zich verder bevinden). 1,8


1,6 1,4 1,2 1

0,8 0,6 0,4

0,2 0 1

2

3

4

Aantal hops

5

6

7

8

Figuur 6.8: Gemiddeld energieverbruik in functie van de afstand tot de sink (aantal hops) (ontvangstratio=50%)(lineaire trendlijn)

b)

Invloed van het gebruik van meerdere sinks

In deze sectie zullen de resultaten met betrekking tot het gebruik van meerdere sinks worden besproken. De besproken resultaten zijn afkomstig uit de performantietesten die werden uitgevoerd met een ontvangstratio van 50% en waarbij maximaal één retransmissie is toegestaan. DODAG structuur Om een idee te krijgen van hoe de pakketten gerouteerd worden in het netwerk werd de opgebouwde DODAG bij het gebruiken van één sink vergeleken met de opgebouwde DODAG wanneer gebruik gemaakt wordt van vier sinks. Deze zijn terug te vinden in

6.4 Simulatie

61

figuren 6.9 en 6.10.

Figuur 6.9: DODAG bij gebruik van één sink

6.4 Simulatie

62

Figuur 6.10: DODAG bij gebruik van vier sinks Uit de figuren 6.9 en 6.10 kunnen we afleiden dat de implementatie zich gedraagt zoals verwacht. De sensor nodes bouwen niet langer één grote DODAG op, maar er wordt nu als het ware per sink een DODAG opgebouwd (merk op dat indien we de virtuele sink zouden toevoegen aan de DODAG we wel opnieuw één DODAG zouden bekomen). Ten gevolge van deze opsplitsing is de gemiddelde afstand tot de sink lager en wordt de data eveneens meer verspreid over het netwerk. Aantal hops Naast de correcte werking van de implementatie kan uit de figuren 6.9 en 6.10 eveneens worden afgeleid dat het gemiddeld aantal hops tot de dichtstbijzijnde sink afneemt naarmate extra sinks aan het netwerk worden toegevoegd. Deze stelling wordt bevestigd in figuur 6.11 waar het gemiddeld aantal hops wordt uitgezet in functie van het aantal sinks. Het

6.4 Simulatie

63

maximaal en minimaal aantal hops werd eveneens aangeduid in de grafiek. 8

Gemiddeld aantal hops

7 6 5 4,218

4

3,517 2,795

3

2,243

2 1 0

1

2

Aantal sinks

3

4

5

Figuur 6.11: Gemiddeld aantal hops in functie van aantal sinks Naast een vermindering van het gemiddeld aantal hops is eveneens waar te nemen dat het maximaal (gemiddeld) aantal hops afneemt naarmate meer sinks worden toegevoegd aan het netwerk. De exacte structuur van de grafiek (en dus hoeveel voordeel het invoeren van een extra sink oplevert) heeft uiteraard te maken met waar in het netwerk de sinks geplaatst werden. In deze opstelling wordt het gemiddeld aantal hops bijna gehalveerd wanneer overgegaan wordt van één sink naar vier (het maximaal aantal hops wordt meer dan gehalveerd). Pakketverlies

In figuur 6.12 wordt de kans op pakketverlies in functie van het aantal gebruikte

sinks uitgezet. Net als in figuur 6.11 wordt ook hier het maximum en minimum aangegeven in de grafiek. Er kan een daling van zowel het maximale als het gemiddelde pakketverlies waargenomen worden wanneer het aantal sinks in het netwerk toeneemt. Wanneer we de figuren 6.11 en 6.12 met elkaar vergelijk zien we dat deze zeer sterk op elkaar lijken. Dit is uiteraard het gevolg van het verband tussen pakketverlies en aantal hops zoals aangetoond in figuur 6.6. In figuur 6.13 wordt zowel het gemiddeld aantal hops (lijn) als het pakketverlies (staafdiagrammen) op één grafiek weergegeven om dit duidelijk weer te geven.

6.4 Simulatie

64

70%


60%

50% 40% 30%

25,940% 20,513%

20%

14,530%

10%

10,171%

0% 0

1

2

Aantal sinks

3

4

5

Figuur 6.12: Pakketverlies in functie van aantal sinks

Gemiddeld packetverlies Gemiddeld aantal hops

25%

4,5 4 3,5

20%

3 2,5

15%

2

10%

1,5 1

5%



30%

0,5

0%

0

1

2

Aantal sinks

3

4

Figuur 6.13: Pakketverlies en gemiddeld aantal hops in functie van aantal sinks

Energieverbruik

Tot slot wordt nog nagegaan welke invloed het gebruik van meerdere sinks

heeft op het energieverbruik van de sensor nodes. In figuur 6.14 wordt het gemiddeld energieverbruik in functie van het aantal sinks weergegeven. Het maximaal en minimaal energieverbruik werden eveneens aangegeven op de grafiek. Net als bij de vorige analyse zien we ook hier een daling van het gemiddeld energieverbruik naarmate het aantal sinks toeneemt. Opnieuw houdt dit rechtstreeks verband met het feit dat

6.5 Real-life

65

het gemiddeld aantal hops zakt naarmate het aantal sinks stijgt. Aangezien het grootste deel van het energieverbruik van een node afkomstig is van het ontvangen/versturen van data over de radio zal een reductie in het aantal hops ervoor zorgen dat een pakket minder energie nodig heeft om de sink te bereiken (m.a.w. het gemiddeld energieverbruik zal dalen). We zien eveneens dat ook de maximale energieverbruik daalt. Wanneer we ervan uitgaan dat alle nodes voorzien zijn van eenzelfde energievoorraad heeft dit als gevolg dat de levensduur van het netwerk (moment tot wanneer de eerste node faalt) verhoogt zal worden. Aangezien de nodes die zich dicht bij een sink bevinden typisch behoren tot de grotere energieverbruikers (ze moeten immers de meeste hoeveelheid data forwarden) kan het falen van slechts enkele nodes er voor zorgen dat geen enkele node in het netwerk nog kan communiceren met de sink (dit werd eveneens aangetoond in [45]).

Gemiddeld Energieverbruik (mW)

2,5

2

1,5

1,418 1,262

1,095

1

0,958

0,5

0 0

1

2

3

4

5

Aantal sinks Figuur 6.14: Energieverbruik in functie van aantal sinks

6.5

Real-life

Zoals reeds vermeld werden naast de simulatietesten eveneens testen uitgevoerd op een real-life testbed (iMinds w-iLab.t). De opstelling en de resultaten zullen in deze sectie besproken worden. In de real-life testen werd het maximaal aantal retransmissies verhoogt naar drie. De draadloze communicatie gebeurd op (IEEE 802.15.4) kanaal 11 en het transmissie vermogen werd ingesteld op -15dBm (niveau 7).

6.5 Real-life

6.5.1

66

Opstelling

De fysieke posities van de sensor nodes die gebruikt werden in de performantietesten worden weergegeven in figuur 6.16. Elk van deze sensor nodes is aangesloten op een embedded PC. Deze embedded PCs zijn onderling verbonden met elkaar d.m.v. een switch (Ethernet). Om de communicatie tussen de verschillende sinks en de registrar mogelijk te maken werd gebruik gemaakt van SLIP (voor de communicatie tussen de sensor node en de embedded pc) en IP tunnels (voor de communicatie tussen de embedded pc’s onderling). De resultaten werden verzameld op de embedded pc waar de registrar op aangesloten is (node 91) en via een VPN tunnel naar de collect-view applicatie gestuurd (die draait op een machine die zich buiten het zuiderpoort netwerk bevindt). Deze opstelling wordt schematisch weergegeven in figuur 6.15. sensornode - registrar

Serial Line IP VPN tunnel collect-view applicatie

IP tunnel

wilab node 91

IP tunnel

wilab node 89

Serial Line IP

sensornode - sink 1

wilab node 57

Serial Line IP

sensornode - sink 2

Figuur 6.15: Opstelling real-life testen: communicatie tussen de sinks en de registrar d.m.v. SLIP en IP tunnels, en tussen de collector en de collect-view applicatie (draait op machine buiten het zuiderpoort netwerk) via een “VPN tunnel”.

6.5 Real-life

Figuur 6.16: Topologie real-life testen: nodes 89 en 57 zijn respectievelijk sink 1 en 2, de overige aangeduide nodes zijn allemaal zenders (18 nodes in totaal)

67

6.5 Real-life

6.5.2 a)

68

Resultaten

Invloed van het aantal te nemen hops

Net als bij de simulaties zullen we eerst de invloed van het aantal hops op het pakketverlies en het energieverbruik van de nodes nagaan. In figuur 6.17 wordt de kans op pakketverlies in functie van het aantal hops dat

Pakketverlies

moet doorlopen worden weergegeven. Vergelijken we de bekomen resultaten met de resultaten uit de simulatie (figuur 6.6) dan zien we dat hier veel minder sprake is van een vast verband tussen het aantal hops en het pakketverlies. We zien dat het pakketverlies enorm stijgt bij de nodes die zich verder dan drie hops van de sink bevinden. Voor nodes die gemiddeld gezien meer dan 4 ´ a 5 hops van de sink verwijderd zijn is er een pakketverlies van maar liefst 90% waarneembaar. Door extra sinks toe te voegen en op die manier te vermijden dat sensor nodes zich op dergelijk afstanden van een sink kunnen bevinden kan het gemiddeld pakketverlies sterk naar beneden gehaald worden. 100%


90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

1

2

3

4

5

Aantal hops

6

7

8

Figuur 6.17: Percentage van pakketten dat verloren gaat in functie van het aantal hops dat moet genomen worden

Energieverbruik

Wanneer we de resultaten uit figuur 6.18 vergelijken met die uit figuur 6.8

is een volledig andere grafiek waar te nemen. De sensor nodes die de meeste energie verbruiken bevinden zich (gemiddeld gezien) op een 4 á 5 hops van de sink. Aangezien we hier niet langer

6.5 Real-life

69

te maken hebben met een simulatie omgeving waar op alle links hetzelfde verliesmodel wordt toegepast zal naast de grootte van de deelboom nu eveneens de fysieke locatie van een sensor node een belangrijke rol gaan spelen in het totale energieverbruik van de sensor node (de interferentie is immers sterk afhankelijk van de omgeving van een senor node). Net als bij de simulatietesten met pakketverlies zal ook hier het lokaal herstelmechanisme mee zorgen voor een verhoging van de energieverbruik wanneer lusvorming optreed. 7


6 5

4 3 2 1

0 1

2

3

4

5

6

7

8

Aantal hops Figuur 6.18: Gemiddeld energieverbruik in functie van de afstand tot de sink (aantal hops) Om een idee te krijgen van de interferentie op een bepaalde positie werd in figuur 6.19 de gemiddelde ETX waarde van de voorkeursouder(s) van een node uitgezet (in functie van het aantal hops dat de node verwijderd is van de sink). We zien bijvoorbeeld dat de gemiddelde ETX waarde van de voorkeursouder van de sensor node die in figuur 6.18 een verbruik had van meer dan 6mW eveneens zeer hoog is. Aangezien de ETX waarde aangeeft hoe vaak een pakket gemiddeld gezien verstuurd dient te worden alvorens het succesvol ontvangen wordt betekent een hogere ETX waarde meer retransmissies en dus een hoger energieverbruik. In ContikiRPL wordt de ETX van een link herberekend telkens een data pakket over de link wordt verstuurd. Deze berekening gebeurt aan de hand van een gewogen gemiddelde van de huidige ETX waarde en het aantal transmissies dat nodig was alvorens een ACK ontvangen werd. Indien geen ACK werd ontvangen wordt de hoogst mogelijke ETX waarde genomen (15 in ContikiRPL). Wanneer we nu opnieuw kijken naar de ETX waarde van de node met een energieverbruik

6.5 Real-life

70

van meer dan 6mW zien we dat deze bijna 12 bedraagt. Dit betekent dat voor (zo goed als) alle pakketten nooit een ACK wordt ontvangen. Aangezien elk pakket vier keer kan worden verstuurd alvorens het “weggegooid” wordt zorgt dit voor het zeer hoge energieverbruik bij deze node.

Gem. ETX van voorkeursouder(s)

12

10 8 6 4 2

0 1

2

3

4

5


6

7

8

Figuur 6.19: Gemiddeld ETX waarde van de voorkeursouder(s) (van een bepaalde node) in functie van de afstand tot de sink (aantal hops)

b)

Invloed van het gebruik van meerdere sinks

Aantal hops

Zoals te verwachten was wanneer we kijken naar de fysieke topologie (zie fi-

guur 6.16) zal het gemiddeld aantal hops afnemen indien naast sink 1 eveneens sink 2 gebruikt wordt. Zowel het gemiddeld maximaal aantal hops als het gemiddeld aantal hops zakt met ongeveer 40% bij het gebruiken van beide sinks i.p.v. slechts één sink.

6.5 Real-life

71


9

8 7 6 5

4,366

4

3

2,612

2 1 0

1

Aantal sinks

2

3

Figuur 6.20: Gemiddeld aantal hops in functie van aantal sinks

Pakketverlies

Aangezien het gemiddeld aantal hops daalt zal dit eveneens zorgen voor een

daling in het aantal verloren pakketten (zoals te zien in figuur 6.21). Hoewel het gemiddeld aantal hops met “slechts” 40% zakt resulteert dit toch in 60% minder verloren pakketten (zie figuur 6.22). Dit heeft uiteraard te maken met de hoge verliesratio’s (rond de 90%) van de sensor nodes die zich op meer dan vier hops van sink 1 bevonden. Waarbij het gebruik van slechts één sink er nodes waren die meer dan 90% pakketverlies hadden zien we het maximale pakketverlies nu niet meer boven de 70% komen. 100%


90%

80% 70% 60%

57,727%

50% 40% 30%

22,150%

20% 10%

0% 0

1

Aantal sinks

2

Figuur 6.21: Pakketverlies in functie van aantal sinks

3

6.5 Real-life

72

4,5 Gemiddeld pakketverlies

60%


4

3,5

50%

3

40%

2,5

30%

2 1,5

20%

1

10%



70%

0,5

0%

0

1

Aantal sinks

2

Figuur 6.22: Pakketverlies en gemiddeld aantal hops in functie van aantal sinks

Energieverbruik

Ook bij het gemiddeld energieverbruik (figuur 6.23) zien we, net als in de

resultaten van de simulatie, een daling na het invoeren van een extra sink. Wat eveneens sterk opvalt in de grafiek is de sterke daling van het maximaal energieverbruik. In de opstelling met slechts één sink was een node die enkel keuze had uit ouders met slechte link kwaliteiten (gemiddelde ETX waarde was meer dan 11). Door het invoeren van de tweede sink krijgt deze node keuze uit een grotere set van mogelijke ouders (de sinks bevinden zich immers op volledig andere fysieke plaatsen, waardoor de node nu eveneens data in een andere richting kan sturen) en blijkbaar is in deze set minstens één ouder aanwezig met een betere link kwaliteit dan voordien. Dit zal bijdragen tot een sterke daling van het maximaal energieverbruik. De opmerkingen die werden gemaakt bij het bespreken van de simulatie resultaten (met betrekking tot het energieverbruik) zijn hier eveneens geldig. Ook hier zal de reductie in maximale energieverbruik ervoor zorgen dat de levensduur van het netwerk aanzienlijk verhoogd wordt (in dit geval zelfs verdubbeld).

6.6 Conclusie

73

Gem. Energieverbruik (mW)

7 6 5 4 3

2,356

2

1,558

1

0 0

1

Aantal sinks

2

3

Figuur 6.23: Energieverbruik in functie van aantal sinks

6.6

Conclusie

De ontwikkelde ondersteuning voor meerdere sinks werd zowel in een simulatie omgeving als op een echt draadloos sensor netwerk geëvalueerd. In dit hoofdstuk hebben we aangetoond dat de implementatie zich gedraagt zoals verwacht, nl. dat het dataverkeer wordt verspreid over de verschillende sinks. Aan de hand van de performantietesten werd aangetoond dat het toevoegen van extra sinks aan een draadloos sensor netwerk zeker voordelen oplevert. Vooral op het testbed waren sterke verbeteringen in termen van pakketverlies en energieverbruik waarneembaar. Zo kon door het toevoegen van een extra sink de levensduur van het netwerk verdubbeld worden en werd het pakketverlies met bijna een factor 3 verlaagt. Uiteraard is de positionering van de sinks een bepalende factor in de hoeveelheid winst die kan behaald worden. In de real-life testen werd de tweede sink zodanig geplaatst dat de bladeren uit de eerste DODAG (het netwerk bestaande uit één sink) de kinderen van de wortel worden in de tweede. Dit betekent dat de sensor nodes die zich vroeger aan het uiteinde van het netwerk bevonden zich nu zeer dicht bij de nieuwe sink zullen bevinden.

MOBILITEIT EN MEERDERE SINKS

74

Hoofdstuk 7

Mobiliteit en meerdere sinks 7.1

Introductie

Naast het ondersteunen van meerdere sinks in ContikiRPL werd eveneens ondersteuning voor mobiliteit ingebouwd. In dit hoofdstuk zal eerst worden besproken hoe deze ondersteuning ontworpen en ge¨ımplementeerd werd. Vervolgens zullen de resultaten van de uitgevoerde testen besproken worden. Het hoofdstuk wordt afgesloten met een conclusie over de ontwikkelde mobiliteitsoplossing en een korte bespreking over waar nog verbeteringen mogelijk zijn.

7.2

Ondersteuning voor mobiliteit in ContikiRPL

In deze sectie zal worden ingegaan op welke aanpassingen werden gemaakt aan ContikiRPL om mobiele nodes te ondersteunen. Onmiddellijk DIO sturen

Zoals besproken in het hoofdstuk over RPL wordt het versturen

van DIO berichten getriggerd door een trickle timer. Aangezien de topologie van het netwerk uit het standpunt van de mobiele node constant wijzigt is het belangrijk dat nieuwe topologie informatie deze node zo snel mogelijk bereikt. Wanneer we, zonder aanpassingen aan RPL, informatie zouden opvragen over het netwerk (door het uitsturen van DIS berichten) zou deze ons slechts na enkele seconden bereiken. Dit komt omdat bij het ontvangen van een DIS bericht niet onmiddellijk een DIO bericht wordt uitgestuurd maar gekozen wordt om de trickle timer te resetten(zie sectie 3.7) en dat pas wanneer deze timer verloopt een DIO bericht verstuurd zal worden. Wanneer we dit bekijken met de standaard waarde voor Imin (4 sec) zal een DIO bericht pas 2-4 seconden na het ontvangen van een DIS bericht verstuurd worden.

7.2 Ondersteuning voor mobiliteit in ContikiRPL

75

Men zou kunnen stellen dat een oplossing voor het probleem zou kunnen zijn om de DIS berichten voldoende op voorhand te sturen, m.a.w. stel dat we op t2 de topologie van het netwerk willen weten dan moeten we ervoor zorgen dat we zeker op t2-Imin (=t1) een DIS bericht uitsturen. Hoewel dit in eerste instantie klinkt als een goed idee is dit geen ideale oplossing. Het probleem met deze oplossing zal duidelijk gemaakt worden aan de hand van een voorbeeld.

Stel dat een mobiele node een DIS bericht uitstuurt op t1 en deze ontvangen wordt door nodes 1, 2 en 3 (zie figuur 7.1). Bij ontvangst van het DIS bericht zullen deze nodes hun trickle timer resetten met als gevolg dat rond tijdstip t2 een DIO bericht uitgestuurd zal worden. 4

1

DIS

3

M 7

8 2

5

6

Figuur 7.1: Mobiele node stuurt DIS op t1 Het is echter mogelijk dat de mobiele node op tijdstip t2 zich reeds op een andere plaats in het netwerk bevindt (zie figuur 7.2). Hoewel de DIO berichten nog steeds zullen verstuurd worden door nodes 1, 2 en 3 is het mogelijk dat de mobiele node zich niet langer in het bereik van (een deel van) deze nodes bevindt en het versturen van deze berichten dus nutteloos was. Verder is het zo dat we hadden gesteld dat de mobiele node ge¨ınteresseerd was in de topologie rond tijdstip t2. We zien echter dat enkel de nodes die het DIS bericht ontvangen hebben op tijdstip t1, een DIO bericht zullen sturen rond tijdstip t2. Dit heeft als gevolg dat slechts een deel van de werkelijke topologie op t2 gekend zal zijn voor de mobiele node (het deel dat overlapt tussen het bereik van de node op t1 en het bereik van de node op t2).


76

4

1 3

DIO M

2

5

7

8

6

Figuur 7.2: Mobiele node ontvangt DIO pas op t2 Het op voorhand sturen van DIS berichten (of het netwerk periodiek pollen waardoor DIO berichten constant toekomen) is dus geen ideale oplossing om de werkelijke topologie vanuit het standpunt van een mobiele node na te gaan.

Om deze reden werd dan ook gekozen om bij het ontvangen van een DIS bericht hier onmiddellijk op te antwoorden met een DIO bericht (ook in [1] werd deze aanpassing gemaakt). Op deze manier kan de mobiele node zo goed als direct de nieuwe topologie informatie verkrijgen en doet het probleem dat werd aangekaart in het voorgaande voorbeeld zich niet langer voor. We kunnen nu immers rond tijdstip t2 een DIS bericht sturen en we zullen rond hetzelfde tijdstip een antwoord ontvangen van alle nodes die het DIS bericht ontvangen hebben en zich nog steeds in het bereik van de mobiele node bevinden (wat zo goed als alle nodes zullen zijn die het DIS bericht ontvangen hebben). Mobiele nodes zijn altijd bladeren Zonder aanpassingen aan RPL is het voor een mobiele node mogelijk om zich om het even waar in de DODAG te bevinden. Aangezien geen rekening wordt gehouden met de mobiliteit van deze node kan dit leiden tot veel problemen. Zo zou een vaste node ervoor kunnen kiezen om zijn voorkeursouder aan te passen naar de mobiele node wanneer deze in zijn bereik komt (merk op dat deze situatie zeer aannemelijk is wanneer we de initiële link waardes op 1 instellen). Zolang de mobiele node in het bereik blijft van de vaste node zal er niet onmiddellijk een probleem optreden, maar eens deze buiten het bereik valt zal de vaste node niet langer kunnen communiceren in de opwaartse richting tot wanneer hij een nieuwe voorkeursouder kiest. Dit zal typisch een tijd duren omdat we in LLN niet willen overreageren bij het verloren gaan van pakketten. Wanneer deze vaste node bovendien een grote


77

deelboom heeft kan mogelijk een groot deel van het netwerk niet langer de sink bereiken. 4

1

4

1

3

3

3 7

M

7

7

M

8

8

8

M 2

2

2 6

6

6

5

5

5

Parameters in mobiele node zorgen ervoor dat deze snel wisselt van voorkeursouder (stap 3)

Node 3 beslist om mobiele node als voorkeursouder te kiezen (stap 2)

Initiële DODAG (stap 1)

4

1

4

1

3

2

M

6

6

6 5

Mobiele node is niet langer in het bereik van node 3 (stap 4)

8

8 2

5

7

7

7 8 M

4

1

3

3

2

4

1

Vaste node zal typisch langer zijn voorkeursouder behouden (stap 5)

M

5

Na enige tijd wijzigt node 3 opnieuw zijn voorkeursouder (stap 6)

Figuur 7.3: Node 3 kiest mobiele node als voorkeursouder In figuur 7.3 wordt een situatie weergegeven zoals kort werd beschreven in de vorige paragraaf. Op een gegeven moment beslist node 3 om de mobiele node als voorkeursouder te kiezen (stap 2), dit gebeurt omdat de kost van het pad 1-3 hoger is dan de kost van het pad 1-M-3. Wanneer de mobiele node vervolgens buiten het bereik van node 3 valt zal dit ervoor zorgen dat geen opwaarts verkeer vanuit node 3 meer mogelijk is. Dit heeft in het voorbeeld eveneens als gevolg dat ook nodes 3, 7 en 8 de sink niet meer kunnen bereiken. Wanneer de kost van het pad 1-M-3 uiteindelijk te hoog wordt (omwille van de stijgende kost van de link 3-M) zal node 3 beslissen om opnieuw node 1 als voorkeursouder te nemen (stap 6). Tussen stap 4 (het verliezen van de connectiviteit tot de mobiele node) en stap 6 (het wisselen van voorkeursouder) kan enige tijd zitten daar we voor de vaste nodes niet te snel willen reageren (veranderen van voorkeursouder) op het slechter worden van een link.

Om te verhinderen dat de mobiele node gekozen kan worden als voorkeursouder van een vaste node, zal bij het uitsturen van DIO berichten door de mobiele node steeds de oneindige rank worden meegegeven. Dit zal als gevolg hebben dat de mobiele node nooit de ouder kan


78

zijn van een andere node. Aantal opeenvolgende verloren pakketten bijhouden

Waar het verloren gaan van pak-

ketten bij vaste nodes typisch het gevolg is van storing op een link, geheugen tekort bij de ouder, ... kan dit bij mobiele nodes ook veroorzaakt worden doordat de ouder zich niet langer in het bereik van de mobiele node bevindt. Omdat dit een mogelijke aanwijzing is dat een ouder niet langer bereikbaar is zullen de mobiele nodes het aantal opeenvolgende pakketten die verloren gegaan zijn bijhouden. Merk op dat in Contiki een pakket meerdere keren (CSMA MAX MAC TRANSMISSIONS) verstuurd kan worden alvorens het als verloren bestempeld wordt. Indien dit aantal boven een bepaalde waarde komt (MAX LOSTS) zullen we een ouder als onbereikbaar beschouwen en deze uit de lijst van ouders verwijderen. Er is één uitzondering op deze regel (het verwijderen van een onbereikbare ouder) en dat is de situatie waarbij de mobiele nodes slechts één ouder heeft. Om in dergelijke situatie toch zo snel mogelijk een nieuwe ouder te vinden wordt door de mobiele node (periodiek) een DIS bericht uitgestuurd. Indien er opeens toch opnieuw data verstuurd kan worden naar de onbereikbare ouder (of ontvangen wordt van) dan zal deze uiteraard niet langer als onbereikbaar beschouwd worden. Laatste keer dat een ouder gehoord werd bijhouden Hoewel de voorgaande methode in staat is om een ouder die niet langer bereikbaar is te bepalen, zal dit maar gebeuren nadat een aantal datapakketten verloren gegaan werden. Om te voorkomen dat het noodzakelijk is dat pakketten moeten verloren gaan alvorens gewisseld wordt van ouder werd een extra methode ingevoerd om te bepalen als een ouder zich nog steeds binnen het bereik van een node bevindt. Door bij te houden wanneer een node voor het laatst werd gehoord (een DIO ontvangen ervan of data succesvol verstuurd ernaar) kunnen we een beslissing maken over hoe aannemelijk het is dat de ouder zich nog steeds in het bereik van de node bevindt. Om dit te bepalen werden twee nieuwe parameters ingevoerd: MAX LAST HEARD SEC en REMOVE LAST HEARD SEC, deze parameters zullen nu worden toegelicht. De parameter MAX LAST HEARD SEC geeft aan na hoeveel seconden we een ouder zullen bestempelen als mogelijk verloren gegaan. De objectief functie werd zodanig aangepast zodat bij een beslissing over welke ouder de beste is er een voorkeur gegeven zal worden aan een ouder die niet bestempeld is als mogelijk verloren gegaan. Indien alle ouders bestempeld zijn als mogelijk verloren gegaan of allen als niet verloren gegaan dan zal de werking van de objectief functie

7.3 Opstelling en Resultaten

79

exact hetzelfde zijn als voordien. De parameter REMOVE LAST HEARD SEC geeft aan na hoeveel seconden een ouder bestempeld zal worden als verloren gegaan. Het verschil tussen deze parameter en de voorgaande is dat in dit geval de ouder verwijderd zal worden uit de lijst van mogelijke ouders (en dus zeker niet meer gekozen kan worden als voorkeursouder) terwijl de vorige parameter er enkel voor zorgde dat de ouder minder “aantrekkelijk” werd.

7.3

Opstelling en Resultaten

In deze sectie zal kort worden aangetoond welke bijkomende voordelen (naast diegene die al besproken werden in het vorige hoofdstuk) het gebruik van meerdere sinks heeft in een draadloos sensornetwerk waar ContikiRPL in combinatie met de (aangepaste) ETX objectief functie gebruikt wordt.

7.3.1

Opstelling

De gebruikte testopstelling is terug te vinden in figuur 7.4. Er zijn twee sinks aanwezig in het netwerk (nodes 2 en 3, aangeduid met een cirkel) en één mobiele node (node 7). Het pad dat gevolgd wordt door de mobiele node is weergegeven in figuur 7.5.

Figuur 7.4: Opstelling mobiliteitstest: nodes 2 en 3 (aangeduid met cirkel) zijn sinks, node 7 is een mobiele node, node 1 (volledig zwarte node onderaan) is de registrar. De afstand tussen de gridlijnen die weergegeven zijn op de figuur bedraagt 10m.


80

Figuur 7.5: Pad gevolgd door de mobiele node De parameters die werden gebruikt in de uitgevoerde testen: • Ontvangst bereik: 50m • Interferentie bereik: 65m • Verzendratio (TX): 100% • Ontvangstratio (RX): 100% • Maximum aantal transmissies van hetzelfde pakket: 2 • MAX LOST: 2 (ouder wordt verwijderd indien twee opeenvolgende berichten verloren gaan) • MAX LAST HEARD SEC: 10 (indien 10 seconden niets gehoord van een ouder wordt hij bestempeld als mogelijk verloren gegaan, zie sectie 7.2) • REMOVE LAST HEARD SEC: 20 (na 20 seconden wordt de ouder volledig verwijderd, zie sectie 7.2) In de uitgevoerde test stuurt de mobiele node iedere 10 seconden een DIS bericht uit (om de omgeving te “pollen”) en wordt iedere 10 á 12 seconden een data bericht uitgestuurd naar de sink (hetzelfde bericht als bij de vorige performantietesten).


7.3.2

81

Resultaten één sink

twee sinks

verschil

Verloren pakketten

19,61%

11,76%

-40%

Gemiddeld energieverbruik

3,82mW

3,21mW

-16,03%

2,56

2,03

-20,7%

Gemiddelde ETX voorkeursouder

Tabel 7.1: Resultaten mobiele node Hoewel de ontvangst- en verzendratio op 100% werd ingesteld is toch pakketverlies waar te nemen (zie tabel 7.1). Dit pakketverlies is een gevolg van de mobiliteit van de sensornode, zo is het bijvoorbeeld mogelijk dat een sensor node een voorkeursouder kiest die kort erna buiten het bereik van de node valt (nog voor een nieuwe voorkeursouder werd gekozen).

Wanneer overgaan wordt van een netwerk voorzien van één sink naar een netwerk voorzien van twee sinks is een daling van het pakketverlies met 40% waarneembaar. Deze daling kunnen we verklaren aan de hand van hoe de gebruikte objectief functie (MRHOF met ETX) de DODAG opbouwt. Zoals uitgelegd in sectie 3.9.1 zal de ouder met de laagste rank ingesteld worden als voorkeursouder (behoudens een mogelijke drempelwaarde die eerst overschreden moet worden alvorens gewisseld wordt). Dit heeft als gevolg dat een mobiele node typisch de voorkeur zal geven aan ouders die zich dichter (minder hops) bij de sink bevinden (dit is zeker geval wanneer de ETX waardes van de verschillende ouders zeer sterk op elkaar lijken, zie eveneens sectie 3.9.1). Wanneer de mobiele node van de sink weg beweegt heeft dit als gevolg dat steeds de voorkeur gegeven zal worden aan een ouder waar de node van weg beweegt in plaats van een ouder waar de node naartoe beweegt (en zich dus langer in het bereik van de node zal bevinden). Als we naar de opstelling in figuur 7.4 kijken zien we dat door het activeren van de tweede sink (de meest rechtse sink) de mobiele node in het eerste stuk van het pad naar deze sink toe beweegt. Dit zal als gevolg hebben dat, eens de sink terecht komt in de DODAG opgebouwd vanaf deze sink, steeds in de “goeie richting” voorkeursouders gekozen zal worden (zolang de node in de richting van de sink blijft bewegen). Aangezien de richting waarin de voorkeursouder gekozen wordt overeen komt met de richting waarin de mobiele node beweegt zal op dat stuk van het pad amper nog pakketverlies voorkomen. Vandaar ook dat een sterke daling in pakketverlies waar te nemen was bij het toevoegen van een tweede sink aan het netwerk.

7.4 Tracking van fietsen d.m.v. draadloze sensornetwerken

82

Aangezien de gemiddelde ETX waarde van de voorkeursouder (aantal keer dat een pakket dient verstuurd te worden alvorens het ontvangen wordt) bij het netwerk dat voorzien is van twee sink lager is dan bij het netwerk voorzien van één sink zal dit ervoor zorgen dat eveneens het energieverbruik van de mobiele node daalt.

Tot slot werd de test ook nog eens uitgevoerd met een ontvangstratio van 50%, de resultaten hiervan zijn terug te vinden in tabel 7.2. Een gelijkaardig resultaat (op schalingen na) is waar te nemen. Zowel het pakketverlies van de mobiele node, als zijn energieverbuik dalen wanneer een extra sink wordt toegevoegd. één sink

twee sinks

verschil

Verloren pakketten

27,65%

13,59%

-50,85%

Gemiddeld energieverbruik

3,91mW

3,31mW

-15,43%

2,13

1,85

-13,32%

Gemiddelde ETX voorkeursouder

Tabel 7.2: Resultaten mobiele node (50% ontvangstratio)

7.4

Tracking van fietsen d.m.v. draadloze sensornetwerken

Naast de performantietesten werd eveneens een kleine webapplicatie ontwikkeld die toelaat om mobiele sensoren te volgen op een map. We gaan er hier van uit dat de sensoren voorzien zijn van een GPS module om hun locatie te bepalen. De applicatie werd voornamelijk ontwikkeld om een beeld te geven van wat mogelijk is door het ondersteunen van mobiliteit in RPL.

Men zou bijvoorbeeld (huur)fietsen kunnen uitrusten met draadloze sensoren om een beeld te kunnen krijgen van hoe lang typisch gefietst wordt, welke routes populair zijn, hoeveel kilometers een fiets afgelegd heeft, ... Uiteraard moet hiervoor het gebied waarin de fietsers zullen bewegen bedekt zijn door een draadloos sensornetwerk. Men zou wel kunnen opteren om wanneer de verbinding met het draadloos sensornetwerk verloren gaat periodiek locatiegegevens op te slaan op extern geheugen (bv. EEROM) en deze op een later ogenblik te versturen.

Voor het ontwikkelen van de webapplicatie werd gebruik gemaakt van ASP.NET MVC 4. Dit is een open-source webapplicatie framework welke het Model-View-Controller patroon implementeert. De locatiegegevens die weergegeven worden op de website worden bijgehouden in


83

een MSSQL databank. De communicatie tussen de webapplicatie en de databank wordt verzorgd door het Entity Framework, een Object-Relational Mapping (ORM) bibliotheek. Om de gegevens uit de databank op een eenvoudige manier toegankelijk te maken werd gekozen om een eenvoudige Representational State Transfer (REST) API te ontwikkelen. In een REST API wordt gebruik gemaakt van HTTP verkeer om data aan een databank (in dit geval) toe te voegen (HTTP PUT/POST), data te wijzigen (HTTP POST) of data te verwijderen (HTTP DELETE). Tot slot wordt gebruik gemaakt van Asynchronous JavaScript and XML (AJAX) om aan de gebruiker de mogelijkheid te bieden de locatie van de mobiele nodes in real-time te volgen.

Wireless Sensor Network

(51.038; 3.73)

M

Sink

Sink

Sink

Server

Figuur 7.6: Schematische voorstelling van de communicatie tussen de mobiele node en de databank server In figuur 7.6 wordt een schematische voorstelling gegeven van hoe de communicatie tussen de mobiele node en de server verloopt. De mobiele node zal periodiek locatiegegevens doorsturen naar de dichtstbijzijnde sink. Het is de taak van de sink om ervoor te zorgen dat de data uiteindelijk terecht komt bij de databank server. Hiervoor zal de sink de informatie via Serial Line IP doorsturen naar de (embedded) pc waarop hij is aangesloten. Op deze pc draait een applicatie die de data zal accepteren en vervolgens doorsturen naar de databank server. Voor deze communicatie wordt gebruik gemaakt van de ontwikkelde REST API. De werking van de applicatie werd getest aan de hand van de COOJA simulator. Hiervoor werd gebruik gemaakt van de opstelling die terug te vinden is in figuur 7.4. De mobiele node stuurt nu periodiek (vast gecodeerde) locatie gegevens naar de sink. Eens deze de sink


84

bereiken wordt het communicatiepatroon zoals besproken in de vorige paragraaf doorlopen. De sink stuurt de locatie gegevens over een (gesimuleerde) SLIP verbinding door naar de pc die de simulatie uitvoert. Daar worden ze omgezet in HTTP pakketten die vervolgens naar de REST API worden verstuurd.

Figuur 7.7: Screenshot van de webapplicatie

7.5 Conclusie

7.5

85

Conclusie

Dit hoofdstuk begon met een bespreking van de aanpassingen die aan ContikiRPL werden gemaakt om mobiliteit te ondersteunen. Vervolgens werd, aan de hand van de uitgevoerde testen, aangetoond welke extra voordelen het gebruik van meerdere sinks in een draadloos sensor netwerk waar mobiele nodes aanwezig zijn kan bieden. Wanneer in het netwerk gebruik gemaakt wordt van de MRHOF objectief functie in combinatie met de ETX metriek (wat standaard het geval is in ContikiRPL), kunnen extra sinks ervoor zorgen dat de mobiele nodes minder pakketverlies vertonen ten gevolge van het sturen naar een ouder die niet langer in hun bereik ligt. Tot slot werd voorgesteld hoe de mobiliteitsondersteuning gebruikt kan worden voor een scenario waar een mobiele node (via de sink) periodiek GPS coördinaten naar een centrale server stuurt. Deze co¨ ordinaten kunnen vervolgens weergegeven worden op een kaart (d.m.v. een webapplicatie) en op die manier gepresenteerd worden aan een gebruiker.

BESLUIT

86

Hoofdstuk 8

Besluit In de thesis werd een methode voor het ondersteunen van meerdere sinks in (Contiki)RPL voorgesteld. Doordat enkel in de sink nodes wijzigingen aan de werking van RPL werden aangebracht is de oplossing compatibel met reeds bestaande draadloze sensor netwerken die gebruik maken van RPL. De enige extra vereiste die wordt gesteld is dat een betrouwbaar netwerk aanwezig moet zijn tussen de verschillende sinks. De implementatie werd zowel getest in een simulatie omgeving als op een real-life testbed (iMinds w-iLab.t). Hiervoor werd een opstelling gebruikt waar de sensor nodes periodiek data versturen naar (één van) de sink(s). Deze data pakketten bevatten alle informatie die nodig is om een beeld te kunnen vormen van het netwerk en van de performantie van de nodes (energieverbruik, pakketverlies, ...). Uit de resultaten is duidelijk op te maken dat het gebruik van meerdere sinks in een draadloos sensor netwerk de levensduur van het netwerk sterk kan verhogen en het gemiddeld pakketverlies doen verlagen. Zo werd het pakketverlies op het real-life testbed een factor 3 kleiner door het toevoegen van een extra sink en kon de levensduur van het netwerk verdubbeld worden. Tot slot werd nog een basis ondersteuning voor mobiliteit toegevoegd aan (Contiki)RPL. Aan de hand van in te stellen parameters kan de mobiliteitsondersteuning aangepast worden aan de vereisten van de mobiele nodes (energieverbruik vs. pakketverlies). Er werden eveneens enkele performantietesten uitgevoerd op een netwerk waar een mobiele node aanwezig is. Hierbij werd gefocust op wat de invloed van het gebruik van meerdere sinks is op de performantie van de mobiele nodes. Wanneer gebruik gemaakt wordt van de “Minimum Rank with Hysteresis Objective Function” in combinatie met de ETX metriek (wat standaard het geval is in ContikiRPL) kon worden aangetoond dat door het toevoegen van meerdere sinks aan het netwerk het pakketverlies en het energieverbruik van de mobiele nodes verder verlaagd kan worden.

DEBUGGING COOJA SIMULATION USING GDB-MSP430 AND ECLIPSE

Bijlage A

Debugging Cooja simulation using GDB-MSP430 and Eclipse

87


88

Installing COOJA GDBStub 1. Download COOJA GDBstub This is a COOJA plugin that allows us to debug a node running inside COOJA using GDB-MSP 2. Create a new folder inside the plugin folder of COOJA ([COOJA_DIR]/apps) and extract the COOJA GDBstub files there. 3. Navigate to this folder and build the plugin using ant 4. Enable the plugin in COOJA: Settings -> COOJA Extensions 5. Restart COOJA Installing GDB-MSP430 using apt-get (doesn’t work for the moment) GDB-MSP430 can be installed using sudo apt-get install gdb-msp430, however I didn’t get this to work in Ubuntu 12.04 as it conflicted with the gdb package. Removing the gdb package allowed me to install gdb-msp430, but when trying to connect to a node in COOJA I got a segmentation error which is apparently due to a bug in Ubuntu. So it is possible that in later versions of either gdb-msp or Ubuntu this will be fixed. 1. sudo apt-get install gdb-msp430 Installing GDB-MSP430 (manually) 1. Download and extract GDB 7.3.1 2. Download GDB 7.2a patch and save to the location containing the (extracted) gdb-7.3.1 folder. 3. Download GDB 7.3-fix-segfault patch and save it to the same location 4. Start a terminal and go to the gdb-7.3.1 folder 5. Apply the patches using the commands: a. patch -p1 < ../msp430-gdb-7.2a-20111205.patch b. patch -p1 < ../msp430-gdb-7.3-fix-segfault.patch 6. Build and install gdb-msp430 using the commands: a. mkdir -p BUILD/gdb b. cd BUILD/gdb c. ../../../gdb-7.3.1/configure --target=msp430 --prefix=/usr/local/msp430 d. make e. make install (sudo might be required based on permissions) Debugging using Eclipse 1. Load a simulation in COOJA, right click on the node you want to debug using GDB -> Mote tools for Sky # -> Msp GDBStub 2. (optional) Sometime not all source files could be located, to check this, right click on the node -> Mote tools for Sky # -> Msp Code Watcher -> Locate Sources… by adding a prefixsubstitution couple additional source files can be located, make sure the files where you want to add breakpoints are located. 3. (optional) It might be handy to check if you are able to connect to this stub before setting up Eclipse debugging by running the commands: a. /usr/local/msp430/bin/msp430-gdb (this should launch msp gdb) b. target remote localhost:2000 (see COOJA for exact port number) This should return 0x00000000 in ?? () in case you get an error, make sure all previous steps are followed correctly and check if applying the patches went successfully.


89

4. (optional) Import project in Eclipse a. File -> Import -> C/C++ -> Existing Code as Makefile Project b. Give the project a name, locate the Makefile c. Select <none> as Toolchain 5. Open your project in Eclipse a. Run -> Debug configurations b. Right click on C/C++ Remote Application -> New c. C/C++ Application -> Browse… -> locate your .sky file d. Select Disable auto build under build before launch e. At the bottom of the window click the link Select other… f. Check Use configuration specific settings -> Choose GDB (DSF) Manual Remote Debugging Launcher -> OK g. Go to the Debugger tab -> GDB Debugger -> Browse… -> /usr/local/msp430/bin/msp430-gdb h. Inside the debugger tab go to the connection tab and set the hostname and the port to those listed in COOJA i. Click Apply and Close the window 6. (optional) Set the breakpoints 7. Run -> Debug configurations -> Select the created configuration and press Debug 8. This will launch msp-gdb and will start your COOJA Simulation, when a breakpoint is hit this will automatically pause the simulation inside Cooja. Files COOJA GDB Stub http://contikiprojects.svn.sourceforge.net/viewvc/contikiprojects/unierlangen.de/COOJA_GDBstub/?view=tar GDB 7.3.1 http://ftp.gnu.org/gnu/gdb/gdb-7.3.1.tar.bz2 GDB 7.2a Patch http://sourceforge.net/projects/mspgcc/files/Patches/gdb-7.2a/msp430-gdb-7.2a20111205.patch/download GDB 7.3 Segmentation Patch https://bugs.launchpad.net/gdb-linaro/+bug/891970/+attachment/2614233/+files/msp430gdb-7.3-fix-segfault.patch All files used in this tutorial can also be found on my SkyDrive https://skydrive.live.com/redir?resid=C306906A149F8AE0!1225

BIBLIOGRAFIE

90

Bibliografie [1]

“A Comprehensive Evaluation of RPL under Mobility”. In: International Journal of Vehicular Technology 2012 (2012). issn: 1424-8220. doi: 10.1155/2012/904308. url: http: //downloads.hindawi.com/journals/ijvt/2012/904308.pdf.

[2]

Kemal Akkaya en Mohamed Younis. “A survey on routing protocols for wireless sensor networks”. In: Ad Hoc Networks 3 (2005), p. 325–349.

[3]

H. Ammari. Investigating the Energy Sink-Hole Problem in Connected k-Covered Wireless Sensor Networks. 2013. doi: 10.1109/TC.2013.12.

[4]

Leila Ben Saad, Cedric Chauvenet en Bernard Tourancheau. “Simulation of the RPL Routing Protocol for IPv6 Sensor Networks: two cases studies”. Anglais. In: International Conference on Sensor Technologies and Applications SENSORCOMM 2011. Nice, France: IARIA, aug 2011. url: http://hal.inria.fr/hal-00647869.

[5]

Leila Ben Saad en Bernard Tourancheau. “Sinks Mobility Strategy in IPv6-based WSNs for Network Lifetime Improvement”. Anglais. In: International Conference on New Technologies, Mobility and Security (NTMS). IFIP. Paris, France, 2011, pages. url: http : //hal.inria.fr/inria-00563724.

[6]

A. Bogdanov, E. Maneva en S. Riesenfeld. “Power-aware base station positioning for sensor networks”. In: INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies. Deel 1. 2004, pages. doi: 10.1109/INFCOM. 2004.1354529.

[7]

L. Borsani e.a. “Tree-based routing protocol for mobile Wireless Sensor Networks”. In: Wireless On-Demand Network Systems and Services (WONS), 2011 Eighth International Conference on. 2011, p. 164–170. doi: 10.1109/WONS.2011.5720188.

BIBLIOGRAFIE

[8]

91

Pietro Ciciriello, Luca Mottola en Gian Pietro Picco. “Efficient routing from multiple sources to multiple sinks in wireless sensor networks”. In: in Proc. of the 4th European Conf. on Wireless Sensor Networks (EWSN. 2007. url: http://citeseerx.ist.psu. edu/viewdoc/summary?doi=10.1.1.113.2404.

[9]

Thomas Heide Clausen, Ulrich Herberg en Matthias Philipp. A Critical Evaluation of the ”IPv6 Routing Protocol for Low Power and Lossy Networks” (RPL). Anglais. Rapport de recherche RR-7633. INRIA, mei 2011. url: http://hal.inria.fr/inria-00597036.

[10]

Abhimanyu Das en Debojyoti Dutta. “Data acquisition in multiple-sink sensor networks”. In: SIGMOBILE Mob. Comput. Commun. Rev. 9.3 (jul 2005), p. 82–85. issn: 1559-1662. doi: 10 . 1145 / 1094549 . 1094561. url: http : / / doi . acm . org / 10 . 1145 / 1094549 . 1094561.

[11]

Sebastien Dawans, Simon Duquennoy en Olivier Bonaventure. “On Link Estimation in Dense RPL Deployments”. In: Proceedings of the International Workshop on Practical Issues in Building Sensor Network Applications (IEEE SenseApp 2012). Florida, USA, okt 2012.

[12]

A. Dunkels, B. Gronvall en T. Voigt. “Contiki - a lightweight and flexible operating system for tiny networked sensors”. In: Local Computer Networks, 2004. 29th Annual IEEE International Conference on. 2004, p. 455–462. doi: 10.1109/LCN.2004.38.

[13]

Adam Dunkels. Contiki. url: http://www.contiki-os.org/.

[14]

Adam Dunkels. The ContikiMAC Radio Duty Cycling Protocol. 2011.

[15]

Joakim Eriksson e.a. “COOJA/MSPSim: interoperability testing for wireless sensor networks”. In: Proceedings of the 2nd International Conference on Simulation Tools and Techniques. Simutools ’09. Rome, Italy: ICST (Institute for Computer Sciences, SocialInformatics en Telecommunications Engineering), 2009, 27:1–27:7. isbn: 978-963-9799-455. doi: 10.4108/ICST.SIMUTOOLS2009.5637. url: http://dx.doi.org/10.4108/ICST. SIMUTOOLS2009.5637.

[16]

Dave Evans. The Internet of Things: How the Next Evolution of the Internet Is Changing Everything. Apr 2011. url: http://www.cisco.com/web/about/ac79/docs/innov/IoT_ IBSG_0411FINAL.pdf.

BIBLIOGRAFIE

[17]

92

Muhammad Omer Farooq en Thomas Kunz. “Operating Systems for Wireless Sensor Networks: A Survey”. In: Sensors 11.6 (2011), p. 5900–5930. issn: 1424-8220. doi: 10.3390/ s110605900. url: http://www.mdpi.com/1424-8220/11/6/5900.

[18]

Carlos F. Garcia-Hernandez e.a. “Wireless Sensor Networks and Applications: a Survey”. In: International Journal of Computer Science and Network Security 17.3 (2007). Survey, p. 264–273.

[19]

O. Gnawali en P. Levis. The ETX Objective Function for RPL. Internet Draft. Mei 2010. url: http://tools.ietf.org/id/draft-gnawali-roll-etxof-01.txt.

[20]

O. Gnawali en P. Levis. The Minimum Rank with Hysteresis Objective Function. RFC 6719 (Proposed Standard). 2012. url: http://www.ietf.org/rfc/rfc6719.txt.

[21]

R. Hinden e.a. Internet Protocol Version 6 (IPv6) Addressing Architecture. RFC 3513 (Standards Track). Apr 2003. url: http://tools.ietf.org/rfc/rfc3513.txt.

[22]

Ki-Sup Hong en L. Choi. “DAG-based multipath routing for mobile sensor networks”. In: ICT Convergence (ICTC), 2011 International Conference on. 2011, p. 261–266. doi: 10.1109/ICTC.2011.6082593.

[23]

Ian Akyildiz Ismail, Ian F. Akyildiz en Ismail H. Kasimoglu. Wireless Sensor and Actor Networks: Research Challenges. 2004.

[24]

Haeyong Kim e.a. Optimal Multi-sink Positioning and Energy-efficient Routing in Wireless Sensor Networks.

[25]

Philip Levis e.a. “Trickle: a self-regulating algorithm for code propagation and maintenance in wireless sensor networks”. In: Proceedings of the 1st conference on Symposium on Networked Systems Design and Implementation - Volume 1. NSDI’04. San Francisco, California: USENIX Association, 2004, p. 2–2. url: http://dl.acm.org/citation.cfm? id=1251175.1251177.

[26]

P. Levis e.a. The Trickle Algorithm. RFC 6206 (Proposed Standard). Mrt 2011. url: http://www.ietf.org/rfc/rfc6206.txt.

[27]

Jinbao Li e.a. “Routing in Multi-Sink Sensor Networks Based on Gravitational Field”. In: Embedded Software and Systems, 2008. ICESS ’08. International Conference on. 2008, p. 368–375. doi: 10.1109/ICESS.2008.14.

[28] Mica wireless sensor node. url: http://www.eecs.berkeley.edu/IPRO/Summary/Old. summaries/03abstracts/polastre.1.html.

BIBLIOGRAFIE

[29]

93

Ingrid Moerman e.a. “WiLab: a large-scale real-life wireless test environment at IBBT”. eng. In: Intelligent sensor and actuator based systems for mechatronics, Presentations. Anderlecht, Belgium, 2008.

[30]

¨ F. Osterlind en Swedish Institute of Computer Science. A Sensor Network Simulator for the Contiki OS. SICS technical report. Swedish institute of computer science, 2006. url: http://books.google.be/books?id=vqfrMQAACAAJ.

[31]

F. Osterlind e.a. “Cross-Level Sensor Network Simulation with COOJA”. In: Local Computer Networks, Proceedings 2006 31st IEEE Conference on. 2006, p. 641–648. doi: 10. 1109/LCN.2006.322172.

[32]

E.I. Oyman en C. Ersoy. “Multiple sink network design problem in large scale wireless sensor networks”. In: Communications, 2004 IEEE International Conference on. Deel 6. 2004, 3663–3667 Vol.6. doi: 10.1109/ICC.2004.1313226.

[33] ProtoThreads. url: http://dunkels.com/adam/pt/. [34]

J. Romkey. “A Nonstandard For Transmission of IP Datagrams Over Serial Lines: SLIP; RFC1055”. In: Internet Request for Comments 1055 (jun 1988).

[35] SenseNodeWireless Sensor Node. url: http://www.defence-industries.com/contractors/ army/base-camp-protection/genet/#a. [36] The eLua serial multiplexer. url: http://www.eluaproject.net/doc/v0.8/en_sermux. html. [37]

P. Thubert. Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL). RFC 6552 (Proposed Standard). Mrt 2012. url: http://www.ietf. org/rfc/rfc6552.txt.

[38] Tmote Sky Datasheet. url: http : / / www . eecs . harvard . edu / ~konrad / projects / shimmer/references/tmote-sky-datasheet.pdf. [39]

Nicolas Tsiftes, Joakim Eriksson en Adam Dunkels. Poster Abstract: Low-Power Wireless IPv6 Routing with ContikiRPL.

[40] Tunslip. url: http://wismote.org/doku.php?id=development:tools#tunslip. [41]

J.P. Vasseur en A. Dunkels. Interconnecting Smart Objects with IP: The Next Internet. Elsevier Science, 2010, p. 251–288. isbn: 9780123751669. url: http://books.google. be/books?id=mVji-YA5kgEC.

BIBLIOGRAFIE

[42]

94

J. Vasseur e.a. Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks. RFC 6551 (Standards Track). Mrt 2012. url: http : / / www . ietf . org / rfc / rfc6551.txt.

[43]

Zoltan Vincze, Rolland Vida en Attila Vidacs. “Deploying Multiple Sinks in Multi-hop Wireless Sensor Networks”. In: Pervasive Services, IEEE International Conference on. 2007, p. 55–63. doi: 10.1109/PERSER.2007.4283889. url: http://ieeexplore.ieee. org/xpl/articleDetails.jsp?arnumber=4283889.

[44] Volcano monitoring. url: http://fiji.eecs.harvard.edu/Volcano. [45]

Qin Wang, M. Hempstead en Woodward Yang. “A Realistic Power Consumption Model for Wireless Sensor Network Devices”. In: Sensor and Ad Hoc Communications and Networks, 2006. SECON ’06. 2006 3rd Annual IEEE Communications Society on. Deel 1. 2006, p. 286–295. doi: 10.1109/SAHCN.2006.288433.

[46]

T. Winter e.a. RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. RFC 6550 (Proposed Standard). Mrt 2012. url: http://www.ietf.org/rfc/rfc6550.txt.

[47] Wireless Sensor Node. url: http://mwrf.com/systems/building-wireless-sensornetworks.

Performatie van RPL met meerdere sinks in draadloze sensornetwerken

Recommend Documents