athanasios florosntareme/thanos-thesis-text.pdf · an introduction to routing protocols for wsn and...

1 Athanasios Floros – Master Thesis report

ROUTING PROTOCOLS FOR SUN SPOTS – ANALYSIS,

COMPARISON AND IMPLEMENTATION OF NEW

PROTOCOLS

Master Thesis Report

Athanasios Floros ([email protected])

Supervisor

Marco Zennaro

Examiner

Björn Pehrson


Abstract

In the Wireless Sensor Networks (WSN) scientific field a lot of research has been made. The

routing among these devices is probably the most important part because it can affect the battery

consumption and the reliability of the network. The network has to offer as less energy consumption as possible and as safe exchange of packets as possible among the nodes. This is the

reason why the routing protocol has to take into account the battery level of each node and the

link quality between each pair of nodes along the route. Many routing protocols for WSNs exist but in this research project the aim is to focus especially in Sun SPOTs. Special study for these

devices is needed with experiments and graphs which show which are the benefits and drawbacks

of each protocol and the recommendation for a new one which can offer some new useful

elements. In this document there is (1) the introduction to the hardware used – the Sun SPOTs, (2) an introduction to routing protocols for WSN and a comparison of them, (3) Explanation of the

code of the default routing protocols used in Sun SPOTs and explanation of the two new ones, (4)

Indoor and outdoor experiments description and analysis with graphs.

Acknowledgements

I have to thank Hervé Ntareme with whom I made all the experiments. We were cooperating and

discussing through all the period of the execution of the experiments and after. He helped me so much and guided me so I can organize my time correctly. Also, I would really like to thank

Marco Zennaro, my supervisor, for his very accurate comments and guidance throughout all my

work.


Abbreviations

WSN – Wireless Sensor Networks SPOT –Small Programmable Object Technology

KTH – Kungliga Tekniska Högskolan (Royal Institute of Technology)

USB – Universal Serial Bus

IEEE – Institute of Electrical and Electronics Engineers LED – Light Emitting Diode

J2ME – Java 2 Micro Edition

J2SE – Java 2 Standard Edition CLDC – Connected Limited Device Configuration

VM – Virtual Machine

IDE – Integrated Development Environment TTL – Time To Live

SDK – Software Development Kit

API – Application Programming Interface

MAC – Media Access Control

List of Figures

Fig. 1.1: Free range SunSPOT - Free range SunSPOT without the lid

Fig. 1.2: Sun SPOT’s different parts

Fig. 2.1: Categorization for routing protocols in WSN Fig. 2.3: SPIN example

Fig. 2.4: The process of interest propagation with gradient building in Directed Diffusion

Fig. 2.3: TEEN-APTEEN hierarchical clustering Fig. 3.1: Sun AODV packet exchange example

Fig. 5.1: Topology for indoor AODVManager experiment

Fig. 5.2: Photo of the indoor AODV experiment

Fig. 5.3: AODV protocol indoors – packets received/mVolts

Fig. 5.4: LQRP protocol indoors – packets received/mVolts

Fig. 5.5 Node Lifetime Indoors- packets/mVolts Fig. 5.6: Current Topology with extra node 12D4

Fig. 5.7: Link Quality based protocol Indoors. Packets received/Battery Level(mVolts)

Fig. 5.8: Red: first failed outdoor experiment attempt. Green: second attempt and successful Fig. 5.9: Laptop and base station taped high enough on a stick

Fig. 5.10: SPOT inside its case hanging

Fig. 5.11: LQRPManager outdoor experiment

Fig. 5.12: LQRP – packets received/battery in mVolts

Fig. 5.13: Node Lifetime based protocol topology

Fig. 5.14: Node Lifetime based protocol- packets/mVolts

Fig. 5.15: Topology of Link Quality based protocol

Fig. 5.16: Link Quality based protocol graphs. Packets/mVolts


Table of Contents

1. Introduction............................................................................................................................6

1.1 Sun SPOTs ..........................................................................................................................6

1.1.1 Sun SPOT’s hardware ..................................................................................................7

1.1.1 Sun SPOT’s software....................................................................................................8

1.2 Background........................................................................................................................8

1.3 Unique contribution......................................................................................................... 10

2. Routing protocols in WSN .....................................................................................................10

2.1 Protocols depending on network structure ...................................................................... 11

2.1.1 Flat-based, data-centric routing................................................................................. 11

2.1.2 Hierarchical routing................................................................................................... 16

2.1.3 Location-based routing protocols .............................................................................. 18

2.2 Routing protocols based on protocol operation................................................................ 19

2.3 Proactive and reactive routing ......................................................................................... 20

2.4 Conclusion....................................................................................................................... 20

3. Sun SPOT’s routing protocols’ analysis..................................................................................21

3.1 AODVManager................................................................................................................. 21

3.1.1 AODVManager operation.......................................................................................... 21

3.1.2 Code analysis ............................................................................................................ 22

3.2 LQRPManager.................................................................................................................. 25

3.3 Node Lifetime based protocol .......................................................................................... 26

3.4 Link Quality based protocol.............................................................................................. 26

4. Modifications – the new protocols ....................................................................................... 27

4.1 Node Lifetime based protocol .......................................................................................... 27

4.2 Link Quality based protocol.............................................................................................. 28

5. Experiments – Results ...........................................................................................................28

5.1 Indoor experiments ......................................................................................................... 28

5.1.1 AODVManager .......................................................................................................... 29

5.1.1.1 Introduction ...................................................................................................... 29

5.1.1.2 Routing ............................................................................................................. 30


5.1.1.3 Graphs .............................................................................................................. 36

5.1.2 LQRP......................................................................................................................... 37

5.1.2.1 Introduction ...................................................................................................... 37

5.1.2.2 Routing ............................................................................................................. 37

5.1.2.3 Graphs .............................................................................................................. 45

5.1.3 Node Lifetime based protocol ................................................................................... 46

5.1.3.1 Routing ............................................................................................................. 46

5.1.3.2 Graphs .............................................................................................................. 51

5.1.4 Link quality based protocol ....................................................................................... 52

5.1.4.1 Introduction ...................................................................................................... 52

5.1.4.2 Routing ............................................................................................................. 53

5.1.4.3 Graphs .............................................................................................................. 57

5.2 Outdoor experiments....................................................................................................... 58

5.2.1 LQRPManager........................................................................................................... 61

5.2.1.1 Introduction ...................................................................................................... 61

5.2.1.2 Routing ............................................................................................................. 62

5.2.1.3 Graphs .............................................................................................................. 66

5.2.2 Node Lifetime based protocol ................................................................................... 68

5.2.2.1 Introduction ...................................................................................................... 68

5.2.2.2 Routing ............................................................................................................. 68

5.2.2.3 Graphs .............................................................................................................. 72

5.2.3 Link Quality based protocol ....................................................................................... 73

5.2.3.1 Introduction ...................................................................................................... 73

5.2.3.2 Routing ............................................................................................................. 74

5.2.3.3 Graphs .............................................................................................................. 77

6. Conclusions and Recommendations .....................................................................................79

6.1 Contribution .................................................................................................................... 79

6.2 Conclusions ..................................................................................................................... 79

6.3 Recommendations........................................................................................................... 80

7. References ............................................................................................................................80


1. Introduction

Wireless Sensor Networks (WSN) has been a very important field of research during the last

years. The newest devices are relatively small in size if compared to a router and some of them are designed to withstand harsh environmental conditions. These devices are highly mobilized

and automated, able to adapt to network or environmental changes. However, most WSN nodes

are still in an experimental stage. Hardware and software have to be improved so that these types of networks can work without problems as planned.

In this master thesis the WSN devices used are the Sun SPOTs (Small Programmable Object

Technology) provided by Sun Microsystems. The goal of this master thesis is:

1. To study routing protocols which could be applied to WSNs 2. Study the current and older routing protocol used in Sun SPOTs

3. Implement a new routing protocol which takes into account battery level and link quality

information. 4. Experiment with the protocols and study the results.

1.1 Sun SPOTs

Sun SPOTs are the main devices of interest in this project. They are little devices of 41 x 23 x 70

mm which weigh about 54 grams. They are developed by Sun Microsystems. They are wireless sensor network motes.

There are two types of Sun SPOTs: free range SPOT and base station SPOT. The base station is a

Sun SPOT without the battery which is connected through USB to a computer and it is used as a gateway between the computer and the free range Sun SPOTs. The free range SPOTs are

equipped with battery and add-on boards. As soon as they are charged and deployed with the

appropriate application, they can be placed far away and be able to communicate wirelessly with the base station and thus with the computer. A free range Sun SPOT is shown in Fig. 1.1 with the

lid placed and in Fig. 1.2 without it. The device’s characteristics are presented below.

Fig 1.1: Free range SunSPOT - Free range SunSPOT without the lid

Sun SPOT’s different parts can be clearly seen in Fig 1.2 right below.


Fig. 1.2: Sun SPOT’s different parts

1.1.1 Sun SPOT’s Hardware

A Sun SPOT device is built by stacking a Sun SPOT processor board with a sensor board and

battery.

Sun SPOT Processor Board

• 180 MHz 32 bit ARM920T core - 512K RAM/4M Flash

• 2.4 GHz IEEE 802.15.4 radio with integrated antenna

• USB interface

• 3.7V rechargeable 720 mAh lithium-ion battery

• 32 uA deep sleep mode

The Sun SPOT’s processor board uses a 180 MHz 32 bit ARM92 core with 512K RAM and 4M

flash. For networking, it uses the IEEE 802.15.4 radio standard on 2.4 GHz. The battery is rechargeable by using its USB interface. It can go to deep sleep mode in which it consumes 32

uA.

General Purpose Sensor Board

• 2G/6G 3-axis accelerometer

• Temperature sensor

• Light sensor

• 8 tri-color LEDs

• 6 analog inputs

• 2 momentary switches

• 5 general purpose I/O pins and 4 high current output pins

The sensor board has a 3-axis accelerometer to measure acceleration and generally movement of

the device. It also contains an ambient light sensor, eight tricolor LEDs, two push buttons, six


analog input pads, four high current high voltage output pads, and five general I/O pads.

1.1.2 Sun SPOT’s Software

Squawk Virtual Machine

• Fully capable J2ME CLDC 1.1 Java VM with OS functionality

• VM executes directly out of flash memory

• Device drivers written in Java

• Automatic battery management

Sun SPOTs are very flexible to program with very advanced capabilities for such a small device

because they are programmable with J2ME CLDC 1.1 Java VM. This small J2ME (Squawk) runs

directly on the processor without any other OS (Operating System). Developer Tools

• Use standard IDEs. e.g. NetBeans, to create Java code

• Integrates with J2SE applications

• Sun SPOT wired via USB to a computer acts as a base station

Sun SPOTs can be used with the standard IDEs like Netbeans to write Java code and deploy it on

the device. It can integrate with J2SE applications as well.

1.1.3 Sun’s SDKs

Along with Squawk Virtual Machine comes the SDK. Sun SPOTs started using the first version

v1.0 of the SDK named “Green”. Sun continuously releases updates of every version with minor fixes and in the long run major fixes. Until now, five stable versions have been released with the

current being the red one (v5.0). The stable versions of the SDK are presented below along with

some of the most important features added in each release.

Green v1.0

The first version contains classes and interfaces which deal with the hardware on the SPOT

processor board, support 802.15.4 over the SPOT radio, define the communications by radio

radiogram and socket protocols and other functionalities.

Orange v2.0

• Applications can open and use radio connections to SPOTs that are out of immediate

radio range provided these can be reached via multiple hops through other SPOTs (mesh

networking) with RadiostreamConnection class.

• The port numbers can be automatically assigned

• IRadioPolicyManager, a new class can be used to set radio parameters like panID,

channel, power and so on.

• Radiograms can now be longer than the radio packet size

• One base station can now monitor multiple Sun SPOTs

• Almost 180 bug fixes

With this version this optional software has been released:


• SPOTManager which monitors the system software available on the Sun SPOT

website, alerts developers when new software is available and installs it if desirable.

• Spotworld which monitors the application software on all Sun SPOTs which are within

radio range.

Purple v3.0

• Much improved multi-hop communication

• Improved AODV routing with neighbor announcements


Blue v4.0

• New SPOT utilities to calibrate the accelerometer, sniff packets and test the eDemo

sensors

• New persistent system properties to specify default radio channel, pan id and transmit

power

• Several new ant commands

• Spotworld is renamed to Solarium


Red v5.0

• New default routing manager LQRP replacing the old AODV

• OTA operations more reliable

• Improvements in Solarium

• Major improvements to the reliability of radio transmissions

1.2 Background

One of the most important tasks of a WSN routing protocol is to optimize the network lifetime. The battery energy of a node is depleted by: (i) computational processing and (ii) transmission

and reception of data to maintain the signal-to-noise ratio above a certain threshold. The latter is

often the most energy intensive, so routing protocol design plays a fundamental role in wireless sensor networks.

Extensive research has been carried in the field of routing protocols for WSN. Protocols can be

classified as proactive, reactive or hybrid. Proactive protocols compute all routes before they are

needed, while reactive protocols compute routes on demand. Hybrid protocols make use of a combination of these two. Since a WSN can consist of thousands of nodes, the routing table that

