A Low Overhead Ad Hoc Routing Protocol with Route Recovery.

Full text

Page 1

X. Jia, J. Wu, and Y. He (Eds.): MSN 2005, LNCS 3794, pp. 666 – 675, 2005.
© Springer-Verlag Berlin Heidelberg 2005
A Low Overhead Ad Hoc Routing Protocol
with Route Recovery
Chang Wu Yu1, Tung-Kuang Wu2, Rei Heng Cheng3, and Po Tsang Chen1
1 Department of Computer Science and Information Engineering,
Chung Hua University, Hsin-Chu, Taiwan, R.O.C.
cwyu@chu.edu.tw
2 Department of Information Management,
National Changhua University of Education, Changhua, Taiwan, R.O.C.
tkwu@mail.tkwu.net
3 Department of Information Management,
Hsuan Chuang University, Hsin-Chu, Taiwan, R.O.C.
rhc@hcu.edu.tw
Abstract. Many routing protocols have been designed for Ad Hoc networks.
However, most of these kinds of protocols are not able to react fast enough to
maintain routing. In the paper, we propose a new protocol that repairs the bro-
ken route by using information provided by nodes overhearing the main route
communication. When links go down, our protocol intelligently replaces these
failed links or nodes with backup ones that are adjacent to the main route. Ex-
perimental results show that our protocol finds a backup route around 50% of
cases and achieve better (or as good) in term of the packet delivery rate than the
major Ad Hoc routing protocols, but with much less overhead.
1 Introduction
Ad Hoc networks are wireless networks with no fixed infrastructure. Each mobile
node in the network functions as a router that discovers and maintains routes for other
nodes. These nodes may move arbitrarily, therefore network topology changes fre-
quently and unpredictably. Other limitations of Ad Hoc networks include high power
consumption, low bandwidth, and high error rates [17]. Applications of ad hoc net-
works are emergency search-and-rescue operations, meetings or conventions in which
persons wish to quickly share information, data acquisition operations in inhospitable
terrain, and automated battlefield [17].
For years numerous routing protocols have been developed for ad hoc networks in-
cluding Destination-Sequenced Distance-Vector Routing protocol (DSDV) [15],
Clusterhead Gateway Switch Routing protocol (CGSR) [3], Wireless Routing Proto-
col (WRP) [12], Ad Hoc On-Demand Distance Vector (AODV) [14, 16], Dynamic
Source Routing (DSR) [1, 10], Temporally Ordered Routing Algorithm (TORA) [5,
13], Associativity-Based Routing (ABR) [18], and Zone Routing Protocol (ZRP) [8].
In general, the existing routing protocols either need to maintain routing informa-
tion from each node to every other node in the network or try to create routes on an

Page 2

