Performance Evaluation of MAC protocols in Wireless Sensor Networks

(1)

Performance Evaluation of MAC protocols

in Wireless Sensor Networks

Mälardalen University Sweden

School of Innovation Design and Engineering

Thesis for the Degree of Bachelor of Science in Engineering Student: Mattias Orell

Date: 2016-06-10

Examiner: Elisabeth Uhlemann Supervisor: Maryam Vahabi

(2)

Abstract

Wireless Sensor Networks have limited resources in terms of processing capability, battery power, and channel bandwidth, which makes them both lightweight and cheap. These limitations and also advantages come with some problems regarding network lifetime and fault tolerance, as the nodes share the same wireless media with WiFi, Bluetooth and microwaves. The protocol that affects this the most is the Medium Access Control (MAC) protocol running on the MAC layer. The traditional MAC layer in wireless networking is responsible for accessing the wireless medium and decides when and how data is sent. This is really important as the wireless media is shared between all nodes and collisions needs to be avoided. In a typical sensor network operating system (ContikiOS), the MAC layer design is split into three main parts; (I) MAC, (ii) framer, and (iii) RDC (Radio Duty Cycling). Each of these parts constitute a driver which is responsible for its tasks and it is the combination of these drivers that create the traditional MAC layer. The two drivers which are focused on in this work is the MAC driver and the RDC driver. The MAC driver is responsible for detecting collisions and retransmissions. The MAC drivers being evaluated in this thesis are CSMA and NullMAC. The RDC driver is responsible for the nodes’ wakeup and sleep mechanism. This makes it the most important one as it controls if the radio is on and thus greatly affects both the delay and the energy consumption of the node. The RDC drivers evaluated in this research are ContikiMAC, XMAC and NullRDC. Through extensive simulations with ContikiOS, six different topologies with different parameters are considered.

The different MAC design were compared by evaluating them in terms of average delay, delivery rate and overhead. The resulting analysis concluded that the simulations running CSMA as the MAC driver improves the delivery rate by just adding a slightly more delay in comparison to the NullMAC driver. Simulations running ContikiMAC as the RDC driver has significantly higher delivery rate than the other RDC drivers, with the tradeoff of having a higher delay. The NullRDC RDC driver reveals the lowest average delay, while consuming more power than other RDC drivers by keeping the radio always on. Thus, based on the results from the simulations, it is possible to simply choose proper MAC and RDC drivers in ContikiOS in order to provide reliability and timeliness based on application requirements.

(3)

Acknowledgements

Big thanks to both Hossein Fotouhi and Maryam Vahabi for supporting me through this work and having the patience to explain the concepts of sensor networks for me and answering my multitude of questions.

(4)

1. Introduction

Wireless Sensor Networks (WSN) are data networks consisting of sensor nodes [1]. Sensor nodes have limited processing capability, battery power and channel bandwidth. These characteristics allow sensor nodes to be lightweight and cheap. A sensor network is useful for gathering information from sensor nodes and distributing measurements to the destination. Sensor nodes have a low-power radio and operate in the unlicensed ISM bands (2.4GHz), which is shared with WiFi, Bluetooth, microwave and other wireless gadgets. This results in unreliable links, which subjects to many sources of interference.

The Medium Access Control (MAC) layer in wireless networking provides access to the wireless media. It is responsible for deciding who get to send data and when they send it. This is really important in wireless networking as all nodes share the same media, which is used to send traffic. Only one node can send at the time, and concurrent transmission results in packet collision and packet loss [2]. The MAC protocol used in WSN have more demands on them, considering that the network has unreliable links and power limitations. In many cases, WSNs provide time sensitive applications. This means that the protocols need to be resource efficient, time efficient and reliable [3].

The selection of an appropriate MAC protocol for a WSN is essential by considering how much it affects the lifetime and performance of the network. That is why testing is needed to decide which protocol fits each scenario. A WSN monitoring in an agricultural application might not have the same demands as a WSN tasked with monitoring patients at a hospital [4]. The agricultural application is exposed to a more humid environment, this makes the wireless media more unreliable and makes the resilience of the WSN important. If the WSN will be used for a long term analysis or statistics, the energy consumption also plays a vital part. The WSN monitoring patients can have a requirement that it is really time sensitive, and thus the MAC protocol must provide a low delay guarantee. The layout of the nodes also varies depending on the where they will operate. In a hospital it might need to be placed along a corridor or inside rooms with the nodes close to each other. Nodes which are placed outside when monitoring plants will on the other hand need to cover a large area and the nodes are farther apart. This shows that different applications of WSN need different MAC protocols.

1.1 Problem formulation

Various MAC protocols have been implemented for WSNs. However, using these protocols requires some knowledge from their limitations and also application requirements. The comparison between the different MAC designs will be conducted in ContikiOS. ContikiOS have a more in depth approach to the MAC design by splitting it up into three different parts with each one constituting a driver which handles all its tasks. The two parts which will be evaluated is the MAC driver and the RDC (Radio Duty Cycling) driver. The MAC driver is responsible for controlling the detection of collisions while the RDC driver is responsible for turning on and off the radio. In this work, we are tackling the problem of selecting a proper

combination of MAC and RDC drivers for WSN applications in order to increase their performance. We further elaborate the problem statement in the follow items:

(7)

2  Define network set-up in order to compare drivers, this includes varying node

placements and the amount of interference in the network.

 Compare the drivers in terms of average delay, delivery rate and overhead. Average delay is important as many applications demand a low delay, delivery rate is important as some applications need to be sure that the packets is able to be transmitted and overhead is important as it shows how much extra packets need to be sent when using a driver.

 Find pros and cons with different protocols as there might not be a clear choice in what protocol should be chosen for all applications.

2. Background

There are various MAC protocols designed for WSNs by considering their intrinsic limitations. In this Thesis work, the MAC protocols that have been implemented in one of the commercial-off-the-shelf (COTS) operating systems for WSNs (Contiki) is evaluated. In this way, i describe the basics in Contiki and its emulator (Cooja). There are some relevant issues regarding MAC design in Contiki that will be elaborated in this section.

2.1 ContikiOS

The operating system that is going to be run on the nodes is called Contiki. Contiki is an open source operating system for devices with a low amount of memory that fits for using in sensor nodes [5]. Contiki is written in the C language and is using the uIP library for its TCP/IP stack. uIP is a minimalistic TCP/IP implementation that focuses on the TCP, ICMP and IP protocols, this makes it a good fit for sensor nodes [5]. Contiki supports multiple different platforms by being able to have platform-specific implementations for each platform [6]. The system is purely event-based that concludes in providing process being able to share the same stack, and thus having lower computation overhead, and less memory than a regular multi-threaded system [5].

2.2 Cooja

Cooja is a network simulator for networks running on ContikiOS. Cooja supports simulation of several different types of nodes and each node can be individually programmed with its own code [7]. The simplest way to get started with Cooja is using Instant Contiki. Instant Contiki is a preinstalled Virtual Machine that runs on Ubuntu with Cooja preinstalled. Figure 1 shows a simple implementation of a sensor network running RPL-UDP on IPv6.