each node would have to keep could be huge and therefore proactive protocols are not suited to

WSNs. Advanced routing protocols keep into account the remaining energy of a node, while others use

link quality to select the best path. These protocols are the ones best suited for a real-world

implementation. The behavior of nodes in an outdoor environment, though, can differ from the

one offered by a simulator. These routing protocols should therefore be tested in practice, outdoors, for a long period of time to be able to select the best one in terms of optimization of

network lifetime.

At KTH we have been analyzing the performance of a wireless sensor network in an outdoor


environment in terms of link quality over time and of battery consumption. Six motes have been

deployed on the roof of the TSLab Kista building, in outdoor enclosures, and data has been

collected and stored for further analysis. The results indicate that LQI is a good indicator of link

quality and that battery consumption is linked to the quality of the link. The objectives of the project are to:

1. Analyze the performance of routing protocols for Wireless Sensor Networks in outdoor

environments. 2. Implement a routing protocol that takes into account link quality and battery level information.

1.3 Unique Contribution

During this thesis a lot of conclusions and results have been made. From week to week there was

a better understanding of WSNs and Sun SPOTs. After so many experiments and results only the

posts in the Sun SPOTs' official forum can show how important and new this work was. Many

posts made for this work which has attracted the interest of the Sun SPOT team and other people who work with Sun SPOTs asking for results and further information.

Another unique contribution is the very thorough Sun's routing protocol's comparison with the

new ones on a programming level. The analysis explains how the protocols work by showing the methods and classes that are used and how they function. This is a very important contribution

because both Sun's implementations have no documentation. If someone wants to understand the

protocols they would have to just download the source code and start reading it. With the part of the protocols analysis one can much faster understand how they work, use one of them and even

modify it.

The results-experiments chapter offers a more detailed comparison with numbers and graphs.

Through the figures which have been produced from the results of the outdoor and indoor experiments one can see how much the battery can last and get an idea of how each protocol's

routing works.

Finally, the most important contribution is the two additional versions of the new routing protocol which can offer routing taking into account either the battery level or the link quality information.

It is a unique contribution because the current protocol used by default uses a cost which uses

both parameters.

2. Routing protocols in WSN

Routing protocols in WSN can be categorized depending on the network structure, the protocol operation and as proactive or reactive. Fig 2.1 shows this categorization


Fig. 2.1: Categorization for routing protocols in WSN

2.1 Protocols depending on the Network Structure

The network structure is a very important factor in WSN. Several protocols are based on the network structure. The most important ones are presented below.

2.1.1 Flat-based, data-centric routing

Flat network structure means that every node has the same role. Nodes cooperate to exchange

packets. Since the network consists of a large number of nodes it is not possible to assign an

address or a kind of identifier for each node. The way the routing works in that case is by queries. The node sends queries to a certain region of nodes waiting for data from these specific nodes.

So, the routing is data-centric utilizing the attribute-based naming queries to realize the

communication.

Usually in these category of protocols data aggregation is used during relaying. Data aggregation

is a technique to aggregate the data collected through the network by combining similar data. That way, the amount of data to be transmitted is reduced and, as a result, the total cost is

reduced.

Several protocols fall into this category, the most important of them are presented in the following

paragraphs.


Flooding & Gossiping

In flooding, the node broadcasts the data to all its neighbors until destination is reached or until

packet’s TTL value equals 0

In gossiping the data is sent to one randomly selected neighbor.

The advantages with these ideas are that they are very simple and there is no need for state

maintenance. But, there are many redundant packets in the network, a lot of additional traffic, data overlapping and resources are not taken into account at all. Especially in gossiping there is

an additional delay because it selects a random node to forward the data so the delay appears in

the propagation of data in the network.

Sensor Protocols for Information via Negotiation (SPIN) is a group of adaptive protocols. This

protocol disseminates the data from one or more nodes to the whole network. The nodes that are relatively close maintain similar data. Therefore, the data is sent to nodes that are further away

which do not have it.

SPIN protocols transmit the data into the network with three different types of messages. This

way of communication is an improvement comparing to simple flooding due to the fact that it

takes advantage of negotiation between the nodes and resource adaptation.

When a node has new data to transmit, it sends the ADV (ADVertisement) message to advertise

this data to the neighbors via the data’s metadata.

The receiver of the message compares with what is known to it from this data and requests unknown data through the REQ message.

The requested data is transmitted through the DATA message. An example of the SPIN protocol is presented in Fig. 2.3


Fig. 2.2: SPIN example: A) A has data to send and sends the advertisement (ADV) to B, B) B

receives the ADV and sends back a request for data message (REQ), C) A sends the data


to B, D) After receiving the data, B sends advertisements of the data to the other nodes,

E) the other nodes request the data and afterwards receive it.

The family of the SPIN protocols consists of the following protocols.

• SPIN 1: a simple version of the protocol mentioned above

• SPIN 2: extension to SPIN 1 using threshold in the resources

• SPIN-PP: for point to point communication

• SPIN-EC: similar to SPIN-PP but with energy heuristics added.

• SPIN-BC: special for broadcast network

SPIN offers significant energy saving mechanism comparing it to simple flooding. Additionally, due to the negotiation, significantly less redundant data is added to the network. Last advantage of

SPIN is that the topological changes do not have to bother all the nodes since only the adjacent

nodes will know and learn the new topology.

Directed Diffusion is another data-centric protocol which has no need for global identifier. It uses

attributes combined with the values. Data from different nodes is combined inside the network. Thus, the redundant packets are fewer and the number of transmissions is decreased. Due to this

idea, there is a decrease in energy consumption.

In directed diffusion a base station requests data by broadcasting interests. An interest is a task

that the network needs to fulfill. Sensor nodes create gradients specifying value and direction. As

interests are broadcasted and propagated through the network, gradients are updated serving the queries of the node. Eventually the query will reach the destination node. The intermediate nodes

forward the data to reach the destination and create gradients to the source of the data. Along the

way, the data is aggregated. When the node has new data, it updates the interest and retransmits it. The network reinforces one or a small number of specific paths. This process can be seen in Fig

2.4.

SPIN and directed diffusion have some important differences. In directed diffusion the queries are

sent on demand, they are not advertised. In SPIN the opposite idea is applied; the sensors

advertise the data and interested nodes can query that data. The communication is from neighbor to neighbor, so, data aggregation and caching can be applied. Last, in directed diffusion there is

no need to maintain global network topology.


Fig. 2.3: The process of interest propagation with gradient building in Directed Diffusion

Rumor routing seems like a different version of directed diffusion. In directed diffusion the query

is propagated in the network through flooding when there is no other information about the

geographical position of the recipients. However, if the data being requested is small, flooding is not necessary.

The concept of rumor routing is to send the queries to the nodes which have recorded an event and not flood the queries to the whole network. For that reason rumor routing uses long-lived

packets which are called agents. The moment the node discovers an event, it records the event to

the events table and creates an agent. The agent goes through the network to reach the distant nodes and informs them about the events. Therefore, there is no flooding, a fact that is a


significant improvement of directed diffusion. However, only one route between the source and

the destination is used, a fact that can result in failure of communication if one node stops

working. Rumor routing performs better when the events are relatively few. In the case of many

events, it becomes infeasible to maintain so many agents and event tables.

Minimum Cost Forwarding Algorithm (MCFA) assumes the direction of the routes is known. Each sensor node maintains a least cost to the base station. Therefore, no routing table is needed.

When a node receives a message it checks if it comes from the least cost path between the source

and the base station. If this is true, the node forwards the message to its neighbors.

Gradient-based routing stores the number of hops which have been passed when the interest is

diffused through the network. Therefore, each node can count the height of the node. The height is the minimum number of hops to reach the base station. The gradient on a link is the difference

of the height between the node and the height of its neighbor. The packet is forwarded through the

link with the greatest gradient.

COUGAR uses declarative querying and tasking. The computing is distributed and it is done

inside the network. It uses in-network data aggregation for saving more energy.

ACQUIRE comes from Active Query forwarding In sensor nEtworks. Similar to COUGAR,

considers the network as a distributed database. The query is sent by the sink and each node that receives the query by processing the existing information. After that it forwards the query to a

neighboring sensor. If the existing information in the node needs to be updated, the node looks for

the information from the neighbors who are at most d hops far away. When the query is resolved completely, it is sent back to the sink.

Energy-Aware Routing is a protocol which aims at saving as much energy as possible. It is a reactive protocol and destination initiated. The idea behind this protocol is to use different paths

at different times. As a result each path’s energy will last longer. To achieve this, the protocol

maintains several paths instead of one optimal comparing it to directed diffusion. The paths are

selected taking into account probability of energy consumption. In fact, network lifetime is the only metric in this protocol and what only matters. It starts with localized flooding to discover all

the routes between each pair of nodes, build the routing tables and find the cost of each route.

Then it drops the high cost paths. An important disadvantage of this protocol is the setup phase which can take more time than directed diffusion.

2.1.2 Hierarchical routing

In wireless sensor networks as to in other kind of networks the idea of hierarchy is a very useful

technique to use in routing. Higher energy nodes can be higher in the hierarchy of the protocol

having the role of processing the information and transmitting it.

Clusters and a gateway (cluster head) are created for each cluster. In a single-tier network the

gateway can be overloaded if the number of nodes is increased. If the gateway cannot handle all the nodes latency in communication will occur.

Cluster heads aggregate and merge data so that fewer messages are sent to the base station. Since

the nodes communicate within a cluster having a limited number of hops, the energy consumption

is less. Generally, the main goals of hierarchical routing is what was just mentioned, fewer

messages to the base station and less energy consumption. This concept was used in routing protocols for WSN; the most important ones are presented below.

LEACH (Low Energy Adaptive Clustering Hierarchy) is a cluster based hierarchical protocol.

Each node uses a stochastic algorithm at each round to determine if it will become a cluster head

for this round. Nodes that have been cluster head cannot be cluster heads for P rounds where P is

the desired percentage of cluster heads. The probability for each node to become a cluster head in each round is 1/P. Thus, there is a rotation of cluster heads in order to evenly share the energy

consumption between the nodes. Each node that is not a cluster head looks for the closest cluster


head to become a member of this cluster. The cluster head creates a schedule of how to

communicate with each node in its cluster to transmit the data.

The cluster head compresses the data arriving from the nodes aggregates it and then sends it to the

base station. The aggregation is realized in order to send less information to the base station.

Each node communicates with the cluster head through TDMA (Time Division Multiple Access),

the way the cluster head has decided. The communication happens with the least energy possible

and when no communication is needed the radio is turned off. CDMA (Code Division Multiple Access) is used with different CDMA codes in order to avoid interference among the cluster

heads.

PEGASIS (Power Efficient Gathering in Sensor Information Systems) is a chain-based

protocol. The protocol is considered as an improvement to LEACH. In PEGASIS, each node

communicates only with the closest neighbor. To communicate with the base station, each node has to wait for its turn. In one round all the nodes have to communicate with the base station and

after that a new round begins. Thus, the energy consumption is fairly distributed among the nodes

since all the nodes communicate with the base station one by one. As explained above, there is no cluster structure in this protocol; instead, there is the chain structure where each node has to wait

its turn to collaborate in sharing the energy consumption.

PEGASIS intends first to increase network lifetime by forcing the nodes to collaborate in energy

consumption and second to decrease bandwidth consumption by forcing each node to

communicate with the closest neighbor.

To detect which neighbor is closest, the node uses signal strength indication to discover the

distance to every node. Then, it adjusts the signal strength so that it can communicate with only one node – the closest one. Thus, a chain will be constructed consisting nodes that are closest to

each other creating a route to the base station.

Threshold-Sensitive Energy Efficient Protocols are two protocols best suited for time-critical

networks: TEEN (Threshold-Sensitive Energy Efficient Sensor Network Protocol) and

APTEEN (Adaptive Periodic TEEN).

In TEEN, the sensor nodes are always in contact with the medium but they transmit data only

when it is needed. The cluster head defines a hard threshold which represents the threshold value of the sensed attribute and a soft threshold which represents a change in the value of the sensed

attribute. If that change happens the sensor node will turn on the radio and send the new data. By

using the hard threshold the protocol avoids unnecessary transmissions when the attribute is out of the range of interest. The soft threshold helps to reduce the number of transmissions by

avoiding sending data when there is a little or no change in the sensed attribute. If a smaller soft

threshold is used there will be more precise data while more energy will be needed. By the time a

new cluster head takes place new thresholds are broadcasted. The disadvantage of this protocol is that if the values are not received, the sensor nodes will not exchange data and no data will be

received by the user.

APTEEN is similar to TEEN adapted to user’s needs. The user can choose how often each value

will be used. The cluster heads in the case of APTEEN broadcast the parameters below:

1. Attributes: physical parameters for which the user has interest to receive data

2. Thresholds: the hard threshold and the soft threshold presented in TEEN

3. Schedule: the schedule following the TDMA technique assigning a timeslot for each

node.

4. Count time: the time between two successive transmits of data from the node. If the node

does not send data for time equal to count time, it has to sense and retransmit.

The important characteristics of APTEEN are that it leaves the user to decide what to do and that

it combines reactive and proactive routing. An example of hierarchical routing in TEEN and


