Distributed Systems

A Statistical Vector-basedRouting Protocol for

Wireless Sensor Networks

Rheinisch-Westfalische Technische Hochschule AachenLuFG Informatik 4 Verteilte Systeme

Diploma Thesis

Tobias Vaegs

Advisors:

M. Comp. Sc. Muhammad Hamad AlizaiM. Comp. Sc. Olaf LandsiedelProf. Dr.-Ing. Klaus Wehrle

Registration Date: 03. September 2009Submission Date: 18. March 2010

I hereby affirm that I composed this work independently and used no other than thespecified sources and tools and that I marked all quotes as such.

Ich erklare hiermit, dass ich die vorliegende Arbeit selbstandig verfasst und keineanderen als die angegebenen Quellen und Hilfsmittel verwendet habe.

Aachen, den 18. Marz 2010

Abstract

Establishing stable point-to-point multi-hop routing in Wireless Sensor Networks(WSNs) is challenging because of the dynamics inherent in wireless links. Rout-ing protocols based on virtual coordinates often restrict their routing decisions toconnections with a very high and stable quality to avoid the overhead induced byfrequent retransmissions and coordinate changes. A link estimator is used to identifystable links based on their quality calculated over a longer time period. However, thisapproach makes traditional routing protocols miss out on potential opportunities toreduce the hop count and the number of transmissions in the network provided bylong range intermediate links.

In this thesis we present Statistical Vector Routing (SVR), a protocol that efficientlydeals with communication link dynamics in wireless sensor networks. It assignscoordinates based on the statistical distribution of a node’s hop distance to a setof beacon nodes. The routing metric predicts the current location of a node inits address distribution. Our evaluation of a prototype implementation over realtestbeds compares SVR with a state-of-the-art virtual coordinates-based routingprotocol, i.e. Beacon Vector Routing (BVR). The results indicate that SVR reducesthe hop distance towards the beacons by 15% and achieves three times more stableaddressing when compared to BVR.

Kurzfassung

Stabiles Punkt-zu-Punkt Routing in drahtlosen Sensornetzen zu erreichen ist sehranspruchsvoll aufgrund der Dynamik drahtloser Verbindungen. Auf virtuellen Koor-dinaten basierende Routing-Protokolle schranken daher ihre Weiterleitungsentschei-dungen auf Verbindungen ein, die sehr hohe und stabile Qualitat aufweisen um dieKosten fur haufig zu wiederholende Ubertragungen und Anderungen in den Koor-dinaten zu minimieren. Ein Link Estimator wird verwendet um Verbindungen uberihre Langzeit-Qualitat als stabil zu identifizieren. Dieser Ansatz fuhrt jedoch dazudass traditionelle Routing-Protokolle potenzielle Gelegenheiten verpassen die Hop-Anzahl und die Anzahl der Ubertragungen fur Pakete im Netzwerk zu reduzieren,welche durch Verbindungen ermoglicht werden, die von mittelmaßiger Qualitat abergroßer Reichweite sind.

In dieser Arbeit prasentieren wir Statistical Vector Routing (SVR), ein Protokollwelches der Dynamik der Verbindungen drahtloser Sensornetze auf effiziente Art undWeise begegnet. Es ordnet Koordinaten zu, basierend auf statistischen Verteilungender Hop-Entfernung der Knoten zu bestimmten Beacon-Knoten. Die Routing-Metriksagt die aktuelle Position eines Knoten in dessen Adressverteilung voraus. UnsereEvaluierung einer Prototyp-Implementierung fur reale Testbeds vergleicht SVR miteinem aktuellen auf virtuellen Koordinaten basierenden Routing-Protokoll, BeaconVector Routing (BVR). Die Ergebnisse legen nahe dass SVR im Vergleich zu BVR dieHop-Entfernung zu den Beacon-Knoten um 15% reduziert und eine dreimal stabilereAdressierung erreicht.

Thanks

During my thesis I came to be grateful for all the people that supported me duringthis time. First of all, I would like to thank Prof. Dr.-Ing. Klaus Wehrle forgiving me the opportunity to write a thesis about this subject with his group, whichfascinated me from the beginning, and also for his help with realizing my futureplans. I am really glad that he brought such a great research group to our universityand does his part for great working conditions and a lot of fun during the workinghours. I also thank my second examiner, Priv.-Doz. Dr. Thomas Noll, for takingthe time to read and grade my thesis, too.

The second big pile of thanks goes to my supervisors Muhammad Hamad Alizaiand Olaf Landsiedel, who always found the right words to motivate me and to helpme through rough times during the thesis. Their input paired with their constantcalmness were a huge help. I also want to thank them for the insight they gaveme into the life of a PhD student, which further encouraged me to become onemyself. A special thanks for that goes to Olaf, as he recruited me as a HiWi and issignificantly responsible for my interest in research. I find it hard to thank both ofthem enough for motivating me again and again, inspiring me to a good performance,and providing me with the drive I needed to produce something I can be proud of.

I also have to thank my friends a lot for their support during this chapter of mylife, be it by giving feedback, answering questions, or providing moral support andunderstanding that from time to time and especially towards the end, the thesis de-manded a lot from me, and for understanding that my priorities shifted temporarily.Especially my girlfriend Stephie deserves my measureless gratitude for helping mein every way possible to her. The support and solicitousness I experienced from hermade coping with difficulties easier as well as enjoying achievements more intensive.I am so glad that she has been by my side during the second half of this project.

Furthermore, I would like to mention my colleagues, everybody that ran and runsaround in the rooms of the DS Group. I am glad that I will be around a bit longer.They all create an atmosphere that is really pleasant and fun to work in. I neverused the coffee maker praised everywhere, but the convenience store and the soccertable also helped a lot with having a nice day again and again.

Finally, I express my gratitude to my parents, who not only made my studies possiblein the first place but were always so full of support and pride as long as I canremember enabling me to first find and then pursue my goals freely thereby evolvingto someone I am proud of myself.

Thank you all so much!

Contents

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Our Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 5

2.1 Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Wireless Sensor Networks (WSNs) . . . . . . . . . . . . . . . . . . . . 6

2.3 Wireless Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Link Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Routing in Wireless Sensor Networks . . . . . . . . . . . . . . 13

2.4.2 Routing on Virtual Coordinates . . . . . . . . . . . . . . . . . 13

2.5 Pearson’s χ2-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Related Work 19

3.1 Routing on Virtual Coordinates . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Beacon Vector Routing (BVR) . . . . . . . . . . . . . . . . . . 20

3.2 Link Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 BVR’s Link Estimation . . . . . . . . . . . . . . . . . . . . . . 24

3.2.2 Four-Bit Link Estimation . . . . . . . . . . . . . . . . . . . . 25

3.2.3 Bursty Routing Extension . . . . . . . . . . . . . . . . . . . . 27

3.3 Link Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 The β-factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.2 Opportunistic Routing . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Our Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Analysis 37

4.1 Experimental Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Link Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Coordinate Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Design 45

5.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Address Derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 Statistical Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6 Implementation 57

6.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Neighbor Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4 Coordinate Distributions . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.5 Routing Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7 Evaluation 67

7.1 Memory Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.2 Finding Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . 69

7.3 Coordinate Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.4 Routing Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 Conclusion 77

8.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Bibliography 79

List of Figures 82

1Introduction

The world comes to discover more and more fields of application for Wireless SensorNetworks (WSNs). These networks normally consist of a large number of tiny devicescalled sensor nodes, which are equipped with sensors to measure certain conditions ofthe environment, a low power micro processor, limited memory, and a radio moduleto communicate with each other.

Because of the steady decrease in cost and size of these devices, more and more solu-tions using this technology become available. Their very limited capacity regardingcomputational power, memory, and energy, makes it necessary for sensor nodes toachieve their goals in a cooperative way. Furthermore, because of each node’s limitedradio range a data packet normally has to be relayed over several nodes to reach itsdestination, i.e. multi-hop routing has to take place.

Routing in WSNs entails a set of challenges, which are not common in other net-work scenarios. In traditional (wired) networks a good routing algorithm deliverspackets quickly, which usually means using only few hops on the way. Because theconnections between wired network nodes are stable, problems (i.e. packet loss) canmostly occur because of congestion at one of the participants on the route, whichthen leads to retransmissions or reroutes.

However, in wireless networks the connections between the devices are usually un-reliable. Packets can simply get lost in the air on the way to a node, which wasconsidered a direct neighbor of the sender. In this case the sender has to try againor select another next hop for its packet, either way a retransmission takes place.These retransmissions are not only more common than in wired networks, but alsohave to be considered more costly, since they waste energy, which is very limited ona sensor node and therefore far more precious here than on a device with a stable en-ergy supply. Thus, the total number of transmissions (i.e. hops plus retransmissions)has to be minimized to achieve a good routing performance.

2 1. Introduction

1.1 Problem Statement

As we have to assume unreliable links between participants in a wireless network, weare facing a tradeoff while trying to minimize the number of overall transmissions ina WSN. When selecting the next node to forward a packet to, a node has to chooseamong its neighbors. If a node is selected which is farther away from the currentnode and closer to the destination fewer relay nodes, i.e. hops, might be needed onthe way. However, the greater distance leads to a smaller probability for a successfultransmission, meaning a retransmission is more likely than with a neighbor closer tothe current node. There are basically two ways of dealing with this problem:

• A routing protocol could try to use only those links in the network, which arevery stable over a long period of time. In this case the routing protocol wouldrequire a link estimator, which constantly monitors and rates the connectionsto all neighbors. The protocol would then only use those links for routing,which over time show a high quality, minimizing the probability of retrans-missions. In doing so, it might miss out opportunities for shorter routes toa destination which are only available at times. Furthermore, this approachassumes that in fact there do exist sufficient long term stable connections inthe network to perform all the necessary routing when using only them. Oftenenough we cannot make that assumption.

• A routing protocol could not only use links which are to be considered sta-ble over a longer period of time, but also those whose quality fluctuates andwhich thereby only from time to time provide a quality good enough to sendpackets. It would then always use the node for routing which is closest tothe destination and is reachable right at the time a packet has to be sent. Inthis case the protocol would have to deal with the dynamics this approachintroduces, meaning constant topology changes because of nodes frequentlybecoming neighbors and non-neighbors of each other.

1.2 Our Approach

For this thesis we chose the latter approach. We used a virtual coordinate system,where the addresses of the nodes in the network are vectors of shortest hop distancesto some designated beacon nodes. This means when neighbor relations between thenodes change, their addresses are likely to change, too. A new neighbor mightprovide a shorter route to a beacon than the ones before, or the shortest route to abeacon so far was provided by a neighbor, which just had to be dropped.

This certainly causes a lot of address changes over time, which would lead to ahuge overhead for keeping the address information in the network up to date. Toavoid this, we do not route on the actual current coordinates of the nodes, whichchange far too often. Instead we let every node monitor its coordinate changes fora while, derive certain statistical values from this (e.g. the mean coordinates or theprobability distribution of the coordinates over a specified period) and then publishonly those statistical values in the network. Routing then takes place on these

1.3. Outline 3

statistical values provided by the nodes and not on their actual current coordinates.Our idea is based on the following assumptions:

• The statistical values derived from the coordinates change rarely enough overtime to not overwhelm the network with the overhead which comes with keep-ing this address information up to date. The ideal case would be that thevalues stabilize eventually and would never have to be changed again.

• If a node is still far away from the destination, it does not need its exact currentcoordinates to send the packet on the right way. The statistical values derivedfrom these coordinates suffice to at least get it in the right direction towardsthe desired node.

• Nodes which are close enough to the destination get to know its precise addressinformation and can deliver the packet directly.

1.3 Outline

The rest of the thesis is organized as follows. Chapter 2 provides basic backgroundknowledge about sensor networks, TinyOS, an operating system for sensor nodes,for which we developed our solution, link dynamics and link estimation, routing,especially routing on virtual coordinates, and a statistical test we used in our ex-periments to compare distributions, Pearson’s χ2-Test. The related work done inthe area of routing in WSNs is summarized in chapter 3. We present some link esti-mation mechanisms in use distinguishing between long-term approaches which leaveunstable connections unused and short-term approaches which react to the very cur-rent state of the network. We also introduce Beacon Vector Routing (BVR), whichwe use as a case study and which uses virtual coordinates for routing.

Chapter 4 presents our analysis of link dynamics. We explored how link qualitiesin a network change over time and how it affects the virtual coordinates of theparticipants. In chapter 5 we describe our design goals, what we want to achievewith our protocol and how we do it based on the results presented in chapter 4. Theimplementation details of our solution are presented in chapter 6.

Chapter 7 shows the results of our evaluation. We evaluate factors, such as memoryneeded on the nodes and data required to be sent for the protocol to work. Ourexperiments show how well the protocol performs regarding the number of transmis-sions and how it handles dynamics in the network. Finally, the thesis is concludedin chapter 8 and a brief outlook on future work is given.

4 1. Introduction

2Background

This chapter contains background knowledge enabling a better understanding ofthe rest of the thesis. First, we will have a close look on sensor nodes and theirarchitecture. Then, we will point out what separates WSNs from other networksto become aware of their special needs. After that, we will discuss the implicationsof these needs and of the dynamics of wireless links for the process of designing arouting protocol for WSNs and introduce routing on virtual coordinates, which weuse in our approach. Finally, we will describe Pearson’s χ2-Test, a statistical methodwe used for our analysis and evaluation.

2.1 Sensor Nodes

To grasp what separates wireless sensor networks from other networks and makesthem special one first has to get a good look at the components of such WSNs,namely the sensor nodes, also called motes. Sensor nodes are tiny autonomousdevices able to form a network and participate in it. Their general architecture isdepicted in Figure 2.1, and Figure 2.2 shows some examples of sensor nodes. Theyusually consist of one or more sensors to measure certain environmental conditionsand a micro-processor to process the gathered data. Furthermore, they are equippedwith a ROM to store a program image which can be executed by the processor, andsome RAM to save data. For exchanging information with other nodes they alsohave some kind of communication module, usually a radio transceiver. Finally, theyneed a power source, usually in the form of batteries, as they are supposed to beindependent from any stationary infrastructure.

The sensors on these nodes can gather rather simple data, e.g. about temperature,humidity, brightness, or vibration but also more sophisticated data such as audio orvideo input, which of course needs more energy. A node may also have actors tomanipulate its environment. These can again be simple ones such as LEDs, but alsospeakers or maybe the control of a valve or an engine. Furthermore, most sensor

6 2. Background

Micro-processor

Memory

SensorsRadio

Battery

Figure 2.1 Schematic architecture of a sensor node

nodes provide a way to be programmed easily, for example via an USB connector,often referred to as the serial interface.

Due to the small size and the consequential small amount of energy at its disposal,a single sensor node is a very limited device. The space and the energy it providesare usually not enough to support a fast micro-processor, large memory or a radiotransceiver with a big communication range. This is why programs developed forsensor nodes have rather few resources at their disposal compared to those on othermobile devices or even desktop PCs. Therefore, writing programs requires to thinkminimalist, meaning to focus on essential functionality. TinyOS [14] is a standardoperating system for sensor nodes providing just the very basic services an operatingsystem must have. This is why it is most suitable to support applications developedfor sensor nodes. It is written in nesC [9], a dialect of standard C.

A TinyOS program consists of several components and requires an event-based pro-gramming approach. A component can call an operation provided by another com-ponent and gets informed in the event of that operation being completed, meaninga designated event handler function to be implemented by the programmer is called.Also there are certain hardware interrupts, such as when a timer fires or the radiomodule receives a data packet, which also lead to the execution of the correspondingevent handler. TinyOS does not support several processes, but longer executionscan be implemented in a task, which can be put in an execution queue. Wheneverthere are no events to handle, TinyOS executes the tasks inside the queue one byone in a non-preemptive first-in-first-out manner, meaning there is no schedulingfor a parallel execution of any kind. TinyOS comes with a very powerful simulatornamed TinyOS SIMulator (TOSSIM) [13], which can simulate a program writtenfor TinyOS running on up to 1000 nodes simultaneously with the possibility of out-putting debug messages and testing programs with different network topologies andnoise conditions.

2.2 Wireless Sensor Networks (WSNs)

A wireless sensor network comprises many (10s to 1000s) sensor nodes working to-gether. Every sensor node has to make a small contribution to the goal the wholenetwork is supposed to achieve. In contrast to a traditional (general purpose) net-work, which can provide a lot of applications even simultaneously, a WSN usually isdesigned for one specific, comparatively small application. The origin of the sensornode technology lies in military usage, but nowadays also many civil applicationsfor WSNs exist. Among others, there are:

2.2. Wireless Sensor Networks (WSNs) 7

• Disaster recovery: In such situations there might neither be the possibilitynor the time to set up any fixed communication infrastructure.

• Animal behavior analysis: When nodes are small enough to attach themto animals – as it is being done in the RatPack project [4] – they can collectdata to analyse their behavior.

• Intelligent buildings: With information about the location of people, tem-perature, or air flow it is possible to control things such as heating or airconditioning more efficiently.

• Facility management: Nodes can detect leakages in tanks or provide intru-sion detection.

• Machine surveillance and preventive maintenance: Sensor nodes canobserve if machines work inside given parameter boundaries and maybe directlyreact to deviations or at least report them.

• Precision agriculture: Nodes on a field can give insight about the conditionof the ground enabling farmers to apply the optimal substances needed atexactly the right place.

• Medicine and health care: Patients who have to be monitored constantlywould not have to lie in bed or carry around cables and cumbersome devices.

• Logistics: Nodes attached to containers or boxes help identifying/trackingthose automatically and can report when their storage requirements are notmet, dangerous goods are too close to each other etc.

• Traffic: Intelligent roads could create statistics about traffic conditions toadminister traffic lights or allocate free parking spaces.

Looking at these applications it becomes evident that the requirements for a WSNdiffer quite significantly from those of a traditional network leading to multifariousdifferences between these network types.

First of all, traditional networks are usually designed to provide a service for someusers, which means the participating devices interact with humans. In a WSNthe interaction among devices themselves as well as the interaction between thedevices and the environment play a far more decisive role. Of course, people wantto use the service provided by a WSN, but this means having access to its gatheredinformation, which means the users do not interact with single nodes but with thewhole network. This is why WSNs usually perform data-centric networking. Theuser is not interested in the question where any data is stored or where it comesfrom exactly, but in the data itself. The user does not care about the identities ofthe nodes, but of course they are important for the network and its participants, forexample to perform routing.

Traditional networks, regardless if they are wireless or wired, need some kind ofgiven infrastructure, a backbone comprising routers, gateways, access points, radioposts, or cables. WSNs do not need this, and because every node is considered anequal part of the network, there normally does not exist any fixed infrastructure, as

8 2. Background

(a) The SenseNode from Genet-lab is used for intrusion detectionand classifies vehicles, armouredvehicles, animals, individuals, andgroups with or without gun.

(b) To study their behavioranimals are equipped withsensor nodes. This is donee.g. in the RatPack project.[4]

(c) The CASE Abyssfrom Abyssus MarineServices is used gatherof seismic data on theocean floor.

Figure 2.2 Examples for Sensor Nodes

the nodes may be deployed in remote and hostile environments. No central entitymanages their interaction, assigns roles or coordinates traffic. In WSNs most of thefunctions are performed in a distributed way.

Furthermore, the participants of a WSN are far more limited in their capacities thanthose of other networks, especially regarding energy, yet they have to be operationalover a very long period of time without any maintenance. Thus, they not only have tobe auto-configuring, fault tolerant and self-organizing, but also have to work energyefficiently to maximize their lifetime. Besides using low-power hardware, sensornodes have different power saving modes. They can power down almost completelyfor a certain period of time if they assume they will not have anything to do, butalso power down single components of their hardware temporarily.

Another way to save energy is the practice of in-network processing. Because sendingonly a few bytes over the radio is much more energy consuming than performing alot of computations on the processor, one always tries to process gathered data asmuch as possible on the node itself and only forward accumulated or summarizeddata. A simple example would be a query for the minimum temperature in a certainregion. To answer this each node would only have to forward the minimum ofits own data and all the data received from its neighbors, not both. Because theactual information provided by single nodes, i.e. the temperature in certain places,is not important but only the combined data provided by all the participants of thenetwork, i.e. the minimum temperature.

2.3 Wireless Connections

Connections between participants of a wireless network have a very different naturethan those of wired networks, since the air’s reliability as a communication mediumand the stability of signals propagating through it are not comparable with therespective properties of cables. A signal sent through a wire propagates directlytowards the destination. It may experience interferences or disturbances from the

2.3. Wireless Connections 9

environment caused by other signals nearby, but as it is shielded and isolated, theseinfluences are usually very small. It travels through a medium like copper, whichhas a very low electrical resistance to minimize the weakening of the signal overdistance.

Wireless signals, however, travel through air, a medium whose composition cannotbe controlled and which does not transport electromagnetic signals very efficiently.In vacuum the strength of a received transmission is proportional to 1/d2, d beingthe distance it covered from the sender to the receiver. Air may contain all kindsof gases, pollution, or rain, and there are obstacles such as vegetation, people, orbuildings on the way, which means air weakens a radio signal sent through it, andthis weakening effect varies due to weather, time of day, and time of year.

