MAC Protocols for Wireless Sensor Networks and Their Evaluation

MAC Protocols for Wireless Sensor Networks and Their Evaluation

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan de Technische Universiteit Delft, op gezag van de Rector Magnificus prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties, in het openbaar te verdedigen op woensdag 14 oktober 2009 om 12:30 uur door

Gertjan Pieter HALKES

ingenieur in de technische informatica geboren te Arnhem.

Dit proefschrift is goedgekeurd door de promotor: Prof. dr. K.G. Langendoen

Samenstelling promotiecommissie: Rector Magnificus Prof. dr. K.G. Langendoen Prof. dr. ir. I.G.M.M. Niemegeers Prof. dr. ir. H.J. Sips Prof. dr. ing. P.J.M. Havinga Prof. dr. K.U. Römer Prof. dr. ir. M. van Steen Ing. F. van der Wateren Prof. dr. ir. A.J.C. van Gemund

voorzitter Technische Universiteit Delft, promotor Technische Universiteit Delft Technische Universiteit Delft Universiteit Twente, Enschede Universität zu Lübeck, Germany Vrije Universiteit, Amsterdam Chess, Haarlem Technische Universiteit Delft, reservelid

This work was supported by the Dutch Ministry of Economic Affairs, under grant BSIK-03060 (Smart Surroundings). This work was carried out in the ASCI graduate school. ASCI dissertation series number 183. Advanced School for Computing and Imaging

Cover design by Sebastiaan Spijker, Beyond the Digit. Printed in The Netherlands by Wöhrmann Print Service. Published and distributed by: G.P. Halkes E-mail: [email protected] ISBN: 978-90-9024484-6 Copyright © 2009 G.P. Halkes All rights reserved. No part of the material protected by this copyright notice may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage and retrieval system, without the prior permission of the author.

Preface A mountain stage in a bicycle race is not an easy ride. The road is long, and there are many high peaks, deep valleys and steep inclines. Such a ride is not something you can easily accomplish on your own. To complete the stage successfully, the directions and encouragement of the team leader are essential. And when after rounding a blind corner the top of the hill turns out to be a lot further than expected, the cheers of loyal fans are also invaluable. Of course, the role of the team mates should also not be underestimated. Their work reduces the required effort as well. The peloton, and the friends and family watching and sympathising from home also all make the ride lighter. And even though in the end it is the rider who has to complete the stage, it would not be possible to reach the finish line without the help and support from all these people. That is why I would like to express my gratitude here to all the people who have made it possible for me to reach this finish line. First of all I would like to thank my team leader Koen Langendoen, and my most loyal fans Els Daniëls and Peter Halkes. My team mates Otto Visser, Tom Parker and Ivaylo Haratcharev, and the peloton, among many others Renze Steenhuisen, Jan-David Mol and Peterpaul Klein Haneveld, have all made the ride significantly lighter. Lastly, I would like to thank all those who have watched my efforts and have sympathised, even though I have not always been able to value their genuine interest. Delft, August 2009

Gertjan Halkes

i

Contents Preface 1

2

3

i

Introduction 1.1 Applications . . . . . . . . . . . 1.2 Practical Considerations . . . . 1.3 MAC Protocols . . . . . . . . . 1.3.1 Operational Context . . 1.4 Problem Statement . . . . . . . 1.5 Contributions and Thesis Outline

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

1 2 3 5 6 7 9

Comparing Energy-Saving MAC Protocols 2.1 Related Work . . . . . . . . . . . . . . 2.2 Energy-Saving Protocols . . . . . . . . 2.3 Simulation Framework . . . . . . . . . 2.3.1 Overview . . . . . . . . . . . . 2.4 Experiments . . . . . . . . . . . . . . . 2.4.1 Event-Based Unicast . . . . . . 2.4.2 Convergecast . . . . . . . . . . 2.4.3 Full Scenario . . . . . . . . . . 2.5 Discussion . . . . . . . . . . . . . . . . 2.6 Conclusions . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

11 11 12 14 14 17 17 20 21 23 25

The Crankshaft Protocol 3.1 Related Work . . . . . . . 3.2 Crankshaft . . . . . . . . . 3.3 Simulation Setup . . . . . 3.4 Simulation Results . . . . 3.4.1 Convergecast . . . 3.4.2 Broadcast Flood . 3.4.3 Crankshaft Latency 3.5 TinyOS Implementation .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

27 28 29 32 32 33 35 37 39

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . iii

. . . . . .

. . . . . . . .

. . . . . . . .

iv

CONTENTS

3.6 3.7 4

5

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.6.1 Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 42

The λMAC framework 4.1 Rethinking MAC Protocols . . . . . . . . . . . 4.1.1 Existing Concepts . . . . . . . . . . . 4.1.2 Role Separation . . . . . . . . . . . . . 4.1.3 Design Conclusions . . . . . . . . . . 4.1.4 λ Interfaces . . . . . . . . . . . . . . . 4.1.5 Network Time . . . . . . . . . . . . . 4.2 Transmission Layer Modules . . . . . . . . . . 4.2.1 Notes on Transmission Module Design 4.2.2 Broadcast . . . . . . . . . . . . . . . . 4.2.3 Unicast . . . . . . . . . . . . . . . . . 4.3 Integrating Existing MAC Types . . . . . . . . 4.3.1 λB-MAC . . . . . . . . . . . . . . . . 4.3.2 λT-MAC . . . . . . . . . . . . . . . . 4.3.3 λLMAC . . . . . . . . . . . . . . . . . 4.3.4 λCrankshaft . . . . . . . . . . . . . . . 4.4 Testing . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Testbed Results . . . . . . . . . . . . . 4.4.2 Power Test . . . . . . . . . . . . . . . 4.4.3 Code Size . . . . . . . . . . . . . . . . 4.4.4 CPU-Cycle Overhead . . . . . . . . . . 4.4.5 λB-MAC Micro Benchmarks . . . . . . 4.5 Further Transmission Modules . . . . . . . . . 4.5.1 ExOR . . . . . . . . . . . . . . . . . . 4.5.2 Priority Queueing . . . . . . . . . . . . 4.6 Related Work . . . . . . . . . . . . . . . . . . 4.7 Conclusions . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43 44 44 44 46 47 49 51 51 52 52 53 54 54 55 56 56 57 61 61 64 65 65 66 66 67 68

The PowerBench Testbed 5.1 Related Work . . . . . . . . . . . . . . . 5.2 Testbed Design . . . . . . . . . . . . . . 5.3 Implementation Details . . . . . . . . . . 5.3.1 Runner Software . . . . . . . . . 5.3.2 Sampling Software . . . . . . . . 5.3.3 Trace Processing Software . . . . 5.4 Results . . . . . . . . . . . . . . . . . . . 5.4.1 PowerBench Validation . . . . . . 5.4.2 Estimation Versus Measurements 5.4.3 Trace Visualisation . . . . . . . . 5.5 Conclusions . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

69 70 71 73 73 74 74 74 75 75 78 80

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

v

CONTENTS

6

7

Evaluation of MAC Simulation Abstractions 6.1 Related Work . . . . . . . . . . . . . . . 6.2 Experiment Setup . . . . . . . . . . . . . 6.2.1 Traffic Pattern and Metrics . . . . 6.2.2 Abstractions . . . . . . . . . . . 6.3 Results . . . . . . . . . . . . . . . . . . . 6.3.1 Convergecast . . . . . . . . . . . 6.3.2 Broadcast Flood . . . . . . . . . 6.4 Modelling Differences . . . . . . . . . . 6.5 Conclusions . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

83 84 85 86 87 88 88 96 96 98

Conclusions 99 7.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Bibliography

103

Summary

111

Samenvatting

113

Curriculum Vitae

115

1

Introduction

Measurements of physical phenomena are the cornerstone of the natural and applied sciences, and engineering. Starting with crude length, weight and time measurements in pre-historic times, over time the measurements have been refined. Nowadays a plethora of accurate measurements is possible, ranging from everyday quantities such as length and temperature to electro-magnetic field strengths and advanced particle detectors. Up to a few decades ago all measurements where carried out with analog instruments. With the advent of the computer it became possible to quickly and easily obtain statistics on the measured events. However, with analog instruments all measurements had to be entered into the computer by hand before processing could take place. This is a time consuming and error prone endeavour. The development of digital sensors that could be directly read out by computers was therefore a logical next step. Initially digital sensors were bulky devices connected to heavy stationary computers. But with the development of advanced micro electronics it is now possible to make digital sensors smaller than a cubic millimetre. The price of the digital sensors has also become so low that it is now feasible to not only measure a quantity at a single point, but at many points simultaneously. If one were to connect many sensors spread out over a large area to a computer using wires, the total length of these wires would be impractical. In for example modern cruise ships, where the number of sensors (and actuators) is relatively limited, the length of all the wires running through the ship is several thousand kilometres! Obviously, when the number of sensors increases, using wires to connect all these sensors will be prohibitive. The solution is to use wireless sensors. A wireless sensor is built out of several components. First of all the sensor. Then, as the sensor has to operate wirelessly, a power source such as a battery is required. Furthermore, a wireless communication device, or radio, needs to be in place. Finally, to coordinate the operation of both the sensor and the radio, and to preprocess the sensed values, a small microcontroller is needed. The combination of these components is called a wireless sensor node. When a group of these nodes form a wireless network, the collection of nodes is called a Wireless Sensor Network (WSN). Ideally, wireless sensor nodes should be very small, such that deployment is not hampered by the nodes’ size. The current generation of wireless sensor nodes (see Figure 1.1) is still 1

2

INTRODUCTION

Figure 1.1: A Tnode wireless sensor node.

quite bulky compared to the “smart dust” with nodes a few cubic millimetres large [Kah99] that wireless sensor nodes are envisioned to be in the (near) future. Partly the large size is due to practical considerations such as making connections with other devices and extensions possible, partly the technology still needs to be developed further. However, the current form factor is already small enough to be deployed relatively unobtrusively.

1.1

Applications

Wireless sensor networks are already being used in academic pilot projects and commercial projects alike. In this section we list several examples of such projects to give an idea of the wide array of applications made possible by wireless sensor networks. Wild-life monitoring The Great Duck Island study [Mai02] studied the Storm Petrel colony at Great Duck Island of the coast of Maine. The Life Sciences researchers were interested in the usage patterns of nesting burrows, to study the behaviour of the birds without any interfering human activity. To detect the birds in the burrows, the wireless sensor nodes were equipped with temperature, light, air pressure, humidity and infrared sensors. Crop monitoring In the LOFAR_Agro [Goe05; Lan06] project, a wireless sensor network was deployed in a potato field. The goal of the project was to perform fine-grained measurements of the temperature and relative humidity to be able to find parts of the field where the conditions were favourable for the potato disease phytophthora. Using this knowledge, the amount of pesticides can be reduced by spraying only those areas where the disease has any chance of spreading, rather than spraying the whole field indiscriminately. Asset tracking Keeping track of large numbers of containers or goods within a storage facility is not an easy task. Misplacing a container between thousands of similar looking containers can result in lost productivity due to the effort required to find it. With the use of wireless sensor networks the tracking of such containers can be done without

1.2

PRACTICAL CONSIDERATIONS

3

relying on manual administration, making the tracking much more reliable. As an added benefit, it is also possible to monitor the contents of the containers. This is especially useful for containers for perishable goods, which need to be stored under specific conditions. Using wireless sensor networks, an alarm can be raised when conditions exceed the acceptable parameters. In this case, the radio is used as a sensor, as radio connectivity is an indication of proximity and can be used to derive the location of the wireless sensor node. Car park management Finding an empty spot in an almost fully filled car park can be a frustrating experience. Products are currently being developed whereby each parking space is equipped with an occupancy sensor to allow smart signs to direct the visitor to the nearest free parking space. These sensors also allow finding cars that are staying longer than the car park management allows, or otherwise use the car park inappropriately. Art monitoring The theft of works of art from museums is a serious problem. By attaching a vibration sensor to the works of art, it is possible to detect moving of the pieces. After any movement is detected, guards can be dispatched to intercept the thief. For permanent exhibitions this can conceivably be done with wired sensors, but for changing exhibitions a wireless solution is often the only option. The above examples are just a small selection of the many applications that are made possible by wireless sensor networks. The examples give a good flavour of what possibilities lay open with fine-grained measurements at one’s disposal.

1.2

Practical Considerations

To realise the fine-grained measurements that wireless sensor networks promise, several challenges have to be faced. One such challenge is that individual wireless sensor nodes need to be cheap. This means that the components of a wireless sensor node are necessarily simple. For example, the microcontroller on a wireless sensor node has only 4 KB of RAM at its disposal. This is a tiny amount compared to current desktop computers that now frequently have 4 GB of RAM; 6 orders of magnitude more. The limited capabilities of the components are not only dictated by the price constraints on wireless sensor nodes. These networks are also expected to operate without intervention for extended periods of time. For example, in the wild-life monitoring study on Great Duck Island the researchers want to study how the Storm Petrels behave when no humans are around to disturb them. This necessarily means that the wireless sensor network installed there has to operate for several months without any physical human intervention. Running unattended for months or even years means that wireless sensor nodes have to consume their energy sparingly. Simply running all the components at full capacity all the time will deplete the battery within days. Of course bigger batteries or even solar cells could be used, but that would both make the nodes themselves larger and more cumbersome and it makes the nodes more expensive. As both these characteristics are undesirable for wireless

4

INTRODUCTION

distance = 1

distance = 0

(a)

(b)

(c)

Figure 1.2: Setting up multi-hop network routes. First, the sink notifies its neighbours of its

presence (a). The sink’s neighbours then know how to reach the sink, as indicated with the dashed lines (b), and notify their neighbours about the sink’s presence and distance. Finally, all nodes know which neighbouring node can forward messages to the sink (c).

sensor networks, the only option is to use energy-efficient components that can be switched off when their functionality is not required. One simple way of achieving energy efficiency is limiting the provided functionality. For example, one can use a simple microcontroller that provides computing power similar to that available to early desktop computers instead of current high-performance desktop computer processors. The simple microcontroller can run on a few milli-ampères of current, while the desktop processor consumes several tens of ampères when running at full speed. Another example of limited functionality imposed by the energy-efficiency constraints is the limited range of the radio used on wireless sensor nodes. The energy consumption of the radio scales quadratically1 with the distance. Therefore, to communicate over twice the distance requires four times the amount of energy, which limits the radio range that can be achieved with a limited energy budget. Typical radio ranges for wireless sensor nodes are in the range of 25 – 100 metres, depending on the environment. When nodes are deployed in a large area, such as a potato field, not all nodes can communicate with each other. More importantly, nodes may not be able to reach the computer that is gathering all the measurements, which is known as the sink (also known as base station or gateway). The solution is to let nodes forward messages for one another. When a node A can reach the sink, it can forward messages from other nodes. A node B that can reach node A, but that cannot reach the sink directly can send its message to node A such that node A can forward it to the sink. Of course this process can be repeated such that messages may be forwarded by several nodes in the network before reaching the sink. A network using such an organisation is called a multi-hop network. A second challenge we discuss here is the desire to let the whole network function without a central authority orchestrating everything. A wireless sensor network should operate like an ant colony: all the ants in the colony do a small amount of work according to simple rules, 1 This is a simplification. For radio propagation in free space the energy required scales quadratically. In everyday environments, typical path-loss exponents lie between 1.5 and 6.

1.3

MAC PROTOCOLS

5

but the whole of the colony exhibits complex behaviour. This kind of distributed operation makes the colony resilient to losing ants. As a simple example of distributed operation is the establishing of forwarding relationships (routes) in a multi-hop network. One simple way to set up a multi-hop network is to let each node in the network periodically notify its neighbours how many forwarding steps (or hops) it is separated from the sink (see Figure 1.2). Of course the sink will announce it is 0 hops away (1.2a). If a node in the network has no idea how to reach the sink, it will remain silent. However, once it receives a notification from another node in the network, it will know that is one hop further away from the sink than the neighbour it received the notification from. From that moment on it can inform its own neighbours about its separation from the sink (1.2b). Using these simple rules, the whole network can establish routes without any central authority (1.2c).

1.3

MAC Protocols

As we have seen in the previous section, many challenges arise from the constraints that are put on wireless sensor networks. However, wireless sensor networks by their nature have to communicate, so these challenges must be faced within that context. Therefore the radio, as the node’s communication device, has to be carefully managed to allow effective and efficient communication. To communicate effectively and efficiently using the radio, a set of rules is required. These rules determine which node may send at which time. To illustrate the problems and the kind of rules required, consider a walkie-talkie. A walkie-talkie is a hand-held radio communication device, with a half-duplex radio. That is, the radio can send or receive, but not both at the same time. The radio used in a wireless sensor node is exactly the same in that sense. A major problem when using walkie-talkies is that when two people press the send button to say something to the other person at the same time, neither will hear what the other is saying. People use a very simple rule to prevent this situation from occurring: before pressing the send button, they listen to the walkie-talkie for a short time to hear if the other person is currently sending. If they can hear the other person saying something, they defer their own message until the other has finished speaking. A related problem is when there are three (or more) people using walkie-talkies in the same area. When two people try to simultaneously send to a third person, the third person will be able to hear that the others are sending, but not what they are sending. This situation is called a collision. Collisions can even occur when people obey the rule sketched above, because the two people who try to send may not be within each other’s range, and therefore cannot hear each other. This is called the hidden-terminal problem (see Figure 1.3). The third problem is that of energy efficiency. Consider again the example of the walkietalkies. If the walkie-talkies are left on day and night, the battery will soon go flat. The result is that when the walkie-talkies are necessary to communicate some important piece of information, they are not available. The obvious solution is to turn off the walkie-talkie when

6

INTRODUCTION

A

B

C

Figure 1.3: The hidden-terminal problem. Radios A and C can not detect each other’s trans-

missions, but radio B can hear both. When A and C send at the same time, B hears only noise.

it is known in advance that the users will not want to communicate, for example when the users are sleeping. The collection of rules that governs when which node can communicate is collectively known as a Medium Access Control (MAC) protocol. The MAC protocol is responsible for effective and efficient communication. To accomplish these sometimes conflicting responsibilities, many techniques can be used. For example, Collision Avoidance (CA), time synchronisation, and Low Power Listening (LPL) to name just a few (see Chapter 2). Of course, an important factor in the energy consumption is the number of messages that a node sends or has to receive. Although the management of the radio must be tuned to the expected network communications, it is not the responsibility of the MAC protocol to limit the traffic. Most messages sent by a node are generated by components such as the routing layer and the application. However, the study of how to limit the number of messages sent by the routing protocol and the application has already filled many theses and is outside the scope of this thesis.

1.3.1

Operational Context

MAC protocols for wireless sensor networks have to work with several distinct characteristics that set wireless sensor networks apart from other wireless networks such as traditional Wireless LANs (WLAN, also known as Wi-Fi) and Mobile Ad-hoc Networks (MANETs). We identify the following key characteristics that influence the design of MAC protocols for wireless sensor networks: Limited resources: compared to other wireless networks, wireless sensor networks have to operate on an extremely resource-limited platform. For MAC protocols the limited capabilities of the radio and the limited energy budget are especially important. Quiet networks: wireless sensor networks are mostly used for monitoring and to detect anomalous events. For both these applications the amount of useful information is typically low. That means that the network typically has very few messages to transport to the sink. On the one hand this is a drawback because it leaves fewer opportunities to

1.4

PROBLEM STATEMENT

7

hide or spread overhead. On the other hand this characteristic can be exploited to save energy. Traffic patterns: the traffic patterns in wireless sensor networks differ from typical wireless network applications. The most important traffic pattern is convergecast. The convergecast pattern is the pattern where nodes in the network send data to the sink. Because the sink is the place where interaction with the user or operator of the network takes place, any event of interest to the wireless sensor network user has to be reported at the sink. The second common traffic pattern is the broadcast flood pattern, which is used to disseminate data from the sink to the nodes in the network. In a sense it is the opposite of the convergecast pattern. A broadcast flood is a simple mechanism whereby the sink starts by sending a broadcast message. Each node which receives the broadcast message subsequently repeats it (ignoring messages it already received from other nodes), such that all nodes in the network eventually receive and repeat the message once. A final traffic pattern which can be used in wireless sensor networks is the local unicast pattern. In local unicast a node communicates with its neighbouring nodes, for example to verify that a measured anomaly is not caused by a malfunctioning sensor. Optimisation criteria: where in typical wireless network scenarios metrics such as throughput, message latency and fairness are the main optimisation criteria, in wireless sensor networks these are far less important. For example, in most wireless sensor network applications it makes little difference whether a message arrives after 0.1 seconds or 0.4 seconds, while in MANETs such latency differences are an important factor. The main optimisation criterion for wireless sensor networks is energy-efficiency, which in the case of MAC protocols translates to time that the radio is sleeping. To complicate matters further, the use of the wireless medium also brings with it another challenge. We like to think about communication channels as “connections”, that is some sort of stable link to communicate over. However, the wireless channel is far from stable. Conditions change over time, sometimes rapidly, which results in intermittent connectivity. Being able to communicate one moment provides no guarantee about the ability to communicate in the future. When designing MAC protocols these characteristics of the wireless medium must also be taken into account.

1.4

Problem Statement

Because energy is such a limited resource in wireless sensor networks, the primary concern in wireless sensor network MAC protocols is energy efficiency. To design a MAC protocol that is as energy efficient as possible, one first has to identify the sources of wasteful energy consumption in wireless MAC protocols. Ye et. al. [Ye02] identify the following sources: Idle listening: a node generally cannot predict when another node wants to communicate with it. Therefore, a node has to be ready to receive a message from any of its neighbours at any time. But when none of a node’s neighbours has anything to send, the node

8

INTRODUCTION

will have its radio turned on in receive mode for nothing. If a node were to know that for the next second no neighbours will want to communicate with it, it can then turn off its radio and save energy. As the number of messages in a wireless sensor network is generally low, idle listening is a major source of wasteful energy consumption. Collisions: when two nodes try to send a message to the same node at the same time, there is a good chance that neither message will be received by the intended recipient. This means that energy will have been spent on sending and receiving messages without any useful result. Furthermore, a lack of response from the intended recipient will trigger a second attempt from both sending nodes to try to finish the communication successfully. Overhearing: the wireless medium is by its nature a broadcast channel. This means that when one node sends a message, all nodes in its vicinity will receive the message, even when the message is of interest to only a single node. If the nodes that have no interest in a message could know that in advance, they could power off their radio and save energy. Control packet overhead: MAC protocols usually send short messages for signalling purposes. For example, after a message has been successfully received, many MAC protocols send a short acknowledgement back to the sender. Although these packets are useful for robustness, sending them does consume energy without conveying useful information at the application level and must therefore be considered overhead. These observations lead to the following high-level problem statement: How can we design and implement a MAC protocol that reduces the wasteful energy consumption as much as possible, within the constraints posed by the typical deployment scenarios for wireless sensor networks? Note that the constraints not simply limit what is possible, but also allow optimisations that are not possible in similar fields of research such as MANETs. Of course we are not the first to study MAC protocols for wireless sensor networks. Based on the classification in [Lan08] we now present the basic techniques used in MAC protocols for wireless sensor networks, leaving a detailed overview of the relevant related work for the different chapters. The first major group of protocols is the group of random access protocols. In these protocols nodes can communicate at any time. To save energy, either a hardware solution such as a wake-up radio is used, or a technique called Low-Power Listening (LPL). The wakeup radio technique employs two radios: one energy-hungry radio for communication, and a energy-efficient radio only used for signalling the intention to send. When no communication is taking place only the energy-efficient wake-up radio will be set to receive mode, while the energy-hungry radio is turned off. The LPL technique uses periodic sampling of the radio medium to determine whether another node is currently sending. Between two samples the radio will be turned off. To ensure proper reception of messages, each message will be prepended with a busy tone at least the length of one sample period. The second group of protocols are the so-called slotted access protocols. Slotted access protocols use a sleep/active pattern to save energy. By ensuring, through time synchronisa-

1.5

CONTRIBUTIONS AND THESIS OUTLINE

9

tion, that all nodes turn on their radio at the same time, all communication can be performed in a short burst, after which nodes turn off their radio again. The third group is formed by the frame-based access protocols. These protocols define a strict schedule based on frames that in turn consist of a number of slots. The schedule determines which node may access the medium in which time slot. As a node that is allowed to send will be the only one to access the medium at that time, it can immediately start sending without fear of collisions. Because it is known beforehand which slots of the schedule require a node to send or receive, a node can turn its radio off during all the other slots. Furthermore, if a node has nothing to send, its neighbours will detect that the medium is clear at the start of the slot and will turn off their radios, thereby saving even more energy. The final group of protocols is the group of hybrid protocols. These protocols combine ideas from some or all of the above in an attempt to save even more energy, either through switching between modes of operation depending on the traffic situation or by offsetting the draw-backs of one approach by the strengths of another. The above techniques cover the needs of most general wireless sensor networks. However, as the need for more fine-grained measurements increases, the density of the deployed networks also increases. The techniques described above are not enough to handle the extra problems that the increased density gives rise to. In this thesis we therefore focus on dense wireless sensor networks when designing a MAC protocol. After addressing the design problem, we are immediately faced with a follow-up question: How can we evaluate to what extent we have succeeded in reducing wasteful energy consumption by the MAC protocol? The problem here is that measuring energy consumption in a deployed network is exceedingly difficult. Therefore other solutions need to be found. One example solution is using a testbed. In a testbed a group of nodes is deployed in a controlled environment and in such a way that communication over a wired connection is possible. Measuring energy consumption in a testbed is a lot easier than in deployed network. Another possible solution is to use simulation, in which a powerful desktop computer changes a world model according to the actions taken by simulated wireless sensor nodes. However, using simulation shifts the question to the fidelity of the obtained results.

1.5

Contributions and Thesis Outline

The problems described in the previous section, the design and evaluation of energy-efficient MAC protocols, cover a large research area. In this thesis we contribute to this field in the following ways: Evaluation of several de facto standard MAC protocols. In Chapter 2 we evaluate the performance in terms of energy consumption for several de facto standard wireless sensor network MAC protocols. We base our comparison on simulations of typical wireless sensor network traffic patterns, i.e. convergecast and local unicast. Furthermore we evaluate the use of channel polling as a generic technique for CSMA-based protocols. Our simulations show that the low-power listening technique and the T-MAC protocol are very effective at limiting energy consumption.

10

INTRODUCTION

A MAC protocol for dense wireless sensor networks. Dense wireless sensor networks, in which many nodes are deployed in close proximity of one another, provide new challenges for MAC protocols. In particular the problem of overhearing is much more severe. In Chapter 3 we present the Crankshaft protocol that addresses this problem. By taking into account the specific characteristics of dense networks, the Crankshaft protocol is able to significantly reduce energy consumption. Evaluation of a framework for developing MAC protocols. Many MAC protocols are composed of a small set of common concepts. Such concepts include, for example, sending an acknowledgement when a message has been successfully received. As the MAC protocol is generally perceived as a single block of code, very little code sharing occurs between MAC protocol implementations. This means the same concepts are implemented over and over again. In Chapter 4 we present a framework that allows better code reuse in MAC protocol development, and we show that it allows easy implementation of complex protocols with little overhead. Validation of a three-state radio power-consumption model. Testbeds are useful tools for the development of wireless sensor network protocols in general and MAC protocols in particular. However, most testbeds lack the ability to measure the energy consumption of the nodes, which is required to provide proper evaluation of the energy efficiency of MAC protocols. The PowerBench architecture, which we developed, does provide the required power measuring capability. In Chapter 5 we show, using our PowerBench testbed, that a three-state radio model can provide accurate estimates of the power consumption of a node. An experimental evaluation of simulation abstractions. Most evaluations of MAC protocols for wireless sensor networks are performed through simulations. The impact of the abstractions used in these simulations is largely unknown. In Chapter 6 we present an experimental evaluation of two common reception models used in simulations of wireless sensor networks, using the PowerBench testbed. We show that the Signal-to-Noise Ratio model with additive signals provides results close to the testbed experiments. Chapters 2, 3, 5 and 6 are based on published papers. Chapter 4 is based on a paper accepted for publication. All chapters have undergone some editorial changes to enhance the readability of the thesis as a whole. In Chapter 3 we have replaced the section on realworld results with the results of a more extensive experiment. In Chapter 5 we have removed sections with details that are irrelevant to the topic of this thesis. Chapter 6 is an extended version of the published paper. The thesis is concluded in Chapter 7, which also provides directions for future work.

Comparing Energy-Saving MAC Protocols

2

As our first step into the world of WSN MAC protocols, we evaluate the performance of several de facto standard MAC protocols for WSNs. Our simulations show that low-power listening and T-MAC are very effective at limiting energy consumption.

