Reliable Routing In Mobile Ad Computer Science Essay

Published Date: 02 Nov 2017

Hoc Networks

Zhenqiang Ye, Srikanth V. Krishnamurthy, Satish K. Tripathi

Abstract—Mobile ad hoc networks consist of nodes that are often

vulnerable to failure. As such, it is important to provide redundancy

in terms of providing multiple node-disjoint paths from a source to

a destination. We first propose a modified version of the popular

AODV protocol that allows us to discover multiple node-disjoint

paths from a source to a destination. We find that very few of such

paths can be found. Furthermore, as distances between sources and

destinations increase, bottlenecks inevitably occur and thus, the pos-

sibility of finding multiple paths is considerably reduced. We con-

clude that it is necessary to place what we call reliable nodes (in

terms of both being robust to failure and being secure) in the net-

work for efficient operations. We propose a deployment strategy

that determines the positions and the trajectories of these reliable

nodes such that we can achieve a framework for reliably routing in-

formation. We define a notion of a reliable path which is made up of

multiple segments, each of which either entirely consists of reliable

nodes, or contains a preset number of multiple paths between the

end points of the segment. We show that the probability of establish-

ing a reliable path between a random source and destination pair

increases considerably even with a low percentage of reliable nodes

when we control their positions and trajectories in accordance with

our algorithm.

I. introduction

Mobile ad hoc networks find application in many fields such as

military deployments, disaster rescue missions, electronic class-

rooms. In this paper, we primarily look at reliability in terms of

providing robustness to node failures in ad hoc networks. Node

failures may be intermittent, i.e., for short periods or for long

periods of time, and due to various reasons. First, since these

networks are likely to be deployed in wireless environments, the

communications between the ad hoc nodes will have to be via

a harsh fading channel. Thus, communications between nodes

would typically endure periods of intermittent failure and as a

consequence, packet losses. It is possible that certain nodes might

completely lose connectivity for temporary periods due to the

fading conditions. One way of overcoming this would be to use

sophisticated antenna systems or modulation methods. However,

many of the ad hoc nodes, if not most of them, would be con-

strained by size, processing and power limitations and thus, may

not possess such capabilities. Second, many of the ad hoc nodes

are power constrained. Due to battery drain, it is possible that

some of these nodes might not be able to function. Such an effect

This work was supported by DARPA under contract number: FTN F30602-01-

2-0535.

Zhenqiang Ye is with the Electrical Engineering Department, University of

California, Riverside. E-mail:[email protected].

Srikanth V. Krishnamurthy and Satish K. Tripathi are with the Department of

Computer Science and Engineering, University of California, Riverside. E-mail:

{krish, tripathi }@cs.ucr.edu.

0-7803-7753-2/03/$17.00 (C) 2003 IEEE

may result in a long term failure if a node's battery is completely

drained or if it is possible to re-charge the node's battery, the node

might not function for intermittent short periods. Third, nodes in

an ad hoc network are vulnerable to compromise. Compromises

are especially likely for unattended sensor nodes or handhelds

carried by pedestrians. A simple form of denial of service is to

simply cause node failures, either intermittent or long term.

Multipath routing is one way of improving the reliability of

the transmitted information. While multipath routing may be

used for various other reasons such as load-balancing, conges-

tion avoidance, lower frequency of route inquiries and to achieve

a lower overall routing overhead [1][2][3][4][5], our objective is

to primarily design a multipath routing framework for providing

enhanced robustness to node failures. If one could provide mul-

tiple paths from a source to a destination, one could envision the

transmission of redundant information on the various paths (by

the use of known techniques such as diversity encoding [6]) that

would help the receiver in reconstructing the transmitted infor-

mation even if a few of the paths were to fail. By multiple paths,

we imply multiple node-disjoint routes from a source node to a

destination node. Our first goal towards this is to design a routing

protocol that would allow us to find multiple node-disjoint paths

from a given source to a destination. Towards this, we make