(8)

3

Figure 1: Small sensor network running on Cooja.

2.3 MAC layer design in ContikiOS

In ContikiOS, the MAC layer design is split into three main parts; (i) MAC layer, (ii) framer layer, and (iii) RDC layer. It is the combination of these three layers that creates the traditional MAC layer. Each layer is running its own protocol called a driver, it is the different combinations of these drivers that are being evaluated in this work as they together function as a traditional MAC protocol. The layer called the MAC layer is responsible for detecting collisions, retransmissions and addressing [8]. The framer layer is a collection of functions which is used to create and read frames being sent and received. The RDC layer is the main focus in this work as it controls the wake-up and sleep mechanism. It is most important as it controls if the radio is turned on or off. This makes it greatly affect both the delay and energy consumption in the node as the greatest energy waste comes from idle listening radios. The idea of splitting the MAC layer design into three steps was applied to Contiki in order to facilitate MAC configuration and using various MAC protocols [8]. The protocol running in the MAC layer of ContikiOS is called the MAC driver and the protocol running for the RDC layer is called the RDC driver. The term driver and protocol are interchangeable but to avoid confusing the term driver will be used in this work for the protocols running on the ContikiOS MAC and RDC layer.

2.3.1 MAC drivers

Currently ContikiOS supports two different MAC drivers, which are CSMA (carrier sense multiple access) and NullMAC. CSMA is a driver, which utilizes a queue that keeps data packets, and if it has a packet to send, it will perform carrier sensing, and send the packet if the medium is free [9]. In case of broadcasting, packets are accumulated in the queue. Instead data packets are sent immediately without carrier sensing. NullMAC is a minimalistic driver that simply forwards traffic to the appropriate part of the RDC [10].

2.3.2 RDC drivers

The RDC drivers available for ContikiOS are ContikiMAC, X-MAC and NullRDC. The RDC driver is the most important driver in this work as it has to decide when the radio should be turned off or on. One of the greatest energy wastes on a node comes from idle listening, which means that the radio is turned on but not receiving or transmitting any data [4]. As sensor nodes are battery driven, minimizing energy consumption becomes really important. It is also

(9)

4 important that the node is not sleeping for too long as the delay will increase with long sleep timers. This can be critical for time sensitive applications.

ContikiMAC is an asynchronous sender initiated protocol, asynchronous means that it does

not synch with a global clock and sender initiated means that the sender is responsible for waking the receiver [11]. ContikiMAC is similar to other low-power listening protocols but have a more advanced wake-up mechanism [12]. When a sender sends a unicast packet it keeps repeating the message until it receives an ACK from the receiver, the sender saves the wake up time of the receiver for future transmissions [8]. Figure 2 shows how the sender uses the knowledge of knowing approximately when the receiver will wake up. This function is called Transmission phase-lock [12]. When a sender sends a broadcast message it will send it for a whole wake up period, and all nodes should wake up during some time of this period, and be able to receive the message [11].

Figure 2: ContikiMAC using knowledge of the wake up time of the receiver when sending data [12].

X-MAC is a MAC protocol that uses a technique called short preamble. Ordinary low-power

listening utilizes a long preamble, which is prone to create some waste of energy as the sender will send the whole preamble before the receiver may respond that it is awake [13]. Short preamble in contrast sends shorter preambles with a pause between, where the receiver may respond that it has woken up. Another problem with long preamble is that it wakes all the nodes until the preamble ends, and the sender says which node should receive the message. This is called the overhearing problem. With short preamble the preamble contains information about the receiver so that the other nodes may go to sleep earlier[13]. Figure 3 shows the comparison between the long preamble and X-MAC short preamble.

(10)

5

Figure 3: Comparison between X-MAC short preamble and Low Power Listening (LPL) long preamble [13].

NullRDC is similar to NullMAC, a simplistic driver that is used to develop new drivers.

NullRDC has two main tasks; (i) it uses framer functions to create a header, and (ii) it simply checks if the packet was received or a collision has occurred. It does not take any consideration to energy saving at all as it keeps the radio always on [15].

3. Methodology

Throughout this research, the following four main steps were followed:

 Review related works on MAC protocols in WSNs, both Time Division Multiple Access (TDMA) and Carrier Sense Multiple Access (CSMA) protocols should be included. Two of these protocols will be ContikiMAC and X-MAC.

 Learn basics in using one of the common operating systems for sensor networks, known as Contiki, and also its simulator (Cooja) [16].

 Investigate few MAC protocols that were implemented in Contiki. These protocols will be the ones reviewed in the earlier step.

 Provide comparison between the selected MAC protocols in various network conditions. This comparison will be in terms of end-to-end delay, packet delivery rate, energy consumption, etc.

By going through the above steps, it will be possible to start creating an overview on how protocols are working. Then that knowledge will be used to reflect upon the results of the tests. This will help explaining why one protocol might be better suited for a specific scenario. The steps taken during simulations will be more thoroughly be explained in the next chapter.

(11)

6

4. Technical description

The simulations is conducted in Cooja, and is using the IPv6 UDP-RPL example as the basis. This example uses IPv6 addressing and periodically sends UDP data packets with a “Hello sequence_id”, where sequence_id is the number of the packets.

There are two types of nodes in the network, Server and Client. As this example works with only a single sink, there can only be one server but there can be any number of clients. The client is modified to allow having the periodical data sent at milliseconds intervals and to print the current rate at startup. In addition to these two types, another version of the client was made that is called “silent client” which works exactly as an ordinary client, except it does not provide any output. It was made so that there would not be any unnecessary output that slows down the simulation --- see Appendix 1-3 for the codes.

To change between different MAC drivers and RDC drivers, “project-conf.h” needs to be added. It is added by including it in the Makefile for the nodes, and then by defining NETSTACK_CONF_MAC and NETSTACK_CONF_RDC in the project-conf.h, it is possible to alter MAC drivers --- see Appendix 4 for the code used in the project-conf.h file.

4.1 Simulation variables

The possibility of getting successful data packets in Cooja is managed by a link quality parameter that has a relation with number of hops. For instance, in a scenario with the link quality 75%, where the clients are 3 hops from the server, the chance of receiving packets successfully at the server is 75%3 = ~42% . This is only considering the simulated interference in the network, and is not taking into account any functions the drivers may have. The variable data interval used in these simulations dictates how often the clients will attempt to send a data packet to the server. There is a built-in randomness to when the clients send their packets, so that collisions may be avoided. This controls the amount of data going over the topology, something to keep in mind is that even though some clients are silent clients they will still send out data packets at the same rate as the ordinary clients. To avoid collisions, a small amount of random time is added to the send interval of each node. This will hinder the nodes from sending their packets at the exact same time.