A Low Overhead Ad Hoc Routing Protocol with Route Recovery 667
on-demand basis. Maintaining routing information takes a large portion of network
capacity, even though most of the information is never used. On the other hand, the
on-demand methods usually incur quite a significant latency in order to determine a
route. When the rate of topological changes in the network is sufficiently high, most
of the existing protocols may not be able to react fast enough to maintain necessary
routing. In this paper, we propose a new routing algorithm, which overcomes the
drawback associated with the conventional routing algorithms. Simulations show that
the proposed algorithm achieves better in most aspects than most of these notable
protocols, and with much less overhead.
The rest of paper is organized as follow. In Section 2, we give a survey of how
relevant routing protocols react to link failure. The main ideas of our algorithm are
described in Section 3, with experimental results of our proposed protocol presented
in Section 4. We conclude the paper in Section 5.
2 Related Work
Ad Hoc routing protocols can generally be categorized as (1) table-driven routing and
(2) source-initiated on-demand routing [17]. Table-driven routing protocols require
constant propagation of routing information, which incurs extra communication over-
head and power consumption. As a result, these become the limiting factors of their
applications in Ad Hoc network environment since both bandwidth and battery power
are scare resources in mobile devices [17]. On the other hand, on-demand routing
protocols establish a route only when a source requires to send messages to some
destination without requiring periodic update of routing information. However, vari-
ous on-demand routing protocols differ in how they handle route maintenance and
how they react to link failure, these will be the focus of the following survey.
AODV (Ad Hoc On-Demand Distance-Vector) [14, 16] Routing is an improve-
ment to the table-driven and distance-vector based DSDV algorithm. With DSDV
(Destination-Sequenced Distance-Vector) Routing [15], every mobile node maintains
a routing table recording all the possible destinations and number of hops to each
destination. In order to maintain routing table consistency, it requires nodes to peri-
odically broadcast routing updates throughout the network. AODV minimizes the
number of broadcast messages associated with DSDV by building routes on a demand
basis. In case a broken link notification is received, source nodes in AODV would
restart the route discovery process. But before sending the link failure notification to
source, AODV allows the upstream node of the break to try to repair a recently used
route by sending a Route Request (RREQ) message [16]. However, if the route repair-
ing attempts were unsuccessful, more data packets would be lost.
DSR (Dynamic Source Routing) [1, 10] uses source routing, with each packet to
be routed carrying in its header the complete, ordered list of nodes through which
the packet have to go through. If a link fails, the upstream of this failed link sends a
route error packet to the source node. When a route error is received, the hop in
error is removed from this host’s route cache, and all routes that contain this hop
must be truncated at that point. A new route discovery process must be initiated by

Page 3

668 C.W. Yu et al.
the source. A salvaging technique proposed by Maltz, Broch, Jetcheva, and Johnson
[11] uses alternate route from caches when a data packet meets a failed link on its
source route.
The Multiple Next Hops (MNH) routing protocol proposed by Jiang and Jan [9],
applies the concepts of forward link and reverse link used in AODV. For each desti-
nation, each mobile node in MNH routing protocol maintains multiple next hops in its
routing table. Hence the MNH may provide multiple routing paths for a source-
destination pair. As link failure occurs, the upstream node will detect that and try to
reconstruct a new route. However, the MNH constructs multiple routing paths on the
first initiation, but does not update the information to reflect the current network
status. Therefore, as the topology of network changes, there is little chance of using
these backup paths.
Chung, Wang and Chuang [4] proposed the Ad Hoc Backup Node Setup Routing
Protocol (ABRP) that is similar to the DSR. ABRP saves backup route information in
certain on-the-route node. When a link fails, data messages are sent back to a backup
node. The backup node checks its backup route cache, and pick one path (if there
exists one) to replace the current broken one. Similarly, ABRP does not update its
backup route information to reflect the network topology change.
TORA (Temporally Ordered Routing Algorithm) [5, 13], also a source-initiated
routing algorithm, maintains multiple routes for any desired source-destination pair.
The key idea of TORA is that control messages are restricted to a small set of nodes
in case of topological change. However, to achieve this, it needs to build a directed
acyclic graph (DAG) rooted at the destination. As links fail, only local routes are re-
established to a destination-oriented DAG within a finite time. For maintaining a list
of a node’s neighbors, each node periodically transmits a BEACON packet, which is
answered by each node hearing it with a Hello packet. Furthermore, in order to main-
tain the order, TORA needs a global timer to record the time of link failure.
As we have seen in the above review, the two major on-demand protocols (AODV
and DSR) do not respond quickly enough to link failure. And they usually suffer from
the risk of flooding the whole network for new route discovery. Variations of the two
protocols try to cope with these issues by storing extra backup routes for use upon
link failure. However, the backup routes are usually created during initial routes con-
struction stage, no effort is done to modify these routes in order to reflect the chang-
ing network topology. On the other hand, TORA replies on periodic HELLO mes-
sages to monitor the status of network topology and tries to fix broken routes that may
not be used later on, which considerably increases its protocol overhead.
3 The Proposed New Routing Protocol
Here we present a new fully distributed and on-demand based Ad Hoc routing proto-
col with nearly real time repairable route that handles the broken-link recovery in
more efficient way. Before moving on to the details, we present the intuitive ideas
behind our protocol in the following.

