1
Bypass Routing: An On-Demand Local Recovery
Protocol for Ad Hoc Networks
Cigdem Sengul
University of Illinois Urbana-Champaign
e-mail: sengul@uiuc.edu
Robin Kravets
University of Illinois Urbana-Champaign
e-mail: rhk@cs.uiuc.edu
Abstract—On-demand routing protocols for ad hoc net-
works reduce the cost of routing in high mobility environ-
ments. However, route discovery in on-demand routing is
typically performed via network-wide flooding, which con-
sumes a substantial amount of bandwidth. In this paper, we
present bypass routing, a local recovery protocol that aims
to reduce the frequency of route request floods triggered by
broken routes. Specifically, when a broken link is detected,
a node patches the affected route using local information,
which is acquired on-demand, and thereby bypasses the
broken link. We implemented SLR (Source Routing with
Local Recovery) as a prototype of our approach. Simula-
tion studies show that SLR achieves efficient and effective
local recovery while maintaining acceptable overhead.
Index Terms—Ad hoc networks, routing, local recovery.
I. INTRODUCTION
An ad hoc network is formed by a group of wireless de-
vices without depending on any infrastructure. Each node
communicates directly with its neighbors and functions as
a router that forwards packets for nodes that are not within
transmission range of the sender. Maintaining communi-
cation in ad hoc networks requires effective routing mech-
anisms in the presence of dynamic topology, which may
cause route failures and require discovery of new routes.
Therefore, the challenge to routing in dynamic ad hoc net-
works stems from the need to maintain routes while min-
imizing overhead from such maintenance.
Routing protocols for ad hoc networks can be cate-
gorized as proactive or reactive (on-demand) based on
when routes are discovered. Proactive protocols [1] main-
tain up-to-date routing information regardless of the pres-
ence of traffic, and so consume valuable resources such
as bandwidth and power even if the network is idle. On-
demand routing protocols have been shown to reduce rout-
ing overhead in high mobility environments by only main-
taining actively used routes [2], [3]. Although on-demand
routing protocols only initiate route discovery when a
route is needed, such discovery is typically performed via
network-wide flooding. Since flooding consumes a sub-
stantial amount of bandwidth, it is essential to reduce the
frequency of route discoveries, and so network flooding.
To overcome performance problems from frequent
route discovery attempts, hybrid protocols incorporate
both reactive and proactive protocol characteristics [4].
Although hybrid protocols do not waste resources by
flooding the network for each route request, it is difficult
to balance the cost of exchanging routing information pe-
riodically (i.e., proactivity) and network-wide flooding for
route discovery (i.e., reactivity) [5]. Other protocols re-
duce the frequency of flooding by allowing a relay node
to initiate a limited route discovery in the event of a route
failure [6], [7] or employ local error recovery mecha-
nisms [8], [9]. However, protocols using either limited
broadcast or local error recovery have focused on reducing
packet drops and not on utilizing the bandwidth efficiently
during route recovery. Multipath routing protocols cache
multiple routes to a destination in a single route discov-
ery [10], [11], [12]. However, in the presence of mobil-
ity, multipath protocols incur additional packet drops and
delay due to their dependency on potentially stale routes
from caches. Based on these observations, our goal is to
design an efficient on-demand local recovery protocol that
reduces route request floods due to route failures without
incurring any overhead from proactive exchanges.
The contribution of our research is bypass routing,
which effectively localizes reaction to route failures using
on-demand local recovery and a novel cache invalidation
mechanism. Essentially, bypass recovery uses link-state
information to find a patch between one of the neighbors
and a node along the route to the destination, bypassing
the link that caused the broken route. Different than other
route repair techniques [8], our approach acquires link-
state information of the neighborhood of a broken link on-
demand. Therefore, bypass recovery ties local recovery
to up-to-date information about a node’s neighborhood,
and hence increases the chance of recovering a broken
route compared to using potentially stale routes (or link
state information) from caches. The key benefit of by-
pass recovery comes from this localization of route re-
2
covery to the one hop neighborhood of the broken link,
which reduces the impact of route recovery on the rest of
the network. Additionally, the on-demand nature of by-
pass recovery ensures no extra overhead is incurred dur-
ing normal operation of the network. Finally, an improved
route invalidation mechanism that closely ties route valid-
ity to up-to-date neighbor information is integrated into
route caching, enabling the early identification of broken
routes. Through the localization of recovery and the im-
proved caching, bypass routing is an effective and efficient
approach to recovery from route failures. Results of ex-
tensive simulations based on our prototype SLR (Source
Routing with Local Recovery) show that SLR enables fast
recovery of broken routes, increasing the packet delivery
ratio while maintaining acceptable overhead.
The rest of the paper is organized as follows. In Sec-
tion II, we give a brief overview of proactive and reac-
tive protocols and discuss existing approaches for local
recovery in ad hoc networks. In Section III, we present
bypass routing and describe our prototype SLR in Sec-
tion IV. We demonstrate the effectiveness of bypass re-
covery in the context of SLR via simulation in Section
V and further compare the results from the evaluation
of SLR to the published results of AODV-BR (Ad Hoc
On-Demand Distance Vector - Backup Routing) [13] and
NSR (Neighborhood-aware Source Routing) [8] in Sec-
tion VI. Section VII concludes with future work.
II. LOCAL RECOVERY IN AD HOC NETWORKS
Routing protocols for ad hoc networks can be catego-
rized into three classes: Proactive, Reactive and Hybrid.
In general, protocols differ based on how they handle
Route Discovery and Route Maintenance. Route discov-
ery sets up initial routes or searches for new routes when
the old ones break. Route maintenance manages accurate
information about existing routes and also supports error
recovery when a broken route is detected.
In proactive protocols, routing information is ex-
changed among neighbors periodically or each time a
change occurs in network topology (i.e., route discov-
ery and route maintenance are continuously performed).
While protocols in this category have the advantage that
routes are immediately available when requested, they in-
cur high control overhead. Although hybrid protocols aim
to reduce the control overhead by balancing proactivity
and reactivity, all current hybrid protocols rely on proac-
tively acquiring at least one-hop neighborhood informa-
tion for all nodes. In comparison, on-demand routing pro-
tocols reduce routing overhead by tying route discovery
to network communication [2], [3]. On-demand proto-
cols initiate a route discovery only when a new route is
needed for initial route set-up or due to a broken route.
Such route discovery is achieved by flooding the network,
which causes high routing overhead and interference with
ongoing traffic. If a broken route can be repaired, route
discovery from the source, which causes the network-
wide flood, is no longer necessary. However, it is impor-
tant to ensure that any route recovery technique costs less
in terms of control overhead and delay than a new route
set-up via flooding.
Several protocols implement solutions to the flooding
problem in on-demand routing by providing more efficient
route recovery mechanisms. These protocols can be cate-
gorized into three main classes:
Limited broadcast: Route discovery is initiated by
relay nodes. The broadcast range is limited and does
not flood the whole network [6], [7], [14].
Multipath routing: Multiple routes are discovered
and cached in a single route discovery [11], [10],
[12], [13].
Local error recovery: Route errors are handled at a
relay node instead of relying on end-to-end error re-
covery at the sender [9], [8].
The rest of the section discusses route recovery proto-
cols in these three classes in more detail.
A. Limited Broadcast Approaches
AODV [6] and ABR [7] provide route recovery by al-
lowing relay nodes to initiate a search to replace a failed
route. In AODV, if a node is no further than maximum re-
pair hops away from the destination, it attempts to repair
the route by broadcasting a route request with a limited
time-to-live. ABR (Associativity-Based Routing) uses
a similar technique but repairs broken routes with new
routes that tend to be more long-lived by basing route de-
cisions on a measure of next hop mobility. However, both
methods are too bandwidth consuming, since even with a
limited scope, flooding can deliver the request messages
to a large number of nodes, leading to high routing over-
head. Additionally, routes are repaired based on route
replies from caches, and therefore recovery may not be
successful if the caches contain stale routes. Other mech-
anisms that try to localize flooding to a limited region
of the network either require location information (e.g.,
GPS) [14] or use a heuristic-based approach that requires
fine tuning of parameters based on current network char-
acteristics to determine the query region [15].
B. Multipath Routing Approaches
Multipath routing [10], [11], [12] discovers and caches
multiple routes with a single route discovery. When a bro-
ken route is detected, it is expected that other routes are
3
available from the cache and a new route discovery due
to a broken route is only needed when all cached routes
to a destination break. Although multipath routing re-
duces the number of route discovery attempts, it may not
be effective in the presence of mobility, incurring addi-
tional packet drops and delay. For instance, if a signifi-
cant amount of time has passed between route discovery
and route recovery, it is likely that the cached routes are
invalid due to topology changes. Without any mechanism
to keep the caches up-to-date, a route discovery attempt
may be inevitable.
C. Local Error Recovery Mechanisms
Local error recovery provides more robust route recov-
ery during route failures in mobile environments by al-
lowing a relay node to repair a broken route. While local
recovery can extend the lifetime of a route in traditional
routing protocols, it can also extend the lifetimes of indi-
vidual routes when multiple routes are used for load bal-
ancing [16], [11], [17].
In AODV-BR [13], nodes snoop route reply messages
to create alternate next hops to a destination. When a
node detects a broken route, it broadcasts the packet to its
neighbors, which forward it to the destination (if they have
an entry in their cache). However, the alternate routes may
be stale since they are only populated during route discov-
ery. A similar approach is used in WAR (Witness-Aided
Routing) [9] that designates nodes in the neighborhood
of an ongoing communication as witness nodes, which
buffer overheard packets and deliver the packets them-
selves to the next hop if a failure occurs. This requires
witness nodes to maintain state and dedicate storage for
communication in which they are not involved. Addition-
ally, both AODV-BR and WAR may cause unnecessary
overhead by delivering the same packet to the destination
several times.
DSR [18] potentially caches multiple routes to a des-
tination and provides a route salvaging option that en-
ables relay nodes to recover from route failures locally by
searching for alternate routes in their caches. However,
nodes immediately send a route error back to the source.
Therefore, salvaging in DSR does not achieve any reduc-
tion in the frequency of route discoveries. A recently pro-
posed protocol, CHAMP (Caching and Multipath) [19],
uses a salvaging algorithm where all nodes temporarily
cache packets before forwarding. When a node receives a
route error and if the failed packet still exists in its packet
cache, the node sends the packet with an alternate route
from its route cache. Therefore, local recovery is achieved
by incurring additional storage overhead in relay nodes.
Furthermore, trying to recover from the failure at all up-
stream nodes using stale route cache information may in-
cur additional delay and packet overhead.
NSR [8] incorporates proactivity into DSR by main-
taining two-hop neighborhood state for all nodes via
HELLO, route request and reply messages and uses this
link-state information to enable relay nodes to repair bro-
ken routes. Specifically, HELLO messages contain each
node’s neighbors, which provides a way of obtaining two-
hop neighborhood state that cannot be acquired by snoop-
ing. However, HELLO messages incur additional over-
head even when the network is stable and hence, are very
expensive.
Although each of these local error recovery mecha-
nisms has limitations, we believe localization of recovery
is necessary for the scalability of ad hoc routing protocols.
Next, we present design guidelines for local recovery pro-
tocols to achieve effective local recovery.
D. Local Recovery Protocol Design Guidelines
The goal of any local recovery mechanism should be to
repair broken routes in a way that reduces control over-
head and chooses valid routes. Therefore, a routing al-
gorithm with local recovery should possess the following
characteristics to enable efficient route repair:
Repair with cached routes when available
Repair with local error recovery when cached routes
are not available
Repair all active routes affected by broken links
Utilize bandwidth efficiently
Utilization of both route caches and local error recov-
ery mechanisms is essential for providing robust recovery
in ad hoc networks. The benefit of using route caches
is two-fold. First, when a link failure occurs, an alter-
nate route may be immediately available. Second, using
route caches can provide reduction in the control overhead
that is required to repair a route. However, in high mo-
bility environments route caches may contain stale routes.
Therefore, route recovery should not entirely rely on route
caches and local error recovery mechanisms should take
over when route caches do not provide useful information.
Although the main concern of local recovery is to repair
a broken route as fast as possible, it is important to allevi-
ate the effects of a broken link on future transmissions by
repairing all routes that actively use the broken link. Fi-
nally, a local recovery mechanism should use bandwidth
efficiently by incurring minimum overhead.
To achieve efficient and effective route recovery, a local
recovery protocol should follow these guidelines. How-
ever, none of the protocols discussed in Section II-C fully
recognize these characteristics. For example, NSR, which
4
is the closest approach to our work, uses local error recov-
ery for route repairs. However, recovery is achieved at the
expense of efficient bandwidth utilization (due to HELLO
messages). To this end, we propose bypass routing, which
is a novel approach that incorporates these guidelines for
effective route recovery.
III. BYPASS ROUTING
Bypass routing performs on-demand route recovery uti-
lizing both route caches and local error recovery. Essen-
tially, to recover from a route failure, a node first salvages
a route by searching its route cache for an alternate route
to the destination (if the node caches multiple routes). If
a route exists, the node patches the broken route with the
alternate route. If the node is not able to repair the route
from its route cache, it initiates bypass recovery by query-
ing its neighbors to see if they have a link to any nodes
on the downstream route to the destination (e.g., the next
hop, or all downstream nodes in case of source routes).
As replies arrive, the node repairs the routes affected by
the link failure with the received connectivity information.
When those packets reach the destination, the new route
information is added to an enhanced route error packet
and sent back to the source to inform it about the broken
link and successful route change.
A. An Illustration of Bypass Routing
Although bypass routing is not limited to any routing
protocol, the specifics of the mechanism depend on the
characteristics of the underlying on-demand routing pro-
tocol. An illustration of bypass routing integrated into a
source routing protocol is shown in Figure 1. Initially,
the flow from Node S to Node D uses the route “S-L-M-
N-P-R-D”. When the link between Node M and Node N
breaks, Node M detects the failure and attempts to patch
the route by using an alternate route from its cache to des-
tination D. When Node M finds a route without loops,
Node M salvages the packet with the “S-L-M-T-U-V-D”
route. Figure 1 also illustrates an example of bypass re-
covery. Again, Node S initially uses the route “S-L-M-
N-P-R-D”. When the link between Node P and Node R
breaks and Node P does not have an alternate route in its
cache to the destination, Node P triggers a local query to
its neighbors. The neighbors reply if they have active links
to any of the downstream nodes on the broken route. In
Figure 1, Node X reports its connectivity with Node R
to Node P. Node P patches the route accordingly and the
packet is first forwarded to Node X and then to Node R to
reach the destination.
These examples show that local repair of broken routes
may result in an increase in route lengths. However,
Y
DM
N
L
X
P
R
T
U
V
S
Connectivity Salvage path
Local recovery pathOriginal route of the packet
Fig. 1. Error recovery example
sources that are informed of repair information are not
forced to use a longer route if they know a shorter route.
Specifically, bypass recovery aims to reduce the frequency
of route discoveries, while allowing the node to use
shorter routes when possible.
B. Operation of Bypass Routing
Bypass routing uses three mechanisms that work to-
gether to allow efficient recovery from route failures. A
novel MAC cache structure is used for determining the
state of links to neighboring nodes. A Route cache caches
recently discovered routes to avoid expensive route dis-
covery. Finally, Error recovery includes route salvaging
and bypass recovery.
The remainder of this section explains the MAC cache
and error recovery mechanisms. We leave discussing
route caches to Section IV, since operation of route caches
depends on the underlying routing protocol.
1) MAC Cache: In bypass routing, MAC caches pro-
vide connectivity information. To maintain the most re-
cent neighborhood state, a node updates its MAC cache if
any communication is heard from any neighbor. On any
activity, a neighbor’s link status is set to active. Cache
invalidation is a two stage process. If a refresh interval
passes without any sign from a neighbor, the neighbor’s
link status is set to no communication. Once in the no
communication state, if there is still no sign of the neigh-
bor during the delete interval, the neighbor is deleted from
the MAC cache. The rationale behind this two-stage pro-
cess is that it provides a second chance for nodes that have
not been in active communication recently.
Bypass routing uses MAC caches to enhance route se-
lection. A node searching for a route in its route cache
checks if the next hop exists in its MAC cache. A route is
considered stale if the next hop is not in the MAC cache.
Therefore, MAC caches serve to determine the validity
of the routes in route caches. A node uses a route even
5
if the next hop is in the no communication state, thereby
utilizing its route cache even when there is little commu-
nication in the network. However, a neighbor is deleted
from the MAC cache if there is no activity from it within
a delete interval. Although this does not necessarily mean
the link is broken and may result in not using a valid route,
the route is reactivated as soon as the node hears from this
neighbor. Essentially, if the node does not have any routes
to the destination, a one-hop query is performed, which
potentially rediscovers all neighbors without flooding the
network.
MAC caches are also essential during local recovery,
where a node queries its neighbors to see if they have con-
nectivity to any of the downstream nodes on the broken
route to the destination. For local recovery, the status of
the links should be taken into account and only nodes that
have active links to any of the nodes in the query message
should reply, since query replies must carry the most re-
cent connectivity information to facilitate effective local
recovery.
While bypass routing is not limited to any specific
MAC protocol, some knowledge of the underlying MAC
protocol is useful to successfully populate the MAC
cache. For example, IEEE 802.11 [20] uses RTS
(Request-to-send) and CTS (Clear-to-send) to provide a
form of channel reservation. After the RTS/CTS ex-
change, data packet transmission is followed by an ACK.
A node listens for RTS/CTS/DATA/ACK packets and up-
dates its MAC cache accordingly. It must be noted that
this type of snooping of MAC headers does not incur any
additional listening overhead at a node, since a node must
try to receive a packet to see if there is a packet being
transmitted to it. However, IEEE 802.11 has one behavior
that requires additional state to determine the originator
of a packet. While RTS and DATA carry both sender and
receiver information, CTS and ACK only contain receiver
information. When a node overhears a CTS (ACK), the
node checks if it is the destination and if it has recently
sent the corresponding RTS (DATA). However, without
any additional mechanisms, a node that is not the sender
of the RTS (DATA) cannot determine the originator of the
CTS (ACK). Due to this problem, a node can only cache
senders but not receivers on a route. To utilize CTS and
ACK packets in bypass routing, all nodes follow the same
method as the actual senders of RTS and DATA. Basically,
a node that has overheard an RTS (DATA) records the re-
ceiver and the sender of the packet. When the node over-
hears the CTS (ACK), it checks if the recorded sender
matches the receiver of the CTS (ACK). If there is a
match, the receiver of the RTS (DATA) is a neighbor and
should be in the MAC cache. Using this method, MAC
Path traversed by data
Links learned via RTS/DATA
Links learned via CTS/ACK
A B C D
E
F
G
H
Fig. 2. Link-state information learned from RTS/CTS/DATA/ACK
cache represents the current neighborhood of a node more
accurately (see Figure 2).
2) Error Recovery: In bypass routing, error recovery
proceeds in three stages : 1) salvaging using route caches,
2) bypass recovery, and 3) error reporting (see Figure 3).
In the presence of a route failure, a node initially searches
its cache for alternate routes to the destination to salvage
a packet and records this recovery attempt in a fail-record
table. If the salvaged packet arrives at its destination, the
destination sends back an enhanced route error message
to the source to indicate the salvaged route as an alternate
to the broken route. When forwarding this information,
the repairing node snoops on the packet to update the fail-
record with the repair information. If new packets that
use the broken link in their source routes arrive at the re-
pairing node, the node continues salvaging packets using
the repair information. However, if no acknowlegment
is received from the destination the node should prevent
packets from using the recently broken link and send back
error messages to source of these packets.
In bypass routing a packet is salvaged only once. This is
important to reduce the reliance on route caches for route
recovery. Failure of the salvaged route serves as a warning
for the node detecting the failure to perform bypass recov-
ery instead of salvaging. Thereby, a node performs bypass
recovery if 1) the node does not have an alternate path to
perform salvaging, or 2) the packet has already been sal-
vaged. Specifically, the node buffers the failing packet
and all packets in the interface queue that need to use the
broken link in a fail-packet buffer. The bypass recovery
attempt is recorded in the fail-record table and a list of
nodes existing on such soon-to-fail routes is broadcast to
one-hop neighbors to see if they are neighbors with any of
those nodes. Therefore, a query reply in by-pass recovery
can fix multiple active routes.
The nodes that receive the query message search their
MAC caches for a neighbor listed in the query. The node
includes all such neighbors in its reply. To avoid query
reply storms, the nodes use a random backoff algorithm
and send a query reply only if they have not overheard an
identical query reply. When the querying node receives
