Networks of low power wireless devices have introduced novel routing issues. These devices, such as sensors, actuators and smart objects, have different constraints: very limited memory, little processing power, and long sleep periods. The fact that these devices are battery-powered makes the energy efficiency a critically imperative factor. This requires the protocols to make responsive decisions but with minimum topology changes and energy costs. In most of the cases their deployment is in hostile areas, which raises various security concerns.

Mobile Sensor Networks (MSNs), a special class of sensor networks, inherit the properties and constraints of Mobile Adhoc Networks (MANETs), with the added limitations of resources. These constraints along with the operational characteristics of MSNs place special requirements on routing algorithms.

In this research, a secure zone based routing protocol for MSN is developed. A novel zone-based protocol has been developed that divides the network into square zones. The zone head is responsible for finding route to the Base Station keeping into account the factor of mobility across every path. Path repair mechanism has been designed in order to prevent the error messages from spreading across the whole network. The network always converges to an error free state in case of broken links, due to the immediate selection of new zone head.

NS-2 simulator has been used to simulate the proposed solution. It has been tested for various application environments of WSNs. The suitability of the FTSR protocol against different attacks has been analyzed. Energy consumption, scalability and throughput in static as well as mobile environments have been shown in the form of output graphs.


All Praise And Thanks To Almighty Allah, The Most Beneficent And The Most Merciful, Master Of The Day Of Judgment. O Lord! Guide Us With Courage And Right Path, Path Of Those To Whom You Have Bestowed Your Blessings.

Dedicated to My Mother


Firstly, I would like to thanks my supervisor Lt. Col. Dr. Muhammad Arif Wahla, Head of Information Security Department, Military College of Signals, NUST for his continuous encouragement and able guidance. Without his support and guidance this thesis could not be completed in time.

I am grateful to Dr. Faisal Bashir Hussain of Computer Science Department for his selfless and generous support in the completion of this thesis.

I am also thankful to my guidance committee members Lt Col Attique Ahmed, Electrical Engineering Department, Lt. Col. Dr. Fahim Arif and Maj Faisal Amjad, Computer Science Department for their able guidance and support.

Chapter 1



Wireless Sensor Networks abbreviated as WSNs belongs to a class of Low power and Lossy Networks. As the name suggests, WSNs use tightly resource constrained tiny sensing nodes that are self organizing in nature with little or no infrastructure. WSNs are gaining momentum as they have great potential for both research and commercial applications. The sensor network nodes themselves are low-priced, very small devices. Typical functions in a WSN include sensing and collecting data, processing and transmitting sensed data, possibly storing data for some time, and routing processed data as information to a base station. Deployment of WSNs in unattended hostile environment needs securing all those functions.

MSNs are composed of sensor nodes that can move under their own control or under the control of the environment. Mobile networked systems combine the most advanced concepts in perception, communication, and control to create computational systems capable of interacting in meaningful ways with the physical environment, thus extending the individual capabilities of each network component and network user to encompass a much wider area and range of data. A key difference between a mobile sensor network and a static sensor network is how information is received or delivered to or from the node.

Keeping in view all the considerations of Mobile WSNs or mobility within WSN, new concerns have come to surface which has increased the complexity of network. Therefore it is required to restructure the proposed approaches in existing literature or to develop new schemes capable of handling mobility issues.

Statement of Problem

Besides all the efforts and research carried out in the field of Mobile WSNs, we still are lacking a standardized efficient and secure routing algorithms that address the problems regarding efficient path finding, route creation, route preservation and route recreation with an added capability of avoiding impulsive degradation.

The algorithm must also cater for security concerns raised by mobility and their deployment in hostile environment, with maximum fault tolerance while utilizing a minimum amount of resources.

Research Question

This thesis will attempt to answer the question, "How the routing protocols designed for MANETs can be altered for implementation on resource constrained MSNs, instead of designing a whole new protocol, keeping in view that the protocol is energy efficient, reliable and secure in various proposed threat models".

Research Purpose

The background of this research has identified some key issues related to routing in MSNs. Similarities in MSNs and MANETs infer that the routing protocols designed for MANETs are strong candidates to be implemented on MSNs with such modifications that let them operate in resource constrained environment. Therefore the purpose of this research is to develop a secure and efficient, fault tolerant routing algorithm that is effective in case of mobile nodes where topology changes are more often than static nodes.

Research Methodology

The first step involves extensive literature study which will be used to lay the foundation for routing protocols in wireless ad hoc networks.

The next step will use the established principles of secure routing protocols in both MANETs and static sensor networks for their analysis. This will help to identify the limitations of MANET routing protocols, and the answer to how they can be implemented on Sensor Networks specifically mobile sensor networks.

Third step involves both the development of a routing protocol that is suitable for MSNs and verifying the proposed protocol in performance test simulator under various test environments.

Research Scope

The scope of this research is limited to zone based routing in mobile sensor networks where each zone consists of a Zone Head and a finite number of member nodes. All nodes possess same capabilities and constraints with the ability to move either at free will or depending on the application. Each node in the zone reports the sensed data to the zone head which is responsible for aggregating and routing the aggregated information to the Base Station. Member nodes in each zone are not aware of routing decisions and hence do not participate in routing except for special cases.

Document Organization

This thesis has been organized in chapters. Chapter 2 provides an overview of sensor networks, their characteristics, limitations, proposed routing algorithms and their level of contribution to security and fault tolerance, emphasizing on Mobile Sensor Networks. This chapter also discusses various secure routing protocols, their effectiveness in case of mobile networks, various types of attacks, their attributes, and their effects on routing protocols for sensor networks, thus concluding the literature review.

Chapter 3 proposes a more versatile secure zone based AODV protocol called as Fault Tolerant Secure Routing (FTSR) for Mobile Sensor Networks. This protocol has been designed keeping in view the aspect of fault tolerance and security. This chapter describes operation, path setup, path maintenance link breakage, local connectivity management and fail-safe mode of operation for our FTSR protocol.

Analysis of FTSR protocol with respect to security and level of fault tolerance has been covered in chapter 4.

Chapter 5 provides information on simulation methodology of FTSR and describes simulation and the results achieved.

Chapter 6 concludes the whole research, and wraps up talking about the goals and objectives achieved and a way forward for new areas of research.

Chapter 2

Literature Review


This chapter introduces wireless sensor networks, categorized by their types and applications. Special emphasis has been made on Mobile Sensor Networks, their existing routing protocols and their contribution to security and fault tolerance. Characteristics and requirements of secure routing protocol in sensor networks are also elaborated to provide guideline for research work. In the last section a thorough analysis of secure routing protocols has been provided.

Mobile Sensor Networks

Mobile Sensor Network (MSN) is a wireless network consisting of spatially distributed autonomous mobile devices using sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants, at different locations.

In addition to one or more sensors, each node in a sensor network is typically equipped with a radio transceiver or other wireless communications device, a small microcontroller, a mobilizer and an energy source, usually a battery. The envisaged size of a single sensor node can vary from shoebox-sized nodes down to devices the size of grain of dust, although functioning 'motes' of genuine microscopic dimensions have yet to be created. The cost of sensor nodes is similarly variable, ranging from hundreds of pounds to a few pence, depending on the size of the sensor network and the complexity required of individual sensor nodes. Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and bandwidth.[1].


The applications for WSNs are many and varied, but typically involve some kind of monitoring, tracking, and controlling. Specific applications for WSNs include habitat monitoring, object tracking, nuclear reactor control, fire detection, and traffic monitoring.

In a typical application, a WSN is scattered in a region where it is meant to collect data through its sensor nodes.

Area monitoring

Area monitoring is a common application of WSNs. In area monitoring, the WSN is deployed over a region where some phenomenon like is to be monitored. Typically this type of network is composed of static sensors.

Environmental Monitoring

A number of WSN deployments have been done in the past in the context of environmental monitoring [2]. The environment monitoring networks are usually composite of static and mobile nodes.

Target Tracking

Typical network comprise of mobile node. These are mainly used for target tracking applications. These types of networks require fine grained and reliable solutions in every concerned domain ranging from application design, physical and electrical characteristics to the domains like media access, routing and data delivery with minimum latency. We are mainly concerned with this type of sensor network in our proposed research.

Routing Protocols

Mobile Sensor Networks have possessed the constraints and limitations of Wireless Sensor Networks; however their mobility pattern is some what close to Mobile Adhoc Networks. We can safely assume MSNs as an advanced representation of low powered Mobile Adhoc networks that are able to sense, predict, decide and move at their own will or on the command of their controller node.

Mobility within Sensor Networks, that are already constrained in nature, imposes special requirements to be considered when either designing new protocols, or implementing the presently designed.

Routing protocols already developed for sensor networks consider static nodes, as this assumption facilitates the design. Routes once established are never to be changed except in the case of node failure or link failure that is obvious but less frequent. Therefore very less overhead is incurred upon the network.

Routing protocols for Mobile Adhoc Networks are strong candidates for routing in MSNs as they cater for mobility of the participating nodes. However, they have been designed for MANETs that are, in fact battery powered, but still not that much resource constrained as MSNs. Therefore they can not be implemented to MSNs without modification in their architecture and operation.

Besides all the efforts to propose a routing protocol, it must also be considered that sensor networks are deployed in unattended and hostile environments and are much more prone to attacks resulting in the compromise of information and/or operation failure.