APTEEN is shown in Fig. 2.3

Fig. 2.4: TEEN-APTEEN hierarchical clustering

2.1.3 Location-based routing protocols

Location-based routing happens when the protocol takes into account the location of the node. The location of the node can be specified by using signal strength indicators. A node can

approximately calculate the relative distance with its neighbors by examining how high or low the

signal strength from a neighbor is. If the signal strength is high, the neighbor is close. By examining all the signal strengths, a node can calculate relative coordinates. Another way to

specify nodes’ location is from a satellite by using a GPS (Global Positioning System) if the

nodes have a GPS receiver installed.


Geographic Adaptive Fidelity (GAF) is a location-based routing protocol with energy-aware

characteristics. The area of the network is split into zones. Inside the zone the nodes work

together to save energy. They choose one node to stay in wake up mode to monitor the network

behavior and report what is happening back to the base station what happens while the rest of the nodes are in sleep mode. GAF saves total energy by turning off nodes that are not used. Each

node specifies its position in the zone using GPS indication.

Three modes are used in the protocol:

• Discovery: for discovering the neighbors in the area

• Active: showing if the node is currently participating in the routing

• Sleep: the radio is turned off

The protocol handles mobility of the nodes by forcing the node to report what time it will leave

the area. When the node is about to leave, the other nodes wake up and decide a new one to stay on wake up mode.

Geographic and Energy Aware Routing (GEAR) is a protocol that uses heuristics to define the

position of the nodes and their energy state for routing. The concept is to decrease the data being

sent in the network by transmitting the data in specific regions and not to the entire network.

Each node maintains an estimated cost and a learning cost of reaching a destination. The

estimated cost is calculated from the energy left and the distance to the destination. The learned cost is the estimated cost but with taking into account holes that may appear meaning not having

any close neighbor in a specific area. If a hole appears, the route has to be changed. GEAR has

two phases:

• Forwarding packets towards the target region: when a node receives a packet, it checks if

it can reach the target region through a neighbor. If there are several neighbors available,

the node chooses the closest one. If there is none, it means that there is a hole. The packet is forwarded to a neighbor and the learning function is used.

• Forwarding packets inside the region: When the packets reach the destination region it

can be diffused by either recursive geographic forwarding or restricted flooding.

2.2 Routing Protocols based on Protocol Operation

Another classification of routing protocols in Wireless Sensor Networks is by protocol operation.

The categories are presented below:

Multipath routing protocols – In this case, the routing protocol uses multiple paths between two

nodes for routing. This idea can help in terms of redundancy and energy consumption. If there are

two paths available, when the primary link breaks, the routing protocol will route the packets through the secondary link and the communication will continue flawlessly. Concerning energy

consumption if there are several paths available the energy of the nodes of each path will not be

consumed so quickly since the paths will change. However, the switching of paths can consume energy as well.

Query-based routing – In the query based routing the node sends a query to the network asking for data. The node which has the sensing data asked will transmit it back to the node which

initiated the query. Directed Diffusion is an example of this type of routing with queries. Data

aggregation is a good solution for saving energy.

Negotiation-based routing – In this routing negotiation is used among the nodes in order to

minimize transmitting data that has already been transmitted. Data descriptors are used for this negotiation and the result is increase of network lifetime. SPIN is an example of that kind of

routing.


Quality of Service routing – The network in this case has to balance between energy

consumption and QoS parameters like delay, bandwidth.

Coherent and Non coherent Processing – This is a data processing technique which is closely

connected with the routing in a protocol. In non coherent processing, the main processing is done

by the nodes locally and then from other nodes for more processing. In coherent routing the nodes apply a minimal processing and send it to the aggregators for the main processing.

2.3 Proactive and Reactive routing

If someone thinks of how the source finds the route to destination, the protocols can be

categorized in reactive, proactive and hybrid mode.

Reactive routing: In this type of routing routes are computed on demand. A node sends a request

that wants to communicate and by receiving a route reply message the communication can begin. The disadvantage with this concept is high latency may appear during the procedure of finding

routes. Also the network can be overloaded if the flooding is heavy. On the other hand this type of

routing is bandwidth efficient.

Proactive routing protocols create and keep routing information for all the nodes whether this

information is needed or not. The information is collected by using control messages periodically. Proactive routing protocols are not bandwidth efficient since there are a lot of messages being

exchanged without all of them being useful. The main advantage of proactive routing is that it is

easy to get routing information and easy to establish a session. The drawbacks are first the heavy load of unnecessary data saved for routing and the difficulty in restructuring the communication

when there is a link failure.

Hybrid routing (Reactive and Proactive) is a type of routing which combines advantages of both

reactive and proactive routing. The routing is initially established with some prospected routes

and then serves the demand from additionally activated nodes through reactive flooding.

2.4 Conclusion

Routing in WSN uses several different techniques to be energy efficient and scalable. That is why

there are so many different protocols. Each protocol may use techniques from different categories

trying to be more efficient. It depends on the network and which are the user’s goals to specify

which protocol is the best for this occasion. In table 1 there is a summary of what was written in this document.

Category Negotia-tion

based

Data aggr.

Mobility Localiza-tion

QoS Scalability Multipath

Query-based

SPIN flat yes yes possible no no limited yes yes

Direct diffusion

flat yes yes limited yes no limited yes yes

Rumor routing

flat no no very

limited

no no good no yes

MCFA flat no no no no no good no no

GBR flat no yes limited no no limited no yes

COUGAR flat no yes no no no limited no yes

ACQUIRE flat no yes limited no no limited no yes


EAR flat no no limited no limited no yes

LEACH hierarchical

no yes fixed BS yes no good no no

PEGASIS hierarch

ical

no no fixed BS yes no good no no

TEEN-APTEEN

hierarch

ical

no yes fixed BS yes no good no no

GAF location no no limited no no good no no

GEAR location no no limited no no limited no no

Table 1: Comparison of WSN routing protocols

3. Sun SPOTs' routing protocols analysis

Sun had been using an AODV implementation for the Sun SPOTs until the 4th

blue version of the

Sun SPOT SDK. In an early stage of the 5th version of the SDK, the red one, Sun SPOT team

decided to change the default routing manager from the AODVManager to LQRPManager. LQRPManager is actually a module which was at an under development stage when included at

the early version of the API. LQRP (Link Quality Routing Protocol) is a module, a routing

protocol which takes into account battery level and link quality to route the packets. All the following routing managers are based on the Ad-hoc On demand Distance Vector (AODV)

protocol for routing. This layer offers communication from node to node no matter how far away

they are. Intermediate nodes are used to forward the packet to reach its destination. In a theoretical approach, AODV is a reactive protocol which creates the route to the destination

only when it is needed to, that is, on demand. When a node needs a connection, it broadcasts a

connection request. Every node receives the message, copies the source and forwards the

message. When a node that knows the destination receives the message, it sends back a message to the node that requested the connection. The requesting node chooses the route with the least

hops. It uses controlled flooding. Generally, AODV has been designed for mobile ad-hoc

networks and it ensures avoidance of loops and the counting to infinity problem. The Sun SPOTs have the RoutingPolicyManager class which implements

IRoutingPolicyManager. From this class the routing policy of the SPOT can be set. The four

routing policies of the SPOT are the following:

• ALWAYS: This is a dedicated mode. The SPOT participates fully in the AODV routing. It

replies to all RREQ packets and forward packets to other nodes. Deep sleep mode is

disabled in order for the SPOT to work all the time.

• IFAWAKE: The SPOT participates fully in the AODV routing is in ALWAYS policy if it

is awake. If the application turns the SPOT to deep sleep mode though, the SPOT will

disappear from the network.

• ENDNODE: The SPOT behaves as an end node. It generates RREQ packets when trying

to find a route, it replies if it is the destination. But it will not repeat RREQs to other

nodes or process packets for other SPOTs.

• SHAREDBASESTATION: Currently unimplemented.

3.1 AODVManager

3.1.1 AODVManager operation

The general operation of AODV in the default stack of Sun SPOTs consists of exchanging of the

common messages of AODV: Route Request (RREQ), Route Reply (RREP) and Route Error


(RERR). A common operation example is explained below. Its illustration is shown in Fig. 3.1.

1. A wants to send data to D. It does not have information about how to reach D in its

routing table. So, it broadcasts a RREQ which reaches B. B does not know either so it

rebroadcasts the message to C which does the same until it finally reaches D. 2. D answers with a RREP message since it is the destination which reaches the sender A.

3. In case the link C to D breaks, C generates a RERR message to inform that there was a

link failure to D. B and A refresh their routing tables.

Fig. 3.1: Sun AODV packet exchange example

3.1.2 Code analysis

The routing is managed by AODVManager class which controls how all the classes related to the

routing behavior will be used. The most important methods of this class are the following:

• findRoute(long address, RouteEventClient eventClient, Object uniqueKey)

• int getCurrentSequenceNumber()

• RouteTable getRoutingTable()

• synchronized void initialize(long ourAddress, ILowPan lowPan)

• boolean initiateRouteDiscovery(long address)

• boolean invalidateRoute(long originator, long destination)

• int getStatus()

The manager finds the routes asked, asks for the current sequence number of the packets, initializes, starts and stops the service, discovers routes and invalidates a route if it is broken.

Also, with event listener it maintains the service’s status.

In the same package com.sun.spot.peripheral.radio.mhrp.aodv there are Receiver and Sender classes.

The Receiver’s class main functionality is to handle the AODV messages (RREQ, RREP, RERR)

and process incoming data.

• void handleRERRMessage(RERR message, long lastHop)

Handler for route error messages, deactivates the broken route.

If necessary, the message is forwarded.

• void handleRREPMessage(RREP message, long lastHop)


Handler for route reply messages. A new route is added.

If necessary, the message is forwarded.

• void handleRREQMessage(RREQ message, long lastHop)

Handler for route request messages. Eventually new routes are added.

If necessary, message is forwarded, or a route reply is sent.

• void processIncomingData(byte[] payload, LowPanHeaderInfo headerInfo)

This method is called whenever the low pan layer receives a packet that carries this

routing manager's protocol number. It implements the protocol manager’s interface.

The Sender’s main functionalities are to forward AODV messages and send AODV messages:

• boolean forwardAODVMessage(AODVMessage message)

Put into the queue, a message that must be forwarded

• boolean sendNewRREP(RREP message)

Create an entry for the queue and put it in to the designated queue

• boolean sendNewRREQ(long address, RouteEventClient eventClient, Object uniqueKey)

Create an entry for the queue and put it in to the designated queue

The parameter address is the destination for which a route is wanted

The parameter eventClient is the instance that is waiting for this route

The parameter uniqueKey is the identifier for this RREQ

Returns success if everything was ok

• private void sendRERR(RERR message)

Send out a route error

• private void sendRREP(RREP message)

Send out a route reply

• private void sendRREQ(RREQ message, RouteEventClient eventClient,

Object uniqueKey) Send out a route request

AODVManager routing messages All the routing messages of the radiostack are located in the package com.sun.spot.peripheral.radio.mhrp.aodv.messages. The messages are the following:

• RREQ(long origAddress, long destinationMACaddress):

In this constructor, a new route request message is constructed consisting of the

originator address and the destination address.

• RREP(RREQ message):

In this constructor, a new route reply is created by taking as a parameter the route reply

message that has been received.

• RERR(long originator, long destination):

A route error is created when a broken link is detected

These are the messages which are used. Additionally, there is a class named AODVMessage.java which is extended by all the message classes RREQ.java, RREP.java and RERR.java. From this

class, information can be taken about the type of a message, its sequence number and originator

and destination addresses.

AODV.REQUEST

In the next package called com.sun.spot.peripheral.radio.mhrp.aodv.request the following classes

are included:

• RequestEntry

It compares two request entries

• RequestTable

� RequestTable()

Constructs a new request table


� boolean addRREQ(RREQ message, RouteEventClient eventClient,

Object uniqueKey)

Add a route request to the request table

The parameter message is the RREQ that should be added

The parameter eventClient is the instance that caused this route request

The parameter uniqueKey is the identifier for this RREQ

It returns true when ready

• RequestTableCleaner

In this class a thread is created which is responsible for calling the clean table method()

of the request table

AODVManager Routing table Routing table is handled in the package com.sun.spot.peripheral.radio.mhrp.aodv.routing. It

contains the following classes:

• RoutingEntry

It contains the entries of the routing table like sequenceNumber, nextHopMACAddress,

hopCount, routeCost. It contains the compare(Object object) method as well to compare

two routing entries and see if they have expired.

• RoutingNeighbor

Constructs a new routing table advertiser and periodically broadcasts a new route

advertisement (RREP) to keep our route active in neighbors.

• RoutingTable

For the creation of the routing table a sorted list is used along with a hash table. It

contains the following methods for controlling the routes:

� void addRoute(long address, long nextHopMACAddress, int hopCount, int routeCost, int destSeqNumber)

� Create a new route entry using the parameters, then call doTableAddition()

The parameter address is the destination address of route entry

The parameter nextHopMACAddress is the address of the next hop of this

address

The parameter hopCount is the number of hops to the destination

The parameter routeCost is the AODV route cost mechanism

The parameter destSeqNumber is the AODV sequence number

