A Bandwidth-Reservation Mechanism for On-Demand Ad hoc Path Finding
Irina Gerasimov and Robert Simon
Center for Image Analysis
Department of Computer Science
George Mason University
Fairfax, VA, 22030
{igerasim, simon}@cs.gmu.edu
ABSTRACT
One of the major challenges faced by designers of ad hoc
network systems is the deployment of end-to-end quality-of-
service support mechanisms. This paper describes QoS-
AODV¸ an integrated route discovery and bandwidth
reservation protocol. QoS-AODV is designed to operate
within a TDMA network. Unlike other path finding and
route discovery protocols that ignore the impact of the data
link layer, QoS-AODV incorporates slot scheduling
information to ensure that end-to-end bandwidth is actually
reserved. Further, QoS-AODV is an enhanced version of
the Ad hoc On-demand Distance Vector routing protocol,
and is therefore compatible with proposed route discovery
and maintenance techniques. In order to test the
effectiveness of our protocol we implemented a version of
QoS-AODV, along with two similar protocols, in the ns-2
simulator. Our experiments showed the QoS-AODV
significantly improved the probability of being able to find
an end-to-end QoS path.
Key Words: Ad hoc Networking, Ad Hoc QoS routing,
QoS over AODV.
1. Introduction
The new generation of wireless mobile computers can
temporarily form multi-hop networks without the aid of a
fixed infrastructure. This activity is usually called ad hoc
networking. As this technology matures, ad hoc networks
will increasingly need to support distributed multimedia
communication. In a traditional wired network, supporting
multimedia communication involves using some number of
widely studied quality-of-service (QoS) algorithms for
routing and resource reservation. However, due to
unpredictable and potentially rapid changes in route and
bandwidth availability, significant challenges need to be
addressed before QoS techniques can be deployed in ad hoc
environments.
Supporting QoS in an ad hoc environment entails the
coordination of several system activities. The first is route
Proceedings of the 35th Annual Simulation Symposium (SS’02)
1080-241X/02 $17.00 © 2002 IEEE
discovery and route repair. Since ad hoc network topologies
are highly dynamic, routes between two nodes often need to
be produced or discovered upon demand, at the time of
connection establishment in the case of a QoS connection,
since previous routes may no longer exist. Route repair is
concerned with finding a new route during the lifetime of a
connection, because the existing route has “broken”, due to
node mobility or transmission impairment. The second
system activity consists of resource reservation for QoS
connections. This often involves allocation of resources at
the data link or MAC level. An example of this is the
reservation of slots in a TDMA frame. The problem of
resource reservation at the data link level is complicated in
an ad hoc environment, for two reasons. The first is the
mobility problem, and the second is the so-called “hidden
terminal” problem. A hidden terminal in a wireless system
is due to two nodes transmitting simultaneously to a third
node, such that the two nodes that are transmitting are out of
each other’s range. However, their transmissions are garbled
at the third node, which can hear them both.
This paper describes a novel solution to the QoS path
finding problem in ad hoc networks. We present QoS-
AODV, a protocol that combines on-demand routing with an
efficient MAC layer resource reservation mechanism. The
protocol is a modified and enhanced version of the Ad hoc
On-demand Distance Vector (AODV, [Perkins1999]). In
particular, we have introduced link and path bandwidth
calculation mechanisms and a resource reservation protocol
into the original AODV protocol. The outcome is a QoS
path finding mechanism that maximizes the likelihood of
finding routes that can support QoS traffic requirements in
ad hoc networks. Although the focus of our work is on
bandwidth reservation within a TDMA framework, our
technique can be extended to other data link layer resource
reservation issues.
In order to test the performance of our protocol we have
implemented QoS-AODV in the ns-2 simulator [Ns2]. We
also defined and implemented two other QoS path-finding
protocols, and ran an extensive series of performance tests to
assess the relative effectiveness of our approach. Our results
 indicate that for a variety of mobility scenarios QoS-AODV
