OPNET-based Ad-hoc On Demand Distance Vector

Routing Protocol Research and Simulation

Meigen Huang

Xinfeng Chang

Department of Computer
Chongqing University of Posts and Telecommunications
Chongqing, China
huangmg@cqupt.edu.cn

Department of Network center

Pingdingshan University
Henan, China
xin83@126.com

AbstractThe report has presented an OPNET simulation model

for the Ad-hoc on demand Distance Vector routing protocol.
During the process of validation, this implementation of the
AODV protocol is supplied with a hierarchical structure of
models consisting of a simulation model, a network model, a node
model, and finally a set of process models. All the conclusions are
helpful to further development and optimize routing protocol for
Ad-hoc network.

locate its interlocutor node. On the other hand, when a route is

no longer used, it is simply expunged from the routing table.
This approach is known as source-initiated on-demand routing
as opposed to table-driven routing. It is also known as reactive
as opposed to proactive. For reasons of scalability, proactive
protocols may not find the same response within the MANET
community as reactive protocols, such as AODV, DSR, or
OLSR would probably have [6].

Keywords-Ad-hoc Networking, network simulation, OPNET,

AODV

Another adjustment was added as far as route maintenance

is concerned. In fact, in case of link failure, the node upstream
immediately broadcast an update message to the set of nodes
that are truly affected. Periodic updates such as full dump
packets in DSDV were completely eradicated. Of course,
AODV uses the same set of sequence numbers as in DSDV,
which guaranties loop-freedom in its routes.

I. INTRODUCTION
A mobile ad-hoc network (MANET) [1] is a collection of
wireless mobile hosts forming a temporary network without the
use of any pre-existing structure. Because of the improvised
nature of such networks, a routing protocol is used to discover
routes between nodes.
The Internet Engineering Task Force (IETF) has formed a
new working group for Mobile Ad-hoc networking in order to
provide a framework for developing IP-based routing protocols
in ad-hoc networks. At this time, no standard protocol has been
adopted yet but many of them are currently under study. The
Ad-hoc On-demand Distance Vector algorithm [2] is one of the
promising protocols under study.
As a contribution of the Wireless Communication
Technologies Group of the National Institute of standards and
Technology, a simulation model for AODV [3] was developed
and made available in order to provide a tool for researchers
who need to conduct studies in MANETs [4].
This paper presents a description and an evaluation of the
said model.
II. AODV SPECIFICATIONS
A. Ad-hoc On-demand Distance Vector Protocol
The Ad-hoc on demand Distance Vector protocol (AODV)
brings another brick to the edifice. As an improvement on
DSDV [5], AODV reduces the amount of control traffic by
simply minimizing the number of enquired routes. Instead of
building a route for all possible destinations in the network, a
node only creates and maintains routes that it really needs.
When a route is needed, a node initiates a request in order to

B. Addition to AODV
In this section, it is presented some useful additions to
AODV in order to cope with a major issue that can occur
during the discovery process. Assuming that the current node
does not have a fresh enough active route to be able to reply,
what will happen if a route to the Source IP Address already
exists but is invalid (waiting for deletion) with a destination
sequence number greater than the Source Sequence Number
that is included in the RREQ?
One thing is for sure: The node should definitely not update
its route table entry if the sequence number in the RREQ is less
than that in the route table entry. It is too risky and may lead to
the appearance of loops. The other hand, if the node does not
update its reverse route, the node should not forward the RREQ
either. Because if the node receives an eventual RREP back to
the node which originated the RREQ, it would not have a route
to forward it anyway.
One solution would be for each node to update its own
sequence number each time it broadcasts a RREQ packet.
Hence, a node should never re-broadcast a RREQ if the reverse
route has not been previously updated.
In this case, the following sentence If the node does not
have an active route, it rebroadcasts the RREQ from its
interface(s) from the draft should be extended to:
A node forwards a RREQ only if:
1) It has no route for the requested destination;

978-1-4244-7874-3/10/$26.00 2010 IEEE

2) It has previously updated or created a reverse route to