� void addRoute(long senderMACAddress, RREQ message)

Create a new route entry based on a received route request, then call

doTableAddition()

The parameter senderMACAddressis the MAC address of the requestor

The parameter message is the route request message received

� void addRoute(long senderMACAddress, RREP message) Create a new route entry based on a received route request, then call

doTableAddition()

The parameter senderMACAddress is the MAC address of the requestor

The parameter message is the route reply message received

� int getDestinationSequenceNumber(long address)

Get the destination sequence number for a certain entry

The parameter address is the address of the entry that we are interested in

Returns the destination sequence number

� long cleanTable()

Delete all table entries that have expired

� void doTableAddition(Long key, RoutingEntry newEntry)

This method checks if a new route is better than the one that already might exist

in the routing table. Only if this is the case the old one is replaced.


The parameter key is the destination address for which we have a new route

The parameter newEntry is a new entry in the routing table

� boolean freshenRoute(long address)

Increases the expiry time for a route that is specified by the destination

The parameter address is the destination address to be refreshed

Returns true when finished

� void deactivateRoute(long originator, long destination) Removes a node from the users list of a route and sets the activity flag to false

The parameter originator originator of the route request

The parameter destination is the destination address of route entry

� Vector getAllEntries()

This method provides access to the entire routing table. It can be used to monitor

the state of the routing table by an application.

� void dumpTable()

• RoutingTableCleaner

Responsible for constructing routing table cleaners and calling the appropriate method

for cleaning the table (routingTable.cleanTable())

3.2 LQRPManager

As AODVManager, LQRPManager is based in AODV with some additional functionality. It takes

into account node lifetime and link quality to route the packets. The whole packages and classes

structure is very similar with the AODVManager with some additional classes and methods:

• synchronized void initialize(long ourAddress, ILowPan lowPan) It initializes the service by starting the sender and receiver threads,

• RouteInfo getRouteInfo(long address)

Obtain route info and refreshen a route whenever it is used

• findRoute(long address, RouteEventClient eventClient, Object uniqueKey)

This method triggers a new route request.

• boolean invalidateRoute(long originator, long destination)

This method is called when it is recognized that the route is broken somewhere. The route

is marked deactivated and a RERR is being sent.

• void addEventListener(IMHEventListener listener)

Registers an application that is notified when this node processes supported route events

• void removeEventListener(IMHEventListener listener)

Deregisters an application

• int getNextSequenceNumber(int givenNumber)

This method creates new sequence numbers.

• int getCurrentSequenceNumber()

• RouteTable getRoutingTable()

This method returns a snapshot of the routing table

• boolean initiateRouteDiscovery(long address)

• int getStatus()

Return the current status of this service

The different methods in this class are the following

• void addLQRPListener(ILQRPEventListener listener)

Registers an application that is notified when this node processes supported route events

• void removeLQRPListener(ILQRPEventListener listener)

Deregisters an application

The Receiver class is similar with the AODVManager Receiver class apart from some additions


due to the LQRP module.

• void handleLQREPMessage(LQREP message, long lastHop)

Handler for link quality reply messages.

• void handleLQREQMessage(LQREQ message, long requestor)

Handler for link quality request messages.

The Sender class is similar with the AODVManager Sender class with the following additions as the most important ones:

• boolean forwardLQRPMessage(LQRPMessage message)

Put a message that must be forwarded into the queue

• void sendLQREP(LQREP message)

Send out a link quality reply

• void sendLQREQ(LQREQ message)

Send out a link quality request

The addition to this module appears in the package com.sun.spot.peripheral.radio.

mhrp.lqrp.linkParams in this routing manager. In this package there are four classes:

• ConfigLinkParams

It contains link parameters such as the time window for each transmission, the number of

timeslots, a weight parameter for the calculation of the cost, the max data rate and the

max battery voltage.

• NbrLinkInfo

This class contains information about how well our neighbors can hear our packets, how well we can hear our neighbor’s packets, when did we last hear from this neighbor, when

did we last send an LPREQ to this neighbor and when did we last receive an LPREP from

this neighbor. Also, it has methods to get information such as getCurrNormalizedLQ(), getNbrLastLQREQ().

• NodeLifeAndLinkMonitor

The most important methods it contains are the following:

� void notifyPacket(long srcAddress, long dest, int rssi, int corr, int lq, int packetSize)

Update LQI Sum for each packet received. Called by RadioPacketDispatcher

� NbrLinkInfo addLinkWithAddress(long address, double lq)

Add a new link for a neighbor with a given address

� void removeLinkWithAddress(long address)

Remove a link for a neighbor with a given address

� double getCurrNormLQForAddress(long address) Get the current normalized link quality for this specific address

� void setNbrLQ(long address, double cost)

To be called by Receiver upon receiving an LQREP packet

� void updateLinkInfo()

Function executed at the end of each slot duration expiry

• NodeLifetime

This class contains a very important part – the calculation of the cost of the route. The

formula used for this purpose is the following

currNormExpLifetime = remainingBattFrac * ( 1.0 – 1000 * burnRate /

( ConfigLinkParams.MAX_DATA_RATE * ENERGY_PER_BIT_RX ) )

The formula calculates the normalized current node lifetime. The burnRate is a number calculated from the transmitted energy for bytes added with the received energy for bytes

divided by the time window. remainingBattFrac is the remaining battery fraction

meaning remaining battery voltage divided by max battery voltage. MAX_DATA_RATE


is a constant for bits per second. ENERGY_PER_BIT_RX is another constant nJ value to

receive a bit.

The package com.sun.spot.peripheral.radio.mhrp.lqrp.messages contains the same messages with

AODVManager with two messages added. LQRPMessage is very similar to AODVMessage.

• LQREP

� LQREP(LQREQ request, double cost)

It constructs a new link quality reply message with parameters the link quality request

that caused this link quality reply and the average link quality cost for messages received on this link.

� LQREP(byte[] newMessage)

Constructs a new route request message � byte[] writeMessage()

Writes the properties into the appropriate bytes of the buffer

• LQREQ

� LQREQ(long origSourceAddress, long destinationMACaddress, double cost)

This constructor constructs a new link quality request message with parameters the originator source address, the destination’s MAC address and the cost.

� LQREQ(byte[] newMessage, int lqi)

Constructs a new route request message � byte[] writeMessage()

writes the properties into the appropriate bytes of the buffer

The other two packages com.sun.spot.peripheral.radio.mhrp.lqrp.request and com.sun.spot.peripheral.radio.mhrp.lqrp.routing are very similar to AODVManager’s.

4. Modified versions – the new protocols

4.1 Node Lifetime based protocol

This version of the protocol aims at taking into account only the battery level of the nodes to

route the packets. The battery level is given from each node in volts. The lowest value it can reach

is approximately 3200mV and the highest approximately 4200mV. Many classes have been left

unmodified and the rest have been modified to serve the needs of the new protocol. Consequently, the analysis of the classes for AODVManager and LQRPManager is valid because it analyses the

most important functionalities which are the same. The most important and worth mentioning

modification done in this version of the protocol is the line with the calculation of the cost which has been modified as follows

cost = linkM.getNodeLifetime().getNormNodeLifetime();

A variable is located in the updateRouteCostToDest(long nextHop) method of RREP and in the updateRouteCost(long lastHop) method of RREQ message. It has been modified the same way in

both messages. This is the method which updates the route cost of the message. The method

getNormNodeLifetime() is located in NodeLifetime class in LinkParams. This method returns the

variable currNormExpLifetime which uses the getVbatt(). The answer is given from the power controller which is responsible for measuring the voltage. In this case the answer is simply the

voltage of the battery and not the current normalized lifetime as before:

currNormExpLifetime = 1/Spot.getInstance().getPowerController().getVbatt();

The idea is to get only the battery level in order to route each packet to the neighbor with a

battery level which does not fall below a certain acceptable threshold. As a result, the node will

choose the right neighbor with enough battery. The goal of the protocol is to be able to achieve an even energy consumption among all the nodes.

The protocol chooses the link with the lowest cost. So, the use of 1/batteryLevel is to ensure that


if we get a high battery level (4100) and a low one (3800), the protocol does choose the better of

the two – 4100. So, in order to achieve this goal, the division has to happen to produce the right

decision: 1/4100<1/3800.

4.2 Link quality based protocol

The second version of the protocol is the link quality one. In this protocol the routing manager

uses the link quality to route the data. The same rule counts again about the classes’ analysis. The

general architecture of the package has been left unmodified so the analysis for AODVManager and LQRPManager is valid. Actually the following modification is the most important and worth

mentioning:

cost = 1/linkLQ ;

while linkLQ is calculated as

linkLQ = linkM.getCurrNormLQForAddress(nextHop);

LinkLQ means link’s link quality and it is the current normalized link quality of a specific address

(a node) with the next hop of the route. For the link quality calculations the parameter that is used is the Link Quality Indicator (LQI). Again, apart from some other modifications, the most

important modification is the actual functionality of the protocol which is determined by the cost.

The cost is calculated through 1/linkLQ to ensure the selection of the lowest cost as explained before.

The goal of this protocol is to be able to determine which node has acceptable link quality among

the possible links. There are many scenarios which can take place in a large network. Without the

link quality based protocol the node randomly sends the packet to a neighboring node. It may seem that they can communicate but if the link quality is not good enough the packet may be lost

or following packets may be lost. If the packets are routed with the link quality based protocol,

they are routed more “safely” that means with more reliability. If there link quality is below threshold, the node looks for another neighbor with which it can have a link with acceptable link

quality for a reliable communication.

5. Experiments – Results

Apart from the implementation analysis, many experiments have taken place to show the results

of each protocol. It is very important to see how the protocol behaves in short or long distances or

with different topology as the time passes by. That way, by studying the results, one can observe how the routing works and how fast the battery is depleted according to the environment and

conditions. Indoor and outdoor experiments have taken place to study how the Sun SPOTs and

the protocols behave in such different conditions. Indoors, different kinds of interference exist due to lamps or heaters for example – the heat causes a lot of interference if the heating source is

close to the antenna – other wireless devices which may work in the same frequency band, or

reflections from the walls. This is the reason why the outdoor experiments are needed to support a

more real life approach of the mesh network.

5.1 Indoor experiments

The indoor experiments took place in the lab using almost all the times the same or very similar

topologies specially suited to compare the protocols to each other. The idea behind the topology is to have enough nodes specifically placed in order to offer the opportunity to the routing protocol

to decide a route among several routes. More specifically, as mentioned above, 02E6 is sending

data to 3230. The data being transmitted was one packet per 200msec meaning 5 packets/sec. The

meaning behind this is that 02E6 has several routes to choose to reach 3230. Of course it is the routing protocol that decides, not 02E6. The experiment was planned to offer three different


routes as it seems from the first look at the topology. This was the plan because a neighboring

SPOT which is on the same line (1379-1893) is closer than a neighboring node that is on the

diagonal (1379-3A1B). Therefore, it is a test of which routes will the protocol choose since this

fact is true. But, it can happen for example in AODV, as it seems from the following results, the routes to be so confusing that instead of taking for example 2274-242B-3230 which is two hops,

it takes 2274-3A1B-1379-3230 which is three hops away.

In the following presentations of the experiments, in the beginning there is the introduction to

each experiment with some details and after that there are the routing tables of each node which participated in the experiment along with explanations of the table. These routing tables are

specific ones specially chosen to show key moments during the experiment that a very important

change has happened or a strange behaviour of the protocol took place. They are definitely worth taking a look in order to understand how the protocol behaves during a whole experiment; the

changes of the routes, the depletion of the battery, possible end of functionality due to an error.

5.1.1 AODVManager

5.1.1.1 Introduction to the experiment

The node 02E6 was sending packets to the base station 3230. A lot of data was gathered as the

experiment was running for about six hours. Even if the software used was implemented so 02E6

to send packets to 3230, the intermediate nodes have their own routing tables about how to reach each node. The distances involved were 8 cm between SPOTs that are on the same line (i.e. 1379-

1893) and more for diagonally connected (i.e. 3A1B-1379).

All the nodes seem to have a very bad routing behavior. Most of the times – almost all – when

there is multihop routing, the route is longer or even much longer than the one expected (the shortest path). Nodes seem to skip even three intermediate nodes to reach the destination without

a specific reason. At some point everything seems almost completely random. Analysis of each

node’s behavior follows. The topology of this experiment is shown in Fig. 5.1 and Fig. 5.2 shows a photo of the topology of the experiment.

Fig. 5.1: Topology for indoor AODVManager experiment


Fig. 5.2: Photo of the indoor AODV experiment

5.1.1.2 Routing – routing tables

242B Battery Level: 34 Time: 2009-5-15 15:28:11 Voltage: 3907 of

0014.4F01.0000.242B LQI: 242 Seq Nber: 11

Destination Next Hop Hops

0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.3A1B 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Destination 3230: 1 hop Destination 2274: To reach 2274 one would expect for it to do it directly since it is a neighboring

node topologically. But in the beginning 242B reaches 2274 through 3A1B.

Destination 3A1B: Directly. It skips 2274. Destination 22A5: Directly.

There is no route yet for 1379, 1893, 02E6

Battery Level: 34 Time: 2009-5-15 15:28:12 Voltage: 3902 of