Page 4

A Low Overhead Ad Hoc Routing Protocol with Route Recovery 669
The proposed routing protocol begins by finding a route from a source S to a desti-
nation D, which we call the main route. All data packets are then sent along this main
route to the destination. As the data packets proceed to move along the main route,
nodes that are close enough to the path will overhear the messages. In other word,
nodes that are able to overhear the messages should be close to the main route and are
potentially good candidates for substituting the failed node. By piggybacking appro-
priate information within packets and applying proper procedure, our algorithm
makes nodes that overhearing the packets the backup nodes for future route recon-
struction in case of broken main route. Other than adding an additional field (for stor-
ing height value, as explain later) to a node’s route table and header of message, there
is no need for frequent message flooding and huge table maintenance. Our protocol
consists of route construction and maintenance stages. Detailed description is given
as follows.
3.1 Route Construction
In our proposed routing protocol, a routing path is constructed only when a node
needs to communicate with another node. Assume that a source node S wants to send
a packet to some destination node D. If the destination node D is a neighbor of source
node S, the packet is sent directly to node D. Otherwise, the source node will first
check if node D is in its main route table (MRT). If it is, packets will then be sent
directly to the next-hop node as specified by the entry. On the other hand, a path (the
main route) from source node S to destination node D need to be constructed before
source node S can start the data transmission. The process of finding such a routing
path is called the main route construction, which begins with the source node S send-
ing a main route request (MREQ) to all its neighbors. Every host that receives the
MREQ acts exactly the same as the source node does. MREQ is thus flooded over the
network, and would eventually arrive at node D if a routing path exists between them.
When node D receives a MERQ, it sends back main route reply (MRRP) and a value
H, representing the hop number from this node (D) to the destination (which is zero in
this case), to the host from which MREQ was received. Once a node receives MREQ,
it adds a main route entry for node D to its MRT. It then propagates the MRRP, to-
gether with value H+1, to the host from which it receives the MREQ. Every other host
receiving MRRP behaves similarly until node S receives MRRP and updates its MRT
accordingly. A routing path from node S to D, referred to as the main route, is thus
established.
3.2 Route Maintenance
The route maintenance process consists of two parts: the main route messages sniffer-
ing and the main route repairing. In main route messages sniffering stage, our concern
is how to manage the messages go through the main route that are overheard by the
neighboring nodes. With main route repairing, we need to take care of a broken main
route using the messages collected and avoid the flooding of repair query (REPQ)
packets as long as possible.

Page 5

670 C.W. Yu et al.
The Main Route Messages Sniffering. The main route messages sniffering stage
begins as packets start delivering through the main route. However, we need to
modify the packets delivery slightly to accomplish this task. First of all, we need to
insert an H field into the header of data packet and require the nodes to maintain an
extra height table for storing the H value. Secondly, with the broadcast nature of
wireless communication, a node promiscuously “overhears” packets transmitted by
nodes that are within the radio range. In case a node, which is not part of the main
route, overhears a data packet transmitted by a neighbor on the main route, it records
the H value within the packets header into its height table. If more than one such
packet is received, the average of the received H values are computed and then
recorded in its height table. The recorded H value can later be used to assist repairing
of the route and to restrain flooding of control packets.
The Main Route Repairing. When a link on the main route is broken, the upstream
node of this link would find out in a period of time and then initiate the main route
repairing process by broadcasting a repair query (REPQ) packet. The REPQ packet
contains the height value of the initiating node. Each node that receives the REPQ
packet would first check if it has a route to the destination. If it does, a repair reply
(REPR) packet is sent back to the node from which the repair query (REPQ) packet
was received and the route repairing process is done. Otherwise, it compares the
height value (denotes Hreq) contained in the REPQ packet to its own height value
(denotes Ht) in the height table to determine what the next step will be. In case Hreq
is greater than (or equal to) Ht, which means very likely the route repairing request
was sent from a node that is closer (or as close) to the source node, the receiving node
would then rebroadcast the REPQ and hope the REPQ packet would propagate to the
nodes that are closer to the destination. However, if Hreq is smaller than Ht or the
node has no Ht in its height table, the REPQ packet will be dropped.
4 Performance of the Proposed Protocol
Our proposed routing protocol described in previous section is simple, straightforward
and should be viable to be included in any Ad Hoc networks without incurring much
overhead. In this section, we will demonstrate how it performs as comparing to some
major routing protocols.
We use NS-2 [7], which was adopted in numerous researches to evaluate the per-
formance of existing Ad Hoc routing protocols [2, 6], as the simulation tools. The link
layer of our simulator is IEEE 802.11 Distributed Coordination Function. Physical
and data link layer models are devised and described in [2].
The simulation environment is a 1500 by 1500 meters rectangular region with 100
mobile nodes moving around. Each of the 100 nodes is placed randomly inside the
region. Once the simulation begins, each node moves toward a randomly selected
direction with a random speed ranges from 0 to 50 meters per second. Upon reaching
the boundary of the rectangular region, the node pauses for a few seconds, then se-
lects another direction and proceeds again as described earlier. The simulation period
is set to 500 seconds for each simulation.