Although theoretically traveling along the direct line of sight, electromagnetic wavesare severely influenced by almost everything located on this line. Signals can bereflected on large planes, scattered at small obstacles or diffracted on edges. Thisleads to signals being received where no direct line of sight exists, but it also makessignal propagation less predictable. If sender or receiver are moving during thetransmission, the issue becomes even more complex, as phenomena like the Dopplereffect may have an impact on the signal, too.

Furthermore, if there are several devices using the same communication technology inproximity transmitting at the same time, their transmissions interfere. Thus, everysignal a device produces poses an interference all devices in the vicinity have to dealwith when receiving something. The area in which a device produces an interferencefor other signals by transmitting something is much bigger than its communicationrange in which its signal can actually be received correctly.

Another important problem arises from the inherent asymmetry of wireless connec-tions. If two nodes A and B are in proximity to each other and node A can receivepackets sent by node B, this does not necessarily imply the ability of node B to receivepackets from A. Reasons for this can be the two nodes having different transceiverhardware resulting in one of the nodes simply having a bigger communication rangethan the other.

However, also two identical nodes have an asymmetric connection, since a radiosignal is mostly disturbed by interferences at the receiver’s location. Node A maybe located in an area with a lot of noise produced by other participants constantlysending. This noise may not reach as far as to node B, but node A may not receiveanything addressed to it at all. Nevertheless, packets sent from node A to node Bmay be received without problems. Since it is only possible to establish a commu-nication between two participants of a network if both partners can receive eachother’s data, a communication protocol may only assume a connection between twonodes, if this connection has proved to be symmetric.

All this leads to links as well as connectivity between nodes being very unstablein a wireless network, especially in a low power network such as WSNs. Even ifthe nodes themselves do not move1 and even if there are no drastic changes in theenvironment, link qualities may change a lot over time. Because of these dynamicslink estimation on sensor nodes is a challenging task.

1In this thesis we do not explicitly cover node mobility. The dynamics we address are causedby the instability of wireless links or node failures.

10 2. Background

2.3.1 Link Estimation

Link estimation is the process of finding a way to predict the chance of being able touse a connection between two devices successfully for data packet transfer. A pas-sive link estimator listens to data packets the node sends and receives and therebydiscovers to which of its neighbors the node can communicate at the moment. Ac-tive link estimators (additionally) probe the connections to the neighbors of thenode periodically with designated packets to derive the link quality between theseneighbors.

Usually the Packet Reception Rate (PRR) of a link is used as a metric for its qual-ity, i.e. the percentage of successfully received packets during a given time interval.To appreciate the inherent asymmetry of wireless links, the product of the qualityof both link directions is considered the quality of the whole communication link,because this corresponds to the probability of both participants being able to commu-nicate with each other. Hence, test packets have to be sent by both communicationpartners to determine the PRR for each direction of the connection.

There are basically two possible approaches: long-term link estimation and short-term link estimation. A long-term link estimator identifies the neighbors of a nodewith a very stable connection, i.e. a constantly very high packet reception rate overa long period of time (good links, defined by us as having a PRR of >90%). Byrestricting communication to those good links one can ensure a lower number ofnecessary retransmissions. However, neighbors which provide such a good connectionare not likely to be very far away. Thus, the routing progress of each hop will notbe very high in a protocol only using these links, which usually are about 35% ofall the links in the network, as illustrated in Figure 2.3. All the possible otherlinks are left unused. Of course, the majority of these links are not worth beingused, because they provide a really bad quality (bad links, defined by us as having aPRR of <10%), but a few links can be considered to be of intermediate link quality(intermediate links, defined by us as having a PRR between 10% and 90%). Theseintermediate links usually do not have a constant intermediate quality but switchfrequently between good and bad link quality, because of short lasting interferencessuch as people passing by. This then leads to an intermediate average long-termquality measured for those links.

In contrast to this, short-term link estimators detect and use the short time periods,in which a link has a good quality, as they measure link qualities during a farmore narrow time period. It is not derived how many packets could be sent over aconnection in the last several minutes or seconds to have a list of neighbors readyin case data has to be sent. Instead one tries to determine on demand very quicklywhat quality a link provides right in the moment a packet has to be sent by usingthe success or failure of a packet to render a decision for the next. After somevery few successfully sent packets over a certain link the link estimator declares it apromising link making the routing protocol use it for packet transfer, whereas veryfew unsuccessful attempts to send a packet (usually only one) directly label a link asunreliable and stop the protocol from using it for a while. In this way, a protocol canuse a link of intermediate (fluctuating) quality in the short time periods in which itprovides a good quality and avoid using it during times with bad quality.

2.4. Routing 11

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

CDF

Long-Term�Link�Quality�(PRR)

Good�links�(quality�>�0.9)

Bad�links�(quality�<�0.1)

Intermediate�links

(0.1�<�quality�<�0.9)

~ 35%

~ 45%

~ 20%

Figure 2.3 Cumulative Distribution Function (CDF) of link qualities in a usualnetwork based on the packet reception rate (PRR)

This also means short-term link estimators can only operate if there are bursts ofdata to be sent, since they exploit the correlations between consecutive packets. Asuccessfully sent packet correlates with a high success probability for the next packetas well as an unsuccessful attempt to sent correlates with a low probability. However,this correlation becomes weaker as the time between the packets becomes larger.Hence, to take advantage of it a protocol has to use a link immediately, which is tobe considered promising because of some successfully sent packets. Furthermore, ithas to wait an appropriate amount of time after declaring a link not available beforetrying to use it again. If packets have to be sent only sporadically, short-term linkestimation in this form is not possible.

However, if applicable, short-term link estimators can adapt more quickly to changesin the network topology caused by node failures, node mobility or short-term inter-ference. They do not provide a big picture about the average qualities of the node’sconnections to its neighbors, but can make use of links with intermediate quality,which may provide shortcuts through the network as they are usually farther awayand thus may bring the packet closer to the destination when used as a next hop.Long-term link estimators generally rule out these links, as they concentrate on goodlinks, and frequent influences which disturb the communication only for a short timewill decrease the average long-term quality of a link constantly, thereby demoting itto one of intermediate quality.

Concrete examples of how link qualities are estimated can be found in chapter 3,where certain long-term and short-term link estimators as well as routing protocolsusing virtual coordinates are presented in detail.

2.4 Routing

Routing is the process of finding the way for a data packet through the network fromone specific participant to another. This route should be as short as possible for the

12 2. Background

A

B

E

I

G

J K

H

F

D

C

(a) Example topology of the network

A

B

C

D

E

F

G

H

I

J

K

2(C)

2(C)

3(I)

3(F)

2(E)

3(I)

4(J)

2(B)

2(B)

4(K)

2(F)

3(E)

4(K)

3(H)

3(B)

2(C)

3(B)

4(K)

2(F)

4(E)

4(K)

3(H)

2(B)

3(C)

3(C)

2(I)

4(F)

2(I)

3(J)

3(B)

2(C)

3(B)

3(K)

4(E)

3(K)

2(H)

3(E)

3(E)

4(B)

4(F)

2(I)

3(H)

2(K)

4(B)

3(C)

2(F)

2(F)

4(B)

2(K)

3(G)

2(K)

2(E)

2(E)

3(B)

4(C)

4(H)

3(K)

2(J)

3(E)

3(E)

4(B)

4(F)

2(I)

3(H)

2(K)

4(E)

2(B)

2(E)

3(C)

3(C)

3(I)

4(F)

3(I)

4(J)

A B C D E F G H I J K

4(C)

3(F)

3(F)

3(I)

2(H)

2(J)

1

1

-

1

1

-

1

1

1

-

1

1

1

-

1

1

1

-

1

-

1

1

1

1

-

1

1

1

-

1

1

1

-

1

-

1

1

1

1

1

-

fromto

(b) Distance vectors of the nodes in the net-work (table rows)

Figure 2.4 Example for Distance Vector Routing: Each row of the table is a dis-tance vector stored on the node denoted in the first column. A distanceof one implies a direct connection to the destination named in the toprow. The letter inside the brackets states the next hop to send a packetto on the way to the destination. Sometimes there are several possi-bilities, for example from node H to node E there exist three routes ofequal length. Hence, the corresponding table entry could also be 4(k).In such a case another metric can be consulted to decide on the entry,e.g. the nodes’ workload.

packet to be delivered quickly. Traditional (wired) networks such as the Internet orparts of it usually have a stable infrastructure, a backbone with a given topologyand hierarchy, over which packets can be routed. Because of the stable connectionsinside the backbone, packets can travel fast, since every node on the way alwayschooses the neighbor as the next hop which is closest to the destination. Because ofthis stability, routes in a traditional network are also quite stable, i.e. packets from aspecific sender to a specific destination most of the time take the same route. Everynode in the network stores a routing table, which provides information on where toforward a packet to on the way to a certain destination.

A common class of traditional routing protocols are the distance-vector routing pro-tocols. Using these protocols routers keep a vector of minimum hop distances toall the other participants in the network. They inform their neighbors about thosedistances and update them according to the vectors, which they receive from theirneighbors. Over time every node derives a distance and next hop for every othernode in the network. With this information they can route packets along the short-est path from their position to the destination by always selecting the neighbor asthe next hop which has the smallest distance to the destination.

Retransmissions can occur on the one hand in case connections break or topologieschange, which is very rare, since backbones of big networks are not supposed to bealtered a lot and are usually very reliable. However, a packet can be dropped by arouter if that router is currently under too much load to process further packets, i.e.if it is congested. In this case, the node which wanted to use this congested routeras a next hop has to choose another neighbor to forward the packet to or wait sometime and try the same node again, either way it has to retransmit the message.

2.4. Routing 13

2.4.1 Routing in Wireless Sensor Networks

Because of the limitations the sensor nodes present, traditional routing protocols arenot suitable for WSNs, since they are not scalable. A sensor node does not havethe memory necessary to store a big routing table such as a distance vector withinformation about the whole network. It usually knows about its direct neighborsbut has only very limited knowledge about the rest of the nodes. Searching insidea big table also would take some time on a processor as limited as those used onsensor nodes.

Additionally, in distance-vector routing protocols far too much time is needed topropagate the distance information throughout the whole network until every partic-ipant has a stable knowledge about the network topology at its disposal. In wirelessnetworks, especially in highly dynamic ones such as WSNs, topologies change fartoo often to ever reach a stable state to be published to all the participants.

Furthermore, the hop distance between two nodes is not a meaningful metric inwireless networks, where connections are rather unreliable because of the radio signalgetting weaker over distance very quickly. This means with increasing distance ofsender and receiver the probability of a packet arriving successfully decreases rapidly.Hence, choosing the closest node to the destination as a next hop may help to reducethe number of hops needed for the packet to arrive, but may simultaneously increasethe probability of packet losses and thereby of retransmissions. In wired networksretransmissions can mostly be neglected, since they are quite rare. However, inWSNs they are not only far more common (as WSNs are wireless) but also far moreexpensive (as energy is very limited and radio communication needs a lot of energy).Thus, the neighbor which brings the packet the farthest towards the destination maynot necessarily be the best choice as the next hop of a route.

Therefore, routing protocols for wireless networks often use the Expected Transmis-sion Count (ETX) as a distance metric between nodes. It is the expected (mean)number of times the sender has to transmit a packet to a receiver before it is receivedsuccessfully, i.e. the reciprocal of the probability of a packet sent by the sender ar-riving at the receiver in the first attempt. On a certain path between two nodesthe sum of the ETXs assigned to the connections on the way measures the numberof transmissions needed to deliver a packet over this path, meaning the number ofhops plus all retransmissions expected due to packet loss. Hence, in wired networksthe ETX of a path would almost equal the hop distance, since there are very fewretransmissions to be expected. In our experiments we always used the total numberof transmissions needed to deliver a message from a sender node to a destinationnode as a metric for the performance of our routing protocol.

2.4.2 Routing on Virtual Coordinates

A lot of applications for WSNs are designed in a way that all the nodes in the networkgather some data, which is supposed to arrive eventually at one specific node (a socalled sink). This sink may be a gateway node to another network e.g. the Internetor a node to which the user has direct access to query the data. The Collection TreeProtocol (CTP) [10] for example uses this design, which is illustrated in Figure 2.5.

14 2. Background

A designated sink node sends periodic beacon packets into the network advertisingits existence. These beacon packets are forwarded by the other nodes throughout thewhole network. Inside the packets the respective senders always state their distanceto the sink node.

To derive this distance a node has to calculate the costs for a packet to travelover any of its neighbors by adding the distance it received from a neighbor to thecosts of its connection to this neighbor (the costs can be defined as the ETX of theconnection or any other suitable metric). The node then publishes the minimumof those calculated costs, i.e. the expected number of transmissions when routinga packet over it. Because in a collection tree there is basically only one directionin which packets have to be sent, routing is quite simple: A node always routes apacket to the neighbor with the minimum costs for a packet to travel to the sink.This neighbor is called its parent. Because with this topology a node basically onlyhas to remember which node is its parent, the required memory is rather smallcompared to a full-grown routing table filled with information about a lot of nodes.

This many-to-one or one-to-many schema (depending on if the sink collects or dis-tributes data) is widely used in WSNs, because it fits the nature of a lot of ap-plications in this area. However, in this thesis we want to design a point-to-point(or any-to-any) routing protocol which can deliver a packet from any node inside anetwork to any other node. For this we need an addressing schema, which reflectsthe location of the nodes relatively to each other, such that a packet can be routedaccording to these addresses.

For the addressing of the nodes we build up a virtual coordinate system. Thecollection tree of CTP can be considered the one-dimensional special case of this idea,where every node derives the path costs from itself to the sink node and publishesthis value as its current address. If there are several sink nodes in a network, everynode can derive a cost vector for the paths to all these nodes. If those nodes (the socalled beacons) are numerous enough and distributed evenly throughout the wholenetwork, they provide the intended coordinate system.

A higher value in one component of the distance vector not necessarily implies butcorrelates with a greater distance to the respective beacon. This means we can as-sume nodes with similar coordinates to be located in vicinity of each other. Hence,forwarding a packet to the neighbor closest to the destination translates to for-warding it to the neighbor whose coordinates are the most similar to those of thedestination. An example for routing on virtual coordinates is given in Figure 2.6.

2.5 Pearson’s χ2-Test

Pearson’s χ2-Test serves to find out whether or not a given frequency distributionof events is consistent with another distribution. An example for this would beto test the distribution of the results after rolling a dice several times against thetheoretical distribution of results expected after rolling a perfectly fair dice (whereeach number between 1 and 6 is shown exactly a sixth of the times the dice is rolled).It is important that all possible events (in the example the numbers 1 to 6) togetherhave a probability of 1 and are mutually exclusive, i.e. there cannot be a 1 and a 3on top of a dice at the same time.

2.5. Pearson’s χ2-Test 15

sink

0

1

1

(a) First step: A beacon packet issent by the sink and all its neighborsacknowledge it as their parent.

sink

0

1

1

2

2

(b) Second step: The direct childnodes of the sink forward the beaconpacket with an increased distance in-side to become parents on their part.

sink

0

1

1

2

2

3

3

3

3

(c) Third step: Every node which hasfound a parent starts participating inforwarding the beacon message.

sink

0

1

1

2

2

3

3

3

3

4

4

(d) Fourth step: This proceduregoes on until the beacon packet hasreached all network participants.

Figure 2.5 Creation of a collection tree: Bold lines illustrate parent relations, thenumber inside a node its distance to the sink. In this example stablelinks are assumed resulting in costs of one for every edge in the graph.

The test has two applications: It is a test of goodness of fit which shows how muchtwo distributions (usually an observed one and a theoretical one) differ from oneanother. It is also a test for independence of paired observations, for example to testif the age of people correlates with their affinity for a certain political party. As weuse only the first application in our experiments, we will also limit our explanationhere to the test of goodness of fit.

First of all, given two distributions to compare one has to calculate the χ2 statisticfor them, called X2. It is defined as

X2 =n∑

i=1

(Oi − Ei)2

Ei

where n is the number of categories of the distributions (in the example with the dicen would be 6), Oi is the number of times an event out of the i-th category occurredin the observed distribution (The experiment with the dice would have the categories1, 2, 3, 4, 5, and 6.), and Ei the number of events of the corresponding categoryin the theoretical (expected) distribution. Secondly, the degree of freedom has to

16 2. Background

B1B2

B3

0,3,3

1,3,2

2,4,1

2,1,4

3,4,04,3,1

4,2,2

3,1,3

3,4,1

1,2,3 3,0,4

S

R

(a) Using B1, B2, and B3 as beacons, thenodes will derive these address vectors.

D=4

D=7

D=6

B1B2

B3

0,3,3

1,3,2

2,4,1

2,1,4

3,4,04,3,1

4,2,2

3,1,3

3,4,1

1,2,3 3,0,4

S

R

(b) S calculates the difference D of itsneighbors’ address vectors to the vector ofR and sends the packet to the node withthe most similar address (4,2,2).

B1B2

B3

0,3,3

1,3,2

2,4,1

2,1,4

3,4,04,3,1

4,2,2

3,1,3

3,4,1

1,2,3 3,0,4

D=3

D=6

S

R

(c) In the next step 3,1,3 is chosen, afterthis the options become fewer. The ar-rows depict the complete route taken bythe packet.

B1B2

B3

0,3,3

1,3,2

2,3,1

2,1,2

3,3,03,3,1

4,2,2

3,1,3

2,2,1

1,2,2 3,0,3

D=6

D=3

D=4

S

R

(d) If the protocol does not concentrateon long-term stable links, the temporalavailability and use of unstable connections(dashed lines) can lead to a lot of changesin addresses and routing decisions.

Figure 2.6 Routing on virtual coordinates: B1, B2, and B3 are the beacons defin-ing the coordinate system, S is the sender and R the receiver of theexample packet. For simplicity all edges have costs of one.

be determined. It is the number of independent frequencies in the distribution. Inmany cases this is n−1, since the frequency of one event is always determined by thetotal number of event occurrences. The degree of freedom however is independentof the total number of frequencies. For example, the number of times a 6 was dicedis always the total number of events minus the sum of the frequencies for the results1 to 5, and this holds for every total number of events, i.e. regardless if the dice wasrolled 100 or 10,000 times in total. If the different categories of the distribution arefurther dependent, the degree of freedom might be even lower. In our experimentswe always find the degree of freedom to be n− 1.

The next thing to do with the X2-value and the degree of freedom is to derive thecorresponding p-value. The calculation is out of the scope of this thesis, there aremany calculators and tables to derive it. A p-value always has a meaning regardinghypotheses. The statistical hypothesis in the case of this test is that the observeddistribution is equal to the expected one. The X2-value already states how differentthey are. However, the value also becomes bigger as the distributions contain more

2.5. Pearson’s χ2-Test 17

data. Also, these differences between the two distributions may be due to randomvariation. Thus, we need the p-value to decide on the statistical significance of theX2-value. A statistic is defined as being statistically significant if it is unlikely to beobtained only by chance, i.e. if it is likely to really mean something.

The p-value for a given X2-value and degree of freedom is the probability of X2

being at least as high as it is only due to chance, i.e. the probability of the twodistribution’s deviations being random variations. Thus, p is the chance to makethe mistake of denying the hypothesis of equal distributions while they in fact areequal. On the other hand, if the p-value is high, there is a good chance the twodistributions appear different because they really are different and the deviationsreally are substantial. This is the reason why the p-value is an indicator for thesignificance of the result. Usually statistical tests have a significance level of 5% or1% meaning the p-value has to be at most 0.05 or 0.01 respectively for the hypothesisto be denied, i.e. to consider the distributions different.

18 2. Background

3Related Work

There are countless routing protocols proposed for any kind of network type. Asmentioned before, among those designed for WSNs many protocols only supportmany-to-one data traffic, as this is a common scenario in this domain. Point-to-point traffic (as we intend to provide) is much more challenging especially in WSNs,because more information is needed and routes are more complex to find. A lot of ap-proaches aiming at tackling this can be found in [18]. One can divide them into fourmain categories [8]: shortest path, hierarchical addressing, geographic coordinates,and virtual coordinates.

• Shortest Path: This basically covers distance vector algorithms, adapted tothe wireless domain, which we already referred to in section 2.4. Aside fromthe fact that usually on sensor nodes there is not enough space to store theinformation needed for this, the instability of topologies in WSNs does notleave enough time to publish a state throughout the entire network before itchanges significantly.

• Hierarchical Addressing: This works fine in fixed networks such as withIP-addressing in the Internet, where it is easier to make the addressing schemareflect the connectivity relation between the nodes. However, in WSNs connec-tivity depends on the environment, which is hard to predict and too unstableto use for addressing. Even if it was usable, it would produce unacceptableoverhead.