substantially increases the likelihood of being able to find
suitable paths that meet the QoS requirements of a
multimedia connection.
The paper proceeds as follows. Section 2 describes
related work and gives some background in the AODV.
Section 3 presents the details of QoS-AODV. Section 4
describes our performance study, and Section 5 offers some
concluding remarks.
2. Background
QoS-AODV is a combined route discovery and
bandwidth reservation mechanism for providing end-to-end
QoS in an ad hoc environment. This section first describes
related work in QoS routing over ad hoc systems. We then
provide a brief overview of the original AODV protocol.
2a) Related Work
There are several major approaches for QoS routing and
resource reservation in ad hoc networks. Here we present
some current proposals related to our work. The first
approach is based on distributed on-demand path search,
which uses known link bandwidth between nodes. An
example of this approach is contained in [Chen 1999]. Due
to the distributed path calculation, this approach is scalable.
Further, by limiting the number of path search requests
flooding is prevented. Although scalability and limited
protocol overhead are clearly desirable in all ad hoc QoS
routing techniques, we believe there are potential drawbacks
to this approach. In particular, the path finding procedure is
not designed to take advantage of QoS information available
at the MAC layer. This in turn can lead to underutilization
of network capacity. The second approach of QoS
implementation over ad hoc networks [Chen 1997], [Lin
1999], [Lin 2000] and [Ho 2000] focuses specifically on the
MAC layer. It is based on reservation of node MAC layer
Time or Code Division Multiple Access (TDMA or CDMA)
time slots. In this approach, one or several paths to
destination are discovered, regardless of the link bandwidth
available on nodes along those paths. Only after the path is
discovered, is the path bandwidth to the destination node
calculated. However, requiring the complete path
information has several potential drawbacks, such as low
scalability, poor tolerance to fast topology changes,
calculations overhead, message flooding, etc.
QoS-AODV uses some of the scheduling mechanisms
presented in [Lin 1999]. However, our QoS approach is
different from the above solutions in that we incorporate
QoS path finding based on bandwidth-scheduling
mechanism into an already existing ad hoc non-QoS routing
Proceedings of the 35th Annual Simulation Symposium (SS’02)
1080-241X/02 $17.00 © 2002 IEEE
protocol. Moreover, our routing algorithm is fully aware of
the bandwidth resource availability that was done by
coupling together routing and MAC TDMA layers.
2b) The AODV routing protocol
The starting point for our protocol was to modify an
existing on-demand routing protocol for best effort ad hoc
networking. We took the Ad hoc On-Demand Distance
Vector protocol (AODV) [Perkins1999]. AODV uses a
broadcast route discovery mechanism, and it relies on
dynamically established routing table entries at intermediate
nodes. The functions performed by AODV protocol include
local connectivity management, route discovery, route table
management and path maintenance.
Local connectivity management happens as follows.
Nodes learn about their neighbors by either receiving or
sending broadcast packets from or to their neighbors.
Receiving the broadcast or HELLO from a new neighbor, or
failing to receive HELLO messages from a node that was
previously in the neighborhood, indicates that the local
connectivity has changed.
The source node initiates path discovery by broadcasting
a route request, RREQ, packet to its neighbors. When a node
receives an RREQ, in case it has routing information, it
sends the reply, RREP, packet back to the destination.
Otherwise, it rebroadcasts the RREQ packet further to its
neighbors. As the RREQ packet travels from the source to
the destination it automatically sets up the reverse path from
all nodes back to the source. As the RREP travels back to the
source, each node along the path sets up a forward pointer to
the node from which the RREP came and updates its timeout
information for route entries to the source and destination.
For each destination of interest a node maintains a single
route table entry that contains the address of the destination,
the next hop along the path to that destination, the number of
hops to the destination, and other route related parameters. If
a node is presented with two different routes to the
destination it chooses the fresher route. If both routes were
discovered simultaneously, the route with fewer hops is
preferred.
Path maintenance is performed in several ways. When
any node lying along an established path moves so that some
of the nodes become unreachable, a special RREP message
is send to affected source nodes. Upon receiving notification
of a broken link, the source node restarts the path discovery
process, if it still requires that route.
The design of AODV protocol does not have QoS
functionality. Since it is in the class of best-effort ad hoc
routing protocols, AODV does not take into account the
underlying data link layer and features of transmission over
wireless media.
 3. QoS-AODV protocol