Applications for wireless sensor networks have notably different characteristics and requirements from standard WLAN applications. Low energy consumption is the most important consideration. The low message rate that is typical for sensor network applications and the relaxed latency requirements allow for significant reductions in energy consumption of the radio. An important technique in this respect is duty-cycling of the radio. By periodically turning the radio off, much energy can be saved. However, duty-cycling can be achieved in different ways and at different granularities. Each method of duty-cycling has its own tradeoff between energy consumption and other metrics such as latency and fairness, resulting in different proposals for MAC protocols. In this chapter we study the energy saved by two duty-cycling MAC protocols optimised for wireless sensor networks, S-MAC and T-MAC, in comparison to standard CSMA/CA. By providing a head-to-head comparison we show the strengths and weaknesses of the different protocols, rather than just showing that each protocol saves energy compared to CSMA/CA. At the time of writing S-MAC and T-MAC were the standard MAC protocols for wireless sensor networks, and other protocols such as TDMA protocols with distributed slot assignment had yet to prove themselves. We also report on the effects of low-power listening, a physical layer optimisation, in combination with these MAC protocols.

2.1

Related Work

The popular IEEE 802.11 standard for WLANs is a contention-based protocol that can be operated in ad-hoc mode [LAN99]. Its prime feature, borrowed from the MACAW proThis chapter is based on: “Comparing energy-saving MAC protocols for wireless sensor networks”, G. Halkes, T. van Dam, and K. Langendoen, Mobile Networks and Applications, vol. 10(5):pp. 783–791, October 2005.

11

12

COMPARING ENERGY-SAVING MAC PROTOCOLS

Sender

Preamble

Message

Receiver

Figure 2.1: Low-power listening: the sender uses a longer preamble to allow the receiver to

only turn its radio on periodically.

tocol [Bha94], is its in-band signalling (through RTS/CTS messages) to reduce collisions caused by so-called hidden nodes. Furthermore it includes a power-save mode in which individual nodes periodically listen and sleep. The 802.11 protocol, however, was designed with the presumption that all nodes are located in a single network cell. Adaptations for multi-hop networks have been proposed, but require more complexity and dynamic state than would generally be available in wireless sensor networks [Tse02]. The PAMAS protocol [Sin98] uses out-of-band signalling (on another radio channel) to reduce the overhearing overhead, while preserving throughput and latency. Whenever a node overhears signalling destined for another node it calculates the time until the associated data transfer finishes; this is straightforward since the length of the data transfer is included in the control packets on the signalling channel. The radio is then turned off, and will be switched on in due time when the ether becomes available again for other transfers. Energy-savings between 10 and 70 % are reported. The out-of-band signalling, however, is not really an option for low-cost sensor nodes since it requires a too complex radio.

2.2

Energy-Saving Protocols

Recently, a number of MAC protocols have been developed explicitly targeted at multi-hop ad-hoc sensor networks: low-power listening [Hil02], S-MAC [Ye02], and T-MAC [Dam03]. They all focus on reducing idle listening, but collisions, protocol overhead, and overhearing are also addressed. Low-power listening The first approach to reduce idle listening, by introducing a duty-cycle, operates at the physical layer. The basic idea of low-power listening is to shift the cost from the receiver (the frequent case) to the transmitter (the rarer case) by increasing the length of the preamble [Hil02]. This allows the receiver to periodically turn on the radio to sample for incoming data, and detect if a preamble is present or not. If it detects a preamble, it will continue listening until the start-symbol arrives and the message can be properly received (see Figure 2.1). If no preamble is detected the radio is turned-off again until the next sample. Low-Power Listening (LPL) was applied to CSMA in the TinyOS project with a sample time of 30 µs every 300 µs, a duty-cycle of 10 %, reducing the idle listening overhead by a factor of ten. The energy savings come at a slight increase in latency (the length of the preamble is doubled), and minor reduction in throughput. LPL can be applied to any MAC protocol (see Section 2.4) provided that switching the radio on/off takes little time.

2.2

ENERGY-SAVING PROTOCOLS

13

CSMA Active time

S−MAC

Sleep time

Active time

T−MAC

TA

Sleep time

TA

TA

Figure 2.2: The S-MAC and T-MAC duty cycles; the arrows indicate transmitted and received

messages; note that messages come closer together. (TA denotes the activity time-out period.)

S-MAC The second approach mitigating idle listening is the S-MAC protocol, a true MAC protocol, which also addresses the overheads caused by collisions, overhearing, and protocol overhead [Ye02]. The basic idea of this contention-based protocol is that time is divided into –relatively large– frames. Every frame has two parts: an active part and a sleeping part. During the sleeping part, a node turns off its radio to preserve energy. During the active part, it can communicate with its neighbours and send any messages queued during the sleeping part, as shown in Figure 2.2. Since all messages are packed into the active part, instead of being ‘spread out’ over the whole frame, the time between messages, and therefore the energy wasted on idle listening, is reduced. The exact savings are under control of the application: the active part is fixed1 to 300 ms, while the frame length can be set to any length. Consequently, also the increase in latency, and reduction in throughput, are under control of the application. S-MAC needs some synchronisation between nodes, but that is not as critical as in TDMAbased protocols: the time scale is much larger with typical frame times in the order of 300 ms to 1 second. S-MAC uses a technique called virtual clustering, in which nodes periodically send special SYNC messages to keep synchronised. These messages, transmitted at the start of a frame, also allow new (mobile) nodes to join the ad-hoc network. The S-MAC protocol uses the RTS/CTS/DATA/ACK signalling scheme from 802.11 to reduce the number of collisions caused by the hidden-node problem. It borrows the overhearing avoidance technique from the PAMAS protocol, but uses in-band signalling (i.e., overhearing RTS/CTS packets) since the target platform (i.e., Berkeley motes [Ber]) has only a single-frequency radio, as is the case for most other prototype sensor nodes. Finally, S-MAC includes message passing support to reduce protocol overhead when streaming a sequence of message fragments. T-MAC The third energy-saving protocol for sensor networks considered here is the T-MAC protocol [Dam03], which automatically adapts the duty cycle to the network traffic. 1 A later enhancement of S-MAC, which is called adaptive listening, includes a variable length active part to reduce multi-hop latency [Ye04]. Since the time-out policy of the T-MAC protocol behaves similarly and was designed to handle traffic fluctuations as well, we do not discuss adaptive listening further.

14

COMPARING ENERGY-SAVING MAC PROTOCOLS

As with S-MAC, nodes form a virtual cluster to synchronise themselves on the beginning of a frame. But instead of using a fixed-length active period, T-MAC uses a time-out mechanism to dynamically determine the end of the active period. The time-out value, TA, is set to span a small contention period and an RTS/CTS exchange. If a node does not detect any activity (an incoming message or a collision) within interval TA it can safely assume that no neighbour wants to communicate with it and goes to sleep. On the other hand, if the node engages or overhears a communication, it simply starts a new time-out after that communication finishes (see Figure 2.2). The adaptive duty-cycle allows T-MAC to adjust to fluctuations in network traffic, both in time (physical events trigger neighbour-to-neighbour communication) and in space (nodes close to the sink relay more traffic than edge nodes). S-MAC, on the other hand, operates with a single active-time for all nodes, which must be chosen conservatively to handle worst-case traffic. The down-side of T-MAC’s aggressive power-down policy, however, is that nodes often go to sleep too early: when a node s wants to send a message to r, but loses contention to a third node n that is not a common neighbour, s must remain silent and r goes to sleep. After n’s transmission finishes, s will send out an RTS to sleeping r and receive no matching CTS, hence, s must wait until the next frame to try again. T-MAC includes two measures to alleviate this so-called early-sleeping problem, but nevertheless favours energy-savings over latency/throughput much more strongly than S-MAC and LPL (see the simulation results in Section 2.4).

2.3

Simulation Framework

In a previous study [Dam03] we already reported on how the behaviour of S-MAC and T-MAC compares under communication patterns specific to sensor networks. In this chapter we extend that work by also studying low-power listening in combination with CSMA (as part of TinyOS) and with S-MAC and T-MAC (novel combinations). This section describes our simulation framework, and provides details about the specific settings of the parameters for each protocol.

2.3.1

Overview

The simulator is constructed using the OMNeT++ discrete event simulation package [Var01], in which we have built a realistic model of the EYES prototype wireless sensor nodes [Eye] in use at our research laboratory. The EYES nodes consist of a 16-bit embedded processor (Texas Instruments MSP430F149), a low-power radio (RFM TR1001, 868.35 MHz, hybrid transceiver), a 2 Mbit EEPROM memory, and various connectors to interface to the outside world. A node runs from 3 V supplied by two AA batteries taking up most of the node’s volume. Table 2.1 provides a current breakdown of the processor and radio for active and sleep modes according to the component specifications [RFM; TI]. The OMNeT++ model has the same limits on clock resolution and precision (32 KHz crystal), radio turn-around and wake-up times (43 µs and 10 µs respectively), and transmission bit rates (115 kbps) as the EYES nodes have. Energy consumption in the model is based on

2.3

SIMULATION FRAMEWORK

Component

State

Current

CPU (5 MHz)

Active Sleep Transmit Receive Sleep

2.1 mA 1.6 µA 10 mA 4 mA 20 µA

Radio (115 kbps)

15

Table 2.1: Current breakdown of EYES nodes.

the amount of energy the radio uses; we do not take protocol processing costs on the CPU into account. Preliminary current measurements of the EYES nodes have shown that the numbers in Table 2.1 are quite realistic, except for the transmit current that was measured with a peak of 18 mA. Since it is not clear what is causing this discrepancy, we use the specified current numbers in Table 2.1 in our simulations. In our experiments we have used a static network with a 10×10 grid topology. We have chosen a radio range so that non-edge nodes all have 8 neighbours. Concurrent transmissions are modelled to cause collisions if the radio ranges (circles) of the senders intersect; nodes in the intersection will receive a garbled packet with a failing CRC check. The application is modelled by a traffic generator at every node. The generator is parametrised to send messages either to direct neighbours (i.e., nodes within the radio range of the sender), or to the sink node, which is located in the left bottom corner of the grid. To route the latter messages to the sink we use a randomised shortest path routing method; for each message, the possible next hops are enumerated. Next hops are eligible if they have a shorter path to the final destination than the sending node. From these next hops, a random one is chosen. Thus messages flow in the correct direction, but do not use the same path every time. No control messages are exchanged for this routing scheme: nodes automagically determine the next hop. By varying the message length and inter arrival times we can study how the protocols perform under different loads. The implementation details of the four energy-saving protocols under study are discussed below. Table 2.2 provides a brief summary, listing the most important radio and protocol parameters.

LPL In the simulator we have chosen to implement Low Power Listening with the same parameters as on the TinyOS/Mica1 platform. This means we have used a 10 % duty-cycle with an on period of 30 µs and an off period of 270 µs. LPL is implemented as a thin layer between the MAC and physical layer such that we can easily control whether or not LPL should be applied and in combination with which MAC protocol. Whenever the MAC layer turns the radio to receive mode, LPL will transparently poll the physical layer with the 30 µs sample time. This short probe is possible with our radio which can be activated in about 10 µs. When the MAC switches to send mode the physical layer is instructed to stretch the preamble by 300 µs effectively doubling the preamble time (347 vs. 647 µs). Hence, the penalty for

16

COMPARING ENERGY-SAVING MAC PROTOCOLS

Category

Parameter

Value

General

Radio bit rate Channel coding Control packets DATA packets SYNC packets Queue length Frame time Activity time-out Contend time Frame time Active period Contend time

115 kbps 8-to-12 bit coding 8 bytes 6 – 256 bytes 10 bytes 10 610 ms 15 ms 9.15 ms 1s 61 – 915 ms 3.05 – 9.15 ms

T-MAC

S-MAC

Table 2.2: Implementation details of the simulator.

sending under LPL is acceptable given that even a very short control message like an RTS takes 1.4 ms to transmit without the use of LPL and 1.7 ms with LPL.

CSMA/CA The basic CSMA/CA (802.11) protocol was implemented using an 8 byte header encoding all information needed in the control messages, that is, the RTS/CTS/DATA/ ACK messages. The payload of the DATA message can be up to 250 bytes (the routing information is part of the DATA header). Furthermore we implemented overhearing avoidance. Reliability is implemented by restarting the transmission when an expected reply packet (CTS/ACK) is not received.

T-MAC For the T-MAC protocol we use a frame time of 610 ms and a 15 ms time-out value (TA) to end the (adaptive) active time. This 15 ms is set to span the contention period (9.15 ms), an RTS (1.7 ms), the radio turnover period (43 µs) and the start of a CTS. These settings cause T-MAC to operate with a 2.5 % duty cycle in an empty network. In a loaded network the duty cycle will increase as the active period is adaptively extended. To warrant reasonable throughput levels in our experiments we set T-MAC to include all options for mitigating the early-sleeping problem (i.e., the future request-to-send and full buffer priority options are activated), and overhearing avoidance is also used, see [Dam03] for details. For the T-MAC protocol we used the same message layout and reliability features as for the CSMA/CA protocol. The SYNC messages, which are specific to T-MAC and S-MAC are 10 bytes long (control header and a 2 byte timestamp) and are issued once every 90 seconds on average. In our grid topology with 8 neighbours within radio range, that amounts to receiving a SYNC message every 11 seconds.

2.4

EXPERIMENTS

17

S-MAC We implemented the S-MAC protocol by reusing as much of the T-MAC protocol as possible, hence, the basic parameters like MAC header length differ slightly from the real implementation by Ye et al. [Ye02]. The code re-use approach also led us to use a fixed frame time of 1 second in combination with a parametrised active time, which was varied between 61 and 915 ms. Although this is the opposite of the original (fixed active time, variable frame length) a similar parameterisable duty cycle [6 – 92 %] is obtained. Overhearing avoidance is activated for S-MAC since it proved beneficial, especially for longer active periods. In our experiments we do not send large messages across the network, so the message passing support of S-MAC was not needed, nor implemented.

2.4

Experiments

In this section we provide a head-to-head comparison of CSMA/CA, S-MAC, and T-MAC both with and without LPL, by comparing their energy usage under several sensor-network specific scenarios with different communication patterns and varying traffic loads. Each reported energy use is the average of 10 simulation runs with the same settings, but with different seeds for the random number generators. Since throughput is not completely unimportant, we will end each curve at the point where less than 90% of the messages are correctly received. In multi-hop patterns this means that 90% of all messages must reach their final destination (i.e., the sink node). Messages can only get lost due to queue overflows. All corruptions at the physical layer (e.g., collisions) are detected at the MAC layer through missing ACKs, and retransmissions are initiated causing messages to be dropped because of queue overflow (head of line blocking).

2.4.1

Event-Based Unicast

The first experiment concerns local traffic exchanged between neighbours when observing the same physical event in some part of the sensor network. Once every 10 seconds the traffic generator randomly selects an area in the grid where such an event takes place; this area includes approximately 9 nodes, and the event lasts for about 5 seconds. During the event, the observing sensor nodes send (unicast) messages to their neighbours, some of which are also observing the same event. On reception of a message a node will, with a probability of 20%, send a reply message modeling cooperation at the application level. A simulation parameter controls the message frequency during events. Figure 2.3 plots the average current draw for different peak loads [2 – 160 bytes/node/sec] during an event. For reference Figure 2.3 includes the performance of the CSMA/CA protocol without low-power listening. Since plain CSMA/CA operates without a duty cycle, and the network is empty most of the time, the radio is effectively set to receive mode using 4 mA. Note that the curve descends slightly with increasing traffic. This is caused by the overhearing avoidance mechanism that puts nodes into sleep whenever an unrelated communication takes place within radio range. Apparently, the benefits of overhearing avoidance outweigh the increased costs of transmitting (10 mA) vs. receiving (4 mA).

18

COMPARING ENERGY-SAVING MAC PROTOCOLS

Average current draw [mA/node]

4.5 4 915 ms

3.5 3

762 ms 686 ms

2.5 534 ms

2 457 ms 1.5

CSMA/CA S-MAC T-MAC CSMA/CA lpl

381 ms 305 ms

1 183 ms 0.5 0 0

20

40

60 80 100 120 Peak load [bytes/node/sec]

140

160

Figure 2.3: Event-based unicast performance with small 20 byte messages. For S-MAC both

the per parameter lines and the per load tuned line are drawn.

The energy consumption of the S-MAC protocol depends on the choice of the duty cycle. We have experimented with various lengths of the active-period parameter, each yielding a CSMA/CA-shaped curve at a fraction of the energy consumption that roughly corresponds to the duty cycle. The lower the duty cycle, however, the sooner S-MAC cannot handle the peak load causing more than 90 % of the messages to be dropped, hence, cutting the curve short. This points at a serious drawback of S-MAC: the optimal value for the active-period is load-dependent, hence, the application (or user) is left with the difficult task of selecting the duty cycle that compromises best between energy savings and message delivery rate. For now we assume that the optimal choice will be made, and in the remaining graphs we will just plot the best value for each individual load, that is, the line connecting all cut-off points. Applying low-power listening (10 % duty cycle) to CSMA/CA has a dramatic effect: the average current draw drops from 4 mA to 0.42 mA for a (near) zero load, only slightly increasing for higher traffic loads (0.52 mA at 150 bytes/node/second peak). The increased transmission costs, due to the longer preamble, are not compensated by the overhearing avoidance as for plain CSMA/CA. Nevertheless LPL is very effective without impacting network throughput as in the case of S-MAC. Finally, the lowest energy consumption is obtained by T-MAC. At zero load it outperforms CSMA/CA with LPL with a factor of 2.5 (0.42 mA vs. 0.16 mA). For higher loads, T-MAC automatically uses a larger active-period and approaches the CSMA/CA-lpl curve. Note, however, that the T-MAC curve stops at a peak load of 110 bytes/node/sec; due to the early-sleeping problem, T-MAC fails to deliver at least 90 % of the messages. This effect can be countered at the application level, by having nodes aggregate multiple messages into one large message.

2.4

19

S-MAC T-MAC CSMA/CA lpl S-MAC lpl T-MAC lpl

1.4 Average current draw [mA/node]

EXPERIMENTS

1.2 1 0.8 0.6 0.4 0.2 0 0

20

40

140

160

S-MAC T-MAC CSMA/CA lpl S-MAC lpl T-MAC lpl

1.4 Average current draw [mA/node]

60 80 100 120 Peak load [bytes/node/sec]

1.2 1 0.8 0.6 0.4 0.2 0 0

100

200 300 Peak load [bytes/node/sec]

400

500

Figure 2.4: Event-based unicast performance for small 20 byte messages (top) and large 100

bytes messages (bottom).

Figure 2.4 plots the average current draw of event-based unicast traffic for both small (20 byte) and large (100 byte) messages and zooms in on the bottom part of the y-axis. Note that the plain CSMA/CA curve at 4 mA is no longer visible. With large messages T-MAC can sustain a load of 300 bytes/node/sec, a three-fold increase over small messages, while consuming the same amount of energy. Figure 2.4 also shows the positive effects of combining low-power listening at the physical layer with the MAC-level solutions implemented by S-MAC and T-MAC. (Note that the S-MAC and T-MAC curves with low-power listening use the same symbols as before, but connected with a dotted line.) For S-MAC the effect of employing low-power listening is quite large: 1) at zero load the energy consumption is

20

COMPARING ENERGY-SAVING MAC PROTOCOLS

reduced with a factor of 5.5, and 2) the inclination of the curve is reduced with roughly a factor of 8, showing that LPL for S-MAC is effective irrespective of the load. For T-MAC low-power listening is also beneficial, but not as much as for S-MAC since T-MAC includes less idle-listening time due to its adaptive schedules. For near zero load the energy consumption of T-MAC drops with a factor of 4.7 (0.17 mA vs. 0.036 mA), which is less than expected since LPL has a 10 % duty cycle. The reason is that due to T-MAC’s aggressive power-off strategy the ratio of energy used on sending and receiving messages to the energy used on idle listening is already quite favourable. This also explains why the relative gain of LPL for T-MAC reduces when the load increases: the fraction of idle listening is gradually reduced when more messages are transmitted.

2.4.2

Convergecast

The second experiment considers the important case where sensor nodes periodically report their status to the sink (in the left bottom corner of the grid). As described before, messages are routed with a randomised shortest path algorithm to spread the load among multiple trajectories. Nevertheless, the nodes on the right-top to left-bottom diagonal must handle most traffic. No message aggregation at the routing layer is applied. As with event-based unicast the traffic generators can be run with different injection rates and message sizes to control the traffic characteristics. Figure 2.5 shows the performance of the three MAC protocols with and without LPL (except plain CSMA/CA at 4 mA). The first thing to notice, is that in comparison to eventbased unicast, the generated load (plotted along the x-axis) is two orders of magnitude lower. This is caused by two effects: 1) messages now travel about 6.2 hops to reach the sink vs. one hop to a neighbour, and 2) all 100 nodes generate traffic at a constant rate instead of just 9 during the lifetime of an event. Thus, the same injection rate for event-based unicast and convergecast generates about 70 times more traffic network-wide for the latter. Since all traffic is destined for the sink, it becomes a bottleneck for higher traffic loads limiting the maximum throughput of CSMA/CA and S-MAC. The throughput of T-MAC, on the other hand, is limited by the early-sleeping problem. The second observation is that T-MAC has more difficulty handling the convergecast pattern than both S-MAC and CSMA/CA. T-MAC without LPL uses more energy than CSMA/CA with LPL for high loads, which was never the case for event-based unicast, and the gap between T-MAC and S-MAC is a lot smaller (with or without LPL). Nevertheless, T-MAC still has the advantage, especially for larger messages, because it adapts to the load at each node. Figure 2.6 illustrates this aspect. It shows the cumulative distribution of the active times of the T-MAC protocol with LPL for message size 100 and a load of 6 bytes/node/sec. From this graph we can see that 50 % of the nodes have an average active period of less than 70 ms (11 % duty cycle), while the busiest node runs with a 342 ms active period (56 % duty cycle). S-MAC in this case performs best with a duty cycle of 23 % at each node. This shows that half of the nodes run with a duty cycle that is at least a factor of two too high. The resulting abundance of idle listening is effectively dealt with by low-power listening, hence, the remarkably good performance of the S-MAC with LPL combination (a reduction of the inclination of about a factor 4). The effects of T-MAC’s adaptive time-out mechanism are

2.4

21

S-MAC T-MAC CSMA/CA lpl S-MAC lpl T-MAC lpl

1.4 Average current draw [mA/node]

EXPERIMENTS

1.2 1 0.8 0.6 0.4 0.2 0 0

1

5

6

S-MAC T-MAC CSMA/CA lpl S-MAC lpl T-MAC lpl

1.4 Average current draw [mA/node]

2 3 4 Load [bytes/node/sec]

1.2 1 0.8 0.6 0.4 0.2 0 0

2

4 6 8 Load [bytes/node/sec]

10

12

Figure 2.5: Convergecast performance for small 20 byte messages (top) and large 100 byte

messages (bottom).

more pronounced for larger message sizes because S-MAC’s fixed activity period is proportional to the message length, hence the idle-listening time of most nodes is proportional to the message length, while T-MAC’s idle-listening time is basically constant (i.e., the 15 ms time-out).

2.4.3

Full Scenario

This final experiment combines both previous communications patterns into a full sensor network scenario: nodes in the network observe physical events and report their findings

22

COMPARING ENERGY-SAVING MAC PROTOCOLS

100

Percentage of nodes

80

60

40

20

0 0

50 100 150 200 250 300 Average length of the active period [ms]

350

Figure 2.6: Cumulative distribution of active-times for T-MAC, for the convergecast experi-

ment with 100 byte messages and an average load of 6 bytes per node per second.

CSMA/CA LPL Event-based Convergecast full scenario

3.97 3.97 3.93

0.43 0.44 0.46

S-MAC LPL 0.37 0.38 0.80

0.11 0.08 0.18

T-MAC LPL 0.19 0.21 0.28

0.06 0.07 0.12

Table 2.3: Average current draw [mA/node] for the full scenario.

periodically to the sink. In the case of detecting an event, nodes send a 100 byte (unicast) message once per second to a randomly selected neighbour for the duration of the event (5 seconds). One of the approximately 9 nodes detecting the same event reports their joint findings to the sink by sending, also at a rate of once per second, an additional 100 byte multi-hop message. All nodes (including those observing an event) send regular 20 byte status messages to the sink once per minute. Table 2.3 lists the average current draw of the three MAC protocols with/without lowpower listening. Note that LPL is very effective for each of the MAC protocol reducing energy consumption with a factor of 8.5 for CSMA/CA, 4.4 for S-MAC, and 2.7 for T-MAC. Even though T-MAC does not benefit as much, it achieves the lowest energy consumption of all combinations: T-MAC outperforms CSMA/CA with a factor 3.8 and S-MAC with factor 1.5 (all with LPL). For reference Table 2.3 also includes the average current draw of the underlying eventbased unicast and convergecast communication patterns (cf. figures 2.4 and 2.5). Although the convergecast communication generates the most traffic, adding the event-based unicast

2.5

DISCUSSION

23

traffic to it has different effects for different MAC protocols with/without LPL. The energy consumption of CSMA/CA is hardly affected, that of S-MAC is increased noticeably. These differences may be caused by queues overflowing more rapidly when packing traffic into active periods as S-MAC and T-MAC do. Additional research is needed to determine exactly what factors contribute to the observed behaviour.

2.5

Discussion

From the experiments we conclude that Low-Power Listening at the physical layer is a good idea and large energy savings are gained by using it. The negative effects of stretching the preamble (347 vs. 647 µs) are limited: throughput and latency are hardly affected by LPL itself. The exact reductions in energy consumption that can be obtained depend on three factors: 1) the duty cycle (fixed at 10 % in our experiments), 2) the specific MAC protocol running on top of it, and 3) the network traffic load generated by the application. These factors are dependent making it hard to draw general conclusions. What we did learn though, is that the relative impact of LPL is inversely related to the degree at which the MAC protocol is optimised for the sensor network specific traffic characteristics. That is, LPL achieves the greatest reduction in energy consumption for CSMA/CA, the reduction for S-MAC is somewhat less, and LPL is the least effective for T-MAC. Nevertheless, in the full scenario LPL still reduces the energy consumption of T-MAC with a factor of 2.3, which is significant indeed. When reviewing the effectiveness of the two MAC protocols designed for wireless sensor networks we conclude that T-MAC outperforms S-MAC because of its capabilities to adjust to the fluctuations, in time and space, of the network traffic. Without LPL the energy consumption of S-MAC deteriorates rapidly when the volume of network traffic increases, because the fixed duty-cycle must be tuned to handle the peak loads. The resulting idle-listening overhead is well handled by LPL, hence the decent performance of S-MAC with low-power listening. T-MAC, on the other hand, already achieves acceptable energy savings without LPL. The down-side of T-MAC’s aggressive time-out policy is that it cannot cope with high message rates. In this case, however, data aggregation at the routing and/or application layer can probably be applied to alleviate the load on the busiest nodes. The advantage of T-MAC over S-MAC is most pronounced for the event-based communication pattern, since in this case the load at each node toggles between busy and dormant resulting in very bursty traffic over time. For convergecast reporting the network load depends on the location of the nodes, with nodes on the diagonal towards the sink handling the most messages. In this case, the energy saved by a tailor-made active time (T-MAC) over a fixed, worst-case active time (S-MAC) is of little significance, because of all energy spent on the useful work of receiving and transmitting messages.

24

COMPARING ENERGY-SAVING MAC PROTOCOLS

Event-based Convergecast Full scenario ∗ only

T-MAC

Q-MAC

T-MAC lpl

0.19 0.21 0.28

0.11 0.14 0.35∗

0.06 0.07 0.12

84 % of the messages was received correctly.

Table 2.4: Average current draw [mA/node] for Q-MAC.

Low-power listening at the MAC layer To leverage the elegant approach of lowpower listening on platforms where the radio cannot be controlled to such a detailed level as generating 30 µs samples and stretching preambles, we have performed some preliminary experiments with a modified version of T-MAC that polls the ether at the medium access layer (ms resolution). Q-MAC is optimised to handle Quiet networks (i.e., typical sensor networks). The basic idea is that the energy consumption of T-MAC can only be reduced by lowering the time-out value TA, which is currently set to 15 ms (see Table 2.2). The key component that determines TA is the contend time (9.15 ms) needed for collision avoidance. In quiet networks the chances of collision are by definition very low, so Q-MAC takes the drastic measure of removing the contention interval altogether. Therefore, a node that has a message queued when waking up at the beginning of a frame, immediately sends an RTS to the destined neighbour r. This will trigger r to send a CTS; all other nodes in the vicinity can go to sleep. If two nodes send an RTS at the same time, the surrounding nodes will observe the collision and proceed with an ordinary T-MAC frame with contention interval. Both senders will detect the collision indirectly through the missing CTS, and also proceed with the normal T-MAC procedure. The end result is that under Q-MAC nodes only need to listen for 1.5 ms, the transmit time of an RTS, versus 15 ms for T-MAC. Thus, the potential reduction in energy consumption is a factor of ten. In practice, the network will not be completely empty because, at least, SYNC packets must be exchanged and applications do generate some traffic. To asses Q-MAC’s potential for large energy savings, and its anticipated sensitivity to network load, we repeated the full-scenario experiment with Q-MAC, as well as the underlying event-based unicast and convergecast experiments. The results in Table 2.4 give a mixed signal. For light loads (event-based unicast and convergecast) Q-MAC strikes a middle ground between plain T-MAC and T-MAC combined with low-power listening. The reductions in energy consumption, however, do not even come close to Q-MAC’s tenfold potential and are limited to less than a factor of two. For moderate loads (i.e., the full scenario) Q-MAC’s performance is counter productive: the energy consumption increases, and the message delivery rate drops below acceptable levels (i.e., 90 %). For now, we conclude that the Q-MAC approach is too sensitive to load, and we plan to investigate the exact causes and possible counter measures so as to make low-power listening at the MAC layer a viable alternative.