0014.4F01.0000.242B LQI: 238

Seq Nber: 13


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.3A1B 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1


0014.4F01.0000.242B LQI: 242

Seq Nber: 15

Destination Next Hop

Hops

0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.3A1B 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1


0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Route to 1379 has been found


0014.4F01.0000.242B LQI: 238

Seq Nber: 25


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.3A1B 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

After several transmissions 242B found a route to 02E6 just one hop away despite the two

intermediate nodes.


0014.4F01.0000.242B LQI: 242

Seq Nber: 85


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Here the routes to 2274 and 1379 are lost


0014.4F01.0000.242B LQI: 221

Seq Nber: 15773


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.3A1B 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.22A5 2

The route to 2274 is found again with 3A1B as next hop. The protocol uses the same route which is clearly not the best choice.


0014.4F01.0000.242B LQI: 212

Seq Nber: 20468


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.3A1B 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.22A5 2

Route to 24AB is found through 22A5 which seems as the right choice. The routes remain the same; the only changes are activations and deactivations of some routes.

Some routes may disappear for some time and appear again, something that does not make sense.


3A1B Battery Level: 11 Time: 2009-5-15 15:28:7 Voltage: 4181 of

0014.4F01.0000.3A1B LQI: 182

Seq Nber: 14


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

The first routing table of 3A1B shows that route has been found for almost all the nodes apart

from 1379. However, all routes have one hop even if they are far - for example 242B. The route

with destination the base station 3230 is through 02E6 which is clearly not a good route decision.


0014.4F01.0000.3A1B LQI: 191

Seq Nber: 40


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

In this datagram the node shows that now it has routes to all the nodes. Everything else remains

the same.


0014.4F01.0000.3A1B LQI: 153

Seq Nber: 71


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Three routes have been lost.


0014.4F01.0000.3A1B LQI: 153

Seq Nber: 197


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.242B 2


The route to 22A5 has changed to two hops through 242B, again a “weird” route decision.


0014.4F01.0000.3A1B LQI: 212

Seq Nber: 1317


0014.4F01.0000.3230 0014.4F01.0000.242B 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

Losing more routes. Route to 3230 has been changed by using 242B as the next hop. A better choice.

22A5 Battery Level: 2 Time: 2009-5-15 15:28:15 Voltage: 3877 of

0014.4F01.0000.22A5 LQI: 174

Seq Nber: 14


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.24AB 2

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

22A5 uses 02E6 to reach the base station, the last node to reach the first. It prefers to go to 1893

through 02E6.


0014.4F01.0000.22A5 LQI: 221

Seq Nber: 38206


0014.4F01.0000.3230 0014.4F01.0000.242B 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

In this routing table 22A5 has 242B as a next hop in all its routes. Even to 24AB which would be

much more convenient to be reached directly. Some routes have been lost.


0014.4F01.0000.02E6 LQI: 153

Seq Nber: 9


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.242B 0014.4F01.0000.3A1B 2

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1


0014.4F01.0000.02E6 LQI: 127

Seq Nber: 184


0014.4F01.0000.3230 0014.4F01.0000.3230 1


0014.4F01.0000.2274 0014.4F01.0000.24AB 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Routes to all nodes have been established now. A strange route appears to 2274 through 24AB.

For some reason 02E6 disappeared quickly from the network despite the fact that the battery was high.

1893 Battery Level: 18 Time: 2009-5-15 15:28:7 Voltage: 3877 of

0014.4F01.0000.1893 LQI: 165

Seq Nber: 8


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Very wrong routing decision to reach 3230 through 02E6. This node was disappeared from the

network very quickly and unexpectedly.

24AB Battery Level: 50 Time: 2009-5-15 15:28:8 Voltage: 4087 of

0014.4F01.0000.24AB LQI: 165

Seq Nber: 8


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.242B 0014.4F01.0000.22A5 2

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

The node reaches the base station through 02E6 and skips three intermediate nodes (242B, 1379,

22A5). Another wrong route is the communication with 1893 through 02E6.


0014.4F01.0000.24AB LQI: 221

Seq Nber: 19720


0014.4F01.0000.3230 0014.4F01.0000.22A5 3

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Route to 3230 changed to three hops through 22A5. Some routes have been lost.

2274



0014.4F01.0000.2274 LQI: 170

Seq Nber: 3


0014.4F01.0000.3230 0014.4F01.0000.3A1B 3

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.242B 0014.4F01.0000.3A1B 2

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

The node reaches 3230 through 3A1B which about that time reaches 3230 through 02E6. It seems

as the route chosen is not the right one going all the way around the network. The two hop routes are wrong routes as well.


0014.4F01.0000.2274 LQI: 221

Seq Nber: 23277


0014.4F01.0000.3230 0014.4F01.0000.3A1B 3

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Usual behavior as with the other nodes – loses some routes and maintains the same hops in the ones which remain on the table.


0014.4F01.0000.1379 LQI: 191

Seq Nber: 219


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

1379 from the beginning found routes to all nodes of the network. It is reasonable from the point

of view that it is in the middle of the network. Very strange route to 3230 through 02E6. All the rest are direct routes.

02E6 Battery Level: 42 Time: 2009-5-15 15:28:32 Voltage: 4156 of

0014.4F01.0000.02E6 LQI: 157

Seq Nber: 41


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.24AB 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1


0014.4F01.0000.242B 0014.4F01.0000.3A1B 2

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

02E6 reaches directly the base station despite the fact that 3230 has four intermediate nodes along

the way. For 2274 which is much closer it chooses two hops through 24AB.


0014.4F01.0000.02E6 LQI: 140

Seq Nber: 916


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.24AB 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

The node finds finally a direct route to 242B. One route lost. 02E6 disappeared from the network

relatively soon.

5.1.1.3 AODV Indoors Graphs

In Fig. 5.3 there are the graphs of the experiment.


Fig 5.3: AODV protocol indoors – packets received/mVolts

5.1.2 LQRP

5.1.2.1 LQRP indoors introduction This is the default routing manager in the first beta release of the red SDK - LQRPManager. It is a

different routing manager from the old one – AODVManager. The new routing manager takes

into account link quality and battery level to route the packets. Since link quality cannot change so much, the battery level plays more important role during the

experiment since this is what changes significantly over time.

Generally, this protocol seems much better than its predecessor. It quickly selects a route in the beginning and after some time it tries to find the best one for each destination and most of the

times it manages to do that. However, from this experiment one can see that many nodes lose

routes for a long time or even lose some routes permanently. The protocol seems able to handle the broken links in an acceptable manner since it can find routes with even four hops in this

experiment if some of the intermediate nodes have run out of battery.

This experiment used the same topology and configuration with AODV experiment.

5.1.2.2 LQRP Indoors Routing


0014.4F01.0000.22A5 LQI: 204

Seq Nber: 167


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1


0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.1379 0014.4F01.0000.02E6 3

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

The node discovers routes to all nodes of the network from the beginning. It reaches 2274, 3A1B,

1893 and 1379 via 02E6. 1379 is reached through three hops even though it is an adjacent node.


0014.4F01.0000.22A5 LQI: 212

Seq Nber: 160


0014.4F01.0000.3230 0014.4F01.0000.242B 2

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.1379 0014.4F01.0000.24AB 2

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

The route to 3230 has been changed to two hops via 242B which seems as a proper routing

decision since it is the intermediate node between 22A5 and 3230 and it is supposed to offer

better link quality. The route to 1379 has been changed via 24AB, a better route since it is closer and fewer hops

than the previous choice.


0014.4F01.0000.22A5 LQI: 229

Seq Nber: 7109


0014.4F01.0000.3230 0014.4F01.0000.242B 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Some routes have been lost.


0014.4F01.0000.22A5 LQI: 225

Seq Nber: 22792


0014.4F01.0000.3230 0014.4F01.0000.1893 2

0014.4F01.0000.2274 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Many differences in this datagram. The route to 3230 has been changed via 1893.The same with

the route to 2274. The rest seem pretty acceptable decisions. The negative thing is that there is no


route to 1379 at that moment.


0014.4F01.0000.22A5 LQI: 229

Seq Nber: 30710


0014.4F01.0000.3230 0014.4F01.0000.242B 2

0014.4F01.0000.2274 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.1893 3

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

The route to 3A1B has been changed to three hops via 1893 this time. Still there is no route to 1379.


0014.4F01.0000.2274 LQI: 178

Seq Nber: 177


0014.4F01.0000.3230 0014.4F01.0000.02E6 3

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.02E6 2

0014.4F01.0000.1379 0014.4F01.0000.02E6 3

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.22A5 0014.4F01.0000.02E6 2

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2

The node in the beginning reaches almost every node via 02E6, the base station through three

hops.


0014.4F01.0000.2274 LQI: 229

Seq Nber: 3861


0014.4F01.0000.3230 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.1893 3

0014.4F01.0000.22A5 0014.4F01.0000.1379 3

The route to 3230 has been changed via 1893, a better decision than the previous one. Since the

decision is not good enough though. Strange and not reasonable decision of going to 22A5 via 1379 through three hops. It is reasonable for this protocol though to choose 1379 and 1893 since

they supposedly have better link quality.



0014.4F01.0000.2274 LQI: 225

Seq Nber: 22334


0014.4F01.0000.3230 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.1893 2

0014.4F01.0000.24AB 0014.4F01.0000.1893 3

The routes seem better now. However, some routes have been lost.


0014.4F01.0000.2274 LQI: 106

Seq Nber: 30925


0014.4F01.0000.3230 0014.4F01.0000.3A1B 3

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

This datagram has been sent when the experiment was reaching the end due to battery depletions.

Since 1893’s battery has been depleted, the protocol chooses other nodes which have enough battery.


0014.4F01.0000.242B LQI: 204

Seq Nber: 138


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.1379 0014.4F01.0000.02E6 3

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

The protocol chooses again 02E6 as the next hop for almost all nodes.


0014.4F01.0000.242B LQI: 204

Seq Nber: 18689


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.1893 3

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.22A5 2

A lot of routes have been changed. Strange routing decision to reach 3A1B via 1893 through three


hops. Everything else seems acceptable and reasonable.


0014.4F01.0000.242B LQI: 199

Seq Nber: 46610


0014.4F01.0000.3230 0014.4F01.0000.3230 1

Towards the end of the experiment.


0014.4F01.0000.02E6 LQI: 161

Seq Nber: 172


0014.4F01.0000.3230 0014.4F01.0000.242B 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1379 0014.4F01.0000.24AB 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

02E6 seems able to reach almost all nodes directly. It uses 242B to reach the base station and

24AB to reach 1379. For 242B which is further than 1379 only one hop is needed.


0014.4F01.0000.02E6 LQI: 178

Seq Nber: 9529


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.24AB 2

02E6 can reach 3230 directly even though there are three intermediate nodes.


0014.4F01.0000.02E6 LQI: 123

Seq Nber: 30441


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1


Route to 2274 is changed via 1893 to two hops.


0014.4F01.0000.3A1B LQI: 225

Seq Nber: 132


0014.4F01.0000.3230 0014.4F01.0000.02E6 3

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1379 0014.4F01.0000.02E6 3

0014.4F01.0000.242B 0014.4F01.0000.02E6 2

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.22A5 0014.4F01.0000.02E6 2

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2

A strange route is to 1379 through three hops but it is only the first datagram. 02E6 is the next

hop decision for most of the routes again.


0014.4F01.0000.3A1B LQI: 204

Seq Nber: 6024


0014.4F01.0000.3230 0014.4F01.0000.2274 3

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2

The node lost some routes. The remaining routes seem good choices from the protocol which

seems to scale well after some time.


0014.4F01.0000.3A1B LQI: 199

Seq Nber: 25151


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2

0014.4F01.0000.22A5 0014.4F01.0000.02E6 2

The routes have been changed again. 3A1B goes to 3230 via 02E6 which currently has higher

battery than 2274 which was skipped. At that point 1893 has very low battery and this is probably the reason why the protocol chooses 02E6 to route the packets to the other side of the network –

22A5, 24AB


0014.4F01.0000.3A1B LQI: 187

Seq Nber: 33167



0014.4F01.0000.3230 0014.4F01.0000.2274 3

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.22A5 0014.4F01.0000.1893 3

Here, towards the end of the experiment many nodes have almost depleted their batteries. It chooses again 2274 probably because at that time it has higher battery voltage which plays an

important role.


0014.4F01.0000.24AB LQI: 212

Seq Nber: 0


24AB is very slow in finding routes to the rest of the nodes. It has already sent the first datagram

which actually had no routes.


0014.4F01.0000.24AB LQI: 221

Seq Nber: 2


0014.4F01.0000.3230 0014.4F01.0000.02E6 3

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

22AB finds a route to the base station via 02E6 through three hops. It would be better to reach the base station through 22A5 though because it has higher battery at the moment and higher link

quality.


0014.4F01.0000.24AB LQI: 204

Seq Nber: 14411


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

22AB continues to have few routes to the other nodes of the network.


0014.4F01.0000.24AB LQI: 119

Seq Nber: 15816


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 4

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

A serious change that happens is the four hops used to reach 3A1B which happens due to the

depletion of the batteries of the nodes. The protocol manages to find a route which is not a good


one but still it succeeded in finding one.