This section defines our protocol, called QoS-AODV.
QoS-AODV performs path search simultaneously with time
slot scheduling by using simple heuristic algorithms. When
paths having the required QoS characteristics are
discovered, the protocol creates Virtual Connections by
reserving MAC TDMA time slots along one of those paths.
We first present a description of how we augmented pure
AODV with QoS capabilities. There we explain how nodes
exchange and calculate their time slot schedules and how we
calculate link bandwidth between the nodes. Then we
demonstrate how AODV path discovery was augmented with
our path bandwidth scheduling mechanism and explain how
that mechanism works. At the end of the section, we describe
our reservation protocol that is able to create, maintain and
release Virtual Connections.
3a). Time slot information calculation
The QoS-AODV protocol is coupled with the underlying
MAC TDMA protocol. Each MAC TDMA frame consists
of two phases, a control phase and a data phase. The control
phase is divided into number of slots that equal to the
maximum number of nodes in the ad hoc cluster. An ad hoc
cluster is defined as a set of mobile hosts that exchange
messages between each other. Due to node mobility, nodes
can join or leave at any time. Nodes of one ad hoc cluster are
not able to receive messages from another ad hoc cluster;
otherwise, both clusters need to be considered as a single
group in order to prevent packet collisions. Slot scheduling
is not negotiated between nodes in the control phase, since
each node transmits during its own time slot. This way each
node has a chance to transmit its control packets that include
AODV, MAC and messages of other network control layers
without collisions.
The data phase is used for transmission of application-
layer packets and it consists of a limited number of slots.
Each node keeps information about its and its neighbor time
slots that are used for send and receive. This time slot
information is presented as a schedule. We define a schedule
as a sequence of the numbers 0 or 1, where each number is
the order number of the time slot in the phase. We call a
node a neighbor of another node if those nodes are in the
transmission range of each other. It is necessary for each
node to calculate which are slots are available for send and
receive to its neighbors. In Figure 1 we show how to
calculate this information for a node A.
free_recv_slots(node A) =
^(send_slots(node A) | recv_slots(node A))
free_send_slots(node A) =
free_recv_slots(node A) ^
recv_slots(node A neighbors)
Proceedings of the 35th Annual Simulation Symposium (SS’02)
1080-241X/02 $17.00 © 2002 IEEE
Figure 1. Calculation of node time slot
scheduling. The notation c=a^b means that c is a
schedule received from a schedule a after slots of
a schedule b were extracted from a. The c=a|b
means that c includes slots of both schedules, a
and b.
Send_slots(node A) and recv_slots(node A) are the slots
that node A uses for sending and receiving of data packets to
its neighbors. Recv_slots(node A neighbors) are the slots that
the neighbors of node A use for receiving of data packets
from node A and other neighbors.
We distinguish between free_send_slots and
free_recv_slots terms. Free_recv_slots are node slots that
are not used for receiving or sending data packets from that
node. Those slots can include the slots used by node
neighbors to receive data packets from their neighbors. In
case of the calculation of free_send_slots of a node, the slots
used for receiving by that nodes neighbors must be taken
into consideration, since scheduling those slots for sending
from the node does lead to collision at node neighbors, if
they receive during the time of those slots. Therefore,
free_send_slots are the slots at which none of a node or its
neighbors receive or send.
For the exchange of slot scheduling information in QoS-
AODV, we use modified AODV HELLO messages. Those
messages are sent either in the predefined time periods if
none of the link bandwidths to neighbors are changed, or in
shorter time periods if there are any changes in link
bandwidth. When a node A receives time scheduling slots
from its neighbor X, it updates its own and its neighbor slot
scheduling information as shown on Figure 2.
send_slots(node X) = HELLO(send_slots(node X))
recv_slots(node X) = HELLO(recv_slots(node X))
free_slots(node X) = HELLO(free_slots(node X))
recv_slots(node A) = 0
recv_slots(node A neighbors) = 0
for (each neighbor N of node A) {
recv_slots(node A) =
recv_slots(node A) | send_slots(node N)
recv_slots(node A neighbors) =
recv_slots(node A neighbors) | recv_slots(node N)
}
Figure 2. Update of node slot scheduling
information at node A when node A receives
HELLO message from neighbor node X.
The link bandwidth between two nodes is calculated as
the intersection of their free slot schedules (Figure 3). The
send link bandwidth is defined as intersect of
 free_send_slots of a sender node and free_recv_slots of a