Security measures, however stringent they are, may fall for some highly advanced and unforeseen circumstances that may halt operation in some area of network. Otherwise, whatever issue the network is facing in terms of a network segment failure, our aim is to provide a mechanism that the network failure in one segment does not spread across the entire network.

The network must have the capacity to endure path failures due to network segment faults and fail-safe mechanism for information flow is always there with minimum overhead, i.e. over head of route discovery.

Following is the brief description of the currently proposed routing protocols for sensor networks. The performance analysis metrics consist of the level of security, fault tolerance, mobility, scalability, power awareness and estimated overhead.

TinyOS Beaconing

The TinyOS beaconing protocol constructs a breadth first spanning tree rooted at a base station as shown in figure 2-2. Periodically the base station broadcasts a route update. All nodes receiving the update mark the base station as its parent and rebroadcast the update.

The algorithm continues recursively with each node marking its parent as the first node from which it hears a routing update during the current time epoch. All packets received or generated by a node are forwarded to its parent (until they reach the base station).

Directed Diffusion

Directed diffusion [4] is a data-centric routing algorithm for drawing information out of a sensor network. Base stations flood interests for named data, setting up gradients within the network designed to draw events (i.e., data matching the interest). Nodes able to satisfy the interest disseminate information along the reverse path of interest propagation. Nodes receiving the same interest from multiple neighboring nodes may propagate events along the corresponding multiple links. Interests initially specify a low rate of data flow, but once a base station starts receiving events it will reinforce one (or more) neighbor in order to request higher data rate events. This process proceeds recursively until it reaches the nodes generating the events, causing them to generate events at a higher data rate. Alternatively, paths may be negatively reinforced as well.

There is a multi-path variant of directed diffusion [4] as well. After the primary data flow is established using positive reinforcements, alternate routes are recursively established with maximal disjointedness by attempting to reinforce neighbors not on the primary path.

Geographic Routing

Geographic and energy aware routing (GEAR) and greedy perimeter stateless routing (GPSR) [4] leverage nodes' positions and explicit geographic packet destinations to efficiently disseminate queries and route replies. GPSR uses greedy forwarding at each hop, routing each packet to the neighbor closest to the destination. When holes are encountered where greedy forwarding is impossible, GPSR recovers by routing around the perimeter of the void. One drawback of GPSR is that packets along a single flow will always use the same nodes for the routing of each packet, leading to uneven energy consumption. GEAR attempts to remedy this problem by weighting the choice of the next hop by both remaining energy and distance from the target. In this way, the responsibility for routing a flow is more evenly distributed among a ''beam'' of nodes between the source and base station. Both protocols require location (and energy for GEAR) information to be exchanged between neighbors, although for some fixed, well structured topologies (a grid for example) this may not be necessary.

Minimum Cost Forwarding

Minimum cost forwarding [5] is an algorithm for efficiently forwarding packets from sensor nodes to a base station with the useful property that it does not require nodes to maintain explicit path information or even unique node identifiers. It works by constructing a cost field starting at the base station. The base station has cost zero. Every other node maintains the minimum cost required to reach the base station. Cost can represent any application dependent metric: hop count, energy, latency, loss, etc.

Every node except the base station starts with cost (infinity). Cost values are established by flooding a beacon starting from the base station. The beacon advertises the base station s cost (zero) and is propagated throughout the network. Upon hearing an advertisement from node M containing M's cost, node N now knows of a path of cost CM + LN.M. Node N compares its current cost CN to CM + LN.M, where CM is M's cost carried in the advertisement and LN.M is the cost of the link between N and M. If the new cost is smaller, then it sets CN = CM + LN.M and rebroadcasts an advertisement containing its new cost. In essence, this is a distributed shortest-paths algorithm. As a node's cost converges to its minimum cost, the node will immediately send out a new advertisement every time its cost is updated. The authors present an optimization to the above algorithm which reduces the number of messages sent to establish the minimum cost field. After a node updates its cost, it delays rebroadcasting the advertisement containing its new cost for a time proportional to the link cost in the advertisement it received. A message initiated by a source contains a cost budget initialized to the calculated minimum cost from the source to the base station. At each hop, the link cost of the hop is subtracted from the budget. The message is broadcast without specifying a next hop. A neighboring node hearing the message will forward the message only if the packet s remaining cost budget is equal to that node's own minimum cost. The authors also present a multi-path version called credit-based mesh forwarding [6] which works by giving a message an extra amount of ''credit'' beyond the minimum cost of the source, enabling possibly multiple receivers to forward the message.

LEACH: Low-Energy Adaptive Clustering Hierarchy

LEACH [7] leverages clustering to efficiently disseminate queries and gather sensor readings to and from all nodes in the network. LEACH assumes every node can directly reach a base station by transmitting with sufficiently high-power. However, one hop transmission directly to a base station can be a high-power operation and is especially inefficient considering the amount of redundancy typically found in sensor networks.

LEACH organizes nodes into clusters with one node from each cluster serving as a cluster-head. Nodes first send sensor readings to their cluster-head, and the cluster-head aggregates or compresses the data from all its ''children'' for transmission to a base station. If cluster-head selection is static, those unlucky nodes chosen as cluster-heads would quickly run out of energy and die. LEACH uses randomized rotation of nodes required to be cluster-heads to evenly distribute energy consumption over all nodes in the network. LEACH operation is broken into rounds, with each round having a set-up phase and a steady state phase. In the beginning of the set-up phase, each node probabilistically decides whether or not to be a cluster-head based on its remaining energy and a globally known desired percentage of cluster-heads. Each node electing itself as a cluster-head broadcasts an advertisement message announcing its intention. Non-cluster-head nodes receive possibly several advertisements and pick one cluster to join based on the largest received signal strength of the advertisement from the corresponding cluster-head. Nodes inform the cluster-head of the cluster they intend to join, and each cluster-head sends back a TDMA schedule for sending data to it for each node in its cluster.

In the steady-state phase, each cluster-head waits to receive data from all nodes in its cluster and then sends the aggregated or compressed result back to a base station.

Rumor Routing

Rumor routing [8] is a probabilistic protocol for matching queries with data events. Flooding and gossiping [9] of events and/or queries throughout the network are robust mechanisms for doing this, but both have relatively high-associated energy costs. However, flooding can be used to create a network-wide gradient field [5],[10] which is useful in routing frequent or numerous events or queries and amortizes the initial set-up cost. Rumor routing offers a energy-efficient alternative when the high-cost of flooding cannot be justified. Examples include posing a query on a very small cluster of nodes and advertising an observed event of possibly limited interest. In rumor routing, when a source observes an event, it sends an agent on a random walk through the network. Agents carry a list of events, the next hop of paths to those events, the corresponding hop counts of those paths, a time to live (TTL) field, and a list of previously visited nodes and those nodes neighbors (used to help ''straighten'' paths and eliminate loops). When an agent arrives at a new node, it informs that node of events it knows of (and the next hop on the path to those events), adds to its event list any events the node might know of, and decrements it's TTL. If the TTL is greater than zero, the node probabilistically chooses the agent's next hop from its own neighbors minus the previously seen nodes listed in the agent. When a base station wants to disseminate a query, it creates an agent that propagates in a similar way. A route from a base station to a source is established when a query agent arrives at a node previously traversed by an event agent that satisfies the query.

GAF: Geographic Adaptive Fidelity

GAF [11] places nodes into virtual ''grid squares'' according to geographic location and expected radio range. Any pair of nodes in adjacent grid squares are able to communicate. Nodes are in one of three states: sleeping, discovery, and active. Active nodes participate in routing while discovery nodes probe the network to determine if their presence is needed. Sleeping nodes have their radio turned off. Nodes are ranked with respect to current state and expected lifetime. Discovery messages are used to exchange state and ranking information between nodes in the same grid. GAF attempts to reach a state in which each grid square has only one active node.


In SPAN [12], nodes decide whether to sleep or join a backbone of ''coordinators'' that attempt to maintain routing fidelity in the network. Coordinators stay awake continuously while the remaining nodes go into ''power saving'' mode and periodically send and receive HELLO messages to determine if they should become a coordinator. In a HELLO message, a node announces its current status (coordinator or not), its current coordinators, and its current neighbors. A node's current coordinators are those neighbors which are coordinators. A node becomes eligible to become a coordinator if two of its neighbors cannot reach other directly or via one or two coordinators. In order to prevent broadcast storms if multiple nodes discover the need of a coordinator and were simultaneously to announce their intention to become one, each node delays its announcement of becoming a coordinator by a randomized back-off. While in the back-off stage, it continues to listen for additional HELLO messages and coordinator announcements. If at the end of the back off stage, the coordinator eligibility condition still holds, the candidate node announces its intention to become a coordinator. The randomized back off is a function of utility and remaining energy. Utility is a measure of the number of pairs of nodes (among a node's neighbors) that would become connected if that node were to become a coordinator. A node with high-utility and energy is more likely to calculate a shorter back-off time. Nodes eventually withdraw from being a coordinator for two reasons: (1) the eligibility requirement no longer holds, or (2) in order to ensure fairness, after some time a node will withdraw from being a coordinator if it discovers every pair of neighboring nodes can reach each other through some other neighbor. A node will then announce its intention to withdraw, but will continue to forward packets for a short period of time until a new coordinator is elected.

Security Architecture