0014.4F01.0000.1379 LQI: 174

Seq Nber: 2


0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

In the beginning of the protocol execution, 1379 finds a route to only one adjacent node, 24AB.


0014.4F01.0000.1379 LQI: 208

Seq Nber: 27


0014.4F01.0000.3230 0014.4F01.0000.24AB 3

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Here 1379 finds a route to 3230 via 24AB


0014.4F01.0000.1379 LQI: 165

Seq Nber: 70


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

1379 finds routes to all the possible destinations with just one hop.


0014.4F01.0000.1379 LQI: 212

Seq Nber: 702


0014.4F01.0000.3230 0014.4F01.0000.1893 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2


This was the last packet sent from 1379. It disappeared from the network after this one.


0014.4F01.0000.1893 LQI: 187

Seq Nber: 7


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

1893 finds routes to all nodes from the beginning of the protocol execution. The two hop routes

are not good routing decisions. They will probably be improved afterwards.


0014.4F01.0000.1893 LQI: 208

Seq Nber: 4614


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.2274 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2

Interesting fact in this packet is that it skips two nodes to reach 3230. The rest of the route choices seem good.

5.1.2.3 LQRP Indoors Graphs The graphs of the protocol are shown in Fig. 5.4


Fig. 5.4: LQRP protocol indoors – packets received/mVolts

5.1.3 Node Lifetime based protocol

This protocol is a modified version of the LQRP module. For routing it takes into account the battery level in volts as it is given from the SPOTs.

5.1.3.1 Node Lifetime Indoors Routing


0014.4F01.0000.242B LQI: 242


Seq Nber: 719


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.1893 3

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.1893 2

Strange route to 3A1B through three hops. Everything else seems reasonable.


0014.4F01.0000.242B LQI: 242

Seq Nber: 1658


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.1379 2

0014.4F01.0000.3A1B 0014.4F01.0000.1379 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.22A5 2

Voltage: 4151 of 0014.4F01.0000.1379 LQI: 233 Voltage: 4022 of 0014.4F01.0000.1893 LQI: 238

Here it seems that 242B has chosen 1379 as the next hop in two routes due to the voltage

difference.


0014.4F01.0000.22A5 LQI: 242

Seq Nber: 321


0014.4F01.0000.2274 0014.4F01.0000.1379 2

0014.4F01.0000.3A1B 0014.4F01.0000.1893 3

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Strange route to 3A1B through three hops.


0014.4F01.0000.22A5 LQI: 246

Seq Nber: 774


0014.4F01.0000.3230 0014.4F01.0000.1893 2

0014.4F01.0000.2274 0014.4F01.0000.1379 2

0014.4F01.0000.3A1B 0014.4F01.0000.1379 2


0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Voltage: 4007 of 0014.4F01.0000.1893

Voltage: 4156 of 0014.4F01.0000.1379

Voltage: 4091 of 0014.4F01.0000.242B The protocol assigns 1893 as the next hop in the route to 3230 which has higher battery level than

242B that could be chosen for this but it has lower battery level than 1379 which is along the

route as well.


0014.4F01.0000.22A5 LQI: 238

Seq Nber: 4952


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Towards the end of the experiment the protocol manages to maintain the traffic in the network

even though some links are broken.


0014.4F01.0000.1379 LQI: 136

Seq Nber: 415


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1893 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

1379 can reach almost every node directly. Strange decision to reach 1893 via 02E6. The node’s routing table had no serious changes afterwards.


0014.4F01.0000.2274 LQI: 89

Seq Nber: 878


0014.4F01.0000.3230 0014.4F01.0000.1379 2

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.1893 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1


0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.1893 2

0014.4F01.0000.24AB 0014.4F01.0000.1893 2


0014.4F01.0000.2274 LQI: 246

Seq Nber: 1243


0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.1893 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.22A5 0014.4F01.0000.1379 2

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2


0014.4F01.0000.24AB LQI: 229

Seq Nber: 286


0014.4F01.0000.2274 0014.4F01.0000.1893 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.1893 2

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1


0014.4F01.0000.24AB LQI: 242

Seq Nber: 793


0014.4F01.0000.3230 0014.4F01.0000.22A5 3

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.1893 2

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1


0014.4F01.0000.1893 LQI: 238

Seq Nber: 46


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.2274 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1


0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1


0014.4F01.0000.1893 LQI: 238

Seq Nber: 1005


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

This was the node’s last packet. After that it disappeared from the network due to some kind of

device failure. The reason was clearly not the battery since it is very high in volts = 4022. This

kind of failures can easily happen to Sun SPOTs due to a software failure (a bug which appears

under some circumstances) or due to a hardware failure (hardware temporary malfunction).


0014.4F01.0000.3A1B LQI: 153

Seq Nber: 408


0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.02E6 3

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.24AB 0014.4F01.0000.02E6 2

0014.4F01.0000.22A5 0014.4F01.0000.02E6 3


0014.4F01.0000.3A1B LQI: 242

Seq Nber: 3111


0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

After a lot of time it has lost some routes.


0014.4F01.0000.02E6 LQI: 242

Seq Nber: 489


0014.4F01.0000.2274 0014.4F01.0000.2274 1


0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.1893 2

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.1893 2

02E6 does not have a route to the base station 3230.


0014.4F01.0000.02E6 LQI: 238

Seq Nber: 1414


0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.1379 2

5.1.3.2 Node Lifetime Indoors Graphs

In Fig. 5.5 there are the graphs of the results of the experiment.


Fig. 5.5 Node Lifetime Indoors- packets/mVolts

5.1.4 Link Quality based routing protocol

5.1.4.1 Introduction

This protocol takes into account the quality of a link to route packets. A normalized value of the link quality is used for the routing decision.

In this experiment another node was added in the mesh network, 12D4.The new topology is

shown in Fig.5.6. The extra node was added to monitor the network and receive some additional

data. Mesh routing was supposed to be disabled but somehow it was used as a mesh router so it was forwarding packets and it appeared in the routing tables of the nodes. As a result it couldn’t

be ignored and anyway it is interesting to see what happens with one additional node. A very

important fact to be mentioned is that 12D4 is not running the application used in the rest of the nodes so it is simply used as a mesh router, it is not sending packets to the base station.


Fig. 5.6: Current Topology with extra node 12D4

5.1.4.2 Link Quality Routing


0014.4F01.0000.242B LQI: 195

Seq Nber: 16


0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.1379 4

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.22A5 0014.4F01.0000.2274 3

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Four hops route to 3A1B is not a good routing decision.


0014.4F01.0000.242B LQI: 208

Seq Nber: 4875


0014.4F01.0000.3230 0014.4F01.0000.24AB 3

0014.4F01.0000.2274 0014.4F01.0000.24AB 2

0014.4F01.0000.3A1B 0014.4F01.0000.12D4 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

242B has found a route to the base station, not a good one though.


0014.4F01.0000.22A5 LQI: 195


Seq Nber: 25


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.1893 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1


0014.4F01.0000.22A5 LQI: 165

Seq Nber: 16033


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.12D4 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.24AB 0014.4F01.0000.12D4 2

The nodes which are in the middle of the network – 1379, 1893 and especially the new one, 12D4

have stronger transceiver which means better link quality. A lot of traffic passes through these nodes. This table remains as it is until the end of the experiment.


0014.4F01.0000.1379 LQI: 233

Seq Nber: 30


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.24AB 3

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

Strange route to 3A1B with three hops.


0014.4F01.0000.1379 LQI: 182

Seq Nber: 2263


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.12D4 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1


Route to 2274 has been lost. The route to 3A1B has been changed with 12D4 as next hop because the 12D4-1379 (closer and 12D4 better transceiver) link is better than 24AB-1379.

12D4

12D4 does not run the same application as the other nodes. This fact means that it does not send

data to the base station. So, it does not send its routing table or other kind of information.

However it forwards data so it appears in the routing tables of other nodes.


0014.4F01.0000.2274 LQI: 182

Seq Nber: 2


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.242B 0014.4F01.0000.24AB 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1


0014.4F01.0000.2274 LQI: 187

Seq Nber: 21573


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

2274 has routes to only five of the nodes but it has found a better route to 3A1B, the direct one.


0014.4F01.0000.24AB LQI: 174

Seq Nber: 2


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.1893 2

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

This routing table remained the same until the end of the experiment.


0014.4F01.0000.1893 LQI: 233

Seq Nber: 29


0014.4F01.0000.3230 0014.4F01.0000.3230 1


0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

1893 disappeared from the network very early.


0014.4F01.0000.3A1B LQI: 170

Seq Nber: 19


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1893 0014.4F01.0000.1893 1

0014.4F01.0000.1379 0014.4F01.0000.1379 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.24AB 0014.4F01.0000.242B 2

0014.4F01.0000.22A5 0014.4F01.0000.1379 3

Strange route appears with destination the base station via 02E6. 02E6 seems able to reach 3230

directly and the link between 02E6 and 3A1B seems to be a good link quality link.


0014.4F01.0000.3A1B LQI: 174

Seq Nber: 19103


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.242B 0014.4F01.0000.12D4 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.24AB 0014.4F01.0000.2274 2

The route to 242B has been changed having 12D4 now as next hop instead of direct communication. The route to 24AB has been changed by using as a next hop 2274 instead of

242B which makes sense as a better link – it is an adjacent link.


0014.4F01.0000.02E6 LQI: 187

Seq Nber: 17


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.22A5 2

0014.4F01.0000.1893 0014.4F01.0000.1893 1


0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1


0014.4F01.0000.02E6 LQI: 182

Seq Nber: 30201


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

No interesting routing in these routing tables, direct communication between the nodes.

5.1.4.3 Link Quality Graphs

The graphs of the experiment can be seen in Fig. 5.7


Fig. 5.7: Link Quality based protocol Indoors. Packets received/Battery Level(mVolts)

5.2 Outdoor experiments

The outdoor experiments took place on the roof of the “Forum” building of KTH in Kista. The

roof is very convenient for these outdoor experiments. The shape of the roof along with the

ventilation benches offers excellent conditions for an experiment. The shape offers the opportunity to evenly scatter the nodes across the network and the benches offer a good spot to

place the nodes in order to be higher from the ground and avoid its interference.

The drawback of the roof is that it may sometimes have a lot of interference because the area

around the place is full of antennas which probably work in the unlicensed frequency band like Sun SPOTs. As far as interference is concerned, there were some serious problems in the

beginning of the attempts to realize the experiments. It was difficult at the time to keep the SPOTs

high so they could communicate only if they were very close (2-3 meters) when placed on the ground. The main reason and the main problem was the base station which had to be close to the

window of the highest floor (on the edge of the roof) and there was no way to be placed high

enough. The base station had to be connected to a computer to run the host application and the computer had to be kept inside a room and run the experiment until all the SPOTs run out of

battery; this time usually is around six to seven hours with the appropriate configuration.

However, the experiments kept failing. The edge of the roof where the base station was placed in

the beginning along with the bench that was placed afterwards can be seen in Fig. 5.8. So, another solution had to be found and this solution was to run the experiment for much less

time in order to have to opportunity to move with the laptop and find a proper position for the

base station. The possible experiment time could be as long as the laptop’s battery can last. The idea was to hang the base station as high as possible from the ground and the solution was offered

by a stick which was placed in one of the benches as shown in Fig 5.9.


Fig. 5.8: Red: first failed outdoor experiment attempt. Green: second attempt and successful1

1 Image taken from Bing Maps


Fig 5.9: Laptop and base station taped high enough on a stick

With the new position of the base station, the communication was much better and finally it was the time for the experiment. To ensure as good communication as possible, there was a concept of

positioning all the nodes as far off the ground as possible. So some SPOTs were hanging from

somewhere like shown in Fig 5.10 or were taped somewhere high from a stick like the base

station. The topology used outdoors is very similar in all three experiments. The topology can be seen

from the first experiment in Fig. 5.11. The concept was to scatter the nodes around the whole area

as much as possible but at the same time, of course, be able to communicate. Additionally, there was an attempt to use as much multi hop communication as possible. This could be achieved by

using many nodes and long distances, something that was possible on the roof. From the topology

map one can see that the nodes are very scattered and they are somehow evenly scattered except the right side of the area. This happened because, as it can be seen from the figure as well, there

were not enough proper positions for the nodes on that side. There were not enough appropriate

benches in order to hang the nodes from somewhere. However, the experiment does not lose its

usefulness; this topology is very interesting and effective anyway. In all the outdoor experiments all the nodes send 1 packet per 200msec to the base station. The

exact topology and configuration for every experiment can be seen in the following chapters.


Fig. 5.10: SPOT inside its case hanging

5.2.1 LQRPManager


In this experiment the LQRPManager was used. The topology which was decided is the one

shown in Fig. 5.11.


Fig. 5.11: LQRPManager outdoor experiment2

5.2.1.2 LQRPManager Routing

Some routing tables from each SPOT are presented below to show important points of the

experiment.


0014.4F01.0000.02E6 LQI: 229

Seq Nber: 6


0014.4F01.0000.2274 0014.4F01.0000.07F9 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.12D4 0014.4F01.0000.07F9 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.07F9 3

02E6 finds quickly routes to all the SPOTs except the base station. A strange route appears to

