Quality of Service-Aware Source-Initiated Ad-hoc
Routing
Sirisha R. Medidi
Knut-Helge Vik
School of Electrical Engineering and Computer Science
Washington State University, Pullman 99164-2752
Abstract— Desirable features of routing protocols for Mobile
Ad Hoc Networks (MANETs) include ability to adapt to changing
network conditions due to mobility and provide quality control
mechanisms during the life time of a route. Current routing
protocols that provide Quality of service (QoS) for MANETs
have proposed routing based on a single QoS metric. This paper
proposes a QoS aware source initiated ad-hoc routing protocol
(QuaSAR) that adds quality control to all the phases of an ondemand routing protocol. QuaSAR gathers information about
battery power, signal strangth, bandwidth and latency during
route discovery and uses in route choosing. Additionally, our
approach has proactive route maintenance features in addition
to the reactive maintenance. We conducted simulation experiments using ns-2 network simulator and compared our results
with Dynamic Source Routing (DSR). Our performance results
demonstrate that our technique has increased throughput and
packet delivery ratio.
I. I NTRODUCTION
Mobile Ad Hoc Networks (MANETs) are infrastructure-less
networks, where the information regarding mobile nodes need
to be updated continuously. This poses a challenge for the
design of routing protocols for MANETs. Routing protocols
proposed in the literature so far can be classified as table driven
[9], [13] and on-demand [12], [14]. The table driven protocols
are proactive and incur a significant overhead. The on-demand
approaches are source initiated reactive mechanisms. These
proposals are primarily concerned with providing a route
between a given source and destination pairs. In addition to
finding a route, it is desirable to find a route that has a better
chance of surviving over a period of time from node movement
and that has better network resources like bandwidth and nodes
with longer battery life. Current proposals in the literature
have attempted to incorporate QoS metrics such as delay
and bandwidth requirements. [2], [4], [5], [21], [22]. To our
knowledge, these proposals have not been implemented or
tested.
The mobile nodes are battery constrained and selecting
routes that have low battery power would lead to frequent
disconnections of the route. Providing routes that are stable
based on route statistics could potentially reduce the communication disruption time. This can be achieved by incorporating
QoS metrics such as battery life, signal strength, bandwidth,
and latency into the routing decisions as opposed to choosing a shortest path. In this paper we propose a Quality of
Service (QoS) aware source initiated ad-hoc routing protocol,
QuaSAR, that adds quality control to all the phases of an on0-7803-8796-1/04/$20.00 (c) 2004 IEEE.
demand routing protocol. The routing decisions are based on
the metrics discussed above.
In section II we review current QoS MANET routing
protocols in the literature. We introduce the proposed Quality
of Service aware source initiated ad-hoc routing protocol in
section III. In section IV we provide performance comparison
of our routing protocol with Dynamic Source Routing (DSR).
Conclusions are presented in section V.
II. R ELATED W ORK
The Flexible QoS Model for MANETs (FQMM) in [21]
adopts the idea of DiffServ to MANETs. It is designed for
small to medium sized MANETs, with fewer than 50 nodes
and using a flat non-hierarchical topology. As in DiffServ [20]
the QoS is mapped to Per Hop Behavior (PHB) bit patterns
from the ingress (source) node and forwarded according to
these by the interior (intermediate) nodes. FQMM proposes
a hybrid between per-class and per-flow provisioning. The
highest priority traffic is given per-flow provisioning while
the other traffic types are given per-class provisioning. FQMM
assumes that the topology information is available to all the
nodes. It is not scalable and does not consider high mobility.
In [4] a distributed QoS routing scheme that selects a
network path with sufficient resources to satisfy a certain delay
or bandwidth requirement in a dynamic multi-hop mobile
environment is proposed. A multi path parallel route discovery
is used instead of flooding the network and assumes that
distance-vector routing is used [12]. Fault tolerance mechanisms that shifts traffic to neighbor nodes are introduced
when the QoS degrades to reconfigure the path around the
breaking point rather than using an entirely new path. Since [4]
uses distance-vector routing protocol it is not a very scalable
approach and high mobility would incur a massive overhead.
The Ad-hoc QoS on-demand routing (AQOR) in MANETs
AQOR [22] is a resource reservation and signaling algorithm
that provides QoS support in terms of bandwidth and end-toend delay. The paper introduces detailed computation algorithms and a model for available bandwidth calculation and
end-to-end delay in an unsynchronized wireless environment.
It reserves bandwidth on each node along a path that is being
used by the source. The reservation is done in the route
discovery phase but is not realized until the first packet has
been forwarded at a node. AQOR proposes an adaptive route
recovery model when a QoS violation has been detected. This
model makes the destination do a reverse route exploration.
108
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
The bandwidth calculation and resource reservation model in
AQOR showed promising results. It is an interesting proposal
and not tested.
The Optimized Link State Routing (OLSR) for MANETs
is a proactive QoS routing protocol [2]. It uses the table
driven link state routing protocol. OLSR exchanges topology
information with other nodes in the network regularly. Multipoint relays (MPR), are selected nodes that forward broadcast
messages during the flooding of topology information. QoS
extensions are added to the messages used for neighbor
discovery. OLSR uses an end-to-end bandwidth calculation
proposed in [23] to find the minimum bandwidth on a route.
Each node stores minimum bandwidth and maximum delay in
its routing table. A global timing structure is assumed and oneway delay information is used with a degree of certainty. The
admission control analyzes the available bandwidth to allow
the selection of an MPR by a new node. A HELLO Message
format [11] is used with a willingness field, which indicates
how willing a mobile node is chosen as an MPR point. The
selection of the MPRs is susceptible to failure with increased
mobility in the network. The condition requiring the neighbors
of MPR to be inside the transmission range makes it a very
fragile infrastructure.
In [5], a protocol that reactively collects link-state information from source to destination in order to dynamically construct a partial network topology is proposed. A
CDMA/TDMA channel model [16] is used to find routes
that satisfies the QoS in terms of bandwidth specified by the
source. End-to-end QoS guarantees are provide by assuming
that a mobile node knows the available bandwidth to all
its neighbors. They provide interesting ideas in terms of
bandwidth calculation and a multi-path route to the destination.
Using a link-state algorithm adds protocol overhead but it was
optimized by using an on-demand approach.
The proposals for QoS routing so far [2], [4], [5], [21], [22]
have not provided details to measure their effectiveness.
A. Research Challenges
There are several challenges that arise during route discovery, route choosing and route maintenance and must be
addressed for better network performance.
Route Discovery: The primary issues that degrade the network
performance in this phase are broadcast-storm problem and
route reply-storm problem. Broadcast-storm Problem arises
due to increased mobility of the nodes. More routes break
and require maintenance and hence route discovery phase has
to be initiated several times. Route requests flood the network
and the performance of the network drops. Route reply-storm
problem is a ripple effect of the broad-cast storm problem.
With each route request, there will be route replys containing
routes that may not be used are generated thereby increasing
the overhead and the possibility of a stale cache.
Route choosing: Link-stability based routing is used in Signal
Stability Adaptive Routing (SSA) [7], Associativity Based
Routing (ABR) [17], and Routelifetime Assesment Based
Routing (RABR) [1]. In addition to link-stability a routing
protocol should consider the QoS of a path.
Route Maintenance: Reactive route maintenance mechanisms
as in DSR and AODV are initiated after the route failure
has occurred. The proactive mechanisms aim to predict and
preempt route failures of any kind. The proactive proposals in
[3], [8] use the signal strength and the signal power threshold
as a means to preempt link failures. Since the signal strength
is subject to chanel fading and transient interference, using
this leads to erroneous calculations and unnecessary route
discoveries. Continuous route discoveries degrade the network
performance.
In addition to addressing these research challenges in our
routing protocol, we also present simulation results to measure
the effectiveness.
III. Q UALITY OF S ERVICE AWARE S OURCE INITIATED
A D - HOC ROUTING
Quality of Service aware Source initiated Ad-hoc Routing
(QuaSAR) adds quality control to all the important phases of
a routing protocol. In this section we first identify the phases
in QuaSAR and then describe the algorithms for the protocol.
QuaSAR has the following three phases: route discovery, route
choosing and route maintenance.
A. Route Discovery
QuaSAR is an on-demand routing protocol and finds a route
to the destination by flooding the network with a QoS route
request (QRREQ). Upon reception the destination sends a
QoS route reply (QRREP) back to the source with the entire
path. Broadcast-storm problem is an issue with on-demand
routing protocols and to alleviate this QuaSAR adds quality
control to the re-broadcasting of QRREQs. We use selective
re-broadcasting based on the current QoS of the QRREQ and
the state of the receiving Mobile Node (MN).
The following QoS metrics are used in our protocol to give
applications the opportunity to provide the Network Layer
with QoS demands that are used during the route discovery:
• Latency: The end-to-end latency the application can
tolerate.
• Bandwidth: The lowest bandwidth the application can
tolerate on the route.
• Signal Strength: This is the maximum distance that can
be tolerated between any hop in terms of percentage of
total transmission range.
• Battery Power: The Network Layer maps the estimations
of the data to be transmitted to a battery power demand.
The application layer can choose from 8 classes each for
latency and bandwidth and 3 classes each for battery power
and signal strength. The lowest battery power class is critical
since it means the node has the capability of a threshold packet
forwards before it runs out of battery. The application can also
use signal strength in route discovery, which will help to find a
stronger linked route that has a higher probability of surviving
longer. Class 3 signal strength means the MNs on the route are
all within 80 percent of transmission range, class 2 is within
109
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
100 %
90 %
80 %
Receiver
Receiver
Class 3
Class 2
Class 1
Transmitter
Receiver
iss
sm
an
Tr
ion
es
ng
Ra
Fig. 1.
Transmission range classification
90 percent, and class 1 is outside 90 percent of transmission
range as shown in Fig 1. The signal strength calculations will
be explained in more detail later.
The Route discovery in QuaSAR can be divided into two
subphases: QoS Route Request and QoS Route Reply.
QoS Route Request: QuaSAR adds a QoS header to an
ordinary route request (RREQ) packet. In the QoS Route
Request (QRREQ) we have added the following in order to
store the route statistics for later use:
• QoS Demands: Contains the QoS the current application
seeks
• QoS Available: Contains the current QoS image of the
route
Before broadcasting a QRREQ the QoS header is initialized
to the application’s requirements which is different from available QoS. Battery, signal strength and bandwidth are min/max
metrics, and are initialized appropriately to the highest class.
One-way latency could be used but that would require time
synchronization [10].
Broadcasting and flooding the network with route requests
introduces broadcast-storm problem. We address this problem
by adding a status to the route request such that nodes that have
previously propagated a QRREQ can rebroadcast a second
QRREQ only if the QoS of it is better.
When an intermediate node receives a QRREQ it records
the QRREQ id, updates the QoS variables, and records the
minimum length of the route contained in a QRREQ, the
best QoS mapped to a number according to the QoS metric
precedence rules and the current service class of the QRREQ.
(The QoS metric precedence rules are presented in Section IIIB). The QRREQ statistics are stored for each route discovery
session, and are designed to address problems that may occur
by using broadcast as means of finding routes.
Before a MN rebroadcasts a QRREQ it invokes a routine
to find the service class and the service level of the QRREQ.
If all the QoS demands are met the service class is set to
two, however if any of them were not met the service class is
set to one. If the battery on the MN is about to run out the
service class is set to zero. The service level is a statistical
number describing the QoS of the QRREQ using the QoS
metric precedence. The current QoS available are mapped to
classes and the service level is calculated from them.
To reduce the broadcast storm, QRREQs are then selectively
re-broadcast based on the service class and the service level
of the QRREQ compared to the MNs QRREQ re-broadcasting
history. A MN rebroadcasts a QRREQ iff it previously did
not process a QRREQ with better service class. If the MN
has processed a QRREQ with the highest service class the
following QRREQ must have a better service level and the
QRREQ.route.length () ≤ {2 * minQRREQLength}. The route
length is used to avoid QRREQ outliving to find long routes
that are statistically of no use.
QoS Route Reply:
In a high density network the number of routes that are
sent back to the source is very high, this creates a problem
called route-reply storm problem. Most of these routes are
never used and only waste memory. To address this issue, we
use a selective route-reply algorithm that gives the source a
wide range of routes instead of all the routes.
The destination automatically sends a QRREP to the first
threshold QRREQs that are received, afterward only selective
QRREQs are responded to. The MN stores the best QoS
metrics of the current QRREQ session, the previous hops and
the minimum length route. These variables are then used in
the selective route-reply algorithm. Only QRREQs who have
a length ≤ {minLength * 2} are considered. A QRREQ is
responded to only if the previous hop hasn’t been processed
or if it has a better QoS metric. If the minimum route length
is one hop, QuaSAR interprets it as a route length of 2. In
the case of length 2 any QRREQ route with more than 5 hops
aren’t considered. The selective route reply phase does not
execute before a threshold of QRREQs has been responded
to.
Once a QRREQ is accepted and statistics have been noted
a QRREP is unicast back to the source. QuaSAR does not
update the QoS of a QRREP since the QoS does not change
significantly during this time. Updating the QoS both ways
would consume MN battery power, steal CPU cycles and make
the source wait longer for a QRREP.
B. Route Choosing
QuaSAR employs a route discovery phase that collects route
statistics. These statistics are used in the Route Choosing phase
to find a route that is better according to the combination of
these numbers. QuaSAR records the available bandwidth, latency, signal-strength and battery power for each route during
route discovery. The route-choosing algorithm interprets and
converts these statistics to distinguish the routes efficiently.
QuaSAR uses QoS metric precedence to choose between
110
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
routes, and the application has the opportunity to choose the
ranking of the metrics. This is done because applications
have very different needs in terms of QoS. However, if the
application does not have any preferences the default metric
precedence in terms of route importance is as follows: battery
power, signal strength, bandwidth, and latency. We chose the
battery to be the most route critical metric since there is no
point in considering a weak MN which will lead to a route
break soon. Second, if there is one hop in the route with
low signal strength, it is a good idea to consider other routes
which satisfy battery power requirements. Third, if bandwidth
is not available, it would cause massive packet drops. Finally,
straming applications need an estimate of end-to-end latency
and could be used in route choosing.
C. Route Maintenance
QuaSAR has both proactive and reactive route maintenance
mechanisms where the reactive part is similar to the one in
AODV or DSR. The proactive mechanisms in QuaSAR aim
to preempt route breaks based on battery power and signal
strength estimations. Route critical incidents in MANETs may
be caused by:
• Signal strength weakening: MN is moving out of range.
• Battery power depletion: Probably disconnects soon.
• Memory shortage: Becomes selfish and drops packets.
If a MN discovers that route critical incidents are most
likely to happen, QuaSAR sends a Route Change Request
(RCR) back to the source using the reverse route informing
about the nature of the problem. Depending on the current
problem the node(s) involved are flagged by inserting them
into a RCR-table and the route choosing algorithm gives the
routes containing the element(s) less priority than other routes.
Flagging nodes as route critical is faulty if there aren’t any
update mechanisms. It is possible that nodes experiencing
battery power problems may receive more power from the
operator. In addition node movement could cause a critical
signal hop to become stronger thus invalidating RCR-table
entries. These changes are handled in QuaSAR when the route
discovery phase is initiated. As the QRREQs are propagated
the routes are checked for RCR-nodes and the intermediate
MN’s RCR tables are updated if a link has changed from
critical to better. When the source receives QRREPs it also
updates the RCR-table. A Route Change Request includes
these fields:
• Reason [ ] : The reasons for an RCR in QuaSAR may
be low signal or low battery.
• Route: The route with the RCR reason.
• Originator: The source of the RCR.
• PrevNode: If a low signal RCR is sent the low signal
link must include two MNs, the previous node and the
originator.
• NewRoute: As the RCR traverses through MNs they seek
new routes to the destination or source.
An RCR originates from a MN that operates as a router for
a currently active flow. In the case of weak link detection the
destination can also send an RCR back to the source. When
a MN receives a data packet it checks the signal strength by
which the packet was received with, and the current power
level of the MN. If any of these checks indicate that a route
break is likely to occur a proactive mechanism is initiated.
QuaSAR defines a threshold for the battery power where it
has less than a number of packet forwards before the MN dies.
The received signal strength is used to estimate when the route
breaks and issue an RCR at an appropriate time based on the
bit rate of the data flow. A description of the criteria to issue
an RCR follows next.
In [8] the received signal strength threshold is used to decide
when to start a proactive mechanism. However it may be an
incomplete approach to only consider a proactive mechanism
once the preemptive threshold has been exceeded. There is
no preemptive region in QuaSAR and hence we base the
execution of our proactive mechanism on an estimation of
how many transmissions are left before the route break. The
estimation assumes that the current trend in the received
signal strength would continue. We estimate the number of
transmissions left in the MN before it dies from the current
and previous signal strength and receive time.
A weak link is categorized by how many estimated transmissions of the data flow are left before the route breaks. If it
is below a threshold an RCR is sent. Based on the estimations
the algorithm decides whether there is time to send an RCR to
the destination in order to trigger a RCR/QRREP or if it needs
to send an RCR directly to the source. The source must be able
to complete a route discovery before the route breaks. Once
proactive mechanisms are used they must be exploited to the
fullest – QuaSAR uses RCRs both as a notifying mechanism
and as a unicast route discovery. The RCR is sent out using the
active route and forwarding MN checks if it has a new route
that does not contain the same or more severe RCR-reasons.
The RCR-reasons and the routes are prioritized during route
choosing with the most critical first:
1) Low battery powered node and a low signal hop.
2) Low battery powered node.
3) Low Signal hop.
If an the RCR was sent to the destination it checks if the
RCR contains any route suggestions and compares it to routes
it has in its own cache. If a route is found a RCR/QRREP is
unicast back to the source otherwise the RCR is dropped. If the
problem persists at the RCR originator it now sends an RCR
back to the source applying the same algorithm, only now the
MNs tries to find a route to the destination. The source checks
for routes and initiates a route discovery if it fails to find a
route that satisfies its QoS demands. To avoid continuous route
discoveries QuaSAR restricts the interval to every threshold
seconds.
IV. S IMULATION E XPERIMENTS
QuaSAR was implemented in ns-2 Network Simulator [18].
The performance metrics we used are throughput, packet
delivery ratio and latency metrics which are all standard
measurements. We tested the protocol overhead in the network
111
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
in terms of the number of protocol packets received by any MN
per data packet received by the destination. To our knowledge
Signal Strength aware Routing Protocols have not been tested
in terms of throughput before. We conducted two types of
experiments: a fine grain simulation to capture the features of
QuaSAR and another to test the protocol performance with
different mobility models.
200
300
400
500
600
Source Static
100
200
Strong Antenna 4 Mbps
Strong Antenna 4 Mbps
A. Fine Grain
The purpose of the fine grain simulation is to create a
small environment that capture the features of the protocols.
We designed the network to have 8 MNs with different QoS
features in the network to take advantage of the QoS support
in QuaSAR. The goal was to place MNs within reach of the
destination and loose connection to the destination at some
time during the simulation. Simultaneously at least one MN
must be within reach of the destination at all times.
•
•
•
•
Weak MNs: The weak MNs are stationary and have a
link capacity of 128 Kbps and are placed in the grid one
hop away from the destination as shown in Figure 2. The
weak connections are lost when the destination moves.
Strong Antennas: Four static antennas with a link capacity of 4 Mbps are placed in a way that {1,2} and {3,4}
can communicate, in addition 2 and 4 has a connection
to the destination but loose connection when it moves.
Source Node: The source is placed within range of the
two closest antennas and all the weak MNs to have a
weak connection with the three weak MNs and a strong
link to the antennas. The source sends at a constant bit
rate (CBR) of 50 packets/second, where one packet is 512
bytes. The source requires a minimum bandwidth of 200
Kbps on the route to avoid bottleneck packet drops. The
QoS demands of the destination include a class 3 signal, a
bandwidth of 2 Mbps and compatible end-to-end latency.
Destination Node: The destination is designed to move
back and forth such that it looses its connection to all but
the closest strong antenna at the end points. This fulfills
the goal of having at least one link to the destination at all
times. The speed of the node is 10 m/s and it moves 200
meters in east and west direction. The starting point of
the destination node is {450, 470} and it moves between
{350, 470} and {550, 470}. It completes one round trip
in 40 seconds.
The transmission range is 250 meters for all the involved
nodes. The simulation lasted 80 seconds, which was enough
for the destination to perform two patrol rounds. Since none
of the quality of service routing algorithms proposed in the
literature have evaluated their performance with respect to
the performance metrics we have considered, we compare our
algorithm with a generic shortest path routing algorithm. For
the purpose of fairness, application is considered to require
the i strongest signal strength demand. That is class 3 signal
strength, which means the MN is within 80 percent of the total
transmission radius.
Discussion
Weak MNs 128 Kbps
300
400
Strong Antenna 4 Mbps
Strong Antenna 4 Mbps
500
Destination Moving
Fig. 2.
Fine Grain Simulation Environment
TABLE I
F INE G RAIN S IMULATION R ESULTS
Throughput
QuaSAR
Shortest Path
48.2
45.1
Packet
del. ratio
99.1
93.9
Protocol
overhead
0.038
0.023
Latency
0.035
0.056
The results from the fine grain simulation are summarized in
Table I. The experiment captures the problems shortest path
routing has when a network consists of MNs with diverse
QoS. Our algorithm is aware of the battery power, signal
strength, bandwidth and end-to-end latency of a route and
naturally choose longer routes instead of shorter routes if the
QoS demands are not met with the shorter routes. The signal
strength between the weak MNs and the destination is class
1, which is outside 90 percent of transmission range.
Algorithms based on shortest route exhausts all the routes
starting with the shortest, which in this scenario consist of the
weak MNs routes before trying any longer routes. The two
best routes in terms of QoS are the strong antenna routes. This
is because these routes would stay up longer than any other
routes in the scenario. Since mobility of the nodes destroy
these routes, route discovery must be initiated on a regular
basis. Hence routing based on shortest path will rediscover
the weak MN links and the problem starts all over again.
QuaSAR on the other hand switches between the two
antenna routes as the source receives a Route Change Request
(RCR) before the link is about to break. This switching
diminishes the communication disruption time and the packet
loss ratio.
The throughput increased by 3 packets/second. A packet
size of 512 bytes results in an increased throughput of 12
Kbps, a considerable improvement in such a scenario. The
112
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
TABLE II
C OURSE G RAIN M OBILITY C ATEGORIES
Mobility
Low
Medium
High
Max Speed (m/s)
4
10
20
Pause Time (seconds)
30
20
10
throughput increase is a result of the quality control in
QuaSAR.
It can be seen from the packet delivery ratio that shortest
path algorithm has a significantly higher number of dropped
packets than QuaSAR. QuaSAR has a delivery ratio of 99.1
percent whereas shortest path algorithm is on 93.9 percent.
The proactive route maintenance along with the QoS metrics in
QuaSAR diminishes the packet loss by choosing more reliable
routes and notifying the source when route critical incidents
in progress increase. Since the routes with the weak MNs
do not meet the signal strength demands the source initiates
a new route discovery when a strong antenna route breaks.
The selective re-broadcasting feature QuaSAR has is not an
important factor in the overhead as the node density is small.
The simulation results demonstrate that using the proactive
route maintenance in QuaSAR increases the throughput and
the packet delivery ratio. To our knowledge this has not been
studied before.
B. Course Grain
The course grain simulation is based on tools that create
an environment based on certain distinctive scenario types.
A randomly generated environment is a good pin pointer to
whether an implementation performs well. Since we are using
tools to randomly generate a network it is not very reliable
to give results based on only one simulation. Next we present
the simulation setup, results and an analysis.
Setup: The network was setup with 50 MNs in a 700 meters
by 700 meters sized grid. Nodes were generated with random
QoS. All the active nodes were initialized with the same QoS.
They have a minimum bandwidth of 0.5 Mbps and a maximum
bandwidth of 4.5 Mbps. The design includes 2 % of the MNs
run out of battery. All the nodes were given the same QoS
demands for each simulation for the purpose of uniform testing. The transmission range was statically set to 250 meters,
which means that every MN has at least seven neighbors and
at most 21 neighbors with a uniform distribution. Simulation
experiments were conducted with three different levels of
mobility as shown in Table II. The simulations were run for
100 seconds.
Communication and Movement Patterns: A network needs
communicating nodes to be able to test a routing protocol.
We used CMU’s traffic-pattern-generator [15] to randomly
produce the communication patterns for our experiments.
Choosing a maximum of 10 active nodes in the network
translates to maximum 20 percent of the nodes being active
at the same time. This number indicates that the network is
reasonably active. For a packet size of 512 bytes, choosing
3 packets/second translates to one node transmits at a rate of
12 Kbps. We primarily intended to test signal strength routing
and the proactive route maintenance features of QuaSAR and
by choosing a CBR this low we lessened the importance of
choosing a high link capacity route.
QuaSAR has mechanisms that are triggered by mobility,
thus we needed to simulate node movements as well. Mobility
models can be classified into entity models and group models.
In the entity models the actions of the MNs are completely
independent. On the other hand in a group model there are
several MNs that move together such as the core of a platoon
formation. Group mobility is of a cooperative nature.
We used a tool bonnMotion [6] for the movement pattern
generation. BonnMotion is Java software that creates and
analyses mobility scenarios. BonnMotion supports Random
Waypoint, Gauss Markov and Manhattan Grid model that are
entity models. Additionally it supports Reference Point Group
Mobility Model which is a group model.
Wireless Channel Model: As mentioned in section III-C we
assume a TwoRayGroundModel [19] to be the platform for
initiating the proactive maintenance based on signal strength
weakening in our simulations.
Analysis: We have conducted experiments will all the above
mentioned model. Since Random Waypoint and Gauss Markov
Models are similar, we present th e results together. The results
for Random Waypoint and Reference Point Group Model are
presented seperately. We compared our results with DSR.
Random Waypoint: QuaSAR performs better than DSR in
terms of throughput and packet delivery ratio. With Random
Waypoint the throughput of QuaSAR is higher. However for
Gauss Markov Model the throughput drops at a similar rate for
QuaSAR and DSR with QuaSAR performing slightly better.
This is due to the randomness of a walk in the Gauss Markov
Model where MNs don’t walk in a straight line and the speed
varies. The packet delivery ratio is close to 100 percent since
the grid is small and the node density is high, but the tendency
is clearly in favor of QuaSAR. One of the goals of having
quality control in QuaSAR was to make it choose better routes
yielding a higher probability of a successful delivery.
QuaSAR has a higher number of (protocol packets)/(packets
received), the protocol overhead, than DSR. The proactive
route maintenance of QuaSAR and the QoS demands makes
the source look for routes more often than DSR. When a route
critical incident occurs and an RCR packet is received by the
source it results in a route discovery phase being initiated. This
can happen when the source doesn’t have a route that satisfies
the QoS demands and a route discovery hasn’t been performed
in the last ten seconds. In addition selectively re-broadcasting
with high node density causes a growth in QRREQs in the
network. If the average number of neighbors is 21 the selective
re-broadcasting overhead is a function of (x ∗ 21) where x
is the number of re-broadcasts. This is the main reason why
QuaSAR has a higher number of (protocol packets)/(packets
received).
The latency measured as (mean latency)/packet is about the
same. We had expected QuaSAR to have a slightly higher latency than DSR. The explanation may be that QuaSAR selects
113
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
Random Waypoint
Random
Random Waypoint
Waypoint
1.7
QuaSAR
DSR
12
QuaSAR
QuaSAR
DSR
DSR
Protocol Packets/Delivered
Packets/Delivered Packet
Packet
Protocol
1.68
Throughput (packets/second)
(packets/second)
Throughput
1.66
1.64
1.62
1.6
1.58
1.56
10
8
6
4
2
1.54
1.52
0
1.5
4
8
6
10
12
Mobility (m/s)
14
16
18
Fig. 6.
Fig. 3.
10
8
6
4
20
12
Mobility (m/s)
14
16
18
20
Random Waypoint: Protocol Packets/Delivered Packet
Random Waypoint: Throughput
Gauss
Gauss Markov
Markov Model
Model
1.7
Random Waypoint
1
QuaSAR
QuaSAR
DSR
1.68
QuaSAR
DSR
1.66
Throughput (packets/second)
(packets/second)
Throughput
(received/sent)
Packet Delivery Ratio (received/sent)
0.98
0.96
0.94
1.64
1.62
1.6
1.58
1.56
1.54
0.92
1.52
1.5
0.9
4
6
Fig. 4.
8
10
12
Mobility (m/s)
14
16
18
QuaSAR
DSR
Mean Latency/Delivered Packet (sec)
0.018
0.016
0.014
0.012
0.01
0.008
0.006
Fig. 5.
8
Fig. 7.
Random Waypoint
6
6
10
12
Mobility (m/s)
14
16
18
20
Gauss Markov: Throughput
Random Waypoint: Packet Delivery Ratio
0.02
4
4
20
20
8
10
12
Mobility (m/s)
14
16
18
Random Waypoint: Mean Latency/Packet
20
routes with better QoS for example, bandwidth. Eventhough
the routes are longer, the latency is still low.
Although the increase in throughput is very slight we believe
that in a tougher environment with sources demanding more
bandwidth the tendency would be stronger. The packet delivery
rate is noticeably higher, which is evidently because QuaSAR
chooses more robust routes than DSR.
Manhattan Grid Model: The throughput statistics show that
the Manhattan Grid Model has a higher throughput on average
both for QuaSAR and DSR than Random Waypoint and Gauss
Markov when the mobility increases. Having a mobility of
20 m/s in a city model is not very realistic, but for the
purpose of investigating worst case scenarios we chose to
include this high mobility. QuaSAR has a slightly higher
throughput than DSR in this model as well. The same behavior
as with Random Waypoint and Gauss Markov can be seen
with the other statistics. The mean latency is about the same,
(protocol packets)/(packets received) is higher with QuaSAR
114
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
Manhattan Grid Model
Gauss Markov Model
1
QuaSAR
DSR
QuaSAR
DSR
1.7
Throughput (packets/second)
(packets/second)
Throughput
Packet Delivery Ratio (received/sent)
0.98
0.96
0.94
1.65
1.6
1.55
0.92
0.9
1.5
6
4
8
Fig. 8.
10
14
12
Mobility (m/s)
16
18
4
20
Fig. 11.
Gauss Markov: Packet Delivery Ratio
18
16
20
Manhattan Grid Model
0.035
QuaSAR
DSR
DSR
QuaSAR
DSR
0.03
(sec)
Mean Latency/Delivered Packet (sec)
0.03
Mean Latency/Delivered
Latency/Delivered Packet
Packet (sec)
(sec)
Mean
14
Manhattan Grid: Throughput
Gauss Markov Model
0.035
0.025
0.02
0.015
0.025
0.02
0.015
0.01
0.01
0.005
12
Mobility (m/s)
10
8
6
0.005
6
4
10
8
Fig. 9.
12
Mobility (m/s)
14
16
18
20
4
8
6
Fig. 12.
Gauss Markov: Mean Latency/Packet
10
12
Mobility (m/s)
14
16
18
20
Manhattan Grid: Mean Latency/Packet
Manhattan Grid Model
Gauss Markov Model
1
20
QuaSAR
DSR
QuaSAR
DSR
Packet Delivery Ratio (received/sent)
Protocol Packets/Delivered Packet
0.98
15
10
5
0.96
0.94
0.92
0.9
0
4
6
Fig. 10.
8
10
12
Mobility (m/s)
14
16
18
4
20
6
8
Fig. 13.
Gauss Markov: Protocol Packets/Delivered Packet
115
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
10
12
Mobility (m/s)
14
16
18
Manhattan Grid: Packet Delivery Ratio
20
Manhattan Grid Model
Reference Point Group Model
66
QuaSAR
DSR
QuaSAR
QuaSAR
DSR
0.014
Mean Latency/Delivered
Latency/Delivered Packet
Packet (sec)
(sec)
Mean
Protocol Packet/Delivered
Packet/Delivered Packet
Packet
Protocol
55
44
33
22
0.012
0.01
0.008
11
0.006
0
6
4
8
Fig. 14.
10
12
Mobility (m/s)
14
16
20
18
4
Manhattan Grid: Protocol Packets/Delivered Packet
6
Fig. 16.
10
8
12
Mobility (m/s)
14
16
18
20
20
Reference Point Group: Mean Latency pr. Packet
Reference Point Group Model
1.7
Reference Point Group Model
QuaSAR
DSR
11
1.68
QuaSAR
DSR
0.98
0.98
1.64
Packet Delivery Ratio (received/sent)
Throughput (packets/second)
1.66
1.62
1.6
1.58
1.56
1.54
0.94
0.94
0.92
0.92
1.52
1.5
0.96
0.96
4
6
8
Fig. 15.
10
12
Mobility (m/s)
14
16
18
20
0.9
0.9
88
66
44
10
10
12
12
Mobility (m/s)
14
16
16
18
18
20
20
Reference Point Group: Throughput
Fig. 17.
V. C ONCLUSIONS AND F URTHER R ESEARCH
In this paper we proposed a Quality of Service aware
source initiated ad-hoc routing protocol, QuaSAR, that adds
quality control to all phases of an on-demand routing protocol.
The QoS metrics incorporated into the routing algorithm
are: battery life, signal strength, bandwidth, and latency. We
have conducted simulation experiments using ns-2 network
simulator and compared the results with shortest path routing.
To our knowledge this is the first implementation of a Quality
Reference Point Group Model
10
QuaSAR
DSR
8
Protocol Packets/Delivered Packet
than with DSR. The delivery rate shows that QuaSAR on the
average picks routes that have a higher chance of successfully
delivering a packet.
Reference Point Group Model (RPGM): The same behavior
was seen with this group model in terms of throughput, (protocol packets)/(packets received) and delivery ratio. However,
QuaSAR has lower (mean latency)/packet than DSR for this
group model. This may be because RPGM is a group model
and routes are fairly stable.
Reference Point Group: Packet Delivery Ratio
6
4
2
0
4
Fig. 18.
6
8
10
12
Mobility (m/s)
14
16
18
20
Reference Point Group: Protocol Packet pr. Delivered Packet
116
0-7803-8797-X/04/$20.00 (C) 2004 IEEE
of Service aware Ad-hoc Routing Protocol based on several
QoS metrics. First we constructed an experimental setup with
8 mobile nodes to demonstrate the capability of QuaSAR, and
next we conducted experiments in a 50 node network with
several mobility models. Our simulation results confirm that
using signal strength as a means of choosing and maintaining
routes yields higher throughput and delivery ratio. We intend
to test the algorithm with TCP traffic.
R EFERENCES
[1] Sulabh Agarwal, Ashish Ahuja, Jatinder Pal Singh, and Rajeev Shorey.
Route-Lifetime Assessment Based Routing (RABR) Protocol for Mobile
Ad-Hoc Networks. In ICC (3), pages 1697–1701, 2000.
[2] Khaldoun Al Agha Anelise Munaretto, Hakim Badis and Guy Pujolle.
A Link-state QoS Routing Protocol for Ad Hoc Networks. Technical
report, 2002.
[3] Azzedine Boukerche and Liqin Zhang. A preemptive on-demand distance vector routing protocol for mobile and wireless ad hoc networks. In
Proceedings of the 36th Annual Simulation Symposium, page 73. IEEE
Computer Society, 2003.
[4] Shigang Chen and Klara Nahrstedt. A Distributed Quality-of-Service
Routing in Ad-Hoc Networks. IEEE Journal on Selected Areas in
Communications, 17(8), August 1999.
[5] Yuh-Shyan Chen, Yu-Chee Tseng, Jang-Ping Sheu, and Po-Hsuen Kuo.
On-Demand, Link-State, Multi-Path QoS Routing in a Wireless Mobile
Ad-Hoc Network.
[6] Michael Gerharz Christian de Waal. BonnMotion (c), 2002-2003.
[7] R. Dube, C. Rais, K. Wang, and S. Tripathi. Signal stability based
adaptive routing (SSA) for ad hoc mobile networks, Feb 1997.
[8] Tom Goff, Nael Abu-Ghazaleh, Dhananjay Phatak, and Ridvan Kahvecioglu. Preemptive routing in ad hoc networks. J. Parallel Distrib.
Comput., 63(2):123–140, 2001.
[9] David B Johnson and David A Maltz. Dynamic Source Routing in
Ad Hoc Wireless Networks. In Imielinski and Korth, editors, Mobile
Computing, volume 353. Kluwer Academic Publishers, 1996.
[10] R. Kay. Time synchronization in ad hoc networks. In Proceedings of
the 2nd ACM international symposium on Mobile ad hoc networking &
computing, pages 173–182. ACM Press, 2001.
[11] J. Moy. The OSPF Specification. Technical Report 1131, 1989.
[12] Shree Murthy and J. J. Garcia-Luna-Aceves. A Routing Protocol for
Packet Radio Networks. In Mobile Computing and Networking, pages
86–95, 1995.
[13] C. Perkins. Ad-hoc on-demand distance vector routing, Nov 1997.
[14] Charles Perkins and Pravin Bhagwat. Highly Dynamic DestinationSequenced Distance-Vector Routing (DSDV) for Mobile Computers.
In ACM SIGCOMM’94 Conference on Communications Architectures,
Protocols and Applications, pages 234–244, 1994.
[15] The Rice Monarch Project. Traffic Pattern Generator for Network
Simulator (ns) (version 2).
[16] S. Ramakrishna and J. Holtzman. A Scheme for Throughput Maximization in a Dual-Class CDMA System, Oct 1997.
[17] Chai-Keong Toh. Associativity-based routing for ad hoc mobile networks. Wirel. Pers. Commun., 4(2):103–139, 1997.
[18] UCB/LBNL/VINT. Network Simulator (ns) (version 2).
[19] UCB/LBNL/VINT. Network Simulator (ns) (version 2) Documentation.
[20] P. White. RSVP and integrated services in the internet: A tutorial, May
1997.
[21] H. Xiao, W. Seah, A. Lo, and K. Chua. A Flexible Quality of Service
Model for Mobile Ad-Hoc Networks.
[22] Qi Xue and Aura Ganz. Ad hoc qos on-demand routing (AQOR) in
mobile ad hoc networks. J. Parallel Distrib. Comput., 63(2):154–165,
2003.
[23] C. Zhu and M. Corson. QoS routing for mobile ad hoc networks, June
2001.
117
0-7803-8797-X/04/$20.00 (C) 2004 IEEE