receiver node. The receive link bandwidth is defined as
intersect of free_recv_slots of a receiver node and
free_send_slots of a sender node.
send_link_bandwidth (A sends to X) =
free_send_slots(node A) & free_recv_slots(node X)
recv_link_bandwidth (A receives from X) =
free_recv_slots(node A) & free_send_slots(node X)
Figure 3. Calculation at node A link bandwidth
scheduling from A to its neighbor X.
The link bandwidth information is used for calculation of
path bandwidth schedules to source and destination nodes.
3b) QoS path discovery and maintenance
The QoS-AODV path discovery process is
complimentary to AODV path discovery algorithm. In
“pure” AODV the path from the source to the destination is
chosen regardless of bandwidth availability for that path.
However, the simple addition of calculation of slot
scheduling along that path cannot provide the quantity of
available bandwidth and slot scheduling. If the system
supports a set of calls with different bandwidth
requirements, then for each call the slot scheduling and path
bandwidth availability calculation must be done
individually. This makes it necessary to set specific Ids in
each routing table entries and routing packets used for the
path discovery.
The scenario of path discovery in QoS-AODV is as
follows: Once the source node receives the QoS call request
from its application layer, it needs to establish the virtual
connection from the source to the destination node. To do
so, the source node checks if it has enough link bandwidth
available to any of its neighbors. If it does not it denies the
request for connection. However, if it does, then the source
node creates a routing table entry for the requested
application call ID and the destination address. Finally, the
source node broadcasts RREQ, the AODV request message
that in addition to standard AODV information contains the
call ID and the number of slots required for reservation.
When an intermediate node receives a RREQ message it
checks whether it already has an entry in its routing table
corresponding to the received Application call ID. If it does
not, it creates a new entry, otherwise it checks whether the
received route to the source is fresher then the one it already
has. In case it is, it sets information for the reverse path to
the source, which corresponds to the given call ID. The route
table entry information contains the addresses of three nodes
Proceedings of the 35th Annual Simulation Symposium (SS’02)
1080-241X/02 $17.00 © 2002 IEEE
along the path to the source and link and path bandwidth
schedules between those nodes, in addition to one that
corresponds to the original AODV protocol. Based on
received link and path bandwidth information of nodes along
the path, the intermediate node calculates the path bandwidth
schedules by the algorithms similar to ones presented in [Lin
1999]. If the calculated path bandwidth to the source is
insufficient, then the node does not forward RREQ message
further.
When the destination node receives a RREQ, it does the
path bandwidth calculation using the same algorithm as the
intermediate nodes. Afterwards, if there is path bandwidth
available it starts the reservation protocol.
When a RREQ message is received for a specific route in
“pure” AODV, the node checks whether the newer path is
fresher then the older one and if they are equal, it compares
the hops counts of both paths. In QoS-AODV, we add
another heuristic, available bandwidth, so the node can
choose a path with the sufficient bandwidth, in addition to
the one with fewer hops. If there is enough path bandwidth,
RREQ message is augmented with the path and link
bandwidth parameters and is broadcasted further.
Since the routing table entries are created on “per call
ID” basis, the number of entries can grow quite high. To
prevent growing of route tables, their entries are removed
either when the VC is released or during periodic clean ups.
Figure 4 shows an example of how the QoS-AODV
path’s search is performed, starting from the source node X
to the destination node D. When a source node X receives a
call from the Application layer to create a new VC with
specific bandwidth requirements, it broadcasts RREQ
message containing call ID and number of slots required for
the reservations (Figure 4a). When the RREQ message is
received by A, it knows that X is its neighbor, so the
available path bandwidth from X to A is equal to receive
link bandwidth from X to A. Path bandwidth XA is
calculated as the portion of the receive link bandwidth XA.
Then A augments the received RREQ message with link
bandwidth of XA and address of X and rebroadcast RREQ
(Figure 4b). When B gets a RREQ message from A it figures
out that X is A's neighbor, so the available path bandwidth
and slot scheduling are calculated using XA and AB receive
link bandwidth. Then B checks whether path bandwidths XA
and AB are sufficient, and if they are B adds address of X
and A together with receive link bandwidth AB and path
bandwidth XA to RREQ message and rebroadcast it (Figure
4c). When C receives RREQ from B, in order for C to
calculate path bandwidth schedules to X, it has to know all
tree link bandwidths, XA, AB and BC to avoid packet
collisions.
In order to cut down on the amount of calculations, C
gets only path bandwidth XA, which was calculated on B,
and link bandwidth AB. C uses receive link bandwidths BC
and AB in order to calculate path bandwidths AB and BC. In
 order to prevent the hidden terminal problem, before the