2.6

2.6

CONCLUSIONS

25

Conclusions

Wireless sensor networks hold a great potential for ubiquitous applications in the area of (remote) sensing and control. A key issue that needs to be addressed is the efficient operation of the radio link to foster collaboration between individual resource-scarce sensor nodes, on the one hand, and to minimise the energy consumption to extend lifetime on the other hand. The focus on energy consumption requires special solutions since typical communication protocols for wireless LANs are designed to achieve high throughput, low latency, and fairness. In this chapter we have compared three approaches for saving energy in sensor networks: low-power listening at the physical layer, and S-MAC and T-MAC operating at the medium access layer. These three approaches have in common that they introduce a duty-cycle to mitigate idle listening, the dominant cause of energy consumption in typical sensor network scenarios where applications communicate seldom. Low-power listening extends the length of the preamble, so receivers can probe the ether periodically. S-MAC synchronises nodes, and introduces frames in which nodes only listen at the beginning for some fixed active time. T-MAC also operates with frames, but the length of the active time is adapted to the network traffic through a simple time-out mechanism. Through extensive simulation we studied the energy savings of S-MAC and T-MAC over standard CSMA/CA (IEEE 802.11) in combination with or without low-power listening. We used a traffic generator to model typical sensor network behaviour: neighbour-to-neighbour communication when observing a physical event, convergecast reporting for relaying status updates, and a full scenario that combines both patterns. The results show that • Low-power listening is very effective at mitigating idle-listening; it has the highest relative impact on CSMA/CA, but the absolute lowest energy consumption is reached in combination with T-MAC. • T-MAC’s aggressive time-out policy allows it to adapt seamlessly to variations in traffic induced by typical sensor network applications at a the expense of a slight reduction in peak throughput. T-MAC performs slightly better for variations over time (events), than for variations in location (periodic reporting). • S-MAC suffers from over-provisioning. Since its duty cycle is fixed for all nodes often a rather large value must be selected to avoid dropping messages under peak loads, which causes S-MAC’s idle-listening to deteriorate for increasing traffic loads. When combined with low-power listening, however, S-MAC achieves acceptable results, but not as good as those of T-MAC with low-power listening. Since T-MAC with LPL performs best, but not all platforms allow a very precise control of the radio at the µs scale, we briefly discussed a novel approach (Q-MAC) that implements the idea of low-power listening at the MAC level (ms scale). Preliminary results indicate that additional research is needed to make it a viable technique.

The Crankshaft Protocol

3

In the previous chapter we have examined several de facto standard general-purpose MAC protocols for WSNs. We now turn our attention to dense networks to which general purpose MAC protocols are not well suited, and design a new MAC protocol named Crankshaft specifically for this situation. We show that taking into account the specific characteristics of dense networks allows significant energy savings.

Recent experiences with real-world deployments [Lan06] have shown that the number of neighbours in WSNs can be higher than 15, which exceeds the 5–10 that MAC protocol designers have typically assumed. The “smart-dust” vision of WSNs also incorporates these dense deployments. Dense deployments have their own specific challenges, due to the high connectivity. Below we list the most important problems in current MAC protocols arising from dense networks: Overhearing Overhearing of messages destined for other nodes is a source of energy waste in any deployment. However, in dense deployments there are more neighbours that will overhear a message, which exacerbates the problem. Furthermore, having more neighbours also means there may be more messages to overhear. Communication grouping Several protocols, like S-MAC [Ye02] and T-MAC [Dam03], group communication into active parts of frames. This is done to allow the network to go to sleep during the inactive parts of frames. The approach has a significant drawback: the grouping increases contention and collisions. Collisions cause retries, which in turn increases the traffic load. Furthermore, for adaptive protocols like T-MAC the increased traffic will keep nodes awake longer without increasing useful energy consumption. This chapter is based on: “Crankshaft: An energy-efficient MAC-protocol for dense wireless sensor networks”, G. Halkes and K. Langendoen, in 4th European Conference on Wireless Sensor Networks (EWSN ’07), pp. 228–244. Delft, The Netherlands, January 2007.

27

28

THE CRANKSHAFT PROTOCOL

Over-provisioning TDMA protocols like LMAC [Hoe04a] schedule send-slots for participating nodes. However, if a node has nothing to send, the slot goes unused. In a dense deployment, a frame has to be split into many slots to allow all nodes to participate in the network. Most of these slots go unused, but as a node has to wait for its send slot before it is allowed to send, latency increases and throughput decreases. Also, all the non-sender nodes will have to listen for at least a short amount of time to check if the scheduled sender is actually using the slot, and to check if they are being addressed by the sender. Neighbour state Protocols that save neighbour state as for example PMAC [Zhe05] and WiseMAC [EH04] do, also run into problems in dense deployments. Because in a dense deployment each node has many neighbours, the MAC protocol will have to either maintain a lot of state or discard some of the neighbours. Maintaining state for over 20 neighbours is undesirable as it uses precious RAM. However, discarding neighbour information means that communication with certain nodes is not possible or at least severely hindered. Furthermore, the routing protocol also maintains a neighbour list. If the neighbour list of the routing layer contains different nodes than the neighbour list of the MAC protocol, considerable problems arise. This chapter introduces the Crankshaft MAC protocol, which is specifically designed to perform well in dense deployments. It reduces overhearing and communication grouping by letting nodes power-down their radios alternately, rather than simultaneously. It does not keep per-neighbour state and receive-slot scheduling ensures that over-provisioning is bounded. The trade-off is that the maximum throughput is reduced, especially for broadcast traffic. For many applications however, this trade-off is acceptable. The rest of this chapter is organised as follows: First we will present related work. Then, in Section 3.2 we discuss the design of the Crankshaft protocol. In Section 3.3 we discuss the setup of our simulations, followed by the simulation results in Section 3.4. In Section 3.5 we present our results with our TinyOS implementation. Finally in Sections 3.6 and 3.7 we provide more discussion of the results and finish with our conclusions and future work.

3.1

Related Work

The problems introduced by dense networks can be solved in several layers of the networking stack. One proposed technique that could reduce overhearing in dense networks is based on clustering, as demonstrated by for example [Hoe04b]. By creating a backbone of active nodes to maintain routing, the rest of the nodes, called passive nodes, can go to sleep. However, this method presents several significant drawbacks. First of all, this technique requires integration of the MAC and routing layer. Second, the route redundancy in the network is reduced or even removed, leaving the network vulnerable to failures. Lastly, the clustering increases complexity in the protocol and implementation, and thus increases the chance of bugs. We therefore focus on MAC-level solutions for dense networks. Many MAC protocols have been designed for WSNs. Below we present a selection of protocols that have relevance to our new Crankshaft protocol.

3.2

CRANKSHAFT

29

One of the earliest proposals is Low-Power Listening [Hil02] (LPL). LPL uses efficient channel polling to reduce the energy spent on listening for incoming messages (see Section 2.2 for details). The B-MAC [Pol04] protocol employs LPL, with the added functionality that the application can tweak the poll period depending on its bandwidth usage. The B-MAC protocol employs a DATA/ACK sequence to detect transmission problems. The channel polling mechanism of LPL has been further refined in the SCP-MAC [Ye06] protocol. It uses channel polling, but it synchronises all nodes to poll at the same time, essentially implementing a slotting mechanism. This allows potential senders to do contention resolution before the intended receiver wakes up. Furthermore, the message preambles do not have to be stretched for a complete poll period because the poll moment is known. Crankshaft employs a mechanism of channel polling very similar to the SCP-MAC protocol. Several TDMA protocols have also been developed. A good example is the LMAC protocol [Hoe04a]. Contrary to many other TDMA protocols, the LMAC protocol uses a completely distributed slot assignment mechanism. Each slot owner sends at least a packet header in the slot the node owns. Neighbouring nodes listen to the start of each slot, and detect which slots are free. However, for a TDMA protocol it is required that a slot is not reused within a two-hop neighbourhood. The LMAC protocol therefore includes a bitmap with all the slots assigned to a node’s neighbours in the header. By combining the bitmaps of all neighbours, a node can determine which slots are free within a two-hop neighbourhood. Crankshaft also uses frames and slots, but schedules receivers rather than senders. However, the mechanisms employed by LMAC to achieve synchronisation, framing and slotting are used in Crankshaft. Pattern MAC [Zhe05], or PMAC, also divides time into frames. Each frame consists of two parts: the Pattern Repeat part and the Pattern Exchange part. Both parts are divided into slots. During the Pattern Repeat part, nodes follow the sleep/wake pattern they have advertised. Nodes also wake up when a neighbour for which they have a packet to send has advertised it will be awake during a particular slot. Nodes advertise their chosen patterns during the Pattern Exchange part. Each slot in the Pattern Exchange part is long enough to send a node’s pattern information and nodes have to contend for these slots. To enable all nodes to send their pattern information, the Pattern Exchange part has as many slots as the maximum number of neighbours a node is expected to have. The sleep/wake patterns are adapted to the traffic going through a node, to achieve maximal energy savings. The PMAC protocol is similar to the Crankshaft protocol in that it also schedules nodes to be awake for reception on a slot basis. However, the PMAC protocol requires nodes to exchange and store schedules. When employed in dense networks all the above protocols suffer from one or more of the problems signalled in the introduction. This results in suboptimal energy use.

3.2

Crankshaft

Having signalled the problems MAC protocols face in dense wireless-networks, we designed the Crankshaft protocol. The basic principle of the protocol is that nodes are only awake to receive messages at fixed offsets from the start of a frame. This is analogous to an internal combustion engine where the moment a piston fires is a fixed offset from the start of the

30

THE CRANKSHAFT PROTOCOL

Frame

Time

Slot number 0 1 Nodes to wake up 70 (examples) 130

2 92

3

4

5

6

7

8 9 38 158

B B All All

Figure 3.1: Crankshaft frame structure with ten unicast slots and two broadcast slots. Nodes

wake up to receive a message in one unicast slot and in the broadcast slots.

rotation of the crankshaft. Allowing different nodes to wake up for reception at different offsets from the start of the frame means that there are fewer nodes overhearing messages and spreads out the communication between unrelated receivers. Below we detail the working of the Crankshaft protocol. The Crankshaft protocol divides time into frames, and each frame is divided into slots (see Figure 3.1). There are two types of slots in the Crankshaft protocol: broadcast slots and unicast slots. During a broadcast slot all nodes wake up to listen for an incoming message. Any node that has a broadcast message to send contends with all other nodes to send that message. A frame starts with all the unicast slots, followed by the broadcast slots. Each node also listens for one unicast slot every frame. During that slot a neighbouring node can send a message to that node, provided it wins the contention. The slot a node listens to is determined by the node’s MAC address. Therefore, a node wanting to send a message knows precisely in which slot the destination wakes up. Crankshaft uses a Data/Ack sequence for unicast messages, and the slot length is such that it is long enough for the contention period, maximum-length data message and acknowledgement message. If the sender does not receive an acknowledgement, the protocol is set to retry each message three times in subsequent frames. However, to reduce contention when retrying the transmission the node will only retry in the next frame with a probability of 70%. Otherwise it will wait for another frame. Special provisions are made for base-station or sink nodes. Sink nodes will listen to all unicast slots. The rationale for this is that the sink is the destination for most traffic in the network and therefore requires more receive bandwidth. Furthermore, the sink is typically connected to either a much larger battery or mains power, which will allow it to spend more energy. To allow other nodes to determine whether a neighbour is a sink node, sink nodes use specially reserved addresses. For example, in TinyOS node 0 is always considered a sink node. Although many complicated methods of slot assignment are possible (e.g. Time Division Hashing [Che05]), we have chosen to use a simple mechanism to limit the amount of processing power required. Each frame has n unicast slots, and the slot assignment is performed by calculating MAC address modulo n. Using a static slot assignment like this may result in two neighbours being assigned the same slot. To allow such neighbours to communicate,

3.2

CRANKSHAFT

31

Message Exchange Window

Contention Window Receiver Poll Sender A

Sender B

Receiver

Poll

Receiving

Preamble

Message

Acknowledgement

Figure 3.2: Contention and message exchange in the Crankshaft protocol.

nodes are allowed to act as senders in their own receive slot. A node that acts as a sender in its own receive slot will revert to receive mode if it loses contention. Clearly, using frames requires that nodes are synchronised. Synchronisation can be achieved both through a reference node (i.e., the base-station or sink node), or through a distributed algorithm like GSA [Li05]. This synchronisation can also be used to achieve increased energy savings. Nodes need not wake up for an entire slot, but only for a small amount of time at a fixed offset to the start of the slot (see Figure 3.2). The period between the start of the slot and the moment the listening node turns on its radio is used to resolve contention. A node that wants to send a message in a particular slot chooses a moment in the contention window. The sending node listens for a short amount of time just prior to its chosen moment to detect other nodes contending for the same slot. If no other nodes are sending, the sending node starts sending a preamble to notify other nodes of its intention to send. Shortly after the receiving node is known to wake up, the sending node transmits the start symbol and the actual message. This is similar to the channel polling mechanism in the SCP-MAC protocol [Ye06]. Note that during the contention window only the contending senders are awake, and only the winner of the contention is awake for more than a short poll. This results in very energy efficient contention resolution. To improve contention resolution, the Crankshaft protocol also employs the Sift distribution [Jam06] for choosing the moment to start sending. The Sift distribution is essentially a truncated geometric distribution, which results in fewer collisions than using a uniform distribution. Using Sift also reduces the average amount of time between the start of sending and the wake up moment of the receiver, saving even more energy. The header for Crankshaft packets consists of a one byte length field, two byte to and from addresses, a one byte message type field, three bytes of clock synchronisation information, and two CRC bytes. For broadcast messages, the type field is set to broadcast and the to address is omitted. In our simulations, the synchronisation information contains the number of hops to the reference node, and the current (estimated) clock at the reference node.

32

THE CRANKSHAFT PROTOCOL

Although not implemented in our simulations or real-world implementation, the Crankshaft protocol can use address filtering to reduce overhearing. A node would then simply turn of its radio after receiving the to address if the message is for another node.

3.3

Simulation Setup

To evaluate the Crankshaft protocol we created an implementation in an extended version of the OMNeT++ [Var01] based simulator used in Chapter 2. The simulator contains a model of the EYES wireless sensor node, which includes an RFM TR1001 radio. The radio model has been replaced with an SNR-based model, on top of a simple path-loss propagation model. For timing the nodes use a 32 KHz crystal, and the nodes are powered by two 1.5 V AA batteries supplying 3 V. For our experiments we use the layout of a real-world potato-field experiment [Lan06]. This setup includes 96 nodes on a field of approximately 90×50 meters. The simulated nodes have a radio range of 25 meters, which is similar to the radio range in the real-world experiment. The base station is situated near a corner. Average degree in the network is approximately 17.3. In our simulations we have included five protocols: B-MAC with retries, T-MAC, LMAC, SCP-MAC*, and of course Crankshaft. The SCP-MAC* protocol is our variation of the SCP-MAC protocol. Instead of using two contention periods, one of which the receiver overhears, it uses the Sift distribution for a single contention period before the receiver wakes up. This way the SCP-MAC protocol can easily be implemented as a variation of the Crankshaft protocol, where each slot is a receive and broadcast slot at the same time, and acknowledgements are disabled. We have focused our simulations on traffic patterns we consider most important for wireless sensor networks: convergecast and broadcast flood. The convergecast pattern is the pattern used in most monitoring applications. All nodes periodically send data to a sink node, which then processes the data or stores the data for further processing. Broadcast floods are typically found in routing protocols and in distributing queries over the network. Table 3.1 lists the simulation parameters. Each simulation lasts 200 seconds of simulated time and the results are the average of 20 runs with different random seeds. Routing is done using a static routing table. Therefore there is no routing traffic exchanged during the simulation.

3.4

Simulation Results

Below we present our simulation results. In Section 3.4.1 we present the results for the convergecast pattern followed by the results for the broadcast flood pattern in Section 3.4.2. In Section 3.4.3 we revisit the convergecast pattern results and show how the latency of the Crankshaft protocol can be improved.

3.4

SIMULATION RESULTS

Category

Parameter

Value

General Radio

Message payload Effective data rate Preamble + start byte Transmit Receive Sleep Sample period Frame length Contention window Packet header Maximum data length Activity time-out Maximum data length Slots per frame Packet header Contention window Poll length Maximum data length Sift nodes parameter Packet header (max.) Unicast slots Broadcast slots

25 bytes 61 kbps 433 µs 12 mA 3.8 mA 0.7 µA 300 µs 610 ms 9.15 ms 8 bytes 250 bytes 15 ms 64 bytes 80 20 bytes 9.15 ms 300 µs 64 bytes 512 11 bytes 8 2

B-MAC T-MAC

LMAC

SCP-MAC* and Crankshaft

Crankshaft specific

33

Table 3.1: Simulation parameters.

3.4.1

Convergecast

Figure 3.3 shows the results of our convergecast experiments. It is clear that the B-MAC protocol has the highest delivery ratio1 (top graph) except for high message rates, but at the expense of consuming a lot of energy (middle graph). The high energy consumption is due to the the high connectivity which causes many nodes to overhear each transmission. As nodes using B-MAC can send their message any time, i.e. they do not have to wait for a slot or frame to start, the latency remains low until the network is saturated (bottom graph). The delivery ratio of the SCP-MAC* protocol is clearly adversely affected by the lack of acknowledgement messages for low message rates. Even for low message rates SCP-MAC* does not achieve perfect delivery. However, the lack of acknowledgements also means that there are fewer messages to send. For high messages rates the lack of acknowledgements is beneficial. For protocols using acknowledgements the increasing collisions at high message rates will induce more retransmissions, which in turn increase the network load. This effect 1 The

delivery ratio is defined as the fraction of messages sent by all nodes that arrive at the sink node.

THE CRANKSHAFT PROTOCOL

B-MAC T-MAC LMAC Crankshaft SCP-MAC*

1

Delivery ratio

0.8 0.6 0.4 0.2 0 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.6

0.7

0.8

0.6

0.7

0.8

Average power consumption [mW/node]

Load [messages/node/sec] 10

B-MAC T-MAC LMAC Crankshaft SCP-MAC*

8

6

4

2

0 0

0.1

0.2

0.3

0.4

0.5

Load [messages/node/sec] 12 Avg. per message latency [sec]

34

B-MAC T-MAC LMAC Crankshaft SCP-MAC*

10 8 6 4 2 0 0

0.1

0.2

0.3

0.4

0.5

Load [messages/node/sec]

Figure 3.3: Performance under convergecast traffic: delivery ratio (top), power consumption

(middle) and latency (bottom).

3.4

SIMULATION RESULTS

35

can be seen in that the SCP-MAC* curve does not drop like the B-MAC and Crankshaft curves do. SCP-MAC*’s energy consumption is much better than B-MAC, but for high message rates increases quickly as well. Compared to the B-MAC protocol, Crankshaft’s delivery ratio starts to drop at lower message rates. This is caused by limiting the per-node receive bandwidth through selecting only one receive slot per frame. For low message rates Crankshaft does manage perfect delivery. The bandwidth limitation does mean that for medium and high message rates the Crankshaft protocol cannot achieve the high delivery ratios of B-MAC and SCP-MAC*. The Crankshaft protocol is very energy efficient. It consumes a factor of 3.5 less energy than SCP-MAC*. There are two factors which contribute to the energy efficiency: firstly, because only a subset of the nodes is awake in each slot overhearing is reduced. Secondly, contention is reduced. When using SCP-MAC* and node A wants to send to node B and node C wants to send to node D, and A and C are within communications range, nodes A and C contend for the right to send. However, when using Crankshaft nodes B and D generally wake up in different slots, automatically resolving the contention between nodes A and C. LMAC suffers from the need to assign a contention-free slot to all nodes in the network. To allow such an assignment to exist 80 slots are required. Even at low message rates the LMAC protocol does not achieve a perfect delivery ratio. Network congestion caused by low per-node bandwidth prevents this. The energy consumption remains nearly constant, because the LMAC protocol already saturates at low message rates. The small increase in energy consumption is due to more messages that are sent one hop, only to be discarded because of full message queues at the receiver. The large number of slots also induces a high message latency for the LMAC protocol. Finally, T-MAC is unable to cope with the flood of messages directed towards the sink node. The aggressive sleep policy is causing nodes to go to sleep too often, which hinders throughput. Although latency seems low for high message rates, this is caused by only the nodes near the sink being able to reach the sink. The aggressive sleep policy does provide low energy consumption, even though the T-MAC protocol suffers from communication grouping and overhearing. Of all the protocols compared, SCP-MAC* has the lowest latency. Again this is caused by the lack of acknowledgements and retries. Messages are not kept in queues waiting for retransmissions of other messages, which means latency is kept down. Crankshaft’s latency rises quickly as the delivery ratio drops. This is partly caused by messages having to wait in queues due to congestion, and partly caused by messages having to wait a full frame (150 ms) when contention is lost. However, Crankshaft’s latency can be improved, as we will show in Section 3.4.3.

3.4.2

Broadcast Flood

With our second experiment we investigate the performance under broadcast flood traffic. In this experiment the sink node initiates the floods. The delivery ratio is calculated as the total of unique flood messages received by all nodes, divided by the total of unique messages that should have been received by all nodes. To allow nodes to determine the uniqueness of a message, each message contains a serial number. Nodes compare the serial number

36

THE CRANKSHAFT PROTOCOL

1

Delivery ratio

0.8

0.6

0.4

0.2

0

B-MAC T-MAC LMAC Crankshaft SCP-MAC*

Average power consumption [mW/node]

0 10

1

2 3 Floods per second

4

5

4

5

B-MAC T-MAC LMAC Crankshaft SCP-MAC*

8

6

4

2

0 0

1

2

3

Floods per second

Figure 3.4: Performance under broadcast-flood traffic: delivery ratio (top), power consumption

(bottom).

in the message with the highest serial number received so far. If the serial number in the message is lower or equal, the message is discarded. Note that this may result in messages not previously received being discarded, if a message with a higher serial number has already been delivered. For this to happen, collisions or link errors must have resulted in the failed reception of a lower numbered message first. Figure 3.4 shows the delivery ratio (top) and average power consumption (bottom) for all protocols under the broadcast flood traffic pattern. B-MAC outperforms all other protocols in terms of delivery ratio for high message rates, but at the expense of high energy consumption.

3.4

SIMULATION RESULTS

37

Again, because it does not use any slotting or framing it can quickly move messages through the network. Although it uses much energy, the energy is mostly put to good use. The T-MAC curve shows a remarkable artifact. As the amount of traffic in the network increases, so does the delivery ratio. The cause is again T-MAC’s aggressive sleep policy. In low traffic conditions, most of the network is asleep after the sink initiated the broadcast flood. Although all nodes that heard the sink’s broadcast repeat the message, the sleeping part of the network does not receive most of these. Depending on the collisions and backoff, parts of the network may not receive any of these messages at all. Increasing the traffic load will keep more nodes awake for more time, increasing the number of nodes receiving re-sends. However, it also increases the chance of messages arriving out of order, thereby causing nodes to disregard previously unseen messages arriving later. LMAC’s performance is not hampered by the 80 slots in this scenario, because all nodes need to send the same number of messages. Therefore, there is little over-provisioning. Protocols like B-MAC and SCP-MAC* can support more simultaneous transmissions than LMAC, because they do not require all nodes in a two-hop neighbourhood to remain quiet. Of course this leads to collisions, but because every message is sent multiple times, although by different nodes, this is not a problem. If a node does not receive the first transmission, it probably receives a second or third. Hence, the B-MAC and SCP-MAC* protocols outperform LMAC. The Crankshaft protocol shares the SCP-MAC* characteristics in the broadcast case. However, because only two out of every 10 slots are broadcast slots Crankshaft can cope with roughly one sixth of the traffic that SCP-MAC* can. It only uses approximately one sixth of the energy as well. Crankshaft’s broadcast flood performance can be tuned to the amount of broadcast flood traffic is expected, by increasing the number of broadcast slots. Of course the broadcast performance is then traded for unicast performance, as unicast traffic will receive a smaller share of the available time.

3.4.3

Crankshaft Latency

The average message latency for the Crankshaft protocol under convergecast traffic increases quickly as the number of messages per node per second exceeds 0.15. However, the design of the Crankshaft protocol leaves an option to improve the latency. Recall that the cause of the quickly increasing latency is that a node that loses contention or does not receive an acknowledgement has to wait for an entire frame to retry. Given that a dense network provides many alternate paths to the sink, a node that loses contention or does not receive an acknowledgement could also try to send its message to another next hop. Of course the routing layer has to cooperate with the Crankshaft protocol to make this work. To this end the interface between the routing layer and the MAC protocol is augmented. First of all, the routing layer can query Crankshaft about which of a list of neighbours wakes up first. Secondly, Crankshaft will return a message that it could not deliver in the first try to the routing layer. That is, it will not block and try at some later moment as most MAC layers do. The routing layer will then decide if and to whom to retry sending the message. Figure 3.5 shows the latency (bottom) for the Crankshaft protocol with the low-latency option, marked Crankshaft LL. For reference the results for the regular Crankshaft protocol and the SCP-MAC* protocol are repeated.

THE CRANKSHAFT PROTOCOL

Average power consumption [mW/node]

38

10

Crankshaft Crankshaft LL SCP-MAC*

8

6

4

2

0 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.6

0.7

0.8

Load [messages/node/sec]

Avg. per message latency [sec]

12

Crankshaft Crankshaft LL SCP-MAC*

10 8 6 4 2 0 0

0.1

0.2

0.3

0.4

0.5

Load [messages/node/sec]

Figure 3.5: Crankshaft power consumption (top) and latency (bottom) with low-latency option.

Even for Crankshaft’s low-latency version, average latency starts to increase noticeably at approximately 0.15 messages per node per second. The latency is however reduced to approximately 37% of the regular Crankshaft protocol’s latency. The increase at 0.15 is almost entirely due to a small group of 15 nodes that are in the corner opposite the sink. These nodes do not have many next hop neighbours. As the network load increases these nodes are having increasingly more difficulty in sending their messages to the next hop. Average latency for the messages for these nodes increases to some eight seconds and more. From 0.25 through 0.35 messages per node per second the increase in latency stops. On this interval the number of messages that arrive at the sink from the 15 distant nodes decreases in such a way

3.5

TINYOS IMPLEMENTATION

39

that it compensates for the increased latency. Most of the other 80 nodes still have average per message latencies in the range of 0–0.7 seconds. Using the regular Crankshaft protocol, approximately half of the nodes already have average per message latencies (much) larger than one second. For message rates larger than 0.35 the other 80 nodes are also seriously affected by the increasing network load. This is reflected by the increasing latency. As can be seen from the top graph in Figure 3.5, Crankshaft’s energy consumption does not change for message rates below 0.35 messages per node per second. At higher rates the energy consumption does increase significantly, to 2.7 times the energy consumption without the low-latency option at a rate of 0.8 messages per node per second. The congestion in the network is causing increasing numbers of retransmissions, which consume much energy. The delivery ratio is affected very little by the low-latency option. For message rates between 0.15 and 0.5, at most 7 percentage points are gained, while at 0.8 approximately 10 percentage points are lost.

3.5

TinyOS Implementation

To demonstrate the real world feasibility of the Crankshaft protocol, we have created an implementation of Crankshaft for the TinyOS operating system. We have tested our implementation by using the monitoring application that was used for the potato-field experiments [Lan06]. We have set up 29 nodes in a garden. To create a multi-hop network we have limited the send power of the nodes, such that a dense two-hop network was created. This network was then left to run for four weeks. The application sent temperature and humidity data to the sink at ten minute intervals. Furthermore, a message with statistics was sent to the sink once every two hours. To route the data to the sink the CTP protocol was used. CTP estimates the link quality by checking, amongst other things, whether a message was acknowledged or not. If the MAC layer does automatic retries, this will skew CTP’s link-quality statistics. Therefore, the retries in the Crankshaft protocol were disabled for this experiment. By tuning the retry timeout in the CTP protocol we were able to maintain a probabilistic retry behaviour similar to that of the Crankshaft protocol. The default CTP setting of thirty retries was reduced to a less aggressive seven. Table 3.2 lists the other parameters of the experiment. We only present results for the first seven days of the experiment, because a glitch in the sink software caused the sink to cease advertising itself after the first week. This was not detected until more than a week later because many messages were still received through overhearing, or through a couple of nodes with poor links that still kept the sink in their routing tables. Only when the network completely collapsed due to routing cycles was this glitch detected, and subsequently resolved by rebooting the sink node. Figure 3.6 plots the average six-hourly per-node delivery ratio (roughly 97%) and the standard deviation (about 4%). Only messages that were directly addressed to the sink were included in the calculation of the delivery ratio, not the messages the sink overheard. The dip on the second day of the experiment was caused by an interruption of mains power, during which time the sink was down. The results also show a relatively large standard deviation. Our first hypothesis was that this was due to nodes that were unable to reach the sink in a