The main issues that affect the delay of the simulations are the presence of collisions, the back off timers, retransmissions and full CSMA queues. The issues that affect the overall delivery rate negatively are collisions and unsynchronized wake up timers. The issues that affect the delivery rate positively are back off timers, retransmissions and synchronized wake up timers. One issue that affects the delay and delivery rate negatively is the case where the network becomes congested that means existence of many packets that the network should handle. This can happen when the delay is higher than the send interval that makes the network fill up with packets trying to reach the server.

(12)

7

4.2 Routing Protocol for Low power and Lossy Networks

The routing protocol being run in these simulations is Routing Protocol for Low power and Lossy Networks (RPL). The RPL protocol is made for IPv6 wireless networks with a low data rate and with limited resources on the nodes [17]. In RPL, the nodes organize themselves by putting each node in a rank which go from high to low where low means that the node are closer to the sink/root [18]. This is then used for the nodes to identify a parent which it will use when sending packets to the sink.

4.3 Topologies

Throughout this research a small collection of different topologies will be used to simulate different scenarios. The topologies being used is called Simple, Line scenario 1, Line scenario 2, Grid, Mesh and Star. There are two variables that will vary between scenarios, and these are the data rate and the link quality. The data rate will affect the overall load on the network and shows how much traffic a scenario can manage. The data rate is expressed in data send interval. The link quality is expressed in a percentage which shows the existence of interference. All the topologies, except the “Simple” one, will be using scenarios with 100% or 75% link quality and data intervals ranging from 10 seconds to 500 milliseconds.

4.3.1 Simple topology

The Simple topology is a small network with only two devices, one client and one server. The nodes are placed 10 meter apart; the topology is shown in Figure 4. In contrast to the other topologies, a different set of data rates and link qualities are used. In the simulations with the simple network, the scenarios consist of data rates from 1000 ms down to 10 ms. The link quality will be tested for a link quality of 100%, 85% and 50%.

Figure 4 - Simple topology with one server and one client.

4.3.2 Line scenario 1 topology

The Line scenario 1 topology is a topology, where the nodes are placed in a line in a way that each can only reach its closest neighbors. The nodes are placed 30 meter from each other --- see the topology in Figure 5.

This type of topology might come up when placing nodes in a corridor or along a border. Problems that might raise from this topology are single point of failure and the hidden terminal

(13)

8 problem. Single point of failure means that if one of the middle nodes stops responding or becomes congested then the nodes farther from the server not be able to reach the server. The hidden terminal means that collisions can occur when two nodes send packets simultaneous because they cannot sense each other’s traffic [19].

Figure 5 - Line scenario 1 topology with one server and four clients.

4.3.3 Line scenario 2 topology

The Line scenario 2 Topology is similar to the Line scenario 1 in the way the nodes are placed, but in Line scenario 2 the nodes are placed with 20 meter distance resulting in the nodes being able to reach two nodes in each direction. The topology can be seen in Figure 6.

This topology may appear in the same places as the previous line topology, that is in something like a corridor or along a border. This topology removes the single point of failure problem that was existed in the previous topology by each client having multiple nodes from which it can reach the server. The topology also mitigates the hidden terminal problem (but not eliminating it) as more nodes are able to reach each other. One thing introduced in this topology is the overhearing problem, when a node is transmitting a packet to a neighbor all nodes in range will also receive the packet. This causes some unnecessary wake time for the nodes not receiving the packet but are still in range.

(14)

9

4.3.4 Grid topology

The Grid Topology is a topology where the nodes are arranged into a grid where they can reach their closest neighbors. The nodes are placed with a 37-meter interval; the topology can be seen in Figure 7.

This topology might appear when the network needs to cover a large area. In resemblance with the line scenario 2 topology, this topology also has a slight amount of overhearing happening. In this topology, the packets will have two equally long paths to choose between when trying to reach the server from the farthest, which can affect the results.

Figure 7 - Grid topology with one server and three clients.

4.3.5 Mesh topology

In the Mesh Topology, nodes are arranged in such a way that all nodes can reach each other. It means that they are located in a single broadcast domain. The nodes are placed within 20 meter of each other, where the topology can be seen in Figure 8.

This topology may appear on sensor networks covering a smaller area or in a Body or Personal Area Network. It is possible to place them closer to each other by reducing the transmission power, which enables using them in various applications. One of the main concern with this topology is that it can create a lot of overhearing when all nodes can reach each other. One of the main benefits of this topology is that there is no hidden terminal problem, and all the client nodes have a single hop to the server, which reduces delay.

(15)

10

Figure 8 - Mesh topology with one server and three clients.

4.3.6 Star topology

The Nodes in the star topology are arranged in a four pointed star or a plus where the points are 37 meter from the center node. This makes each client able to reach the server but not able to reach the other clients. This is a specific simulation setting for evaluation, which does not eliminate star network topologies for being in same transmission range. The topology can be seen in Figure 9. Each client node in a star network topology has single hop communication with the server, which consequently results in eliminating routing protocols.

This topology can be found in various scenarios where a server can be centrally placed. One scenario that it can appear could be indoors when there are walls blocking the signal between the clients. This topology is the one of these topologies which have the biggest problem with hidden nodes. Like the mesh topology all clients in this topology are only one hop away from the server which results in a lower delay. It is also possible to employ star topology on human body, where sensors approach server node directly, and clients may experience radio overlapping.

(16)

11

Figure 9 - Star topology with one server and four clients.

4.4 Test protocol

When running these tests some guidelines are needed to be made to ensure that the simulations would be run fairly. The steps followed when running a simulation for a single scenario are the following:

1. Check if the simulation topology matches the correct topology.

2. Check the range of all the nodes and make sure they can reach all the nodes they are supposed to but not the ones which should be out of range.

3. Check that the link quality matches the current scenario being tested.

4. Remove any old PCAP1 files in the build directory so that the new one cannot be mistaken for an old one.

5. Clear the file receiving the output from the nodes.

6. Start the simulation, check the initial output from the nodes so that they are running the correct protocols/drivers and at the correct send interval.

7. Monitor the simulation to make sure that Cooja does not get stuck, a bug that can appear when running on lower send intervals is that the server and clients will completely lose connectivity. When this happens reload the simulation and save the current results, then run again until enough data is collected.

8. When enough time have passed stop the simulation and collect the data from the PCAP file and node output.

The tools which will be used to analyze the data will be Wireshark and a simple C program that was created for calculating average delay. It allows analyzing the node output from Cooja, so that it can calculate the average delay, and counts the amount of missed and received packets. The code can be found in Appendix 5. Wireshark is a free network protocol analyzer that can be used both to monitor running network interface or to analyze PCAP files. In this work it is used to see how much overhead are being generated in the different scenarios.

1_{PCAP (Packet Capture) is a format which packet capturing software uses to save the} captured packets.

(17)

12

5. Results and analysis

Several extensive simulation experiments have been performed, which are illustrated and discussed in this section. They will show that how the protocols relate to each other, and the change when the send interval becomes shorter. To see the raw values of tables, see Appendix 6-11. The drivers are presented in “MAC-RDC” format. For instance, “CSMA-ContikiMAC” presents the “CSMA” MAC driver and “ContikiMAC” RDC driver being used in a MAC design. The link quality is presented in “TX/RX: %” format. For instance, “TX/RX: 75%” presents a link quality of 75%.

