Dynamic, Ad-hoc Source Routing with Connection-Aware Link-State
Exchange and Differentiation
Wei-Peng Chen and Jennifer C. Hou
Department of Computer Science, University of Illinois at Urbana-Champaign
wchen3,jhou @cs.uiuc.edu
Abstract— In this paper, we propose an enhancement to DSR, called DSR
with Connection-Aware Link-state Exchange aNd DiffERentiation (DSRCALENDER). Specifically, to effectively collect and disseminate neighbor link
states to nodes which may potentially use them, we devise a neighbor link-state
information exchange mechanism: once a connection has been established,
the neighbor link-state information is exchanged among nodes along the route
from the source to the destination. As the information of the neighbor lists is
piggybacked in data packets, the nodes on the source route are able to learn
the partial topology around the neighborhood of the connection. In this manner, DSR-CALENDER balances the gain obtained from additional neighbor
link states and the overhead incurred to distribute them. In the case that link
failure occurs, an alternate route can be more effectively located in the route
cache of the source or the intermediate nodes, and the number of times the
route discovery phase is invoked can be reduced. To improve the quality of
route caches, we investigate all possible sources from which a node may learn
of its link states, and associate each of the sources with a different level of fidelity. In the case that a new/alternate route has to be computed, the level of
fidelity is figured into the link cost so as to locate a route that likely exists. The
simulation results show that with limited overhead incurred in neighbor list
dissemination, DSR-CALENDER outperforms DSR with either path or link
caches in terms of packet delivery ratio and route discovery overhead.
I. I NTRODUCTION
With the proliferation of mobile computing devices, the demand for
continuous network connectivity regardless of physical locations has
spurred interest in the use of tether-free, mobile ad hoc networks. We
envision such a network consisting of a massive number of small, lightweighted and low-powered mobile computing devices (called mobile
hosts, MHs) communicating with one another using wireless radios.
Two MHs are said to be neighbors if they are within the transmission
range of each other; otherwise, all message communication between
them must pass through one or more intermediate hosts. Here we assume that each device has the capability of packet forwarding (relying
an incoming packet to one of its neighboring nodes) and the transmitted
energy level can be adjusted to a level appropriate for the receiver to be
able to receive the data correctly if the receiver is within the transmission range. MHs are free to move randomly in any direction, resulting in
establishment of new wireless links or disconnection of existing links.
The rate of topology change depends on the mobility extent, and the
transmission range, of MHs.
Due to the different characteristics between static wireline networks
(such as the Internet) and mobile ad hoc networks, many protocols originally designed for wireline networks have to be adapted for ad hoc networks. For example, routing protocols must be adaptive and be able to
maintain routes in spite of the dynamic changing network topology. In
an interest to run internetworking protocols on ad hoc networks, a working group for Mobile, Ad hoc Networking (MANET) has been formed
within the Internet Engineering Task Force (IETF). Several unicast routing protocols [1], [2], [5], [6], [9], [10], [16], [17], [20]have been proposed in conjunction with the MANET working group efforts, and can
be categorized into two classes: table driven and on-demand driven routing protocols [18]. The main difference between these two classes is that
each node in table driven routing protocols proactively broadcasts the
route information it knows to other nodes, while in on-demand driven
routing protocols the route information is propagated only when a source
requests. There exists a trade-off between control overhead and route
optimization: in table driven routing protocols the latency to discover a
route is usually shorter and the route is adjusted according to topology
changes. On the other hand, the control overhead incurred in on-demand
driven routing protocols is much less than that in table-driven protocols.
Due to the limited resource and power of mobile nodes, on-demand
rather than proactive routing protocols are desirable in ad hoc networks. Among existing unicast on-demand routing protocols, the dynamic source routing (DSR) protocol [9] and the ad hoc on-demand distance vector (AODV) [17] attract perhaps the most attention. The major
differences between DSR and AODV are (i) in AODV the routing decision is made hop by hop while the sources in DSR need to determine the
whole path to destinations; and (ii) unlike DSR, which can keep multiple paths in the routing cache, AODV only record the information of
single route in the route table. For clarity of presentation, we focus on
DSR, but claim that with modest modification, the proposed approaches
can be incorporated into AODV as well. There are two major problems
associated with DSR/AODV:
a) The routing information kept at each node may become outdated
as the topology changes. When a source receives a route error message,
if there does not exist a route to the destination in its routing cache, it
invokes the route discovery phase to locate a new route. The number of
route requests/replies may be excessive in the case of frequent topology
changes, and connections suffer from service disruption during the route
discovery phase.
b) stale entry in the route cache may block the propagation of route
requests, and pollute other route caches. In DSR, the route cache is
used in the route discovery process in the following two ways: (i) before
broadcasting a route request, a sender refers to its route cache to see
if any route to a destination is available; and (ii) a node responds to a
route request and sends back a gratuitous route reply to the sender if it
knows a route to the destination, both of which significantly prevent the
route request storm problem. In the route maintenance phase, the route
cache is referred when a node attempts to salvage a transit packet so as
to increase the packet delivery ratio.) However, the incorrect gratuitous
route reply sent from intermediate nodes may block the propagation of
route requests. Not only does a sender use the stale route, but also it
cannot receive a fresh reply from the destination. Once a stale route
is used by other nodes, it pollutes their route cache. Several previous
studies [4], [7], [8], [12], [13] have indicated the negative effects of the
stale route cache.
With respect to the first problem, AODV-BR[11], AOMDV[14], and
multipath DSR[15] have been proposed to reduce route requests, while
the Location-Aided Routing (LAR)[10] intends to reduce both route requests and route replies. With respect to the second problem, route cache
strategies proposed in [8], [13] attempt to purge stale caches as early as
possible so as to prevent propagation of stale route information, avoid
link failures, and reduce route error packets. We will summarize and
categorize existing approaches and motivate our work in Section II.
In this paper, we jointly address the above two problems and propose
an enhancement to DSR, called DSR with Connection-Aware Link-state
Exchange aNd DiffERentiation (DSR-CALENDER). Specifically, to ef-
fectively collect and disseminate neighbor link states to nodes which
may potentially use them, we devise a neighbor link-state information exchange mechanism: once a connection has been established, the
neighbor link-state information is exchanged among nodes along the
route from the source to the destination. As the information of the neighbor lists is piggybacked in data packets, the nodes on the source route
are able to learn the partial topology around the neighborhood of the
connection. In this manner, DSR-CALENDER balances the gain obtained from additional neighbor link states and the overhead incurred to
distributing them. In the case that link failure occurs, an alternate route
can be more effectively located in the route cache of the source or the
intermediate nodes, and the number of times the route discovery phase
is invoked can be reduced. To improve the quality of route caches, we
propose to differentiate the sources from which a node collects the link
state. We investigate all possible sources from which a node may learn
of its link state, and associate each of the sources with a different level
of fidelity. In the case that a new/alternate route has to be computed,
the level of fidelity is figured into the link cost so as to locate a route
that likely exists. With the clever modification, DSR-CALENDER can
achieve higher delivery ratio and incur less route discovery overhead, as
compared to DSR with either path or link caches.
The rest of the paper is organized as follows. Section II summarizes
related work. Sections III–IV gives, respectively, an overview and a
detailed description of our proposed approach. Section V presents a
performance study of the proposed approach. This paper concludes with
Section VI.
II. R ELATED W ORK
In this section, we first give a succinct overview of DSR that pertains
to the proposed work. Then, we categorize existing proposals to enhance
the performance of on-demand ad hoc routing protocols with respect to
the two problems discussed in Section I. We also discuss the merits and
drawbacks of each approach and motivate our proposed work.
A. An overview of DSR
DSR is an on-demand, source routing protocol, with each packet carrying in its header the complete, ordered list of nodes through which the
packet will be routed. DSR consists of two mechanisms: route discovery
and route maintenance. When a node has a packet to send for which
it does not have a route, it initiates route discovery by broadcasting a
route request (RREQ). The request is propagated in a controlled manner through the network until it reaches either the destination node or
some intermediate node, , that knows of a route to node . Node (or
node ) then sends a route reply (RREP) to node with the new route In
the case that multiple routes are located (i.e., multiple route replies are
received), node selects the one with the best metric (e.g., hop count).
To reduce the cost of route discovery, each node maintains a cache of
source routes it has learned through route discovery or other means such
as snooping routes in route replies and data packets. Each node also operates its network interfaces in promiscuous mode, disabling the address
filtering function on each interface and causing the interface to receive
all packets that it overhears. These packets are scanned for source routes
and then discarded. All the source routes learned or overheard are aggressively used to limit the frequency and propagation of route requests.
Route maintenance is the mechanism by which a node detects
whether or not a route kept in its cache has become stale as a result
of host mobility and topology change. When an (intermediate) node
detects that the next link in a packet’s route is broken, it first sends
a route error (RRER) message to the source node that generated the
packet’s route. Node then attempts to salvage the packet by checking
its cache to see if it knows of an alternate route to the destination node.
If so, node inserts the new source route into the packet header and
forwards it on that route; otherwise, the packet is simply dropped.
As mentioned in Section I, the main drawback of DSR is that it can
not immediately adjust routes to topology changes since a source node
keeps using a route until it receives a RERR packet from intermediate
nodes. Then, if no other route in the cache of the source can reach the
destination, the source needs to send a RREQ to find a new route. The
overhead of RREQ and RREP appears in both bandwidth consumption
and transmission latency.
B. Existing Work to Enhance On-Demand Ad Hoc Routing Protocols
In order to mitigate the first problem discussed in Section I, several approaches have been proposed besides the standard route discovery/reply mechanism:
a) Multipath DSR [15]: The multipath information is carried in
route reply packets sent by the destination. When a destination receives
a route request that origins from the same source and destined for the
same destination, it sends back a route reply only if the route recorded
in the route request is disjoint from that in the route request that arrived
first. In this manner, a source has multiple, disjoint paths to a destination.
When a link failure occurs on the primary route, the source uses the
shortest alternate route to send packets. This process repeats until all the
routes kept by the source fail, and the route discovery/reply mechanism
is invoked to locate a new set of multipaths. The major drawback of this
approach is that all the multiple disjoint routes are identified in the same
route discovery phase, and may become outdated by the time they are
used.
b) Ad Hoc On-demand Multipath Distance Vector (AOMDV) [14]:
Similar to Multipath DSR, the multipath information is computed during
the route discovery phase. When an intermediate node receives a route
request that origins from the same source and destined for the same destination, if a route to the destination is available, it sends back a route
reply with node-disjoint route(s) to the source; otherwise, it forwards
the request in the same manner as AODV does. On the other hand, the
criteria taken by a destination to send link-disjoint replies is looser. This
approach suffers from the same drawback as Multipath DSR has.
c) AODV Backup Routing (AODV-BR) [11]: AODV-BR attempts
to create backup paths in intermediate nodes. The backup paths are built
by neighbor nodes of a forwarding node during the route reply phase.
When these nodes overhear the route reply, they record the node which
sends the reply as the next hop to the destination in their alternate route
table. Upon receipt of a salvaged packet sent by the node that detects
a link failure, a node can refer to its alternate route table to see if it
can rescue this packet. AODV-BR improves the packet deliver ratio,
as more routing information is kept and hence local recovery becomes
more effective. Nevertheless, the improvement is not significant due to
the following two reasons: first, similar to AOMDV, the alternate routes
are located during the same route discovery phase. Second, AODV-BR
does not reduce the number of route requests because when a route error
occurs, the route error packet is sent back all the way to the source,
which in turn triggers another route request.
d) Location-Aided Routing (LAR) [10]: As an extension of DSR,
LAR utilizes the location information obtained from the Global Positioning System (GPS) to restrict the route discovery area. For a (source,
destination) pair, a request zone is defined for the route request. A node
forwards route requests only if it is in the request zone. LAR significantly reduces the control overhead, but does not reduce the number of
times the route discovery/reply mechanism is invoked. Its dependence
on GPS also prevents LAR to be widely deployed.
e) Neighborhood Aware Source Routing (NSR) [19]: NSR enhances DSR with the notion of neighborhood awareness. With periodic
unknown neighbor links
j
h
i
known neighbor links
data connections
e
ej e
s
fj ej e
a
fgh fj ej e
hi fgh fj ej
b
hi fgh fj
c
hi fgh
e
d
f
hi
g
Fig. 1. An example of the dissemination of neighbor information
exchanges of hello messages, each node maintains the neighborhood information within two hop away. The information includes the neighbor
link states of the transmitter node, and can be used in two ways: (i) As
NSR uses link state cache (rather than path cache), a node learns from
hello packets more link states in its neighborhood which can be used in
the routing decision; and (ii) NSR can salvage packets more effectively
by searching an alternative link to one of the downstream nodes.
To deal with the second problem discussed in Section I, Hu et al. [8]
investigate the effects of updating and using route cache from three aspects, cache structure, cache capacity, and cache timeout. Two types of
cache structures, path cache and link cache, have been used in the study.
The link cache utilizes the collected information more effectively than
the path cache. Many potential paths can be found in the link cache but
not in the path cache. On the other hand, the link cache incurs higher
computation complexity and is more susceptible to the effect of stale
cache (the latter due to the fact that more stale caches exist in the link
cache structure). Marina et al. conducted another study on the route
cache [13] and proposed three mechanisms, wider error notification,
timer-based route expire, and negatives caches, all of which attempt to
relieve the effect of stale cache. Our proposed approach complements
their mechanisms and can be readily incorporated into the latter.
IV. D ETAILED D ESCRIPTION
III. OVERVIEW OF DSR-CALENDER
There are two objectives in the proposed approach — we attempt to
accommodate DSR with more routing information (in the form of neighbor link states) and use more effectively the routing information kept
in the cache. As mentioned in Section II, each node operating in the
promiscuous mode can discover its neighbors by snooping packets at no
extra cost. Instead of proactively broadcast link states through the entire
network, the proposed approach only maintains link states around the
neighborhood of established connections. Specifically, a connection is
established by the standard route discovery phase of DSR. Once a connection is established, the nodes along the path exchange either their
neighbor information (in the first data packet) or incremental changes in
their neighbor information (in subsequent data packets).
Take Fig. 1 as an example: the source node has located a route to
the destination node via nodes , , and . The dashed line represents
the neighbor relationship between two nodes. Each node piggybacks
its neighbor list in data/acknowledgment packets, e.g., node includes
in the first transit data packet the information of its neighbors and .
Neighbor relationship between , , and have been indicated in the
source route in the packet, and hence can be excluded from the neighbor
list. When receipt of a data packet, a node can learn the neighbor link
states of its upstream nodes. In TCP or other bidirectional connections,
a node can also learn the neighbor link states of its downstream nodes.
With the aid of the neighbor information, it is more likely for the source
or intermediate nodes to perform local repair and locate an alternate
route in the case that link failure occurs. As a result, the on-demand
protocol will be more robust to topology changes.
To reduce the overhead incurred in exchanging neighbor link states, a
node attaches the entire neighbor list only in the first transit data packet,
and incremental changes in its neighbor list in subsequent data packets.
In fact, it is difficult to maintain an exact and synchronized link states
of each node in ad hoc networks. Thus, our approach only intends to
maintain loose neighbor link states.
The work that comes closest to ours in the aspect of exchanging
neighbor link states is NSR [19]. Both approaches enhance DSR with
neighbor link states and keep link state information in the routing cache.
The main differences, however, lie in that NSR intends to maintain an
exact neighbor link states by having each node periodically send a Hello
packet including its entire neighbor link states. These Hello packets of
larger sizes contend for bandwidth with other packets. In contrast, our
approach does not require additional control packets but piggybacks the
(incremental) link states in data packets. By properly controlling the
size of control overhead and restricting the link state update area to the
vicinity of the data path (rather than the entire network), we ensure that
the benefits resulted from obtaining more neighbor link states outweighs
the control overhead.
To more effectively use routing cache and prevent stale route cache
entries from polluting other route caches, we devise a simple mechanism that differentiates the sources from which a node learns of the link
state. For example, the link state learned from a node’s own neighbor
(by snooping packets) is more creditable than the link state learned from
a RREP sent by an intermediate node. Similarly, the link state included
in the upstream part of a data packet’s source route is more reliable than
that in the downstream part, as the fact that the packet arrives at the node
indicates the upstream part of the source route does exist. We will provide an exclusive list of link state sources and associate them with different levels of fidelity in Section IV. Then, with minor modification to
Dijkstra’s algorithm, the proposed approach can more effectively identify and purge stale route information, and select a route that is likely to
exist.
OF
DSR-CALENDER
DSR-CALENDER consists of two component mechanisms — disseminating neighbor link state and selecting a more reliable path with
differentiation of link state sources. We describe each of the mechanism
in details in the following two subsections.
A. Dissemination of Neighbor Link States
a) Maintenance of Neighbor List: In DSR-CALENDER, each
node maintains its own neighbor list. Whenever a node receives or overhears a packet from other nodes, it learns the existence of a neighbor.
Then it adds this neighbor to its neighbor list. The neighbor list is maintained in the form of a linked list in the chronological order from the
most to the least updated neighbors. Each entry in the neighbor list
contains two timestamps: (i) the construction time: the time when the
neighbor was first learned of; and (ii) the update time: the latest time
when the node received/overheard a packet from this neighbor. If a node
receives/overhears a packet from one of its neighbors in its neighbor list,
it updates the corresponding update time and moves the entry to the head
of the neighbor list. Meanwhile, neighbor(s) from which the node has
not received/overheard any packet for NBR LINK EXPIRE TIME units
of time are purged from the list.
As compared to NSR [19], DSR-CALENDER does not require the
use of Hello packets to keep track of neighbors, but instead use a more
passive method to collect link states.
b) Dissemination Method of Neighbor Link States: With the
list of neighbors collected, the next step is to disseminate the list to nodes
which may potentially use it. Our objective is to disseminate the information inexpensively by limiting the extent to which the information
will be broadcast and the amount of link states that will be broadcast.
Specifically, DSR-CALENDER has the following characteristics:
1) Piggybacking neighbor link states in data packets: Each node
on the source route piggybacks (incremental changes of) its neighbor
link states in data packets. There are several advantages associated with
this approach: first, the neighbor link states can be propagated in an
on-demand fashion to nodes that are most likely to use them, without
introducing excessive control overheads. Second, as the nodes along the
source route have more link states available to them, they can locate alternative routes in the case of link failures. Unlike the other proposals
with multi-paths identified during the route discovery phase, the link information kept by each node in DSR-CALENDER is kept continuously
updated as data packets arrive.
2) Distributing incremental updates of neighbor link states: Another salient feature of our dissemination mechanism is that only the
changes in the neighbor list (rather than the entire neighbor list) is included and propagated in data packets. This is done by having each
node keeps track of, for each destination (but not for each connection)
what has been piggybacked in data packets. The latest time when a node
sends a packet destined for a destination is recorded. By comparing this
value to the construction time of the corresponding entry in the neighbor
list, a node can determine the incremental change in the neighbor link
states for the destination.
3) Periodically updating all neighbor link states: In a highly mobile environment, link states may become extremely unstable. To deal
with this problem, we employ the soft state approach, i.e., a link state
in the cache is purged if it has not been updated for a pre-determined
period of time. Also, a node periodically sends the entire neighbor list
to refresh link states in other nodes’ caches. In DSR-CALENDER, the
latest time when a node sends its whole neighbor list to a destination
is recorded. When a node sends a data packet destined to a destination, it checks whether the difference between this value and the current
time exceeds NBR ALL BROADCAST PERIOD. If so, the node appends its entire neighbor lists in the data packet; otherwise, only the
incremental updates are included. Note that the updates usually include
only newly added neighbors, but not deleted neighbors, unless the node
detects the link failure to the neighbor(s). This is because link entries
that are not updated will be purged in other nodes’ caches due to timer
expiry.
4) Limiting the overhead incurred in neighbor link states: It is important to limit the size of neighbor link states to be included in data
packets, because the probability of successful transmission decreases as
the packet size increases. Another reason for setting such a bound is
to de-synchronize the action of attaching the entire neighbor list to the
same packet. We impose a limit on the size of neighbor link states that
can be piggybacked in a data packet. Once the quota is depleted by
nodes upstream of a node, the node has to wait for the next data packet
to include its entire neighbor list (if need be). Furthermore, to prevent
the quota from being depleted by upstream nodes, each node adjusts
the amount of quota it is entitled to according to the length of the source
route. In DSR-CALENDER, a node can not send its neighbor link states
more than twice of its share. Moreover, a node only distributes neighbor
link states updated within NBR SPREAD TIME seconds. This prevents
potentially outdated neighbor link states from spreading to other nodes.
B. Selection of Reliable Shortest Paths
In order to fully utilize the neighbor list information, each node keeps
a link cache instead of a path cache to record the received information.
The next step is then to compute an appropriate route to a destination. As discussed in Section I, the performance of routing protocols
degrades when stale routes are selected from the cache. Worse of all,
the stale route may pollutes the other nodes’ cache. To deal with this
problem, a node has to distinguish the fidelity of the sources from which
it learns of the route, where the possible sources are forwarded packets,
route reply packets, or overheard packets. For example, a route reply
prepared by an intermediate node might contain a stale route. We classify different sources into different fidelity classes. The exclusive list
of possible sources and their assigned fidelity classes and timeout values are given in Table I. Specifically, the sources can be classified into
the following categories (the number inside the parentheses is the code
number of sources in the first column of Table I):
1) Neighbor Link States (1,9,13): The most reliable source of link
state is the node’s own neighbor. The neighbor link states spread to
other nodes might lose their fidelity because of the time latency incurred
in synchronizing link states. The update of neighbor link states is more
reliable than the complete neighbor link states of a node.
2) Source Route in Data Packets (2, 3, 4, 10, 14, 15): The source
route included in data packets is determined by the source. The upstream links of the route, which the packet has just traversed, are more
reliable. On the other hand, the downstream links might not be reliable
because the route may be determined based on stale information. The
route contained in a route request can be viewed as a special case of the
upstream links in a source route. It is, however, slightly less reliable
than the upstream links of a source route because it has not been verified
in both directions.
3) Reply Path in Route Replies (5, 6, 7, 8, 11, 12, 16, 17): A node
can distinguish whether a route reply origins from the destination or an
intermediate node, by checking the source ID of the IP packet. If it is
different from the first ID in the source route, the route reply is from
an intermediate node. The cases in which route replies are received by
the requester (case 5, 6, 16) are similar to those of source routes in data
packets. The upstream links are more reliable than the downstream links
because the downstream links are retrieved from the cache of some other
node and may be stale. On the other hand, in cases of forwarding or
snooping route replies from the destination (case 7, 11), the situation is
simply opposite. The downstream links indicated in the route reply from
a destination are more reliable than the upstream links because these
links have been verified in both directions, while only one direction is
verified for the upstream links.
In the case of snooping a route reply from an intermediate node (case
8, 12, 17) , the reply path can be divided into three parts and treated differently. Fig. 2 illustrates an example of a forwarding node processing
the reply route. A RREQ from source is replied by an intermediate
node . A RREP with the reply route, - - - , is forwarded by an
intermediate node . From the perspective of node , the reply route
can be divided into upstream, middle, and downstream parts. The middle part, from the replying node ( ) to itself ( ), is the most reliable
information in the reply route, and can be processed in the same manner in which the downstream links of a source route in the request reply
from a destination. The upstream part from itself to the source ( ) is
less reliable than the middle part, while the downstream part from the
replying node to the destination ( ) is the least reliable.
Now an entry in the routing cache consists of three fields: the fidelity,
the time of expiry, and the cost, where the fidelity and the time of expiry
are in the third and fourth columns of Table I. The notion of fidelity
classes among sources is used in the following two ways: First, we use
the hop count as as the main metric and fidelity as the auxiliary metric
in computing the shortest path. The well known Dijkstra algorithm [3]
upperstream
middle−stream
downstream
RREP from B
S
S
A B D
A
B
D
Fig. 2. An example that illustrates how the route obtained from snooping a route
reply from an intermediate node should be treated.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Source
to its own neighbor
source route of in the received data packets
upstream source route in the forwarded data
packets
upstream source route in the snooped data
packets
reply route from destinations
upstream reply route from an intermediate
node
snooping downstream reply route from a destination
snooping middle-stream reply route from an
intermediate node
updates of neighbor link states
source route in the route request packets
snooping upstream reply route from a destination
snooping upstream reply route from an intermediate node
complete set of neighbor link states
downstream source route in the snooped data
packets
downstream source route in the forwarded
data packets
downstream reply route from an intermediate
node
snooping downstream reply route from an intermediate node
Fidelity
1
2
2
Timeout
3s
5s
5s
2
5s
3
3
5s
5s
3
5s
3
5s
4
4
4
5s
5s
5s
4
5s
5
5
3s
3s
6
2s
6
2s
6
2s
TABLE I
T HE INCLUSIVE
LIST OF LINK RELIABILITY FOR ALL ORIGINS OF LINKS
is used to compute the shortest path to a destination.1 In the case of a
tie, the path with a higher fidelity value is selected. Second, fidelity is
used to prevent a stale route from being included in the route reply to a
source. A threshold is defined to restrict the routes that can be included
in gratuitous replies. If the route computed has a fidelity value that is
less than the threshold, this route is not included in the route reply and
the intermediate node will keep forwarding the route request.
V. P ERFORMANCE E VALUATION
A. Simulation Environment
We use ns-2 with the CMU Monarch extension [1], [21] to carry
out the simulation study. The simulation environment is summarized
in Table II. A detailed description of the simulation environment and
the model can found in [1], [21]. In addition, important parameters used in DSR and DSR-CALENDER are listed in Table III. The
send buffer maintained in each source can accommodate at most 64
packets. When the 65th packet arrives, the source drops the oldest packet. Besides, packets which have existed in the send buffer
for more than send buffer timeout will be purged. To prevent stale
Note that the Dijkstra algorithm is executed only if any change has occurred
in its link cache since the last retrieval; otherwise, the whole source route can
be obtained by backtracking the parent list of the destination to the source in the
shortest path tree (SPT).
Item
Propagation Model
MAC
Node number
Connection number
Simulation Time
CBR rate
Mobility Model
Range
Pause
max speed
Value
two-ray ground reflection
IEEE 802.11
50
20 and 30
300 sec.
4 packets/s
Waypoint
1500m * 500m
0 sec.
30 m/s
TABLE II
T HE SIMULATION ENVIRONMENT
Item
Send buffer size
Send buffer timeout
LINK TIMEOUT
NBR LINK EXPIRE TIME
NBR ALL BROADCAST PERIOD
NBR SPREAD TIME
MAX NBR LEN
SETTINGS
Value
64 packets
30 sec.
5 sec.
3 sec.
5 sec.
0.05 sec.
50 byte
TABLE III
T HE PARAMETER SETTINGS IN DSR-CALENDER.
links from occupying the cache, links which are not updated within
LINK TIMEOUT are purged. Similarly, a neighbor which has not
been heard of for NBR LINK EXPIRE TIME is removed from neighbor lists. In every NBR ALL BROADCAST PERIOD a node piggybacks
its entire neighbor list in a data packet, but only links updated within
NBR SPREAD TIME are appended in packets. Finally, the maximum
size for neighbor link states is restricted to MAX NBR LEN. Traffic
sources of constant bit rate (CBR) are used in the experiments.
We have considered different traffic loads and mobility in our simulation study. In particular, in what follows we report results for the cases
of 20 and 30 connections with a maximum speed ranging from 0 to 30
m/s. In each scenario, four schemes are tested: two are DSR with the
path cache and the link cache, respectively. They represent the baseline in the simulation. DSR-CALENDER is evaluated in the following
sequence: first, the neighbor link state exchange mechanism is incorporated into the link state cache. Second, the notion of fidelity is figured
into the calculation and selection of a path. The performance is evaluated with respect to the following metrics [1]: packet delivery ratio,
end to end delay, routing overhead, and overhead bytes carried in the
data packets. The packet delivery ratio is the ratio of the number of data
packets received to that sent out. The end to end delay is the average
delay incurred by all the data packets (with dropped packets excluded)
from sources to destinations. The routing overhead is the average control packets generated by sources, and includes route requests, route
replies, and route error packets. The average control bytes carried in a
data packet includes the source route information and the piggybacked
neighbor list information. This metric is used to quantify the impact of
control overhead incurred in exchanging neighbor link states.
B. Simulation Results
Fig. 3 (a) and (b) gives the delivery ratio under the case of 20 and
30 connections, respectively. In the case of 20 connections, DSRCALENDER outperforms DSR with either link or path caches. In the
case of 30 connections, the link cache is inferior to the path cache because the network is overloaded with control packets of link cache.
Max. Speed
DSR Path
DSR Link
Link+Nbr
Nbr+Reliable
0
265
1178
685
692
RERQ
10
20
340
536
1206
1251
654
728
666
783
30
632
1320
833
750
0
1571
5647
3755
2475
RERP
10
20
2497
4295
7430
6548
3781
3912
2574
2993
30
5180
8065
4706
3249
0
329
319
353
312
RERR
10
20
884
1730
840
1078
617
903
699
1177
30
2344
1695
1606
1689
TABLE IV
RREQ, RREQ, RERR
CONTROL PACKET COUNT UNDER THE
DSR-CALENDER performs slightly worse than DSR with the path
cache in the case of low mobility, but outperforms in the case of high mobility. Our two mechanisms provide more choices on alternative routes
to the source and intermediates. On the other hand, as shown in Fig. 3
(c) and (d), the approach with the use of neighbor link states performs
best, while the approach with the use of fidelity performs worst with
respect to the end-to-end delay. This is mainly caused by the longer latency incurred in responses of route requests. With the use of fidelity
threshold, a node sends a reply from its cache only when a potentially
high-fidelity route is found.
As shown in Fig. 3 (e) and (f), as compared to DSR with the link
cache (which incurs the most control overhead), DSR-CALENDER significantly reduces the normalized control overhead sent from sources.
DSR-CALENDER is also quite competitive with DSR with the path
cache. The detailed routing overhead results in the case of the 30 connections are given in Table IV. In DSR, the number of route requests
and route replies in the case of link cache is much higher than those in
the case of path cache, because the link cache approach uses the soft
state but the path cache approach uses the hard state. When a link in the
source route to a destination is purged and no other route is available in
the cache, a new route request is sent no matter whether the link is alive.
DSR-CALENDER compensates this drawback. Although the number of
RREQs in our approach is higher than that in DSR with the path cache,
the number of RREPs and RERRs are less than those in DSR with the
path cache. Fig. 3 (g) and (h) gives the overhead of neighbor link states
carried in data packets. The proportion of the overhead is about 10 % in
the overall overhead of data packets. Since we set NBR SPREAD TIME
to be only 0.05 second, only fresh link states are propagated to the other
nodes.
VI. C ONCLUSION
This paper has two contributions. First, we enhance DSR with exchange of neighbor link states in a connection-aware manner. Every
node piggybacks its neighbor link states (or the incremental changes of
them) in data packets so that the other nodes on the source route can
learn the partial network topology in the vicinity of the connection. Second, we classify the sources from which link states can be learned of
into different levels of fidelity and figure them into the calculation of
the most reliable shortest path. By properly controlling the overhead of
the neighbor link states, we have shown through simulations that DSRCALENDER achieves higher delivery ratio. Also, the number of control
packets incurred in route discovery is significantly reduced because the
neighbor link states provides more alternatives to sources when link failure occurs. The overhead of neighbor link state is small as compared to
the overhead of source route.
The proposed approaches can be applied to not only DSR but also
other link-state routing protocols. In particular, the neighbor link state
dissemination mechanism can be readily incorporated into AODV. Our
future work thus includes applying the proposed approaches to the other
on-demand link-state routing protocols. We will also look into the issue
of adjusting tunable parameters in fast-changing wireless environments.
30 CONNECTIONS
CASE .
R EFERENCES
[1] J. Broch, D. A. Maltz, D. Johnson, Y.-C. Hu, and J. Jetcheva, “A performance comparison of multi-hop wireless ad hoc network routing protocols,”
in Proc. of ACM/IEEE Int’l Conf. on Mobile Computing and Networking
(MobiCom’98), October 1998.
[2] T. Clausen et. al., “Optimized Link State Routing Protocol,” Internet draft,
IETF MANET working group, October 2001.
[3] T. H. Cormen, C. E. Leiserson, R. L. Rivest, “Introduction to Algorithms,”
, MIT Electrical Engineering and Computer Science, 1990.
[4] S. Das, C. Perkins, E. Royer, “Performance comparison of two on-demand
routing protocols for ad hoc networks,”in Proc. of INFOCOM’00, March
2000.
[5] M. Gerla et. al., “Fisheye State Routing Protocol (FSR) for Ad Hoc Networks,” Internet draft, IETF MANET working group, November 2000.
[6] M.R. Pearlman and Z.J. Haas, “Determining the Optimal Configuration for
the Zone Routing Protocol,” IEEE Journal on Selected Areas in Communications, Vol. 17, No. 8, August 1999.
[7] G. Holland and N. Vaidya, “Analysis of TCP performance over mobile ad
hoc networks,” in Proc. of ACM/IEEE 5th Int’l Conf. on Mobile Computing
and Networking (MobiCom’99), August 1999.
[8] Y.-C. Hu and D. Johnson, “Caching strategies in on-demand routing protocols for wireless ad hoc networks,” in Proc. of ACM/IEEE 6th Int’l Conf.
on Mobile Computing and Networking (MobiCom’00), August 2000.
[9] D. Johnson, D. A. Maltz, Y.-C. Hu, and J. G. Jetcheva, “The dynamic source
routing protocol for mobile ad hoc networks,” Internet draft, IETF MANET
working group, November 2001.
[10] Y.-B. Ko and N. H. Vaidya, “Location-aided routing (LAR) in mobile ad
hoc networks,” in Proc. of ACM/IEEE 4th Int’l Conf. on Mobile Computing
and Networking (MobiCom’98), October 1998.
[11] S.-J. Lee and M. Gerla, “AODV-BR: backup routing in ad hoc networks,”
in Proc. of IEEE Int’l Conf. on Computer Communications and Networks
(IC N 2000), October 2000.
[12] D. A. Maltz, J. Broch, J. Jetcheva, and D. Johnson, “The effects of ondemand behavior in routing protocols for multi-hop wireless ad hoc networks,” Special issue on mobile and wireless networks, IEEE Journal on
Selected Area in Communications, 1999.
[13] M. K. Marina and S. R. Das, “Performance of route caching strategies in
dynamic source routing,” in the Proceedings of the 2nd Wireless Networking and Mobile Computing (WNMC), Phoenix, April 2001.
[14] M. K. Marina and S. R. Das, “On-demand Multipath Distance Vector Routing for Ad Hoc Networks,” in the Proceedings of the International Conference for Network Protocols (ICNP) , Riverside, November 2001.
[15] A. Nasipuri and S. R. Das, “On-demand multipath routing for mobile ad
hoc networks,” in Proc. of IEEE Int’l Conf. on Computer Communications
and Networks (IC N 2000), October 2000.
[16] V. D. Park and M. S. Corson, “Temporally-ordered routing algorithm
(TORA) version 1: Functional specification,” Internet draft, IEEE MANET
working group, November 1997.
[17] C. E. Perkins ,E. M. Royer, and S. R. Das, “Ad hoc on demand distance vector (AODV) routing,” Internet draft, IETF MANET working group, November 2001.
[18] E. M. Royer and C.-K. Toh, “A Review of Current Routing Protocols
for Ad-Hoc Mobile Wireless Networks,” IEEE Personal Communications
Magazine, April 1999.
[19] M. Spohn and J.J. Garcia-Luna-Aceves, “Neighborhood Aware Source
Routing,” Proc. ACM MobiHoc October 2001, Long Beach, California.
[20] C.-K. Toh, “A novel distributed routing protocol to support ad hoc mobile
computing,” Wireless Personal Communication, 1997.
[21] UCB,
LBNL,
“VINT
network
simulator,”
http://wwwmash.cs.berkeley.edu/ns/.
1
0.95
0.9
0.98
Delivery Ratio (%)
Delivery Ratio (%)
0.85
0.96
0.94
0.8
0.75
0.92
0.7
path DSR
link DSR
link DSR+Neighbor
Neighbor+Fidelity
path DSR
link DSR
link DSR+Neighbor
Neighbor+Fidelity
0.9
0.65
0
5
10
15
20
25
30
0
5
10
Max. Speed (m/s)
15
20
25
30
25
30
25
30
Max. Speed (m/s)
(a) packet delivery ratio (20)
(b) packet delivery ratio (30)
40
90
85
35
80
75
25
Delay (msec)
Delay (msec)
30
70
65
60
20
55
50
15
path DSR
link DSR
link DSR+Neighbor
Neighbor+Fidelity
path DSR
link DSR
link DSR+Neighbor
Neighbor+Fidelity
45
10
40
0
5
10
15
Max. Speed (m/s)
20
25
30
0
5
(c) end to end delay (20)
path DSR
link DSR
link DSR+Neighbor
Neighbor+Fidelity
Number of normalized control packets
Number of normalized control packets
path DSR
link DSR
link DSR+Neighbor
Neighbor+Fidelity
0.6
0.3
0.25
0.2
0.5
0.4
0.15
0.1
0.3
0.2
0.1
0.05
0
0
0
5
10
15
Max. Speed (m/s)
20
25
30
0
(e) normalized control packets per data packet (20)
5
10
15
Max. Speed (m/s)
20
(f) normalized control packets per data packet (30)
25
25
20
20
Normalized overhead in data packets (byte)
Normalized overhead in data packets (byte)
20
0.7
0.35
15
path DSR: data
link DSR: data
link DSR+Neighbor: data
link DSR+Neighbor: nbr
Neighbor+Fidelity: data
Neighbor+Fidelity: nbr
10
15
Max. Speed (m/s)
(d) end to end delay (30)
0.4
10
5
0
15
path DSR: data
link DSR: data
link DSR+Neighbor: data
link DSR+Neighbor: nbr
Neighbor+Fidelity: data
Neighbor+Fidelity: nbr
10
5
0
0
5
10
15
20
25
30
0
5
10
Max. Speed (m/s)
(g) normalized overhead bytes carried in a data packet (20)
15
20
25
30
Max. Speed (m/s)
(h) normalized overhead bytes carried in a data packet (30)
Fig. 3. Performance comparison of DSR-CALENDER against DSR under the cases of 20 and 30 connections.