modifications to the Ad Hoc Distance Vector Routing Protocol

(AODV) [7] which is one of the most popular ad hoc routing

protocols to facilitate the discovery, and consequently the use of

multiple node-disjoint paths.

We found that the number of node-disjoint paths from a source

to a destination is dependent on the node density in the ad hoc

network (as might be expected). Furthermore, we found that as

the distance between a source and its destination is increased, one

could find no more than a very limited number of paths between

them, even at moderate node densities (average node degree is

6.7). This observation lead us to believe that, one would require

at least a few of the ad hoc nodes to be more reliable. One could

envision that these nodes would be placed in moving vehicles

and could be less constrained in terms of size, processing and

power. They would be physically more secure and robust to

compromises. These nodes (typically much fewer in number

in comparison with the normal ad hoc nodes) could then, be

allowed to participate in routing along multiple routes between

the same source-destination pair. For the ease of notation let

us call these nodes R-nodes. The revised objective is then to

construct a sequence of reliable segments between the source

and the destination. Nodes that join two segments have to be

R-nodes. A segment is deemed reliable if it consists of either a

IEEE INFOCOM 2003

preset number of paths between the two R-nodes that it connects

or if it is made up of R-nodes entirely. A concatenation of reliable

segments is called a reliable path. We describe the construction

of a reliable path in detail in Section V.

The next question that arises is: where should these R-nodes

be placed so that the probability of finding a reliable path be-

tween an arbitrary source and destination is acceptable? Initially,

we placed these R-nodes at random locations within the area of

interest. However, we found that this does not help in achiev-

ing an acceptable probability of finding a reliable path between

a source and a destination. Thus, we need a more intelligent way

of placing these R-nodes. Furthermore, as the nodes in the ad

hoc network are mobile, the R-nodes would have to adaptively

move so as to maintain these advantageous positions with respect

to the other nodes. We propose a methodology to control the tra-

jectory of an R-node based on information exchanged within a

local vicinity of the R-node. We find by simulations that placing

each R-node at positions defined by our algorithm (which is in

fact, a version of the randomized min-cut algorithm1[8]) is a very

effective deployment strategy in terms of achieving a high prob-

ability that a reliable path is found between any arbitrary source

and destination.

The remainder of this paper is organized as follows. In Sec-

tion II, we review the related work on multipath routing in ad

hoc networks. We describe our modified version of AODV (we

call it AODVM for AODV-Multipath) in Section III and describe

how it finds multiple node-disjoint paths from a given source to a

given destination. In Section IV we discuss the simulation exper-

iments performed with AODVM and discuss the observed results

in terms of performance. We describe the various strategies that

we consider for deploying the R-nodes and the motivation for

doing so in Section V. In Section VI we describe our simulation

results with a new experimental set up with an ad hoc network

that includes a small number of R-nodes and discuss the observed

results in terms of the performance of the various deployment

strategies. We present our conclusions in Section VII.

II. Related Work

Multipath routing has been well studied in wired [1][9][10]

and wireless [2][3][4][5][11] networks. Multipath routing in

MANETs has also received some attention recently. DSR [12]

and TORA [13] have the ability to find multiple paths. In DSR,

by using the information received from multiple route queries

which might traverse distinct paths, the destination can attempt

to construct multiple node-disjoint paths. However, due to its

inherent nature (as in AODV, described in the next section), DSR

can find only a small fraction of the possible node-disjoint paths

if used without any modifications. TORA builds and maintains

multiple loop free paths using Directed Acyclic Graph (DAG)

rooted at the destination; however, it does not find node-disjoint

paths.

Path disjointness has been studied in [2][3][5][11]. In [2], the

authors have analyzed the performance impacts of alternative

path routing for load balancing. Nasipuri et al.[3] studied the

1The details are provided in a later section.

0-7803-7753-2/03/$17.00 (C) 2003 IEEE