• Geographic Coordinates: Mapping the actual location of the nodes intothe addressing schema assumes the availability of geographic information (asprovided by GPS), a certain minimum precision of this information and thatgeographic distances of the nodes correlate with their connectivity. Further-more, this connectivity is assumed to be symmetric.

• Virtual Coordinates: Since our approach belongs in this group, we discussit in more detail.

20 3. Related Work

3.1 Routing on Virtual Coordinates

Protocols belonging to this class use a designated subset of the nodes in the networkto function as beacons, i.e. artificial landmarks. All other nodes define their locationrelatively to each other by their distance to these beacon nodes. Their real distance,of course, would be very hard to derive for devices as limited as sensor nodes, evenif the beacon nodes were aware of their actual geographic location. Approacheswithout the need for real geographic coordinates are for example NoGeo [17] andGEM [15], which lack practical applicability because of too much node state andmessage overhead for coordinate construction and maintenance. To our knowledgethe only practically usable and published implementation of a point-to-point routingprotocol is Beacon Vector Routing (BVR), which is why we used it as a case studyfor our approach and compared our evaluation results to BVR.

In the rest of this chapter we explain how BVR works in detail and present someexamples for link estimators (the one BVR uses and the Four-bit link estimator)as well as the Bursty Routing Extension to convey an impression of different wayshow link estimation can be done. Furthermore, two ideas how to use certain linkdynamics to increase the network throughput are discussed. At the end we pointout how our protocol differs from the approaches presented here.

3.1.1 Beacon Vector Routing (BVR)

Beacon Vector Routing (BVR) [8] manages a set of (randomly chosen) beacon nodes.Every node determines its distance to all the beacons and declares the vector ofthese distances its address in the network. To accomplish this, every node (not onlythe beacons) periodically sends out beacon messages to its neighbors containing itscurrent address vector and constantly updates this vector according to the messagesit receives. Because of the unreliable nature of wireless links, BVR nodes do not useall of their potential neighbors. Only those to which their connection has a stablelong-term quality can be elected as parents or next hops when forwarding packets.This is why not always the neighbor with the smallest hop distance becomes theparent of a node. The details of the parent selection are described in section 3.2.1,where BVR’s link estimation process is presented. With established coordinates agreedy distance-minimizing routing algorithm is used to deliver data packets. Forthis, BVR defines a distance metric δ(p, d) on the address vectors, which determineshow well a node p would be suited as a next hop on the route to the destination d.

The intuition behind this metric is that the packet should be routed to the node,whose address vector is most similar to the one of the destination. For this, in everyrouting decision the absolute vector distance between the destination’s address andthe next hop’s address has to be minimized. In the published formulas this is done forthe k beacons closest to the destination d making the adjustment of k a possibilityof saving packet size. Yet the available implementation uses all beacons for thecalculations. Transmitting a packet in direction towards a beacon is consideredbetter than getting farther away from it, since moving away may lead to increasingthe distance to the destination in case it is located on the opposite side of the beacon(cf. Figure 3.1). This intuition is reflected in the following formulas:

3.1. Routing on Virtual Coordinates 21

B

S

D

D

(a) S is farther away from B thanD. Therefore, it has to send towardsB, which means into the grey circleand thereby definitely also towardsD, wherever it may be.

D

B

D

S

(b) S is closer to B than D.Therefore, it has to send awayfrom B, meaning in some di-rection outside the grey circle,which may or may not be to-wards D.

Figure 3.1 Illustration for routing steps towards beacons assuring progress whereasrouting further away does not: With given coordinates, the destination(D) has to be located somewhere on the black circle around the beacon(B). The sender (S) has to elect the next hop for a packet route.

δ+(p, d) =∑

i∈C(d)

max(pi − di, 0)

δ−(p, d) =∑

i∈C(d)

max(di − pi, 0)

δ+(p, d) is the vector distance of the possible next hop’s address and the destination’saddress restricted to those components which correspond to the beacons which arecloser to d than to p. δ−(p, d) represents this distance for the other components, i.e.those corresponding to beacons farther away from d than from p. Because of thephenomenon explained above, δ+ has to be minimized with priority to advantagemoving towards beacons. Only in case of a tie this has to be broken by minimizingδ− as well. In the actual implementation this is accomplished by always minimizingδ = Aδ+ + δ− for a factor A, large enough to realize the higher priority of the firstsummand (10 in BVR’s implementation). Beside the destination’s coordinates andits unique identifier, which is made necessary by the possibility of duplicate coor-dinates and to preserve consistency of identities, every packet carries the minimumdistance δmin reached so far on the route. To avoid routing loops, forwarding apacket always has to decrease this distance.

Having found a list of suitable neighbors, a node uses up to five retransmissionsmanaged by lower layers to the neighbor at the top of the list. If all those fail, thenext neighbor in the list is tried. For the case in which the end of the list is reached orit was empty in the first place, because of low connectivity or the inability of findinga next hop which decreases δmin, BVR defines a fallback mode in which the packet

22 3. Related Work

is routed towards the beacon closest to the destination. If the smallest componentof the destination’s address vector is at position i, then the packet is sent to theforwarding node’s parent number i, which then proceeds with the normal greedyrouting algorithm. Every time a node has to resort to the fallback mode the packetapproaches the beacon closest to the destination a bit more, which can ultimatelylead to the packet arriving at this beacon. After having received the packet, thebeacon will also attempt the normal greedy distance-minimizing routing algorithm.If this fails again, it starts a scoped flooding, sending the packet n hops into thenetwork with n being the ith component of the destination’s address vector, as thisis an upper bound for the distance between the beacon and the destination. Theauthors claim their design to be a guarantee for every packet to reach its destinationin a fully connected network.

BVR offers a number of advantages over other protocols. The algorithm is compar-atively simple meeting the requirements of devices with limited capacities such assensor nodes. It requires only little state on the nodes, as they only have to storeinformation about their direct neighbors. This neighbor information is based on con-nectivity, which the nodes are aware of anyway, meaning no additional mechanisms(e.g. deriving real geographic locations) are needed to collect it. For the greedyforwarding no assumptions have to be made about geographic information, beaconstructure or the topology of the nodes. During the equally simple coordinate con-struction algorithm several trees are constructed, but packets are not routed alongthem. Instead BVR provides point-to-point packet delivery, which together with itsother advantages makes us consider it the state-of-the-art implementation for thesekind of protocols and therefore the ideal comparison for our prototype.

Another proposed routing protocol very similar to BVR is Logical Coordinate Rout-ing (LCR) [5], which has four main differences:

• Nodes correct invalid coordinates and hop count differences to a neighborgreater than one with information from their vicinity.

• Routing loops are avoided by using source routing. The last hops of the routea packet has taken are sent along in the packet as well as a time to live (TTL).

• The fallback mode differs from the one in BVR. The procedure called voidavoidance by LCR’s authors is executed when a node does not have a neighbor,which is closer to the destination than itself, i.e. a neighbor underbidding thecurrent δmin. In this case the packet is forwarded to the neighbor closest tothe destination. Thereby flooding is avoided, but at the expense of a lowerprobability of packets reaching their destination. A counter to log how manytimes the void avoidance had to be done is included in the packets and theyare dropped if it exceeds a certain threshold.

• LCR uses a different distance metric to compare address vectors, which issimpler than the one used in BVR:

D =

√√√√ n∑i=1

(Vi −Wi)2

3.2. Link Estimation 23

0

0.2

0.4

0.6

0.8

1

0 100 200 300 400 500

Link�Quality

Time�(seconds)

measuredWMEWMA�(t=20�sec,�alpha=0.6)

Figure 3.2 Impression of the inability of long-term link estimators to capture short-term fluctuations in link quality: Depicted is the actual real time linkquality (dotted line) compared to the quality measured by a long-termlink estimator using the WMEWMA approach presented in [22]. [2]

3.2 Link Estimation

Long-term link estimators monitor the connections of a node to its neighbors over arather long period of time and derive the packet reception rate (PRR) or some othermetric for the average long-term quality of the link. In this way, routing protocols canconstrict their routing choices to links with good long-term quality or at least alwaysselect the link with the best quality to forward a packet to. Since only long-termlink estimators monitor connections over time, only they can detect intermediatequality links. During a short time a link has a good chance of appearing perfect ornon-existent, since it may be operational or not operational the whole time. Whenlooking at a larger time scale, the link is more likely to alternate between thesebehaviors leading to the estimator deriving an intermediate long-term quality forit. Thus, the probability of a link belonging to this intermediate class (i.e. linkswith a PRR between 10% and 90%) increases as the time period it is monitoredbecomes larger. We present the long-term link estimator used by the Beacon VectorRouting protocol (BVR) in section 3.2.1 and the Four-bit (long-term) link estimator,currently for example used by CTP, in section 3.2.2.

Since changes in the dynamics of links in a network often happen on a sub-secondlevel, long-term link estimators are unable to capture them. They cannot adapt toshort-term link quality changes and therefore generally adapt more slowly, whichcan be observed in Figure 3.2. Another fact long-term link estimators do not takeinto account (because it does not concern them) is the correlation of packet lossesand packet successes at a short time scale, such as short-term link estimators tryto detect and use. Because with intermediate links quality changes appear veryfrequently, a successful packet increases the probability of further packets being sentsuccessfully only for a very short time as well as a packet loss does not necessarilymean the link will be constantly unavailable but only in the current instant and alittle bit later [1]. Because they can detect them, short-term link estimators take

24 3. Related Work

advantage of the opportunities intermediate links offer, such as temporary shortcutsin the network, which are likely, as with increasing distance the chance of findinggood quality links diminishes while the probability for intermediate links rises. Wepresent the Bursty Routing Extension, which is a short-term link estimation conceptto be integrated into traditional routing protocols using long-term link estimation,in section 3.2.3.

3.2.1 BVR’s Link Estimation

Beacon Vector Routing (BVR) [8] is a routing protocol for point-to-point data traffic.Its functioning is described in section 3.1.1. Here we want to concentrate on the linkestimator used in BVR. Since every node’s coordinates are supposed to represent hopdistances to the beacons, the nodes monitor the connections to all their neighborsconstantly. Only those neighbors to which the connection is of very high and stablequality are used by the nodes for deriving their coordinates as well as for routingpackets.

To select the usable subset of all neighbor connections a passive link estimator isused which snoops all packets in the node’s reception range, enabled by the broadcastnature of wireless connections. Additional link estimation packets are not needed,but the nodes are required to receive every packet even when no data addressed tothem is to be expected, which costs more energy.

Furthermore, passive link estimation always bares the problem of detecting packetloss not before the next successful packet is received and thereby a gap in the se-quence numbers is detected, with which every outgoing packet is tagged before itstransmission. By means of this numbering nodes can determine how many packetsthey received from a neighbor and how many they missed. Another way to handlethis problem and to avoid the delay in packet loss detection is to assume a minimumdata rate in the network, which often enough is realistic in WSNs. BVR uses bothmechanisms, as the “hello” messages periodically sent by the nodes to communicatetheir coordinates to their neighbors implies a lower bound for the frequency of sentpackets from every node.

Because communication partners in wireless networks always may have an asym-metric connectivity, these link quality estimations can only provide information forincoming links from neighbors of the node. This lack of information is tackled by pe-riodically broadcasting a neighbor list. This information lets nodes use good qualityincoming links for routing and to derive the node’s coordinates, if the correspondingneighbors attest good outgoing link quality as well. For the latter every node has todecide which of its neighbors is best connected to a certain beacon and choose thisone as its parent in this beacon’s tree. The instability of wireless connections leadsto the fact that the best connected neighbor does not have to be the one with thesmallest hop count towards the beacon, although the coordinates itself comprise hopdistances. Therefore, a metric called expected progress, which combines link qualityand progress, is used to determine the best neighbor to become a parent. It is de-fined as hops times link quality to a neighbor, the latter being represented by theexpected number of transmissions (ETX), i.e. the reciprocal of the packet receptionrate (PRR).

3.2. Link Estimation 25

The logic of the link quality estimation itself (i.e. calculating the PRR) is basedon the approach presented by Woo et. al. [22]. No complex calculations to derivelink quality are possible on sensor nodes. Therefore, this relatively simple algorithmwas chosen in BVR, a window mean with an exponentially weighted moving average(WMEWMA). It calculates the success rate of the packet delivery (i.e. the PRR)for the recent past. How far this goes back in time is defined by t, the numberof message opportunities to consider. The total number of packets inside the timeframe is at least the number of expected packets (regarding the assumed minimumdata rate). If more packets have been received than were expected, the numberof received packets forms the basis for the calculation. This is expressed by thefollowing formula:

Packets received during t

max(Packets expected during t,Packets received during t)

The single data points inside this window are either packet receptions or timerinterrupts, which signify packet losses. The average over this data is weighted expo-nentially meaning the significance of older data points decreases exponentially withtheir age. In this way, the older the link’s history is the less importance it gets com-pared to the current state of the link, yet it is still being considered when estimatingthe link’s quality.

3.2.2 Four-Bit Link Estimation

Fonseca et. al. designed the four-bit link estimator [7], a hybrid link estimator formany-to-one scenarios in wireless mesh networks, which combines regular beaconpackets including route information on the one hand with knowledge (representedby four bits) gathered from the physical layer (one bit), the link layer (one bit) andthe network layer (two bits) on the other hand. They designed narrow platformindependent interfaces over which the link estimator can communicate with thedifferent layers of the communication stack to exchange necessary information. Forevaluation the link estimator of the standard WSN routing protocol Collection TreeProtocol (CTP) was exchanged with a prototype implementing the idea. Today theFour-bit link estimator is used by CTP shipped together with TinyOS.

Despite the approach’s platform independence, the prototype developed by the au-thors was tested on wireless sensor networks, because they consider it the mostchallenging network type with its multifarious limitations. The restricted capaci-ties of sensor nodes make it necessary for a link estimator to choose which linksto estimate, as usually not all available connections fit into the neighbor table inthe memory. Every layer contributes the information to the process, which is mostefficiently gathered on this layer. Figure 3.3 depicts the structure of this approach.

The physical layer provides information about the channel quality during the re-ception of a packet. The so called white bit is set when the transmitted symbolshave a low chance of containing errors. It is a cheap and quick possibility to filterout unpromising links before even considering them further. However, this layercan only evaluate single packets independently and also only packets which actu-ally have been received by the node. If a channel alternates between good and bad

26 3. Related Work

Figure 3.3 Structure of the Four-bit link estimator, which is represented by thetriangle in the center: Information represented by arrows leading to-wards a layer are requested by the link estimator on packets the nodereceives or connections to its neighbors. Information actively providedby the layers is depicted as arrows pointing towards the triangle. [7]

quality, these isolated pieces of information have to be combined to prove useful forthe overall estimation of the link. Depending on the hardware of the transceiver,maybe also different information can be consulted to derive the status of the whitebit. If there is no useful information to be gathered at all, it can even be left unsetfor every packet, as it then will be ignored by the link estimator.

One requirement of this link estimation approach is that the link layer uses ac-knowledgement packets, which is the case in most common wireless communicationtechnologies such as IEEE 802.11b or 802.15.4. The ack bit is set whenever theacknowledgement for a transmitted packet has been received. This couples link esti-mation and data transfer, as all packets are used for the acknowledgement statisticsleading to more accurate and realistic results than active probing alone. Moreover,with this technique the loss of a packet is noticed already before the next successfullyreceived packet arrives. Without considering the acknowledgements, only a gap inthe sequence numbers of the received packets would indicate failed transmissions.The problem with relying on data packets for link estimation is the circular depen-dency induced by data traffic presuming link estimation to enable the routing of thedata packets.

Finally, the decision which links may be helpful for the routing process and whichmay increase the danger of producing circles in the topology or pruning nodes fromthe network is incumbent on the network layer and expressed via the pin bitand the compare bit. The former can be set on an entry in the neighbor table toindicate that the link to this neighbor is currently being used and therefore not tobe evicted. The latter can be requested by the link estimator resulting in a networklayer evaluation if the corresponding link is to be considered more promising thanany link currently cached in the neighbor table of the node. Of course, to answerthis, access to some routing information is needed, which is provided by periodicbeacon packets.

Because of the usually high number of potential neighbors of a node in a WSN, it isimperative to saving precious memory that only a subset of the connections to thenode’s neighbors are maintained in the routing table. The final decision about which

3.2. Link Estimation 27

sink

Figure 3.4 Collection tree established by CTP and additional bursty links (dottedlines), which provide routing shortcuts from time to time

connections to store in this table is to be rendered including information of all thelayers to avoid incompatible decisions, which would impair the routing performance.

3.2.3 Bursty Routing Extension

The Bursty Routing Extension (BRE) does not aim to substitute an existing long-term link estimation mechanism, which provides a stable routing topology. Its pur-pose is to be seamlessly integrated into existing many-to-one routing protocols tocooperate with the long-term mechanism by disclosing temporarily available short-cut opportunities and to use the long-term solution as backup in case the short-termapproach of BRE does not yield any promising routing opportunities.

It provides a way to detect bursty links, i.e. links which right at that time allow lim-ited packet transfer, using a short-term link estimation mechanism (STLE). Basedon this it defines an adaptive routing strategy, which allows the sensor node to usethese bursty links temporarily. BRE was tested accompanying the link estimator ofCTP (the Four-bit link estimator).

BRE works passively overhearing packets sent by the node’s neighbors and creating ahistory for each connection, which is used to find out how many consecutive packetswere received and not received over it. The sequence number carried in each packetmakes it possible to fill the history also with packet loss events as soon as the nextsuccessful packet arrives. Thresholds are defined to indicate on the one hand afterhow many consecutive successful packets a link is to be considered useful for routingand on the other hand after how many consecutive unsuccessful packets a link isto be considered unavailable again. If either one is the case, the routing protocolis informed about this, otherwise the history of the link is collected further. Inexperiments BRE’s authors found three to be a suitable value for the first thresholdand one for the second.

To explain the algorithm behind BRE, three types of nodes have to be defined: Thesender-node sends packets to its parent in the routing tree, which is the node on thenext level towards the sink. A node overhearing packets between those two is the

28 3. Related Work

overhearing-node. Every node in the network can assume any number of these rolesat any time.

If a bursty link was found by the overhearing-node because the threshold for con-secutive successful packets has been reached, the routing protocol is queried for theETX of the sender-node’s parent. It is likely that the overhearing-node has informa-tion about this, since it can overhear packets sent between the sender-node and itscurrent parent, therefore the parent can be assumed to be in the overhearing-node’sneighborhood as well. Its ETX is compared with the ETX of the overhearing-nodeto decide if the latter would be a better parent for the sender-node. If this is the case,the overhearing-node informs the sender-node that it volunteers as its new parent,because this would lead to a routing advantage, i.e. a reduced hop count betweenthe sender-node and the sink.

This announcement automatically functions as a symmetry check for the connectionbetween the sender-node and the overhearing-node, which is necessary, because untilthen the overhearing-node only derived the link to be usable in one direction. In caseof a symmetric link the sender-node makes the overhearing-node its temporary par-ent for the time the bursty link is available. This change, however, is not propagatedthrough the network. The link is used until the sender-node notices the thresholdfor unsuccessful packets to the temporary parent to be reached, which makes it useanother bursty link at its disposal or resort to traditional routing.

BRE is a very reliable approach. It was designed to influence the routing processvery carefully, which is shown by the facts that really bad links are not considered forrouting, because they would not reach the success threshold and that an aggressiveback-off is in place, which leads to a fallback to traditional routing triggered afteronly one failed packet. This assures intermediate links in the network only to beused if the routing process can really benefit from using them.

While many traditional routing protocols use periodic beacon messages to measurethe PRR of all the links in the network, BRE does not induce additional overheadbut works by only passively overhearing data packets, which also is a much moreaccurate way to measure link qualities because of the usually much higher frequencyof data traffic compared to beacon traffic. Overhead is also limited since changes inthe topology induced by BRE stay local.

The locality of the changes additionally decrease the chance of instabilities, e.g. loops,happening in the network. Those often occur when in case of sudden connectivityloss to its parent a node chooses a neighbor with a very high ETX to replace it.A node can detect a loop by receiving a packet from a neighbor which has a lowerETX than itself. A parent change because of BRE’s algorithm is very unlikely tocause this, since only nodes with lower ETX than the former parent can be chosento replace them temporarily. The locality of the changes decrease the probability ofloops further. In experiments BRE did not let its authors experience any additionalloops compared to their already low number in traditional routing.

3.3 Link Dynamics

The following concepts also do not work like traditional long-term link estimators.They merely try to exploit certain characteristics of connections between nodes in

3.3. Link Dynamics 29

-100 -50 0 50 100Consecutive  fa ilures/successes

0

0.2

0.4

0.6

0.8

1.0

Co

nd

itio

na

l p

rob

ab

ilit

y(a) KW = 0, β = 1.

-100 -50 0 50 100Consecutive  fa ilures/successes

0

0.2

0.4

0.6

0.8

1.0

Co

nd

itio

na

l p

rob

ab

ilit

y

(b) KW = 0.06, β = 0.8.

-100 -50 0 50 100Consecutive  fa ilures/successes