calculation of path bandwidths AB and BC is done, the path
bandwidth schedule XA has to be subtracted from AB and
BC receive link bandwidths, since if B would transmit in the
same time slots as X then packet collisions will happen. At
last, C checks whether the bandwidth is sufficient, as it was
done on B, and if it is it sets addresses of B and A as well as
receive link bandwidth BC and path bandwidth AB in RREQ
message and broadcast that (Figure 4d). After D gets RREQ
from C, it performs calculations similar to the ones done on
C in order to get path bandwidth scheduling CD and BC
(Figure 4e).
Figure 4a. X broadcasts RREQ message with
number n slots required for VC.
Figure 4b. A got RREQ from X and calculates
pw(XA). Then A rebroadcasts RREQ with the
address of X and lw(XA).
Figure 4c. B got RREQ from A and calculates
pw(AB) and pw(XA). Then B broadcasts RREQ with
the addresses of X and A, pw(XA) and lw(AB).
Proceedings of the 35th Annual Simulation Symposium (SS’02)
1080-241X/02 $17.00 © 2002 IEEE
Figure 4d. C got RREQ from B and calculates
pw(AB) and pw(BC). Then B rebroadcasts RREQ
with the addresses of A and B, pw(AB) and lw(BC).
Figure 4e. D got RREQ from C and calculates
pw(BC) and pw(CD).
Figure 4. Example of QoS-AODV path search
initiated at source node X for the destination node
D. A solid line between two nodes indicates that
node can hear each other. The arrow out coming
from the node means that a node broadcast
messages to its neighbors.
The parameters needed to calculate path bandwidth from
a node to the destination are summarized in Figure 5. Those
parameters are kept in routing table entries corresponding to
the specific Application ID.
receive link bandwidth NA (A receives from N)
index of N’s neighbor M, where M is next hop in
routing table entry for the destination X, at node N
receive link bandwidth MN (N receives from M)
index of M’s neighbor P, where P is next hop in
routing table entry for the destination X, at node M
path bandwidths NA, MN and PM
Figure 5. Path bandwidth calculation
parameters set at node A for the routing table entry
for the destination node X, whose next hop is a
node N.
3c) Virtual Connection (VC) establishment,
maintenance and release
Once the destination node receives RREQ message and
figures out that there is bandwidth available to the source
node, it starts the reservation protocol. First, it creates the
reservation instance with parameters, shown in Table 1.
 source node ID