3A1B through 1539. In many routes the next hop is the same SPOT 07F9. Battery Level: 31 Time: 2009-9-4 5:41:5 Voltage: 3987 of

0014.4F01.0000.02E6 LQI: 238

Seq Nber: 1401


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.2274 0014.4F01.0000.1539 3

0014.4F01.0000.3A1B 0014.4F01.0000.1539 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.12D4 0014.4F01.0000.1539 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.1539 3

After a while 02E6 finds a route to all SPOTs and to the base station. 1539 has taken over in most

routes as the next hop. For example in the route 02E6 to 3A1B, the next hop in 1539 and the route

has 3 hops; a routing decision which shows that the protocol considers this route better than the direct one. This could happen due to a higher level, due to better LQI value or both.


0014.4F01.0000.3A1B LQI: 221

Seq Nber: 45


0014.4F01.0000.3230 0014.4F01.0000.1539 2

0014.4F01.0000.2274 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.12D4 2

0014.4F01.0000.242B 0014.4F01.0000.1539 3

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

3A1B finds routes to 6 SPOTs including the base station after a significant amount of time from

2 Image taken from Google Earth


the beginning of the experiment and after a lot of lost packets. This is obvious from the Seq Nber

which starts with 45 - this is the first packet received from the base station and sent from 3A1B.

3A1B reaches 242B which is a neighboring node with next hop 1539 which is on the other side of

the area and far away. It reaches 12D4 directly despite the fact that it is 3 hops away. Battery Level: 2 Time: 2009-9-4 5:54:21 Voltage: 4121 of

0014.4F01.0000.3A1B LQI: 242

Seq Nber: 1087


0014.4F01.0000.2274 0014.4F01.0000.07F9 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 3

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.07F9 2

0014.4F01.0000.22A5 0014.4F01.0000.07F9 3

0014.4F01.0000.1539 0014.4F01.0000.07F9 3

3A1B has never found routes to all SPOTs. Here it seems that it has even lost the route to 3230,

the base station. The protocol seems to consider as a good link 3A1B-07F9 or considers that 07F9 has batter node lifetime because 07F9 is used a lot as the next hop of 3A1B.


0014.4F01.0000.242B LQI: 233

Seq Nber: 16


0014.4F01.0000.3230 0014.4F01.0000.07F9 3

0014.4F01.0000.2274 0014.4F01.0000.07F9 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

242B completes its routing table with routes to all SPOTs and base station fairly quickly. It can

reach 3A1B, 07F9, 02E6, 12D4 and 1539 directly and 3230 through 3 hops. The routes seem

reasonable.


0014.4F01.0000.242B LQI: 233

Seq Nber: 2000


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.02E6 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.02E6 3

0014.4F01.0000.22A5 0014.4F01.0000.02E6 4

The node has only lost a route to 1539. After many packets (Seq Num 16 to 2000 now) the

routing table has been changed significantly. In all routes except one, the protocol uses 02E6 as

242B’s next hop which means that at this moment it considers this cost the lower from the


possible ones. Only 07F9 is reached directly – it is an adjacent node anyway. An interesting route

is the one to 22A5 which takes place through 4 nodes via 02E6 as next hop again.

07F9 Battery Level: -13 Time: 2009-9-4 4:51:6 Voltage: 4037 of

0014.4F01.0000.07F9 LQI: 238

Seq Nber: 20


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.242B 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

From the beginning it finds routes to all SPOTs as the previous nodes. The node reaches directly

the distant node 2274.

Battery Level: -13 Time: 2009-9-4 5:41:35 Voltage: 3907 of

0014.4F01.0000.07F9 LQI: 242

Seq Nber: 2230


0014.4F01.0000.3230 0014.4F01.0000.12D4 4

0014.4F01.0000.2274 0014.4F01.0000.2274 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.1539 3

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

The node keeps reaching 2274 directly. It reaches the BS through 4 hops which is reasonable because they are fairly far away.

12D4 Battery Level: 92 Time: 2009-9-4 4:51:17 Voltage: 4017 of

0014.4F01.0000.12D4 LQI: 233

Seq Nber: 32


0014.4F01.0000.2274 0014.4F01.0000.07F9 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.07F9 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Not something unusual appears in this routing table.


0014.4F01.0000.12D4 LQI: 238

Seq Nber: 2570



0014.4F01.0000.3230 0014.4F01.0000.1539 3

0014.4F01.0000.2274 0014.4F01.0000.07F9 2

0014.4F01.0000.3A1B 0014.4F01.0000.07F9 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.1539 3

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

A rather interesting routing decision is that the node reaches 242B through 1539 which is from

the other side of the area through 3 hops.


0014.4F01.0000.22A5 LQI: 238

Seq Nber: 325


0014.4F01.0000.3230 0014.4F01.0000.12D4 4

0014.4F01.0000.2274 0014.4F01.0000.12D4 3

0014.4F01.0000.3A1B 0014.4F01.0000.12D4 3

0014.4F01.0000.07F9 0014.4F01.0000.12D4 2

0014.4F01.0000.242B 0014.4F01.0000.12D4 2

0014.4F01.0000.02E6 0014.4F01.0000.12D4 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

After quite many lost packets, the node reaches the base station and it shows that it has routes for

7 SPOTs. It needs 4 hops to reach 3230, a reasonable fact since it is far away. It is interesting to note that for all the routes the next hop is 12D4 which is very reasonable as well since it is by far

closer than the other neighbor 1539.


0014.4F01.0000.22A5 LQI: 238

Seq Nber: 2368


0014.4F01.0000.3230 0014.4F01.0000.12D4 4

0014.4F01.0000.2274 0014.4F01.0000.12D4 2

0014.4F01.0000.3A1B 0014.4F01.0000.12D4 3

0014.4F01.0000.07F9 0014.4F01.0000.12D4 2

0014.4F01.0000.242B 0014.4F01.0000.12D4 4

0014.4F01.0000.02E6 0014.4F01.0000.12D4 3

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

Some changes happen but nothing that may seem very unusual. The 2 hops to 242B became 4.

The protocol continues to use only 12D4 as next hop in all routes.


0014.4F01.0000.1539 LQI: 225

Seq Nber: 60


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.07F9 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1


0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

The node finds routes to all SPOTs with no more than 2 hops. It is able to reach directly nodes which are from the other side of the experiment area like 3A1B.


0014.4F01.0000.1539 LQI: 233

Seq Nber: 1994


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.2274 0014.4F01.0000.07F9 2

0014.4F01.0000.3A1B 0014.4F01.0000.07F9 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.02E6 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

Two unusual routes in this routing table are 1539-07F9-3A1B and 1539-12D4-22A5.


0014.4F01.0000.2274 LQI: 229

Seq Nber: 134


0014.4F01.0000.3230 0014.4F01.0000.07F9 4

0014.4F01.0000.3A1B 0014.4F01.0000.07F9 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 3

0014.4F01.0000.02E6 0014.4F01.0000.1539 2

0014.4F01.0000.22A5 0014.4F01.0000.07F9 3

0014.4F01.0000.1539 0014.4F01.0000.1539 1

2274 which is very close to BS reaches it through 4 hops. This seems as a very unusual routing

decision. Actually almost all the routes are very unusual in this routing table. Battery Level: 87 Time: 2009-9-4 5:37:36 Voltage: 4027 of

0014.4F01.0000.2274 LQI: 174

Seq Nber: 269


0014.4F01.0000.3230 0014.4F01.0000.07F9 5

0014.4F01.0000.3A1B 0014.4F01.0000.07F9 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.07F9 3

0014.4F01.0000.242B 0014.4F01.0000.07F9 4

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

2274 had a very strange routing behavior during all the experiment as it seems from this table as

well. After a lot of time, which means that the protocol had time to scale, the node reaches the BS through 5 nodes this time – even more than before. It reaches 242B through 07F9 through 4 hops.

Again, almost all the routes seem unusual. Additionally, it is interesting to note that the BS

received few packets from this node.


5.2.1.3 LQRP Graphs

The graphs of the experiment can be seen in Fig. 5.12. In x axis there are the packets received and

in y axis the battery level in milliVolts. The number of packets that the base station receives from

each node varies greatly and some graphs may receive more than 5000 packets. In this case the graph may seem noisy so, whenever needed, there was a function applied in order to make the

graphs look “smoother” and clearer for someone to understand what is happening. Consequently,

the number shown in x axis is not exactly the number of packets but a percentage of the packets depending on how high was the amount of packets received from the BS.


Fig. 5.12: LQRP – packets received/battery in mVolts

5.2.2 Node Lifetime based protocol


The protocol takes some time to scale. The routing tables need some time to be completed (takes time to find routes). The topology is shown in Fig. 5.13

Fig. 5.13: Node Lifetime based protocol topology3

5.2.2.2 Node Lifetime Routing

Some important routing tables of all the SPOTs are shown below.


0014.4F01.0000.02E6 LQI: 212

Seq Nber: 989


0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

02E6 is slow at finding routes and it has only found routes of 5 out of 8 SPOTs


0014.4F01.0000.02E6 LQI: 221



Seq Nber: 3347


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.242B 0014.4F01.0000.3A1B 4

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

An interesting route exists when communicating with 242B through 4 hops.


0014.4F01.0000.3A1B LQI: 229

Seq Nber: 1116


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.07F9 0014.4F01.0000.1539 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.1539 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.1539 3

For many routes 3A1B uses 1539 as next hop. The protocol considers that currently this is the node with the best cost of all the available ones for each route.


0014.4F01.0000.3A1B LQI: 242

Seq Nber: 2795


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.07F9 0014.4F01.0000.02E6 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.242B 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.1539 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.1539 2

The route to 07F9 has 02E6 now as next hop.


0014.4F01.0000.242B LQI: 242

Seq Nber: 250


0014.4F01.0000.3230 0014.4F01.0000.02E6 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.07F9 2

The node reaches the neighboring node 3A1B through 1539.



0014.4F01.0000.242B LQI: 174

Seq Nber: 1038


0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.07F9 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.07F9 2

The routes are quite normal. The table has lost one route keeping routes with no more than 2 hops.


0014.4F01.0000.07F9 LQI: 157

Seq Nber: 299


0014.4F01.0000.3230 0014.4F01.0000.12D4 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

No unusual routes in this routing table.


0014.4F01.0000.07F9 LQI: 187

Seq Nber: 1773


0014.4F01.0000.3230 0014.4F01.0000.1539 4

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

07F9 reaches 3230 in 4 hops through 1539 this time. This is a long route in number of hops and in

total distance.


0014.4F01.0000.12D4 LQI: 212

Seq Nber: 523


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Though the node is far away, it reaches 3230 directly. The rest of the routes are quite normal and


short (at most 2 hops).


0014.4F01.0000.12D4 LQI: 242

Seq Nber: 2403


0014.4F01.0000.3230 0014.4F01.0000.1539 4

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.22A5 0014.4F01.0000.07F9 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

22’ later the node reaches 3230 in 4 hops through 1539.


0014.4F01.0000.22A5 LQI: 191

Seq Nber: 37


0014.4F01.0000.3230 0014.4F01.0000.12D4 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

22A5 has found routes to only 3 SPOTs Battery Level: 13 Time: 2009-9-8 3:46:52 Voltage: 4012 of

0014.4F01.0000.22A5 LQI: 225

Seq Nber: 362


0014.4F01.0000.3230 0014.4F01.0000.12D4 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

The node finds 3230 in 3 hops now. It has no routes for the distant nodes 3A1B, 02E6 and 2274 but it has for 3230 which is also distant.


0014.4F01.0000.1539 LQI: 225

Seq Nber: 1119


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.242B 3

1539 uses very short routes – only with 1 hop. Exception is the route to 22A5 which happens in 3

hops through 242B which is an unusual routing decision.



0014.4F01.0000.1539 LQI: 238

Seq Nber: 3893


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.02E6 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

43’ later 1539 loses some routes.


0014.4F01.0000.2274 LQI: 225

Seq Nber: 15


0014.4F01.0000.3230 0014.4F01.0000.3230 1

In this experiment, 2274 had a very strange behavior. It managed to get very few packets to 3230

despite it was very close (adjacent node).

5.2.2.3 Graphs

The graphs of the protocol are shown in Fig. 5.14.


Fig. 5.14: Node Lifetime based protocol- packets/mVolts

5.2.3 Link Quality based protocol

5.2.3.1 Introduction-topology

The topology used in this experiment is shown in Fig. 5.15.


Fig. 5.15: Topology of Link Quality based protocol4

5.2.3.2 Link Quality-based protocol routing

Some important routing tables of each node are shown below.


0014.4F01.0000.24AB LQI: 136

Seq Nber: 371


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.07F9 3

Nothing unusual – the node is trying to find routes to the rest of the nodes.


0014.4F01.0000.24AB LQI: 238

Seq Nber: 5333


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.1539 3

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.1539 4

Apart from the route to 3230, the protocol chooses only 1539 as the next hop despite it may

produce routes with many hops. An example is the route to 22A5 in 4 hops.


0014.4F01.0000.3A1B LQI: 204

Seq Nber: 89


0014.4F01.0000.3230 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.07F9 2

In the beginning the node has found most of the routes with not really unusual routes.