Security issues in ad-hoc networks are similar to those in sensor networks and have been well enumerated in the literature [4], but the defense mechanisms developed for ad-hoc networks are not directly applicable to sensor networks. There are several reasons for why this is so, but they all relate to the differences between sensor and Adhoc networks. Some ad-hoc network security mechanisms for authentication and secure routing protocols are based on public key cryptography [13]-[15]. Public key cryptography is too expensive for sensor nodes. Security protocols for sensors networks must rely exclusively on efficient symmetric key cryptography.

Secure routing protocols for ad-hoc networks based on symmetric key cryptography have been proposed in [16]-[19]. These protocols are based on source routing or distance vector protocols and are unsuitable for sensor networks. They are too expensive in terms of node state and packet overhead and are designed to find and establish routes between any pair of nodes--a mode of communication not prevalent in sensor networks.

Perrig et al. [22] present two building block security protocols optimized for use in sensor networks, SNEP and µTESLA. SNEP provides confidentiality, authentication, and freshness between nodes and the sink, and µTESLA provides authenticated broadcast.

Network Assumptions for Security

This section describes some inherent characteristic of sensor networks and explains a few assumptions regarding the network setup. As the Sensor networks use wireless communication and radio links are insecure, so at the very least, attackers can eavesdrop on our radio transmissions, inject bits in the channel, and replay previously overheard packets.

The physical and MAC layers are susceptible to direct attack. Adversaries can jam radio links by transmitting without stop or try to cause collisions by leveraging the ''hidden terminal'' problem [23]. With a MAC protocol using Clear-to-Send/Receive-to-Send (CTS/RTS) frames, adversaries can send frequent CTS frames with long ''duration'' fields, effectively preventing other nodes from using the channel. In addition, MAC protocols using randomized back off are susceptible to attack if nodes have poor entropy management or predictable pseudo-random number generation. Adversaries able to predict back off times (and thus when a node will transmit) can cause long back off times or collisions.

Physical layer threats are typically countered by frequency hopping or spread spectrum communication [24], and MAC layer attacks can be alleviated by using a less susceptible protocol (Slotted Aloha [25], for example), good entropy management, and a cryptographically secure pseudorandom number generator [26]. It is possible for adversaries to exploit weaknesses in these layers to mount attacks, for example, an adversary could try to corrupt packets selectively by well timed collisions or jamming, but we will not consider attacks on the physical and MAC layers any further.

Trust Requirements

Base stations connects a sensor network to the outside world, therefore the compromise of a significant number of them can render the entire network useless. For this reason it is assumed that base stations are trustworthy, in the sense that they can be trusted if necessary and are assumed to behave correctly. Most, but not all routing protocols depend on nodes to trust messages from base stations.

Aggregation points may be trusted components in certain protocols. Nodes may rely on routing information from aggregation points and trust that messages sent to aggregation points will be accurately combined with other messages and forwarded to a base station. Aggregation points are often regular sensor nodes. It is possible that adversaries may try to deploy malicious aggregation points or attempt to turn currently compromised nodes into aggregation points. For this reason aggregation points may not necessarily be trustworthy.

Security Goals

In an ideal world, we would like to guarantee the confidentiality, integrity, authenticity, and availability of all messages in the presence of resourceful adversaries. Every eligible receiver should receive all messages intended for it and be able to verify the integrity of every message as well as the identity of the sender. Adversaries should not be able to infer the content of any message, even if they participate in the routing of it. However, the question remains to which of these goals should be the responsibility of the routing protocol and which goals are handled better at higher (e.g., application) or lower (e.g., link) layers.

In more conventional networks, the primary security goal of a routing protocol is reliable delivery of messages, i.e., protection against denial of service, and message authenticity, integrity, and confidentiality are usually achieved by an end-to-end security mechanism such as SSH or SSL. The reason for this grading of responsibilities is because the dominating traffic pattern is end-to-end communication, where it is neither necessary nor desirable for the contents of the message (beyond the necessary headers) to be available to the intermediate routers.

This is not the case in sensor networks. The many cases, the dominant traffic pattern in sensor networks is many-to-one, with many sensor nodes needing to communicate sensor readings or network events back to a central base station. In-network processing such as aggregation, duplicate elimination, or data compression is needed to do this in an energy efficient manner. Since in-network processing requires intermediate nodes to access, modify, and possibly suppress the contents of messages, it is highly unlikely that end-to-end security mechanisms between a sensor node and a base station can be used to guarantee integrity, authenticity, and confidentiality of such messages.

In the presence of outsider adversaries, link layer security mechanisms can guarantee integrity, authenticity, and confidentiality of messages because they deny an outsider access to the network.

However, we still must rely on the routing protocol to guarantee availability. The presence of insiders significantly lessens the effectiveness of link layer security mechanisms. By definition, an insider is allowed to participate in the network. Link layer security can still prevent a compromised node from interfering with messages between other nodes, but such a node will have complete access to any messages routed through it and is free to modify, suppress, or eavesdrop on the contents. The conclusion then is that link layer security is not enough: since insiders may be able to exploit features in the routing protocol to violate the security goals, the routing protocol itself must be considered security critical.

In the presence of only outsider adversaries, it is conceivable to achieve these idealized goals. However, in the presence of compromised or insider attackers, especially those with laptop-class capabilities, it is most likely that some if not all of these goals are not fully attainable. Rather, instead of complete compromise of the entire network, the best we can hope for in the presence of insider adversaries is graceful degradation. The effectiveness of a routing protocol in achieving the above goals should degrade no faster than a rate approximately proportional to the ratio of compromised nodes to total nodes in the network.

Finally, it can be said that protection against the replay of data packets should not be a security goal of a secure routing protocol. This functionality is best provided at the application layer because only the application can fully and accurately detect the replay of data packets (as opposed to retransmissions, for example).

Attacks on Sensor Network Routing

Many sensor network routing protocols are quite simple, and for this reason are sometimes susceptible to attacks from the literature on routing in ad-hoc networks. Most network layer attacks against sensor networks fall into one of the following categories:

  • Spoofed, altered, or replayed routing information,
  • Selective forwarding,
  • Sinkhole attacks,
  • Sybil attacks,
  • Wormholes,
  • HELLO flood attacks,
  • Acknowledgement Spoofing.

A general discussion on types of attacks and how these attacks may be applied to compromise routing protocols that have been previously proposed in the literature.

Spoofed, Altered, Or Replayed Routing Information

The most direct attack against a routing protocol is to target the routing information exchanged between nodes. By spoofing, altering, or replaying routing information, adversaries may be able to create routing loops, attract or repel network traffic, extend or shorten source routes, generate false error messages, partition the network, increase end-to-end latency, etc.

Selective Forwarding

Multihop networks are often based on the assumption that participating nodes will faithfully forward the received messages. In a selective forwarding attack, malicious nodes may refuse to forward certain messages and simply drop them, ensuring that they are not propagated any further. A simple form of this attack is when a malicious node behaves like a black hole and refuses to forward every packet it sees. However, such an attacker runs the risk that neighboring nodes will conclude that it has failed and hence will decide to seek another route. A more subtle form of this attack is when an adversary selectively forwards packets. An adversary interested in suppressing or modifying packets originating from a select few nodes can reliably forward the remaining traffic and limit suspicion of her wrongdoing.

Selective forwarding attacks are typically most effective when the attacker is explicitly included on the path of a data flow. However, it is conceivable an adversary overhearing a flow passing through neighboring nodes might be able to emulate selective forwarding by jamming or causing a collision on each forwarded packet of interest. The mechanics of such an effort are tricky at best, and may border on impossible.

Thus, we believe an adversary launching a selective forwarding attack will likely follow the path of least resistance and attempt to include herself on the actual path of the data flow. In the next two sections, we discuss sinkhole attacks and the Sybil attack, two mechanisms by which an adversary can efficiently include herself on the path of the targeted data flow.

Sinkhole Attacks

In a sinkhole attack, the adversary's goal is to lure nearly all the traffic from a particular area through a compromised node, creating a metaphorical sinkhole with the adversary at the center. Because nodes on, or near, the path that packets follow have many opportunities to tamper with application data, sinkhole attacks can enable many other attacks (selective forwarding, for example). Sinkhole attacks typically work by making a compromised node look especially attractive to surrounding nodes with respect to the routing algorithm. For instance, an adversary could spoof or replay an advertisement for an extremely high-quality route to a base station. Some protocols might actually try to verify the quality of route with end-to-end acknowledgements containing reliability or latency information. In this case, a laptop-class adversary with a powerful transmitter can actually provide a high quality route by transmitting with enough power to reach the base station in a single hop, or by using a wormhole attack discussed in Section 6.5. Due to either the real or imagined high-quality route through the compromised node, it is likely each neighboring node of the adversary will forward packets destined for a base station through the adversary, and also propagate the attractiveness of the route to its neighbors. Effectively, the adversary creates a large ''sphere of influence'', attracting all traffic destined for a base station from nodes several (or more) hops away from the compromised node. One motivation for mounting a sinkhole attack is that it makes selective forwarding trivial. By ensuring that all traffic in the targeted area flows through a compromised node, an adversary can selectively suppress or modify packets originating from any node in the area. It should be noted that the reason sensor networks are particularly susceptible to sinkhole attacks is due to their specialized communication pattern. Since all packets share the same ultimate destination (in networks with only one base station), a compromised node needs only to provide a single high-quality route to the base station in order to influence a potentially large number of nodes.

The Sybil Attack

In a Sybil attack [27], a single node presents multiple identities to other nodes in the network. The Sybil attack can significantly reduce the effectiveness of fault-tolerant protocols such as distributed storage [28], disparity [29] and multipath [30] routing, and topology maintenance [11]-[12].