destination node ID
application call ID
previous hop
next hop
previous hop bandwidth scheduling
next hop bandwidth scheduling
reservation status
Table 1. Resource reservation parameters,
stored at each node along VC for that VC ID.
The parameters for a reservation instance are taken from
the routing table entry that corresponds to the VC ID. Then
the destination node reserves MAC receive slots
corresponding to previous hop bandwidth scheduling and
composes a reservation message, RSV, which is a new
message added to AODV protocol. The RSV message has
the address of the next hop, the path bandwidth to that hop,
and the addresses and path bandwidth of two more hops
along the path. RSV is sent to the next hop contained in the
routing table entry.
When an intermediate node receives the RSV message, it
creates a reservation instance and sets its resource
reservation parameters, corresponding to ones contained in
RSV messages. It reserves MAC receive and send slots and
it reserves send path bandwidth to the neighbor it got the
RSV message from. If the slot reservation was made
successfully, intermediate nodes get the address of the next
neighbor along the path and the path bandwidth to it,
composes RSV message and sends it along the path to the
source. If the slot reservation has failed, which can happen
because other neighboring nodes may reserve the same slots
simultaneously, then resource release is made, and an
unreserved message, URSV, is sent along the path back to
the destination. When source node receives the RSV
message, it does reservations and notifies the application
layer that the VC is set as well. The application layer in turn
starts sending data packets.
After the application terminates the connection, the VC
is released by generating a URSV message that is sent along
the path to the destination. When node receives the URSV
packet it release resources as described above.
Established VCs can be broken when nodes go beyond
each others transmission range or when new nodes enter
node transmission range with the slots already reserved for
the transmission or receiving. After QoS-AODV discovers
that VC is broken, it releases resources and sends URSV
messages to the source and the destination nodes. When the
source node receives URSV, it checks whether it has more
messages to transfer. If it does, then it goes through the path
discovery session.
Proceedings of the 35th Annual Simulation Symposium (SS’02)
1080-241X/02 $17.00 © 2002 IEEE
4. Performance Evaluation of QoS-AODV.
In order to judge the effectiveness of QoS-AODV, we
performed an extensive series of simulation experiments that
compared QoS-AODV to two other protocols. We used the
CMU extension of ns-2 simulator that has already
implemented the AODV protocol. Since the existing
implementation of AODV relies on the underlying MAC
802.11 and there was no suitable implementation of TDMA
MAC in ns-2, we implemented a new MAC TDMA layer.
We developed an interface between MAC and the routing
layers that enables slot reservation for sending to and
receiving from the specified neighbors. In addition, we
added the capability to detect and report the collisions for
the MAC TDMA layer. Collisions occur when a node
receives or sends data packets from a neighbor in time slots
that have already been assigned to receive or send to another
neighbor.
For simplicity, we refer to QoS-AODV as QOSA-AODV.
The two protocols that we compared to QOSA-AODV are as
follows. The first protocol is called PURE-AODV. Its
functionality is close to one in the original AODV, with only
exception that a VC is created for sending packets from the
source to the destination. As the original AODV, PURE-
AODV does not maintain information about the link
bandwidth available to its neighbors. After the source node
gets a route to the destination it starts the reservation
protocol. From the routing table entry corresponding to that
route it gets the address of the immediate neighbor then
guesses the path bandwidth to it. If the bandwidth is
sufficient, it makes reservations, as described for QOSA-
AODV, and then sends the RSV message to the next hop
along the path. When an intermediate hop receives the RSV
message, it guesses the path bandwidth scheduling to the
next hop, from the full link bandwidth range with the
exclusion of the path bandwidth received from the source
and if that guess is right, it propagates the RSV message
further. In case the guess was wrong, the URSV message is
composed and sent back to the source node. When the RSV
message reaches the destination and all the reservations went
successfully, the rest proceeds as in QOSA-AODV. The
resource release and handling of broken routes happen the
same way as in QOSA-AODV as well.
The second protocol is called Simple QoS AODV, or
QOSS-AODV. The path discovery and maintenance in this
protocol, together with the VC creation and reservation
mechanisms, happen as in PURE-AODV. The difference is
that in QOSS-AODV, the nodes are aware of the available
link bandwidth to their neighbors, and exchange link
bandwidth information as in QOSA-AODV. While doing
reservations, QOSS-AODV composes a path bandwidth
scheduling out of known link bandwidth to the next hop. The
 above-described properties of the protocols are summarized 10 nodes/500x500sq.m