40

THE CRANKSHAFT PROTOCOL

Category

Parameter

Value

Experiment

Message rate Message payload (data + routing header) Effective data rate Preamble + start byte Slot length Contention window Poll length Packet header Unicast slots Broadcast slots

7 messages/hour 49 bytes 19.2 kbps 2.1 ms 49 ms 6.25 ms 2 ms 13 bytes 16 2

Radio Crankshaft

Table 3.2: Real-world experiment parameters.

1

0.8

0.8

0.6

0.6 Delivery ratio Duty cycle

0.4

0.4

0.2

Duty Cycle

Delivery ratio

1

0.2

0

0 1

2

3

4 Day

5

6

7

Figure 3.6: Average six-hourly per-node delivery ratio and duty cycle for the garden experi-

ment.

single hop. Multi-hopping of course provides more opportunity for losing a message because each hop the message may be dropped. However, careful analysis showed that both the nodes that used the sink as their first hop, as well as the nodes that had to use multi-hopping showed this large standard deviation. A full investigation of this issue requires more extensive logs than the MAC layer statistics we gathered, so we cannot provide a definitive explanation. Also plotted in Figure 3.6 is the average duty cycle of the radio. The average duty cycle is around 4.2%, of which approximately 2.5% is caused solely by the time-synchronisation protocol. The rest is used for polling, data messages and routing broadcasts. The fairly low data rate of the CC1000 radio impacts the duty cycle, as sending a message takes a fairly

3.6

DISCUSSION

41

long time. It should also be noted that the average acknowledgement rate was 50%, meaning that each unicast message was on average sent twice per hop, in turn causing extra energy consumption. The mediocre acknowledgement rate likely points to a remaining problem in our MAC implementation, as the acknowledgement rate over time showed sudden drops in performance even when the parent choice remained stable. Despite the few remaining issues described above, which are related to our specific implementation and not to the Crankshaft protocol itself, we conclude from this deployment that the Crankshaft protocol can indeed be implemented on real hardware.

3.6

Discussion

The simulations results show that the Crankshaft protocol can provide good convergecast performance at low energy consumption in dense networks. Latency can be a problem in the unoptimised protocol. However, by spending a little more energy latency can be kept down if the routing layer is modified as well. Furthermore, message rates of more than 0.5 messages per node per second are infrequent in monitoring applications. The trade-off is that broadcast bandwidth is significantly reduced. This means that to use the Crankshaft protocol effectively, broadcast flooding must be minimised. Flooding is used mostly for two purposes in WSNs: collecting routing information and pushing queries into the network. For the former purpose broadcast flooding is required to operate correctly. The latter can be achieved by more bandwidth efficient broadcasting schemes, especially in dense networks. This would eliminate the need for high broadcast throughput. Also, sustained flood rates of more than one flood per second are probably excessive. A point to consider with respect to the implementation of the Crankshaft protocol is the recent trend towards packet-based radios. To implement Crankshaft variable preamble lengths are required. Packet radios in general do not provide sufficient flexibility to implement this directly. However, the creators of the WiseMAC protocol [EH04] already provide a solution: repeatedly sending the packet for the required duration. Although this may seem wasteful, one has to consider that sending is the infrequent operation. Letting the sender spend more energy to allow multiple (overhearing) receivers to save energy is usually more energy efficient on balance. The Crankshaft protocol can also be tuned to the specific application and network density. By increasing the number of unicast slots the consumed energy can be brought down further, although maximum bandwidth will be decreased and latency will go up. By decreasing the number of unicast slots, the maximum per node bandwidth can be increased and the latency decreased, at the expense of more energy consumption and more collisions. Similar considerations hold for the number of broadcast slots.

3.6.1

Variations

The Crankshaft protocol design allows for some variations in the slot assignment mechanism. For example, we have tested using meta frames consisting of four frames. Each of the four

42

THE CRANKSHAFT PROTOCOL

frames would use a different assignment calculation, in our case different parts of the MAC address. As nodes are usually numbered sequentially, simply using the higher bits of the MAC addresses would not give enough variation. Therefore the calculations were more complex than simple modulo calculation. We also disallowed sending in a node’s receive slot, because there always is at least one of the four frames in which the slot assignment for two neighbours differs. Although this assignment scheme resulted in a small performance increase, we felt the difference did not compensate for the added code complexity and processing requirements. Other options we tested are Time Division Hashing [Che05], and using broadcast slots for unicast if two neighbours share a slot assignment. None of these options gave a significant performance benefit, so they are not included in the results.

3.7

Conclusions and Future Work

In this chapter we have presented Crankshaft, a MAC protocol for dense wireless sensor networks. It employs receive-slot scheduling to reduce overhearing and bases the schedule on MAC addresses to obviate the need to keep neighbour state. We have shown through simulation that Crankshaft can provide good delivery ratios in convergecast scenarios with respect to Low-Power Listening, T-MAC, LMAC and SCP-MAC*. Simulations also show that Crankshaft manages to do so while consuming very little energy. Further simulations show that the Crankshaft protocol cannot provide good broadcast flood delivery. However, Crankshaft’s energy consumption does not suffer from broadcast flooding either. Most applications only require sporadic flooding, for which Crankshaft provides adequate performance. We conclude that the Crankshaft protocol is suitable for long-lived monitoring applications, where energy efficiency is key. The Crankshaft protocol can provide the required delivery ratios for convergecast traffic at extremely low energy consumption. The Crankshaft protocol as proposed has a very rigid structure. This limits the applicability of the protocol. One possible way to improve the protocol is adaptive scheduling of extra receive slots to facilitate more application types and mitigate bottlenecks that can occur near sink nodes and elsewhere in the network. Another research item is improving the broadcast capabilities of the Crankshaft protocol. A final research direction for the Crankshaft protocol is leveraging multi-channel radios. In principle this is as simple as assigning nodes a channel as well as a time within a frame. Because Crankshaft uses fixed receiveslot scheduling the usual problem associated with multi-channel protocols, i.e. coordination of the sender-receiver rendez-vous, does not require a control channel but is implicit in the schedule.

The λMAC framework

4

In the design of the Crankshaft protocol in the previous chapter, several concepts from other MAC protocols were used, suggesting an opportunity for code sharing between protocol implementations. In this chapter we investigate a framework for implementing MAC protocols that allows such code reuse. The results show that the framework allows implementation of complex protocols in few lines of code with only small overhead.

Current MAC protocol design for WSNs covers a wide variety of different tasks. A MAC protocol is responsible not only for deciding when to send packets, but also what to send. For example, generating the standard Unicast sequence of RTS/CTS/DATA/ACK messages is usually the responsibility of the MAC protocol after the application has provided a data packet to be sent. The MAC must maintain an internal state machine monitoring which one of these packets it last sent or received, enabling it to determine what packet should be sent/received next. Unfortunately, the decision about whether a MAC’s implementation of Unicast uses RTS/ CTS messages (which are seen by some designers as overhead, and by others as required for reliability) tends to be a somewhat haphazard affair. Often, whether they are required should be an application-level decision, and so some MAC protocols that implement RTS/CTS allow this functionality to be switched off and on at run or compile time. However, this is another example of a feature that may or may not be in a given MAC protocol depending on the whims of its designer. Given that we have a set of functionality that should be common to all MAC protocols, but certain implementations do or do not have particular features implemented, we lose out on the advantage of common functionality: the idea that we can ideally use any given MAC protocol as a drop-in replacement. Additionally, because the duplication of effort results in both This work was initiated by Tom Parker, and an earlier version of this work appears in his thesis “Rewriting the Sensor Network Abstraction Stack”. Presented here is a revised version, with most of the revision focused on the evaluation of the framework. This chapter is based on: “The λMAC framework: redefining MAC protocols for wireless sensor networks”, T. Parker, G. Halkes, M. Bezemer and K. Langendoen, accepted for publication in Springer Wireless Networks.

43

44

THE λMAC FRAMEWORK

increased bug count due to multiple implementations of the same ideas (e.g. Unicast), and a system that is hard to extend, we conclude that the current design brief for MAC protocols has a number of significant problems, and so should be rethought. In this chapter we will set out an improved design brief for MAC protocols called the λMAC framework, and show how these principles can be implemented efficiently by demonstrating our example λB-MAC protocol. The same principles will then be shown to work for λ-layers implementations of T-MAC, LMAC, and Crankshaft, and we will show more data gathered from these protocols.

4.1

Rethinking MAC Protocols

We wish to redesign the process for creating a MAC protocol such that the common functionality that does not necessarily need to be in a MAC protocol itself can be separated out. The first step to achieving this is to determine what is common functionality, and what are MAC-specific requirements.

4.1.1

Existing Concepts

Before we can start rethinking the design process for MAC protocols, we need to look at the current state of the art. Current WSN MAC protocols are usually grouped in two different groups: TDMA protocols (LMAC [Hoe04a], TRAMA [Raj03], PEDAMACS [CE06], etc) and CSMA-based protocols (S-MAC [Ye02], T-MAC [Dam03], B-MAC [Pol03], etc). These two approaches are usually regarded as being very different. Even within each approach there are many different protocols that all do things in drastically different ways. However, despite the apparent differences, all of these protocols have one thing in common: they are designed to manage the available time in the radio medium in order to fulfil certain metrics while sending/receiving messages (latency, energy usage, etc). Specifically, all protocols do this by managing when a particular node can send messages. TDMA protocols do this by separating the available time into slots and allowing nodes only to send in their slot; CSMA protocols do this by making nodes perform carrier sense before sending (and in the case of protocols like S-MAC, also by waiting until the beginning of the next “frame”). In total, a MAC protocol must do three things: given an application wishes to send a packet, determine what time this node will be able to send; perform a message exchange to send the packet at that point; and transmit appropriate control packets to maintain MAC protocol operation, for example synchronisation messages.

4.1.2

Role Separation

We then looked at separating the large existing MAC protocols into 3 parts: below the MAC, above the MAC and a λMAC layer. This set of layers we refer to collectively as the MAC stack, and together they should do everything a traditional monolithic MAC layer would do on its own.

4.1

Application

RETHINKING MAC PROTOCOLS

45

Application

Demultiplexer

Transmission Traditional MAC Protocol

Multiplexer

λ MAC

Network time layer

Packet layer

Packet layer

Figure 4.1: A traditional MAC protocol vs. the λMAC protocol stack.

Our first task was looking at the modules required “below” the λMAC layer. Working from the conclusions of Section 4.1.1, we know that MAC protocols need to send/receive packets, and to decide when to send/receive. The former can be achieved with a “dumb” packet layer (no queueing, minimal latency, switches radio on/off only when told to); the latter requires medium activity detection (as part of the “dumb” packet layer) and/or a time synchronisation layer. Time synchronisation can also then be used to generate “frames” (periodic timers, as used by all TDMA protocols and S/T-MAC), but it would need to be designed such that it will not interfere with protocols that do not require time synchronisation (e.g. B-MAC [Pol03]). The biggest question regarding how much we can pull out of a standard MAC layer was deciding what a λMAC layer actually really needs to do. Or in other words, knowing what a complete MAC stack needs to do, what makes one MAC protocol different from another? Our conclusion was simple: time management. One of the standard opinions about the role of WSN MACs is power management, and time management can be considered an extension of this – one of the time management roles is deciding when to switch the radio on/off, but the other is deciding when to start sending a packet sequence. However, once a node has started a packet sequence (e.g. all of Unicast after the RTS message), the code becomes remarkably generic and MAC-portable, yet is currently still embedded within the MAC. What if we could extract that – let the MAC decide when to initiate packet sequences, but then hand off to a generic module to perform the actual sequence itself? This new transmission layer module could then be reused in other MAC protocols. Now that basic packet sending/receiving, time synchronisation, and the sending of particular packet sequences have all been separated out, the λMAC layer only needs to contain time management: that is, the maintenance of the knowledge about what time is a good time

46

THE λMAC FRAMEWORK

to send packets; allocating blocks of time as required by the transmission layer modules in order to allow them to both send and receive data; and switching the radio on/off as appropriate for the individual protocol. A block of time is simply an interval during which the radio is exclusively handed over to a particular transmission module which has previously requested that the λMAC layer give it n milliseconds in order to send a packet sequence; conversely time blocks are also allocated when a packet comes in informing the local node that another node will be performing a packet sequence for a short period from now and so the local node should not give the radio over to other transmission-layer requests for that time. Note that when we talk about a good time to send a packet, we imply that this is a time with a high probability that the destination node will be able to receive the packet, which is information that the λMAC layer needs to keep track of as part of its time management role.

4.1.3

Design Conclusions

Given our new formulation of a MAC protocol stack, we redefine the required modules and connections as follows (see Figure 4.1 for an overview of how these interact): Packet layer – responsible for the actual sending/receiving of a packet, radio state changes (Rx/Tx/sleep) and for providing carrier sense functions (for CSMA-based λMAC protocols). The sending/receiving radio state here is “dumb” – it does things right now, with no options for delay or smart decisions considered. In the case of byte-based radios, we also provide a platform-specific byte interface layer (which can only be talked to via the Packet layer), and for packet-based radios the Packet layer is a slim layer on top of the existing hardware capabilities. This allows us to abstract away from the differences of these two paradigms, as only packet-level information is required for the λMAC implementation. Network Time layer – responsible for storage and generation of time-synchronisation information to provide event synchronisation, e.g. frame timers. This is not required by all λMAC layers and therefore optional. However, there are several reasons to include the Network Time layer here. First, time-synchronisation information is useful to a large quantity of WSN MAC layers, due to the energy savings that can be made if nodes are able to agree when transmit/receive periods should be. Second, the information is potentially useful to other layers. Finally, doing accurate timing information above the MAC layer, given the uncertainty of timing in at least the 10-msec range above most WSN MAC protocols is very difficult. For these reasons, we designed the Network Time layer as a general service to the entire application stack. The Network Time layer can, through its placement in the stack, override the λMAC layer’s decisions on when to keep the radio in receive mode in order to do neighbour discovery. The overrides will make the radio be in receive mode more than it would be normally, but will not switch the radio off when the MAC wishes it to be on, or switch the radio from transmit to receive mode (or vice versa). The Network Time layer here provides the same interfaces as the Packet layer in addition to the Network Time interface in order to allow insertion of time-synchronisation

4.1

RETHINKING MAC PROTOCOLS

47

headers in packets on their way to/from the Packet layer itself. For more information, see Section 4.1.5. λMAC – responsible for time management. Allocates time blocks in response to requests

from the Transmission layer, at times that are considered to be “good”. Talks to the Packet/Network Time layer in order to send its own control packets, as well as for carrier-sense checking in order to determine if the radio medium is free for sending (for CSMA-based λMAC layers), and decides when to switch the radio on and off. Passes packet send requests/receive events from/to the Transmission layer to/from the Packet/Network Time layer, possibly adding and removing headers on said packets along the way. Given the roles now allocated to other layers, the λMAC layer will be considerably smaller than a traditional MAC layer. Multiplexer – (de-)multiplexer to allow for the λMAC to only provide a singular interface to the upper modules, yet talk to many Transmission layer modules. Transmission layer – contains the Unicast, Broadcast and other application-level primitives of this nature. Requests time blocks from the λMAC layer as required, and then sends packets during the allocated time. The transmission layer is fully explored in Section 4.2. Demultiplexer – provides the standard MAC interface to the application and hands off the packets from the application to the appropriate Transmission layer module. There is one limitation on the choice of MAC protocol for the λMAC layer: packet exchanges should performed in a contiguous block of time. To allow optimal flexibility, this block of time should be usable for both sending and receiving by a node. Most TDMA protocols restrict which nodes can send during a time slot, and therefore restrict which packet exchanges (and thereby transmission modules) can be used with such a protocol. Contention-based MACs generally do not have such restrictions and thus allow optimal flexibility in choosing transmission modules to use.

4.1.4 λ Interfaces As we wish to define common connections between the λMAC and Transmission layers to enable reuse of the Transmission modules, we need to define some standard interfaces for these connections. We use here the terminology of nesC [Gay03] to provide common semantics, and also because our reference implementation is implemented on top of TinyOS [Hil00]. There should however be no obstructions to implementing this with any other WSN software platform. All modules in the λMAC stack use the standard TinyOS Send and Receive interfaces for passing messages up and down the stack. Furthermore, we define the AllocateTime interface, which defines the necessary functionality for a Transmission module to allocate time from the λMAC layer. In general, a Transmission level module requires a single instance of the AllocateTime interface (see Table 4.1), plus one instance of the Send and Receive interfaces

48

THE λMAC FRAMEWORK

Name

Type

Arguments

Return

Function

requestBlock

command

uint16_t msec, am_addr_t to

error_t

requestSafeBlock

command

uint16_t msec, am_addr_t to

error_t

startBlock

event

void

cancelBlock

command

void

endBlock

event

sleepRemaining

command

sendTime

command

Request a period of msec milliseconds to send a message to to, which can be the broadcast address. A return value of FAIL indicates a persistent failure i.e. the requested period is too long. As requestBlock, but asks the λMAC layer to trade off increased latency for a better chance of success. Should only be called after a previous block has run to completion, but has completely failed i.e. no response has been received from any other nodes at all. Called on the successful start of a period. Always corresponds to the last call to requestBlock or requestSafeBlock. Cancel a previous requestBlock or requestSafeBlock request. Should only be called before the requested block has started. Called at the end of a period, where myStart indicates whether this was a block started at this node or a block initiated by another node’s packet. Switch the radio off for the remaining length of the AllocateTime period. This is intended for periods when there will be packets in the air, but none of them are destined for this node. Query how long a packet of length bytes should take to be transmitted with the relevant headers. firstPacket indicates if the packet will be the first packet in the packet sequence, which can be used by protocols using lowpower listening techniques to determine whether a long preamble will be used.

bool myStart

void

void

uint16_t length, bool firstPacket

uint16_t

Table 4.1: AllocateTime interface

4.1

RETHINKING MAC PROTOCOLS

49

per message type (e.g. the Broadcast module requires a single Send/Receive interface set, and a standard Unicast requires 4 Send/Receive interface sets (RTS, CTS, DATA and ACK)). The λMAC layer, however, only needs to provide a single instance of each of AllocateTime and Send/Receive to the Multiplexer module. The Multiplexer module provides generic multiplexing services to create a parametrised interface to both AllocateTime and Send/Receive, thus enabling the capability for multiple Transmission layer modules to be enabled in a single stack, without having to deal with the multiplexing complexity in each λMAC layer. Individual Transmission layer modules could be implemented using a single Send/Receive interface set per module. However for modules that require multiple message types (e.g. Unicast), the implementers of the Transmission modules would have to both add their own type field to the sent messages, and do de-multiplexing of the different types at the receiver side. As the Multiplexer module allows for multiple instances of Send/Receive already (in order to allow multiple Transmission modules in a single application), the Transmission layer protocol design can be simplified by using multiple Send/Receive interface sets, and this also removes the necessity for the overhead of an additional type field. The interface between the packet layer and the λMAC layer is much simpler, and as this is more in keeping with traditional WSN MAC design, we will not cover it in detail here. The Packet layer must provide interfaces to change the radio state (Tx/Rx/sleep), and also to send/receive packets using the commands and events of the Send and Receive interfaces. For a CSMA-based λMAC layer, the Packet layer will also require an interface to carrier-sense operations. As we stated before, the Packet layer is “dumb” in the sense that all of the smart decisions regarding when to send, to listen and to sleep are decided by the particular λMAC layer in use.

4.1.5

Network Time

In order for many MAC protocols to operate correctly, they require a mechanism to synchronise nodes so that differing nodes can agree on events happening at the same time e.g. synchronised awake times. Additionally, placing this between the packet layer and the λMAC layer also allows us to integrate time synchronisation information into each outgoing packet, thus reducing the need for additional control packets whenever we are sending other data packets. However, as we wish the Network Time layer to not override λMAC-layer decisions about when to send packets, in the case where we do not have a sufficient rate of outgoing packets to guarantee time synchronisation, the Network Time layer will send a packetRequired event (Table 4.2) to the λMAC layer requesting that it send a packet “soon” in order to maintain time synchronisation. In keeping with the idea of the Network Time layer as a generic layer, and also because we wish to provide information to modules other than the λMAC layer, we need to define the timing information appropriately. We started with the work of Li et al [Li05] on the global schedule algorithm (GSA), but then expanded it one step further. In GSA, nodes keep track of how much time has passed since they were switched on, and add this information to their outgoing packets. If a node sees an incoming packet with a greater age than the local age, the local age is updated to be the same as the incoming packet, thus allowing the network to converge towards a shared timing value based on the oldest (first switched-on) node’s age.

50

THE λMAC FRAMEWORK

Name

Type

Arguments

packetRequired

event

void

sendDummySyncPacket

command

void

isSyncPacket

event

message_t msg

Return

bool

Function Notify the λMAC layer that it should send a packet soon to maintain synchronisation. Request the time synchronisation module to send an empty packet for the purpose of time synchronisation, when the λMAC layer has no useful data to send. Ask the λMAC layer whether the message msg was useful to maintain time synchronisation. Only packets that are likely to be received by all neighbours should be indicated as such.

Table 4.2: TimeSync interface

Note that although we chose to use a synchronisation algorithm which results in a global network synchronisation, this is an implementation decision, not a decision resulting from the requirements of the design. In the original implementation of GSA, schedule information (time since last frame timer) was also distributed with the age value in order to calculate the correct current frame timer for the MAC protocol. In the λMAC framework, we have a separate TimeSync module, which is used by the λMAC framework as a storage location for the current local value of the age value, and a separate FrameTimer module which derives frame-timer events from this age value. The FrameTimer module provides periodic frame timers through the FrameTimer interface (see Table 4.3), to all application modules that require this capability (not just λMAC layers that need it) – e.g. for experiments that require an entire field of nodes to make a measurement at the same time (a commonly wanted requirement for many biological experiments being proposed for sensor networks). We do this by taking the age value modulus the frame length to provide a frame timer every time (localAge mod FrameTime) = 0. This allows the creation of multiple frame timers for different application modules, while only requiring synchronisation on the single age value. All of the periodic frame timers also have an allowable “fuzz” value: if because of updating the local clock, we jump over the time when we should have fired a frame timer, but we jump over by less than the “fuzz” value, then we fire the timer anyways. This bounds the acceptable jitter in the frame timer event. In the event we jump too far over the event point, the safest approach is usually just to skip the event entirely and wait for the next one (e.g. not doing a TDMA frame that is out of sync with the other nodes). This allows us to cope with small changes in the network clock due to varying speeds of clocks on different nodes.

4.2

TRANSMISSION LAYER MODULES

Name

Type

Arguments

Return

setFrameTime

command

uint32_t ms, uint32_t fuzz

void

clearFrame frameStart

command command

void uint32_t

frameIndex

command

uint32_t

globalTime

command

globaltime_t

frame

event

sanitystate_t sanity

void

frameGuaranteed

event

sanitystate_t sanity

void

frameSkipped

event

void

51

Function Set time between frame timers (msec milliseconds) as well as allowable fuzz time (fuzz milliseconds) Stop this FrameTimer Retrieve the local time at which the current frame started. Retrieve the time in milliseconds since the start of the current frame. Retrieve the current value of the network time. Indicates that the new frame has started. sanity indicates whether the network time layer has fully synchronised or is still in one of the start-up phases. Indicates that fuzz milliseconds have passed since the start of the frame. Arguments as frameGuaranteed. Indicates that one or more frame events have been skipped due to network time re-synchronisation.

Table 4.3: FrameTimer interface

4.2

Transmission Layer Modules

In this section we will look at how to implement Transmission layer modules, with a focus towards the standard set of WSN Transmission modules on top of the λMAC layers i.e. the set of functions that would be expected from a standard MAC protocol. An exploration of what can be done with non-standard modules is in Section 4.5.

4.2.1

Notes on Transmission Module Design

Before we go into a more detailed look at how to build basic Transmission modules, a number of features of the AllocateTime interface should be noted: • The point of an AllocateTime period is to grab time in order to send packets, with a reasonable guarantee about our neighbours being in a state where they are able to receive our packets. A node does not need to be in an AllocateTime period for any other purpose.

52

THE λMAC FRAMEWORK

• The AllocateTime period (as marked by a startBlock() event) is only started when the λMAC layer deems it appropriate to start sending. In CSMA-based protocols this will be determined via a carrier sense mechanism of random length (to resolve contention issues between multiple nodes wishing to start AllocateTime), and in TDMA-based protocols this is dictated by the time slot mechanism. • The λMAC layer will piggyback information about the remaining AllocateTime period on outgoing packets, in order to place other nodes into the AllocateTime state as well. If the MAC protocol implemented uses a slot structure, this may be avoided as the allocation will always be for an entire slot. • Once an AllocateTime period is started, it cannot be stopped. This is because of the difficulty of telling other (possibly asleep) nodes of this change of plans. A node can be told to go to sleep for the rest of the time period however (via sleepRemaining()).

4.2.2

Broadcast

Broadcast is simply implemented on top of a single set of Send/Receive and AllocateTime interfaces. Sending is implemented as follows: 1. Call requestBlock() for sendTime(packet length, true) milliseconds. 2. On startBlock(), call send(). 3. On sendDone(), call sleepRemaining(). 4. On reception, call sleepRemaining() as no other packets will be forthcoming in this period. The receiving node can determine the remaining length of this period from the message it received.

4.2.3

Unicast

Unicast is somewhat more complicated than Broadcast, partly because it can have variants both with and without RTS/CTS. For the case with RTS/CTS, an example implementation runs as follows. During the initialisation of this module, we calculate the time it takes to send each of the control packets. We calculate this by asking the lower layers how long it takes to send a packet with only the control information required by those lower layers. This is achieved by calling sendTime with a zero packet length in the Multiplexer layer, which will in turn use the sendTime call in the λMAC layer etc. As the RTS packet will be the first packet of the message exchange, we set the firstPacket parameter of the sendTime function to true for RTS, and false for both the CTS and ACK packets. To send a packet, we first calculate the time needed to send the packet itself by calling the sendTime(packet length, false). Then we add the previously calculated durations for the RTS, CTS and ACK packets, and some platform-dependent allowance for processing and radio state transition delays. We then call requestBlock() with the calculated time to complete the packet exchange. On startBlock() , we start to cascade through the RTS/CTS/DATA/ACK

4.3

INTEGRATING EXISTING MAC TYPES

53

Listen Timing

Continual

Scheduled

B−MAC

Send Timing

Carrier Sense

Crankshaft

T−MAC

Scheduled

LMAC

Figure 4.2: WSN MAC protocol division.

sequence i.e. we send an RTS packet using send(), wait to receive a CTS, then send a DATA packet with send(), then wait to receive the ACK. After receiving the ACK packet, we tell the λMAC layer to sleep for any remaining time in the block. At the receiver node, we first see a receive() with an RTS packet. If the RTS packet is destined for the receiving node it sends a CTS packet. Then, the receiver waits for a DATA packet, sends an ACK packet and calls sleepRemaining() in order to go to sleep for any remaining left over processing time. Other nodes that are not the destination for this Unicast sequence will go to sleep by calling sleepRemaining() after receiving the initial RTS packet. This is a simplified description for an example Unicast module, and our complete implementation includes retries for lost/missed packets. However, it gives a flavour of how Unicast can be implemented on top of the λMAC layer.

4.3

Integrating Existing MAC Types

Now that we have shown how we intend to split up existing monolithic MAC protocols into a more generic and reusable stack (Section 4.1.3), and described how that stack works (Sections 4.1.4, 4.1.5 and 4.2), we need to go back and show that all of this can work with existing MAC protocols. We divide WSN MAC protocols into 3 groups; dividing first into continual listening vs. scheduled, and then further divide scheduled listening protocols into how they decide when to send – carrier sense vs. scheduled (see Figure 4.2 for a diagrammatic view of this). We have implemented a protocol for each of the groups to demonstrate the flexibility of the λMAC framework. For the continual listening group we implemented B-MAC [Pol03], the standard TinyOS MAC protocol. For the scheduled listening with carrier-sense based send timing group we implemented both T-MAC [Dam03] and Crankshaft [Hal07]. In the scheduled listening and sending group we implemented LMAC [Hoe04a], a TDMA protocol. We believe that by showing that these protocols can be implemented with the λMAC framework, and by providing data from experiments on our testbed using these protocols, we adequately demonstrate that the λMAC framework is suitably generic to serve as a base for implementing a large portion of currently proposed WSN MAC protocols.

54

THE λMAC FRAMEWORK

In the remainder of this section we describe how we implemented the distinguishing features of the four implemented protocols. We will also show how the concept of time allocation maps to the scheduling mechanisms in the selected MAC protocols.