5.1 Simple topology results

The results from the simulations run on the simple topology shows that while NullRDC is both the one with the lowest delay and the least overhead, ContikiMAC is the preferred one regarding delivery rate. Due to the limitations related to the simulator and hardware, it was impossible to run CSMA-XMAC with a send interval less than 125 ms, and thus there will be no data for the lower intervals for CSMA-XMAC in this topology. XMAC have the highest ratio of overhead and a delivery rate close to that of NullRDC, it does have a lower delay than ContikiMAC which can make it useful if the delay is a concern. It was also made apparent that if a network is going to send many packets in a short time frame, then CSMA should be used to avoid collisions.

5.1.1 Average delay

Figure 10 shows average delay with 100% link quality. The results show that ContikiMAC have the highest average delay by a good margin, which is due to the retransmissions. Another issue is that for both XMAC and NullRDC, the NullMAC driver reduces its delay, and this is not true for ContikiMAC as NullRDC introduces more collisions than CSMA, and therefore creates more retransmissions.

By reducing the link quality to 85% (see Figure 11), both ContikiMAC and NullRDC remain largely unaffected, while the delay in XMAC increases. If the link quality is lowered down to 50% it can be seen in Figure 12 that XMAC delay keeps increasing to the level of ContikiMAC, at the same time as ContikiMAC have a slight increase in delay. This shows that in terms of delay, NullRDC is vastly superior and if the link quality is bad ContikiMAC often is a better choice over XMAC.

(18)

13

Figure 10 : Simple topology, TX/RX: 100% - Average Delay comparison with the send interval 1 second.

Figure 11: Simple topology, TX/RX: 85% - Average Delay comparison with the send interval 1 second.

0 20 40 60 80 100 120 A ver ag e D ela y (ms) 0 20 40 60 80 100 120 A ver ag e D ela y (ms )

(19)

14

Figure 12: Simple topology, TX/RX: 50% - Average delay comparison with the send interval 1 second.

Figure 13 shows that the average end-to-end delay increases as the data generation rate increases from 10 to 1000 ms in both MAC designs of CSMA-ContikiMAC and NullMAC-ContikiMAC. With the latter MAC design, there is a considerable increase in the average delay from 100 ms. The reason is that the NullMAC-ContikiMAC starts re-transmitting the collided packets, which in turn increases the average delay.

In Figure 14 it can be seen that NullMAC-XMAC like NullMAC-ContikiMAC starts getting a higher delay when the send interval reaches 100 ms. Figure 15 shows how NullMAC is almost not affected at all by the increase in data being generated, it maintains its low delay all the way. From these figures that in terms of low delay NullRDC is to be preferred, if the other ones are to be used in networks with more data then CSMA should be used together with them to avoid collisions.

Figure 13: Simple topology, TX/RX: 100% - Average Delay of CSMA-ContikiMAC and NullMAC-ContikiMAC protocols with varying data rates.

0 20 40 60 80 100 120 A ver ag e D ela y (ms ) 0 50 100 150 200 250 300 CSMA-ContikiMAC NullMAC-ContikiMAC A ver ag e D ela y (ms )

Send interval (ms)

1000 500 100 50 10

(20)

15

Figure 14: Simple topology, TX/RX: 100% - Average Delay of CSMA-XMAC and NullMAC-XMAC protocols with varying data rates.

Figure 15: Simple topology, TX/RX: 100% - Average Delay of CSMA-NullRDC and NullMAC-NullRDC protocols with varying data rates.

5.1.2 Delivery rate

As can be seen in Figure 16, all the combinations of drivers are able to deliver a 100% delivery rate when the link quality is at 100%. When the link quality degrades ContikiMAC keeps having almost a 100% delivery ratio, this is due to it using retransmissions for lost packets. This can be seen in Figure 17 and Figure 18. Both XMAC and NullRDC are getting a delivery rate close to the actual quality of the link. In this case of delivery rate ContikiMAC is clearly the best one when the link quality is not around 100%.

0 50 100 150 CSMA-XMAC NullMAC-XMAC A ver ag e D ela y (ms )

Send interval (ms)

1000 500 125 100 50 10 0 5 10 15 20 CSMA-NullRDC NullMAC-NullRDC A ver ag e D ela y (ms )

Send interval (ms)

1000 500 100 50 20 10

(21)

16

0% 20% 40% 60% 80% 100% D eliv er y Ra te 0% 20% 40% 60% 80% 100% D eliv er y Ra te

(22)

17

By looking at Figure 19, Figure 20 and Figure 21, it can be seen that the delivery rate for all drivers is keeping up at 100% except for CSMA-ContikiMAC when the send interval is 10 ms. CSMA-ContikiMAC starts dropping packets due to the nodes becoming congested and packets are dropped as the CSMA cannot keep up. ContikiMAC is the one being affected as it is the one with the highest average delay, the other one are forwarding fast enough to not become congested.

Figure 19: Simple topology, TX/RX: 100% - Delivery rate of CSMA-ContikiMAC and NullMAC-ContikiMAC protocols with varying data rates.

0% 20% 40% 60% 80% 100% D eliv er y Ra te 0% 20% 40% 60% 80% 100% CSMA-ContikiMAC NullMAC-ContikiMAC D eliv er y Ra te

Send interval (ms)

1000 500 100 50 10

(23)

18

Figure 20: Simple topology, TX/RX: 100% - Delivery rate of CSMA-XMAC and NullMAC-XMAC protocols with varying data rates.

Figure 21: Simple topology, TX/RX: 100% - Delivery rate of CSMA-NullRDC and NullMAC-NullRDC protocols with varying data rates.

5.1.3 Overhead

The Figure 22 shows clearly that NullRDC are the one driver who generates the least amount of overhead. By comparing Figure 22, Figure 23 and Figure 24 it can be see that when the quality of the link degrades, ContikiMAC decreases its ratio of overhead while XMAC increases and NullRDC stays unaffected.

0% 20% 40% 60% 80% 100% CSMA-XMAC NullMAC-XMAC D eliv ery R at e

Send interval (ms)

1000 500 125 100 50 10 0% 20% 40% 60% 80% 100% CSMA-NullRDC NullMAC-NullRDC D eliv er y Ra te

Send interval (ms)

1000 500 100 50 20 10

(24)

19

Figure 22: Simple topology, TX/RX: 100% - Overhead ratio comparison with the send interval 1 second.

0% 20% 40% 60% 80% 100% Ov er h ea d 0% 20% 40% 60% 80% 100% Ov er h ea d

(25)

20

In Figure 25 and Figure 26 it can be seen that both ContikiMAC and XMAC have a similar relation to how much overhead is created with lower send intervals. They both slightly lowers in their overhead ratio which means that the added amount of overhead is almost as many as the amount of added packets. The overhead of NullRDC is easier explained through a table seen in Figure 27, there it can be seen that NullRDC will not increase its overhead when the send interval is lowered. This means that NullRDC will always have about the same amount of overhead packets over a timespan independent of the data rate.