in the Table 2. 1
QOSS

call acceptance ratio

0.8
QOSA
AODV: PURE QOSS QOSA
0.6 PURE
Time slot
information No Yes 0.4
is available
RREQ contains 0.2
Path RREQ, RREP as in additional QOS 0
discovery original AODV information 0 6 12 18 24 30
node speed, m/s
Route table One route table entry per One route table
management destination as in original entry per call
AODV ID Plot 1. Call acceptance ratio for different node
RSV is sent from source RSV is sent speeds for 10 nodes placed on 500x500 meter area.
Reservation to destination, then ACK is from
protocol sent from destination to destination to
source source 20 nodes/700x700sq.m
1
QOSS

call aceptance ratio

Table 2. Properties of PURE, QOSS and QOSA 0.8 QOSA
AODV protocols.
0.6 PURE
The performance of three protocols was studied for
different system topologies and mobility models. The 0.4
mobility pattern was set as follows: in the beginning of the 0.2
simulation the nodes wee randomly distributed on the
specified area. Then for each node, the destination is 0
randomly picked, and the node starts moving towards that 0 6 12 18 24 30
node speed, m/s
destination with the speed not exceeding a predetermined
threshold. When node stops it picks up a new destination,
and this behavior is repeated. For call generation, the
Plot 2. Call acceptance ratio for different node
destination and the source nodes were randomly picked and
the time for ith call to be issued is calculated as stime(i) = speeds for 20 nodes placed on 700x700 meter area.
stime(i-1) + interval*0.75 + random_uniform(0,
interval*0.5). Here, stime(0) = 0, and interval = total
simulation time/total number of calls, and random_uniform() 30 nodes/900x900sq.m
returns a random number from the interval specified in its 1
QOSS
call acceptance ratio

parenthesis. 0.8 QOSA

The topology of the system was created by the random PURE
generation of sets of nodes, varying from 10 to 30, for 0.6
different square areas varying from 500x500m (10 nodes) to 0.4
700x700m (20 nodes) to 900x900m (30 nodes). The radius
of node transmission was set to be equal to 250m. The 0.2
simulation time was set to 40,000 seconds and the number of
0
calls was set to 10,000 per simulation. The holding time of
0 6 12 18 24 30
the connection requests followed the normal distribution. node speed, m/s
The number of TDMA time frames required per connection
was randomly set to 1, 2, or 3 slots. The node speed was
varied from 0 to 30m/s. The results are presented on Plots 1- Plot 3. Call acceptance ratio for different node
3. speeds for 30 nodes placed on 900x900 meter area.
Each point shown on presented plots is the average of
data taken from five simulation experiments; the error bars
are the standard deviation of those data. As it can be seen,
for the stable nodes, most of the calls are accepted for

Proceedings of the 35th Annual Simulation Symposium (SS’02)

1080-241X/02 $17.00 © 2002 IEEE
 QOSA-AODV, while QOSS-AODV and PURE-AODV