4.3.1 λB-MAC B-MAC is a prominent example of the continual listening group, which uses the Low-Power Listening (LPL) technique to save energy. The LPL technique requires periodic sampling of the medium, and long preambles on the first message of a message sequence. The physical layer provides an interface to change the preamble length at run time, such that the long preamble required by protocols such as B-MAC can be generated. The periodic sampling of the medium is not directly supported by the λMAC framework, but can be easily implemented using a timer and the carrier-sense primitive provided by the packet layer. We have decided not to implement the periodic sampling as part of the physical layer as it is too MAC-protocol specific, and different preamble sampling MAC protocols use different sampling strategies. λB-MAC should also provide the same contention resolution mechanism as B-MAC. This means it can start sending at any time, provided it performs carrier-sense and random back-off first. However, in the case of λB-MAC, once a node determines that it has won the contention it does not start sending itself, but instead signals the requesting transmission module that its block has started through the startBlock() call. λB-MAC will then wait for the block to end. The transmission module will in the mean while ask the λB-MAC protocol to send a message for it. λB-MAC appends its own header, after which it will pass the message on to the packet layer immediately. When transmission modules are used that mimic the packet sequences used by the B-MAC protocol for broadcast and unicast, the behaviour of the MAC stack with the λB-MAC protocol will be as described for the B-MAC protocol. A final feature of the B-MAC protocol is that it allows on-line tuning of the sampling interval by higher layers in the protocol stack. Although we have not implemented this feature it could easily be added as an additional interface implemented by the λB-MAC protocol itself. This is much like the monolithic implementation which also has an additional interface, next to the standard MAC protocol interface, which allows such tuning.

4.3.2 λT-MAC T-MAC is a CSMA-based MAC protocol, derived from S-MAC [Ye02], but with adaptive duty cycling (see Section 2.2 for details). We used the frame timers from the Network Time layer to assume a lot of the complexity from T-MAC. A significant part of the code of an existing T-MAC implementation was dedicated to schedule synchronisation, including discovery of new schedules; a role now subsumed by the Network Time layer. Another reduction in complexity stems from the removal of the packet exchange logic, which is now performed in the transmission modules. Instead of passing a request to send a packet to T-MAC, a requestBlock() call is made requesting a block of time to perform a packet exchange. λT-MAC will then go through all the steps a T-MAC implementation would go through to determine when to send the RTS message, at which point it will signal the startBlock() event to the transmission module. The transmission module will then handle the packet exchange, leaving the

4.3

INTEGRATING EXISTING MAC TYPES

55

λT-MAC with nothing to do except passing send and receive calls between the transmission

module and the packet layer. If λT-MAC gets a packetRequired event (a request from the Network Time layer for a packet to be sent), λT-MAC sends out a Sync packet – a packet with no actual data payload, and only containing timing information in order to maintain the inter-node time synchronisation.

4.3.3 λLMAC LMAC [Hoe04a] is a TDMA-based MAC protocol, aimed at giving WSN nodes the opportunity to communicate collision-free, and at minimising the overhead of the physical layer by reducing the number of transceiver state changes. The LMAC protocol is self-organising in terms of time slot assignment and synchronisation, starting from a sink node (specified by the application). To allow distributed slot assignment, each node participating in the frame schedule advertises the slot occupancy of itself and its one-hop neighbours. Upon start-up, the sink node sets a frame schedule and chooses the first slot in the frame as its sending slot. Next, one-hop neighbours receiving the sink’s transmissions, choose their sending slots based on the frame schedule of the sink node and the advertised slot occupancy. This is then repeated for all next-hop neighbours. Mobility is handled through collision detection by neighbouring nodes, which will subsequently advertise the detected collision, forcing the nodes involved in the collision to redo the slot selection. When an application wants to send a message, LMAC delays the transmission until the start of the node’s next sending slot. We created a TinyOS implementation of λLMAC based on the protocol description and the OMNeT++ code available from the LMAC authors. For time synchronisation between the nodes, we used the Network Time layer, and so were able to use a frame timer to determine the start of each slot. This way, all nodes agree on the exact start time of all slots. When using a frame timer to determine only the start of each LMAC frame, intermediate clock updates during the frame may lead to inaccurate start times of slots near the end of an LMAC frame. Although λMAC supports sending multiple packets in a single slot, in LMAC it is only possible for a node to transmit a single message per frame. The authors suggest gluing together multiple messages to the same destination to prevent high latency, but this suggestion is not implemented in the available OMNeT++ program code. To make our results comparable to the OMNeT++ implementation we had available, we did not implement this feature. On a requestBlock() call, λLMAC sets a flag indicating that there is a packet waiting to be sent at the node’s next time slot. During its time slot, a node will always transmit a packet. If a node has no data to send, an empty Sync packet is sent to keep the network synchronised and to keep a claim on the slot. Otherwise λLMAC signals startBlock() and waits until the end of the time slot to call endBlock(). Since a TDMA-based MAC-protocol does not need the full Unicast RTS/CTS/DATA/ ACK sequence to keep other nodes from transmitting at the same time, we created a Unicast module that only sends the DATA packet. As the TinyOS message header already contains information about destination node and packet length, this information was removed from the LMAC-specific header.

56

THE λMAC FRAMEWORK

Protocol

Parameter

Value

B-MAC LMAC

Sleep time Number of slots Slot length Number of unicast slots Number of broadcast slots Slot length

85 msec 32 50 msec 8 2 48 msec

Crankshaft

Table 4.4: Protocol parameters as used during the experiments. λMAC and non-λMAC ver-

sions use the same parameter values. Time values are in binary milliseconds.

4.3.4 λCrankshaft The Crankshaft protocol, as described in detail in Chapter 3, uses the frame and slot structure of TDMA protocols like LMAC, but instead of scheduling the senders to eliminate contention all together, it schedules receivers to limit contention. As far as implementation using the λMAC framework is concerned the most distinguishing feature is that the correct moment to contend and send depends on the destination (owing to the receiver scheduling). This feature requires that when a block is allocated, the destination is also made available to the λCrankshaft implementation. Crankshaft uses a simple DATA/ACK message sequence which is readily implemented using our stock Unicast Transmission module.

4.4

Testing

We performed a series of tests comparing the λMAC versions of B-MAC, T-MAC, LMAC and Crankshaft to other implementations. In the case of λB-MAC we compare against the standard TinyOS B-MAC implementation. Although we have a TinyOS 1 implementation of T-MAC, it does not perform to an acceptable level to allow proper comparison. Therefore, for T-MAC, as well as for LMAC and Crankshaft, we had to resort to comparing against simulation results. Using simulations limits us to studying whether the λMAC implementations show similar degradation patterns under load, rather than allowing us to study their exact behaviour. However, we are forced to use simulations as no independent implementations are available for these protocols. This also illustrates one of the problems we hope the λMAC framework will alleviate: the lack of real-world implementations of MAC protocols. To simulate the T-MAC, LMAC and Crankshaft protocols, we use the same OMNeT++ based MAC protocol simulator used in Chapter 3. We do not compare against TOSSIM, as we only have our own λMAC framework implementations for TOSSIM and our goal is to check against a different implementation of the same protocol, so as to verify the correct operation of our λMAC implementations. All real-world experiments are performed on our 24 node testbed (described in Chapter 5). The nodes in our testbed are mica2 class nodes, with Atmel ATMega128 processors and CC1000 radios. Table 4.4 show the parameters used for the different protocols for all our

4.4

TESTING

57

1

Delivery ratio

0.8 B-MAC (standard) λB-MAC T-MAC (sim) λT-MAC

0.6 0.4 0.2 0 0

0.5

1

1.5

2

Broadcast node message rate (msg/node/sec)

Figure 4.3: Unicast communication test between two nodes surrounded by broadcasting nodes.

tests. The simulator has been set to match both the hardware and software characteristics as closely as possible. Both simulations and real-world experiments are performed five times and experiments last 360 seconds.

4.4.1

Testbed Results

We tested the implementations of λB-MAC, λT-MAC, λLMAC and λCrankshaft on our full testbed. At the default transmit power setting, our testbed is a single cell network of 24 nodes. First of all we perform a benchmark test, in which two nodes A and B communicate with each other while the other nodes are sending broadcast packets. Nodes A and B send at a fixed rate of one message per two seconds, while the message rate of the broadcasting nodes is varied. We measure the packet success rate as the success rate for packets between A and B, ignoring all other packets. Figure 4.3 shows the result for the λB-MAC and λT-MAC, as well as the results for the standard TinyOS B-MAC protocol on our testbed and simulation results for T-MAC. We have omitted the graph with the results for λLMAC and λCrankshaft because, as expected, they show (almost) 100% reception for all broadcast-node message-rates. As can be seen in the figure, the standard B-MAC implementation outperforms the λB-MAC implementation by a small margin for low contention. However, as the contention increases, λB-MAC starts to outperform the standard B-MAC approximately 17% percentage points. In our original test runs the delivery ratio of the standard B-MAC implementation dropped to almost zero due to a bug in the dynamic noise-floor algorithm, which caused B-MAC to consider all transmissions as background noise when channel utilisation was high. The results shown in this chapter are the results with the bug fixed. The remaining performance gap is likely due to a contention anomaly which causes extra collisions under high load that λB-MAC avoids.

58

THE λMAC FRAMEWORK

1

Delivery ratio

0.8 0.6 0.4 B-MAC (standard) λB-MAC T-MAC (sim) λT-MAC

0.2 0 0

0.5

1

1.5

2

Message rate (msg/node/sec)

1

Delivery ratio

0.8 0.6 0.4 LMAC (sim) λLMAC Crankshaft (sim) λCrankshaft

0.2 0 0

0.5

1

1.5

2

Message rate (msg/node/sec)

Figure 4.4: Unicast test.

The results for the T-MAC protocol show that the λT-MAC implementation shows a similar curve as the simulation-based T-MAC implementation. As the simulator uses a simple SNR based radio model with free-space propagation, it is expected that the simulation results are better than the real-world results. However, we do expect that both curves show similar decay in delivery ratio, as we see in the figure. As a second test, we let all the nodes in the testbed send to a single node. The results are plotted in Figure 4.4. The top graph shows the same protocols as before. Again the simulated T-MAC implementation outperforms the λT-MAC implementation, but shows a similar drop in delivery ratio.

4.4

Sender A

Preamble

Receiver

Preamble

59

Data A

Preamble

Sender B

TESTING

Data B

Collision

Data B Preamble

Figure 4.5: Two partially overlapping B-MAC packets cause a single packet to be received.

S

Figure 4.6: Hidden-terminal setup.

The λB-MAC implementation and the standard B-MAC implementation show almost identical delivery ratios. Even though the clear channel assessment in the standard B-MAC implementation is not optimal, in this scenario it is not so much of a problem. If two messages partially overlap, the second message will still be received (cf. Figure 4.5). For the unicast test this counts as one successfully received message. In the previous test such collisions cause problems if the first message is a unicast message and the second message is a broadcast message, as only the unicast messages count for the delivery ratio. This explains why for the unicast test the standard B-MAC implementation does not suffer a large performance hit at high contention. The bottom graph in Figure 4.4 shows the results for λLMAC and λCrankshaft. For the LMAC protocol the graphs for the simulated LMAC and λLMAC are virtually the same. As the LMAC protocol does not use a contention resolution algorithm, the only impact the channel model has is in message detection and correct transmission. Because our testbed is a single cell network in the default configuration, the chance of incorrect transmission is minimal. The only factor determining the delivery ratio of the LMAC protocol is therefore the maximum throughput. As the simulator was set to match the the real nodes as closely as possible, it is no surprise that there is hardly any difference in delivery ratio between simulation and real life. In the Crankshaft protocol results we see a similar sudden drop in performance as we see in the LMAC protocol result. Again this is caused by bandwidth limitations inherent in the protocol. The Crankshaft protocol does use a contention resolution algorithm which relies on a correct clear channel assessment and low contention to get a 100% delivery ratio. Because the test is set up in such a way that all nodes generate their messages at the same time, there is always a limited contention. The simulated version has a perfect clear channel assessment, which explains the slightly better performance compared to the λCrankshaft protocol.

60

THE λMAC FRAMEWORK

1

Delivery ratio

0.8 0.6 0.4 B-MAC (standard) λB-MAC T-MAC (sim) λT-MAC

0.2 0 0

0.5

1

1.5

2

2.5

3

3.5

4

3.5

4

Message rate (msg/node/sec)

1

Delivery ratio

0.8 0.6 0.4 LMAC (sim) λLMAC Crankshaft (sim) λCrankshaft

0.2 0 0

0.5

1

1.5

2

2.5

3

Message rate (msg/node/sec)

Figure 4.7: Hidden-terminal test results.

Finally we performed a small hidden-terminal test with five nodes. The setup is shown in Figure 4.6. The four unmarked nodes all send unicast messages to the sink node (S). Nodes on opposite ends of the sink node cannot directly communicate. For carrier-sense based protocols, this situation presents problems because the “hidden nodes” are not aware of each others transmissions and thereby cause collisions. We chose this simple setup because it can be replicated in our simulator. Figure 4.7 shows the delivery ratio for the different protocols. The figure shows that the carrier-sense based protocols λT-MAC and λCrankshaft perform better than their simulated counterparts. This is most likely due to the fact that even though the “hidden nodes” in the testbed cannot successfully receive messages, they can in

4.4

40

61

Sender Receiver

35 Current consumption (mA)

TESTING

30 25 20 15 CW RTS CTS DATA ACK

Timeout

10 5 0 3.18

3.2

3.22

3.24

3.26

3.28

3.3

3.32

Time (s)

Figure 4.8: Power trace from a run using the λT-MAC protocol.

some cases detect the ongoing transmission through signal strength measurements. As in the first experiment, λB-MAC outperforms the standard B-MAC due to better clear-channel assessment. Because the LMAC protocol does not depend on carrier sensing, the λLMAC protocol and the simulated LMAC protocol again show very similar performance. From these experiments we conclude that the λMAC implementations of the tested protocols properly implement the protocols.

4.4.2

Power Test

To further demonstrate the correct working of the protocols, we used the power tracing capability of our testbed. As an example, we include a trace of a λT-MAC packet exchange in Figure 4.8. The only difference with power traces from previous implementations like for example in [Dam03] is that nodes briefly switch off the radio after the exchange is complete. This is an artifact of our unicast transmission module, which tells the MAC layer it may go to sleep once it has sent/received an ACK message. As other nodes should not be sending until the block is complete this has no impact on further message exchanges. After the message exchange we can see the wait for activity before the radio is turned off, which is characteristic of the T-MAC protocol. We do not show the traces for the other protocols as they provide limited value over the λT-MAC trace.

4.4.3

Code Size

Next, we examine the lines of the code for the different MAC layer implementations. For this evaluation we can use the original TinyOS 1 implementation for T-MAC as a comparison as bug-free operation of the protocol is not required for this comparison. We have verified that

62

THE λMAC FRAMEWORK

Protocol B-MAC λB-MAC T-MAC (TinyOS 1) λT-MAC λCrankshaft λLMAC λMAC transport & multiplexing λMAC time synchronisation

SLOCCount 499 324 1090 330 523 426 775 431

Table 4.5: Lines of code in the implementation of the tested protocols.

the interfaces above and below the MAC protocol are similar to those in TinyOS 2, to ensure that the comparison is fair. However, the numbers for the TinyOS 1 implementation should be seen as a careful estimate rather than an precise measure. First we look at the lines of code required to implement the protocol. We use this measure, as it is a measure of the effort required to implement the protocol. Table 4.5 shows the number of lines of code as counted by the SLOCCount utility [Whe01] for the tested protocols. For the standard B-MAC implementation we counted the lines for all the modules above the packet layer interface (i.e. CC1000CsmaP.nc and CC1000ActiveMessageP.nc). The same holds for the TinyOS 1 T-MAC implementation. For the λMAC protocols we only count the parts specifically implementing the functionality of the protocol, and not the shared parts of the λMAC framework. Again, this is because we are interested in the implementation effort required for the protocol, not the MAC stack as a whole. The lines of code of the λMAC framework (excluding the packet layer) are listed in the table as well. The time synchronisation is listed separately because it is an optional component. The λB-MAC implementation for example does not use the time synchronisation module. The λMAC implementations are significantly smaller than their monolithic counter parts. The λB-MAC implementation is 35% smaller and the λT-MAC implementation is 70% smaller. Because the B-MAC protocol does not include any form of time synchronisation, the code size gain obtained by using the λMAC framework is smaller than it is for the T-MAC protocol which does include time synchronisation. For the λCrankshaft and λLMAC implementations we do not have monolithic implementations. However, what the the table does show is that even a complex protocol like Crankshaft can be implemented within the λMAC framework with relatively little effort. From the lines of code comparison in Table 4.5 we can also see that the flexibility of the λMAC framework and the reduced per-protocol complexity comes at the expense of a larger total lines of code for the MAC stack as a whole. However, lines of code only indirectly translate to RAM and ROM size. Therefore we also compare the RAM and ROM size of a minimal program that includes the MAC layer (see Table 4.6). Note that contrary to the lines-of-code comparison, the numbers in Table 4.6 include the size of the λMAC stack.

4.4

Protocol

RAM

ROM

B-MAC λB-MAC T-MAC (TinyOS 1) λT-MAC λCrankshaft λLMAC

164 249 538 ∗ 381 409 611

9114 11664 17514 16320 17158 16120

TESTING

63

∗ After correction for serial stack and packet-layer buffers

Table 4.6: RAM and ROM sizes in bytes of the same empty application for different MAC

protocol implementations.

What is immediately clear is that λB-MAC uses 52% more RAM than the standard B-MAC implementation. The actual λB-MAC module only uses 9 bytes of memory for state variables. The overhead is therefore mainly due to the λMAC framework modules. The most important source of overhead is in the unicast module. The unicast module incorporates a message buffer which is used to send control messages. In the case of λB-MAC it is used as an ACK message. The standard B-MAC implementation has a hard coded ACK sequence which also does not include any information about the message that the ACK was sent in response to. Therefore it can store this sequence (5 bytes) in ROM rather than keeping a 44 byte message buffer in RAM. Other significant overheads introduced by the λMAC framework are bitmaps and tables in the multiplexer (16 bytes), and state variables in the unicast module (12 bytes). Analysis of the causes of the difference in ROM size is thwarted by the inlining employed by the compiler. The RAM size for the TinyOS 1 T-MAC implementation shown here is after correction. In TinyOS 1, the radio stack and the serial stack cannot be enabled and disabled separately. The serial stack uses approximately 130 bytes of RAM. Furthermore, the packet layer used in the TinyOS 1 T-MAC implementation uses an extra 94 bytes in packet buffers that the TinyOS 2 packet layers do not. Including these extra overheads would distort the comparison. Of course the different TinyOS versions already distort the comparison somewhat, but that cannot be avoided. The ROM size cannot be easily corrected for the inclusion of the serial stack due to the inlining performed by the compiler. Closer inspection of why the TinyOS 1 T-MAC implementation uses more memory than the λT-MAC implementation revealed that the monolithic implementation includes three packet buffers more than λT-MAC. These packet buffers account for 134 bytes, which leaves a difference of only 23 bytes between the two implementations. The remaining difference can be mostly attributed to the different TinyOS versions used, but the exact variables are hard pinpoint exactly. The overall picture that arises from these RAM and ROM size numbers is that the less complicated the protocol, the larger the overhead incurred by the λMAC implementation. However, the overhead is not very large. Even in the case of the relatively simple B-MAC protocol, the overhead in RAM size is limited to only 85 bytes. For the more complex T-MAC

64

THE λMAC FRAMEWORK

Experiment Idle Idle (optimised) Send Send (optimised)

Overhead 225.2% 5.2% 80.2% 2.9%

Table 4.7: CPU cycle overhead for λB-MAC, with and without radio switching optimisation.

protocol, the overhead is negligible. Whether the small increase in ROM size is acceptable depends on the hardware platform and the application.

4.4.4

CPU-Cycle Overhead

Generally, the flexibility offered by using a framework rather than creating a monolithic implementation comes at a price. As we have seen in the previous section, using the λMAC framework incurs an overhead in RAM and ROM use. In the context of sensor networks another important factor is energy consumption. The two main energy consuming parts of a sensor node are the CPU and the radio. In this section and the next we therefore quantify the overhead of the λMAC framework with respect to CPU and radio use. Because we have two TinyOS implementations of B-MAC, we can perform detailed comparisons. First of all, we compare the CPU overhead for the λB-MAC protocol compared to the original B-MAC protocol implementation. We use the Avrora emulator [Tit05] to get accurate CPU cycle counts. We have tested two situations: first, we compare the cycles used when there is no communication taking place. Second we look at the situation where a node is sending. Both tests are the result of taking the cycle count over a 20 second period. In the send test, the node was sending one message per second. Unfortunately, Avrora does not simulate the RSSI output of the CC1000 radio, which means that the channel polling will always detect an idle channel. As a result, we cannot provide CPU overhead numbers for a receiving node. Table 4.7 summarises our results. The CPU cycle test results show a significant overhead for λB-MAC in the idle test, and to a lesser extent in the send test. Closer examination of the results showed that the original B-MAC employed an optimisation in the radio switching. Instead of switching the radio on completely for channel polling, it only switches the radio on to the state where RSSI measurements can be taken. Because the timing during the radio switches is done through busy waiting, only performing part of the radio state switch uses fewer cycles. Integrating such an optimisation into the λMAC framework in a generic way is possible, but would require more complicated interfaces to the radio. The benefits of this optimisation are limited to a single radio chip, which does not justify the extra complexity in the framework. However, we have implemented this optimisation in a separate version of the λB-MAC protocol, such that we can provide a better estimate of the overhead induced by the λMAC framework. The results show that λB-MAC could in principle be almost as CPU cycle efficient as the original

4.5

FURTHER TRANSMISSION MODULES

Protocol

Average Rate

B-MAC

9.0 (msg/sec) 8.8 (msg/sec)

λB-MAC

65

Table 4.8: Average maximum broadcast rate for B-MAC and λB-MAC.

Protocol

Sender

Receiver

Average

B-MAC λB-MAC

15.4% 13.6%

7.4% 8.0%

11.4% 10.8%

Table 4.9: Average radio duty-cycle for one node sending unicast messages to another node,

using B-MAC and λB-MAC.

B-MAC, indicating that the λMAC framework does not introduce a significant CPU-cycle overhead.

4.4.5 λB-MAC Micro Benchmarks Next we performed two micro benchmarks with the two TinyOS B-MAC implementations. First of all we setup two nodes, one receiver and one sender node. The sender simply tried to send as many broadcast packets as it can in 50 seconds. Both the original B-MAC and the λB-MAC implementation approach the theoretical maximum of approximately 10 messages per second, and there is only a small difference between the two implementations (cf. Table 4.8). Second, we measured the average radio duty-cycle for the same two nodes, sending unicast messages from one node to the other at a rate of one message per second. Table 4.9 shows the average radio duty-cycle over 590 seconds for the sender, the receiver, and the average of both nodes. Again, both the standard B-MAC and λB-MAC implementations perform very much the same.

4.5

Further Transmission Modules

In this section we look at some Transmission modules that can be implemented on top of the λMAC layer that would not be considered part of a standard MAC protocol, but would provide useful additional primitives for other applications. Notably, these would be nontrivial to add to most normal MAC protocols, as we would either have to try and build them out of Broadcast and Unicast operations, which would be significantly sub-optimal; or we would need to rebuild the MAC entirely. Our modular approach makes these additions not only possible, but relatively easy because they are no longer integrated with the other parts of the MAC protocol. The implementation of one transmission module is completely separate from all other transmission modules, while in most MAC protocols all possible message

66

THE λMAC FRAMEWORK

Acknowledgements Data

3

2

4

1

Time

Figure 4.9: Example ExOR packet time-line

exchanges are encoded in a single state machine. Furthermore, we only need to implement the functionality once as a transmission module, rather than in each MAC protocol separately, significantly reducing development effort.

4.5.1

ExOR

ExOR (Extremely Optimistic Routing) is a “one send, many replies” approach to reliable multicast for routing protocols. It was first explored by Biswas and Morris [Bis04], and an extended version was proposed in the Guesswork routing protocol [Par05]. Both variants can be implemented on top of the AllocateTime interface, but would require significant effort to implement inside existing MAC protocols. An ExOR sending node sends a packet that not only contains the data for the packet, but also a list of other nodes that should respond (in the order that they are meant to respond in). Every node that is in the list that receives the packet waits sufficient time for all of the earlier nodes in the list to respond, and then sends an ACK to the sender node (see Figure 4.9). This can be used for a number of things – for example, implementing Reliable Broadcast, as the sending node knows that all nodes that it receives an ACK from have received the packet; or making a best-effort next-hop transfer in a routing algorithm (by using the ACKs to implement an election mechanism to pick the “best” possible next-hop node that has correctly received the original packet). From the point of view of implementing ExOR as a Transmission layer, it can be considered as a variant of Unicast, with no RTS/CTS and a series of receiver nodes, all of which need to pause a variable amount of time before sending their ACK packets, and then call sleepRemaining() to avoid overhearing the remaining ACKs.

4.5.2

Priority Queueing

Another possibility that arises once the λMAC layer has been implemented is an option that has been requested by various applications, namely priority queueing [Lor04; Tal06] – allowing for messages to be sent out in an order different from that which they were received (either from other nodes in routing scenarios, or events from local sensors). In standard MAC protocols, the “send” method is a fire-and-forget concept i.e. once the “send” has been called, cancelling the message (or even being aware of whether the message is queued or actually being sent right now) is impossible. The TinyOS AMSend and Send interfaces do provide a

4.6

RELATED WORK

67

cancel command, but the specification allows too much freedom in implementation such that building priority queueing on it cannot be done reliably. Using the λMAC layer, a priority queue can be implemented. By using the cancelBlock() call, a previous request to the λMAC layer can be revoked, after which a different block can be requested. Priority queueing would change the default MAC interface semantics in the sense that currently a MAC protocol would not accept a new packet before the last packet was completely handled. However, when using priority queueing, the MAC stack would have to accept more than one packet. Also, an interface should be provided for the priority queue to determine which packet to send first.

4.6

Related Work

At some levels, the core concepts of λMACs vs. traditional MAC protocols can be viewed as similar to the micro vs. macro-kernel debate in more conventional operating systems. In common with micro kernel design [Eng95; Ras89], the λMAC layer is able to separate out parts of a WSN application that would normally be considered a very complex part of the system (as both MAC layers and operating system kernels in general tend to be regarded by many programmers as “here be dragons” areas of code), and these separated parts are then able to be altered with a significantly lower chance of affecting the rest of the code base. Polastre et. al [Pol05] proposed the Sensornet Protocol (SP) that provided a greater level of control to applications wishing to influence the choices made by lower level protocols. Their system created a much more horizontal design for differing levels of an application stack, as opposed to the more traditional vertical design in normal MAC protocols. This design allowed a lot of control at application-level, with the trade-off that an application was able to tweak core parts of the MAC layer that could potentially introduce significant instabilities in the MAC, unless the application was fully aware of how the particular MAC would react to those changes. In the λMAC design, applications have large quantities of control – they can allocate arbitrary blocks of time and do pretty much whatever they like during this time – but in a way that preserves the integrity of the λMAC layer, as it is able to delay AllocateTime requests until it is a “good” (for values of “good” defined by the individual λMAC layer) time for the application to have control. The λMAC separation of control, with most timing control out of the hands of the application designer, allows for cleaner, safer, and simpler design. The MAC Layer Architecture (MLA) proposed by Klues et. al. [Klu07] also provides a component-based architecture for WSN MAC protocols. MLA provides a set of modules implementing common MAC building blocks like channel polling and TDMA slot handling. The common building blocks identified by MLA are at the level of mechanisms and orthogonal to the role separation proposed in our λMAC framework. For example, different from our work MLA still requires the MAC implementer to manually code the packet exchanges into the MAC specific code, sacrificing flexibility. Ee et. al [Ee06] attempted similar goals as the λMAC framework, but for routing protocols. Their approach looked at providing a generic toolkit for building routing protocols, and for creating modules that could be used to piece together protocols, including the pos-

68

THE λMAC FRAMEWORK

sibility of new hybrid protocols built from parts of earlier protocols. Their wish to provide a toolkit as opposed to a framework design such as we proposed is possibly indicative of a wider variety of options in routing protocol design, as opposed to the relatively small set (time management) that we have identified here for MAC protocols.

4.7

Conclusions

We set out to redesign and rethink how MAC protocols are designed for WSNs, to create a new and improved design concept, and to modularise common functionality. We have managed to do this, and along the way also provide new capabilities and a refocused take on the role of a MAC in the WSN network stack. The reduction in the roles of a MAC protocol to its core feature of time management, by separating out the Network Time layer to provide node-wide time synchronisation, as well as the Transmission layer modules to allow for clean separation of the logic required for features like Unicast, has given a new look at an old topic. Through our testing we have managed to show that our initial attempt at a reference λMAC layer (λB-MAC) was able to achieve similar performance, both in terms of data rates and power usage, to a traditionally designed MAC protocol, but with a significant decrease in complexity. Lines of code is not always a good indicator of system complexity, but the reduction of duties required of λB-MAC vs. monolithic B-MAC is. Implementations of LMAC, T-MAC and Crankshaft within the λMAC framework show the λMAC framework’s flexibility. As it turns out, the TDMA-based LMAC protocol that we expected to be the most difficult case, was not so hard to implement. By implementing several significantly different MAC protocols, we have shown that our framework is sufficiently generic to be used by the wider community as a general-purpose MAC creation framework. Especially for experimental platforms, the importance of allowing people to extend existing work without having to reinvent the wheel cannot be overemphasised. We hope that one of the side effects of our creation of the λMAC framework will be the creation of more MAC protocol implementations for real hardware, as many new MAC protocols are currently only implemented in simulation. We feel that this is important because simulation is a poor guide to how something as low-level and radio hardware dependent as a MAC protocol will behave on real hardware.