Figure 25: Simple topology, TX/RX: 100% - Overhead of CSMA-ContikiMAC and NullRDC-ContikiMAC protocols with varying data rates.

0% 20% 40% 60% 80% 100% Ov er h ea d 0% 20% 40% 60% 80% 100% CSMA-ContikiMAC NullMAC-ContikiMAC Ov er h ea d

Send interval (ms)

1000 500 100 50 10

(26)

21

Figure 26: Simple topology, TX/RX: 100% - Overhead of CSMA-NullRDC and NullRDC-ContikiMAC protocols with varying data rates.

Simple network TX: 100% RX: 100%

CSMA-NullRDC NullMAC-NullRDC

Run time (min) 10 10 10 10 10 10 10 10 10 10 10 10 Send Interval (ms) 1000 500 100 50 20 10 1000 500 100 50 20 10 Total number of packets 620 1216 6407 12808 33743 35953 618 1217 6412 12806 31460 47227 Number of Control packets 19 20 20 19 19 20 19 19 20 19 19 17

Overhead percentage 3,06% 1,64% 0,31% 0,15% 0,06% 0,06% 3,07% 1,56% 0,31% 0,15% 0,06% 0,04% Figure 27: Simple topology, TX/RX: 100% - Overhead of CSMA-NullRDC and NullRDC-ContikiMAC protocols with

varying data rates.

5.2 Line scenario 1 topology results

In the Line scenario 1 topology the protocol which comes out on top is NullRDC concerning average delay, delivery rate and overhead. This is when the quality of the link is very good, if the link quality is low then ContikiMAC should be utilized. If ContikiMAC or XMAC is being used and the network is going to be sending a data at a reasonable fast rate, then CSMA should also be used to avoid collisions.

By looking at Figure 28 it can be seen that the delay for each protocol is not that even for the different send intervals, most notably is the massive spike in delay in CSMA-XMAC at the 1 second send interval. This spike was examined by running some additional simulations, the results of those can be seen in Figure 29. As the figure shows it steadily increases with the different intervals, this indicates that it shouldn’t be a bug in Cooja and rather that the protocol is unable to keep up with the amount of packets being sent. This can also be seen in CSMA-ContikiMAC as the delay increases by a bit at the 0,5 second send interval. Like most of the time NullRDC remains unaffected by the different send intervals.

0% 20% 40% 60% 80% 100% CSMA-XMAC NullMAC-XMAC Ov er h ea d

Send interval (ms)

1000 500 125 100 50 10

(27)

22

Figure 28: Line scenario 1 topology, TX/RX: 100% - Average Delay comparison with varying send intervals.

Figure 29: Line scenario 1 topology, TX/RX: 100% - Average Delay of CSMA-XMAC over varying send intervals.

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 A ver ag e D ela y (ms )

Send interval (sec)

10 5 2 1 0,5

0 2000 4000 6000 8000 10000 CSMA-XMAC A ver ag e D ela y (ms )

(28)

23 When comparing the average delay with different link qualities in Figure 30 and Figure 31 the standout difference is the increase in delay for CSMA-ContikiMAC. This is due to it having to do so many retransmissions which in turn can create some congestion on the network in addition to adding to the delay. The other protocols only see a slight increase in delay with a lower quality link.

Figure 30: Line scenario 1 topology, TX/RX: 100% - Average delay comparison with the send interval 1 second.

In Figure 32 it can be seen that CSMA greatly helps mitigate collisions and improves the delivery rate of all the drivers. In this scenario NullMAC-XMAC is the clear loser as it only has a delivery rate of about 40% as its best. Both ContikiMAC and NullRDC are able to achieve a good delivery rate in this topology, but this is from two different reasons. ContikiMAC is able to have a good delivery rate because its retransmissions of packets. NullRDC is able to keep up the good delivery rate by having the packets spend so little time on the network, this in turn by itself avoids collisions as the already have reached their destination when new packets are sent.

0 1000 2000 3000 4000 5000 6000 7000 8000 A ver ag e D ela y (ms ) 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 A ver ag e D ela y (ms )

(29)

24 NullMAC-ContikiMAC sees a lower delivery rate from the fact that it has a high amount of collisions. CSMA-XMAC delivery rate spikes down when the send interval reaches 1 second, this is due to the network getting congested which results in more dropped packets. This is a consequence from CSMA-XMAC having a to large delay which makes the packets stay on the network to long.

Figure 32: Line scenario 1 topology, TX/RX: 100% - Delivery rate comparison with varying send intervals.

In Figure 33 it can be seen that XMAC is really struggling to get packets all the way to the server, this is due to all the collisions happening and the absence of retransmissions. The results from simulations with a lower quality link can be seen in Figure 34. Here XMAC is having an abysmal low delivery rate. NullRDC have a low delivery rate which can easily be explained with that if each hop has about 75% chance of a successful packet transmission then over four hops you will have 75%4 _{= ~31% chance of a packet reaching the server. This is slightly} higher than NullRDC but this is not taking into account the distance between nodes which also lowers the chance of a successful transmission.

Figure 33: Line scenario 1 topology, TX/RX: 100% - Delivery rate comparison with the send interval 1 second.

0% 20% 40% 60% 80% 100% Deli very R at e

Send interval (sec)

10 5 2 1 0,5

0% 20% 40% 60% 80% 100% D eliv er y Ra te

(30)

25

Figure 34: Line scenario 1 topology, TX/RX: 75% - Delivery rate comparison with the send interval 1 second.

5.2.3 Overhead

As can be seen in Figure 35, ContikiMAC ratio of overhead decreases when the data interval decreases. This means that in this topology ContikiMAC is only generating slightly more overhead with more packets being sent. XMAC is keeping the overhead ratio really high with both high and low send intervals which indicates that the amount of overhead is increasing at the same rate as the amount of data increases. NullRDC keeps being unaffected as in the simple topology.

Figure 35: Line scenario 1 topology, TX/RX: 100% - Overhead ratio comparison with varying send intervals.

When comparing Figure 36 and Figure 37 it can be deduced that ContikiMAC does not need so much extra overhead while dealing with the drops and its retransmissions. XMAC is still having a really high ratio of overhead independent of how good the link is.

0% 20% 40% 60% 80% 100% D eliv er y Ra te 0% 20% 40% 60% 80% 100% Ov er h ea d

(31)

26

Figure 36: Line scenario 1 topology, TX/RX: 100% - Overhead ratio comparison with the send interval 1 second.

Figure 37: Line scenario 1 topology, TX/RX: 75% - Overhead ratio comparison with the send interval 1 second.

5.3 Line scenario 2 topology results

From the results of the simulations on the Line scenario 2 topology it can be said that as long as the link quality is perfect NullRDC is still to be preferred in terms of delay, delivery rate and overhead. But as soon as the link quality starts to degrade NullRDC rapidly drops in delivery rate, in that case ContikiMAC is to be preferred as it is able still deliver almost 100% delivery rate.