effect of number of multiple paths and lengths of those paths on

routing performance using analytical models. Lee et al. [11]

proposed the Split Multipath Routing protocol (SMR), which

can find an alternate route that is maximally disjoint from the

shortest delay route from the source to the destination. All of

the above protocols are based on source routing. Distance vector

based multipath routing protocols are investigated in [4][9][14].

However, of these, AOMDV [4] is the only protocol that ensures

that the paths are edge-disjoint.

The multipath routing protocols described above, which are

based on source routing, allow the source node to compute mul-

tiple node or edge-disjoint paths. The source can do so from the

partial topology information that is made available by means of

multiple responses to a single route query. With distance vector

based protocols, the topology information that a node can ob-

tain is further limited. Thus, it would be difficult to construct

node-disjoint paths from a source to a destination. Link state

routing can be used to generate multiple node-disjoint paths but

the use of such protocols requires large overheads [15]. AODV

is a popular routing protocol that creates distance vector routing

tables on-demand and it requires a lower overhead as compared

with DSR [16]. Thus, we choose AODV as a candidate protocol

and make modifications to it, to facilitate the discovery of node-

disjoint paths from a source to a destination. Although there has

been prior work on modifying AODV to compute edge-disjoint

paths [4], to the best of our knowledge, our AODVM protocol is

the first modified version of AODV, that has the ability of finding

node-disjoint paths. Furthermore, our work is the first to study

the relationship between the number of node-disjoint paths that

can be found between a source and a destination and the density

of nodes in the network. Our observations lead us to conclude

that in the absence of any infrastructure it is highly improba-

ble that we can find a satisfactory number of node-disjoint paths

even at moderate densities, especially when the source and the

destination are far apart. Thus, we propose an infrastructure that

is facilitated by the deployment of reliable nodes (that we call

R-nodes), that can route on multiple paths, as described earlier.

Our work also investigates the effect of the location of R-nodes

on the performance in terms of computing multiple paths. We

propose a distributed protocol to control the trajectories of the R-

nodes such that a reliable routing framework could be provided.

In [17], a trajectory control algorithm was proposed for mobile

gateways in ad hoc networks. The objective of the trajectory con-

trol algorithm is to determine where the gateways are to be placed,

relative to the ad hoc group of nodes that the gateway serves such

that certain network performance metrics such as throughput was

maximized. Unlike in [17] wherein one would most likely place

the gateways in dense regions within the network, our objective

would be to place the R-nodes in sparser regions of the network

and control their trajectories so as to increase the probability of

establishing a reliable path (defined earlier) between two arbi-

trary nodes.

IEEE INFOCOM 2003

Source ID

Source Destination

Links that are recorded in the routing table Links that are discarded

Source ID

Destination ID

Neighbor List

(a)

Neighbor ID

Hops To Source

Expiration Timer

Destination ID

Destination Sequence Number

Route List

(b)

Source Sequence Number

Last Hop ID

Next Hop ID

Hop Count

Expiration Timer

Fig. 1. The RREQ propagation procedure in AODV

III. Ad-hoc On-demand Distance Vector Multipath

(AODVM) Routing

In order to facilitate the computation of multiple node-disjoint

paths from a source to the destination, we choose AODV as a

candidate protocol and make modifications to it to enable the

discovery of such paths. First, the choice of AODV is based

on prior studies [15] that show that on-demand routing proto-

cols consume lower overhead than pro-active routing protocols.

Second, as compared with DSR (which is the other popular on-

demand routing protocol), AODV avoids the high source routing

overhead.

A. AODV

We first briefly describe the AODV protocol. We omit most of

the details due to space limitations. A more detailed description

of AODV may be found in [7].

AODV combines the use of destination sequence numbers in

DSDV with an on-demand route discovery technique. If a source

needs a route to a destination, it invokes a network-wide flood

of a route request or RREQ message. In response, either the

destination or an intermediate node that knows a route to the