The PowerBench Testbed

5

After implementing a MAC protocol, it is important to test it. To test the protocol in a realistic environment, the most convenient solution is to use a testbed. As energy efficiency is an important goal in designing MAC protocols for WSNs, it is important to be able to measure the energy consumption of all the nodes in the testbed. The PowerBench architecture described in this chapter provides that functionality. Using this functionality, we show that estimations based on a simple three-state radio model can be quite accurate.

One of the key characteristics that defines the field of Wireless Sensor Networks (WSNs) is the focus on energy consumption, and the efforts in reducing that to near zero levels, in order to reach the goal of being able to deploy large-scale networks built out of small, autonomous devices operating without human assistance. Typical WSN deployment scenarios involve nodes powered by small batteries, so (average) energy consumption must be limited to tens of µW to keep the recurring maintenance costs within economic feasibility when compared to the one-time installation costs of traditional, wired networks. As today’s sensor nodes consume in the order of mW when processing and tens of mW when communicating, the WSN research community has looked extensively at the problem of reducing energy consumption. Common approaches for achieving energy efficiency include duty cycling the radio at the MAC layer and sleep/awake scheduling at the routing/clustering layer. These can be very effective with researchers claiming energy savings of a factor of ten to a hundred – or even more– over conventional protocols like IEEE 802.11 (CSMA/CA). The true gains, however, remain to be determined as most results are based on simulations using coarse energy-consumption models; in the case of MAC protocols for example, one generally maintains statistics about what percentage of time the radio is used for transmitting, receiving, and listening (for incoming traffic) to compute the energy a node consumes by factoring in the current drawn in each particular radio state as specified in the data sheet. A slight improveThis chapter is based on: “PowerBench: A scalable testbed infrastructure for benchmarking power consumption”, I. Haratcherev, G. Halkes, T. Parker, O. Visser, and K. Langendoen, in International Workshop on Sensor Network Engineering (IWSNE), pp. 37–44. Santorini Island, Greece, June 2008.

69

70

THE POWERBENCH TESTBED

ment is to measure the power consumption of each state using an expensive oscilloscope hooked up to a node performing a ping-pong test. To the best of our knowledge, however, we are not aware of any experiments that verify that single-node consumption rates may be extrapolated to large, multi-hop networks. Until recently the WSN community heavily depended on simulation results; only 10 % of the papers mentions the term testbed, with an even smaller fraction actually using one for experimental evaluation. Fortunately, as WSN technology is maturing, the number of experimental testbeds is rapidly expanding, as well as the number of nodes within. Nowadays, testbeds with 100+ nodes are readily available (e.g., MoteLab [WA05], Kansei [Ert06], TWIST [Han06]), which provides researchers with a firm grip on the notoriously unpredictable wireless channel. In that respect the Deployment Support Network approach [Dye07] offers the unique possibility to exercise (and debug) protocols in real-world conditions by attaching wireless monitoring nodes instead of running cables to each sensor node. However, regarding the task of determining the energy efficiency of a protocol, none of the testbeds provide support to actually measure the power consumed by each node. In this chapter we present PowerBench, a scalable testbed infrastructure for benchmarking power consumption. PowerBench is centred around a low-cost interface board capturing the power consumption of a target Tnode (a Mica2 clone) in the testbed by means of a shunt resistor and an A/D converter (30 µA resolution). Up to eight interface boards are connected to a modified Linksys NSLU2 device (an embedded Linux platform) sampling the output of the A/D converters in parallel at a rate of 5 kHz. The samples are time stamped and sent out over an Ethernet backbone to a central host storing the power data of the complete testbed. Our current configuration consists of 24 nodes (4 rooms with 6 nodes each), generating a continuous feed of 180 KB/s. After each experimental run the power traces can be graphically displayed for detailed analysis, or processed into a set of per-node statistics (average power consumption, etc). Preliminary experience with the PowerBench testbed includes the surprising observation that crude three-level, timer-based estimations can match true, measured power consumption values within a few percent. This important result provides credibility to (unvalidated) estimation-based research performed on other testbeds and simulators.

5.1

Related Work

Due to a lack of tools, researchers initially resorted to ad-hoc solutions when quantifying the energy consumption of their algorithms and protocols. The focus was on accounting for the induced wireless communication as the radio is generally the part of a sensor node that consumes most energy. At higher levels in a protocol stack, simply counting the number of message transfers was considered good enough; at lower levels protocols were instrumented to record the time spent in each radio state in order to provide more accurate power-consumption estimates. Energy = ∑ Pstate j × tstate j (5.1) state j

The level of detail, i.e. the number of states would vary from a crude two (RX/TX), via a reasonable three (RX/TX/SLEEP), to an elaborate six or more when taking radio state transitions

5.2

TESTBED DESIGN

71

into account. Eventually, this approach found its way into mainstream network simulators like NS-2 [Kak05] and GloMoSim/Qualnet [Mar04], as well as WSN-specific simulators like PowerTOSSIM [Shn04], AEON [Lan05], and Prowler [Bar07]. Besides estimating the power consumption of the radio, both PowerTOSSIM and AEON also consider the other hardware components in a sensor node (e.g., CPU, sensors, and LEDs). The resulting level of accuracy was determined to be within 5 % (AEON) and 10 % (PowerTOSSIM) for a number of TinyOS applications running on a single node; AEON has the edge as it is emulating at the instruction level, while PowerTOSSIM performs a discrete event simulation at the basic block level. With the recent move to experimentation on testbeds, mainly inspired by the lack of realism regarding the simulation models of wireless channels, some testbeds like MoteLab include one node hooked up to a digital multimeter for accurately measuring the power consumption of that node. This single probe provides valuable insight into the actual behaviour of an application, but it is hard to expand the scope to the full testbed due to the costs of the measuring equipment. Some extrapolating, however, is possible by feeding the measured power consumption levels back into equation (5.1) while actually recording at each node the time spend in each state. A large-scale study is desired to determine the validity of this approach, which implies the need for low-cost, but accurate equipment to measure the power consumption of an individual node. We are aware of two dedicated hardware designs addressing this need. The first design, called SPOT [Jia07], uses the standard current sensing technique of putting a shunt resistor between the supply and the sensor node (MicaZ). The SPOT design is such that the measurements must be processed by the host sensor node that the SPOT board is attached to. This interferes with normal operation as counters must be read, and their values must be processed on-the-fly, which seriously compromises the usability of this approach. In contrast to SPOT, the approach by Milenkovic et al. [Mil05] is truly unobtrusive as they use a non-contact current probe (Extech 380946) in combination with a high-end data acquisition card (National Instruments DAQCard-AI-16XE-50). This setup allows for high accuracy and sampling rates, but only at considerable cost limiting the use to a single node only; the authors’ claim of using “inexpensive” equipment is not backed up by retail prices of US$ 230 and US$ 1500 for the current probe and acquisition card, respectively.

5.2

Testbed Design

The primary objective of designing the PowerBench infrastructure was to be able to measure the power1 consumption of all 24 nodes in our testbed, which translates into the requirement for a low cost solution. In Delft we are using Tnodes, which are similar to the familiar Mica2 nodes, in combination with a separate programmer board powering a Tnode and offering convenient wired access by means of an USB interface for programming and serial I/O. The idea was to re-design the programmer to provide the additional functionality of measuring the power consumption of the Tnode hosted by it. The target was to keep the costs of the additional components (e.g., A/D converter) below e 10, roughly 25 % of the total price of 1 We use power and current interchangeably in this chapter. As the nodes are operated at a constant voltage, there is only a constant factor between them.

72

THE POWERBENCH TESTBED

Ethernet

Linksys NSLU2 control

USB hub

USB hub

Linksys NSLU2 A/D sampling TNOdes 4

Figure 5.1: Testbed building block.

a programmer. This price increase would allow us to scale to any number of nodes in our testbed (see Section 5.3). Further requirements on the testbed infrastructure include a minimum accuracy and time resolution of the power samples, as derived from our objective to study energy-efficient MAC protocols. An effective carrier sense operation with the CC1000 radio takes about 0.5 ms [Pol04], so a sampling rate in the order of 5-10 kHz would suffice to observe these basic (shortest) events. As we want to limit the measurement errors to 5 %, and the base current drawn by an active Tnode is about 5 mA (CPU running idle, radio off), the sampling resolution must be below 250 µA. Capturing the ATmega 128L processor in sleep mode would be nice, but is not essential as the current drawn then drops to 30 µA rendering it insignificant for MAC protocols like B-MAC [Pol04] waking up every couple of hundred milliseconds. A final set of requirements is derived from the desire to process (view) the power data after it has been captured by the testbed. Such off-line processing requires accurate timestamping of (batches of) raw power samples, and (some) local processing would reduce the delay between measurement and time-stamping. Also, it is essential that the stream of power data can be aligned with the serial output of the Tnode such that internal protocol events can be used to “explain” particular power profiles. Again, the finest granularity of events is in the order of milliseconds, which translates to a time synchronisation in the order of 100 µs. Figure 5.1 shows the basic architecture of the PowerBench testbed. The central component is a pair of Linksys NSLU2 devices (a low cost, embedded Linux platform) accessible by Ethernet. One of them is used for controlling the application running on the Tnodes in the testbed; it can be instructed to install (flash) specific program images, start/stop execution, and handles serial I/O. The second Linksys device is dedicated to capturing the raw ADC samples produced by the modified programmer board (see below). Note that we initially planned to use a simpler design featuring only one Linksys device by reusing the USB interface chip on the programmer board to access the A/D converter in parallel with the serial

5.3

IMPLEMENTATION DETAILS

73

I/O. However, a hardware fault in the USB interface chip forced us to implement dedicated circuitry (wires + Linksys device) for handling the power data.

5.3

Implementation Details

The basic building block of the PowerBench infrastructure, a pair of Linksys devices (cf. Figure 5.1), can host up to 8 Tnodes and must be replicated to support larger configurations. For example, the current testbed installed into the ceilings of 4 rooms in our department consists of 24 nodes and 8 Linksys devices (one pair per room). Experiments can be started from any PC connected to the Ethernet backbone, with the power data being streamed back to the PC by the Linksys devices. Besides hardware the PowerBench infrastructure includes various software components to make it all work. There is software for controlling the execution of the application programs on the testbed, software for sampling the A/D converters, and a set of tools to process the recorded power consumption traces. In the remainder of this section we provide additional detail regarding these software components.

5.3.1

Runner Software

The software that controls the execution of application programs on the PowerBench testbed was designed to make the life of both user and administrator simple. In particular, the software is self configuring such that adding, removing, and replacing Tnodes and Linksys controllers can be handled automatically, i.e. the user can simply request execution on N nodes without further ado. For experimentation purposes, however, a user can request a specific set of nodes such that a measurement can be repeated with the exact same configuration. To rule out interference by other users executing another application on a different part of the testbed, users can lock the whole testbed for the duration of their experiments. The software consists of two parts: a server program running on each Linksys device and a runner program running on the user’s own computer. Software updates, which occurred frequently during the development of the testbed, are downloaded from a central repository. Protocol version numbers help to detect incompatible versions of the server and runner software. The runner program takes a single application image (compiled from TinyOS code for the Tnode target) and distributes that to the Linksys servers involved in the particular run. Each server then checks for all nodes attached to it if they need to participate, and if so inserts the node number (as TOS_LOCAL_ADDRESS) into a copy of the image and flashes that into the node. Next the server waits for a start command from the runner to reset the node and start capturing output (serial data or power traces). The start command is sent out as one broadcast packet over the Ethernet to ensure synchronised execution and data capture across all nodes in the run. All data is streamed back to the runner program at the user’s computer, who can then process the raw output. An example of the serial output is shown below: 11:1422736: 00 1A 00 1B 00 0D F4 33 00 1C 00 01 1E 2A 00:1432098: 7E 42 7D 5E 00 11 DE 0C 00 00 02 00 18 00 00 00 ... 00:1435625: 7E 42 7D 5E 00 11 DE 0C 00 00 14 00 17 00 00 00 ...

74

THE POWERBENCH TESTBED

00:1436718: 7E 42 7D 5E 00 11 DE 00:1436878: 0C 00 00 16 00 18 00 00 00 F0 00 17 00 D2 C1 7E 18:1513929: 00 00

The format of the data is . Time is measured in ticks of 1/10,000 seconds since the start of the program. The data is a simple byte stream and needs to be interpreted by the user. In the example above we can see a mixture of TOS_Msgs (delimited by 7E markers) and our own UARTDebug support (lines marked 11 and 18). Note that information may be spread across multiple lines, as is the case with the third TOS_Msg (lines 00:1436718 and 00:1436878)

5.3.2

Sampling Software

We adapted the original Linksys NSLU2 firmware (a modified Linux 2.4.22+ kernel) to match our hardware modifications and include a sampling driver. A major change was the reconfiguration of 7 GPIO pins to interface to the switchboard/wiring hooked up to the 9 ADCs (8 Tnodes + 1 temperature sensor) in a testbed building block (cf. Figure 5.1). Our sampling software, which is part of the server program, communicates with the ADCs on the Tnode programmers via the SPI protocol made available in user space. We control the chip enable lines, generate the clock signal, and capture the 12-bit data samples from the 9 ADCs in parallel. Each ADC value is paired with the corresponding node ID, and one timestamp is attached to the collection of 9 readings before it is sent out over the Ethernet to the user who initiated the run. The maximum sampling rate that we can reliably sustain on a Linksys device is 5 kHz, which meets the requirements to be able to observe basic events like a carrier sense operation (taking about 0.5 ms).

5.3.3

Trace Processing Software

The power data that is received by the runner program from the testbed consists of raw ADC values. These values need further processing to be useful. The first step consists of converting (inverting and scaling) the ADC values to current draw in mA. However, because of hardware differences the values obtained from each programmer have to be adjusted by a small offset to ensure correct current draw values. To this end we have calibrated the current draw of each individual sensor node in the testbed. Once the ADC values have been converted to true current draw figures, the data can be used to generate plots and calculate total current draw over the trace (see Section 5.4 for sample results).

5.4

Results

After having installed the PowerBench testbed we were anxious to use it to falsify (or validate) the estimation-based approach widely used for assessing the energy efficiency of protocols. First, however, we needed to validate the accuracy of our modified programmer board and software-based sampling method.

5.4

5.4.1

RESULTS

75

PowerBench Validation

We started off by performing a careful static calibration of the power measurement subsystem for each programmer. We replaced the normal Tnode with a resistor to precisely control the current to be measured. That current was measured simultaneously by a precise (≤1%) multimeter and our power trace capturing setup. We recorded the difference and incorporated that into a calibration table (one entry per node) that assures compensation for both absolute and proportional errors. (This table is used by the runner when processing the raw ADC values.) By using resistors with different values the whole current measurement range (0– 65 mA) could be calibrated. The dynamic accuracy of the setup depends on the one hand on the noise of the opamp and the ADC, and on the other hand on the bandwidth of the measured signal (the node current) and the acquisition sampling rate. Unfortunately we do not have access to the necessary (and quite expensive) equipment to test the real dynamic measurement accuracy of our setup. However, since we do not work with high sampling rates (5 kHz) and high bandwidth signals (≤5 kHz) we are confident that most of the dynamic errors come from the noise of the ADC and the op-amp. The magnitude of this noise expressed in terms of ADC code difference is about ±1 LSB, resulting in a dynamic resolution of about 30µA.

5.4.2

Estimation Versus Measurements

With the calibrated testbed we engaged in the following experiment to determine the accuracy of the estimations derived from tracing the radio states. We modified the core CC1000ControlM module from the TinyOS protocol stack to intercept all state changes of the radio; at every change we read out an internal, high-accuracy timer and update the amount of time spent in the current state (RX/TX/SLEEP). This corresponds to the simple three-state model commonly used to estimate the energy consumption of MAC protocols. The resulting statistics are periodically output over the serial link. We multiply the measured time in each radio state with a combined figure for CPU and radio power consumption for that state. This is because the CPU of the nodes consumes more energy during transmission and reception than during sleep, for two reasons: Firstly, the radio on the nodes is a byte based radio, which means that each byte received or transmitted causes an interrupt on the CPU. Secondly, to receive that interrupt the CPU cannot go to its lowest power mode, but instead has to stay in idle mode. We used the instrumented CC1000ControlM module to estimate the current draw of the canonical TinyOS Surge application, with Multihop routing and two different MAC protocols; B-MAC [Pol04] and Crankshaft (see Chapter 3). At the same time we used the power traces to derive the real power consumption at each of the 24 nodes in the testbed. Figure 5.2 shows the estimated average current draw and the measured current draw for running B-MAC configured to use Low-Power Listening with a 12 Hz polling rate, i.e. performing a carrier sense every 83 ms. (Note that we only show the results for 12 out of 24 nodes to enhance readability.) The first bar shown for each node is an estimate based on the average current draw of all nodes for the three radio states. The second bar shows the real current draw as measured

THE POWERBENCH TESTBED

76

Average mA

7 6 5 4 3 2 1 0 0

1

3

RX estimate TX estimate Sleep estimate

5

7

8 Node

10

Measured

14

16

18

20

RX estimate (calibrated) TX estimate (calibrated) Sleep estimate (calibrated)

21

Figure 5.2: Estimated average current draw broken down into sources based on average current draw for each state (first bar) real current draw (second bar) and estimated current draw broken down into sources based on per-node calibrated values (third bar) for 12 nodes.

5.4

Protocol

Average

Std. dev.

B-MAC [always on] B-MAC [12 Hz poll] B-MAC [5.5 Hz poll] Crankshaft

-1.62 % -1.03 % -1.91 % -13.48 %

0.97 1.16 1.44 5.93

RESULTS

77

Table 5.1: Error as a percentage between estimated and real power consumption for the Surge

application with different MACs.

by our testbed. As can be seen from the figure, using the average current draw numbers can lead to significant errors in estimating the current draw of a node. For example node 7 has an estimated current draw of 4.75 mA, but a real current draw of 5.95 mA, an undershoot of 21 %. However, if we use per-node calibrated values for the different states we get far more accurate values, as shown by the third bar. In the example of node 7 it is also clear what is causing the difference between the first estimate and the measured current draw: node 7 draws a lot more current in sleep mode than is estimated with the average current draw figures. However, even with the calibrated estimates, some estimates can still be off by several percent for a specific run as shown by the results for node 21 (-5.0 %). From the estimates that are based on the average consumption figures we can see that nodes have to listen a lot. This is because at the default transmit power setting the network is a two-hop network. This means that when one node is transmitting, most of the others can hear this. Node 0 is the sink collecting all Surge data, and consequently transmits the least; it only has to send routing advertisements. Furthermore, we see that node 5 transmits a little more than most others. This is because after some time it will start forwarding messages for the few nodes that cannot directly communicate with the sink (node 0). For the B-MAC protocol we experimented with different polling frequencies, to see the impact of the radio switching. Table 5.1 shows the average error over 2 runs with a total of 46 traces2 . (The estimations are obtained with per-node calibrated current draw information.) Much to our surprise it was quite easy to obtain fairly accurate estimations for the B-MAC protocol; on average the estimations are off by only 2 %. The experiments with polling did show that radio state transitions cannot be ignored completely, with higher errors for more frequent polling. The underlying issue is that during the SLEEP-to-RX state transition of the radio the CPU is kept in a busy-waiting loop for correct timing. The energy consumed during this busy-waiting cannot be ignored. However, by simply modelling the power consumed by the CPU as an additional fraction of time spent in RX mode, we were able to obtain accurate estimations of the total consumed energy. This result demonstrates that the standard practice of disregarding the intricacies of radio state transitions when estimating power consumption is valid, for B-MAC that is. The results for the Crankshaft protocol paint a different picture. Using the radio states to model the energy consumption for Crankshaft leaves us with a significant underestimate of the real power consumption (-13 % on average). The reason for this is the inefficient imple2 One

node broke down after the initial measurements, so we had to continue with 23 nodes.

78

THE POWERBENCH TESTBED

mentation of the Crankshaft protocol. Crankshaft is a slotted protocol, but nodes do not wake up in each slot (see Section 5.4.3 for additional detail). However, for ease of implementation the current version of the protocol does wake up the CPU at each slot. Waking up the CPU and the subsequent processing also costs energy. Because the Crankshaft protocol keeps the radio turned off for most of the time, this limited CPU use still has a significant impact on the estimate. If the CPU were to only wake up for the slots in which the radio is turned on, the estimate would improve. As a quick fix, we did attempt to model the power consumed by the CPU when the radio was off, but failed to do so accurately due to most processing taking place inside interrupt handlers, which is very difficult to account for. This problem was also observed by Landsiedel et al. and explains why AEON (emulator-based) yields more accurate results than PowerTOSSIM (estimation-based) in certain cases [Lan05]. In summary, our results demonstrate that the times the radio spends in different states (RX/TX/SLEEP) can be used to calculate accurate estimates of the real energy consumption, provided the CPU is used sparingly.

5.4.3

Trace Visualisation

The power traces from the nodes can also be used for debugging purposes. Many artifacts are much easier to see from a visualisation than from textual debug output. Although the debug output can be visualised as well, the power traces provide a natural visualisation by plotting the consumed power versus the time. We cannot provide quantitative evidence on how much the visualisation of the power traces helps in debugging, but we will provide some anecdotal evidence. B-MAC Contention Anomaly

When running Surge with B-MAC as the underlying MAC protocol we observed that in some cases where contention was high, a node would switch to send mode almost immediately after receiving a message (see Figure 5.3). This seemed to be contrary to the back-off mechanism which B-MAC is advertised to employ. The expected behaviour is for the node that has just received a message to wait for a small random amount of time to do a clear channel assessment before starting to send itself. Of course it is possible that the random amount of time is actually zero, but further examination of the trace showed that this behaviour occurs quite frequently. Careful examination of the B-MAC implementation for the Mica2 platform revealed that there is in fact a deviation from the advertised behaviour. Rather than picking a new random back-off period after receiving a message, the time remaining from a lost contention is used as the back-off period. Also, when a node starts its contention during a data part of a message sent by a neighbouring node, it will count down the back-off timer. These two artifacts have the effect that the back-off period is not uniformly random, but rather skewed towards short periods. Although the quick switching behaviour does not seem to have a large impact on the protocol workings, it does increase the chance of collisions. Particularly in high contention situations the chances of collisions are increased because of the skewed distribution of the back-off periods.

5.4

30

RESULTS

79

Node 1 Node 4

28 26

mA

24 22 20 18 16 14 2.6

2.7

2.8

2.9 Time [sec]

3

3.1

3.2

Figure 5.3: Power trace of a node (4) running B-MAC switching to transmit mode immediately

after receiving a message (from 1). Receiving consumes approximately 18 mA, transmitting 23 mA.

Having the power traces from all 24 nodes was invaluable for finding the quick switching behaviour. By plotting all traces in a single graph it quickly becomes apparent that something strange is happening. If one were to have the traces from only two nodes it would be likely that there would be a message from another node between the messages from the instrumented nodes, hiding the quick switching behaviour. Trying to find this behaviour in the debug data or the simulator output is possible, but requires far more effort. Crankshaft Modulo Bug

As explained in Chapter 3, time in the Crankshaft protocol is divided into frames, and frames are subsequently divided into slots. Each frame starts with a set of unicast slots, followed by one or more broadcast slots. A node has to listen to each broadcast slot, and to one unicast slot. The unicast slot a node has to listen to is determined by taking the MAC address modulo the number of unicast slots. For example, when there are 8 unicast slots, a node with MAC address 4 will listen in the fourth unicast slot, as will a node with MAC address 12. During implementation of the MAC protocol, it was initially decided that the number of unicast slots would be 16. However, later on during the implementation process the number of unicast slots was made a compile time constant. The code was changed for determining when a neighbouring node would be awake, but the code to determine in which slot to listen was accidentally left untouched. The result of this oversight can be seen in Figure 5.4. The two graphs show the power traces for node 4 and 12, with the number of unicast slots set to eight and the number of broadcast slots set to two. One can clearly see the two consecutive pulses in current draw for the broadcast slots for two consecutive frames, where the radio was set to receive mode (at

80

THE POWERBENCH TESTBED

mA

Node 4 25 20 15 10 5 0 2.3

2.4

2.5

2.6

2.7

2.8

2.9

2.7

2.8

2.9

mA

Node 12 25 20 15 10 5 0 2.3

2.4

2.5

2.6 Time [sec]

Figure 5.4: Power trace for nodes running Crankshaft. Node 4 (top graph) and node 12 (bottom

graph) should listen to the same slots. The bottom graph demonstrates the missing power pulse at 2.68 seconds which would correspond to turning the radio to receive mode.

2.40, 2.45, 2.85 and 2.9 seconds). For node 4 we can also see another pulse between the two sets of broadcast slots at 2.68 seconds, which corresponds to unicast slot 4. In the bottom graph, which shows the power trace for node 12, the pulse in the middle is missing. Of course the modulo bug could also have been found either by simulation or by inspecting the debug output from the serial port. However, detecting that the start of slot marker is missing from the the simulator output or the debug output is made difficult by all the other messages. In the visualisation it is immediately clear. Although for this case it is not necessary to have all 24 traces available, it is necessary to have the trace of a node with a MAC address in a specific range. If the traces of a limited set of nodes were available, there would be a good chance that none of these nodes had appropriate MAC addresses, and the bug would have been missed.

5.5

Conclusions

In this chapter we have presented PowerBench, a scalable testbed infrastructure for benchmarking power consumption. PowerBench includes hardware components as well as software for capturing the power traces of all nodes in the testbed in parallel. These traces are stored for off-line processing and viewing, aiding in the analysis and debugging of the energy footprint of various protocols. PowerBench was developed for the Tnode architecture, which is similar to the familiar Mica2, and is validated to accurately measure power consumption with a 30 µA resolution at a sampling rate of 5 kHz. This is precise enough to trace events at the lowest level in the protocol stack, for example B-MAC performing a (periodic) carrier sense and then going to sleep immediately.

5.5

CONCLUSIONS

81

The software developed for the PowerBench testbed includes programs to run applications on the nodes, to collect the resulting power traces, and to visualise them or to compute the average current draw. We have installed a 24-node testbed in our labs and used it for two purposes. First, we have compared the traditional method of estimating energy consumption –based on counting the time spent in each radio state– with the true measurements provided by PowerBench. Much to our surprise the estimates can be tuned (calibrated) to perfection with errors generally below 2 %, provided the CPU is used sparingly. Second, we used it to study/develop MAC protocols and provided examples of anomalies detected through visualising the power traces obtained on the PowerBench testbed.

Evaluation of MAC Simulation Abstractions

6

Evaluation of MAC protocols is often done through simulation. However, the impact on the performance of MAC protocols of the different abstractions used in WSN simulators is mostly unknown. In this chapter we use our PowerBench testbed to test common reception models for WSN simulators. We show that the simple SNR model with additive signals provides results close to testbed experiments.

To evaluate a MAC protocol for a Wireless Sensor Network (WSN) requires that one performs several experiments with different representative topologies. Furthermore, these experiments should ideally be repeated several times to obtain statistically relevant results. Performing these experiments in the real world is exceedingly time consuming and costly. Therefore, MAC protocol designers normally resort to using a simulator to evaluate their protocols. Using a simulator is a cheap and quick way to perform many experiments with different topologies and parameter settings. Simulators necessarily abstract away from reality in many ways. For example, radio propagation is not simulated by simulating the EM radiation through the air and obstacles from one antenna to the next, but by using a formula to calculate the received signal strength at the receiving radios. It is clear that these abstractions are required to make simulation feasible, and it is likely that many details can be ignored because of their limited impact on the simulation results. However, limited work has been done to validate the abstractions commonly used in simulators for WSN MAC protocols evaluation. In this chapter we study the impact two abstractions commonly used in simulations of WSNs. These abstractions are different ways to model the reception of signals at WSN nodes. First we evaluate the binary reception model that is used in the Unit Disk Graph (UDG) model. In this reception model a signal is either received by a node at sufficient strength that perfect reception is guaranteed, or it is not received at all. Furthermore, all signals have equal strength, so if two signals arrive at the same node at the same time the node will not be able to receive either signal. This model is sometimes extended with an This chapter is an extended version of: “Experimental evaluation of simulation abstractions for wireless sensor network MAC protocols”, G. Halkes and K. Langendoen, in 14th IEEE International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (IEEE CAMAD ’09). Pisa, Italy, June 2009.

83

84

EVALUATION OF MAC SIMULATION ABSTRACTIONS