the source node of the RREQ (the node must have an active
route back to the source node of the request if it decides to
rebroadcast it).
III. SIMULATIONS AND RESULT
A. Simulation Environment
Along with the AODV routing implementation, the AODV
OPNET Model provides a general framework to simulate a
MANET environment. This platform includes a hierarchical
structure of models consisting of a network model, a node
model, and a set of process models. As the name states, AODV
OPNET Model is built using the commercially available
network simulation tool OPNET [7] by MIL3.

Second step: once in the init state, each node would check
its interlocutor attribute.
Final step: the current node is in the idle state and can
transit to either the rx (upon packet arrival from the lower
layer) or the tx (upon packet arrival from the lower layer) state.
3) AODV Routing (aodv_routing) Process Model
This section presents a general description of the
aodv_routing process model. The aodv_routing process (Figure
2) implements the AODV routing protocol as specified in the
IETF AODV draft version. In our effort to accomplish the
implementation of the present model, we have tried to make
the aodv_routing process model as independent as possible
from the rest of the platform (at the node model level).

1) AODV Node Model

As it is shown in Figure 1, AODV node model tries to
reproduce the so-called OSI stack. The primary idea behind the
development of the AODV node model is to provide a test bed
around the AODV routing implementation. Each node within
the network is uniquely identified with its IP address. In our
platform, the IP address is assimilated to the MAC address
which must be indicated before the simulation compilation.
The AODV node model include: src module, app_manager
module, aodv_routing module, wlan_mac_intf module
(provided by OPNET), wlan_mac module (provided by
OPNET), wlan_rx + wlan_tx modules, and mobility module.
Figure 2. AODV Routing Process Model

4) AODV Mobility Process Model

The mobility process model, shown in Figure 3,
implements a random waypoint mobility scheme which is
described bellow. The general motion of a particular node is
simulated through a set of discredited small step intervals. A
node in motion updates its position every time step period of
time. In our simulations, the duration of each step is set to a
value of 0.2 seconds.

Figure 1. AODV Node Model

2) AODV Application Manager (app_manger) Process

Model
The primary function of the application manager process is
to attribute a destination IP address for each incoming packet.
The other function of the app_manger is to reply to each
received packet by emitting a data packet to the attention of the
source node of the received packet. This mechanism is
introduced in order to fake a two-way conversation between
the members of each pair source/destination.
The principle is very basic and can be divided into 3 steps:
First step: on one hand, the attribution of the flows obeys to
a FIFO (first in-first served) policy. On the other hand, each
node, at the pre-init state, randomly picks a waiting period
before transiting to the init state.

Figure 3. Mobility Process Model

5) The simulation model

In all our runs, it is used that the same network model
which is shown in Figure 4. This network contains 40 mobile
nodes which can move around a 1200x800 meters square wide
area. Nodes communicate over wireless links with a
transmission range of 250 meters. The AODV layer maintains
a send buffer of 64 packets, and the node traversal time is set to
30 seconds (a packet may remain within a send buffer for a
period of 30 seconds at most).
As far as the traffic model is concerned, we used
Continuous Bit Rate (CBR) sources with a rate of 4 packets per

second. Packet size is constant and equals to 512 bytes. Each

run needs a simulation of 900 seconds.

restored and packets are delivered to their destinations.

Therefore, the version with Repair provides better efficiency.

Figure 4. AODV 40-node Network Model

In our simulations, we have studied the effect of four

different parameters: The Mobility Parameter, The Offered
Load Parameter, The Repair Parameter and The Connectivity
Parameter.
B. Results and Discussion
1) Varying Mobility and Repair
It varies the Speed Limit parameter between 0 and 20 m/s
and measures the corresponding mobility factor (average
relative speed). All other parameters are set to their default
value (16 flows and no connectivity support). The results are
shown in Figures 5 and 6.

Figure 6. Average end-to-end delay vs. Mobility

Figure 6, however, shows smaller delays for the other

version (the one without Repair). This observation is biased. In
case of no Repair, packets are immediately dropped upon link
failure. The average delay is then measured with much less
packets. On the other hand, packets waiting for repair are
queued in the send buffer. Therefore, delays increase in case of
repair because of extra queuing times.
Finally, both graphs show that the Repair feature is
definitely not suitable for networks with frequently changing
possibility. Repair attempts usually end-up with a failure and
cumulated packets (during repair period) are yet dropped at the
end.
2) Varying Offered Load
In this study, we vary the number of flows in the network.
The maximum speed is set to 0.5 m/s in all runs which
corresponds to a mobility factor around 0.24 with an interval of
0.01. All connectivity supports are disabled and local repair is
not allowed.