The Figure 38 is very similar to the same figure for the Line scenario 1 Figure 28, the main difference is that the spike for CSMA-XMAC is not as high, this spike is only half of the other one. In this topology the server is fewer hops away the delay is lower. The same problem the drivers have this time is the same as in the Line scenario 1, the drivers are not able to keep up with the data being generated.

(32)

27

Figure 38: Line scenario 2 topology, TX/RX: 100% - Average delay comparison with varying send intervals.

When looking at Figure 39 and Figure 40 it can be seen that with a good quality link CSMA-ContikiMAC is keeping an even delay with NullMAC-CSMA-ContikiMAC while CSMA-XMAC is having really long delays. When the link goes down in quality then CSMA-XMAC gets a lower delay and CSMA-ContikiMAC goes up really high. The reason why CSMA-ContikiMAC is getting so long delays is due to all its retransmissions which increases the average delay by a good margin. CSMA-XMAC lowering in delay can be attributed to the low amount of successful transmissions and that the ones actually being able to arrive having a respectable delay. NullRDC keeps being unaffected.

0 500 1000 1500 2000 2500 3000 3500 4000 A ver ag e D ela y (ms )

Send interval (sec)

10 5 2 1 0,5

0 500 1000 1500 2000 2500 3000 3500 4000 A ver ag e D ela y (ms )

(33)

28

In Figure 41 it can be seen that the protocols are able to maintain a good delivery rate as long as the send interval isn’t too low. CSMA-XMAC is becoming congested when the send interval reaches 1 second, CSMA-ContikiMAC is able to mitigate the collisions caused by the congestion by using its retransmissions. NullMAC-ContikiMAC and NullMAC-XMAC both becomes too congested at a send interval of 0,5 seconds which causes them to start drop packets.

Figure 41: Line scenario 2 topology, TX/RX: 100% - Delivery rate comparison with varying send intervals.

Figure 42 shows how all the protocols except CSMA-XMAC is able to maintain a high standard of delivery ratio. CSMA-XMAC is dropping packets due to the congestion being created by it having a long delay which means that the packets are being sent faster than they can traverse the network. The delivery rate of all the protocols is greatly reduced when the link quality is degraded, this can be seen in Figure 43. The only one still doing well is the CSMA-ContikiMAC, this is much due to the retransmissions from ContikiMAC but an ever bigger contribution comes from CSMA. This makes it so that it can avoid collisions which otherwise would have happened, this can be seen as important trough that NullMAC-ContikiMAC got a low delivery rate.

0 500 1000 1500 2000 2500 3000 A ver ag e D ela y (ms ) 0% 20% 40% 60% 80% 100% D eliv er y Ra te

(34)

29

Figure 42: Line scenario 2 topology, TX/RX: 100% Delivery rate comparison with the send interval 1 second.

Figure 43: Line scenario 2 topology, TX/RX: 100% Delivery rate comparison with the send interval 1 second.

5.3.3 Overhead

The overhead in the topology is shown in Figure 44, it is very similar the overhead in Line scenario 1 Figure 35. ContikiMAC overhead decreases with lower data interval indication that it does not need to add as much overhead as data when the send interval decreases. XMAC overhead is increasing in about the same rate as the data is increasing meaning that it will always have a high ratio of overhead. NullRDC remains unaffected and always have the same amount of overhead packets over a time frame disregarding the amount of data being sent.

0% 20% 40% 60% 80% 100% D eliv er y Ra te 0% 20% 40% 60% 80% 100% D eliv er y Ra te

(35)

30

Figure 44: Line scenario 2 topology, TX/RX: 100% - Overhead ratio comparison with varying send intervals.

By comparing Figure 45 and Figure 46 it can be seen that XMAC is still having a high amount of overhead while ContikiMAC is decreasing. The meaning of ContikiMAC decreasing is that the additional traffic created from retransmissions and handling collisions is not adding that much extra overhead.

Figure 45: Line scenario 2 topology, TX/RX: 100% Overhead ratio comparison with the send interval 1 second.

0% 20% 40% 60% 80% 100% Ov er h ea d

Send interval (sec)

10 5 2 1 0,5

0% 20% 40% 60% 80% 100% Ov er h ea d

(36)

31

Figure 46: Line scenario 2 topology, TX/RX: 75% Overhead ratio comparison with the send interval 1 second.

5.4 Grid topology results

In this topology it is apparent that CSMA-XMAC is not performing well when either the send interval is below 1 second or when the link quality is lowered. If reliability is needed ContikiMAC is the clear winner but if the link quality is close to 100% then NullRDC can also function. For delay ContikiMAC performs well but if the delay needs to be below 200 ms then NullRDC is the one which can provide that.

Figure 47 shows the average delay of the protocols; it shows that CSMA-XMAC have a great spike in delay when the send interval reaches 0,5 seconds. The other protocols are having an even amount of delay except for CSMA-NullRDC which also have a spike at the 0,5 second send interval. This is caused by a large amount of collisions.

Figure 47: Grid topology, TX/RX: 100% Average delay comparison with varying send intervals.

When Figure 48 and Figure 49 is compared it is apparent that the CSMA driver really takes a hit when the link quality is decreased. When the link quality is perfect then all the protocols

0% 20% 40% 60% 80% 100% Ov er h ea d 0 1000 2000 3000 4000 5000 A ver ag e D ela y (ms )

(37)

32 have good delay but when it is degraded to 75% link quality, then the CSMA driver greatly increases the delay. This is due to the nature of CSMA and queueing packets to avoid collisions which will lead to an increase in delay.

Figure 48: Grid topology, TX/RX: 100% Average delay comparison with the send interval 1 second.

Figure 49: Grid topology, TX/RX: 75% Average delay comparison with the send interval 1 second.

All the protocols are able to provide a good delivery rate except for CSMA-XMAC; this can be seen in Figure 50. CSMA-XMAC starts dropping packets when the send interval reaches 0,5 seconds. This is due to the high delay which builds up congestion that results in packets being dropped. 0 50 100 150 200 250 A ver ag e D ela y (ms ) 0 500 1000 1500 2000 2500 3000 3500 4000 A ver ag e D ela y (ms )

(38)

33

Figure 50: Grid topology, TX/RX: 100% Delivery rate comparison with varying send intervals.

When the quality of the link is degraded to 75% it can be seen in Figure 51 that while CSMA-ContikiMAC is able to keep an almost 100% delivery rate, this is again thanks to its ability to retransmit packets. NullMAC-ContikiMAC have a lower delivery rate because without CSMA more collisions are happening and ContikiMAC is not able to cope with the extra amount of collisions. XMAC have a very low delivery rate as it is not able to handle any of the collisions. NullRDC is able to have a higher delivery rate than XMAC by having a lower average delay which in turn means that packets will not spend as much time on the network. This reduces congestion and collisions.

Figure 51: Grid topology, TX/RX: 75% Delivery rate comparison with the send interval 1 second.

5.4.3 Overhead