0

0.2

0.4

0.6

0.8

1.0

Co

nd

itio

na

l p

rob

ab

ilit

y

(c) KW = 0.20, β = 0.5.

-100 -50 0 50 100Consecutive  fa ilures/successes

0

0.2

0.4

0.6

0.8

1.0

Co

nd

itio

na

l p

rob

ab

ilit

y

(d) KW = 0.14, β = 0.3.

Figure 3.5 CPDFs and corresponding KW and β values: The positive part ofthe X-axis represents the consecutive successes, the negative part thefailures. The horizontal line denotes the average packet reception rate(PRR) of the link. [20]

a wireless network to make use of good phases of intermediate links. As we will seein chapter 4, network links exhibit a bursty behavior. When the link is available,bursts of packets can be sent, and in between there are times with no connectivityand therefore packet loss. β (section 3.3.1) is supposed to be a metric to measurethe burstiness of links to configure routing protocols accordingly, while opportunisticrouting (section 3.3.2) tries to make use of several neighbors overhearing a transmis-sion to the next hop of a route in case this transmission fails to reach this hop.

3.3.1 The β-factor

Srinivasan et. al. proposed a metric for the burstiness of links, which they call β[20]. In their contribution they explain causes for burstiness of links and a way tomeasure it. Furthermore, they designed an algorithm which exploits this knowledge.They show how to improve the performance of an existing routing protocol (CTP)significantly by adjusting only one parameter based on their findings, namely thetime to wait after a packet transmission has failed. Hence, what this link estimationmethod would contribute to a routing protocol is monitor the links of the network(vicinity) for a while, derive their β-values and configure the timeout accordingly.

β is a value between 0 and 1 and states how bursty a link is, meaning how thetimes of good and bad quality correlate. To define β one first has to understandconditional probability delivery functions (CPDF) [12]. These functions illustratethe probability of a packet to be transmitted successfully after a certain numberof consecutive successful transmissions or failures. Some examples can be seen inFigure 3.5.

If a link has a β-value of 1 (as in Figure 3.5(a)), this signifies that it exhibits an idealbursty behavior, i.e. the time periods which allow sending correlate very much. If

30 3. Related Work

Figure 3.6 Calculation of KW and β of an example link: The KW between thisCPDF and the ideal bursty one is the mean of all the ek. [20]

the link has already transmitted an arbitrary number of packets successfully so far(even only one), it has a 100% chance of successfully transmitting more packets afterthat. However, if any number of packets fail to be transmitted, there is definitelyno way of successfully sending another packet. This means, the link is constantlyon or off, either way only one packet suffices to find out its status, and more testpackets do not provide any additional information. The PRR of the link is either 0or 1 depending on if it is on or off.

On the other side of the spectrum there are links with a β-value of 0 signifyingthat they are not bursty at all, i.e. the time periods which allow successful sendingover these links are independent from each other. The CPDF of such a linkwould process along the line denoting the PRR of the link, because any number oftransmitted or failed packet transmissions would not mean anything for the chanceof transmitting the next packet successfully. This chance would constantly be equalto the long-term PRR independent of the number of successful or failed packets sentin a row.

Looking at the CPDF of a link as a visualization of its burstiness one can definea scalar value for this property, the Kantorovich Wasserstein distance (KW ) [19],which numbers how close the CPDF of a link is to the CPDF of the ideal burstylink with the same PRR. The KW is the average difference of the components oftwo vectors. To illustrate this, there is an example CPDF shown in Figure 3.6. LetKW (E) calculate the KW of a given (empirical) CPDF named E and the CPDF ofthe ideal bursty link with the same PRR as the link belonging to E. With I beingthe CPDF of the completely independent link we can now define β:

β =KW (I)−KW (E)

KW (I)

Thus, β indicates how much closer to the perfectly bursty link’s CPDF that of anempirical link is compared to that of the completely independent link with samePRR as the empirical link. All this is set in relation to the distance between theperfectly bursty and the perfectly independent link. In terms of Figure 3.6 thistranslates to:

3.3. Link Dynamics 31

β =mean(i1, . . . , in)−mean(e1, . . . , en)

mean(i1, . . . , in)

A completely bursty link would have a CPDF, in which all ek were 0, hence β wouldderive to 1. The CPDF of a completely independent link would cause all ek to beequal to the corresponding ik’s, which would make β equal to 0.

Being aware of β for all the links to a node’s neighbors, the correlation betweenindividual successful and failed packet transmissions can be exploited if it exists, i.e.if β is high. In this case a packet loss implicates a low chance for further packets to betransmitted without failure. Thus, the routing protocol should interrupt the packetflow to avoid wasting energy on retransmissions and wait an appropriate amount oftime before it starts transmitting again.

There exists a tradeoff between latency (longer waiting) and possible energy waste(shorter waiting), but since usually in WSNs energy is much more valuable than time,a certain latency is acceptable to break the correlation between packet failures. Inexperiments performed by the authors a reasonable waiting time was determined tobe around 500ms, which can easily be spent. If the node has more packets to sendto a different neighbor, the waiting time can be filled with this as well.

The authors implemented an algorithm, which uses opportune transmissions to ex-ploit the knowledge provided through β. It sends packets back-to-back as quickly aspossible until a single failure occurs. In this event the packet flow is paused for thenext packet to have an independent chance of getting transmitted.

Results show that in networks with many high-beta links a high improvement canbe achieved by using opportune transmissions, thereby individually adjusting theinter packet intervals (IPIs), i.e. the time between the packets sent. (The proposedalgorithm implies an IPI of almost 0 between successful packets and a significantamount of time (e.g. 500ms) after unsuccessful ones.) This suggests that β indeedmeasures the link’s burstiness, since opportune transmissions are known to performwell in networks with a lot of bursty links [20].

However, sending packets at a lower rate decreases the improvement, since higherdistance between packets weakens or even breaks the correlation of their successfultransmissions also leading to lower β’s for the links. Further evaluation shows op-portune transmissions only to improve high-beta links and improve links with a lowPRR more than good quality links. Moreover, the authors claim their approach tobe applicable for a wider range of wireless technologies than just WSNs.

3.3.2 Opportunistic Routing

Another approach to exploit short-term link dynamics is Extremely OpportunisticRouting (ExOR) [3], an example for an opportunistic multi-hop routing protocolfor wireless networks. With ExOR batches of packets destined for the same hostare collected and sent in a burst. The next hop on a route is being selected afterthe packet was forwarded, therefore the decision is based on which nodes actuallyreceived something. In the general idea the sender node broadcasts the packets, thenthe receiving nodes agree on who is the closest to the destination and then this node

32 3. Related Work

broadcasts them further repeating the procedure. The published implementationwas tested on a 802.11b mesh testbed.

Among the challenges involved in this approach is the agreement algorithm whichhas to ensure packets to be transmitted with minimal overhead for the process aswell as exactly once, i.e. neither duplicate packets nor packet loss should occur.Duplicate packets do not only account for wasted transmissions but also for anincreased probability of collisions and higher interference. The overhead can be keptreasonable by batching together a significant amount of packets leading to feweragreement phases and by restricting the number of possible forwarders which haveto agree in each phase.

The protocol works as follows: The sender node collects a batch of packets, broad-casts them and includes in every packet header a list of potential forwarders orderedby their closeness to the destination. Every node which receives a packet from thisbatch and finds itself in the list, buffers all incoming packets and waits until theburst is over. The node in the list with the highest priority (i.e. the one at the topof the list) that has actually received and buffered packets then starts forwardingthem including its batch map in each header indicating for every packet the highestpriority node that has already received it. The destination (which is always the nodewith highest priority in the list) only sends batch maps and no data to inform itsvicinity of successful packet deliveries.

Every node sets a timer to derive when to start broadcasting its buffered packets.This should be after all the nodes with higher priority had a chance to send theirbuffered packets. When a node receives packets from a higher priority node, thewaiting time is extended according to the expected number of packets still to be sentby this node. If no packets are received at all, a minimum waiting time sufficing forfive packets of each node with higher priority is assured before the sending begins.In this way, all the forwarders send in order of their priority all the packets theydid not already receive an acknowledgement for from a higher priority node (in formof a batch map). After the node with the lowest priority finished transmitting, thecycle starts anew.

Nodes refrain from sending any packets during their turn in case their batch mapindicates at least 90% of the packets having reached nodes with higher priority.The remaining packets are requested by the destination directly from the sourcevia traditional routing mechanisms, since the overhead of the agreement algorithmwould be too high for such few packets and the likelihood for nodes setting wrongtimers would increase.

The authors of ExOR claim their approach to perform significantly better than tra-ditional routing algorithms, mainly because of two effects: First, traditional routingalgorithms always route over one forwarding station, in case of packet loss this leadsto retransmissions. Opportunistic routing saves transmissions, because several nexthops are tried, which leads to each packet very likely being received by at least oneof them making some progress towards the destination. Second, ExOR takes advan-tage of unexpectedly long or short connections. If a node receives a packet, whichis unusually close to the destination, hops and thereby time and transmissions canbe saved. In case of a packet not reaching as far as expected in the destination’sdirection but at least being received by some node on the way, it has still made

3.4. Our Approach 33

N20

N18

N11

N8

N17

N13

N5

Time (sec)0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0

N24

Figure 3.7 Example of an ExOR run: 100 packets were transferred from nodeN5 to N24. The grey bars indicate packets sent (the longer the more,different shades of grey for different packet batches). [3]

some progress and can be forwarded from its new position. In traditional routingthe transmission would be lost and would have to be repeated, maybe even in thefirst case, because the intended next hop was not reached.

To compose the forwarder list included in the packets sent by the source, prioritiesfor every node in the network have to be derived to include the possible forwarders inthe right order into the list. To calculate the priorities the expected costs to deliverthe packet over the corresponding node have to be derived, i.e. the path ETX fromitself to the destination. This means the nodes have to obtain and to store globalknowledge about packet reception rates. For this, periodic link-state information isflooded through the network. In addition to this, nodes have to keep state of eachbatch they are participating in, buffer all received packets of the batches and theirforwarder lists.

Figure 3.7 illustrates an example of an ExOR run. A batch of 100 packets is sent bynode N5 including a forwarder list comprising the nodes on the left with decreasingpriority from top to bottom. Nodes N24 (the destination) and N20 did not receiveany of these packets, otherwise they would have sent them immediately after N5finished transmitting its packet batch. The highest priority receiver is N18, whichstarts forwarding every packet stored in its buffer after an appropriate waiting time.After this the other nodes follow in order of their priority. The overlapping in thetimeline happens due to nodes not being able to overhear packets sent by higherpriority nodes and consequently not waiting long enough before sending (i.e. onlythe default time for five packets). All forwarders being done sending, the originalsender (N5) retransmits all packets it did not overhear being sent. Nodes eventuallystop sending one by one when they overheard at least 90% of the packets sent byhigher priority nodes.

3.4 Our Approach

From studies such as the β-factor we learn about link dynamics and how we couldexploit them. β measures the burstiness of a link. This helps to see how usable the

34 3. Related Work

connections might be despite their probably low long-term qualities and to supportan existing routing protocol. However, our approach does not include introducingmetrics for network characteristics to decide which links to use for packet forwarding.Our protocol takes advantage of bursty intermediate links along with all the othersjust by itself (as long as they appear symmetric), i.e. without specifically identifyingthem before.

The Bursty Routing Extension is, as the name suggests, an extension to an existinglong-term link estimator enabling a protocol to use intermediate links additionallyif they provide shortcuts. The idea of using links with unstable quality duringtheir promising times also inspired us while designing SVR. However we wanted toavoid using link estimation altogether to save the overhead and the complexity thatcomes with it. Additionally, BRE was designed for protocols supporting many-to-one traffic. It should be adaptable for point-to-point routing on virtual coordinatesas well, since this would only be an increase in dimension. However, we think that forthis purpose SVR is a more direct approach. Moreover and maybe more important,it is a stand-alone solution.

ExOR was tested on 802.11b testbeds, and it seems to be more suitable for thistechnology, since these environments offer more resources to use, i.e. are less limitedthan WSNs. Maybe on balance the transmissions saved because of scattering therisk for retransmissions compensate the communication necessary for the agreementprocess. However, participants of a wireless sensor network could never bear theoverhead implied by the calculation of the forwarder list and the necessity for globalinformation on connectivity making periodic link state flooding necessary. Nodeswould have to store information about all the packet batches, buffer the messagesthemselves and calculate priorities for all the nodes in the network for each batch.Moreover, ExOR only works for large bursts of packets, as the overhead would beunacceptable for too small batches. This becomes clear by the fact that ExOR doesrevert to traditional routing for the last 10% of a batch’s packets, which failed to betransmitted. All this renders opportunistic routing not scalable, hence inapplicablefor WSNs, since the costs are proportional to the size of the network. Furthermore,in networks with low connectivity – which is likely to be the case for WSNs –packets would get lost despite the existence of several forwarders, because duringthe agreement process messages could not be exchanged properly. Since simplicityis one of our goals, we keep the node state small and use unicast messages with apredetermined receiver. Our trust lies within the fact that SVR’s information aboutthe state of a connection is very up to date and therefore reliable.

The Four-bit link estimator, although designed to be platform independent, profitsfrom certain radio transceiver features. Furthermore, for the information provided bythe network layer (i.e. which links to monitor and which neighbors to elect) additionalrouting information is required, for which beacon messages have to be exchanged.The routing table in SVR is filled naturally with the neighbors most recently heard of,although more sophisticated methods to determine which neighbors to evict in caseof a full table would be interesting to explore. The Four-bit link estimator is a typicallong-term approach which cannot detect and act upon short-term dynamics. SVR’sbeacon messages combine link estimation (in our case just via “hello” messages) androuting information exchange (coordinates). Thereby we avoid the latency whendetecting packet loss because of only passive link estimation as well as the circulardependency from just overhearing data packets.

3.4. Our Approach 35

The most similarities SVR shares with BVR. It also derives virtual coordinates forall the nodes based on their connectivity, which is the most meaningful correlationin WSNs. However, BVR uses a long-term link estimator, which (although not ex-ceptionally complex) induces significant overhead to overhear all the packets sent byneighbors, to send packets to determine link symmetry, calculating link qualities andkeeping state of them. In contrast to this, SVR refrains from using link estimation assuch thereby ensuring a much simpler functioning. We claim all this complexity notto be necessary to provide reliable, adaptive and scalable point-to-point data trafficin wireless sensor networks. Furthermore, SVR’s routing metric is much simplerthan the one BVR uses, although we think that with a more sophisticated metricSVR will outperform BVR even more.

36 3. Related Work

4Analysis

In this chapter we present our preliminary experiments which made us aware of theburstiness of wireless network links and led to the idea of exploiting this burstinessfor routing. First we explain our experimental settings, which testbeds we used andhow they are configured, how we gathered our data and what aspects we explored,before we present our results. We examined the length of packet bursts in a networkas well as some metrics for coordinate dynamics. At the end we summarize theimplications these observations have for our design.

4.1 Experimental Settings

After testing our code with the TOSSIM simulator and on our local testbed atthe university we conducted our experiments (for this chapter and the evaluationchapter) on three different testbeds: MoteLab [21], Indriya [6] and TWIST [11].Our own testbed comprises almost 20 nodes distributed over several rooms of thefloor where our research group is located. All the testbeds utilized by us compriseTMote Sky (also called Telosb) sensor nodes. The Telosb nodes each consist of aTexas Instruments MSP430 processor with 8MHz, 10KB of RAM, 48KB of programflash memory and a Chipcon CC2420 radio transmitting up to 250KB/s at 2.4GHz(IEEE 802.15.4) as well as sensors for humidity, temperature and light intensity,both visible light and infrared.

MoteLab1 is a testbed in the Maxwell Dworkin Laboratory, the Electrical Engineer-ing and Computer Science building at Harvard University. It consists of 170 nodes,although at the time we executed our experiments only 99 of them were available forour experiments. Since on MoteLab the distances between the nodes can be large,we let all the nodes always send with full transmission power.

1http://motelab.eecs.harvard.edu

38 4. Analysis

Indriya2 is located at the School of Computing at the National University of Sin-gapore. It comprises 127 nodes, 71 of which are equipped with an additional sensorboard (WiEye, SBT80, or SBT30, all from EasySen) providing them with the abilityto sense acoustic signals, as well as with a magnetometer, an accelerometer, and amore powerful long-range infrared sensor.

TWIST3 is deployed at the building of the Telecommunication Networks Group atthe TU Berlin. We used 94 of the 102 available nodes. In contrast to the othertestbeds, for TWIST almost no topology information is available due to privacyreasons. Still we experienced a very good connectivity between the nodes. Therefore,we used a power level of -15dBm to simulate a lower node density. Sending with fulltransmission power would not result in expressive data, since almost no multi-hopcommunication would take place.

In all the testbeds the nodes are attached to walls or ceilings on three floors insidetheir buildings and are connected to a stable power source (no batteries) and anethernet backbone (via their USB connection). This allows them to be programmedeasily over a central server. For every testbed there exists a web interface to uploadprogram images to nodes and download data produced during their operation. Theformat of the stored data and the way it is stored vary, but in all testbeds everymessage is stored, which is sent over the nodes’ Universal Asynchronous ReceiverTransmitter (UART), i.e. the USB interface connecting them with the backbone.

The way an experiment works is that the nodes are programmed with a TinyOSapplication, some time passes in which this application is executed by all the nodes,data is produced and stored, and in the end the nodes’ memory is erased, andthe next experiment can be initiated. During the time of the experiment one caninteract directly with the nodes over their serial interface, meaning messages canbe sent and received over the ethernet backbone (and thereby externally over theInternet). In order to gather the right data a programmer has to make the TinyOSapplication produce the corresponding messages and send them over the backbone.Furthermore, to control nodes during the experiments the application has to reactappropriately to messages sent by the experimenter and received over the backbone.

We first performed experiments to find out about the length of packet bursts onwireless network links. After becoming confident that we can exploit these bursts,we explored how the link dynamics would influence the coordinates in a virtualcoordinate system if we refrain from using explicit link estimation at all. There aresome parameters that one can vary in our experiments such as the size of the nodes’neighbor table. The choice for these parameters and the values we used for them isexplained in detail in section 7.2.

4.2 Link Dynamics

Previous studies ([1], [2], [20]) have shown the bursty nature of wireless network links.If a link does not have a very stable long-term quality, meaning it is not constantlyavailable for transmission, then there are times in which bursts of packets can be

2http://indriya.comp.nus.edu.sg3http://www.twist.tu-berlin.de

4.2. Link Dynamics 39

typedef nx s t ruc t bltMsg {nx u int16 t seqNumber ;nx u int16 t beaconCounter ;nx u int16 t sender ;

} bltMsg t ;

typedef nx s t ruc t b l tSe r i a lMsg {nx u int16 t o r i g i n ;nx u int16 t seqNumber ;nx u int16 t beaconCounter ;nx u int16 t sender ;nx u in t8 t r s s i ;nx u in t8 t l q i ;

} b l t S e r i a l M s g t ;

Listing 4.1: bltSerialMsg: This message is logged whenever a message (which is ofthe type bltMsg) is received over the radio during a link dynamics experiment.

sent successfully over this link and unavailable times in between. The length of thesebursts may correlate with the long-term quality of the links but does not have to.If a connection is available for many very short times, this will also lead to a ratherhigh racket reception rate (PRR) and thereby to a high long-term quality.

We wanted to measure the length of packet bursts in wireless sensor networks(WSNs). In our first experiments we chose 10 nodes more or less evenly distributedover the network4 to sequentially send out very long bursts of packets (3000, basi-cally containing only a sequence number) at a very high rate (every 50ms), whichmeans every packet burst had a length of about 150 seconds. During this for wirelesslinks rather long time period the connectivity between the nodes changed a lot, andtherefore usually only parts of the 3000 packets were received by other nodes.

We let all the nodes in the whole network log which packets they received from whichsending node. The radio module of the telosb nodes also allowed us to gather addi-tional information about the reception quality such as the Received Signal StrengthIndication (RSSI) and Link Quality Indication (LQI) values. However, in the endwe did not use these values for our statistics but only to get an impression of thelinks in the network. Overall we logged the following information (cf. Listing 4.1):

• origin: Here we store the nodeID of the node that received the original radiomessage and therefore created this logging message.

• seqNumber: This is the overall sequence number of the corresponding sendernode. Usually every node sends only one packet burst in every experiment, butin case this does not hold, the bursts can be ordered according to this field’svalues.

4Because we lack topology information for the TWIST testbed, we always have to choose randomnodes from it.

40 4. Analysis

100 101 102

Burst Length [number of packets]

0.0

0.2

0.4

0.6

0.8

1.0

CCD

F [P

(X>

x)]

MoteLabIndriyaTwist

Figure 4.1 Distribution of the lengths of packet bursts in a network: We see alot of long packet bursts, which can be used for successful routing.(Notice the logarithmic x-axis. Bursts longer than 100 packets havebeen omitted, since their number was negligible.)