Replicas, storage partitions, or routes believed to be using disjoint nodes could in actuality be using a single adversary presenting multiple identities. Sybil attacks also pose a significant threat to geographic routing protocols. Location aware routing often requires nodes to exchange coordinate information with their neighbors to efficiently route geographically addressed packets. It is only reasonable to expect a node to accept but a single set of coordinates from each of its neighbors, but by using the Sybil attack an adversary can ''be in more than one place at once''.


In the wormhole attack [31], an adversary tunnels messages received in one part of the network over a low-latency link and replays them in a different part.

The simplest instance of this attack is a single node situated between two other nodes forwarding messages between the two of them. However, wormhole attacks more commonly involve two distant malicious nodes colluding to understate their distance from each other by relaying packets along an out-of-bound channel available only to the attacker.

An adversary situated close to a base station may be able to completely disrupt routing by creating a well-placed wormhole. An adversary could convince nodes who would normally be multiple hops from a base station that they are only one or two hops away via the wormhole. This can create a sinkhole: since the adversary on he other side of the wormhole can artificially provide a high quality route to the base station, potentially all traffic in the surrounding area will be drawn through it, if alternate routes are significantly less attractive. This will most likely always be the case when the endpoint of the wormhole is relatively far from a base station. Figure 2-3 above shows an example of a wormhole being used to create a sinkhole. More generally, wormholes can be used to exploit routing race conditions. A routing race condition typically arises when a node takes some action based on the first instance of a message it receives and subsequently ignores later instances of that message. In this case, an adversary may be able to exert some influence on the resulting topology if it can cause a nodes to receive certain routing information before it would normally reach them though multihop routing. Wormholes are a way to do this, and are effective even if routing information is authenticated or encrypted.

Wormholes can also be used simply to convince two distant nodes that they are neighbors by relaying packets between the two of them. Wormhole attacks would likely be used in combination with selective forwarding or eaves-dropping.

HELLO Flood Attack

Many protocols require nodes to broadcast HELLO packets to announce themselves to their neighbors, and a node receiving such a packet may assume that it is within (normal) radio range of the sender. This assumption may be false: a laptop-class attacker broadcasting routing or other information with large enough transmission power could convince every node in the network that the adversary is its neighbor.

For example, an adversary advertising a very high-quality route to the base station to every node in the network could cause a large number of nodes to attempt to use this route, but those nodes sufficiently far away from the adversary would be sending packets into oblivion. The network is left in a state of confusion. A node realizing the link to the adversary is false could be left with few options: all its neighbors might be attempting to forward packets to the adversary as well. Protocols which depend on localized information exchange between neighboring nodes for topology maintenance or flow control are also subject to this attack.

An adversary does not necessarily need to be able to construct legitimate traffic in order to use the HELLO flood attack. It can simply rebroadcast overhead packets with enough power to be received by every node in the network. HELLO floods can also be thought of as one-way. Broadcast wormholes are potentially difficult when used in conjunction with the Sybil attack.


The recent research results on data routing in sensor networks has been summarized in the table 2-1 shown below. The table shows how different routing protocols fit under different category and also compare different routing techniques according to many metrics.

From the table above, it can be concluded that none of the protocols so far developed for sensor networks are safe from attacks and neither has they provided a way to recover from attacks.

For those protocols that support mobility is by the virtue of their operation, and not that they are specifically designed keeping in view the problems created due to mobility. To cater for mobility specific fabrication is necessary at design time to maximize the efficiency of the routing protocol.

IETF [3] has presented a draft document for routing protocols in low power networks, including sensor network. It recommends that instead of designing a whole new protocol for low power networks, its best to implement a low cost version of MANET protocols. It has evaluated certain MANET routing protocols and their feasibility of implementation on sensor networks with or without modification. The metric consist of route table scalability, loss response, control traffic, link and node cost of transferring data.

The most studied of all protocols is the Adhoc On demand Distant Vector (AODV) [33] Routing Protocol. In terms of control traffic, AODV does not generate any traffic until data is sent, and as control traffic is correlated with the data, there is always less control traffic. AODV table size expands with increase in number of communicating nodes, which are always two in case of sensor networks by the virtue of operations.

However in case of loss response, the RERR message is generated to all nodes that are currently in the precursor list, which may reach those nodes that are not currently using the route to send data. In case of link cost hop count is the only metric and for node cost AODV has no mechanism to ensure node's willingness or ability to send data [3].

Chapter 3

Fault Tolerant Secure Routing in Mobile Sensor Networks


Mobility in sensor networks has not only expanded the role of sensor networks but has also given a whole new dimension to all research. Extra vigilance and unique approaches are required to address the concerns raised due to mobility. Therefore, we present a novel Fault Tolerant Secure Routing (FTSR) protocol that is not only efficient in securing routing information in hostile environment but also capable of reducing network segment errors, such that routing information is always available in the underlying network.

In this research we have modified the AODV for mobile sensor networks such that the zone heads are responsible for routing and route error response is confined to active sender zone heads only. In case of link cost the metrics consist of hop count and accumulated mobility factor along the path, and in case of node cost the zone head responsible for routing data is the one that is less mobile of all nodes in the zone and hence it has more energy left with it. Both of these factors ensure that the path selected for routing data will be available for longer duration.

The operation of FTSR is divided into three phases. First is the zone creation and zone head election. Second phase includes path discovery and maintenance mechanism to provide maximum reliability. The third phase is the fail-safe mode of operation that is only activated in case of severe network failures.

Initial Network Setup

A typical sensor network is randomly distributed nodes, across the phenomena with one or more base stations outside the phenomena. Due to the unattended operational nature of the network, it is never feasible to arrange the nodes in fix topology before hand. However, for reducing operational complexity we can have them arranged in such a manner that produce less overhead and is able to simply utilize the already available information within the node, instead of complex computation.

The FTSR protocol make use of the fact that the nodes in the network are aware of their location in the form of (x, y) coordinates. The entire sensor field is divided into M x N square zones, where M and N is an integer value. The zone size 'S' is broadcasted by Base Station and all nodes adhere to the value of 'S' while computing their membership for specific zone. Being mobile it is customary for each node to keep a record of its movements, location, and destination. In our protocol we have used this fact to facilitate the prediction of movement of the nodes in terms of a factor of mobility and remaining energy named as Mobility Factor (M.F). It has been thoroughly explained in section 3.2.2 as it plays a pivotal role throughout the network operation.

Zone Creation

Base station at the time of network setup, announces its own location and the value of 'S', besides other necessary information to the entire network like field size etc. Each node, knowing its location within the sensor field calculates the ZONE_ID of its respective zone. For example a node having location {27, 19} in a sensor field of 100 square meters with a zone size 10 square meters will have a ZONE_ID of {2,1}. As soon as the nodes finish calculating their respective zones, there is an immediate need for zone head.

Mobility Factor and Zone Head Selection

At time of initial network setup, all nodes are equal in their status in the network, that is, they have the same startup energy, they are all static and they have not been assigned any task. The first step is to calculate the mobility factor of each node. For this a node computes the number of moves made in time 't' naming Mt, and the total number of moves that resulted in a zone change naming Ct. M.F. is given as

Where e' is the remaining energy of the node at the specific time 't'. Smaller value of M.F depicts less mobility of the node and makes it a potential candidate for zone head. The larger value of M.F declares that the node is highly mobile and must not be relied as the zone head because it will soon move to another zone possibly causing a disruption in routed traffic. At the time of network setup, however, all nodes may possess the same M.F, so a random number is chosen as M.F to avoid initial perplexity.

As the node 'A' calculates the M.F, it broadcast the information along with its ZONE_ID. This information is heard by all other nodes within the broadcast range. Nodes having the different ZONE_ID immediately drop the broadcast. All other nodes within the same zone accepts this broadcast if and only if the received M.F is less than their own M.F or less than some previously received M.F.

If any node 'H' listens to the broadcast from nodes 'A', 'B', 'C' and 'D' in time 'tA', tB, tC, tD respectively and finds that its own M.F i.e. M_F(H) is less than all of the broadcast received, the node H declares itself as the ZONE_HEAD. Subsequently at its respective time 'tH' the node broadcasts its own M_F (H). All other nodes receiving the broadcast adhere to the same comparison rule. On finding M_F (H) as the least mobility factor received within time 't' seconds, the nodes declare H as their ZONE_HEAD. This procedure is adhered by all nodes and a random delay RAND_DELAY is added for each broadcast to avoid collision.

Key Exchange

After the zone head election procedure every zone ends up having a ZONE_HEAD. The ZONE_HEAD shares a group secret key with its neighbor zones i.e. not more than eight in any case as shown in figure 3-2. A pair-wise key is exchanged between each zone head and the base station.

An efficient and scalable group key management protocol is proposed for Cluster Based Mobile Sensor Networks in [32]. The protocol presents a viable key distribution and revocation scheme for sensor networks with mobile nodes. The scheme is efficient in case of nodes leaving or joining the zone.

Local Information and Connectivity

Besides other mandatory information, each node in the zone maintains the information about ZONE_ID and ZONE_HEAD_ID. Zone Head bears additional information about its neighbors and routes in the routing table.

For the sake of neighborhood knowledge each zone head keeps track of its continued connectivity to its active next hops (i.e., which next hops have forwarded packets to or from the respective zone head during the last active route timeout), as well as those neighbor zone heads that have transmitted signed Hello messages during the last (ALLOWED_HELLO_LOSS * HELLO_INTERVAL).