As can be seen in Figure 52, the ContikiMAC driver is not having to add that much overhead for when more traffic is generated. XMAC keeps the overhead at about the same ratio and CSMA-XMAC goes up slightly by 0,5 second send interval, this indicates that a high drop count will result in a greater ratio of control messages. NullRDC keeps the same amount of overhead packets over a time interval regardless of the send interval.

0% 20% 40% 60% 80% 100% D eliv er y Ra te

Send interval (sec)

10 5 2 1 0,5

0% 20% 40% 60% 80% 100% D eliv er y Ra te

(39)

34

Figure 52: Grid topology, TX/RX: 100% Overhead comparison with varying send intervals.

By comparing Figure 53 and Figure 54 it can be seen that XMAC is in need of a higher amount of overhead while ContikiMAC gets a lower ratio as its retransmissions does not generate that much overhead. NullRDC is unaffected by the quality of the link.

Figure 53: Grid topology, TX/RX: 100% Overhead ratio comparison with the send interval 1 second.

Figure 54: Grid topology, TX/RX: 75% Overhead ratio comparison with the send interval 1 second.

0% 20% 40% 60% 80% 100% Ov er h ea d

Send interval (sec)

10 5 2 1 0,5

(40)

35

5.5 Mesh topology results

In this topology NullRDC is performing really well, with the server only being one hop away it does not have a very low delivery rate and in terms of overhead NullRDC is clearly superior. In terms of delivery rate then ContikiMAC comes out on top as it is able to have a delivery rate of almost 100% for all the simulations run on this topology. With a send interval of 1 second all the protocols have a really good delay with the highest ones only being 100 ms. There is only one exception and that is NullMAC-XMAC with a lower quality link, it got an average delay of 250 ms.

It can be seen in Figure 55 that almost all the protocols can keep a respectable low delay, the one which is having trouble is CSMA-XMAC. Some additional simulations where run to analyze the spike in CSMA-XMAC, the results can be seen in Figure 56. The spike is due to a large amount of collisions occurring on the network.

Figure 55: Mesh topology, TX/RX: 100% Average delay comparison with varying send intervals.

Figure 56: Mesh topology, TX/RX: 100% The average delay of CSMA-XMAC with varying send intervals.

In Figure 57 it can be seen that all the protocols have a really good delay in this scenario, NullMAC-XMAC is even close to the delay of NullRDC. This shows that in some cases CSMA increases delay significantly in contrast to NullMAC. If you lower the link quality the reversed happens, Figure 58 shows that NullMAC-XMAC is the one with the highest delay by a good

0 500 1000 1500 2000 A ver ag e D ela y (ms )

Send interval (ms)

10 5 2 1 0,5 0 500 1000 1500 2000 2500 3000 CSMA-XMAC A ver ag e D ela y (ms )

(41)

36 margin. CSMA-ContikiMAC delay increases slightly by the degradation of the links but the rest remain largely unaffected. The increase in delay for NullMAC-XMAC is due to the excessive amount of collisions happening and this results in that the delivery rate also becomes very low.

Figure 57: Mesh topology, TX/RX: 100% Average delay comparison with the send interval 1 second.

Figure 58: Mesh topology, TX/RX: 75% Average delay comparison with the send interval 1 second.

As can be seen in Figure 59, CSMA-XMAC is the only protocol having any real trouble with this topology. When the send interval reaches 0,5 seconds it starts dropping almost all its packets. The other protocols are able keep an almost 100% delivery rate. The drop in delivery rate for CSMA-XMAC can be contributed to an excessive amount of collisions due to its delay being so long and making the network congested.

0 20 40 60 80 100 A ver ag e D ela y (ms) 0 50 100 150 200 250 300 A ver ag e D ela y (ms )

(42)

37

Figure 59: Mesh topology, TX/RX: 100% Delivery rate comparison with varying send intervals.

By comparing Figure 60 and Figure 61 it can be seen that while the link quality is good all the protocols are able to have a high delivery rate. When the link quality is degraded only ContikiMAC is able to keep having a good delivery rate while CSMA-XMAC goes down by a bit and NullMAC-XMAC goes down to a very low delivery rate. NullMAC-XMAC is having a really low delivery rate as this topology is prone to collisions and with the combination of NullMAC which does not to any carrier sensing and XMAC that does not have any retransmissions results in a low delivery rate. NullRDC is not dipping so considerably because the server is only one hop away.

Figure 60: Mesh topology, TX/RX: 100% Delivery rate comparison with the send interval 1 second.

0% 20% 40% 60% 80% 100% D eliv er y Ra te

Send interval (sec)

10 5 2 1 0,5

0% 20% 40% 60% 80% 100% D eliv er y Ra te

(43)

38

Figure 61: Mesh topology, TX/RX: 75% Delivery rate comparison with the send interval 1 second.

5.5.3 Overhead

Figure 62 shows the amount of overhead generated by the protocols. NullRDC keeps having a set amount of overhead packets for a set time interval. ContikiMAC does not have a significant increase in overhead when more data are generated and this is seen by the ratio of overhead is decreasing. This is partly due to the retransmissions increasing the amount of data packets sent while not creating almost any extra overhead. XMAC generates additional overhead in almost the same rate as data increases leaving it with an even amount of overhead.

Figure 62: Mesh topology, TX/RX: 100% Overhead ratio comparison with varying send intervals.

With a lower quality link XMAC increases in amount of overhead while retransmissions for ContikiMAC makes the ratio of overhead lower, this can be seen in Figure 63 and Figure 64. NullRDC remains totally unaffected by the link quality.

0% 20% 40% 60% 80% 100% D eliv er y Ra te 0% 20% 40% 60% 80% 100% Ov er h ea d

(44)

39

Figure 63: Mesh topology, TX/RX: 100% Overhead ratio comparison with the send interval 1 second.

Figure 64: Mesh topology, TX/RX: 75% Overhead ratio comparison with the send interval 1 second.

5.6 Star topology results

The protocols have a reasonable low delay but have a bit higher than the mesh topology as there are more collisions happening when the clients can’t here each other. ContikiMAC is the slowest one with XMAC coming close behind, NullRDC is having a very low delay due to its simplicity. In terms of delivery rate ContikiMAC is the best, XMAC is second as NullRDC is not reliable in terms of the delivery rate. NullRDC is the one with the lowest overhead and with good links ContikiMAC and XMAC have almost the same with XMAC having a bit more than ContikiMAC.

In this topology the delay is varying a bit as can be seen in Figure 65, this is from collisions happening when the clients try to send at the same time to many times. ContikiMAC only have a slight higher delay than XMAC and NullRDC is still having the lowest delay but the other ones are also respectable low.

(45)

40

Figure 65: Star topology, TX/RX: 100% Delay comparison with varying send intervals.

By comparing Figure 66 and Figure 67 a peculiar change can be seen, the delay of CMSA-ContikiMAC actually decreases when the link quality is degraded. NullMAC-CMSA-ContikiMAC is unaffected but at the same time XMAC suffers an increase in delay when the link is degraded. NullRDC is not affected by the link quality when it comes to delay.