• beaconCounter: The sequence number inside one packet burst is stored here.If a node sends more than one burst, it is reset each time a new burst starts.

• sender: Here is the nodeID of the node that sent the original radio message,which is recorded by this logging message.

• rssi: We logged the Received Signal Strength Indication (RSSI) value for thereceived packet.

• lqi: We logged the Link Quality Indication (LQI) value as well.

From this data we derived the length of the packet bursts that came through froma sending to a receiving node, i.e. the interval lengths of all consecutive sequencenumbers received. The outcome is depicted in Figure 4.1. It shows the Comple-mentary Cumulative Distribution Function (CCDF) of the burst lengths measuredduring the whole experiment. These functions are the complementary versions ofthe Cumulative Distribution Functions (CDF). CDFs (similar to the CPDFs in sec-tion 3.3.1) state the probability for a value out of a distribution to be at most ashigh as the value on the x-axis. Consequently, CCDFs comprise the complementaryprobabilities, i.e. the chance of a value from a distribution to be at least as high asthe x-value. This leads to the relation CCDF(x) = 1 - CDF(x).

In Figure 4.1 we see that the majority of the packet bursts is rather short, but therealso exists a number of longer bursts that can be useful for routing. For exampledepending on the testbed between 10% and 20% of the bursts are at least 10 packetslong, and between 5% and 10% of the bursts even exceed the length of 20.

4.3. Coordinate Dynamics 41

typedef nx s t ruc t SVRBeaconLoggingMsg {nx u in t8 t sender ;nx u int16 t seq no ;Coordinates cu r r en t coo rd s ;Coordinates mean coords ;nx u in t8 t number of ne ighbors ;nx u in t8 t n e i g h b o r s i d s [MAX NEIGHBORS] ;Trace t r a c e s [N ROOT BEACONS ] ;

} SVRBeaconLoggingMsg ;

Listing 4.2: SVRBeaconLoggingMsg: This message is logged every time a node sendsout a beacon message. Its content equals that of a SVRBeaconMsg.

4.3 Coordinate Dynamics

These results mean even far away neighbors of nodes may provide a useful linkenabling them to receive several packets once in a while. Thus, we implemented abasic algorithm realizing our idea of a virtual coordinate system (cf. section 2.4.2)with several beacon nodes and observed the development of all the nodes’ coordinatesover time pursuing a very greedy coordinate establishing mechanism, which section5.3 explains in detail. We wanted to see how dynamically the coordinates (i.e. hopdistance to the beacons) would evolve if we used every opportunity of a shortcut inthe network that presents itself.

We let every node send out periodic one-hop beacon messages stating its currentdistance to all beacon nodes in the network. The nodes derived the current distanceby adding 1 to the minimum coordinate they received from their neighbors. Thefrequency of the beacon messages was very high (every second for the first 10 minutesand every 10 seconds for the last 20 minutes of the experiments) to capture evenshort-term dynamics in the nodes’ connectivity and to compensate for the shortexperiment duration.

Simultaneously to the beacon sending every beacon message sent was logged byall the nodes. The logging message’s format is basically identical to the one ofthe beacon messages themselves (SVRBeaconMsg), which is given in Listing 6.2 insection 6.2, and the fields all have the same meaning as in the SVRBeaconMsgmessage type. For this experiments we only used the values of the current coordsfield, as they contain the node’s current hop distance to the beacon nodes (thecurrent coordinates). The results of these experiments are shown in Figure 4.2. Wemeasured the following values each for the whole duration of the experiments (30minutes):

• coordinate range: the difference between the maximum and minimum coor-dinate

• average coordinate: the average distance to any beacon

• coordinate change rate: the share of beacon intervals in which a coordinatechanged

42 4. Analysis

0 2 4 6 8 10 12 14 16Node Coordinate Range

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

MoteLabIndriyaTwist

(a) CDF of the coordinate range

1.0 1.5 2.0 2.5 3.0 3.5 4.0Node Average Coordinate

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

MoteLabIndriyaTwist

(b) CDF of the coordinate average

0 10 20 30 40 50 60Node Change Rate [Share of Intervals with Change, %]

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

MoteLabIndriyaTwist

(c) CDF of the coordinate change rate

80 85 90 95 100Share of Nodes Changed per Interval [%]

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

MoteLabIndriyaTwist

(d) CDF of the number of changed nodes

Figure 4.2 Results from the Coordinate Dynamics experiments: The numbersshow a very dynamic environment with frequent and drastic coordi-nate changes, which makes it unsuitable for routing unless we find away to reduce the overhead induced by the dynamics.

• nodes changed: the percentage of nodes that changed their coordinates inany beacon interval

We see an environment which looks very dynamic, although we do not have a pointof reference here. A comparison with other environments is given in section 7.3. Thetestbeds present rather different environments themselves, for example the averagecoordinates (as a metric for the connectivity in the network) vary quite much betweenTwist and the other testbeds, as can be seen in Figure 4.2(b). Twist is a very denseand well connected testbed, hence the short paths even for our low power level of-15dBm. Our aim was to evaluate our prototype in several different environments,which our testbeds with different node densities provide.

To explain the results we took a closer look at the nodes’ coordinates, their devel-opment and distribution. Figure 4.3(a) shows an example of how a node’s distanceto a single beacon develops during an experiment. We see a lot of changes, a highcoordinate range, but we also see a concentration of the numbers, which is illustratedin Figure 4.3(b). It shows the distribution of the same coordinate, which is almosta normal distribution with a mean of 10.

4.3. Coordinate Dynamics 43

0 20 40 60 80 100 120 140 160 180

8

9

10

11

12

13

7

14

Cu

rren

t H

op

s to

Beaco

n

Beacon Intervals (10 sec)

(a) Development of coordinates

Hops to Beacon

Pro

bab

ility

6 8 10 12 140.00

0.05

0.10

0.15

0.20

0.25

0.30

(b) Distribution of coordinates

Figure 4.3 The distribution of coordinates (i.e. hop distances to a beacon node)shows a lot less dynamics than their actual development. This is whatwe want to deal with.

The idea of Statistical Vector Routing (SVR) implies this distribution to stay moreor less the same over a very long time. The actual current distance of a node isalways located somewhere on this distribution. There it may move around a lot,but the probability with which it is at a certain position on the distribution shouldonly change if the network topology is altering significantly. Otherwise a node mayjust as well be identified with its address distribution rather than with its currentaddress. This is what we want to achieve to reduce the overhead for the updates inthe address knowledge base of the network.

Our analysis creates confidence regarding this goal, that we can exploit the burstynature of wireless connections to take advantage of opportunities provided by short-cut links inside the network, which present themselves every now and then. To realizethis, however, it is important to find ways to represent and publish the coordinatedistributions that keep the induced overhead on a reasonable level. In chapter 7 wewill see how much our approach reduces the coordinate dynamics and that routingindeed is possible using our newly designed representation of the coordinate distri-bution.

44 4. Analysis

5Design

This chapter comprises the design of the Statistical Vector Routing (SVR) protocol.It starts by listing the design goals we wanted to achieve, as well as the assumptionswe made for our design and the aspects we concentrated on as opposed to theaspects we considered out of the scope. A detailed description of SVR’s addressingmechanism is given, followed by an explanation of the statistical values we use toroute on and the way routing decisions are made.

5.1 Design Goals

Our goal is to develop a point-to-point routing protocol for wireless sensor networks(WSNs) in contrast to the many-to-one or one-to-many routing schema widely used(e.g. by the Collection Tree Protocol, CTP, cf. section 2.4.2). In CTP the wholenetwork is organized in a routing tree that roots in a sink node designated to collectall the data produced by the network (or dispense data in it). This is practical if allthe data actually has to be sent to one node, while arbitrary point-to-point trafficwould have to be sent up the whole tree from the sender to the sink and from thereon back down to the destination. This would be the only way in the network thenodes know of and hence the only possibility of transmitting data from one arbitrarynode to another.

With our approach, however, every node in a network shall be able to send datato any other node without the packets taking absurdly long paths to reach theirdestination. Thus, we need an addressing schema that supports variable sender andreceiver pairs and navigating in arbitrary directions through the network. We foundthat the best way to achieve this is to use a virtual coordinate system into whichthe nodes are mapped. True absolute location information is very hard to obtainon devices as limited as sensor nodes, but the absolute location of the nodes doesnot concern us anyway. The nodes’ location in relation to each other suffices to aidrouting decisions. Hence, we derive locations in relation to members of a certain

46 5. Design

0

0.2

0.4

0.6

0.8

1

2 4 6 8 10 12 14 16 18 20

Pro

bab

ilit

y

Distance�(metres)

quality�>�0.9quality�>�0.1

Figure 5.1 The probability of finding a good (>0.9) or intermediate (>0.1) qualityneighbor decreases with growing distance between the node and itsneighbors, but there are possibilities to cover substantial distances fromtime to time via long distance neighbors [2].

small subset of designated nodes which function as landmarks (i.e. reference points).These nodes are referred to as beacons or beacon nodes.

Still, true relative location information needs a lot of effort to be gathered. However,what we are really interested in is not the location of the nodes but their connectivity.Of course these two properties correlate. Nodes which are closer to each other usuallyhave a higher connectivity, i.e. a higher probability of a connection between themand a higher quality of that connection. It is however possible that nodes in directproximity of each other share a very low quality link, if any at all, or that a node can(at least for a short while) receive packets from a neighbor located very far away.We want to base addressing and routing on short-term connectivity to adapt quicklyto changes in the network topology and to use shortcuts provided by temporarilyavailable connections to nodes relatively far away.

Instead of estimating long-term link qualities to identify and restrict usage to con-stantly reliable links in order to achieve a stable routing topology we want to useevery opportunity of sending a packet the farthest towards the destination as pos-sible. Figure 5.1 illustrates that the probability of finding a neighbor with a good(>90% packet reception rate, PRR) or intermediate (>10% PRR) link quality cor-relates with the nodes’ distance, but also that a significant number of long rangeneighbors can exist in a network. For example in this experiment at a distance of14 metres the chances of finding a good quality neighbor are still almost 10% andfor an intermediate quality neighbor even around 20%.

Following this very greedy idea also when establishing the nodes’ addresses (i.e.when deriving the distances between them and the beacons), this mechanism isbound to result in frequent changes in the nodes’ addresses. In order to let other

5.2. Assumptions 47

nodes know where to send a packet to in case they want to reach a certain participantof the network, addresses have to be published somehow. However, publishing theseaddresses every time they change would induce unacceptable overhead eliminatingany advantage in routing performance there might be. Our goal is to condense thenecessary routing information by learning from the dynamics in the network and toarrive at information that can guide the routing process but is more stable than theraw information we gather during the address derivation process.

Therefore, we see the nodes’ addresses as probability distributions and use certainrelatively stable statistical values derived from the addresses over time to publishthem and to route on, rather than the ever-changing actual coordinates themselves.These statistical values have to be designed in a way that, on the one hand, theyare stable enough to keep the overhead for updates on a reasonable level, and on theother hand, are precise and adaptive enough to ensure a good performance when usedas basis for routing. Last but not least, the calculation of these values also shouldbe simple enough and the transmitted and stored data has to be small enough fora device as limited as a sensor node to be able to handle them. The whole protocolaims at simplicity to minimize requirements regarding memory, computational powerand transmitted data. To summarize, our design goals are the following:

• SVR has to support point-to-point traffic enabling arbitrary nodes to sendpackets to any other node in the network.

• It has to use an addressing schema based on virtual coordinates eliminatingthe necessity of true location awareness for the nodes.

• The nodes’ addresses used for routing have to be stable enough to keep themaintenance overhead on a reasonable level.

• Yet the addresses have to be precise and adaptive enough in capturingnode connectivity such that routing success can be sustained.

• The protocol has to impose minimal requirements on the hardware of thenodes and their capacities.

5.2 Assumptions

We make certain assumptions about the conditions we find in a network in whichour protocol would offer its functionality. The addressing schema we introduce needsa number of nodes that function as reference points for the virtual coordinates ofall the nodes (the so called beacons), and we assume those to be in place and tostay operational. This is not to say that SVR will stop working in case of beaconfailures (in fact we experienced a certain resilience against those events). However,we assume a mechanism to be in place to specify which nodes function as beaconsas well as to make sure that a beacon is being replaced eventually in case it fails.This problem is not covered in this thesis, as there exist well established solutionsfor it, such as the one used in the Logical Coordinates Routing [5].

Our prototype of SVR also does not support changing the number of beacons at runtime, a feature that can easily be added. However, all the concerns regarding beacon

48 5. Design

maintenance we consider out of the scope of our project, since it opens up a wholenew problem space on its own. Questions can be asked about the right numberof beacons for a certain network topology as well as the right distribution overthe deployment area. A related issue is the one of duplicate coordinates, which canalways be resolved by increasing the number of beacons (i.e. of the coordinate space’sdimensionality). One could also think of the fact that it might have advantages torotate the role of a beacon among the nodes in some manner, although SVR undernormal circumstances does not induce an increased burden on the beacon nodes1. Inour implementation we define a fixed-sized set of nodes at compile time to functionas beacons.

Another mechanism we consider already available is a lookup service for addressesin the network. In case data has to be sent from one node to another, the addressof the destination has to be found out first. In our experiments we provided thisinformation to the sending nodes over their serial port (USB connector) after firstobtaining it from the destination over the same interface (cf. section 7.4). In generalwe assume a knowledge base to be existent in the network, which every node canquery with a node identifier and obtain more or less up to date information aboutthe corresponding node’s address.

Again the design of this knowledge base opens up a whole own set of questions tobe explored. Wireless sensor networks are most likely to lack any kind of centralmanagement entity that could be used to store the location information and handlerequests to it, making a distributed solution seem appropriate. This leads to ques-tions such as how the information should be distributed throughout the network andhow it can be accessed efficiently. We do not address these problems in this thesis.However, our evaluation gives hints about the rate such a knowledge base wouldhave to be updated with new addressing information to always contain informationrecent enough to enable an efficient routing procedure (cf. section 7.2). For locationservices in wireless sensor networks well known solutions exist [16].

Since SVR is a routing protocol, it only tackles the problem of finding paths forpackets from a sender node to a destination and leaves related problems to otherspecialized protocols. For example we assume the data to be sent by a node to fitinto one packet and do not consider packet fragmentation. In very big and/or densenetworks with a lot of beacon nodes and a high number of neighbors for each nodethe beacon message format we designed would likely exceed reasonable packet sizesfor a wireless sensor network, but for the testbeds we evaluated SVR on this was notan issue. For really vast networks one has to consider certain optimizations anyway,such as a logical partitioning of the network and locally limited dissemination ofinformation.

5.3 Address Derivation

The first aspect we explain in detail is the mechanism of finding addresses for allthe nodes in the network. This can be considered the basis every routing protocol

1Beacons will experience more traffic in case of frequent switching to the fallback and floodingrouting modes (cf. section 5.5), usually a result of unfavorable node addresses, which might be dueto very low connectivity, and which is likely to be resolved by changing the beacon topology.

5.3. Address Derivation 49

requires to work, since routing decisions are made according to node addresses. Thisis why a routing protocol always needs some initialization time when it is set up forthe nodes to establish their addresses, except if those addresses are not based oncertain network conditions but are determined a priori, which however is very rarelypractical in wireless sensor networks. In reality WSNs are often deployed for a verylong time, rendering the length of the initialization period negligible.

In Statistical Vector Routing (SVR) every participating node starts composing itsaddress as soon as it has finished booting. This address is a vector with one com-ponent for every beacon in the network. Each component of the vector states thenode’s distance to the corresponding beacon. As a metric to measure this distancewe use the hop count. This is the minimum number of nodes over which a packetwould have to be forwarded to reach the beacon, i.e. the length of the shortest pathbetween the node and the beacon. On this path every hop is a neighbor of the hop infront and behind it on the path. Because we also want to capture short-term changesin the network topology (i.e. also use connections that are only available for a shorttime), we consider two nodes neighbors if they share a link to communicate witheach other for the time being regardless of their history and future prognosis. Thecorrelation between node distance and link quality leads to nodes having neighborrelations with relatively many nodes in their real geographic vicinity and only a fewneighbors that are far away. Our goal is to utilize these farther neighbors as oftenand as long as possible, since they might provide significant shortcuts towards thedestination.

To establish the address vectors of the nodes in the network, the nodes’ coordinatevector has to be communicated to all direct neighbors such that distance trees canform rooting in the beacon nodes. Figure 2.5 in section 2.4.2 illustrates the procedureCTP uses to establish its routing tree which can be considered the one-dimensionalspecial case of the virtual coordinate system we use. Although the picture conveysthe impression the beacon node would start sending out its coordinate (which isalways zero) and whichever node receives this message starts forwarding it, in SVRall nodes start sending out beacon messages containing their coordinates from themoment on they start operating. In the beginning all the vector components repre-sent invalid components, because no topology information has been gathered so far,but eventually the data sent out will become more and more useful for the node’sneighbors.

The missing distinction between beacon nodes and the rest of the network in theirbehavior agrees with SVR’s philosophy of considering all nodes equal. A beacon doesnot behave in a special manner during the address derivation procedure compared toother nodes besides the fact that it always automatically sets one of its coordinatecomponents to zero, namely the one representing the distance to itself. A possibleoptimization would be for a node not to start participating in the procedure beforeat least a certain number of its coordinate components has become valid. This wouldsafe some transmissions in the initialization phase of the protocol at the beginningwhile slowing down the whole process. Furthermore, the initialization time span canbe considered insignificant compared to the whole lifetime of the network particularlybecause if there are sufficient beacon nodes and if they are distributed evenly acrossthe network, it should be the case that every node is reached by messages from itsnearest beacon(s) rather soon.

50 5. Design

Of course the nodes have to use the information they receive from their neighbors toadjust their own coordinate vector. Every node sends a beacon message2 once everybeacon interval, which is fixed in our prototype but could also be adjusted accordingto the degree of change observed in the network. By means of these messages nodeslet their neighbors know about their current coordinates (and automatically alsoabout the fact that they are still operational). The coordinates sent along with thebeacon packets were derived based on all the beacon messages the node has receivedduring the last n beacon intervals, n being a predefined (or also adaptive) integervalue. Because of these messages the node is aware of its neighbors’ distances toall the beacons and according to this information for every beacon determines itsneighbor with the shortest distance to this beacon. This node then becomes itsparent in the distance tree of the corresponding beacon node.

An important fact to keep in mind is that wireless links are not necessarily symmet-ric. It might happen that a node receives a beacon message from a neighbor butcannot successfully send packets to this node on its part. That is why the symmetryof the link to a neighbor has to be checked by a node before using the coordinatesof this neighbor for the derivation of the own coordinates. This could be done reac-tively on demand with a probing message in the instant the information is needed,or (as we do) it can be a feature integrated into the beacon messages as well.

In SVR nodes attach the information from which neighbors they recently receivedsomething into their own beacon messages. In this way, a node directly detects ifits messages have been received by a neighbor before. In this case the just receivedbeacon message completes the symmetry check, since packets were evidently ableto be sent in both directions. The sender of the message would then be declared avalid neighbor and could henceforth be used to adjust the node’s coordinates. It alsomeans that packets can be routed over this neighbor (cf. section 5.5). Of course, thismechanism also enables a node to detect if its messages are not received anymore bya certain neighbor. This would manifest itself in the neighbor’s beacon messages notcontaining the information about received beacon messages from this node anymore(or in the beacon messages not even arriving anymore). In this case the node wouldstop using this neighbor for deriving coordinates and routing packets even though itmight have valid information about its coordinates.

Another information a node has to include in its beacon messages to avoid loops inthe distance trees of the beacons is the traces of its parents, i.e. the nodes directlyabove it in the beacons’ distance trees. Every node keeps a trace for every beaconnode in the network, which contains the path from the corresponding beacon to thenode itself. To save memory on the node and to keep the beacon message packetssmall the traces’ length can be bounded, which leads to traces containing only thelast part of the path from the beacon to the node, i.e. the t hops nearest to the nodeitself. In case of unbounded traces the mechanism of providing this information(the so called source beaconing) can prevent loops in the distance trees or in case ofbounded traces at least make them very unlikely.

If a node receives a beacon message and finds itself in the trace corresponding toa certain vector component, it must not use this neighbor’s information to adjustits own coordinates in this component. Otherwise this would produce a loop, since

2The exact format of our beacon messages can be seen in section 6.2.

5.3. Address Derivation 51

31 B 2

01 1 2

31 B 2

0- 3 2

31 B 2

0- 3 4

31 B 2

0- 5 4

31 B 2

0- 5 6

time

Figure 5.2 Illustration of the count to infinity problem: The node B is a beacon,the others (1, 2, 3) are part of its distance tree. Every row of thepicture shows the network topology at one point in time.

the node would then appear twice in the trace and thereby twice in the path to thebeacon node. If a node is already in a trace of one of its neighbors, it appears that itmust have a higher distance to the corresponding beacon node, since the path of theneighbor to the beacon leads over the node itself. However, sudden node failures onthe way to a beacon in a sparse network can lead to a count to infinity phenomenon,which source beaconing can help to avoid.