Page 6

A Low Overhead Ad Hoc Routing Protocol with Route Recovery 671
The radio coverage region of each mobile node is assumed to be a circular area
with 250 meters in diameter. The transmission time for a hop takes 0.002 seconds,
and the beacon period is one second. We assume the source node sends a data packet
every half second (CBR: Constant Bit Rate), and use UDP as the transport protocol.
Each data packet contains 512 bytes, and totally 920 data packets are sent. Each node
has a queue, provided by network interface, for packets awaiting transmission that
holds up to 50 packets and managed in a drop-tail fashion. One source-destination
pair is selected arbitrarily from 100 nodes in each simulation. Each simulation sce-
nario represents an average of at least 150 runs.
Three on-demand protocols including TORA, DSR, and AODV are used as the ba-
sis of comparison to our protocol. These three models and protocols described above
are all supported natively by NS-2. Four aspects in evaluating how these algorithms
perform are simulated and given in the following four subsections, include (1) data
delivery rate, (2) routing overhead, (3) communication latency and (4) average num-
ber of hops a message needs to traverse to reach its destination.
4.1 Effectiveness of the Proposed Protocol in Repairing Broken Route
The first thing we would like to know is how the proposed protocol performs in term
of broken route repairing. The experimental simulation result shows that in around
50% of cases of the simulations, the broken routes can be repaired, as shown in
Table 1. As can be expected, the successful repair rate increases in accordance with
the pause time since longer pause time implies more stable nodes.
Table 1. Percentage of Successful Route Repair
Pause Time (in seconds)
10
20
30
40
50
Percentage of Successful Repair
45.95 %
47.26 %
50.32 %
51.60 %
55.56 %
4.2 Data Delivery Ratio
Figure 1 shows the simulation results in packet delivery ratio. It can be easily seen
that our protocol performs approximately as good as (or better than) AODV in term of
packet delivery rate. In fact, in all the simulation scenarios, the margins are all around
1% range, with AODV slightly ahead in 4 of five cases. On the other hand, both of
our protocol and AODV perform much better that DSR and TORA do, especially
when nodes are moving fast (corresponding to higher node speed and short pause
time). However, when nodes mobility reduces, the performance of DSR and TORA
catches up a little since the pre-established main routes become more stable under
such circumstance.

Page 7

672 C.W. Yu et al.


Fig. 1. Data Delivery Ratio