Figure 5. Efficiency vs. Mobility

Two major observations can be made. First of all, a quick

look to the graphs in Figure 5 shows that the efficiency is
relatively mediocre (0.65% at most). Also, the affect of
mobility is different in each case. In case of low mobility
(mobility factor < 1), the AODV version with Repair gives
better result than the one with no Repair.
The Repair version reacts differently to link breakages. As
a matter of fact, upon link failure, each node queues a copy of
the lost packet and immediately attempts to repair the broken
path by initiating a route discovery for the lost destination. As
there was no breakage at the first place, the route is quickly

Figure 7. Efficiency vs. Offered Load

There is practically nothing to say about Figures 7, 8 and 9

except that AODV seems to react quiet well along the increase
of the traffic load. The current scenario does certainly not

provide a rough situation for the routing protocol, but we can

note that the network start to collapse upon 35 flows. The
overhead is multiplied by a factor of 4.5 and delays are very
high. The stability of the efficiency between 15 and 30 flows is
probably due to a lucky balancing of the traffic within the
network (position of source nodes).

From Figure 10, it can be seen that the use of connectivity

management provides better results as far as efficiency and
delays are concerned (up to 33% more efficiency in case of
Hello RREQs). However, the generated overhead is multiplied
by a factor between 2 and 3.

Figure 10. Performances vs. Connectivity Support

Figure 8. Average Delay vs. Offered Load

IV. CONCLUSION
In this report, it has presented an OPNET simulation model
for the Ad-hoc On demand Distance Vector routing protocol
that was developed at the National Institute of Standards and
Technology. In order to provide a reference simulation
platform, this implementation of the AODV protocol is
supplied with a hierarchical structure of models consisting of a
simulation model, a network model, a node model, and finally
a set of process models. Hope the model provides a reference
basis for researchers and designers who need to conduct
OPNET simulations of Mobile Ad hoc Networks (MANETs).
REFERENCES
[1]

[2]
[3]

Figure 9. Normalized Overhead vs. Offered Load

[4]

Again, the decrease in delays for 40 flows is not due to a

better performance of the routing protocols. It is only caused
by the fewer number of delivered packets compared to the
results obtained for other number of flows.
3) Varying Connectivity Support
In this set of simulations, we study the affect of the
connectivity support in case of average mobility. The Speed
limit is set to 5m/s which correspond to a mobility factor of
0.95 with an interval of 0.05. The number of flows is set to 16.
The HELLO_INTERVAL is set to 1 second, and the
ALLOWED_HELLO_LOSS is set to 2 (two Hello messages
can be lost before assuming a link breakage).

[5]

[6]

[7]

Perkins C, Royer E. "Ad hoc on demand distance vector routing. The

2nd IEEE Workshop On Mobile Computing Systems and Application.
New Orleans, LA, Feb.2003:90-100.
Magnus Frodigh, Per Johansson. "The art of networking without a
network. Ericsson Review, 2001(4):248-262.
Tan D. Chakeres and Elizabeth M. Belding-Royer. "AODV Routing
Prottocol Implementation Design." Priceedings of the International
Workshop on Wireless Ad Hoc Networking (WWAN), Tokyoo, apan,
March 2004.
Tseng, Yu-Chee; Hsieh, Ten-Yueng, "Fully power-aware and locationaware protocols for wireless multi-hop ad hoc networks," Computer
Communi-cations and Networks, 2002. Proceedings. Eleventh
International.
C. Perkins and P. Bhagwat, "Highly dynamic Destin-ation-Sequenced
Distance Vector routing (DSDV) for mobile computers," in ACM
SIGCOMM, Oct. 1994.
Jin-Man Kim, Jong-Wook Jang. "AODV based Energy Efficient
Routing Protocol for Maximum Lifetime in MANET," Proceedings of
the Advanced International Conference on Telecommunications and
International Conference on Internet and Web Applications and Services
(AICT/ICIW), 2006.
Chenmin.OPNET network simulation [M]. Beijing: Tsinghua university
press, 2004.