This is illustrated in Figure 5.2: As long as the beacon node is connected andoperational (first row), the coordinates of the other nodes are 1 for node 1 and node2, and 2 for node 3 as to be expected. In case the beacon fails (second row), node1 correctly declares its coordinate as invalid, since it does not have any connectionto the beacon anymore. However, the other two nodes do not notice this, as theyalways find a neighbor in each other with a valid coordinate for this beacon. They usethis neighbor (since they have no other neighbors) to calculate their own coordinate.Node 2 publishes the coordinate 1 while receiving a 2 from node 3. Hence, it assumesthat there exists a route of length two from node 3 to B, which is the best routeknown to node 2. Therefore, it declares node 3 its new parent and sets its own newcoordinate to the one of node 3 plus one, i.e. 3.

Node 3 on the other hand performs the same. Node 2’s coordinate (i.e. 1 from thetime of the first row) is the minimum coordinate it receives. Thus, node 2 becomesnode 3’s parent and node 3’s coordinate becomes the one of node 2 plus one, i.e.2. This procedure continues, the nodes always pick each other as parents towardsbeacon B and thereby both increase their coordinates indefinitely. The faulty parentselection has led to a loop in the distance tree comprising the nodes 2 and 3. If sourcebeaconing had been performed, node 2 had found itself in the trace sent by node 3and would have refrained from electing node 3 as its new parent. This would haveled to invalid coordinates for both nodes, which would have been consistent with thetopology.

52 5. Design

Notice that we do not use any explicit link estimation algorithm whatsoever. Everytime a node receives beacon messages from one of its neighbors, this neighbor isconsidered alive and available. In case the symmetry check described above hassucceeded as well, the connection to the respective neighbor is recognized, and it isimmediately considered a potential parent in the beacon nodes’ distance trees and apotential next hop on a route for a packet having to be forwarded by the node. Theidea is that because of the relatively frequent beacon message exchange a node willget a fairly precise knowledge about which of its neighbors it can communicate withreliably, not by analysing the history of the connection as a long-term link estimatorwould do but by now and then implicitly checking if the neighbor is still there.

5.4 Statistical Addresses

The problem caused by the frequent refresh of the neighbors’ state is that becauseof the potential instability of wireless links the neighbor relations between the nodestend to change quite often leading to the nodes’ addresses also not remaining thesame over a longer time. A node could discover that one of its neighbors has changedits coordinates (or a new neighbor comes up) and now provides a shorter path to abeacon (i.e. has a smaller corresponding vector component) than the node’s formerparent for this beacon, hence this neighbor would become the new parent. Anothertime one of the node’s parents could become silent (for a while) forcing the node toelect another neighbor as parent, which might have a higher distance to the beaconthan the former parent used to have. These events lead to nodes changing theircoordinates, and they appear quite frequently as can be seen in section 4.3.

If the nodes issued an update to the address database every time even one componentof their coordinates change, the resulting overhead would be immense negating allpositive influence this very adaptive algorithm has on routing performance. Becauseof this we need to introduce a mechanism to reduce this overhead, since we do notwant to give up the positive influence. We are confident that, although nodes in acertain vicinity have to be aware of these frequent coordinate updates (to calculatetheir own current coordinates), it is not necessary for a good routing performance tocommunicate them to the whole network. Therefore, in the following we introducea way to produce condensed addressing information for the nodes, which is morestable and still precise enough to ensure the successful routing of packets, namely arepresentation of the coordinate distribution over time.

To smooth the development of the coordinates thereby avoiding the rapid changesillustrated in section 4.3, in SVR the nodes calculate certain statistical values basedon the coordinates and publish those in the network instead of their actual currentcoordinates. The idea is that the nodes shall learn from the dynamics inside thenetwork. Not the information about the network topology in one instant is importantbut a less detailed view on the network developed over time. Nodes have to noticecoordinate changes in their vicinity (as they will because of the periodic beaconmessages), adjust their own coordinates accordingly and let their neighbors knowabout them. Additionally, they have to keep track of their past coordinates andcalculate a distribution of their coordinates over a defined time interval. Figure 5.3illustrates an example of this concept:

5.4. Statistical Addresses 53

beacon

0 1 2 3 4hop count

pro

pab

ilit

y

B

dab

cN

Figure 5.3 Distributions as addresses in SVR: The function graph depicts the co-ordinate of node N , i.e. the probability distribution for its possible hopdistances to the beacon node B. a, b, c, and d are nodes on possibleroutes from B to N . Straight lines signify connections with a high sta-ble quality, while dotted lines represent unstable links that are availableonly from time to time.

The distribution of the coordinate of node N can be seen in the function graphinside the figure. The node never has the coordinate 0, since it is not a beacon.Coordinate 1 is rare, it happens only if the unstable direct connection to B canbe used. A hop count of 2 between B and N is a bit more common. There aretwo possible paths for that case, B, a,N and B, b,N , depending on which unstableconnection is temporarily available. Most of the time N ’s coordinate will be 3 asthere is a very stable path of this length from B to N (i.e. B, a, b,N), which issupposed to be used every time no shortcut is available. A distance of 4 to B is alsovery unlikely. It can only be the case if the connection between b and N breaks,which is considered stable. Even then, if at the same time the unstable connectionbetween B and b was also available, N ’s coordinate would be 3 once more. Finally,the unstable connection between a and d might add some probability to the hopcounts of 3 and 4. Hence, one can imagine, over time the depicted coordinatedistribution might manifest.

We assume that the current coordinates of a node will always change relatively oftendepending on the dynamics in the network topology, since we chose a very greedyapproach for the coordinate establishment, but the distribution of these coordinateswill stabilize eventually. The ideal case would be that at some point in time thestatistical values calculated from a node’s current coordinates stop changing at allbecause the changes in the network topology were more or less recurrent and thetopology itself essentially stayed similar all the time. Only if substantial changeshappen regarding node connectivity such as the breakdown of big parts of the net-work, also the condensed statistical values would change (and should change). Theyhowever are supposed to provide an abstraction from all the small, maybe temporary,changes that frequently happen in a network.

54 5. Design

The coordinate distributions every node calculates over time and adjusts when itscoordinates change have to be published by the nodes in the network instead of theirtransient current coordinates. We do not specifically cover the latter issue in thisthesis but assume that every node updates this information in the knowledge basefrom time to time and has access to the address information about every other node.The key question is, however, how to represent this distribution in an efficient wayregarding costs for its creation, storage and distribution, keeping in mind the inherenttradeoff between those costs and the level of precision the information provides. Themost precise way would be to always store and communicate a node’s whole historyof coordinates, which of course is impractical.

A way to tackle this tradeoff comes from the fact that not every node in the net-work needs the same information (i.e. the same level of precision) to route a packettowards its destination. Section 5.5 covers how the routing itself is done in SVR. Inour prototype implementation all the nodes use their mean coordinates to representtheir coordinate distribution, i.e. an (unweighted) moving average of the current co-ordinates over a certain time interval. We found that this is a very simple solution,which still suffices to realize acceptable routing performance. However, we are con-fident more sophisticated representations will lead to an even more efficient routingbehavior.

Consider a node p with current coordinate vector < p1, . . . , pr > where r is thenumber of beacons that form the virtual coordinate system and pi is the distance ofnode p to beacon number i. Its mean coordinates then comprise < p1, . . . , pr >, pibeing the mean distance of p and beacon i, defined as

pi =1

n

n∑j=1

pi,j, (5.1)

where pi,j is the jth value in the history kept on the node for the component piand n is the size of this history. Every node recalculates this statistical informationperiodically to update the published values in the knowledge base. In our prototypethis is done once every time a beacon message is sent out, because the informationis included in these messages to make it directly available to the node’s neighbors,which need them for routing (cf. section 5.5). The calculation of the distribution canbe realized efficiently and aided on the fly during the beacon interval. For details ofthe calculations see section 6.4.

5.5 Routing

After the participants of the network have successfully derived their coordinates,data packets can be sent through the network guided by these addresses. In rout-ing protocols based on virtual coordinates this usually means that nodes select theneighbor with coordinates most similar to those of the destination as next hop on aroute to it, because nodes with similar coordinates are likely to be located in vicinityof each other. In SVR nodes do not route on the actual current addresses of thenodes in the network but on the statistical values they can query from the knowledge

5.5. Routing 55

S D

b0

b1

b2

n

n

nn n

4

5

4

3,3,1

2,1,2 0,2,2

1,3,2

2,2,2

3,1,1

2,2,0

2,2,2

1,1,1 2,0,1

Figure 5.4 Illustration of the sum distance: b0, b1, and b2 are beacon nodes, S isa sender, D a destination, and n denotes other nodes. Every node isannotated with its current address vector, perfect links assumed. Thesum distance between S and D is calculated by deriving the number ofhops from S to a beacon and from there to D and averaging this overall beacons. In this example it would be:

[(3 + 1) + (2 + 3) + (1 + 3)]/3 = (4 + 5 + 4)/3 = 13/3 ≈ 4.3

base, i.e. a representation of the destination’s coordinate distribution, which in ourimplementation is its mean coordinates.

Again this leads to a tradeoff, namely between the complexity of the calculationsduring the routing decision and its costs. An increased effort spent to derive thebest neighbor to forward a packet to can lead to a better routing performance, sincenodes could consider additional properties of their neighbors besides the similarityof address vectors, such as the neighbor’s coordinate stability. However, even thesimilarity of the vectors can be exchanged as a metric, as it is supposed to measurethe distance between the nodes the vectors belong to. Another example for a metricto measure this would be the sum distance illustrated in Figure 5.4. A way tocombine different routing metrics is for nodes to use them depending on their distanceto the destination. If it is still far away, simple mean coordinates can already guidea packet in the right direction towards the destination.

As the packet gets closer, nodes having to make a routing decision can try to derivethe actual current coordinates of the destination, i.e. its current location on itscoordinate distribution. Our assumption is that nodes being located in vicinity ofeach other experience a similar shift in their coordinates whenever changes in thenetwork topology occur, since they affect all those nodes in a similar way. Hence, anode might be able to reason the destination’s current coordinates via assuming asimilar location shift on the destination’s coordinate distribution as the node itselfexperienced on its own distribution. Finally, since nodes are aware of the meancoordinates of their direct neighbors, a neighbor can be identified as the packet’sdestination. If that is the case, clearly, it should be forwarded directly to thisneighbor.

As our prototype strives for simplicity regarding the routing metric and becauseoptimizing the routing performance was not our primary concern, we refrained fromimplementing the second mechanism for the time being. A node always calculates the

56 5. Design

difference (i.e. absolute distance) of its neighbors’ mean address vectors to the oneof the destination and forwards a packet to the neighbor minimizing this difference.If pi represents the mean distance of neighbor p to beacon i calculated as shown atthe end of section 5.4 and Ck(d) is the set of the k closest beacons to d, the vectordifference δk between the mean address vector of a possible next hop p and that ofthe destination d considering the k closest beacons is defined as:3

δk(p, d) =∑

i∈Ck(d)

|pi − di| (5.2)

Of course, if one of the direct neighbors of a node happens to be the packet’s destina-tion, then it is delivered directly. We included the mean coordinates into the beaconmessages such that every node is always aware of its neighbors coordinates. Addi-tionally to this normal routing mode SVR has a fallback mode as the one used by theBeacon Vector Routing (BVR) protocol, which is described in detail in section 3.1.1.If no suitable neighbor is found to bring the packet closer to the destination or ifthe suitable neighbors are not reachable (anymore), the packet is forwarded towardsthe beacon closest to the destination. If it reaches this beacon, a scoped floodingis initiated, where the scope is determined by the component of the destination’saddress vector corresponding to the sending beacon node, since this represents thedistance between destination and beacon and can therefore serve as an orientationfor the number of hops necessary to reach it.

3k is another parameter, which can be adjusted to save space and computing time in case thereexist a lot of beacon nodes in the network. However, our implementation uses all available beacons.

6Implementation

This chapter provides an overview on important implementation details of our pro-totype for the Statistical Vector Routing (SVR) protocol. First, we explain for whichplatform it has been developed and give an insight into the implementation of theBeacon Vector Routing (BVR) protocol we used as a basis. Then, we present thedata structures we introduced to store the necessary information on the node and tocommunicate this information to other nodes in the network. Last, we point out howwe use these data structures to realize the address derivation procedure we designed(i.e. the way a node keeps track of its neighbors), how we calculate the statisticalvalues to be published in the network (i.e. the coordinate distributions), and howrouting decisions are made.

6.1 Prerequisites

We developed our prototype for wireless sensor networks (WSNs), although we be-lieve that it can be implemented to support other wireless technologies, such as802.11-based wireless mesh networks, as well. The network is expected to exhibitcommon size and density properties as they can be found in most available testbeds.Our testing and evaluation took place on the MoteLab [21], Indriya [6], and TWIST[11] testbeds (for details about the hardware used in these testbeds see section 4.1).

Our prototype was implemented for TinyOS 2.x [14], a widely used operating sys-tem for sensor nodes. It supports component-based applications and an event-drivenprogramming approach. One can write software in a C dialect named nesC [9] anduse system components provided by TinyOS, such as timer and radio abstractionsof the real node hardware, to write one’s own components. Every component is sup-posed to handle a specific aspect of the whole application and can provide methodsto be used by other components.

To avoid having to implement everything from scratch we used a prototype of BVR[8] and its infrastructure and exchanged the modules responsible for keeping the

58 6. Implementation

testapplication

routercommstack

hardwareradio

state coordinatetable

senddata

receivedata

senddata

sendpacket

receivepacket

receivedata

querynext hops

respondnext hops

respondnext hops

querynext hops

receivebeacon

sendbeacon

Figure 6.1 Structure of the relevant part of BVR: The test application componentsends data over the router component, which queries the state compo-nent for a route before it hands over the data to the communicationstack component. The state component delegates the task of findingsuitable neighbors for routing to the coordinate table component anduses the communication stack itself to send beacon messages.

protocol-relevant state on the node. A more detailed view on the general design ofBVR can be found in the sections 3.1.1 and 3.2.1. Here we give a brief explanationof the structure of the implementation we had at our disposal. Figure 6.1 shows anillustration:

A test application component is used to produce data packets which are supposedto be sent to some node in the network. It thereby simulates the activity of a realapplication being executed on the sensor node. This application component uses arouter component to forward its data packets. It just calls a certain method providedby the router, hands over the packet, and the router component takes care of thedelivery. The router also handles data packets that are received by the node. Incase that this node is the packet’s destination it is handed over to the application,otherwise it is forwarded to the appropriate neighbor of the current node.

Another very important component is the state component, which handles the ex-change of beacon messages between the nodes and the resulting address and neighbormaintenance. This component can be queried for the node’s current address and fora subset of its neighbors which are suited as possible next hops on the way to apacket’s destination. To achieve this the state component uses a coordinate tablecomponent which stores the necessary neighbor information.

The router as well as the state component both use the communication stack com-ponent to send data or beacon packets, respectively. This component has severalsubcomponents organized as a stack which realize a message queue enabling severalcomponents to send packets without hindering each other. Furthermore, it prepares

6.2. Data Structures 59

the packets to be used by BVR’s passive link estimator, which needs an additionalpacket header with another sequence number to measure packet loss.

6.2 Data Structures

One of the most significant differences between BVR and SVR is the latter definestwo kinds of coordinates for every node – its current coordinates and its mean co-ordinates. Both are represented in a Coordinates data structure, a one-byte integerarray with a cell for every beacon in the network. On the one hand, the currentcoordinates are the ones being derived by the exchange of bacon messages, i.e. theyrepresent the node’s distance from all the beacons at one point in time. These valuesare potentially updated with every beacon message that the node receives1. A de-tailed description of the address derivation and neighbor maintenance mechanismscan be found in section 6.3. The mean coordinates on the other hand are our chosenrepresentation of the coordinate distribution a node publishes in the network. Theyare calculated by averaging a history of the current coordinates over the last beaconintervals. Details about this process are given in section 6.4.

There is also a list to keep track of the current parents of the node. Only theparents’ nodeIDs are stored here with which every node identifies itself and whichare usually assigned to the nodes a priori. Detailed information about the nodescorresponding to the IDs are stored in the coordinate table, which is maintained bya separate component. This coordinate table component provides methods to store,find, update and remove entries, which contain all the information about the node’sneighbors that are necessary for the functioning of the protocol. Listing 6.1 showsthe structure of a coordinate table entry containing the following data fields:

• valid: This field states if the entry is considered valid. It is used to mark freeentries. If an entry is being evicted, only its valid field is set to zero, and incase a new neighbor has to be stored an invalid entry is searched for.

• symmetric: This field contains a 1 if and only if the corresponding nodeis a symmetric neighbor. Symmetric neighbors are known to receive beaconmessages from the node on which the coordinate table is stored and also suc-cessfully send beacon messages back on their part.

• first hop: The value stored here is the same as in addr. It was kept to ensurecompatibility with BVR, that somehow supports 2-hop neighbors or plans tosupport them in the future.

• last seqno: This is the sequence number of the last beacon packet successfullyreceived from this neighbor. It is used to filter out duplicate messages.

• addr: Here the nodeID of the node corresponding to this entry can be found.

• current coords: This field contains the current coordinates of the neighbor.They are used to determine the current coordinates of the node to which thecoordinate table belongs.

1Although the current coordinates assigned to the node at the end of the last beacon intervalare stored as well (the so called last coordinates).

60 6. Implementation

typedef nx s t ruc t {nx u in t8 t v a l i d ;nx u in t8 t symmetric ;nx u int16 t f i r s t h o p ;nx u int16 t l a s t s e q n o ;nx u int16 t addr ;Coordinates cu r r en t coo rd s ;Coordinates mean coords ;Trace t r a c e s [N ROOT BEACONS ] ;nx u in t8 t q u a l i t y ;nx u in t8 t age ;nx u in t8 t pos ;

} CoordinateTableEntry ;

Listing 6.1: CoordinateTableEntry: An entry in the coordinate table contains allthe necessary information about a node’s neighbor.

• mean coords: These are the mean coordinates of the neighbor. They areused to estimate the neighbor’s distance to the destination of a packet.

• traces: The path a beacon packet took from the beacon node itself to thisneighbor (or at least the last part of this path) has to be kept here to avoidloops in the topology. The Trace data structure is a one-byte integer array ofa fixed length to be configured at compile time.

• quality: This field was used by BVR to store the long-term quality of the linkto this neighbor. In SVR it is unused, i.e. all neighbor nodes are assigned thehighest quality value possible, but still kept in the data structure to ensurecompatibility.

• age: Here the age of the stored information is kept, i.e. the number of beaconintervals that no beacon message has been received from this neighbor.

• pos: This is supposed to represent an ordering on the table entries. Anotherfield that SVR does not use but BVR might.

To interact with their direct neighbors for the address derivation mechanism beaconmessage packets are exchanged between the nodes. The concrete format of thesemessages is shown in Listing 6.2. SVRBeaconMsg is the type of the message beingtransmitted, which contains an additional header (in the header field) used by BVR’slink estimator. Here every packet is tagged with a sequence number that enablesthe neighbors’ link estimators to detect packet loss easily and thereby calculate thelink’s packet reception rate (PRR). Although this header is not used anymore, sinceSVR does not perform link estimation, we kept the structure for compatibility tothe rest of BVR’s infrastructure. The real information the node’s neighbors need forthe functioning of SVR is included in the type data field and therefore in the typeSVRBeaconMsgData with the following fields:

6.2. Data Structures 61

typedef nx s t ruc t SVRBeaconMsgData {nx u in t8 t sender ;nx u int16 t seq no ;Coordinates cu r r en t coo rd s ;Coordinates mean coords ;nx u in t8 t number of ne ighbors ;nx u in t8 t n e i g h b o r s i d s [MAX NEIGHBORS] ;Trace t r a c e s [N ROOT BEACONS ] ;

} SVRBeaconMsgData ;

typedef nx s t ruc t {nx u int16 t l a s t hop ;nx u int16 t seqno ;

} LEHeader ;

typedef nx s t ruc t SVRBeaconMsg {LEHeader header ;SVRBeaconMsgData type data ;

} SVRBeaconMsg ;

Listing 6.2: SVRBeaconMsg: This is the beacon message format used by SVR;LEHeader: BVR’s link estimator uses this header to calculate PRRs; SVRBeacon-MsgData: The actual payload of SVR’s beacon message presents this structure.

• sender: This field contains the nodeID of the node the beacon message camefrom.

• seq no: This is the sequence number of the beacon message. It is incrementedon every node in every beacon interval to enable nodes to detect duplicatemessages and missed beacons.

• current coords: Here the current coordinates of the node are transmitted toits neighbors to participate in the address derivation process.

• mean coords: The node’s mean coordinates are transmitted as well for itsneighbors to determine the node’s distance to packet destinations.