interference range. The signals arriving at nodes within the interference range are assumed not to be decodable, but strong enough to interfere with all other signals and therefore prevent reception. The second reception model we evaluate is the SNR-based reception model. In this model each signal is given a signal strength. If some signal arriving at a node is stronger than the sum of all other signals at the node by at least an SNR threshold the node can properly receive the signal. If the strength of the strongest signal versus the other signals is below the threshold the node will only receive a garbled message. This model is commonly used in combination with Free space and Two Ray propagation models. However, for our evaluation of the SNR abstraction we use measured signal strength from the testbed we use for validation. We evaluate the accuracy of the physical layer abstractions within the context of MAC protocols for WSNs. Therefore we focus on the performance metrics commonly used in evaluating MAC protocols. These are packet delivery ratio (a.k.a. packet reception rate or goodput), and energy consumption which is usually derived from the time spent in different radio states. Furthermore we investigate the average packet latency. Latency is a less often used metric for the evaluation of MAC protocols as it is usually assumed that latency is not important and can be traded off for better energy consumption. The rest of this chapter is organised as follows: in Section 6.1 we give an overview of relevant prior research in the area of simulation validation. In Section 6.2 we describe the setup of the experiments we performed, followed by the results in Section 6.3. Finally, in Section 6.5 we present our conclusions.

6.1

Related Work

Wireless simulation accuracy has been studied mostly in the context of Mobile Ad-hoc Networks (MANETs). Within this context the work of Ivanov et al. [Iva07] and Liu et al. [Liu05] is most similar to our work. Ivanov compares the results of a real experiment with the results of the ns-2 wireless simulator for the same experiment, concluding that the simulated delivery ratio is quite accurate but latency results show much deviation from the real experiment. Furthermore, the study is limited to a single routing and MAC protocol. This limits the value as other studies have shown that different routing protocols are affected differently by different physical models [Tak01]. The work of Liu et al. [Liu05] provides some validation of the physical layer models used in the SWAN simulator, by using connectivity traces from a real experiment to drive the simulator. This study focuses solely on packet delivery ratio and parameter sensitivity, using different routing protocols. Kotz et al. [Kot04] provides a list of assumptions used by many MANET network simulators and provides a few small experiments to show that these assumptions can lead to erroneous results. More specific studies into the accuracy of WSN simulators have been performed by Colesanti et al. [Col07], Lee et al. [Lee07], Wittenburg et al. [Wit07] and Pham et al. [Pha07]. Colesanti studied the OMNeT++ MAC Simulator, but again only looked at packet delivery ratios and a single MAC protocol. The MAC Simulator uses the Unit Disk Graph (UDG)

6.2

EXPERIMENT SETUP

85

model. Colesanti et al. showed that by introducing probabilistic packet corruption derived from real-world experiments, the results of the UDG model could be made to approach the real-world experiments. Pham studied the channel model in the Castalia WSN simulator. The experiments used an unspecified tunable MAC protocol and were aimed at verifying the connectivity and fluctuations in connectivity by comparing simulations with the results of real experiments. The study found that even with the complex model used in the Castalia simulator, significant differences still occur. The experiments done by Wittenburg et al. [Wit07] focus on single link behaviour. The results show that given a reasonable propagation model, similar packet loss rates can be achieved as in real-world experiments. Lee et al. [Lee07] provides a new trace-based noise model for wireless simulations. Through several experiments Lee et al. show that their model can simulate single links more accurately with respect to packet delivery ratio than existing models. However, because both studies only consider a single link, effects such as collisions and the capture effect are unknown and no conclusions can be derived with respect to MAC protocol behaviour. Because in MANETs energy efficiency is not an important metric, none of the MANET studies have considered energy consumption. The study by Colesanti, although focused on WSNs, also did not consider energy consumption. Heidemann at al. [Hei01] have considered energy consumption but only to show that the energy consumed by nodes when waiting for packets to arrive is a significant factor and must be taken into account in simulations. All MANET validation studies have used the 802.11 MAC protocol. As this is the de facto standard in MANETs, this is perfectly reasonable. However, as we show in this chapter, not all MAC protocols are affected equally by the choice of physical layer abstraction. Therefore it is important to specifically study the impact of simulation abstractions on different MAC protocols.

6.2

Experiment Setup

To evaluate the simulation abstractions, we compare simulation results with results from our PowerBench testbed (see Chapter 5). The testbed consists of 24 nodes installed in our offices. By configuring the send power to its lowest setting we can create a multi-hop network. However, when using this setting we can only usefully employ 22 nodes. The nodes in our testbed are Tnodes, which use the same components as the mica2 nodes (Chipcon CC1000 radio, Atmel ATmega 128L processor). On our testbed we use our TinyOS 2.x λMAC framework, for which we have implementations of several MAC protocols. The MAC protocols using the λMAC framework represent different points in the MAC protocol design space. For our experiments we use the B-MAC [Pol03], T-MAC [Dam03], Crankshaft [Hal07], and LMAC [Hoe04a] protocols. The B-MAC protocol is representative of the Low-Power-Listening class of protocols. T-MAC is also a carrier-sense based protocol, but instead uses frames with active and idle periods to reduce energy consumption. LMAC is an example of a TDMA protocol, and finally Crankshaft is a hybrid protocol using the slotted structure of TDMA protocols in combination with

86

EVALUATION OF MAC SIMULATION ABSTRACTIONS

carrier sensing to achieve high energy efficiency. It should be noted that the LMAC implementation for the λMAC framework uses a static slot assignment and uses a timer to detect the absence of packets in a slot rather than a carrier sense mechanism. In order to limit as much as possible the influence of modelling differences between the software running on the real hardware and the simulation models, we have chosen to use the TinyOS 2.x simulator TOSSIM. TOSSIM uses the same code as is compiled for the hardware platform to compile the simulator, only replacing the hardware control modules with TOSSIM specific ones. The standard TOSSIM however does not provide a model for the CC1000 radio. Therefore, we used and modified the PowerTOSSIM extension for TinyOS 2.x as a basis to implement different reception models.

6.2.1

Traffic Pattern and Metrics

In our evaluation we consider the convergecast or to-sink traffic pattern. In this pattern all nodes in the network send messages to a single sink node. This pattern is representative of data collection in WSNs. Because we are considering a multi-hop network a routing tree needs to be set up. To eliminate the influence of other components than the MAC protocol as much as possible, we use a fixed routing tree that we created off-line based on link quality measurements. Because different network setups have different characteristics we use two different routing trees. The first routing tree has the sink in the centre of the network and has an average hopcount of approximately 1.86. The second routing tree has the sink at the edge of the network and has an average hopcount of approximately 2.48. The second traffic pattern we study is the broadcast flood pattern. This pattern is often used to disseminate data or commands in a WSN. We chose these two traffic patterns because they exercise different aspects of the MAC protocols. As metrics we consider both delivery ratio and energy consumption. The delivery ratio is simply defined as the fraction of messages sent by all nodes that arrive at the sink node. For the broadcast flood pattern the delivery ratio is calculated as the sum of all unique messages that arrived at the nodes divided by the number of messages injected in the network and the number of receiver nodes in the network. So if only half of the nodes receive the message injected, the delivery ratio would be 0.5. The energy consumption in simulation is usually derived from the time the radio spends in transmit, receive and idle state. In Chapter 5 we have shown that using this simple threestate model yields accurate results for energy consumption. In this chapter we therefore use the time spent in the different states as our metric, rather than the combined energy consumption number. Using the separate states allows us to more precisely determine the causes of inaccuracy of the simulator. Finally, we also provide average packet latency, defined as the time between packet generation and arrival at the sink, as metric. Packet latency is usually traded for energy consumption in WSN MAC protocols, and therefore not considered a very important metric. However, it is interesting to see how much latency is incurred because of the trade off, and this does make latency an interesting metric.

6.2

EXPERIMENT SETUP

87

A

C

S1

B

S2

Figure 6.1: Connectivity in the PowerBench testbed. Links shown have at least 95% packet

reception in both directions.

6.2.2

Abstractions

In this chapter we study two reception models commonly used in WSN MAC protocol simulation. The first model is the binary reception model employed by the Unit Disk Graph (UDG) model. In this model nodes either receive a signal perfectly, or not at all. To arrive at a simulation of the binary reception model which can be compared with the results from our testbed, we cannot simply derive a connectivity graph from the node positions. As Figure 6.1 shows, the connectivity in our testbed network is very irregular. For example, there is good connectivity between node A and node B, while the link between A and C, which is much shorter, allows virtually no messages to get through. Therefore we first measured all link reception rates in our testbed. From this we extracted the subset of links that show (near) perfect reception, i.e. those links with 95% reception. These links are then taken to be usable for signal transmission, while all other links are discarded. In our experiments we use the extended reception model that also implements an interference range. The links on which interference can occur are the links for which the signal strength is above a threshold. The threshold has been tuned to provide simulation results as close as possible to the real-world results. We have verified that the extended binary model yields slightly better results than the simple binary model. The second popular reception model is the Signal-to-Noise Ratio (SNR) based model. In this model all signals have a different signal strength. To determine whether a signal can be received, it is compared to the sum of all other signals and noise. If the signal is stronger than the combined signal by at least the SNR threshold it is assumed to be decodable. Collisions therefore only occur when two signals arrive that are close in signal strength. As with the binary reception model, we cannot simply use the positions of the nodes in our testbed to calculate signal strengths as there is too little correlation between received signal strength and distance. This phenomena has already been shown in [Kot04]. We have therefore measured the (average) signal strengths between all pairs of nodes in our testbed. We use this

88

EVALUATION OF MAC SIMULATION ABSTRACTIONS

information as the signal strengths in our simulations. Furthermore, we have experimentally determined the SNR value of the CC1000 radio on the Tnodes to be approximately 5 dB.

6.3

Results

We now present the results of our experiments. All experiments were repeated between 5 and 8 times, and the graphs show the mean and standard deviation.

6.3.1

Convergecast

For convergecast we first show the experiment with the sink at the centre (node S1 in Figure 6.1). This experiment shows the largest divergence between the simulations and the real-world experiments, and shows the most interesting effects. Then we will present the most interesting results from the convergecast experiment with the sink located at the edge of the network. Delivery Ratio

Figure 6.2 shows the delivery ratio for the different protocols. From the graphs it is immediately clear that the binary reception model does not provide a good simulation abstraction. For all protocols except LMAC the simulated delivery ratio is much worse than the measured delivery ratio. It is not surprising that the delivery ratio in LMAC is not affected by the binary reception model, as transmissions in LMAC are scheduled not to collide. The large differences in delivery ratio for the B-MAC, T-MAC and Crankshaft protocols is due to the all or nothing nature of the binary reception model. In real life fewer collisions occur because weak signals do not interfere with strong signals. In the binary model there is no distinction between weak and strong signals, which means all concurrent transmissions arriving at a single node will always cause a collision. The delivery ratio for the SNR-based simulation for the most part approach the measured results quite closely. Notable exceptions are the B-MAC protocol at high message rates and the Crankshaft protocol at low message rates. The reason that B-MAC diverges at high message rates is because the real implementation detects more carriers than the simulator. Even though both use the same code for carrier detection, the fluctuations in (measured) signal strength that occur in real life are not simulated and therefore fewer carriers are detected when the signal strength is close to the detection threshold. We found that this abstraction is the cause of most differences between the measured results and the SNR-based simulation model. The cause of the difference between the SNR-based simulations of the Crankshaft protocol and the measured results is very different. The sending of messages in the Crankshaft protocol is synchronised to a particular time in each slot. When equal length messages are sent as shown in Figure 6.3 both the actual messages and the acknowledgements are received error free. However, when node A is slightly ahead of node D, the acknowledgement sent by node B in response to A’s message will collide with the message from D to C. In simulation

6.3

B-MAC (Testbed) B-MAC (Binary) B-MAC (SNR) T-MAC (Testbed) T-MAC (Binary) T-MAC (SNR)

1 0.8 Delivery ratio

RESULTS

0.6 0.4 0.2 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec) Crankshaft (Testbed) Crankshaft (Binary) Crankshaft (SNR) LMAC (Testbed) LMAC (Binary) LMAC (SNR)

1

Delivery ratio

0.8 0.6 0.4 0.2 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec)

Figure 6.2: Delivery ratio for simulated and real convergecast experiment.

DATA A

DATA B

C

ACK

ACK

D

Figure 6.3: Potential collision situation for the Crankshaft protocol.

89

90

EVALUATION OF MAC SIMULATION ABSTRACTIONS

120

B-MAC (Testbed) B-MAC (Binary) B-MAC (SNR) T-MAC (Testbed) T-MAC (Binary) T-MAC (SNR)

Radio Time (sec)

100 80 60 40 20 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec) 120

Crankshaft (Testbed) Crankshaft (Binary) Crankshaft (SNR) LMAC (Testbed) LMAC (Binary) LMAC (SNR)

Radio Time (sec)

100 80 60 40 20 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec)

Figure 6.4: Radio receive times for simulated and real convergecast experiment.

the clocks of different nodes run exactly at the same rate. Therefore, once properly synchronised there is no chance of such a collision. However, in reality clocks on different nodes drift, which means collisions of this type are likely to occur. At higher message rates the extra carrier detections found in the real-life implementation prevent some hidden terminal problems, which compensates for the synchronisation problem. Energy Consumption

Next we consider the time spent in the different radio states. Figure 6.4 shows the time spent in receive mode. For this metric the difference between the binary reception model and

6.3

RESULTS

91

the SNR-based model are very small. Although this may at first seem contradictory given the delivery ratio graphs, one should take into account that collisions do cause the radio to remain in receive state. Although the time spent in receive mode for the simulated experiment are very similar to the real-life situation, there are some differences that warrant explanation. The time the real B-MAC and T-MAC spend in receive mode is higher than in the respective simulations. This is again caused by the extra carrier detections. A similar explanation holds for Crankshaft. However, the difference here is that the offset between the real and simulated protocol is much more constant. Because Crankshaft separates unicast and broadcast traffic, the time synchronisation protocol will not consider the unicast packets as suitable for time synchronisation. Therefore, even when there is unicast traffic being sent, the time synchronisation protocol will still send broadcast packets at regular intervals. This, combined with the reduced overhearing for unicast messages in the Crankshaft protocol, results in an almost constant offset as the extra receive time is nearly completely caused by the broadcast messages. Figure 6.5 shows the time spent in transmit mode for the different protocols. Note that Figure 6.5 uses a different scale than the receive time graphs in Figure 6.4. Again the binary model shows the largest differences, with differences up to 20%. The largest difference occurs for the T-MAC protocol, which at all message rates spends less time in send state than the real-world implementation. Although the lower transmit time may seem logical given the lower delivery ratio achieved by T-MAC, this is only part of the story. The extra collisions in the binary model also cause more retries. These retries also cost extra send time. However, these retries are mostly RTS retries, which do not cost a lot of extra time. Furthermore there are fewer messages being relayed. Relayed messages cost transmit time for every hop, while messages that get dropped after several retries only cost transmit at a single hop. The transmit time results for the SNR-based model are almost all within 5% of the realworld results. Only the transmit time of the B-MAC protocol with the SNR-based model is 10% less at the highest rate. This is a result of the reduced bandwidth caused by the extra carrier detections. Latency

Finally, Figure 6.6 shows the average packet latency. These graphs do not show the binary model anymore, because the divergence in packet delivery is too large to make these results sensible. For T-MAC the SNR-based latency results seem quite similar to the real-world results, except at low message rates. However, there are two effects here that cancel each other out at higher data rates. The already mentioned extra carrier detections on the one hand cause extra latency in the real-world experiment. On the other hand they also prevent hidden terminal collisions around the sink, which effectively reduces latency. At lower data rates hidden terminal collisions are less of a problem. Therefore the latency in the real-world experiment is higher at low data rates. B-MAC suffers from using long preambles. The real-world latency is much higher because each extra carrier that is detected defers the sending of a packet by a significant amount of time.

92

EVALUATION OF MAC SIMULATION ABSTRACTIONS

30

B-MAC (Testbed) B-MAC (Binary) B-MAC (SNR) T-MAC (Testbed) T-MAC (Binary) T-MAC (SNR)

Radio Time (sec)

25 20 15 10 5 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec) 30

Crankshaft (Testbed) Crankshaft (Binary) Crankshaft (SNR) LMAC (Testbed) LMAC (Binary) LMAC (SNR)

Radio Time (sec)

25 20 15 10 5 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec)

Figure 6.5: Radio transmit times for simulated and real convergecast experiment.

The difference between the real-world Crankshaft results and the SNR-based Crankshaft results is a direct consequence of the difference in the source of packet loss and retries. The packets lost in the real-world experiment are lost throughout the network. However, the SNRbased simulation experiences packet loss mostly around the sink. Because in Crankshaft the sink is assumed to be mains powered and therefore listens in every slot, a retry to the sink can be done in the next slot. However, a packet lost elsewhere in the network has to be retried in the next frame, and therefore has to be deferred for a lot longer.

6.3

14

RESULTS

93

B-MAC (Testbed) B-MAC (SNR) T-MAC (Testbed) T-MAC (SNR)

12

Latency (sec)

10 8 6 4 2 0 0

0.2

0.4

0.6

0.8

1

0.8

1

Message rate (msg/node/sec) 14

Crankshaft (Testbed) Crankshaft (SNR) LMAC (Testbed) LMAC (SNR)

12

Latency (sec)

10 8 6 4 2 0 0

0.2

0.4

0.6

Message rate (msg/node/sec)

Figure 6.6: Average packet latency for simulated and real convergecast experiment.

Topology Effects

To determine how sensitive the results are to the specific topology, we also performed an experiment where we placed the sink at the edge of the network (node S2 in Figure 6.1). In this section we only present the interesting differences with respect to the previously shown experiment. Figure 6.7 shows the delivery ratio for the different protocols. Compared to the experiment with the sink in the centre of the network (as shown in Figure 6.2), the binary reception model results are much closer to the real-world results for all protocols except LMAC. The other notable point in this graph is that the SNR-based results for the Crankshaft protocol

94

EVALUATION OF MAC SIMULATION ABSTRACTIONS

B-MAC (Testbed) B-MAC (Binary) B-MAC (SNR) T-MAC (Testbed) T-MAC (Binary) T-MAC (SNR)

1

Delivery ratio

0.8 0.6 0.4 0.2 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec) Crankshaft (Testbed) Crankshaft (Binary) Crankshaft (SNR) LMAC (Testbed) LMAC (Binary) LMAC (SNR)

1

Delivery ratio

0.8 0.6 0.4 0.2 0 0

0.2

0.4

0.6

0.8

1

Message rate (msg/node/sec)

Figure 6.7: Delivery ratio for simulated and real convergecast experiment with the sink at the

edge of the network.

do not match the real-world results as closely as in the previous experiment. As noted in the analysis in Section 6.3.1, there were two opposite effects that played a part in the good result for the SNR-based model in the previous experiment: fewer collisions caused by small de-synchronisation and more collisions due to hidden terminal problems. As the sink is located at the edge of the network in this experiment there are fewer hidden terminal problems. This results in fewer collisions in the network for the SNR-based simulations, which means a higher delivery ratio. However, the results are still within 10%. For the latency results in Figure 6.8 we again see that the reduced hidden terminal problem changes the relative performance of the SNR-based model. In this case the T-MAC protocol

6.3

16

95

B-MAC (Testbed) B-MAC (SNR) T-MAC (Testbed) T-MAC (SNR)

14 12 Latency (sec)

RESULTS

10 8 6 4 2 0 0

0.2

0.4

0.6

0.8

1

0.8

1

Message rate (msg/node/sec) 16

Crankshaft (Testbed) Crankshaft (SNR) LMAC (Testbed) LMAC (SNR)

14

Latency (sec)

12 10 8 6 4 2 0 0

0.2

0.4

0.6

Message rate (msg/node/sec)

Figure 6.8: Average packet latency for simulated and real convergecast experiment with the

sink at the edge of the network.

is affected most clearly. Where in the experiment with the sink at the centre of the network the extra carrier detections reduced hidden terminal collisions in the real-world experiment and thereby lowered the latency at higher message rates, this is no longer the case with the sink at the edge of the network. This results in a uniformly higher latency for the T-MAC protocol in this experiment. The final interesting difference we see in this experiment is that the latency for the SNRbased simulation of the Crankshaft protocol is very close to the measured latency. Although encouraging, it should be noted that the average hopcount for messages arriving at the sink for the real-world experiment is lower than for the simulation. As the latency difference is

96

EVALUATION OF MAC SIMULATION ABSTRACTIONS

higher further away from the sink, the different distribution hides the real latency differences. Although most differences are at most 10%, for the first hop and the nodes at 4 hops from the sink the difference can be up to 50%.

6.3.2

Broadcast Flood

As a second test we used the broadcast flood traffic pattern. The delivery ratio for all protocols except B-MAC are within a few percent of the real-world experiment for the SNR based reception model (Figure 6.9). Extra carrier detections are again the cause of the difference in performance. Although Crankshaft also suffers from this problem, the problem is most pronounced in B-MAC because B-MAC uses long preambles which exacerbate the problem. When a node running B-MAC has to defer a packet because it detects the channel is busy it has to wait for a significant amount of time. If instead it detects the channel as idle, as it does in the simulated case, the available bandwidth is increased. Note that for T-MAC the extra carrier detections can actually increase the delivery ratio. For T-MAC the available bandwidth is not a problem. What is a problem though for T-MAC is nodes switching off the radio when there is no traffic detected. When a carrier is detected, a node will reset its time-out and will only start the time-out again when the carrier disappears. Then, when the message is resent by another node, the node with the reset time-out may be able to receive the resent message resulting in an increased delivery ratio. The effect however is small. We have also studied the time the radio spends in different states. As the results provide no extra insights, we do not show them here.

6.4

Modelling Differences

As we mentioned in Section 6.2, we used the TOSSIM simulator which is compiled from the same code as is used to compile the hardware code. This limits the differences between the code executing in the simulator and the code running on the hardware. However, this does not mean there are no differences. The modules that normally interact with the hardware have to be replaced by modules that change the simulator state to reflect the requested changes. For example, the radio driver module has to simulate the transmission of signals to the other radio driver module instances when requested to transmit bytes. For the time spent in the different radio states there is another factor that plays an important role: the simulation of busy waiting. When switching the radio between radio states the processor has to wait for short amounts of time at several points. This is implemented by busy waiting in the driving code. For the simulator busy waiting is transformed to a no-op, because busy waiting cannot be directly simulated in a discrete event simulator such as TOSSIM. This modelling difference can result in significant differences in the simulation results. As an example we show the start of an LMAC slot (see Figure 6.10). The radio states shown are for a node which owns the slot. In the real-world implementation the switch from off state to receive state takes just over 2 msec (cf. Figure 6.10 top). This switch is started when the slot timer fires. Then, when the guard time timer fires, the radio is switched to

6.4

MODELLING DIFFERENCES

1

Delivery ratio

0.8 0.6 0.4 B-MAC (Testbed) B-MAC (SNR) T-MAC (Testbed) T-MAC (SNR)

0.2 0 0

0.5

1

1.5

2

2.5

3

Floods per second Crankshaft (Testbed) Crankshaft (SNR) LMAC (Testbed) LMAC (SNR)

1

Delivery ratio

0.8 0.6 0.4 0.2 0 0

0.5

1

1.5

2

2.5

3

Floods per second

Figure 6.9: Delivery ratio for the broadcast experiment. Slot timer

Guard time timer

Slot timer

Guard time timer

Switching (Busy wait)

Receive

Transmit

Figure 6.10: Radio states at the start of an LMAC slot for hardware implementation (top) and

simulation (bottom)

97

98

EVALUATION OF MAC SIMULATION ABSTRACTIONS

transmit state. The time the radio requires to switch is timed through a busy-waiting loop in the code. As already mentioned, this is transformed into a no-op in the simulator. The result is that the switch is effectively performed immediately in the simulator (cf. Figure 6.10 bottom). The total time spent in receive mode would therefore be longer in the simulation than in the real-world, even if the simulation is otherwise perfect. In the specific example we could easily resolve the problem because the guard time is calculated taking into account the switch time. By overriding the switch time constant with a value of zero for the simulation, this specific instance of the busy-waiting problem was resolved. There are also several other points in the radio switching code where busy-waiting loops are used, but the impact of those loops is much smaller as their waiting time is in the order of 0.1 msec. Furthermore, not all protocols are impacted by the demonstrated offto-receive switch problem. If the timing for events after the switch is done relative to the completion of the switch, for example by waiting until a certain number of bytes have been read from the radio, the time difference is effectively zero as well.

6.5

Conclusions

In this chapter we have presented the results of an experimental study of two often-used reception models in the simulation of WSN MAC protocols. We have compared simulations that use these models with data from our PowerBench testbed. The results show that the binary reception model used in, for example, the Unit Disk Graph simulation model results in significant deviations from the real-world results. The SNR-based model, however, can provide quite accurate results for metrics commonly used to evaluate MAC protocols, i.e. delivery ratio and energy consumption. Most results are within 5%, while virtually all are within 15%. For latency the results are less accurate. The main cause of remaining deviation between real-world results and the SNR-based model are the unmodelled fluctuations in (measured) signal strength.

7

Conclusions

In this thesis we have studied MAC protocols for wireless sensor networks. MAC protocols for WSNs have to be optimised for energy efficiency to allow WSNs to operate continuously for long periods of time. As designs for wireless MAC protocols outside of WSNs have concentrated on optimising metrics such as latency and fairness, these wireless MAC protocols are not suitable for WSNs. Therefore, new MAC protocols are required. We have looked at two main aspects of MAC protocol development: the design and implementation of MAC protocols, and the evaluation of MAC protocols. Our work in the design of MAC protocols started with the design of the Crankshaft protocol (Chapter 3). Stemming from experiences with real deployments, the protocol focuses on dense deployments where many nodes are deployed in a relatively small area. The large number of neighbour nodes mean that the problem of overhearing is an important source of wasteful energy consumption. The Crankshaft protocol uses several different techniques to reduce overhearing and energy consumption in general. The most important of these techniques are receiver scheduling and synchronised channel polling. Our experiments show that the Crankshaft protocol outperforms many general purpose MAC protocols in terms of energy consumption for convergecast traffic in dense WSNs, with good delivery ratio. As a further step into the design of MAC protocols we turned our attention to the λMAC framework (Chapter 4). The λMAC framework was designed to allow easy implementation of MAC protocols by allowing code sharing between implementations of different MAC protocols. By trying to apply the λMAC framework to our Crankshaft protocol, we found several areas in which the λMAC framework could be improved. The resulting updated λMAC framework is now general enough to allow implementation of an even wider range of MAC protocols, from random access protocols like B-MAC, to TDMA protocols like LMAC and hybrid protocols like Crankshaft. The second aspect of MAC protocol development, evaluation, is a theme that is found throughout this thesis. In Chapter 2 we have shown the results of extensive simulations of de facto standard MAC protocols. Through these simulations we have shown that low-power listening is a useful technique, which can be combined with CSMA-based MAC protocols to reduce energy consumption. When combined with CSMA-based MAC protocols, it is required that the radio can operated at a sufficiently small timescale to prevent interfering with normal MAC protocol operation. We have also shown that the T-MAC protocol with its 99

100

CONCLUSIONS

variable active time, is flexible enough to cope with fluctuations in traffic both in time and location. The evaluation of MAC protocols is of course also required when designing a new MAC protocol. Therefore, together with the design of the Crankshaft protocol, we have presented simulations that show its relative performance with respect to existing MAC protocols. With these simulations we show that the Crankshaft protocol indeed delivers the expected energy savings in dense wireless sensor networks. In contrast to MAC protocols, the evaluation of a MAC framework such as the λMAC framework cannot be done simply by simulation. To evaluate the λMAC framework a performance comparison of protocol implementations within the λMAC framework with other implementations of the same protocols is required. This cannot be done in simulation, as the framework was designed for real-world implementations. Therefore we have used a testbed to evaluate the performance. We have performed the evaluation with other real-world implementations where possible, and with simulation results in other cases. For a MAC framework the evaluation cannot stop there. Therefore, we have also investigated code size and CPU load to show the overhead incurred by protocol implementations within the λMAC framework. Our results indicate that the overhead caused by the λMAC framework is small. We have also studied the methods for evaluation themselves. First of all we have presented results obtained with the PowerBench architecture (Chapter 5). The PowerBench architecture is a scalable modular architecture that makes it possible to measure the power consumption of all the nodes in a testbed. Using our PowerBench testbed, we have been able to show that the simple three-state radio model for estimating power consumption provides accurate results. As the three-state radio model is often used for calculating power consumption numbers from simulation results, this is an important finding. Also, we have shown that the power tracing capability of the PowerBench architecture is an invaluable tool in developing MAC protocols. Finally, we have studied the validity of two reception models commonly used in simulators for WSN MAC protocols (Chapter 6). By comparing the performance results obtained on our PowerBench testbed with simulation results, we show that the binary model is too coarse an abstraction and has a non-uniform impact on the results for different MAC protocols. Furthermore, the results indicate that the Signal-to-Noise Ratio model with additive signals captures most of the important characteristics of the wireless channel, with respect to MAC protocols. Combined with the validation of the three state radio model for energy consumption estimation from Chapter 5, these results lend credence to simulation results both in this thesis and in the relevant literature.

7.1

Recommendations

The field of MAC protocols for WSNs has been studied extensively since the start of the WSN research. This research has produced a string of MAC protocols based on different ideas and designed for different scenarios. The Crankshaft protocol presented in this thesis is just one example.

7.1