HELLO messages are signed by computing MAC with the group key it shares with its neighbors. MAC can be calculated using keyed hash functions [35].

ZHA à *: {IDA, IDZ, nonceA} || MAC {IDA, IDZ, nonceA}KG

Where nonce is a random number generated by ZHA. Each neighbor generates a reply to this HELLO message, including the nonceA, and computing MAC with the group key it shares with ZHA. This offers a confirmation that the link is bidirectional and prevents ZHA from accepting false HELLO replies that it has not generated.

The HELLO reply message format from ZHB, a neighbor of ZHA, is given as

CHB à CHA: {IDB, IDZ, nonceA} || MAC {IDB, IDZ, nonceA}KG

Protocol Operation

The sensor nodes deployed within the phenomena are required to report the event as soon as any activity is observed in the respective region. The data flow depends on the specification of application being used. It can be broadly divided into three categories, when a node is

  1. Static
  2. Static and at times it becomes mobile.
  3. Fully mobile (in case of target tracking application)

Whatever the case may be, the member nodes transmit data to their respective zone head, which is always one hop neighbor of all member nodes. Zone head can perform the aggregation depending on the type of application and transmit the aggregated or individual data to the base station. Route discovery, maintenance and consistent availability of route for reliable data delivery are the core responsibility of the zone head.

Whenever there is a need to transmit information to the base station the respective zone head generates the route request, which in turn is distributed across the network via some routing algorithm until it reaches the base station. The base station upon receiving the request generates a reply across the desired path and hence the route is established.

In our research, we have proposed a modified and secure version of Adhoc On-Demand Distance Vector (AODV) routing protocol. This modified version will function as the underlying routing protocol in our proposed zone based network architecture.

AODV have some core functions like RREQ, RREP and RERR for route discovery and maintenance. In the remaining of this section, first we have presented the packet formats used by FTSR protocol. Later the protocol operation is described in terms of

  • RREQ generation and its processing at intermediate nodes
  • RREP generation and its processing at intermediate nodes
  • RERR generation and dissemination

The last subsection explains the phenomena of Fail-safe mode of operation in case of severe network segment faults.

Route Request

The format for Route Request (RREQ) message for FTSR is as under.

Generating Route Requests

A zone head disseminates a RREQ when it determines that it needs a route to the base station and does not have one available. This can happen if the base station is previously unknown to the node, or if a previously valid route to the base station expires or is marked as invalid. The Destination Sequence Number field in the RREQ message is the last known destination sequence number for the base station and is copied from the Destination Sequence Number field in the routing table. If no sequence number is known, the field is initialized to zero.

The Originator Sequence Number in the RREQ message is the zone heads' own sequence number, which is incremented prior to insertion in a RREQ. The Originator Zone ID is the zone in which the originator of the RREQ exists. The advantage of using the Zone ID has been further described in section 4.2. The RREQ ID field is incremented by one from the last RREQ ID used by the current zone head. Each zone head maintains only one RREQ ID. The Hop Count field is set to zero. A Message Authentication Code (MAC) is calculated over all non-mutable fields of RREQ using the unique key the zone head shares with the base station. A keyed hash function can be used to calculate the MAC.

  1. Before broadcasting the RREQ, the originating zone head buffers the RREQ ID and the Originator NODE_ID (its own address), Originator ZONE_ID (its own zone id) and MAC of the RREQ for PATH_DISCOVERY_TIME. In this way, when the node receives the packet again from its neighbors, it will not reprocess and re-forward the packet.
  2. A node can not originate more than RREQ_RATELIMIT request messages per second.
  3. After broadcasting a RREQ, the zone head waits for a RREP (or other control message with current information regarding a route to the base station).
  4. If a route is not received within NET_TRAVERSAL_TIME milliseconds, the zone head tries again to discover a route by broadcasting another RREQ, up to a maximum of RREQ_RETRIES times at the maximum TTL value. The Originator Zone Head increments and update the RREQ ID for each new RREQ.

The method of sending RREQ retries is comprehensively modified from the normal AODV operation. Therefore it makes up the major component of FTSR Fail-safe mode of operation and is fully elaborated in section 3.4.

3.3.5 Processing and Forwarding Route Requests

When a node receives a RREQ, it first verifies the neighbor from its neighbor's list and creates or updates a route to the previous hop, then checks to determine whether it has received a RREQ with the same Originator Node ID and RREQ ID within at least the last PATH_DISCOVERY_TIME. If such a RREQ has been received, the node silently discards the newly received RREQ. The rest of this subsection describes actions taken for RREQs that are not discarded. First, it first increments the hop count value in the RREQ by one, to account for the new hop through the intermediate node. Then the node searches for a reverse route to the Originator Node ID. If need be, the route is created, or updated using the Originator Sequence Number from the RREQ in its routing table. This reverse route will be needed if the node receives a RREP back to the node that originated the RREQ. When the reverse route is created or updated, the following actions on the route are also carried out,

  1. The Originator Sequence Number from the RREQ is compared to the corresponding destination sequence number in the route table entry and copied if greater than the existing value there.
  2. The valid sequence number field is set to true.
  3. The next hop in the routing table becomes the node from which the RREQ was received (may not be equal to the Originator IP Address field in the RREQ message).
  4. The hop count is copied from the Hop Count in the RREQ message.

Whenever a RREQ message is received, the Lifetime of the reverse route entry for the Originator IP address is set to be the maximum of (ExistingLifetime, MinimalLifetime), where MinimalLifetime = (current time + 2 * NET_TRAVERSAL_TIME - 2 * HopCount * NODE_TRAVERSAL_TIME).

If the incoming packet has TTL larger than 1, the node updates and broadcasts the RREQ. To update the RREQ, the TTL or hop limit field in the outgoing packet is decreased by one, and the Hop Count field in the RREQ message is incremented by one, to account for the new hop through the intermediate node. Lastly, the Destination Sequence number for the Base Station is set to the maximum of the corresponding value received in the RREQ message, and the destination sequence value currently maintained by the node for the Base station.

Generating Route Replies

Contrary to the normal operation of AODV, the FTSR protocol modifies the generation of RREP as intermediate zone heads are not allowed to generate RREP in any case. The advantage of forcing this restriction is described in section 4.3. When the RREQ reaches the base station, the base station verifies the sender from its neighbor list and establishes a reverse route with the sender. Afterwards it computes MAC over the non-mutable fields of RREQ with the key it shares with the Originator node and compares it with the MAC received within the RREQ. In case of any discrepancy the RREQ is immediately discarded. Otherwise, upon successful comparison the base station gets ready to generate the RREP.

When generating a RREP message, the base station copies the Destination Node ID (its own ID as received in RREQ) and the Originator Sequence Number from the RREQ message into the corresponding fields in the RREP message.

The base station places its sequence number into the Destination Sequence Number field of the RREP, enters the value zero in the Hop Count field of the RREP and copies the value MY_ROUTE_TIMEOUT into the Lifetime field of the RREP.

After all this, the base station computes the MAC over the non-mutable fields of RREP, using the key it shares with the Originator and concatenate it with the RREP.

Once created, the RREP is unicast to the next hop toward the originator of the RREQ, as indicated by the route table entry for that originator. As the RREP is forwarded back towards the node which originated the RREQ message, the Hop Count field is incremented by one at each hop. Thus, when the RREP reaches the originator, the Hop Count represents the distance, in hops, of the destination from the originator.

Receiving and Forwarding Route Replies

When an intermediate node receives a RREP message, it verifies the sender by its neighbor list. Upon knowing that the sender is a verified neighbor and the intermediate node maintains a secure local connectivity with it, the node start processing the RREP and searches for a route to the previous hop. If needed, a route is created for the previous hop, but without a valid sequence number. Next, the node then increments the hop-count value in the RREP by one, to account for the new hop through the intermediate node. Call this incremented value the "New Hop Count".

Then the forward route for the base station is created if it does not already exist. Otherwise, the node compares the Destination Sequence Number in the message with its own stored destination sequence number for the Destination Node ID in the RREP message. Upon comparison, the existing entry is updated only in the following circumstances:

  1. The sequence number in the routing table is marked as invalid in route table entry.
  2. The Destination Sequence Number in the RREP is greater than the node's copy of the destination sequence number and the known value is valid, or
  3. The sequence numbers are the same, but the route is marked as inactive, or
  4. The sequence numbers are the same, and the New Hop Count is smaller than the hop count in route table entry.

If the route table entry to the destination is created or updated, then the following actions occur:

  • The route is marked as active.
  • The destination sequence number is marked as valid.
  • The next hop in the route entry is assigned to be the node from which the RREP is received,
  • The hop count is set to the value of the New Hop Count,
  • The expiry time is set to the current time plus the value of the Lifetime in the RREP message,
  • And the destination sequence number is the Destination Sequence Number in the RREP message.

The current node can subsequently use this route to forward data packets to the destination. If the current node is not the node indicated by the Originator Node ID in the RREP message AND a forward route has been created or updated as described above, the node consults its route table entry for the originating node to determine the next hop for the RREP packet, and then forwards the RREP towards the originator using the information in that route table entry.