• number of neighbors: In this field the number of the node’s neighbors isstored, only to help receiving nodes decoding the message, as it determines thelength of the neighbors ids field and thereby the starting position of the tracesfield inside the packet, which otherwise would be cumbersome to calculate.

• neighbors ids: This is a list of all the node’s neighbors, meaning not onlythe ones with symmetric links. It is used for the link symmetry check, since itcontains the nodeIDs of all the neighbors from which the node received beaconsduring a defined number of the last beacon intervals.

• traces: To avoid loops in the beacon nodes’ distance trees the path fromthe beacon node to the node sending this beacon has to be transmitted. Thepacket contains one trace for every beacon node there is in the network.

62 6. Implementation

typedef nx s t ruc t {nx u int16 t next hops [MAX NEXT HOPS + MAX FALLBACK HOPS ] ;nx u int16 t d i s t a n c e s [MAX NEXT HOPS ] ;nx u in t8 t n ;nx u in t8 t f ;nx u in t8 t index ;

} nextHopInfo ;

Listing 6.3: nextHopInfo: This represents a collection of neighbors that have beendetermined as possible next hops for a packet to be forwarded

When the router component has to forward a packet and therefore has to determinewhich of the node’s neighbors would qualify as a next hop on the route, this task isdelegated to the coordinate table component. This component determines the bestchoices according to the neighbor information in the coordinate table. This processis explained in more detail in section 6.5. At the end a list of nodes is returnedcollected in a nextHopInfo structure presented in Listing 6.3 and comprising thefollowing data fields:

• next hops: This is a list of possible next hops for the packet ordered bydistance, i.e. the MAX NEXT HOPS neighbors closest to the packet’s des-tination. At the end there are also the next hops for a possible routing infallback mode, which in our current implementation not more than one entry.

• distances: The list of distances to the destination of the nodes collected innext hops is given here.

• n: This field stores the number of possible next hops in the first field, whichare to be used for the normal (i.e. not fallback) routing mode.

• f: Here is the number of fallback routing options at the end of next hops.

• index: When routing a packet the entries of next hops are tried one by one.This field keeps track of the number of the entry, which is currently processed.

6.3 Neighbor Maintenance

The main component responsible for the maintenance of neighbor information is thecoordinate table component. It basically manages an array of coordinate table entryinstances (cf. section 6.2). Since applications developed for TinyOS always followan event-driven approach, every action has to be triggered by an event. In case ofSVR the important events are the arrival of a beacon message packet and the firing2

of the timer that represents the beacon interval, the BeaconTimer. The effects ofthese events are detailed here:

2In TinyOS an instance t of the timer component can be started once or periodic set to a certaintime period. When this period is over (in the periodic case: every time it is over), the t.fired()event is triggered and the corresponding event handler function is executed.

6.3. Neighbor Maintenance 63

currentcoordinates

meancoordinates

commstack

coordinatetable

m3: maybeupdate

m2: storeor updateneighbor

entry

m1: receivebeacon

messagereceived

t1: restarttimer

beacontimer

t4: alwaysupdate

t2: clean table,age entries

t5: providebeacon info

t3: maybeupdate

t6: sendbeacon

Figure 6.2 Effects of the two main events in SVR: If a beacon message is receivedover the communication stack component, the effects m1, m2 and m3happen and in case the BeaconTimer fires t1 - t6 are performed.

When a message is being received during a beacon interval, the information fromthe node’s neighbor contained in the message has to be processed directly, as theremight not be enough space on the node to buffer several messages. An entry for thesender node is searched for in the coordinate table and is updated or stored withthe message’s content. Also the age field of the entry (regardless if new or old) is(re)set to zero. The details of the aging process are explained further below as thisis used when the BeaconTimer fires. After updating the coordinate table it has tobe determined if the new information the message provided has to lead to a changein the node’s coordinates. If the newly discovered neighbor (in case it did not existin the coordinate table) or the known neighbor with new coordinates (in case italready existed in the table) presents a better parent than one of the current ones,it becomes the new parent in the distance tree of the corresponding beacon node,and the current coordinates of the node are adjusted accordingly.

However, the neighbor is only considered for the coordinate update if it does notcreate a loop in the topology and has a symmetric connection to the receiving node.The former is achieved by making sure that the receiving node’s nodeID is not partof the trace included in the message, which is associated with the beacon in whosetree the neighbor would become the receiving node’s parent. For the latter thesymmetric field in the coordinate table entry has to be checked, which contains aone if the receiving node’s ID was found in the neighbor list of some beacon messagereceived by the neighbor in the last beacon intervals (also if it was received just nowin this very message). Asymmetric neighbors are still kept in the coordinate tablebut are not considered as potential parents. The only case the neighbor informationis not included in the table is if a new entry would have to be created and the tableis full. Our implementation does not have any neighbor eviction strategy yet exceptthe aging process described below. In our preliminary tests however the table veryrarely reached its capacity.

64 6. Implementation

When the BeaconTimer fires and thereby determines the end of a beacon intervalthe following actions are performed: First, the timer is restarted to begin the nextbeacon interval3. Next, the coordinate table is cleaned, which means that all entrieswith a certain age are evicted. This ensures that information of nodes which staysilent for a long time (e.g. due to node failure) does not have effect on the node’scurrent coordinates and does not block precious space in the coordinate table forlong. Our prototype evicts neighbor entries after not having received beacon mes-sages from them over three consecutive beacon intervals. After the table has beencleaned, the age of all the entries that remain in the coordinate table is increased.The value of the age field is to be understood as the number of beacon intervals thatthe corresponding neighbor was not heard of. Therefore it is incremented by oneevery time a beacon interval ends and reset to zero in the event a beacon messagefrom the corresponding neighbor is being received.

After making sure that the coordinate table does not contain outdated information,it is checked if the current coordinates have to be adjusted according to the table’snew (clean) content. Although the coordinates are potentially updated with everymessage received during a beacon interval, it may be the case that one of the node’sparents has just been evicted from the table due to its age which would then callfor coordinate reconciliation. Still the online update of the coordinates with everybeacon message received makes sense, since it leads to the coordinates always havinga very up to date state on the node which becomes even more important when longerbeacon intervals are configured. However, the state of the current coordinates at theend of a beacon interval is always kept as well (in the last coords) in case they areneeded.

With the updated current coordinates the mean coordinates can now also be up-dated, which is explained in detail in section (6.4). At the end the sequence numberfor the beacons is incremented, the beacon message packet is filled with the necessaryinformation and is handed over to the communication stack component to be sent.Notice that the neighbors ids field in the beacon message is filled with informationfrom all coordinate table entries, not only those of symmetric neighbors, since itis supposed to list all neighbors from which the node sending the beacon messagereceived something regardless if that node has ever received anything itself.

6.4 Coordinate Distributions

Every time a beacon interval ends (i.e. the BeaconTimer fires) the current coordi-nates of the node are updated (cf. section 6.3). This is also the time the node’s meancoordinates are potentially updated according to the new current coordinates. Everynode stores a history of its current coordinates during the last beacon intervals. Ourprototype keeps the last 30 coordinates which, assuming a beacon interval length often seconds, leads to a history size of five minutes4. The history is a ring buffer ofCoordinates (cf. section 6.2), which is appended with the current values of the node’s

3Even though the interval length stays constant (ten seconds in our prototype), a random jitteris always added to it to help avoiding beacon message collisions in the network.

4We justify all these parameters in section 7.2.

6.5. Routing Decisions 65

current coordinates at the end of each beacon interval, regardless if the coordinateshave been changed during this interval or not.

Additional to the history we also keep a representation of the coordinates’ distri-bution on the node. This is not necessarily needed to calculate the node’s meancoordinates, as they can be derived directly from the history as well. However, aswe will see in section 7.1, it needs only a little memory space (240 bytes in ourprototype) and simplifies the mean coordinate calculation. It is an array of two-byteintegers for every beacon in the network sized from zero to some maximum numberof hops (20 in our implementation). Each cell holds the number of times this hopcount appears in the history of the node’s current coordinates. Every beacon inter-val the values in the cells representing the old coordinates from the last interval aredecremented and the cells for the new coordinates are incremented. This procedureassures a very low overhead for keeping this data structure up to date.

Furthermore, there exists an array of two-byte integers, one cell for every beacon,counting the number of invalid coordinates, as they do not belong in the coordinatedistribution but are still important to keep track of, as a very high number of invalidcoordinates attests a very bad connectivity to the node. Now to calculate the node’smean coordinates one could use the history or (as we do) the distribution table.This is possible because we use a simple unweighted moving average for our meancoordinates. The hop distance to the beacons in each of the past beacon intervalsuntil the end of the history length is considered with an equal impact on the result.Later versions of our protocol might use a more sophisticated way to calculate maybeeven totally different statistical values to be published in the network.

6.5 Routing Decisions

Whenever SVR’s router component has to send a data packet with a certain desti-nation, it needs a next hop, i.e. a neighbor of the node to forward the packet to5. Incase the packet’s destination can be found among the node’s direct neighbors, thepacket shall be forwarded there, of course. Otherwise the neighbor closest to thedestination is to be determined, meaning the one whose address vector is the mostsimilar to the one of the destination.

The state component is queried to elect this next hop, which first delegates the taskto the coordinate table component. Here a size-limited list of symmetric neighborsis generated, in ascending order of their distance to the destination. This distancecan be defined in several ways, and in fact there are different distance metrics imple-mented in our prototype to choose from. However, in our tests and experiments weused the simple absolute vector difference between the destination’s and the neigh-bor’s address vector6. For the distance calculations only coordinate componentsthat are valid in the destination’s and the neighbor’s mean coordinates are used,the others are ignored. The absolute difference of all components is calculated andsummed up leading to a distance value for every neighbor in the coordinate table.

5The beacon packets do not need a destination, as they are always broadcasted and not for-warded by other nodes.

6For all these calculations the mean coordinates are used, as those are the coordinates we assumeavailable in the network to route on. Their derivation formula can be found in section 5.4

66 6. Implementation

Only neighbors underbidding the minimal distance to the destination the packet hasreached so far are added to the list of possible next hops, i.e. all neighbors thatcan provide a routing progress. To use the packet’s real minimal distance it wouldhave to be carried in the packet itself. To avoid this we use an upper bound forit, namely the distance of the current forwarding node. Theoretically this wouldguarantee a distance progress in every routing step assuming every node on the wayfinds a suitable next hop that is closer to the destination than itself. This might failin case a node does not find such neighbors in its table or the packet does not reachany of them. If this happens SVR switches to the fallback routing mode.

The fallback mode is the same as in the Beacon Vector Routing (BVR) protocol,which is described in detail in section 3.1.1. The next hop neighbors for the nor-mal routing mode and for the fallback mode are aligned in the same list, in thenextHopInfo structure described in section 6.2, which is returned by the coordinatetable over the state component to the router. It is tried to forward the packet to thenodes in this list from the top on. Every time a certain number of (re)transmissionsto a node in the list fail the next entry is tried.

At the end of the list there is at most one fallback entry, namely the parent ofthe distance tree of the beacon closest to the destination. In case this parent doesnot exist (meaning the forwarding node does not have a valid component for thisbeacon) or in case this parent does not receive the packet either, the sending of thepacket fails as both routing modes did not find a next hop. A possible improvementwould be to alternatively forward the packet to the beacon second closest to thedestination, the third closest and so on and to finally resort to flooding the packetin hope that any of the node’s neighbors will have better neighbors in its coordinatetable.

However, aside from the fact that single data packets in WSNs are hardly thatimportant to justify the resulting overhead in additional transmissions, this eventthat both routing modes fail to forward the packet is very unlikely. The forwardingnode would have to be already very close to the destination, still not a direct neighborand must have no nodes in its coordinate table which are closer to the destinationthan itself. Even then it would also need to have a bad connectivity to lack theone parent it needs to forward the packet to in fallback mode. In our experimentsthis practically never happened, as we always gave the protocol some time in thebeginning to establish the coordinates of all the nodes before we started sendingdata packets.

Normally the fallback routine leads to the packet being forwarded towards the beaconclosest to the destination. If a node on this way finds a neighbor that can deliverthe packet in normal mode, the protocol switches back to this mode. However,if the packet eventually reaches the beacon it aimed for, this beacon initiates ascoped flooding, which is supposed to deliver the packet assuming that the nodesare connected.

7Evaluation

In this chapter we present the results of our evaluation. First we give an overviewover the memory that is needed for the data structures we introduced (cf. section6.2) and explain which parameters exist to influence the functioning of our StatisticalVector Routing (SVR) prototype and the values we chose for them. The next partrefers to section 4.3 of our analysis and compares the dynamics induced by theephemeral current coordinates shown there with the ones of our newly introducedmean coordinates (cf. section 5.4).

We also compare our results to the ones we obtained with the original Beacon VectorRouting (BVR) protocol implementation to see if we benefit from our abandonmentof traditional link estimation. Furthermore, we compare SVR’s and BVR’s routingperformance. Section 4.1 explains the testbeds we used for this and the experimentswe conducted in detail.

7.1 Memory Requirements

Certain parameters influence the behavior of our Statistical Vector Routing protocol.Since they all represent some limit of a data structure size, increasing them alwayscosts memory. Since most of the costs are dependent on more than one parameterat the same time, we give an insight into how much memory it costs (on the nodesand in the beacon messages) to increase each value assuming the others stay thesame. We identify the following parameters:

• history size (h): This influences the length of the time period from whichthe current coordinates are taken to derive the nodes’ address distribution, i.e.its mean coordinates.

• distribution size (d): This denotes the maximum hop distance that can berecorded in the structure, which stores the coordinate distribution.

68 7. Evaluation

• neighbor table size (n): This is the highest number of neighbors a node canbe aware of and have information about at the same time.

• trace length (t): This is how much of the path from the node to the beaconis stored for the source beaconing during the address derivation process.

• number of beacon nodes (b): This states how many beacons there are inthe network, i.e. the dimensionality of the virtual coordinate system.

The history size (h) parameter has the least influence on the memory footprint.It is used to calculate the coordinate distribution and the mean coordinates. Sincethe history stores coordinates, its entries’ size depends on b. Aside from the historyarray itself there is an array of pointers to access its entries. On our sensor nodespointers need two bytes of memory space, hence the overall impact on the memoryconsumption of a transition from h to h + 1 is b + 2. Since the history is onlytransmitted to other nodes in form of the mean coordinates, the history size doesnot affect the beacon messages’ packet size.

The distribution structure, whose size is determined by the distribution size (d)parameter, keeps track of the hop count frequencies of the nodes. It only takes up twobytes for each possible hop count. However, there is one such distribution structurefor each beacon node in the network. Thus, a change from d to d + 1 leads to anincrease in memory of 2b bytes, yet it does not have any impact on the size of thebeacon packets. This structure contains redundant information, which is also storedin the history itself. If the explicit coordinates are not needed but their frequenciessuffice, the distribution structure could provide the necessary information on its own.Omitting the history would save a significant amount of memory.

A change in the neighbor table size (n) has a major effect on the memory foot-print, since it increases the number of Coordinate Table Entries (CTEs) on thenodes. A CTE takes up 11 + 2b + bt bytes of memory: two coordinates (2b), atrace for every beacon (tb) and 11 bytes of static information. The details aboutthe format of the CTEs can be found in Listing 6.1 in section 6.2. Furthermore, thebeacon packet size increases with more neighbors as well (only 1 byte for every n),because all nodeIDs of all entries in the coordinate table have to be included here.

Increasing the trace length (t) leads to more memory consumption on the node aswell as in the beacon packets. On the nodes the size of the entries in the coordinatetable (CTEs) changes, since they all contain a trace for every of the correspondingneighbor’s parents. Additionally, if a neighbor becomes a node’s new parent, one ofthat traces has to be extended with its nodeID and henceforth to be sent around inthe beacon messages from that node. Hence, increasing the trace length from t tot+ 1 leads to the memory footprint increasing by nb, as there are n CTEs and eachCTE stores b traces, which get larger. The size of the beacon packets grows by bbytes, one byte for each trace in the packet.

The most memory growth is caused by an increase in the number of beacon nodes(b), since it affects the size of every data structure that stores coordinates. In totalwe have a memory increase of 8 + 2d+h+ tn+ 2n when changing b to b+ 1, becausewe have to store four coordinates in the router and the state component (4), thedistribution structure becomes longer (another array and a bigger array for invalid

7.2. Finding Parameter Values 69

parameter significance formulanode

formulapacket

increasenode

increasepacket

h historysize

b+ 2 – 8 0

d distributionsize

2b – 12 0

n neighbortable size

11+2b+bt 1 53 1

t tracelength

nb b 180 6

b number ofbeacons

8+2d+h+tn+ 2n

t+ 2 288 7

Table 7.1 Formulas for the memory usage increase for the different parameters

coordinates, hence 2d+2), we need to store an additional parent nodeID (2), a longercomponents in the history (h), and in every CTE the current and mean coordinateboth become longer (2n) as well as every entry gets an additional trace (tn). Inthe beacon packets the traces and both coordinates are extended resulting in a sizeincrease of t+ 2. Table 7.1 summarizes the formulas to calculate the memory usageincrease and the actual values a parameter change would cause in our prototype.

7.2 Finding Parameter Values

The parameters mentioned in the section above all not only influence SVR’s memoryfootprint but also have an impact on its functioning. We had to decide on appro-priate values for them to conduct our experiments. As explained in section 5.2,we do not consider beacon placement and election to be in our scope. We madegood experiences with 6 beacon nodes placed evenly distributed on the edges of thedeployment area, so we kept this setting.

For the values of the trace length, the distribution size and the maximum numberof neighbors we ran some experiments with rather high values to see how close thenodes would get in reaching these upper bounds or if they would even exceed themfrequently. In the end we concluded the values of 5 for the trace length, 20 for thedistribution size and 30 for the maximum number of neighbors. The distributionstructure is only a way to simplify the calculation of the statistical values to publish.It contains redundant information which is also available in the coordinate history.If memory becomes an issue, we can always refrain from using it.

The size of the neighbor table was very rarely reached in our experiments. Weconsider the few times this happens acceptable, as the neighbor table takes a lotof memory space, meaning we cannot make it too large. Furthermore, the table’sfilling degree strongly depends on the transmission power level used, meaning if thetables on the nodes become too full, we can always reduce the power level to avoiddiscarding random neighbors. Later, optimizations such as an appropriate evictionstrategy will lead to a more efficient use of the table space.

70 7. Evaluation

101 102 103 104 105

History Size [seconds]

0

5

10

15

20

Erro

r Pro

babi

lity

[%]

used by SVR (300sec; 6.5% error)

BeaconsMean

Figure 7.1 Error levels for different history sizes: The straight line represents themean of all six beacons. The value chosen for SVR is denoted by thevertical line. It keeps the average error at 6.5%. To get below 5% isonly feasible in longer experiments.

The traces are the only data structure that frequently reach their maximum size,since paths from a beacon to any node in the network may very well at least tem-porarily exceed the length of 5. However, to avoid loops in the beacons’ distancetrees knowledge about the end of the paths is more important than about the be-ginning, since a node would always extend the path at its end. This fact pairedwith the rather high memory consumption of the traces especially inside the beaconpackets made us stick to this value.

The history size parameter deeply effects our statistical values, i.e. the mean coordi-nates published by the nodes, which are supposed to approximate the real coordinatedevelopment and distribution. To explore the effects of different history sizes we usedthe data from the experiments, in which we derived the development of the nodes’current coordinates and which are described in section 4.3. We partitioned the wholeexperiment duration such that one part represents the time for which the coordinateinformation can be stored in the history. A history size of six beacon intervals forexample would lead to parts of one minute length, considering a beacon intervallength of ten seconds.

We derived the coordinate distribution over the whole experiment duration and forthe single parts of the duration and compared them using the χ2 test described insection 2.5. The test calculates how similar two sets of values are and, based onthis, how likely it is that these sets can be represented by the same distribution. Weconsidered its outcome, i.e. the probability that the two distributions are equal, as a

7.3. Coordinate Stability 71

metric for the similarity of the distributions and explored the dependency betweenthis similarity and the history size. Of course, the bigger the history size is, the moresimilar the distributions get, as with a history size as large as the whole experimentduration the probability of both distributions being equal will be one.

However, we have to consider the limited capacity of the sensor nodes, which canonly keep track of rather few of their last coordinates. We wanted to find out howmuch of the coordinates’ history is needed to produce a distribution that is similarenough to the real distribution such that it can represent it and be used instead.The results of these calculations are shown in Figure 7.1. We see that the error ratesdrop rather quickly. To achieve an error rate1 of less than 5%, which would be avery good approximation, we would need a history size of at least 600 seconds, i.e.10 minutes. Since our experiments only last 30 minutes because of the limitationsdictated by MoteLab and Indriya, this was not feasible for us.

We chose a history size of 300 seconds (5 minutes), which still leads to a good errorprobability of 6.5%. Furthermore, it does not take up too much space on the nodesand does not make up too much of the whole experiment duration. The numbersshown in Figure 7.1 were derived on Twist in an experiment running 24 hours, asthis makes the outcome more reliable. Twist does not have a direct upper boundfor the experiment length as it is the case on MoteLab and Indriya. However, whencalculated from the data of a 30 minutes experiments the error rates are much higher,as the distribution for the whole experiment duration is too small to be useful as areference.