Fig. 2. Routing Overhead
4.3 Routing Overhead
Routing overhead, in term of number of control packets sent, is presented in Figure 2.
We can see that our proposed protocol has much lower overhead than that of TORA.
This is attributed to the fact that our protocol does not require to construct a backup
route in advance, and thus save a large number of control packets broadcast. In addi-
tion, comparing to AODV, our protocol also performs better in this aspect. This is not
surprising since AODV, instead of repairing the partially broken main route, always
reconstructs a new main route from scratch when one is broken. As a result, every
time a main route is broken, the main route request (MREQ) broadcast packets are
flooded to the network. On the other hand, our protocol would try to repair the main
route by taking advantage of the neighboring nodes that are close to the main route.
The scope of repair query (REPQ) packet broadcast is thus effectively restricted
within two-hops from the original main route. According to the results shown in Fig-
ure 1 and 2, we can see that AODV may have a slightly better chance in successfully
delivering data packets, but it does that with substantially higher cost (approximately
700~1000 additional packets more than ours in each case). Finally, the gap in term of
overhead between our protocol and DSR is only marginally.
4.4 Communication Latency and Variance
The communication latency is measured by the average data packet delivery delay per
route in our simulation. In Figure 3 and Figure 4, the simulated average delay time
and its variance are illustrated. It is expected that our protocol would perform better
than the AODV and TORA do in this aspect. The reason for such speculation is based
on the fact that instead of starting from scratch every time a route is broken, our pro-

Page 8

A Low Overhead Ad Hoc Routing Protocol with Route Recovery 673
tocol would try to repair the broken main route with some substitute route around the
main link. As a result, our protocol can recover from link failure more quickly in half
of cases (see table 1), which results to the low communication latency. As we can see,
the results correspond exactly to what we expected.
On the other hand, it seems that our protocol does not perform as well as DSR
does. However, the fact that the communication latency is calculated only according
to data packets that are successfully received by the destination nodes and DSR has a
very low delivery ratio make the difference insignificant.


Fig. 3. Communication Latency

Fig. 4. Variance of communication latency
4.5 Average Number of Hops
Figure 5 shows the average number of hops that packets need to go through in order
to reach the destination. The result indicates that our protocol in average requires up
to 1 hop more than the AODV and DSR take. The reason is also resulted from our
protocol’s attempt to repair the main route. A successful repair action implies that
packets now travel via an alternative route that is not as direct or straight as the
original one, which contribute to the increase of the average hop count that a route
traverses. On the other hand, both the AODV and DSR protocols always try to find
a new main route, which tends to be a shorter one. In the case of TORA, the up-
stream node will search its routing table for another outgoing entry to the upstream
node when the main route is broken. If there exist one, the upstream node does
nothing. Otherwise, it sends Failure Query (FQ) to one of its upstream neighbors.
However, upon receiving the FQ message, instead of rediscovering a brand-new
route, TORA also tries to fix the existing ones, which could establish a potentially
longer link as in our case.

Page 9

674 C.W. Yu et al.

Fig. 5. Average number of hops
5 Conclusion and Future Work
In this paper, we present a new on-demand routing protocol that is able to quickly repair
a link or node failure with less communication overhead. Comparing to the other nota-
ble on-demand routing protocols, our protocol has a much higher successful data deliv-
ery rate than those of TORA and DSR, while performs nearly as good as AODV does,
but with approximately 25% less in communication overhead. Our protocol incurs much
less overhead with respect to TORA, too. In term of communication latency, our proto-
col also performs very well, especially when node mobility is higher.
However, there remain issues that deserve further investigation. First of all, it
would be interesting to explore ways in evaluating among various potential alternate
routes so that a more robust or reliable backup route can be chosen under different
network conditions or environments. Secondly, there may also be conditions or
threshold that performing a new route discovery would be more economic than repair-
ing the existing main route. As a result, in the future, we will be working on increas-
ing the data delivery rate through a route maintenance mechanism that can dynami-
cally determine when to initiate the route repairing process and how to select a more
reliable alternative route. In other word, the alternative route construction process
could be initiated at any time, not just when a route is broken. The dynamically con-
structed alternative routes information can be passed to the upstream nodes, which
then determine by themselves when to direct their packets to the “optimal” alternative
route. Finally, we will also be exploring the possibilities in applying similar idea to
the sensor network environment.
References
1. J. Broch, D.B. Johnson, and D. Malt, “The Dynamic Source Routing Protocol for Mobile
Ad Hoc Networks,” IETF, Internet Draft, draft-ietf-manet-dsr-00.txt, Mar. 1998.
2. J. Broch, D.A. Malt, D.B. Johnson, Y.C. Hu, and J. Jetcheva, “A Performance Comparison
of Multi-Hop Wireless Ad Hoc Network Routing Protocols,” MOBICOM’98, pp. 85-97.