Also at each node the (reverse) route used to forward a RREP has its lifetime changed to be the maximum of (existing-lifetime, (current time + ACTIVE_ROUTE_TIMEOUT).

Route Error (RERR) Messages, Route Expiry and Route Deletion

Generally, route error and link breakage processing requires the following steps:

  • Invalidating existing routes
  • Determining which, if any, neighbors may be affected
  • Delivering an appropriate RERR to such neighbors

In sensor networks, links routinely come and go due to being close to the SNR threshold. In case of MSN topology changes are more frequent. It is important that link flapping not trigger unnecessary responses by the routing protocol. This point is stressed in all the application requirement documents, pointing to the need to localize response to link failures with no triggering of global network re-optimization, whether for reducing traffic or for maintaining low route convergence times. The routing requirements draft states that protocols must be able to "recomputed paths based on underlying link characteristics which may change dynamically". The protocol should also "always be in the process of optimizing the system in response to changing link statistics." Protocols with these properties should take care not to require global updates.

Although, AODV has been developed for Mobile Adhoc Networks, however it performs best when the nodes are static or mobile to a limited extent. There are intense performance issues with AODV when it comes to loss response and error reporting. When routes break due to topology changes, AODV floods error messages and issues a new request. Because AODV is on-demand it only maintains routes for active nodes. When a link breaks, AODV issues a Route Error (RERR) and a new route request message (RREQ), with a higher sequence number so nodes do not respond from their route caches. These packets can flood the entire network, giving loss response a fail and hence can not be implemented in sensor networks without modification.

In FTSR, we have anticipated a finer version of loss response and error reporting mechanism. Thus, reducing the overall cost of error, and restricting the propagation of error message across the entire network. The zone head initiates processing for a RERR message in three situations:

  1. If it detects a link break for the next hop of an active route in its routing table while transmitting data and has waited (MAX_HELLO_LOSS x HELLO_INTERVAL) (and route repair, if attempted, was unsuccessful) or
  2. If it gets a data packet destined to a node for which it does not have an active route and is not repairing, or
  3. If it receives a RERR from a neighbor for one or more active routes.

Suppose that ZHS is using a link disjoint path to deliver data to BS.


Link break occurred at this path between ZHB à ZHC. There are two possible causes

ZHC is dead, possible reason being battery starvation.

  • Immediate local repair MUST occur at Zone level. The member nodes upon receiving link layer error message for their connectivity loss to the zone head initiate the Zone Head election procedure as described in section (3.2.2) always followed by 3.2.3. The new Zone Head will immediately broadcast HELLO packet to inform its availability.
  • Meanwhile, ZHB buffers the incoming packets, unicast RERR destined for Originator(s) with 'Route in Repair' Flag set to its previous hop(s) towards the Originator(s) currently using the route to send data, so that they can stop transmitting the data. In our example case this is ZHA which first receives the error message.
  • The maximum time for selecting a new Zone Head in Zone 'C' MUST NOT exceeds (MAX_HELLO_LOSS x HELLO_INTERVAL).
  • Link restoration leads to route update at ZHB. Buffered packets will be sent to the base station. ZHB unicast RERR with 'Route Restored' flag to Originator(s) via reverse path to restore data transmission.
  • In case the path is not repaired within (MAX_HELLO_LOSS x HELLO_INTERVAL), the route will be marked as invalid and ZHB will initiate path discovery.

ZHC has moved out of range from ZHB but is still in range with its member nodes. In this case there will be no initiation of Zone Head election procedure.

  • ZHB buffers the incoming packets, unicast RERR destined to Originator(s) with 'Route in Repair' Flag set to its previous hop(s) towards the Originator(s) currently using the route to send data, so that they can stop transmitting the data. In our example case this is ZHA which first receives the error message.
  • In case the path is not repaired i.e. the ZHC does not come back in range within (MAX_HELLO_LOSS x HELLO_INTERVAL) time, route request is issued by ZHB that is the intermediate node towards the Originator. Path is updated at ZHB as the link is restored.

Link restoration leads to route update at both ZHB and ZHD. Buffered packets will be sent to the base station and ZHB unicast RERR with 'Route Restored' flag to Originator(s) via reverse path to restore data transmission.

Fail-safe mode of operation

Data transmission in sensor networks only happens whenever an activity is detected within a region or for reporting results for a task disseminated by the sink. The flow of this data transmission is always unidirectional i.e. from nodes towards the base station. Sensor networks, being low on resources, avoid using costly acknowledgements for any kind of packet transmission.

This section explains the Fail-safe mode of FTSR protocol. This mode is defined to overcome the effect of severe network segment errors and to ensure reliable data delivery path even in the case of network faults. This mode augments the zone based fault tolerance functionality of FTSR protocol.

In the case of mobile nodes, the nodes move frequently resulting in topology changes. Although the zoning mechanism reduces the effects of mobility by containing the topology changes with respect to zone heads only.

However their might be a chance in a less denser network that a zone head is unable to communicate with its neighbors due to empty zones or just in case that a zone head goes out of range with its only neighbor. So the zone head might fail, either to transmit its own data or be a part of its neighbor's route to which it is the only serving zone head in the path.

So, it is possible that a RREQ transmission never reaches the base station. Normal AODV uses the method of "expanding ring search" [33] in which it increases the TTL value and the node density parameters for repeat RREQs. This mechanism can not be utilized in our zone based mobile network, because our protocol does not depend on network density. Instead we mainly focus on non-empty zones with nodes as least as one.

Generating RREQ in Fail-safe Mode

If no RREP generated from the same route discovery attempt reaches the zone head which originated the RREQ message, the originator reattempts route discovery after a timeout (description in section 3.3.4). However, the same scenario might well be repeated without any improvement, and no route would be discovered even after repeated retries. Unless corrective action is taken, this can happen infinitely and may leave the network in a perplexed state.

Our zone based approach uses a fail-safe mode of operation, in case when a zone head is unable to receive a RREP. The originator keeps track of the number of times the RREQ is generated and is depicted a 'k'. Maximum value of k is 4 after which the originator gives up retrying.

For k > 1 generating an RREQ is somewhat different from that of k=1 and hence the processing at intermediate nodes also varies.

Before generating the RREQ retry, i.e. k > 1, the sequence number and RREQ_ID is updated as described in section (3.3.1). Flag 'F' is set to on, depicting the operation over fail-safe mode. The originator zone head fills the reserved field with its own calculated mobility factor. Originator zone id, Originator node ID, Originator sequence number, destination ID, destination sequence number and Hop count are filled the same way as in normal operating condition. Message authentication code is calculated the same way without including the 'Reserved' field, as it contains mutable value, which is going to change at every hop. The RREQ is then broadcasted by the originator.

Each intermediate node, whether, member or zone head processes the RREQ with F flag set to on.

Processing RREQ at Intermediate Nodes

When a node receives a RREQ retry, it first checks to determine whether it has received a RREQ retry with the same Originator IP Address and RREQ ID within at least the last PATH_DISCOVERY_TIME. If such a RREQ has been received, the node compares the received mobility factor with the one already stored against the same RREQ ID and Originator Node ID. Regardless of the hop count, as in normal mode, if the mobility factor is the greater than the one, if present already in the route table the RREQ is discarded silently.

The rest of this subsection describes actions taken for RREQs that are not discarded. If, however the node has received the only RREQ retry or the RREQ retry is with lesser mobility factor than the one already present in the reverse routing table, it creates or updates a reverse route to the previous hop, respectively.

It now process the RREQ and increments the hop count field in the RREQ by one. Adds up the M.F value in received RREQ with its own mobility factor and replaces it in the RREQ, such that the M.F field in the RREQ now contains the sum of both the received M.F and its own M.F.

The rest of the operation related to life timer, sequence number and TTL values is the same as in normal mode and the RREQ is then broadcasted with its F flag set to on.

Generating Route Replies

When the RREQ reaches the destination, it contains the mobility factor accumulated across the entire path. This factor is copied to the routing table of destination, but only if the RREQ is accepted based on the fulfillment of the criteria. The criteria and procedure for generating route replies in fail-safe mode is the same as in normal mode of operation described in sections 3.3.6. However, the routing table for the destination now contains another field containing the value of the accumulated mobility factor across the entire path.

The base station generates the RREP the same way as normal mode defined in section 3.3.6, except the fact that the 'F' flag is set to on and the reserved field is filled with the mobility factor of the destination. Once created the RREP is unicast to the next hop towards the Originator.

Receiving and Forwarding Route Replies

When an intermediate node receives an RREP with 'F' flag set to on, it adhere to the same procedure of processing RREPs as described in section 3.3.6. However, with one exception that the mobility factor is accumulated on each hop. Thus, when the RREP reaches the originator of RREQ, it contains the value of accumulated mobility factor across the entire path. The Originator node copies the same to its routing table along with other information for the base station.

The rest of the procedure is adhered without any change and thus the node ends up with a route towards the base station that has the least mobility factor among all the possible routes.

The detailed impact of including mobility factor and depending solely on it for generating RREP in fail-safe mode is discussed further in section 4.2. However, briefly it can be said that the lesser mobility factor guarantees the involvement of more zone heads across the path, which in turn means that the path will be stable for longer duration of time.

Route error and route maintenance follow the same procedure as described for the normal mode of operation.

Chapter 4

Security and Fault Tolerance Analysis


We analyze the performance of FTSR protocol with respect to the diversity of features it offers. First we look at the fault tolerant aspect, secondly an analysis of fail-safe mode of operation and at last a detailed overview of the security features it offers.

Fault Tolerance

The zone based approach used over the under lying routing protocol and the error control and repair mechanism adds a multi dimensional fault tolerant aspect to our proposed solution.

Mobile networks undergo far more frequent link breaks than normal static networks. Movement of any node, whether it is the Originator of data or a node serving as intermediate node in the route to base station result in tremendous amount of control traffic for finding the new route to the base station.

Our aim is to manage mobility in such a way that it effects the routing information present in the network to the smallest extent. Also, network performance can be improved if somehow we manage to integrate the cost of our route to the base station with the mobility and remaining energy.

In FTSR, zone head is responsible for aggregating and routing data to base station. All nodes present in a specific zone reports their sensed data to the zone head. The election criteria suggest that the zone head must be the one with least zone changes and maximum remaining energy at time 't' seconds. This predicts that the node elected as the zone head will be serving the respective zone for more time than other nodes in the zone.

Once elected, the zone head is the one that is responsible for handling all the control information to and from other zones and member nodes don't participate in path finding algorithm, except in fail-safe mode of operation.

Movement of member nodes inside the entire network, which ever zone they belong to, does not in any case affect the routes to the base station. The only concern they raise is their securely leaving and joining the zones, whether reporting data or merely sensing it. A change in zone always results in an inquiry by the member node for the new zone head. As the member node is always reporting its zone head, so a change in zone head is sufficient to conclude that now the sensed data will be directed to the new one. Member nodes have no concern how their data reaches the base station and are neither concerned nor involved how others are sending their data. Therefore we can safely conclude that movement of member nodes does not, in any case, affects the routes in the network.

Zone head movement, however is likely to affect the under lying routes as they are the mainstay of our entire network. However, this problem is somewhat limited by choosing the least mobile node as the zone head. Secondly FTSR protocol is zone based instead of node based. That is, all control information and data is intended for the zone and not any specific node and zone head is the one responsible for responding and/or replaying that information. So it does not concern our information which node is serving as the zone head, as long as there is one in the zone.

Incase of zone head movement that results in a zone change; the zone head send a BYE message informing its member nodes about its departure. This message is an indication that the sender zone head is no longer available to serve as an aggregator, and router in case, for the respective zone. The member nodes upon receiving the message initiate zone head discovery and a new zone head is elected by the procedure defined in section 3.2.2 .The previous zone head, which has now joined a new zone and is now considered as a member node, broadcast an inquiry packet with its new zone id. The zone head of the respective zone, upon receipt of this inquiry informs the node about its id and other necessary information which may be required for zone membership. Cryptographic key revocation and exchange for this entire procedure takes place as described in [32].

In any circumstances, else than the one that it is the only node in the zone, the new entering zone can not be the zone head at this time how ever less mobility factor it own. This has strong implications on security as we will see in the next section. This procedure explicitly indicates that as long as the zone contains at least one node, the zone can be a part of routing protocol.

Security Analysis

In this section we analyze the performance of FTSR protocol in terms of reliability and security and show that FTSR protocol is fully reliable, with lowest possible overhead.

Spoofed Altered Or Replayed Routing Information

The most basic form of attack is expected by spoofing, altering, or replaying routing information, so that the malicious nodes is able to create routing loops, draw or repel network traffic, generate false error messages etc.

However, monotonically increasing sequence number system and its inclusion in the calculating MAC in FTSR does not allow the adversary to hold the control packet, change the sequence number and make false use of it after a while.

HELLO Flood Attack

Hello flood attack is mounted by an adversary with powerful transmission capabilities. It broadcasts false HELLO packets in the network and hence convinces the nodes that the adversary is its neighbor.

Hello flood attacks can be defended by verifying the bi-directionality of the link before taking any action on the received message [4]. FTSR uses a random value noncei in HELLO messages and confirm the bi-directionality of the link by only accepting those replies that include the random number previously sent, otherwise the message is discarded and no action taken.

Sink Hole Attack

Malicious nodes lure traffic that it has a high quality route to the base station. Combined with selective forwarding attack it can be successful and undetectable [4].

However the FTSR protocol offers a complete defense against sinkhole attack, by the fact that a RREP is never generated by the intermediate node. The source node will verify the RREP by calculating the MAC on immutable fields with the key that it shares with the base station and in case of any discrepancy, immediately discards the packet.

Sybil Attack

In a Sybil attack, a single node presents multiple identities to other nodes in the network. The Sybil attack can significantly reduce the effectiveness of multi-path routing, or routes believed to be using disjoint nodes could in actuality be using a single adversary presenting multiple identities [4].

FTSR makes use of the fact that each node shares a unique key with the base station and a group key shared among its neighbors. The square zone based structure restricts any cluster head to accept pairing requests after a maximum neighborhood limit is achieved that is eight. Thus the Sybil attack is infeasible and difficult to mount against our FTSR protocol.

Chapter 5

Implementation and Results


This chapter provides a brief description of the working of the simulator tool (NS-2) used to simulate the FTSR protocol. The protocol is tested for various network scenarios and results are verified and compared to normal AODV in the end. We have graphically shown that FTSR is much more efficient than normal AODV operation despite of overhead caused due to zoning and security features.

Simulator (Network Simulator-2)

Simulator is an important tool in the development of network algorithms. It provides an excellent environment to experiment and verify routing protocol correctness. However, simulation does not guarantee that the protocol works up in practice to that extent projected in simulation. However the main objective of any simulation is to study and analyze new ideas in detail before implementation.

The NS-2 network simulator is a powerful tool. It is a discrete event network simulator. It is popular in academia for its extendibility as it is an open source model. Another advantage for using this simulator is the online availability of its manual and documentation along side a plenty of support forums. NS supports an array of popular network protocols, offering its simulation results for wired and wireless network models. NS-2 is the second major iteration of a discrete-event simulation platform programmed in C++ and Object Tcl (OTcl). NS-2 was first released in 1996, and derives from the earlier work on the REAL and NS-1 simulator. The simulator structure uses two languages: OTcl scripting at the front end and C++ on the back end.

OTcl scripting is used to make a simulation scenario, which may include network components like nodes, router and link bandwidth.

C++ is used in the back end, for instance, for conducting AODV routing simulation, the relevant AODV C++ files (i.e. aodv.cc, aodv.h, etc) has to be enabled in OTcl code. The OTcl code links to C++ files, so when the OTcl code runs, it calls the relevant C++ code to execute a particular task.

NS-2 Compatibility

The software has been designed to work under Linux environment but it can be made to run on Windows XP by using Linux emulator tool specifically Cygwin. There are no strict hardware requirements, using a high end platform will result in faster processing. We have used ns-2.33 with Cygwin on top of windows XP, for the ease of usability.

Trace Files

Results of ns-2 simulation are shown in a tabular form called trace file. One line in trace file is produced for each packet that travel from the initiating node to the terminating node and the trace file record every parameter of the transmitted data packet, including the size, start time, type, time to live, starting node, and end node. It is also noted that the packet is unicast or multicast.

NS-2 generates huge trace files which could be as big as 100 MB and showing results of simulation of just few minute. This gives the major disadvantage of using NS-2 as it does not provide any tools for getting results. It simply simulates a network, and provides a trace file of all the events that occur in sequential order. Therefore to get required output, separate tools are required to parse through trace file, commonly Pearl and AWK commands are used.

The Network Animator

NAM is a Tcl/TK based animation tool for viewing network simulation trace and real world packet traces. It is mainly intended as a companion animator to the NS simulator. It supports topology layout, packet level animation and various data inspection tools. Since ns-2 provides limited ability to view the animation after the simulation, a separate program Network Animator (NAM) makes it possible. NAM also can record the animation in the form of graphics as the simulation progress. These graphics can then be converted to GIF or AVI format for later viewing.

Simulated Network Scenario

The FTSR protocol is tested for different scenarios with different network settings. As the sensor network is typically composed of sensor nodes scattered in a region and a base station one end of the field the base station is supposed to be static and the nodes possess both fixed and random mobility pattern.

The region used in our simulation is 100 x 100 and 200 x 200 with varying node density from 100 to 300 nodes. Out of these nodes data sending nodes are 1, 10, 20, and 50 for all network scenarios. Each node possesses 2 joules of initial energy and the radio transmission range of each node is 20 meters. The protocol is both tested for static and mobile network.

The proposed algorithm is tested for zone size of 10m x 10m and 20m x 20m against the normal AODV routing protocol using various mobility patterns. The mobility in each scenario is considered to be no more than 40 percent of the network population with nodes moving at the speed of 10 km/h sending data at the rate of 1.280 kbps. We have simulated a real time scenario in which the target is observed in an area and all nodes in the radius of 5m of this target follow the target across the entire field. The object's location and movement information is needed to be delivered to the base station continuously and reliably. The scope of this simulation is limited to zoning, reliable path creation, maintenance and assurance of path availability in worst case scenario for FTSR protocol. It has not included the information that node has to send inside a data packet to the base station.

The comparison between AODV and FTSR in terms of number of RREQs generated across the static network of 100, 200 and 300 nodes has been shown in figure 5-1 to 5-3. The number of data sending nodes has taken to be 1, 10, 25 and 50 in each network with an exception of skipping data nodes in 100 nodes network. The graphs has clearly elaborated that FTSR has generated less number of route request across the entire network. Also it is obvious from the graphs that FTSR is scalable in terms of node density and has performed well in dense environments.

The below graph elaborates the comparison of energy consumption of both AODV and FTSR. It is clear from the graph that in FTSR, we have less energy consumption as compared to AODV. Despite the fact that FTSR consumes extra energy at initialization phase for zone creation, the total network energy consumption at the end of simulation is less than AODV due to lesser number of RREQs generated.

The simulated results for a network of mobile nodes have been shown in the figure 5-7 to figure 5-9. The graphs have been drawn for total number of route requests generated in case of 100, 200 and 300 nodes with 40% nodes being mobile. The graphs show a comparison of AODV, FTSR with normal zone size of 10m and FTSR in case of increased zone size equal to the normal radio range of a node that is 20m so that the zone head are unable to communicate directly to the neighboring zone head and therefore have to activate the fail-safe mode of FTSR.

Chapter 6



The infrastructure free and tiny node size of sensors makes them more versatile but their constraints and limitations demand for more ingenious developments. Mobility introduces more serious constraints on these networks as movement within network directly affects the topology and protocols like aggregation, key exchange, routing etc. AODV routing protocol, primarily designed for MANETs is considered suitable for implementation in sensor networks but with little modification.

In this thesis we have proposed the modification in AODV routing protocol as one of the three major objectives of this research. Securing the routing information in network due to their deployment in hostile areas and recovering from network failures are the two other concerns focused in this research.

This thesis introduces the concept of zones in the sensor network. The zoning algorithm improves the efficiency of the underlying routing protocol as is evident from the analysis. Also it helps to cater mobility as member nodes leaving or joining the zone never affects the routing table. The error reporting mechanism is so defined to stop the error messages from spreading across the entire network and making global changes. The control messages are attached with hashed message authentication code that proves vital in the security specifically availability of the routing information in the under lying network. This research work is an endeavor to make the AODV protocol more adaptable and effiecient in sensor network environment where nodes behaviour is unpredictable due to mobility.

The proposed solution has been analyzed for its practicability. The effectiveness of the solution has also been verified through simulation carried out on NS-2. The proposed solution does not require any additional hardware and can be equally implemented in both the source and intermediate nodes. The solution is most effective in dense environments where node population is congested. We have seen in the simulated results that performance of FTSR is not a factor of node density; instead it is dependant on zone size and number of zones within the network.


The research objectives set forth during the initial phases have been accomplished. The desired modifications and enhancement in the protocol to fit the needs of mobile sensor networks has been made and desired outcome has been received. A detailed analysis of proposed protocol has been carried out that can serve as the starting point for finding more solutions to the problem.


Verification through simulation is an important step during research and development, which has been achieved. But there is no substitute to live testing that can only be carried out with actual sensor nodes. The solution proposes enhancement of firmware implemented protocol; as a major part of research, therefore actual implementation cannot be done without vendor support.

Future Work

This thesis has presented enhancement for AODV routing protocol only. However the strategy of partitioning our network of mobile nodes into zones is independent of underlying protocol. Fail-safe mode can also be made efficient in terms of energy consumption.


  1. "Wireless sensor networks" http://en.wikipedia.org/wiki/Sensor_network.
  2. J.K. Hart, K. Martinez, "Environmental Sensor Networks: A revolution in the earth system science", Earth-Science Reviews, 78. pp. 177-191.2006.
  3. P. Levis, A, Tavakoli, "Overview of Existing Routing Protocols for Low Power and Lossy Networks". Draft-ietf-roll-protocols-survey-02.txt (2008).
  4. C. Karlof, D.Wagner, "Secure routing in wireless sensor networks: attacks and countermeasures," Proceedings of the IEEE International Workshop on Sensor Network Protocols and Applications, pp. 113-127, May 2003.
  5. F. Ye, A. Chen, S. Lu, L. Zhang, "A scalable solution to minimum cost forwarding in large sensor networks," in Tenth International Conference on Computer Communications and Networks, 2001, pp. 304-309.
  6. F. Ye, S. Lu, L. Zhang, "GRAdient broadcast: a robust, long-live large sensor network," Tech. Rep., Computer Science Department, University of California at Los Angeles, 2001.
  7. W.R. Heinzelman, A. Chandrakasan, H. Balakrishnan, "Energy-efficient communication protocol for wireless micro-sensor networks," in: 33rd Annual Hawaii International Conference on System Sciences, 2000, pp. 3005-3014.
  8. D. Braginsky, D. Estrin, "Rumor routing algorithm for sensor networks," in First ACM International Workshop on Wireless Sensor Networks and Applications, 2002.
  9. L. Li, J. Halpern, Z. Haas, "Gossip-based ad hoc routing," in: IEEE Infocom 2002, 2002
  10. C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed diffusion: a scalable and robust communication paradigm for sensor networks," in Proceedings of the sixth Annual International Conference on Mobile Computing and Networks (Mobi-COM '00), 2000.
  11. Y. Xu, J. Heidemann, D. Estrin, Geography-informed energy conservation for ad hoc routing, in: Proceedings of the Seventh Annual ACM/IEEE International Conference on Mobile Computing and Networking, 2001.
  12. B. Chen, K. Jamieson, H. Balakrishnan, R. Morris, "Span: an energy-efficient coordination algorithm for topology maintenance in ad hoc wireless networks," ACM Wireless Networks Journal 8 (5) (2002) 481-494.
  13. L. Zhou, Z. Haas, Securing ad hoc networks, IEEE Network Magazine 13 (6) (1999) 24-30.
  14. J. Hubaux, L. Buttyan, S. Capkun, The quest for security in mobile ad hoc networks, in: Proceedings of the ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHOC 2001), 2001.
  15. J. Kong, P. Zerfos, H. Luo, S. Lu, L. Zhang, Providing robust and ubiquitous security support for mobile ad-hoc networks, in: ICNP, 2001, pp. 251-260.
  16. Y.-C. Hu, D.B. Johnson, A. Perrig, "SEAD: secure efficient distance vector routing for mobile wireless ad hoc networks," in: Proceedings of the 4th IEEE Workshop on Mobile Computing Systems and Applications (WMCSA 2002), 2002, pp. 3-13.
  17. Y.-C. Hu, A. Perrig, D.B. Johnson, Ariadne: a secure on-demand routing protocol for ad hoc networks, in: MOBICOM, 2002.
  18. S. Basagni, K. Herrin, E. Rosti, D. Bruschi, Secure pebblenets, in: ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), 2001, pp. 156-163.
  19. P. Papadimitratos, Z. Haas, Secure routing for mobile ad hoc networks, in: SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), 2002.
  20. S. Marti, T.J. Giuli, K. Lai, M. Baker, Mitigating routing misbehavior in mobile ad hoc networks, in: Sixth Annual ACM/IEEE International Conference on Mobile Computing and Networking, 2000, pp. 255-265.
  21. S. Buchegger, J.-Y.L. Boudec, Nodes bearing grudges towards routing security, fairness, and robustness in mobile ad hoc networks, in: Proceedings of the Tenth Euromicro Workshop on Parallel, Distributed and Network based Processing, IEEE Computer Society, Canary Islands, Spain, 2002, pp. 403-410.
  22. A. Perrig, R. Szewczyk, V. Wen, D. Culler, J. Tygar, SPINS: security protocols for sensor networks, in: Proceedings of Mobile Networking and Computing 2001, 2001.
  23. A. Demers, S. Shenker, V. Bhargavan, L. Zhang,Macaw: a media access protocol for wireless lans, in: ACM SigComm '94, 1994.
  24. R.L. Pickholtz, D.L. Schilling, L.B. Milstein, Theory of spread spectrum communications--a tutorial, IEEE Transactions on Communications 20 (5) (1982) 855-884.
  25. N. Abramson, The ALOHA system--another alternative for computer communications, in: Proceedings of the Fall 1970 AFIPS Computer Conference, 1970, pp. 281-285.
  26. M. Blum, S. Micali, A simple unpredictable pseudo-random number generator, SIAM Journal of Computing 15 (2) (1986) 364-383.
  27. J.R. Douceur, "The Sybil attack," in: 1st International Workshop on Peer-to-Peer Systems (IPTPS '02), 2002.
  28. M. Castro, B. Liskov, Practical byzantine fault tolerance, in: OSDI: Symposium on Operating Systems Design and Implementation, USENIX Association, Co-sponsored by IEEE TCOS and ACM SIGOPS, 1999.
  29. A. Banerjea, A taxonomy of dispersity routing schemes for fault tolerant real-time channels, in: Proceedings of EC-MAST, vol. 26, 1996, pp. 129-148.
  30. K. Ishida, Y. Kakuda, T. Kikuno, A routing protocol for finding two node-disjoint paths in computer networks, in: International Conference on Network Protocols, 1992, pp. 340-347.
  31. Y.-C. Hu, A. Perrig, D.B. Johnson, Packet leashes: a defense against wormhole attacks in wireless networks, in: IEEE Infocom, 2003.
  32. Sultana, N., Choi, K.M., Huh, E.N.: Application Driven Cluster Based Group Key Management with Identifier in Mobile Wireless Sensor Network. In: Future generation communication and networking (fgcn 2007), vol.1, no., pp.362-367, 6-8 Dec. 2007.
  33. Perkins, C., Belding-Royer, E., Das, S.R.: Ad hoc On-Demand Distance Vector (AODV) routing. rfc3561.txt (2003).
  34. Niculescu, D., Nathi, B.: Ad hoc Positioning System (APS). IEEE INFOCOM 2003. San Francisco, CA. 2003.
  35. Krawczyk, H., Bellare, M., Canetti, R.: HMAC: Keyed-Hashing for Message Authentication. rfc2104.txt (1997)