0014.4F01.0000.3A1B LQI: 221

Seq Nber: 2898


0014.4F01.0000.3230 0014.4F01.0000.1539 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.1539 3



0014.4F01.0000.12D4 0014.4F01.0000.1539 3

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.24AB 0014.4F01.0000.1539 2

0014.4F01.0000.22A5 0014.4F01.0000.1539 4

The protocol chooses 1539 for almost all the routes. At this point it seems that the 3A1B-1539

link is a high quality link and the protocol prefers it as next hop in many routes. This decision

produces again routes with many hops as in 24AB.


0014.4F01.0000.242B LQI: 225

Seq Nber: 113


0014.4F01.0000.3230 0014.4F01.0000.1539 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.1539 2

0014.4F01.0000.22A5 0014.4F01.0000.1539 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

As in previous cases the protocol chooses 1539 as next hop apart from one route.


0014.4F01.0000.242B LQI: 238

Seq Nber: 300


0014.4F01.0000.3A1B 0014.4F01.0000.07F9 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.07F9 3

0014.4F01.0000.12D4 0014.4F01.0000.07F9 2

0014.4F01.0000.22A5 0014.4F01.0000.07F9 3

0014.4F01.0000.24AB 0014.4F01.0000.07F9 2

42’ later the routing table has been completely changed. Now, the protocol considers the link

242B-07F9 as the best and it uses it as the first link for all the routes. A reason for this change is

that the route to 1539 has disappeared from the table.


0014.4F01.0000.07F9 LQI: 199

Seq Nber: 164


0014.4F01.0000.3230 0014.4F01.0000.1539 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.02E6 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

0014.4F01.0000.1539 0014.4F01.0000.1539 1

The protocol finds many routes with reasonable routing decisions here.



0014.4F01.0000.07F9 LQI: 229

Seq Nber: 2048


0014.4F01.0000.3230 0014.4F01.0000.1539 3

0014.4F01.0000.02E6 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.242B 1

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.12D4 2

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

12D4 reaches 3230 directly despite it is very far away. It seems that this link 12D4 is quite good because the protocol chooses 12D4 as next hop to reach 22A5.


0014.4F01.0000.12D4 LQI: 225

Seq Nber: 317


0014.4F01.0000.3230 0014.4F01.0000.07F9 3

0014.4F01.0000.3A1B 0014.4F01.0000.07F9 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.02E6 0014.4F01.0000.07F9 3

0014.4F01.0000.1539 0014.4F01.0000.07F9 2

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

12D4 uses 07F9 for seven out of the eight available routes. It directly communicates with 22A5

which is an adjacent node. Battery Level: 56 Time: 2009-9-9 8:55:52 Voltage: 4022 of

0014.4F01.0000.12D4 LQI: 238

Seq Nber: 2673


0014.4F01.0000.3A1B 0014.4F01.0000.07F9 3

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.02E6 0014.4F01.0000.07F9 5

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1

Almost one hour later the table has fewer routes and it has one long multi hop route of 5 hops.

However, 12D4 is far from 02E6 so the 5 hops make sense. The protocol keeps considering the link 12D4-07F9 the best among the available ones.


0014.4F01.0000.1539 LQI: 204

Seq Nber: 11


0014.4F01.0000.3230 0014.4F01.0000.3230 1

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.07F9 2

0014.4F01.0000.12D4 0014.4F01.0000.12D4 1

0014.4F01.0000.22A5 0014.4F01.0000.22A5 1


1539 in the beginning of the experiment is trying to find the other SPOTs.


0014.4F01.0000.1539 LQI: 238

Seq Nber: 4248


0014.4F01.0000.3230 0014.4F01.0000.24AB 2

0014.4F01.0000.3A1B 0014.4F01.0000.3A1B 1

0014.4F01.0000.07F9 0014.4F01.0000.07F9 1

0014.4F01.0000.242B 0014.4F01.0000.24AB 3

0014.4F01.0000.12D4 0014.4F01.0000.07F9 2

0014.4F01.0000.24AB 0014.4F01.0000.24AB 1

0014.4F01.0000.22A5 0014.4F01.0000.07F9 3


0014.4F01.0000.2274 LQI: 140

Seq Nber: 7106


0014.4F01.0000.3230 0014.4F01.0000.3230 1

As in the previous experiment, 2274 showed some serious problems. Despite it has exactly the

same software and conditions it could not find another route during the whole experiment. The

only route it has is to the base station. It has sent a huge amount of packets (Seq Nber: 7106) but only to the BS.


0014.4F01.0000.02E6 LQI: 212

Seq Nber: 2804


0014.4F01.0000.3230 0014.4F01.0000.1539 2

0014.4F01.0000.3A1B 0014.4F01.0000.1539 2

0014.4F01.0000.242B 0014.4F01.0000.1539 2

0014.4F01.0000.12D4 0014.4F01.0000.1539 3

0014.4F01.0000.1539 0014.4F01.0000.1539 1

0014.4F01.0000.22A5 0014.4F01.0000.1539 5

02E6 was restarted long before the experiment started. This is the reason why in the beginning of the experiment the sequence number is high. The node uses only 1539 as next hop to all routes.

Something noticeable is the 5 hops route to 22A5 via 1539 which means that the SPOTs which

participate in it are scattered around probably all the area. Another interesting routing decision is

the route to 3230 which takes place via 1539 as well despite 02E6 is adjacent to 3230.

5.2.3.3 Link Quality based protocol Graphs

The graphs concerning the packets received and the battery level of the nodes are shown in Fig.

5.16.

It is worth mentioning that 02E6 was connected to a computer inside the office. That is why the

battery level graph is so different from the rest of the nodes. The battery level may be decreased a

bit but since it is connected, it is charged at the same time so the battery level is increased again.


Fig. 5.16: Link Quality based protocol. Packets/mVolts


6. Conclusions and Recommendations

6.1 Contribution

In this master thesis report one can find the presentation of Sun SPOTs, in the first chapter from

the software and the hardware point of view. In the second chapter there is the presentation and comparison of many routing protocols which can be used in WSN with pictures explaining how

they work in more detail. In the third chapter there is the presentation of the old routing protocol

that was used in Sun SPOTs, the current protocol and of two other proposed ones made by the author. The presentation is done through the explanation of the most important methods and

classes that are used in each protocol. This explanation helps the reader understand faster what is

happening in the protocols and why. In the next chapter there is the presentation of the indoor and

outdoor experiments along with pictures, routing analysis and graphs of the results. Through this it is possible for someone interested to read and investigate through the routing tables and the

graphs how each protocol behaves in different conditions and topologies. Also, one can see some

problems one can face while preparing experiments with Sun SPOTs and how it is possible to surpass these difficulties.

To summarize, the contributions offered from this thesis are the following:

• Two new protocols which offer different routing than the one used by default.

• A test-bed on the roof, different from the old one, appropriate for investigating the

routing and avoiding interference due to objects, ground and environment as much as

possible.

• Data from many experiments, indoor and outdoor with different conditions and

topologies.

• Sun SPOT and host applications written to make the communication and the routing

among the nodes possible.

• A deep analysis and comparison of many routing protocols used in WSN with

comparisons along with pictures.

6.2 Conclusions

• AODV, the old routing protocol, is really not good enough. It is great that is has stopped

being used anymore.

• LQRP, the new routing protocol by default, is a great improvement in Sun SPOTs routing.

It uses both link quality and node lifetime as cost to route the packets. It seems to work really well in indoor and outdoor conditions, scales very well and fast. It finds routes and

manages to run for a long time.

• The Link Quality based protocol is a modified version of the LQRP. It uses as cost only

the Link Quality to route the packets, something that in some cases can be proven a wise

choice.

• The Node Lifetime based protocol is a modified version of the LQRP as well. It uses only

the node lifetime to route the packets. Again, there are cases as explained in the report

that may be preferable to use this protocol.

• Link Quality and Node Lifetime based protocols seem to work well. It is obvious that

they exchange packets but it is difficult to be absolutely sure that they work as they should. Many experiments are needed with different conditions to see if they are working

as they should.


6.3 Recommendations

• The new protocols need improvements to ensure that they work flawlessly.

• Also, more experiments are needed to take place with different configurations and

topologies to see if the protocols work as they should. For example it is important to

know that a specific link has been chosen because this link is indeed the link with the

highest LQI of all the available. This is not possible with the current implementations.

• Even LQRP is based on AODV, so, a good recommendation would be to try a different

routing technique on SPOTs, like Dynamic Source Routing (DSR) or Optimized Link-

State Routing (OLSR). Also, it would be interesting first to make a theoretical analysis of

which protocols could work for Sun SPOTs and why.

7. References

[1] Kemal Akkaya and Mohamed Younis “A Survey on Routing Protocols for Wireless Sensor Networks”.

Available at http://perso.ens-lyon.fr/isabelle.guerin-lassous/Enseignement/survey-routing-WSN.pdf

[2] Jamal N.-Karaki, Ahmed E. Kamal, ”Routing Techniques in Wireless Sensor Networks: A Survey”,

2004. Available at http://www.ics.uci.edu/~dsm/ics280sensor/readings/networks/routing-survey.pdf

[3] A. Floros, C. Huang, G, Dogan, T. Sun, Z. Cao, M. Bahader, M. Zennaro. “Waterwell team project”.

Available at http://www.tslab.ssvl.kth.se/csd/projects/0821006/

[4] KSN team : ”KSN Radiostack Project”. Karlsruche Institute of Technology. 2008. Available at

http://www.ipd.uni-karlsruhe.de/KSN/RadioStack/experiments.html

[5] M. Younis, M. Youssef and K. Arisha, “Energy-Aware Routing in Cluster-Based Sensor Networks”, in

the Proceedings of the 10th, IEEE/ACM International Symposium on Modeling, Analysis and

Simulation of Computer and Telecommunication Systems (MASCOTS2002), Fort Worth, TX, October

2002

[6] A. Manjeshwar and D. P. Agrawal, “TEEN : A Protocol for Enhanced Efficiency in Wireless Sensor

Networks," in the Proceedings of the 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing, San Francisco, CA, April 2001

[7] I. Akyildiz et al., “A Survey on Sensor Networks,” IEEE Commununications Magazine, vol. 40, no. 8,

Aug. 2002

[8] A. Manjeshwar and D. P. Agarwal, “TEEN: a Routing Protocol for Enhanced Efficiency in Wireless

Sensor Networks,” 1st Int’l. Wksp. on Parallel and Distrib. Comp. Issues in Wireless Networks and

Mobile Comp., April 2001.

[9] A. Manjeshwar and D. P. Agarwal, “APTEEN: A Hybrid Protocol for Efficient Routing and

Comprehensive Information Retrieval in Wireless Sensor Networks,” Proc. Int’l. Parallel and Distrib.

Proc. Symposium

[10] R. C. Shah and J. Rabaey, “Energy Aware Routing for Low Energy Ad Hoc Sensor Networks,”

IEEE WCNC, Orlando, FL, Mar. 17–21, 2002.

[11] B. Nyirenda and J. Mwanza, “Performance Evaluation of Routing Protocols in Mobile Ad Hoc

Networks (MANETs)”, Blekinge Intitute of Technology, January 2009

[12] M. Alexandropoulou, “Μοντελοποίηση και µελέτη της απόδοσης τεχνικών συνάθροισης δεδοµένων σε

ασύρµατα δίκτυα αισθητήρων”, National Technical University of Athens, July 27 2007

[13] IEEE 802.15 Working Group for WPAN website. Available on http://www.ieee802.org/15/

[14] C. Intanagonwiwat, R. Govindan, and D. Estrin,“Directed Diffusion: a Scalable and Robust

Communication Paradigm for Sensor Networks,” Available at

http://lecs.cs.ucla.edu/~estrin/papers/diffusion.ps

[15] N. Sadagopan et al., “The ACQUIRE mechanism for efficient querying in sensor networks,” in

the Proceedings of the First International Workshop on Sensor Network Protocol and Applications,

Anchorage, Alaska, May 2003.


[16] W. Heinzelman, J. Kulik, and H. Balakrishnan, “Adaptive Protocols for Information Dissemination in

Wireless Sensor Networks,” Proc. 5th ACM/IEEE Mobicom, Seattle, WA, Aug. 1999. pp. 174–85.

[17] J. Kulik, W. R. Heinzelman, and H. Balakrishnan, “Negotiation-Based Protocols for Disseminating

Information in Wireless Sensor Networks,” Wireless Networks, vol. 8, 2002, pp. 169–85.

[18] D. Braginsky and D. Estrin, “Rumor Routing Algorithm for Sensor Networks,” Proc. 1st Workshop.

Sensor Networks and Applications., Atlanta, GA, Oct. 2002.

[19] Y. Yao and J. Gehrke, “The Cougar Approach to In network Query Processing in Sensor Networks,”

SIGMOD Record, September 2002

[20] Moment Lab website. Available at http://moment.cs.ucsb.edu/AODV/

[22]“List of ad-hoc routing protocols”. Available at

http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list

[23] Holger Karl, Andreas Willig, “Protocols and architectures for Wireless Sensor Networks”, Wiley, 2005

athanasios florosntareme/thanos-thesis-text.pdf · an introduction to routing protocols for wsn and...

Documents