acceptance rates are 85% and 40%, correspondingly. As the
nodes move, the acceptance rate for all protocols decreases
because of increasing number of race conditions, which may
occur during the VC establishment process. The race
condition may happen during the reservation phase, and is
due to outdated bandwidth scheduling. This situation arises
because other nodes have reserved the same slots, or the
neighborhood of nodes along path has changed due to node
movements that as the result change node link bandwidth.
The results show that the call acceptance ratio for PURE-
AODV is the lowest and is around 20% for all three topology
setups. It also can be seen that QOSA-AODV outperforms
QOSS-AODV for at least 10% for all topologies presented.
One advantage of PURE-AODV is that it has the least
control message overhead during its local connectivity
management and path discovery sessions. PURE-AODV
starts reservations for every call it receives from the
Application layer. However, unawareness of PURE-AODV
about link bandwidths to the node neighbors may quickly
lead to race conditions.
The QOSS-AODV connectivity management makes
nodes aware of link bandwidth to their neighbors. However,
nodes do not know whether there is a path bandwidth
available to the required destinations. As in PURE-AODV
the reservation process starts for most of the call as soon as
there is enough link bandwidth available between node and
the next hop of corresponding route table entry. During the
reservation process, node may soon discover that while there
is a path to the destination there is no path bandwidth
available, so the reservation backs up to the source and the
call fails.
In QOSA-AODV once the path is discovered it is
guaranteed that the reservation done along that path would
not be refused because of insufficient bandwidth. So, all the
reservations started are completed except ones that
encounter racing conditions. Despite the message overhead
of QOSA, the significant increase in call acceptance makes
it clearly superior to the other protocols we studied.
information. The second used slot scheduling information,
but did not make use of the protocol message features of
QoS-AODV. Our experiments showed the QoS-AODV
significantly improved the probability of being able to find
an end-to-end QoS path, as compared to these two other,
“lighter” approaches.
References
[Chen 1999], Chen, S.; Nahrstedt, K., "Distributed
quality-of-service routing in ad hoc networks", IEEE Journal
on Selected Areas in Communications, page(s): 1488 - 1505
Aug. 1999.
[Chen 1997] Chen, T.-W.; Tsai, J.T.; Gerla, M., "QoS
routing performance in multihop, multimedia, wireless
networks", 1997 IEEE 6th International Conference on
Universal Personal Communications Record, 1997.
Conference Record, pages: 557 - 561 vol.2, 12-16 Oct. 1997.
[Ho 2000] Ho, Y.-K.; Liu, R.-S. "On-demand QoS-based
routing protocol for ad hoc mobile wireless networks", Fifth
IEEE Symposium on Computers and Communications,
2000. Proceedings. ISCC 2000, pages: 560 - 565 3-6 July
2000.
[Lin 1999] Lin C. R.; Liu, J.-S., "QoS routing in ad hoc
wireless networks", IEEE Journal on Selected Areas in
Communications, page(s): 1426 - 1438, Aug. 1999, Volume:
17 Issue: 8.
[Lin 2000] Lin, C. R.; Liu, C.-C., "An on-demand QoS
routing protocol for mobile ad hoc networks", Conference
on IEEE International Networks, 2000. (ICON 2000).
Proceedings, pages: 160 - 164, 5-8 Sept. 2000.
[Ns2] See http://www.idi.edu/nsam/ns/.

5. Summary
[Perkins1999] Perkins C.E.; Royer, E.M.; "Ad hoc on-
This paper described an integrated route discovery and demand distance vector routing", Second IEEE Workshop
bandwidth reservation protocol called QoS-AODV. The key on Mobile Computing and Applications, 1999, Proceedings.
advantage of QoS-AODV is that it incorporates TDMA WMCSA '99., pages 90-100.
scheduling during the route discovery phase. The protocol
is based upon the original AODV technique for route
discovery and repair. We have added several messages and
procedures to support QoS path reservation and release.
We also developed a simulation program within the ns-2
framework. We compared our protocol with two other QoS
enhanced versions of AODV. The first used the path found
by AODV without making use of any type of slot scheduling

Proceedings of the 35th Annual Simulation Symposium (SS’02)

1080-241X/02 $17.00 © 2002 IEEE