Figure 66: Star topology, TX/RX: 100% Delay comparison with the send interval 1 second.

0 20 40 60 80 100 120 140 160 A ver ag e D ela y (ms )

Send interval (ms)

10 5 2 1 0,5 0 20 40 60 80 100 120 140 160 A ver ag e D ela y (ms )

(46)

41

Figure 67: Star topology, TX/RX: 75% Delay comparison with the send interval 1 second.

Both ContikiMAC and XMAC is able to deliver about 100% delivery rate with the varying send intervals as can be seen in Figure 68. NullRDC is the one having trouble in this topology with a low delivery rate when the send interval is 10 seconds. This is due to the hidden node problem and the resulting collisions.

Figure 68: Star topology, TX/RX: 100% Delivery rate comparison with varying send intervals.

When the send interval is one second all the protocols is able to deliver almost a 100% delivery rate. When the link quality is lowered both XMAC and NullRDC is lowered to around 60% delivery rate, this can be seen in Figure 69. ContikiMAC is able to remain at a 100% delivery rate due to it being able to send retransmissions.

0 20 40 60 80 100 120 A ver ag e D ela y (ms) 0% 20% 40% 60% 80% 100% D eliv er y Ra te

(47)

42

Figure 69: Star topology, TX/RX: 75% Delivery rate comparison with the send interval 1 second.

5.6.3 Overhead

In Figure 70 it can be seen that ContikiMAC ratio of overhead decrease with the data interval getting shorter and that XMAC is also decreases but at a much slower rate. This indicates that XMAC generates more overhead for each data packet being sent. This makes it so that if a lot of data is going to traverse the network a good deal of it will be overhead if XMAC is used. NullRDC is having the same amount of overhead packets regardless of the amount of data being sent.

Figure 70: Star topology, TX/RX: 100% Overhead ratio comparison with varying send intervals.

The ratio of overhead for both XMAC and NullRDC remains largely unchanged with a lower quality link as can be seen in Figure 71 and Figure 72. ContikiMAC overhead ratio decreases as its retransmissions increases the amount of data being sent but does not generate as much overhead. 0% 20% 40% 60% 80% 100% D eliv er y Ra te 0% 20% 40% 60% 80% 100% Ov er h ea d

(48)

43

Figure 71: Star topology, TX/RX: 100% Overhead ratio comparison with the send interval 1 second.

Figure 72: Star topology, TX/RX: 75% Overhead ratio comparison with the send interval 1 second.

6. Related works

In [8], a comparison of different RDC drivers in Cooja has been shown, focusing on the performance of WPI-MAC driver compared with the ContikiMAC. The results in this work revealed that ContikiMAC outperforms WPI-MAC in all scenarios. However, WPI-MAC outperform XMAC in terms of delay. This Thesis concluded that ContikiMAC has the best performance compared with other existing MAC protocols in Contiki. It was also stated that more tests need to be run on larger networks where the drivers may show their strengths. In [20] they were evaluating the performance of routing protocols for use in sensor networks. Their approach to the simulations was similar to the ones in this Thesis, one major difference though was that they were using a simulator called Sensoria. This allowed them to run simulations on a larger scale with up to 80 nodes running simultaneously. Sensoria could be used in future tests to emulate larger networks when evaluating protocols, by having two different simulators you can also avoid unexpected results due to bugs in the software.

(49)

44

7. Conclusions

In this Thesis work, a comparison of some combinations of MAC/RDC drivers have been done to see the effectiveness of the resulting MAC protocol. The selected drivers were those that are available in one of the COTS operating systems for sensor networks (ContikiOS). It is important to note that, all conclusions in this work are derived based on the current MAC/RDC drivers, and the scenarios assumed for experiments. For instance, large scale network has been neglected, where some of the current MAC protocols may fail.

The results revealed that from the overall performance no single MAC protocols is suitable for all situations, and it is highly dependent on the scenario and application requirements. The amount of nodes, position of the nodes, amount of traffic and wireless environment greatly affect the performance of the drivers. Some MAC drivers are better handling specific problems like hidden node or congestion. NullRDC is a driver that performs well, but with the expense of consuming more power as the radio is supposed to be always on. This is an important issue as energy efficiency in many sensor network applications is one of the major requirements.

7.1 MAC driver selection

In case of delivery rate the MAC driver that should be used is clearly CSMA if there are several nodes and that there is going to be a decent amount of traffic going over the network. That is because CSMA avoids collisions which otherwise would have dropped the delivery rate. If delay is of the most importance the MAC driver, then NullMAC can be used as it does not add any delay. This will in turn increase collisions which in turn might increase delay, but if the link quality is good and there is a low chance of collisions then NullMAC will be a bit faster than CSMA.

So the MAC driver that should be most often be used should be CSMA, but if the networks permits it NullMAC can be used to lower the delay slightly.

7.2 RDC driver selection

Where delivery rate is concerned ContikiMAC is the clear winner, it has an almost flawless record of providing around 100% delivery rate in all the simulations. NullRDC seems to have a good delivery rate in most of the simulations but it greatly decreases which each hop, the only time NullRDC really provides a good delivery rate is if the link is completely free of collisions and interference. This of course is not realistic with real world networks as there will always be some degree of interference, thus should not NullRDC be used if delivery rate is of importance. XMAC does not provide any good delivery rate as it does not do any retransmissions in contrast to ContikiMAC.

In case of delay NullRDC is the clear winner but as mentioned above should not really be used. When choosing between ContikiMAC or XMAC several considerations need to be taken. If the server is several hops away from the client then NullMAC-ContikiMAC and NullMAC-XMAC are both about the same in delay, be careful about using CSMA in these cases as the delay may increase many times over. In most cases XMAC is having a lower delay than ContikiMAC. If the amount of overhead packets need to be low, then ContikiMAC should be used. NullRDC is the lowest by far due to its simplicity but as stated previously should not be used in a network where nodes need to run on battery power. ContikiMAC have the advantage of not increasing

(50)

45 the amount of overhead by much when it need to do its retransmissions or when there is much traffic being generated. XMAC falls short here as its overhead stays at about the same ratio regardless of how much traffic is being sent. This can be a real problem as its ratio of overhead also is really high.

The RDC driver working the best in these simulations have been ContikiMAC. XMAC might be able to deliver a slightly lower delay but the greatly improved delivery rate and lower overhead ContikiMAC offers make it the preferred driver in most cases.

7.3 Future work

For future work the protocols should be tested in larger networks over a longer period of time to get more accurate data. A larger scale network is more realistic than having a sensor network with only few nodes. The protocols can also be tested for different applications, and not only for sending UDP packets from one point to another, employing several sinks to receive the data or all nodes sending to each other. Some more testing regarding the drivers power consumption may be needed as in this work it was not able to be measured. Other MAC protocols in addition to ContikiMAC and XMAC RDC drivers also need to be properly tested. For instance, LPP (Low Power Probing) is one of the existing MAC protocols that can be evaluated further.

Performance Evaluation of MAC protocols in Wireless Sensor Networks