Page 10

A Low Overhead Ad Hoc Routing Protocol with Route Recovery 675
3. C.C. Chiang, "Routing in Clustered Multi-Hop, Mobile Wireless Networks with Fading
Channel," Proc. IEEE SICON, 1997, pp. 197-211.
4. C.M. Chung, Y.H. Wang, and C.C. Chuang, “Ad hoc on-demand backup node setup rout-
ing protocol,” Proceedings of 15th IEEE International Conference on Information Net-
working, pp. 933-937, 2001.
5. M.S. Corson and V.D. Park, ”Temporally Ordered Routing Algorithm (TORA) version 1:
Functional specification,” Internet-Draft, draft-ietf-manet-tora-spec-00.txt, Nov.1997.
6. S.R. Das, C.E. Perkins, and E.M. Royer, “Performance Comparison of Two On-demand
Routing Protocols for Ad Hoc Networks,“ Proceeding INFOCOM, 2000, pp. 3-12.
7. Kevin Fall and Kannan Varadhan, editors. ns notes and documentation, The VINT Project,
UC Berkeley, LBL, USC/ISI, and Xerox PARC, November 1999. Available from
http://www-mash.cs.berkeley.edu/ns/.
8. Z.J. Haas “The Zone Routing Protocol (ZRP) for Ad-Hoc Networks,“ IETF Internet Draft,
draft-zone-routing-protocol-00.txt, Nov. 1997.
9. M.H. Jiang and R.H. Jan, “An efficient multiple paths routing protocol for ad-hoc net-
works,” Proceedings of 15th IEEE International Conference on Information Networking,
pp. 544-549, 2001.
10. D.B. Johnson and D. A. Maltz, "Dynamic source routing in Ad-Hoc wireless networks, "
Mobile Computing, T. Imielinske and H. Korth, Eds., Kluwer, 1996, pp. 153-181.
11. D. Maltz, J. Broch, J. Jetcheva, and D. Johnson, “The effects of on-demand behavior in
routing protocols for multi-hop wireless ad hoc networks,” IEEE Journal on Selected Ar-
eas in Communication, 1999, to appear.
12. S. Murthy and J.J. Garcia-Luna-Aceves, “A routing protocol for packet radio networks, ”
ACM MOBICOM, 1995, pp. 86-94.
13. V.D. Park and M.S. Corson, “A Highly Adaptive Distributed Routing Protocol for Mobile
Ad Hoc Networks,“ Proceeding INFOCOM ’97, 1997, pp. 1405-1413.
14. C.E. Perkins, “Ad Hoc On Demand Distance Vector (AODV) Routing, “ IETF, Internet-
Draft, draft-ietf-manet-aodv-00.txt, Nov. 1997.
15. C.E. Perkins and P. Bhagwat, “Highly Dynamic Destination-Sequenced Distance-Vector
Routing (DSDV) for Mobile Computers, “ ACM SIGCOMM ’94, pp. 234-244.
16. C.E. Perkins and E.M. Royer, “Ad-hoc On-demand Distance Vector routing, “ Proceed-
ings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, pp.
99-100, 1999.
17. E.M. Royer and C-K Toh, “A Review of Current Routing Protocols for Ad Hoc Mobile
Wireless Networks,“ IEEE Personal Communication, pp. 46-55, 1999.
18. C.K. Toh, “Associativity Based Routing for Ad-Hoc Mobile Networks,“ Wireless Personal
Communication, vol. 4, no. 2, pp. 103-139, 1997.