destination, sends a route reply or RREP message back to the

source along the path on which the RREQ message was received.

Intermediate nodes re-broadcast the RREQ message only if (a)

they do not know a route to the destination and (b) if they have

not already forwarded the particular RREQ message.

Once a route is established, it is used by the source to send

data. If a link fails, the node that detects the link failure (possibly

through feedback from the link layer), sends a route error (RERR)

message to the source, upon the receipt of which, the source re-

initiates a route search. Destination sequence numbers are tagged

onto all routing messages and are used to indicate the relative

freshness of the routing information.

Since duplicate RREQ messages are discarded by intermediate

nodes, it is probable that, some of the possible node-disjoint paths

to the destination, might never be traced during the query pro-

cess. In Fig. 1, the links indicated by the dashed lines are never

reported to the destination since the intermediate relay nodes dis-

card the RREQ messages received on these links. Even though

there are three possible node-disjoint paths from the source to the

destination, AODV can find only one of them.

B. AODV-Multipath (AODVM)

We propose modifications to the AODV protocol so as to en-

able the discovery of multiple node-disjoint paths from a source

0-7803-7753-2/03/$17.00 (C) 2003 IEEE

Fig. 2. (a) Structure of the each RREQ table entry in AODVM

(b) Structure of the each routing table entry in AODVM

to a destination. Instead of discarding the duplicate RREQ pack-

ets, intermediate nodes are required to record the information

contained in these packets in a table which we refer to as the

RREQ table. For each received copy of an RREQ message, the

receiving intermediate node records the source who generated

the RREQ, the destination for which the RREQ is intended, the

neighbor who transmitted the RREQ, and some additional infor-

mation (as shown in Fig. 2(a)) in the RREQ table. Furthermore,

intermediate relay nodes are precluded from sending an RREP

message directly to the source.

When the destination receives the first RREQ packet from one

of its neighbors, it updates its sequence number and generates

an RREP packet. The RREP packet contains an additional field

called ``last hop ID2'' to indicate the neighbor from which the

particular copy of RREQ packet was received. This RREP packet

is sent back to the source via the path traversed by the RREQ copy,

albeit in the reverse direction. When the destination receives

duplicate copies of the RREQ packet from other neighbors, it

updates its sequence number and generates RREP packets for

each of them. Like the first RREP packet, these RREP packets

also contain their respective last hop nodes' IDs.

When an intermediate node receives an RREP packet from

one of its neighbors, it deletes the entry corresponding to this

neighbor from its RREQ table and adds a routing entry to its

routing table (shown in Fig. 2(b)) to indicate the discovered route

to the originator of the RREP packet (the destination). The node,

then, identifies the neighbor in the RREQ table via which, the path

to the source is the shortest, and forwards the RREP message

to that neighbor. The entry corresponding to this neighbor is

then deleted from the RREQ table. In order to ensure that a

node does not participate in multiple paths, when nodes overhear

any node broadcasting an RREP message, they delete the entry

corresponding to the transmitting node from their RREQ tables.

When an intermediate node that receives an RREP message

cannot forward it further (its RREQ table is now empty), it gen-

erates an RDER or Route Discovery Error message and sends

that message to the neighbor that actually forwarded the RREP

to this node. The neighbor, upon receiving the RDER message

will now attempt to forward the RREP to a different neighbor who

can potentially forward it further towards the source. We limit

the number of RDERs that an RREP message can experience in

order to prevent the generation and exchange of a large number

of such packets3.

2We assume that the ID of a node is unique in the network and it can be the

node's IP address.

3In our simulation (to be described later) we set this limit to twice the lifetime

(TTL) of the RREP packet.

IEEE INFOCOM 2003

Thank you for trying Quick PDF Converter.

Please note that Quick PDF Converter trial version converts only limited pages of your document.

To convert your complete document, you need to purchase Quick PDF Converter.

To order, please visit: http://www.quickpdftoword.com/orb_order_now.asp