RECOMMENDATIONS

101

New MAC protocols are usually a combination of one new concept with several existing concepts. As such, new concepts are presented as part of a complete MAC protocol design. However, many of the choices for concept combinations are not dictated by conceptual interdependencies, but rather dependant on the views of the MAC protocol designer. This methodology introduces artificial links between concepts. To break the artificial links between different concepts in MAC protocols, a one concept per module approach is needed. The λMAC framework presented in this thesis is a small step towards that approach. Such an approach allows composition of MAC protocols from a library of modules, such that it is easy to try different combinations of concepts. Instead of designing a new MAC protocol, one would create a new module for the new concept. A further benefit of the one concept, one module approach would be the simplification of creating a MAC protocol for a specific scenario. When looking at the evaluation of MAC protocols we conclude that the evaluation is still mostly done using simulation, and will be for the foreseeable future. Given the high cost and time requirements for implementation on real hardware, this is perfectly reasonable. However, the MAC protocol community needs to be sure that the simulators used approach reality to within several percent. The work in this thesis provides a first step in that direction, but a lot more needs to be done to validate not just the physical layer effects, but also the effect of physical layer modelling on the MAC layer. Furthermore, these physical layer models should be accompanied by a readily available collection of parameter settings for the different physical layer parameters that represent different WSN scenarios. When simulations are performed using such an agreed-upon realistic channel model, the results of simulation can be used with confidence as a substitute for results from real experiments for the evaluation of MAC protocols.

Bibliography [Bar07] A. Barberis, L. Barboni, and M. Valle. Evaluating energy consumption in wireless sensor networks applications. In 10th Euromicro Conference on Digital System Design: Architectures, Methods and Tools (DSD 2007), pp. 455–462. Lübeck, Germany, August 2007. [Ber] Berkeley motes design. http://www.tinyos.net/scoop/special/hardware/. [Bha94] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang. MACAW: a media access protocol for wireless LANs. In Conference on Communications Architectures, Protocols and Applications, pp. 212–225. London, United Kingdom, August 1994. [Bis04] S. Biswas and R. Morris. Opportunistic routing in multi-hop wireless networks. SIGCOMM Computer Communications Review, vol. 34(1):pp. 69–74, 2004. [CE06] S. Coleri-Ergen and P. Varaiya. PEDAMACS: Power efficient and delay aware medium access protocol for sensor networks. IEEE Transactions on Mobile Computing, vol. 5(7):pp. 920–930, July 2006. [Che05] W. Cheng, I.-T. A. Lee, and N. Singh. Time division hashing (TDH): A new scheduling scheme for wireless ad-hoc networks. In 7th International Symposium on Advanced Radio Technologies (ISART 2005), pp. 91–100. Boulder, CO, March 2005. [Col07] U. M. Colesanti, C. Crociani, and A. Vitaletti. On the accuracy of OMNeT++ in the wireless sensor networks domain: Simulation vs. testbed. In 4th ACM Workshop on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-WASUN 2007), pp. 25–31. Crete Island, Greece, October 2007. [Dam03] T. van Dam and K. Langendoen. An adaptive energy-efficient MAC protocol for wireless sensor networks. In 1st ACM Conference on Embedded Networked Sensor Systems (SenSys 2003), pp. 171–180. Los Angeles, CA, November 2003. 103

104

BIBLIOGRAPHY

[Dye07] M. Dyer, J. Beutel, L. Thiele, T. Kalt, P. Oehen, K. Martin, and P. Blum. Deployment support network - a toolkit for the development of WSNs. In 4th European Conference on Wireless Sensor Networks (EWSN ’07), pp. 195–21. Delft, The Netherlands, January 2007. [Ee06] C. Ee, R. Fonseca, S. Kim, D. Moon, A. Tavakoli, D. Culler, S. Shenker, and I. Stoica. A modular network layer for sensornets. In 7th ACM Symposium on Operating System Design and Implementation (OSDI ’06), pp. 249–262. Seattle, WA, November 2006. [EH04] A. El-Hoiydi and J.-D. Decotignie. WiseMAC: An ultra low power MAC protocol for the downlink of infrastructure wireless sensor networks. In 9th International Symposium on Computers and Communications (ISCC 2004), vol. 1, pp. 244–251. Alexandria, Egypt, July 2004. [Eng95] D. R. Engler, M. F. Kaashoek, and J. O’Toole. Exokernel: An operating system architecture for application-level resource management. In 15th ACM Symposium on Operating Systems Principles (SOSP ’95), pp. 251–266. Copper Mountain, CO, December 1995. [Ert06] E. Ertin, A. Arora, R. Ramnath, V. Naik, S. Bapat, V. Kulathumani, M. Sridharan, H. Zhang, H. Cao, and M. Nesterenko. Kansei: A testbed for sensing at scale. In 5th International Symposium on Information Processing in Sensor Networks, Track on Sensor Platform, Tools and Design Methods (IPSN ’06/SPOTS), pp. 399– 406. Nashville, TN, April 2006. [Eye] IST project EYES. http://www.eyes.eu.org/. [Gay03] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The nesC language: A holistic approach to networked embedded systems. In ACM Conference on Programming Language Design and Implementation (PLDI), pp. 1–11. San Diego, CA, June 2003. [Goe05] D. Goense, J. Thelen, and K. Langendoen. Wireless sensor networks for precise Phytophthora decision support. In 5th European Conference on Precision Agriculture (5ECPA). Uppsala, Sweden, June 2005. [Hal07] G. Halkes and K. Langendoen. Crankshaft: An energy-efficient MAC-protocol for dense wireless sensor networks. In 4th European Conference on Wireless Sensor Networks (EWSN ’07), pp. 228–244. Delft, The Netherlands, January 2007. [Han06] V. Handziski, A. Köpke, A. Willig, and A. Wolisz. TWIST: a scalable and reconfigurable testbed for wireless indoor experiments with sensor networks. In 2nd International Workshop on Multi-hop Ad Hoc Networks: from Theory to Reality (REALMAN ’06), pp. 63–70. Florence, Italy, May 2006.

BIBLIOGRAPHY

105

[Hei01] J. Heidemann, N. Bulusu, J. Elson, C. Intanagonwiwat, K. Lan, Y. Xu, W. Ye, D. Estrin, and R. Govindan. Effects of detail in wireless network simulation. In SCS Multiconference on Distributed Simulation, pp. 3–11. Phoenix, AZ, January 2001. [Hil00] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for networked sensors. In 9th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS IX), pp. 93–104. Cambridge, MA, November 2000. [Hil02] J. Hill and D. Culler. Mica: a wireless platform for deeply embedded networks. IEEE Micro, vol. 22(6):pp. 12–24, November 2002. [Hoe04a] L. van Hoesel and P. Havinga. A lightweight medium access protocol (LMAC) for wireless sensor networks. In 1st International Workshop on Networked Sensing Systems (INSS 2004). Tokyo, Japan, June 2004. [Hoe04b] L. van Hoesel, T. Nieberg, J. Wu, and P. Havinga. Prolonging the lifetime of wireless sensor networks by cross-layer interaction. IEEE Wireless Communications, vol. 11(6):pp. 78–86, December 2004. [Iva07] S. Ivanov, A. Herms, and G. Lukas. Experimental validation of the ns-2 wireless model using simulation, emulation, and real network. In 4th Workshop on Mobile Ad-Hoc Networks (WMAN 2007). Berne, Switzerland, March 2007. [Jam06] K. Jamieson, H. Balakrishnan, and Y. Tay. Sift: A MAC protocol for event-driven wireless sensor networks. In 3rd European Workshop on Wireless Sensor Networks (EWSN ’06), pp. 260–275. Zurich, Switzerland, February 2006. [Jia07] X. Jiang, P. Dutta, D. Culler, and I. Stoica. Micro power meter for energy monitoring of wireless sensor networks at scale. In 6th International Symposium on Information Processing in Sensor Networks, Track on Sensor Platform, Tools and Design Methods (IPSN ’07/SPOTS), pp. 186–195. Cambridge, MA, April 2007. [Kah99] J. Kahn, R. Katz, and K. Pister. Next century challenges: Mobile networking for “smart dust”. In 5th ACM/IEEE International Conference on Mobile Computing and Networks (MobiCom ’99), pp. 271–278. Seatle, WA, August 1999. [Kak05] V. Kakadia. Energy model update in ns-2. http://www.isi.edu/ilense/ software/smac/ns2_energy.html, 2005. [Klu07] K. Klues, G. Hackmann, O. Chipara, and C. Lu. A component based architecture for power-efficient media access control in wireless sensor networks. In 5th ACM Conference on Embedded Networked Sensor Systems (SenSys 2007), pp. 59–72. Sydney, Australia, November 2007.

106

BIBLIOGRAPHY

[Kot04] D. Kotz, C. Newport, R. S. Gray, J. Liu, Y. Yuan, and C. Elliott. Experimental evaluation of wireless simulation assumptions. In 7th ACM/IEEE International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM 2004), pp. 78–82. Venice, Italy, October 2004. [LAN99] LAN MAN Standards Committee of the IEEE Computer Society. IEEE Std 802.11-1999, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. IEEE, 1999. [Lan05] O. Landsiedel, K. Wehrle, and S. Götz. Accurate prediction of power consumption in sensor networks. In 2nd IEEE Workshop on Embedded Networked Sensors (EmNetS-II), pp. 37–44. Sydney, Australia, May 2005. [Lan06] K. Langendoen, A. Baggio, and O. Visser. Murphy loves potatoes: Experiences from a pilot sensor network deployment in precision agriculture. In 14th International Workshop on Parallel and Distributed Real-Time Systems (WPDRTS 2006). Rhodes, Greece, April 2006. [Lan08] K. Langendoen. Medium access control in wireless sensor networks. In Medium Access Control in Wireless Networks, Volume II: Practice and Standards, chap. 20, pp. 535–560. Nova Science Publishers, May 2008. [Lee07] H. Lee, A. Cerpa, and P. Levis. Improving wireless simulation through noise modeling. In 6th International Conference on Information Processing in Sensor Networks (IPSN ’07), pp. 21–30. Cambridge, MA, April 2007. [Li05] Y. Li, W. Ye, and J. Heidemann. Energy and latency control in low duty cycle MAC protocols. In IEEE Wireless Communications and Networking Conference (WCNC 2005), vol. 2, pp. 676–682. New Orleans, LA, March 2005. [Liu05] J. Liu, Y. Yuan, D. M. Nicol, R. S. Gray, C. C. Newport, D. Kotz, and L. F. Perrone. Empirical validation of wireless models in simulations of ad hoc routing protocols. Simulation, vol. 81(4):pp. 307–323, April 2005. [Lor04] K. Lorincz, D. Malan, T. R. F. Fulford-Jones, A. Nawoj, A. Clavel, V. Shnayder, G. Mainland, S. Moulton, and M. Welsh. Sensor networks for emergency response: Challenges and opportunities. IEEE Pervasive Computing, Special Issue on Pervasive Computing for First Response, vol. 3(4):pp. 16–23, 2004. [Mai02] A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. Anderson. Wireless sensor networks for habitat monitoring. In First ACM International Workshop on Wireless Sensor Networks and Application (WSNA 2002), pp. 88–97. Atlanta, GA, September 2002. [Mar04] C. Margi and K. Obraczka. Instrumenting network simulators for evaluating energy consumption in power-aware ad-hoc network protocols. In 12th International

BIBLIOGRAPHY

107

Workshop on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS 2004), pp. 337–346. Volendam, The Netherlands, October 2004. [Mil05] A. Milenkovic, M. Milenkovic, E. Jovanov, D. Hite, and D. Raskovic. An environment for runtime power monitoring of wireless sensor network platforms. In 37th Southeastern Symposium on System Theory (SSST), pp. 406–410. Tuskegee, AL, March 2005. [Par05] T. Parker and K. Langendoen. Guesswork: Robust routing in an uncertain world. In 2nd IEEE Conference on Mobile Ad-hoc and Sensor Systems (MASS 2005), pp. 691–699. Washington, D.C., November 2005. [Pha07] H. N. Pham, D. Pediaditakis, and A. Boulis. From simulation to real deployments in wsn and back. In 8th ACM International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2007), pp. 1–6. Helsinki, Finland, June 2007. [Pol03] J. Polastre and D. Culler. B-MAC: An adaptive CSMA layer for low-power operation. Tech. Rep. cs294-f03/bmac, UC Berkeley, December 2003. [Pol04] J. Polastre, J. Hill, and D. Culler. Versatile low power media access for wireless sensor networks. In 2nd ACM Conference on Embedded Networked Sensor Systems (SenSys 2004), pp. 95–107. Baltimore, MD, November 2004. [Pol05] J. Polastre, J. Hui, P. Levis, J. Zhao, D. Culler, S. Shenker, and I. Stoica. Unifying link abstraction for wireless sensor networks. In 3rd ACM Conference on Embedded Networked Sensor Systems (SenSys 2005), pp. 76–89. San Diego, CA, November 2005. [Raj03] V. Rajendran, K. Obraczka, and J. Garcia-Luna-Aceves. Energy-efficient, collision-free medium access control for wireless sensor networks. In 1st ACM Conference on Embedded Networked Sensor Systems (SenSys 2003), pp. 181–192. Los Angeles, CA, November 2003. [Ras89] R. Rashid, D. Julin, D. Orr, R. Sanzi, R. Baron, A. Forin, D. Golub, and M. B. Jones. Mach: a system software kernel. In 28th IEEE Computer Society International Conference (COMPCON ’89), pp. 176–178. IEEE Computer Society Press, San Francisco, CA, February 1989. [RFM] RFM. TR1001 868.35 MHz Hybrid Tranceiver. [Shn04] V. Shnayder, M. Hempstead, B. Chen, G. Werner-Allen, and M. Welsh. Simulating the power consumption of largescale sensor network applications. In 2nd ACM Conference on Embedded Networked Sensor Systems (SenSys 2004), pp. 188–200. Baltimore, MD, November 2004.

108

BIBLIOGRAPHY

[Sin98] S. Singh and C. Raghavendra. PAMAS: Power aware multi-access protocol with signalling for ad hoc networks. ACM SIGCOMM Computer Communication Review, vol. 28(3):pp. 5–26, July 1998. [Tak01] M. Takai, J. Martin, and R. Bagrodia. Effects of wireless physical layer modeling in mobile ad hoc networks. In 2nd ACM International Symposium on Mobile Ad Hoc Networking & Computing (MobiHoc 2001), pp. 87–94. ACM Press, October 2001. [Tal06] M. A. Taleghan, A. Taherkordi, and M. Sharifi. Quality of service support in distributed sink-based wireless sensor networks. In 2nd IEEE International Conference on Information and Communication Technologies: from Theory to Applications (ICTTA ’06). Damascus, Syria, April 2006. [TI] Texas Instruments. MSP430x1xx Family User’s Guide. [Tit05] B. Titzer, D. Lee, and J. Palsberg. Avrora: scalable sensor network simulation with precise timing. In 4th International Symposium on Information Processing in Sensor Networks (IPSN ’05), pp. 477–482. Los Angeles, CA, April 2005. [Tse02] Y. Tseng, C. Hsu, and T. Hsieh. Power-saving protocols for IEEE 802.11-based multi-hop ad hoc networks. In 21st Conference of the IEEE Computer and Communications Societies (INFOCOM 2002), vol. 1, pp. 200–209. New York, NY, June 2002. [Var01] A. Varga. The OMNeT++ discrete event simulation system. In 15th European Simulation Multiconference (ESM 2001), pp. 319–324. Prague, Czech Republic, June 2001. [WA05] G. Werner-Allen, P. Swieskowski, and M. Welsh. MoteLab: A wireless sensor network testbed. In Special Track on Platform Tools and Design Methods for Network Embedded Sensors (SPOTS) associated with IPSN’05, pp. 483–488. Los Angeles, CA, April 2005. [Whe01] D. A. Wheeler. SLOCCount. http://www.dwheeler.com/sloc/, 2001. [Wit07] G. Wittenburg and J. Schiller. A quantitative evaluation of the simulation accuracy of wireless sensor networks. In 6. Fachgespräch “Drahtlose Sensornetze” der GI/ITG-Fachgruppe “Kommunikation und Verteilte Systeme”, pp. 23–26. Aachen, Germany, July 2007. [Ye02] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient MAC protocol for wireless sensor networks. In 21st Conference of the IEEE Computer and Communications Societies (INFOCOM 2002), vol. 3, pp. 1567–1576. New York, NY, June 2002. [Ye04] W. Ye, J. Heidemann, and D. Estrin. Medium access control with coordinated, adaptive sleeping for wireless sensor networks. IEEE/ACM Transactions on Networking, vol. 12(3):pp. 493–506, 2004.

BIBLIOGRAPHY

109

[Ye06] W. Ye, F. Silva, and J. Heidemann. Ultra-low duty cycle mac with scheduled channel polling. In 4th ACM Conference on Embedded Networked Sensor Systems (SenSys 2006), pp. 321–334. Boulder, CO, November 2006. [Zhe05] T. Zheng, S. Radhakrishnan, and V. Sarangan. PMAC: an adaptive energy-efficient MAC protocol for wireless sensor networks. In 19th IEEE International Parallel and Distributed Processing Symposium (IPDPS 2005), pp. 65–72. Denver, CO, April 2005.

Summary MAC Protocols for Wireless Sensor Networks and Their Evaluation PhD thesis by G.P. Halkes

In Wireless Sensor Networks it is of vital importance to operate as energy efficient as possible. Since the radio of a sensor node consumes a lot of energy, it is important to control the radio such that it is used as efficiently as possible. This is the task of the Medium Access Control (MAC) protocol, which determines which node can send when and which nodes will be listening. By recording in the protocol at what times there will be no communication, it is possible to allow nodes to switch off their radios to save energy. Of course we cannot simply let nodes turn off their radios at random. Turning off the radio must be done in a coordinated fashion, and preferably in such a way that the most energy is saved. To optimise the energy savings, one first has to identify the sources of wasteful energy consumption in wireless MAC protocols: Idle listening: waiting for possible messages from neighbouring nodes, with the radio in listen mode. Collisions: two or more messages that arrive at the same node at the same time, resulting in undecodable messages. Overhearing: listening to messages destined for another node. Control packet overhead: control messages that MAC protocols send for robustness and coordination of message transmissions. These observations lead to the following high-level problem statement: How can we design and implement a MAC protocol that reduces the wasteful energy consumption as much as possible, within the constraints posed by the typical deployment scenarios for wireless sensor networks? Of course a lot of work has already been done in this area, so we focus dense networks in our design. Any proposed solution to the design problem automatically leads to a follow-up question: How can we evaluate to what extent we have succeeded in reducing wasteful energy consumption by the MAC protocol? 111

112

SUMMARY

We have approached the first part of the problem statement in two ways. Stemming from experiences with real deployments we designed the Crankshaft protocol, which specifically focuses on dense deployments where many nodes are deployed in a relatively small area. The large number of neighbour nodes mean that the problem of overhearing is an important source of wasteful energy consumption. The Crankshaft protocol uses receiver scheduling to save energy. The λMAC framework was designed to allow easy implementation of MAC protocols by allowing code sharing between implementations of different MAC protocols. By trying to apply the λMAC framework to our Crankshaft protocol, we found several areas in which the λMAC framework could be improved. The resulting updated λMAC framework is now general enough to allow implementation of an even wider range of MAC protocols, including Crankshaft. Our evaluation of the λMAC framework shows that the overhead is small. The second aspect of MAC protocol development, evaluation, is a theme that is found throughout this thesis. We have also approached this topic in two different ways. First of all we have shown the relative strengths and weaknesses of several protocols, including Crankshaft, through simulations. Second, we have contributed to the research into the methods used for MAC protocol evaluation. As our first contribution to the evaluation methods we have presented results obtained with the PowerBench architecture. The PowerBench architecture is a scalable modular architecture that makes it possible to measure the power consumption of all the nodes in a testbed. With this we have shown that the three-state model often used to estimate MAC-protocol energy consumption based on simulation results provides accurate estimates. In our second contribution to the MAC protocol evaluation methods, we have studied the validity of two reception models commonly used in simulators for WSN MAC protocols. Here, we have shown that the Signal-to-Noise Ratio model with additive signals captures most of the important characteristics of the wireless channel. The binary model in contrast, leads to results that significantly deviate from the real-world results obtained on our our PowerBench testbed. Our work has led us to the conclusion that MAC protocols are mostly created by combining existing concepts with a few new ideas, and therefore a more modular approach to building MAC protocols is desirable. Furthermore, even though we have made a first step to validate the models commonly used in MAC protocol simulators, more work is required to gain confidence in simulation results.

Samenvatting MAC-Protocollen voor Draadloze Sensornetwerken en Hun Evaluatie Proefschrift van G.P. Halkes

In draadloze sensornetwerken is het van vitaal belang om zo energiezuinig mogelijk te zijn. Aangezien de radio van een sensor node veel energie verbruikt is het van groot belang om de radio zo aan te sturen dat deze zo efficiënt mogelijk wordt gebruikt. Hierin is een belangrijke taak weggelegd voor het Medium Access Control (MAC) protocol, dat bepaalt welke node op welk moment mag zenden en welke nodes er dan luisteren. Door in het protocol vast te leggen op welke momenten er geen communicatie zal zijn, is het mogelijk om gedurende die periodes de radio uit te schakelen om zodoende energie te besparen. Natuurlijk kunnen we nodes niet zomaar willekeurig hun radio uit laten zetten. Het uitzetten van de radio moet gecoördineerd gebeuren, en liefst op een dusdanige manier dat er zoveel mogelijk energie wordt bespaard. Om de energiebesparing te optimaliseren moeten eerst de verspillingen van energie in kaart gebracht worden. In het geval van MAC-protocollen bestaan die uit: Idle listening: het met de radio in luisterstand wachten op eventuele berichten van naburige nodes. Collisions: twee of meer berichten die tegelijk bij een ontvanger aan komen, waardoor geen van de berichten te decoderen is. Overhearing: het luisteren naar berichten die voor een andere node bestemd zijn. Control packet overhead: de signaleringspakketten die door MAC-protocollen verzonden worden voor robuustheid en coördinatie van het zendverkeer. Deze observaties leiden tot de volgende probleembeschrijving: Hoe kunnen we een MAC-protocol ontwerpen en implementeren dat de energieverspilling zoveel mogelijk reduceert, binnen de beperkingen die daarbij opgelegd worden door de representatieve gebruiksscenario’s voor draadloze sensornetwerken? Natuurlijk is er al veel werk verzet op dit gebied, dus we concentreren ons op dichtbevolkte netwerken in ons ontwerp. Ieder voorstel 113

114

SAMENVATTING

voor een oplossing voor het ontwerp probleem levert direct weer een vervolgvraag op: Hoe kunnen we evalueren in hoeverre we geslaagd zijn in het reduceren van de energieverspilling door het MAC-protocol? Het eerste deel van de probleembeschrijving, de ontwerpvraag, hebben we op twee manieren benaderd. Geïnspireerd door onze ervaringen met uitgevoerde veldexperimenten hebben wij het Crankshaft protocol ontwikkeld, dat specifiek gericht is op dichte draadloze sensornetwerken waarin veel nodes in een relatief klein gebied staan. Het grote aantal buren zorgt voor veel overhearing, en het Crankshaft protocol gebruikt receiver-scheduling om energie te besparen. Het λMAC-framework is ontworpen om het mogelijk te maken gemakkelijk MAC-protocollen te implementeren door het delen van code tussen implementaties van verschillende MAC-protocollen te vergemakkelijken. Door te proberen het Crankshaft protocol te implementeren binnen het λMAC-framework, ontdekten wij een aantal gebieden waarop het framework kon worden verbeterd. Het resulterende bijgewerkte λMAC-framework is nu generiek genoeg om een nog breder spectrum aan MAC-protocollen te implementeren, inclusief het Crankshaft protocol. Onze evaluatie van het λMAC-framework laat zien dat de overhead van het λMAC framework klein is. Het tweede deel van de probleembeschrijving, de evaluatievraag, is een thema dat in heel dit proefschrift terugkomt. Ook met dit onderwerp zijn wij op twee manieren bezig geweest. Ten eerste hebben wij door middel van simulaties en experimenten de relatieve sterktes en zwakten laten zien van verscheidene protocollen, waaronder Crankshaft. Ten tweede hebben wij bijgedragen aan het onderzoek naar de evaluatiemethoden zelf. Onze eerste bijdrage aan het onderzoek naar evaluatiemethoden bestaat uit resultaten behaald met onze PowerBench testopstellingsarchitectuur die het mogelijk maakt om van iedere sensornode in de testopstelling het energieverbruik te meten. We hebben hiermee laten zien dat het drie-toestandenmodel dat vaak gebruikt wordt om het energieverbruik van een MACprotocol te schatten op basis van simulatieresultaten accurate schattingen oplevert. Als tweede bijdrage aan het onderzoek naar evaluatiemethoden hebben we de geldigheid van twee ontvangstmodellen die vaak gebruikt worden in simulatoren voor MAC-protocollen voor draadloze sensornetwerken bestudeerd. Hierbij hebben we middels experimenten op het onze PowerBench testopstelling laten zien dat het signaal-ruis-verhoudingsmodel de belangrijkste karakteristieken omvat. Dit in tegenstelling tot het binaire model welk leidt tot resultaten die sterk afwijken van de werkelijkheid. Op basis van ons werk concluderen wij dat MAC-protocollen voor het grootste deel gecreëerd worden door bestaande concepten met een paar nieuwe ideeën te combineren, en dat er een daarom een meer modulaire aanpak voor het bouwen van MAC-protocollen wenselijk is. En hoewel wij al een eerste stap gezet hebben in het valideren van modellen die vaak gebruikt worden in MAC-protocolsimulaties, is op dat gebied meer werk nodig om het vertrouwen in simulatieresultaten te vergroten.

Curriculum Vitae Gertjan Halkes was born the 17th of September 1979 in Arnhem, The Netherlands. In 1984 he moved with his parents to Heerhugowaard where he finished his secondary education at the Han Fortmann College (Dutch VWO level) in 1997. In 1999 Gertjan started his studies in Technical Informatics at the Delft University of Technology, for which he received a B.Sc. in 2002 (cum laude). Until 2004 he worked on completing his M.Sc. (cum laude) in the Parallel and Distributed Systems group during which time he also briefly served as a teaching assistant. Immediately after finishing his M.Sc., he started as a PhD student (Dutch: promovendus), again in the Parallel and Distributed Systems group at the Delft University of Technology.

List of Publications • T. Parker, G. Halkes, M. Bezemer and K. Langendoen. The λMAC framework: redefining MAC protocols for wireless sensor networks. Accepted for publication in Springer Wireless Networks. • G. Halkes and K. Langendoen. Experimental evaluation of simulation abstractions for wireless sensor network mac protocols. In 14th IEEE International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (IEEE CAMAD ’09). June 2009. • G. Halkes and K. Langendoen. Experimental evaluation of simulation abstractions for wireless sensor network MAC protocols. Tech. Rep. ES-2009-01, Delft University of Technology, P.O. Box 5031, 2600 GA, Delft, The Netherlands, 2009. • I. Haratcherev, G. Halkes, T. Parker, O. Visser, and K. Langendoen. PowerBench: A scalable testbed infrastructure for benchmarking power consumption. In International Workshop on Sensor Network Engineering (IWSNE), pp. 37–44. Santorini Island, Greece, June 2008. • M. Lodder, G. Halkes, and K. Langendoen. A global-state perspective on sensor network debugging. In 5th Workshop on Embedded Networked Sensors (HotEmNets 2008), pp. 37–41. Charlottesville, VA, June 2008. 115

116

CURRICULUM VITAE

• G. Halkes and K. Langendoen. Crankshaft: An energy-efficient MAC-protocol for dense wireless sensor networks. In K. Langendoen and T. Voigt, editors, 4th European Conference on Wireless Sensor Networks (EWSN 2007), vol. 4373 of LNCS, pp. 228– 224. Springer, January 2007. • G. Halkes, A. Baggio, and K. Langendoen. A simulation study of integrated service discovery. In P. Havinga, M. Lijding, N. Meratnia, and M. Wegdam, editors, 1st European Conference on Smart Sensing and Context (EuroSCC 2006), LNCS 4272, pp. 39–53. Springer, Enschede, October 2006. • G. Halkes, A. Baggio, and K. Langendoen. Overview of service-discovery protocols for mobile ad-hoc networks. Tech. Rep. PDS-2006-005, Delft University of Technology, P.O. Box 5031, 2600 GA, Delft, The Netherlands, September 2006. • G. Halkes, T. van Dam, and K. Langendoen. Comparing energy-saving MAC protocols for wireless sensor networks. Special issue of Kluwer MONET on WLAN Optimization at the MAC and Network Levels, vol. 10(5):pp. 783–791, October 2005. • K. Langendoen and G. Halkes. Energy-efficient medium access control. In R. Zurawski, editor, Embedded Systems Handbook, chap. 34. CRC press, 2005. • N. Reijers, G. Halkes, and K. Langendoen. Link layer measurements in sensor networks. In 1st IEEE International Conference on Mobile Ad-hoc and Sensor Systems. October 2004.