There are a lot of other parameters in the implementation, which can influence thefunctioning of the protocol, such as the length of the list derived by the coordinatetable component containing a packet’s possible next hops. However, we considerthe impact of these other parameters to be rather small and did not conduct specialexperiments to determine their optimal value. There might still be room for opti-mization by adjusting these values, but for our experiments we left them on theirdefault value as given in BVR’s implementation. The values for all the parametersmentioned in this section may as well be optimized in dedicated experiments. Weconsider this future work.

7.3 Coordinate Stability

With the parameters fixed as explained in section 7.2 we ran experiments to evaluateif our efforts really led to the coordinates being more stable than we had observed insection 4.3. The results presented in Figure 7.2 and 7.3 confirmed this hypothesis.For our three testbeds we compared:

• coordinate range: the difference between the maximum and minimum coor-dinate

• average coordinate: the average distance to any beacon

1The error is the complementary probability of the χ2 analysis and thereby the chance of thedistributions to be different.

72 7. Evaluation

0 2 4 6 8 10 12 14 16 18Node Coordinate Range

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(a) Coordinate range in Mote-Lab

0 2 4 6 8 10 12 14Node Coordinate Range

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(b) Coordinate range in Indriya

0 2 4 6 8 10 12 14 16Node Coordinate Range

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(c) Coordinate range in Twist

1.5 2.0 2.5 3.0 3.5 4.0Node Average Coordinate

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(d) Average coordinate inMoteLab

1.5 2.0 2.5 3.0 3.5 4.0 4.5Node Average Coordinate

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(e) Average coordinate in In-driya

1.0 1.5 2.0 2.5 3.0 3.5Node Average Coordinate

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(f) Average coordinate in Twist

10-1 100 101 102

Node Change Rate [Share of Intervals with Change, %]

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(g) Coordinate change rate inMoteLab

10-1 100 101 102

Node Change Rate [Share of Intervals with Change, %]

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(h) Coordinate change rate inIndriya

10-1 100 101 102

Node Change Rate [Share of Intervals with Change, %]

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVR (current coords)SVR (mean coords)BVR

(i) Coordinate change rate inTwist

Figure 7.2 Results from the Coordinate Stability experiments: In most cases SVR(with its mean coordinates) produces similar results as BVR or evenoutperforms it. The unfavorable dynamics observed with SVR’s currentcoordinates are definitely under control.

• coordinate change rate: the share of beacon intervals in which a coordinatechanged

We always ran separate experiments for SVR and BVR. The metrics were alwaysderived for SVR’s current coordinates, i.e. the actual ephemeral node distances tothe beacons, BVR’s coordinates, and the mean coordinates SVR uses for routing.Figure 7.2 makes clear that the current coordinates (as expected and seen in section4.2) show a very dynamic behavior, which is much lower with the mean coordinates.In all the cases SVR’s mean coordinates produce better results than the ones usedin BVR. We also see this very clearly in Figure 7.3, where the average values arepresented. SVR always shows a smaller coordinate range, average coordinate, andchange rate despite BVR’s very cautious approach, where only very reliable linkstowards the beacon nodes are used in their distance trees. In section 7.4 we will seethat our more greedy approach leads to fewer hops not only on the paths between

7.4. Routing Performance 73

MoteLab Indriya Twist0

1

2

3

4

5

6

7

8

9Coordinate Range

MoteLab Indriya Twist0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5Average Coordinate

MoteLab Indriya Twist0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6Change Rate [%]

SVRBVR

Figure 7.3 Comparison of the average values from the Coordinate Stability exper-iments: The values for SVR’s current coordinates were constantly offthe charts. “SVR” here means the mean coordinates. We omitted thecurrent ones, as they only impaired the graph’s readability.

the nodes and the beacons (leading to smaller average coordinates), but also on thepaths the data packets take through the network.

7.4 Routing Performance

The other important question we wanted to answer was if our approach to stabilizethe virtual coordinates still allows us to achieve a good routing performance on thisnew addressing schema. For this we included data transfer in our tests. We ranthe experiments for BVR and SVR as well to compare their performance. Everyexperiment lasted 30 minutes, where we let both protocols establish their coordinatesystem in the first 15 minutes of every experiment. Since really long experimentswere not possible on every testbed, we let the nodes send beacons at a faster rate(every second) in the first 10 minutes to speed up the coordinate system establish-ment. The last 20 minutes of the experiment beacons were sent with a frequency of10 seconds as usual.

After the initialization phase the data transfer started. We chose ten node pairs,where for every pair a packet from the sender to the receiver node had to take severalhops. First we queried the destination node over its serial interface for its meancoordinates2. The received coordinates were sent to the sender node together withthe command to send a burst of 500 packets at a rate of 100ms to the destination.Each time a sender node was done sending the next burst was initiated on the nextsender after querying the new destination for its mean coordinates. With ten senderand receiver pairs and this amount of data almost the whole rest of the experimentwas filled with data packet transfers.

Every time a node received a packet, regardless if it was designated for itself orto be forwarded, a message of the type SVRRouteLoggingMsg was logged for us toreconstruct the routes the packets took through the network. All the informationcontained in this logging message is taken from the data packet arriving and from

2Normally the sender node would send a query to the knowledge base in the network.

74 7. Evaluation

1 2 3 4 5 6 7Number of Hops

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVRBVR

(a) Hops needed in MoteLab

0 2 4 6 8 10 12 14 16Number of Hops

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVRBVR

(b) Hops needed in Indriya

0 2 4 6 8 10 12Number of Hops

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVRBVR

(c) Hops needed in Twist

0 5 10 15 20Number of Transmissions

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVRBVR

(d) Transmissions needed ratein MoteLab

0 5 10 15 20Number of Transmissions

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVRBVR

(e) Transmissions needed ratein Indriya

0 2 4 6 8 10 12 14 16Number of Transmissions

0.0

0.2

0.4

0.6

0.8

1.0

CDF

[P(X

x)]

SVRBVR

(f) Transmissions needed ratein Twist

Figure 7.4 Number of hops and transmissions needed in SVR and BVR: Thedashed line represents BVR’s performance, the straight line the per-formance of SVR. In most of the cases SVR outperforms BVR.

a data structure the router component maintains for each routing process, whichbasically contains nodeIDs of the neighbor that forwarded the packet to the nodeand the one the packet is supposed to be forwarded to in the next routing step. Theformat of the logging message can be found in Listing 7.1:

• origin: This is the nodeID of the node that originally sent the packet triggeringthis logging message, i.e. the packet’s original sender.

• msg id: Here the messageID of the packet is stored, i.e. its sequence number.

• mode: This field contains information about the mode the packet was sentin. Details about the normal, fallback and flooding mode are given in section3.1.1.

• last hop: This is the nodeID of the packet’s last hop, i.e. the neighbor thatsent the packet to the node issuing this logging message.

• this hop: This is the node currently handling the packet, which also includeslogging this message.

• next hop: Here the node that is supposed to be the next to receive the packetcan be found, i.e. the first in the list of possible next hops determined via theinformation in the coordinate table.

• hopcount: This field keeps track of the number of hops the packet has takenso far from its original sender to the node logging this message.

7.4. Routing Performance 75

MoteLab Indriya Twist0

1

2

3

4

5Hops

MoteLab Indriya Twist0

1

2

3

4

5

6

7Transmissions

MoteLab Indriya Twist0

5

10

15

20Packet Loss [%]

SVRBVR

Figure 7.5 Comparison of the average values for routing: SVR reduces the packetloss significantly in every testbed. The number of hops and transmis-sions is reduced most of the times.

typedef nx s t ruc t SVRRouteLoggingMsg {nx u int16 t o r i g i n ;nx u int16 t msg id ;nx u in t8 t mode ;nx u int16 t l a s t hop ;nx u int16 t th i s hop ;nx u int16 t next hop ;nx u in t8 t hopcount ;nx u in t8 t number trans ;nx u int16 t d e s t i d ;Coordinates de s t coo rd s ;

} SVRRouteLoggingMsg ;

Listing 7.1: SVRRouteLoggingMsg: This message is logged every time a node re-ceives a message, regardless whether the packet still has to be forwarded or not.

• number trans: This field, however, records all transmissions needed so farto get the packet to this node, i.e. the hops as well as the retransmissions.

• dest id: Here the nodeID of the packet’s destination is stored. If a neighborwith this ID is found in the coordinate table, it can be delivered directly.

• dest coords: These are the mean coordinates of the destination, i.e. theaddress the packet is routed to.

Figure 7.4 summarizes the results of the routing performance analysis. We see thatregarding the number of hops and transmissions SVR’s routing performance is mostlybetter than BVR. For MoteLab the CDF lines cross one and the other time, but theaverages (cf. Figure 7.5) show a clear advantage for SVR, whose magnitude seemsto depend on the connectivity of the testbed. Our prototype almost consistentlyproduces better results than BVR. The packet loss shows the most significant differ-ence, particularly in the less connected testbeds. A poorer connectivity among thenodes seems to challenge BVR’s rather slow adaptability. However, our approach

76 7. Evaluation

while producing a little bit more overhead caused by coordinate changes copes wellwith the network dynamics still delivering packets with acceptable costs.

8Conclusion

In this thesis we presented Statistical Vector Routing (SVR), a multi-hop point-to-point routing protocol for wireless sensor networks (WSNs), which bases on virtualcoordinates. The challenges of the routing task are caused by the dynamics presentin wireless networks. Connections between nodes are not stable and reliable, buttheir quality fluctuates over time. In section 4.3 we saw the dimension of thesedynamics.

The common way for routing protocols to deal with this problem involves a long-term link estimator, which measures the connections to a node’s neighbors. Routingsteps are then restricted to those neighbors, to which a connection of very high andstable long-term quality exists. In this way, mostly very close neighbors are usedas a next hop for routing, because the link quality between nodes correlates withtheir distance. However, farther away nodes can present opportunities to cover a lotof distance towards the packet’s destination with one routing hop. These shortcutscan seldom be used by conservative routing protocols because of their cautious linkselection.

Our approach aims at taking advantage of these opportunities by utilizing connec-tions to all neighbors for routing as well as for the establishment of the virtualcoordinate system, regardless of their long-term link quality. Therefore, our designdoes not need any explicit link estimation, and adapts very quickly to changes in thenodes’ connectivity. We use a very simple routing metric, yet our evaluation showsthat SVR achieves a similar routing performance as Beacon Vector Routing (BVR).Regarding packet loss BVR is even clearly outperformed by SVR.

However, this very greedy approach creates the necessity to deal with the over-head resulting from the constant shifts in the nodes’ coordinates due to changingneighbor relations. With our idea of considering the nodes’ addresses coordinate dis-tributions we derive statistical values, which are published by the nodes instead oftheir ephemeral actual current coordinates. Our evaluation proves these statisticalvalues to be stable enough to reduce the overhead for keeping them up to date in

78 8. Conclusion

the knowledge base of the network to an acceptable level. Therefore, our chosen rep-resentation for these distributions, i.e. the mean coordinates, are precise and stableenough to be used for routing.

8.1 Future Work

In section 7.2 we explored which parameters can influence the functionality of SVRand reasoned why we use certain values for them, which could be extended to otherparameters to further optimize SVR. A candidate for this would be the aging thresh-old. Entries in the coordinate table are deleted if a node does not receive any beaconmessages from the corresponding neighbor for a certain time. Together with a morecomplex eviction strategy, which maybe takes into account more properties of aneighbor, this could lead to a more efficient use of the coordinate table space.

We are confident that a more sophisticated distance metric will improve SVR’s rout-ing performance even more, since we consider our small average coordinates a signfor the success of our greedy neighbor selection mechanism. We would like to ben-efit from this for the routing decisions as well. A related idea is developing severalrouting metrics and always using the one that promises the most gain. Right nowall nodes in the network have the same addressing information at their disposal. Apossible improvement could be to employ several levels of precision for the informa-tion that a node distributes such that nodes farther away only get a rough idea ofit and closer nodes get more precise information for routing.

We would also like to perform a stress test for our protocol to see how quickly packetscan be delivered and how many nodes can send packets simultaneously. Related tothat, SVR’s ability to adapt to changes in the network topology would be anotherinteresting issue to explore. We expect SVR to recover quite fast from node failures.Combined with this is the question of the ideal beacon interval. Right now we areusing a rather high frequency of beacon messages, which surely can be reduced, atleast after some initialization time.

Unfortunately, we were not able to test SVR in really long experiments, as this wouldhave yield further insight in its ability to stabilize. We would expect that after aninitialization phase the nodes’ coordinate distributions will not change significantlyanymore, unless a severe change in the network topology occurs. During normaloperation, however, only very few beacon messages would be needed. Of course,this again rises the question of the appropriate history size, i.e. the time periodwhich best represents the nodes’ coordinate distribution, which we already tried toanswer for shorter time frames in section 7.2.

Our implementation of SVR is a first prototype, which proves that the concept ofstatistical addresses we developed is feasible and can achieve a good performancewhile being much simpler and consuming less resources than existing solutions suchas BVR. Although it produces very promising results, there is still room for opti-mization and improvement.

Bibliography

[1] Alizai, M. H., Landsiedel, O., Bitsch Link, J. A., Goetz, S., andWehrle, K. Bursty traffic over bursty links. In Proceedings of the 7th ACMConference on Embedded Networked Sensor Systems (SenSys’09) (Berkeley,California - November 4-6, 2009, 2009).

[2] Becher, A., Landsiedel, O., Kunz, G., and Wehrle, K. Towardsshort-term wireless link quality estimation. In 7. GI/ITG KuVS FachgesprachDrahtlose Sensornetze (September 2008), pp. 27–30.

[3] Biswas, S., and Morris, R. Exor: opportunistic multi-hop routing forwireless networks. SIGCOMM Comput. Commun. Rev. 35, 4 (2005), 133–144.

[4] Bitsch Link, J. A., Wehrle, K., Osechas, O., and Thiele, J. Ratpack:Communication in a sparse dynamic network. In ACM SIGCOMM 2008 PosterProceedings (Seattle, USA, 2008).

[5] Cao, Q., and Abdelzaher, T. A scalable logical coordinates framework forrouting in wireless sensor networks. In RTSS ’04: Proceedings of the 25th IEEEInternational Real-Time Systems Symposium (Washington, DC, USA, 2004),IEEE Computer Society, pp. 349–358.

[6] Doddavenkatappa, M., Chan, M., and Ananda, A. Indriya: A LowCost, 3D Wireless Sensor Network Testbed. Tech. rep., School of Computing,National University of Singapore (NUS), 2009.

[7] Fonseca, R., Gnawali, O., Jamieson, K., and Levis, P. Four-bit wire-less link estimation. In Sixth Workshop on Hot Topics in Networks (HotNets)(November 2007).

[8] Fonseca, R., Ratnasamy, S., Zhao, J., Ee, C. T., Culler, D.,Shenker, S., and Stoica, I. Beacon vector routing: Scalable point-to-point routing in wireless sensornets. In 2nd Symposium on Networked SystemsDesign and Implementation (May 2005).

[9] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., andCuller, D. The nesc language: A holistic approach to networked embeddedsystems. In PLDI ’03: Proceedings of the ACM SIGPLAN 2003 conferenceon Programming language design and implementation (New York, NY, USA,2003), ACM, pp. 1–11.

[10] Gnawali, O., Fonseca, R., Jamieson, K., Moss, D., and Levis, P. Thecollection tree protocol (ctp). Tech. rep., TinyOS, 2009.

80 Bibliography

[11] Handziski, V., Kopke, A., Willig, A., and Wolisz, A. Twist: a scalableand reconfigurable testbed for wireless indoor experiments with sensor networks.In REALMAN ’06: Proceedings of the 2nd international workshop on Multi-hopad hoc networks: from theory to reality (New York, NY, USA, 2006), ACM,pp. 63–70.

[12] Lee, H., Cerpa, A., and Levis, P. Improving wireless simulation throughnoise modeling. In IPSN ’07: Proceedings of the 6th international conference onInformation processing in sensor networks (New York, NY, USA, 2007), ACM,pp. 21–30.

[13] Levis, P., Lee, N., Welsh, M., and Culler, D. Tossim: accurate andscalable simulation of entire tinyos applications. In SenSys ’03: Proceedings ofthe 1st international conference on Embedded networked sensor systems (NewYork, NY, USA, 2003), ACM, pp. 126–137.

[14] Levis, P., Madden, S., Polastre, J., Szewczyk, R., Whitehouse, K.,Woo, A., Gay, D., Hill, J., Welsh, M., Brewer, E., and Culler,D. Tinyos: An operating system for sensor networks. In Ambient Intelligence(2004).

[15] Newsome, J., and Song, D. Gem: Graph embedding for routing and data-centric storage in sensor networks without geographic information. In SenSys’03: Proceedings of the 1st international conference on Embedded networkedsensor systems (New York, NY, USA, 2003), ACM, pp. 76–88.

[16] Ortiz, J., Baker, C. R., Moon, D., Fonseca, R., and Stoica, I. Beaconlocation service: a location service for point-to-point routing in wireless sensornetworks. In IPSN ’07: Proceedings of the 6th international conference onInformation processing in sensor networks (New York, NY, USA, 2007), ACM,pp. 166–175.

[17] Rao, A., Ratnasamy, S., Papadimitriou, C., Shenker, S., and Sto-ica, I. Geographic routing without location information. In MobiCom ’03:Proceedings of the 9th annual international conference on Mobile computingand networking (New York, NY, USA, 2003), ACM, pp. 96–108.

[18] Royer, E., and Toh, C. A review of current routing protocols for ad-hocmobile wireless networks. IEEE personal communications (1999).

[19] Rubner, Y., Tomasi, C., and Guibas, L. J. A metric for distributions withapplications to image databases. In Computer Vision, 1998. Sixth InternationalConference on (1998), pp. 59–66.

[20] Srinivasan, K., Kazandjieva, M. A., Agarwal, S., and Levis, P. Thebeta-factor: measuring wireless link burstiness. In SenSys ’08: Proceedings ofthe 6th ACM conference on Embedded network sensor systems (New York, NY,USA, 2008), ACM, pp. 29–42.

[21] Werner-Allen, G., Swieskowski, P., and Welsh, M. Motelab: a wire-less sensor network testbed. In Information Processing in Sensor Networks,2005. IPSN 2005. Fourth International Symposium on (2005), pp. 483–488.

Bibliography 81

[22] Woo, A., Tong, T., and Culler, D. Taming the underlying challengesof reliable multihop routing in sensor networks. In SenSys ’03: Proceedings ofthe 1st international conference on Embedded networked sensor systems (NewYork, NY, USA, 2003), ACM, pp. 14–27.

82 Bibliography

List of Figures

2.1 Schematic architecture of a sensor node . . . . . . . . . . . . . . . . . 6

2.2 Examples for Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Cumulative Distribution Function (CDF) . . . . . . . . . . . . . . . . 11

2.4 Example for Distance Vector Routing . . . . . . . . . . . . . . . . . . 12

2.5 Creation of a collection tree . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Routing on virtual coordinates . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Illustration for routing steps towards beacons assuring progress whilerouting further away does not . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Impression of the inability of long-term link estimators to captureshort-term fluctuations in link quality . . . . . . . . . . . . . . . . . . 23

3.3 Structure of the Four-bit link estimator . . . . . . . . . . . . . . . . . 26

3.4 Collection tree established by CTP and additional bursty links . . . . 27

3.5 CPDFs and corresponding KW and β values . . . . . . . . . . . . . . 29

3.6 Calculation of KW and β of an example link . . . . . . . . . . . . . . 30

3.7 Example of an ExOR run . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Distribution of the lengths of packet bursts in a network . . . . . . . 40

4.2 Results from the Coordinate Dynamics experiments . . . . . . . . . . 42

4.3 Development and distribution of coordinates . . . . . . . . . . . . . . 43

5.1 Probability of finding a good or intermediate quality neighbor de-pending on distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Illustration of the count to infinity problem . . . . . . . . . . . . . . . 51

5.3 Distributions as addresses in SVR . . . . . . . . . . . . . . . . . . . . 53

5.4 Illustration of the sum distance . . . . . . . . . . . . . . . . . . . . . 55

6.1 Structure of the relevant part of BVR . . . . . . . . . . . . . . . . . . 58

84 List of Figures

6.2 Effects of the two main events in SVR . . . . . . . . . . . . . . . . . 63

7.1 Error levels for different history sizes . . . . . . . . . . . . . . . . . . 70

7.2 Results from the Coordinate Stability experiments . . . . . . . . . . . 72

7.3 Comparison of the average values from the Coordinate Stability ex-periments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.4 Hops and transmissions needed in SVR and BVR . . . . . . . . . . . 74

7.5 Comparison of the average values for routing . . . . . . . . . . . . . . 75