eaodv

1. Introduction
The use of electronic services, such as electronic-mail (e-mail), video teleconferencing
(VTC) etc, over a wired network has grown significantly. These services were traditionally
implemented on wired or static networks to provide an effective transfer of data. The
reliability of services provided to the user has increased over time to meet current demand.
However, the user today requires more flexibility and requires these services in a mobile,
wireless environment so as not to be limited to a fixed location. Technological advances have
made mobile wireless communications possible, but with many limitations. Improvements in
routing protocols are necessary for future mobile wireless communications.
The mobile ad-hoc network (MANET) used in this work is a network formed without any
central administration, consisting of mobile nodes that use wireless interfaces to send packet
data. The nodes in an ad-hoc network can act as both routers and hosts, thus a node may
forward packets between other nodes as well as run user applications. Networks using ad-hoc
configuration concepts can be used in many military applications e.g., digital maps, voice
communication, etc. Combinations of wide range and short range ad-hoc networks seek to
provide global coverage, even during adverse operating conditions, especially during the
emergency situations and disaster managements. Typical ad-hoc is established for a limited
period of time.
With the help of MANET, computing is not restricted to locality, time or mobility.
Computing therefore can be done anywhere and anytime. Existing routing protocols for the
wired environment cannot overcome the randomness of the MANET environment and are
extremely inefficient. Thus, the wide range of operating configurations of MANET is
considered to be complex. In this project, numerous simulations have been made using a
simulator named Network Simulator 2 (NS2). Efficient routing protocols can provide
significant benefits to mobile ad-hoc networks in terms of both performance and reliability.
Simulators though cannot take into account all the factors, the performance and connectivity
of mobile ad-hoc network depend on some factors. Our motivation is to overcome the
problems occurring in routing protocols by designing an enhanced routing protocol and then
evaluate the behaviour of routing protocols.

1.1 AIMS AND OBJECTIVES
There are two basic groups of routing protocols, Proactive MANET protocol (PMP), Reactive
MANET Protocol (RMP), and whereas the third one is derived from both of these and called
as Hybrid MANET Protocol.
The Proactive MANET protocol is generally called table driven protocol and it detects the
network layout periodically. It tries to maintain the routing table at every node which is used
to detect a most feasible route to the destination from the source with less delay. Proactive
MANET protocols provide good reliability and low latency for deciding a route but these
protocols are not suitable for the nodes moving with high speed as the routing information
cannot be updated in the routing table. If a node is not moving, then its routing table
information is updated continuously. It causes more traffic overhead wastage of network
resources such as bandwidth. Another drawback is the unsuitability for large scale MANETs.
Reactive MANET Protocol is called on-demand routing protocol and finds the route when a
source node requests to communicate with the other. On-demand approach is suitable for the
nodes with high mobility and nodes that transmit data rarely. The main drawback of reactive
routing protocols is that the source node broadcasts the routing requests in the whole network
and it waits for the responses. This route discovery procedure causes significant delay and
makes them less suitable for real time traffic.
Hybrid MANET Protocol integrates the merits of Proactive and Reactive Protocols. Zone
routing protocol (ZRP) and two zone routing protocols (TZRP) are the examples of hybrid of
MANET protocol.
1.2 RESEARCH QUESTION
Our goal in this project is to overcome the disadvantages of Reactive MANET protocol
(AODV). It can be achieved by enhancing AODV protocol, naming it enhanced AODV
(EAODV) and evaluate the performance of these two protocols. These protocols have
different behaviors with respect to wireless routing perspective. The critical issue for routing
in mobile ad-hoc networks is to select a stable path with longer lifetime, higher throughput
and less delay.
First question is what are the demerits of AODV protocol? Second question is how to
improve the performance of the AODV protocol? These questions give rise to improvement
of an existing AODV protocol, resulting in formation of an enhanced protocol, EAODV. The
performance evaluation of these protocols, AODV and EAODV will be carried out with
respect to parameters such as delay, packet delivery ratio, throughput and routing overhead.
We will simulate these scenarios based on the above mentioned parameters and evaluate
them using open source software, Network Simulator 2 (NS2).

1.3 SCOPE OF THE PROJECT
AODV is an on-demand routing protocol specially designed for ad-hoc networks. AODV
suffers from low bandwidth, route interferences, link breakages and higher transmission
delay due to its dynamic nature. In this project, we propose an enhanced AODV (EAODV)
routing protocol by including route repair scheme to overcome the problems of its
predecessor. We evaluate the behavior of above mentioned AODV and EAODV routing
protocols when implemented in the network. We look at how these protocols affect the
network performance and how they behave in these networks. The algorithm design and
analysis of these routing protocols will be the focused; a detailed explanation of these routing
protocols and their effects on the network will be discussed.
1.4 PROJECT STRUCTURE
This project is divided mainly into nine chapters. The first chapter deals with introduction
and scope of the project. In chapter two, a brief explanation about MANETs, it characteristics
and applications are given. A detailed annotation about routing in Adhoc Networks is given
in chapter three. A concise description about different kinds of protocols is mentioned. Fourth
chapter demonstrates the Simulation software (Network Simulator 2) which we used to
simulate networks in this project. The fifth chapter elucidates the detailed explanation of
Adhoc On-Demand Distance Vector (AODV) routing protocol. The route discovery, working
mechanisms, merits and demerits are discussed. Chapter six construes the need for
enhancement of AODV protocol. The enhancement algorithms and practical approach for
enhancement are expounded. Seventh chapter demonstrates various performance metrics that
are to be used in analysis. Eighth chapter illustrates different scenarios that are simulated.
Their corresponding results and evaluations are justified. The final chapter concludes the
project.

2. MOBILE ADHOC NETWORKS (MANETS)
2.1 OVERVIEW
The field of wireless and mobile communications has experienced an unprecedented growth
during the past few decades. Current generation cellular systems enabled worldwide mobile
connectivity. Mobile users can use their cellular phone to check their email and browse the
Internet. All these networks are conventional wireless networks, conventional in the sense
that as prerequisites, a fixed network infrastructure with centralized administration is required
for their operation, potentially consuming a lot of time and money for set-up and
maintenance. Furthermore, an increasing number of devices such as laptops, personal digital
assistants (PDAs), etc are provided with short-range wireless interfaces. In addition, these
devices are getting smaller, cheaper, more user friendly and more powerful. This evolution is
driving a new alternative way for mobile communication, in which mobile devices form a
self- creating, self-organizing and self-administering wireless network, called a mobile ad hoc
network.
Figure 1. Depiction of a MANET
2.2 DESIGN AND STRUCTURE
Opposed to infrastructure wireless networks, where each user directly communicates with an
access point or base station, a mobile ad hoc network, or MANET, does not rely on a fixed
infrastructure for its operation (Figure 1). The network is an autonomous transitory
association of mobile nodes that communicate with each other over wireless links. Nodes that
lie within each other’s range can communicate directly and are responsible for dynamically
discovering each other. In order to enable communication between nodes that are not directly
within each other’s send range, intermediate nodes act as routers that relay packets generated
by other nodes to their destination. These nodes are often energy-constrained, that is, battery-
powered devices. Furthermore, devices are free to join or leave the network and they may
move randomly, possibly resulting in rapid and unpredictable topology changes. In this
energy-constrained, dynamic, distributed multi-hop environment, nodes need to organize
themselves dynamically in order to provide the necessary network functionality in the
absence of fixed infrastructure or central administration.

2.3 CHARACTERISTICS OF MANET
Mobile ad hoc network nodes are furnished with wireless transmitters and receivers using
antennas, which may be highly directional (point-to-point), omnidirectional (broadcast),
probably steerable, or some combination thereof. At a given point in time, depending on
positions of nodes, their transmitter and receiver coverage patterns, communication power
levels and co-channel interference levels, a wireless connectivity in the form of a random,
multi-hop figure or "ad hoc" network exists among the nodes. This ad hoc topology may
modify with time as the nodes move or adjust their transmission and reception parameters.
The characteristics of these networks are summarized as follows:
a) Communication via wireless means.
b) Nodes can perform the roles of both hosts and routers.
c) Bandwidth-constrained, variable capacity links.
d) Energy-constrained Operation.
e) Limited Physical Security.
f) Dynamic network topology.
g) Frequent routing updates.
2.4 ADVANTAGES AND APPLICATIONS
These networks are faced with the traditional problems inherent to wireless communications
such as lower reliability than wired media, limited physical security, time- varying channels,
interference, etc. Despite the many design constraints, mobile ad hoc networks offer
numerous advantages. First of all, this type of network is highly suited for use in situations
where a fixed infrastructure is not available, can be used when the other parties are not
trusted, alternative choice when the infrastructure is too expensive or unreliable. Because of
their self-creating, self-organizing and self-administering capabilities, ad hoc networks can be
rapidly deployed with minimum user intervention. There is no need for detailed planning of
base station installation or wiring. Also, ad hoc networks do not need to operate in a stand-
alone fashion, but can be attached to the Internet, thereby integrating many different devices
and making their services available to other users. As a consequence, mobile ad hoc networks
are expected to become an important part of the future 4G architecture, which aims to provide
pervasive computer environments that support users in accomplishing their tasks, accessing
information and communicating anytime, anywhere and from any device. Figure 2 provides
an overview of present and future MANET applications. The advantages of ad-hoc networks
can be summarized as:
i) Ease of deployment.
ii) Decreased dependence on the infrastructure.
iii) Fault tolerance.
iv) Direct connectivity.
v) Fast installation in places even without previous infrastructure.

Applications of mobile ad-hoc networks are:
Application Possible scenarios/services
Tactical networks
 Military communication and operations
 Automated battlefields
Emergency services
 Search and rescue operations
 Disaster recovery
 Replacement of fixed infrastructure in case of environmental disaster
 Policing and firefighting
 Supporting doctors and nurses in hospitals
Commercial and civilian
environments
 E-commerce electronic payments anywhere and anytime
 Business: dynamic database access, mobile offices
 Vehicular services: road or accident guidance transmission of road or
weather conditions, taxi cab network, inter-vehicle networks
 Sport stadiums, trade fair, shopping malls
 Network of visitors at airport
Home and enterprise
networking
 Home/office wireless networking
 Conferences, meeting rooms
 Personal area networks(PAN)
 Networks at construction site
Education  Universities and campus settings
 Virtual classrooms
 Ad hoc communication during lectures or meetings
Entertainment  Multi user games
 Wireless P2P networking
 Outdoor internet access
 Robotic pets
 Theme park
Sensor networks  Smart sensors embedded in consumer electronics
 Body area networks(BAN)
 Data tracking of environmental conditions, animal movements,
chemical/biological detection
Context aware services  Follow on services-call forwarding, mobile workspace
 Information services: location specific and time dependent services
 Infotainment: touristic information
Coverage extension  Extending cellular network access
 Linking up with internet, intranet ect.
Figure 2. Applications of MANETS

3. ROUTING
As mobile ad hoc networks are characterized by a multi-hop network topology that can
change frequently due to mobility, efficient routing protocols are needed to establish
communication paths between nodes, without causing excessive control traffic overhead or
computational burden on nodes. An ad hoc routing protocol is a standard for controlling node
decisions when routing packets traverse a MANET between devices. A node in the network,
or one trying to join, does not know about the topology of the network. It discovers the
topology by announcing its presence and listening to broadcasts from other nodes (neighbors)
in the network. The process of route discovery is performed differently depending on the
routing protocol implemented in a network.
There are several routing protocols designed for wireless ad hoc networks. Routing protocols
are classified either as reactive or proactive. There are some ad hoc routing protocols with a
combination of both reactive and proactive characteristics. These are referred to as hybrid.
3.1 ROUTING PROTOCOLS IN AD-HOC NETWORK
Designing an efficient and reliable routing protocol is a very challenging task to do with the
changing network conditions such as network size, traffic, topology and other network
conditions. Routing protocols implement many metrics for calculating the best path to route
the packets to the destination. These metrics are considered to be a standard measurement
that could be number of hops, which are used by the routing algorithm to determine the
optimal path for the packet to its destination. Routing algorithms initialize and maintain
routing tables, which contain the route information for the packet which is helpful in the
process of determining the path. This generated route information varies from one algorithm
to another. The routing tables are filled with a variety of information which is generated by
the routing algorithms. Developing efficient routing protocols for MANETs has been an
extensive research area and various routing protocols have been proposed. All routing
protocols function at the network layer and the specific region is depicted in Figure 3.
Figure 3. Protocol Stack for a MANET Node

There are many ways to classify the MANET routing protocols. Depending on how the
protocols handle the packet delivery from source to the destination, most of the protocol
classifications are made as follows:
Flat Routing Protocols:
Flat routing protocols are divided into two types of classes:
a) Proactive routing (table driven) protocols.
b) Reactive (on-demand) routing protocols.
All nodes participating in routing play an equal role in both types of protocols. They have
been further classified based on their design principles; proactive routing is mostly based on
LS (link-state) while on-demand routing is based on DV (distance-vector).
3.1.1 DISTANCE-VECTOR & LINK-STATE ROUTING
Distance vector routing is based on the classical Bellman-Ford routing mechanism. Each
router contains routing information in its internal routing table. The routing table contains the
distance to all available routers, where the distance is measured in hops. The table is formed
by computing the shortest path to each host from the information received as well as
obtaining other routers' broadcasting messages. The messages are sent by request,
periodically, and with each there is a change of metric in the routing table.
Link state routing is based on Dijkstra's algorithm. Network topology information is used to
make routing decisions. Each router actively tests the status of its link to each of its neighbors
and sends this information to its other neighbors, which then propagate it throughout the
autonomous system. Each router takes this information and builds a complete routing table.
3.1.2 PRO-ACTIVE / TABLE DRIVEN ROUTING PRPTOCOLS
Proactive MANET protocols are table-driven and will actively determine the layout of the
network. Proactive routing protocols build and maintain routing information to all the nodes.
This is independent of whether or not the route is needed. In order to achieve this, control
messages are periodically transmitted. Proactive routing protocols are not bandwidth
efficient. This is due to the control messages that are broadcasted even when there is no data
flow. This type of routing protocols has its advantages and disadvantages.
One of its main advantages is the fact that nodes can easily get routing information and it is
easy to establish a session. The disadvantages include: there is too much data kept by the
nodes for route maintenance and it is slow to restructure when there is a failure in a particular
link[4], the life span of the link is significantly short. This phenomenon is due to the
increased mobility of the nodes. Proactive MANET protocols work best in networks that have
low node mobility or where the nodes transmit data frequently. Example of Proactive routing
protocol is DSDV (Destination Sequenced Distance Vector).

3.1.3 REACTIVE / ON-DEMAND ROUTING PROTOCOLS
Reactive routing is a popular routing category for wireless ad-hoc routing. The design follows
the idea that each node tries to reduce routing overhead by only sending routing packets when
communication is requested. The route discovery phase is common for most on-demand
routing protocols, where packets are flooded into the network in search of an optimal path to
the destination node in the network.
Reactive routing protocols are bandwidth efficient. Routes are built as and when they are
needed. This is achieved by sending route requests across the network. There are
disadvantages with this algorithm. One of them is that it offers high latency when finding
routes. The other disadvantage is the possibility of network clog when flooding is excessive.
An example of Reactive protocol is AODV (Ad-hoc On-Demand Distance Vector).
The following table presents the classification of ad-hoc routing protocols with some examples:
OLSR DSDV STAR AODV DSR DYMO TORA ZRP
Figure 4. Classification of Ad hoc routing protocols
4. SIMULATION SOFTWARE
The Simulation software used in this project was NS2, Version 2.35 on a Linux platform
(Ubuntu operating system). The NS2 package was chosen due to its availability as freeware
on the Internet and its simplicity.
4.1 NETWORK SIMULATOR 2 (NS2)
NS2 is simply an event-driven simulation tool that has proved useful in studying the dynamic
nature of communication networks. Simulation of wired as well as wireless network
functions and protocols (e.g., routing algorithms, TCP, UDP) can be done using NS2. In
general, NS2 provides users with a way of specifying such network protocols and simulating
their corresponding behaviours. The simulator is written in the C++ programming language
and the Tool Command Language (TCL).
Ad- hoc routing protocol
Table Driven On-Demand Hybrid

Tcl is a radically simple open-source interpreted programming language that provides
common facilities such as variables, procedures, and control structures as well as many useful
features that are not found in any other major language. Tcl runs on almost all modern
operating systems such as Unix, Macintosh, and Windows. While Tcl is flexible enough to be
used in almost any application imaginable, it does excel in a few key areas, including:
automated interaction with external programs, embedding as a library into application
programs, language design, and general scripting. It is commonly used for rapid prototyping,
scripted applications, GUIs and testing.
Figure5 shows the basic architecture of NS2. NS2 provides users with an executable
command “ns” which takes one input argument, the name of a Tcl simulation scripting file.
In most cases, a simulation trace file is created and is used to plot graph and/or to create
animation. NS2 consists of two key languages: C++ and Object-oriented Tool Command
Language (OTcl). While the C++ defines the internal mechanism (i.e., a backend) of the
simulation, the OTcl sets up simulation by assembling and configuring the objects as well as
scheduling discrete events (i.e., a frontend). The C++ and the OTcl are linked together using
TclCL. In the OTcl domain, a handle acts as a frontend which interacts with users and other
OTcl objects. It may define its own procedures and variables to facilitate the interaction.
Tcl simulation Simulation file
script
Figure 5. Architecture of NS2
Need of two languages for simulation
Simulator has two different kinds of things to do. Detailed simulation and analysis of
protocols require a system programming language which can efficiently manipulate bytes,
packet headers; and implement algorithms that can run over large data sets. For these tasks
“run time” speed is important and “turn round time” (run simulation, find bug, recompile,
return etc) is less important. For this purpose, system programming language C++ is used.
Major part of network research involves slightly varying the parameters or configurations and
quickly exploring a number of scenarios. In these cases, iteration time, changing the model
and running is more important. Since the network configuration runs only once, the run time
of this task is less important. For this task OTcl is used in NS. Most routing is done in OTcl.
r
Tclcl
Simulation
Objects
Simulation
objects
NAM XGRAPH
NS2 SHELL EXECUTABLE COMMAND(NS)

OTcl
C++
NS2 provides a large number of built-in C++ classes. It is advisable to use these C++ classes
to set up a simulation via a Tcl simulation script. In our project, we develop our own C++
classes and use OTcl configuration interface to put together objects instantiated from these
classes.
NS2 provides implementations for network nodes, links between nodes, routing algorithms,
some transport level protocols (especially UDP and many different variants of TCP) and
some traffic generators. The simulator can be extended by adding functionality to these
objects. The result of the simulations is an output trace file (.tr file) that is used for further
data processing and to visualize the simulation with a resident program tool in NS2 called the
Network Animator (NAM).
Figure 5 above depicts an overview of how a simulation is performed in NS2 from the user
input, in the TCL script, to data processing. The user creates node movement and traffic
generation files. The NS2 simulator performs the simulation and creates an output file
containing results of the simulation. The user can add the network animator (NAM) to the
TCL script to view the movement of MANET nodes in the simulation. Figure 6 represents a
screenshot of NAM window. Figure 7 presents a glimpse of simple topology in NAM.

Figure 6. NAM window screenshot
Figure 7. NAM with simple topology
Output files such as trace files have to be parsed to extract useful information. The parsing
can be done using the awk command (in UNIX and LINUX). A software program which can
shorten the process of parsing trace files (Xgraph) has also been used in this project.

A sample trace file (.tr) is represented as:
s 10.006348737 _1_ MAC --- 3 ack 118 [13a 0 1 800] ------- [1:0 0:0 32 0] [0 0] 0 0
r 10.007293041 _0_ MAC --- 3 ack 60 [13a 0 1 800] ------- [1:0 0:0 32 0] [0 0] 1 0
s 10.007303041 _0_ MAC --- 0 ack 38 [0 1 0 0]
r 10.007318041 _0_ AGT --- 3 ack 60 [13a 0 1 800] ------- [1:0 0:0 32 0] [0 0] 1 0
s 10.007318041 _0_ RTR --- 4 tcp 1560 [0 0 0 0] ------- [0:0 1:0 32 1] [1 0] 0 0
s 10.007318041 _0_ AGT --- 5 tcp 1540 [0 0 0 0] ------- [0:0 1:0 32 0] [2 0] 0 0
r 10.007318041 _0_ RTR --- 5 tcp 1540 [0 0 0 0] ------- [0:0 1:0 32 0] [2 0] 0 0
1. First field is event type; it may be r, s, f, d for received, sent, forwarded and dropped
packets respectively.
2. The second field is the time.
3. The third field is the node number.
4. The fourth field is MAC to indicate, if the packet concerns a MAC layer; it is AGT to
indicate the transport layer (e.g. tcp) packet, or RTR if it concerns the route packet. It can be
IFQ for drop packets.
5. After the dashes comes the global sequence number of the packet (not tcp sequence
number).
6. At the next field comes more information on the packet type (e.g. tcp, ack, or udp).
7. Next is the packet size in byte.
8. The 4 numbers in the first square brackets concern MAC layer information. The first
hexadecimal number specifies the expected time in seconds to send this data packets over the
wireless channel. The second number stand for the MAC-id of the sending node third is for
receiving node. And fourth number, 800, specifies that the MAC type is ETHERTYPE_IP.
9. The next number in the second square brackets concern the IP source and destination
addresses, then the ttl (time to live) of the packet (in our case 32).
10. The third brackets concern the tcp information: its sequence number and
acknowledgement number.
4.2 DIRECTORY STRUCTURE
NS2 is installed in Directory nsallinone-2.35. Figure 8 shows the directory structure under
directory nsallinone-2.35. Here, the directory nsallinone-2.35is on the Level 1. On the Level
2, the directory tclcl-1.20 contains classes in TclCL (e.g., Tcl, TclObject, TclClass). All NS2
simulation modules are in the directory ns-2.35 on the Level 2. We refer to directories ns-
2.35 and tclcl-1.20 as ˜ns/ and ˜tclcl/, respectively.
On Level 3, the modules in the interpreted hierarchy are under the directory tcl. Among these
modules, the frequently used ones (e.g., ns-lib.tcl, ns-node.tcl, ns-link.tcl) are stored under
the directory lib on Level 4. Simulation modules in the compiled hierarchy are classified in
directories on Level 3. For example, directory tools contain various helper classes such as
random variable generators. Directory common contains basic modules related to packet
forwarding such as the simulator, the scheduler, connector, packet. Directories queue, tcp,
and trace contain modules for queue, TCP (Transmission Control Protocol), and tracing,
respectively.

LEVEL 1:
….
LEVEL 2:
LEVEL 3:
LEVEL 4:
Figure 8. Directory structure of NS2
Simulation results are achieved with the help of generic trace and NAM trace. Generic trace
is useful to achieve results with the help of Xgraph; and NAM trace is useful for visualization
of the results. In NS2 a network topology is realized using three primitive building blocks:
nodes, links and agents.
The following steps are important in setting up a topology in NS2 and running a simulation:
 The Simulator class has methods to create/configure each of these building blocks.
Nodes are created with the node Simulator method that automatically assigns a unique
address to each node. For creating a node the following command is used
set n1 [$ns node]
 Links are created between nodes to form a network topology with the simplex-link
and duplex-link methods that set up unidirectional and bidirectional links
respectively.
 Agents are the objects that actively drive the simulation and can be thought of as the
processes and/or transport entities that run on nodes that may be end hosts or routers.
For creating agents the following command is used: set tcp [new Agent/TCP], Once
the agents are created, they are attached to nodes with the attach-agent Simulator
method. Each agent is automatically assigned a port number unique across all agents.
 Sources are attached to agents using the attach-source and attach-traffic agent
methods.
 Simulation is started via the run method and continues until there are no more events
to be processed.
 Every Tcl script must be written in small letters only, except protocol agents i.e. TCP,
FTP.
ns-2.35 Tcl 8.5.10 Tclcl-1.20
TCLCL
CLASSES
All NS2
SIMULATION
MODULES
common tools tcp queue trace tcl
lib rtglib
Commonly used modules
in interpreted hierarchy
Modules in
interpreted
hierarchy
NSallinone-2.35

5. AD HOC ON-DEMAND DISTANCE VECTOR
(AODV) ROUTING
Perkins and Royer developed the AODV routing protocol in 1999. AODV incorporates the
attributes of two other routing protocols, DSR and DSDV. DSR is a source oriented on-
demand protocol, and DSDV is a table-driven protocol. AODV is a combination of these two
protocols and is considered to be a hybrid protocol. Specifically, AODV uses the same
features as DSR for route discovery and maintenance and, from DSDV, uses the hop-by-hop
routing, sequence numbers, periodic update packets and ensures loop free routing. The
purpose of this hybrid protocol is to allow local regions to utilize local routing information
and to obtain a route outside the local region on-demand. Ad hoc On-demand Distance
Vector Routing (AODV) protocol is an on demand routing protocol as it determines a route
to the destination only when a node wants to send data to that destination. The following
discussion on AODV will focus on route discovery
5.1 ROUTE DISCOVERY
The route discovery process is initiated when a source node needs to send information to a
node either outside the local region or when no local routing information exists for the
destination node. The source node begins route discovery by broadcasting a route request
(RREQ) packet to all of its neighbors. Figure 9 illustrates a source node sending a broadcast
RREQ to destination node D.
Figure 9. Initial Route Request from Node S to Node D
The RREQ packet contains the following information fields: type, reserved, hop count,
broadcast ID, destination IP address, destination sequence number, source IP address and
source sequence number. Figure 10 depicts the format of the RREQ.

Figure 10. Route Request (RREQ) Format
The description of different field is as follows:
Type field: Indicates the traffic: constant bit rate (CBR) or transmission control protocol
(TCP).
Reserved field: Reserved for future use.
Hop count field: Indicates the number of hops from the source IP address to the node
handling the request.
Broadcast ID field: Indicates a unique sequence number identifying the particular request
when taken in conjunction with the source node's IP address.
Destination IP address field: Indicates the IP address of the destination for which a route is
required.
Destination sequence number field: Indicates last sequence number received by the source
for any route towards the destination.
Source IP address field: Indicates the IP address of the node that originated the request.
Source sequence number field: Indicates the current sequence number for route information
generated by the source of the route request.
An intermediate node can reply to the RREQ if it knows an up-to-date route to the destination
or it is the destination itself by sending a route reply (RREP) back to the source node. Figure
11 shows the format of the RREP.

Figure 11. Route Reply (RREP) Format
Type field: Indicates the traffic: constant bit rate (CBR) or transmission control
protocol(TCP).
L field: Indicates if the L-bit is set. If set, the message is a hello message and contains a list
of the node's neighbors. If not set, then the L-field is ignored.
Reserved field: Reserved for future use.
Hop count field: Indicates the number of hops from the source IP address to the destination
IP address.
Destination IP address field: Indicates the IP address of the destination for which a route is
supplied.
Destination sequence number field: indicates the destination sequence number associated
with the route.
Lifetime field: indicates time for which nodes receiving the reply consider the route to be
valid.
Otherwise, the intermediate node will rebroadcast the RREQ to its neighbors and increase the
hop count. The intermediate nodes keep track of the source address and the broadcast ID and
discards redundant RREQ broadcasts. If an intermediate node cannot accommodate the
RREQ, it maintains the following information: destination IP address, source IP address,
broadcast ID, expiration time for reverse path route entry and the source node's sequence
number. This information will be necessary to implement the reverse and forward path setup
that accompanies the RREP.

5.1.1 REVERSE PATH SETUP
The RREQ contains six key pieces of information. The only information of interest to the
reverse path setup is the source sequence number and the destination sequence number. The
source sequence number maintains the most up-to-date information concerning the reverse
route to the source node. The destination sequence number indicates how up-to-date the route
to the destination node must be in order for the source node to accept it. Figure 12 depicts the
reverse path setup back to the source node S.
Figure 12. Reverse Path Setup to Source Node S.
The RREQ moves from the source node through numerous intermediate nodes. As the RREQ
traverses the network, it automatically begins to establish the reverse path from all nodes in
the network back to the source node. Nodes update their route table with source node
information before forwarding the RREQ. The reverse path entry is used to forward the
RREP back to the source node. The expiration time of the reverse path entries is long enough
for a RREP to be received and forwarded.
5.1.2 FORWARD PATH SETUP
The RREQ will eventually arrive at a node that contains the most current route to the
destination. The RREQ uses the source sequence number and the destination sequence
number for particular functions as previously stated in the reverse path setup. Intermediate
nodes in the network function as beacons in determining the most current route to the
destination. Intermediate node can reply to the RREQ when it contains a route with a
destination sequence number that is greater than or equal to the destination sequence number
in the RREQ. Otherwise, the intermediate node rebroadcasts the RREQ. The intermediate
node can unicast a route reply (RREP) packet to the neighbor from which it received the
RREQ under two conditions, both of which must be satisfied. If the intermediate node
contains a current route to the destination node and the RREQ has not been processed
previously, then the RREP can be sent.
As the RREP traverses the network back to the source, two processes occur. The intermediate
nodes along the path use the reverse path setup to forward the RREP, and forward links
(forward path setup) are established when the RREP travels along the reverse path. Figure 13
depicts the forward path setup from the source node S to the destination node D.

Figure 13: Forward Path Setup from Source S to Destination D.
The source node can begin transmitting data once it receives the first RREP. Additionally, the
source node can update its routing information if it knows a better route at any time.
AODV minimizes the network load for control and data traffic. It is capable of adjusting to
changes in topology and ensures loop-free routing even while repairing broken links.
5.2. EXAMPLE SCENARIOS
Let us consider few scenarios for AODV routing in NS2.
a) 10 nodes b) 20 nodes c) 30 nodes d) 40 nodes e) 50 nodes
Figure 14. AODV routing in 10 mobile nodes

These scenarios are considered for evaluation and analysis of various performance metrics
and to study the dependency & variation characteristics. It is also used to compare between
various protocols under various circumstances.

5.3. MERITS & DEMERITS OF AODV ROUTING PROTOCOL
The following are considered to be the merits of AODV routing protocol:
1. The AODV routing protocol does not need any central administrative system to control the
routing process. AODV tend to reduce the control traffic messages overhead at the cost of
increased latency in finding new routes.
2. AODV reacts relatively fast to the topological changes in the network and updates only the
nodes affected by these changes.
3. The HELLO messages supporting the routes maintenance are range-limited, so they do not
cause unnecessary overhead in the network.
4. The AODV routing protocol saves storage place as well as energy. The destination node
replies only once to the first request and ignores the rest. The routing table maintains at most
one entry per destination.
5. If a node has to choose between two routes, the up-to-date route with a greater destination
sequence number is always chosen. If routing table entry is not used recently, the entry is
expired.
6. A not valid route is deleted: the error packets reach all nodes using a failed link on its route
to any destination.
The following are considered to be the limitations / demerits of AODV routing protocol:
1. Requirement on broadcast medium: The algorithm expects/requires that the nodes in the
broadcast medium can detect each others’ broadcasts.
2. Overhead on the bandwidth: Overhead on bandwidth will be occurred compared to DSR,
when an RREQ travels from node to node in the process of discovering the route info on
demand, it sets up the reverse path in itself with the addresses of all the nodes through which
it is passing and it carries all this info all its way.
3. No reuse of routing info: AODV lacks an efficient route maintenance technique. The
routing info is always obtained on demand, including for common case traffic.
4. It is vulnerable to misuse: The messages can be misused for insider attacks including route
disruption, route invasion, node isolation, and resource consumption.
5. AODV lacks support for high throughput routing metrics: AODV is designed to support
the shortest hop count metric. This metric favours long, low bandwidth links over short, high
bandwidth links.
6. High route discovery latency: AODV is a reactive routing protocol. This means that
AODV does not discover a route until a flow is initiated. This route discovery latency result
can be high in large-scale mesh networks.

6. ENHANCED AD HOC ON-DEMAND
DISTANCE VECTOR (AODV) ROUTING
We know that, in a MANET, mobility and power drain of a node causes frequent path
failures / link failures and in return causes frequent route discoveries. A mobile node blindly
rebroadcasts the first received route request packets unless it has a route to the destination,
and thus it causes the broadcast storm problem and hence results in overhead at each node.
Due to the dynamic nature of MANETs, route interferences are quite common. Route
reconstructions are major task for MANETs. Due to the dynamic topology, we mainly focus
on route management which includes Route discovery, Routing table and Logging structures.
Now, considering AODV routing protocol, we know that it is a combination of DSDV
protocol and DSR protocol. Therefore, it is considered to be the best routing protocol among
the most popular used protocols for MANETs. Though AODV is quick in finding routes and
suitable for high mobility nodes, it also causes delay, overhead and high latency. To
overcome these demerits and establish a stable path for transmission, we need to enhance or
improve the AODV routing protocol. Let us name the enhanced version of AODV routing
protocol as “EAODV”.
In EAODV, for successful transmission of packets from source to destination, the node
broadcast range is increased. It therefore triggers more number of nodes with lesser number
of hops required for successful transmission of packets. In this mechanism, all the nodes in a
scenario are categorized into zones. Each zone consists of a group of nodes, which is divided
based on each node’s transmission / broadcast range and nodes with similar ranges are
grouped into a single zone. Each zone follows a node forwarding mechanism which can
forward request only to a concerned packet. It has other nodes at backup. If transmission
through one node is failed, it is achieved by the other node.
We know that in AODV, communication depends on nearest neighbors, and then to the
destination, hence doesn’t form a stable path. Every node has limited energy and limited
memory. Once an intermediate node discards, broadcast process has to be reconstructed or
restarted. But in EAODV, we form different zones / clusters. It manipulates the transmission
range. We need to select a cluster head node in each zone. This cluster head communicates
with cluster head of other zones. As in AODV, here the cluster head communicates with
nearest cluster head first. A cluster head communicates with other intermediate nodes of a
zone. A cluster head is selected based on energy. This mechanism is clearly depicted in the
flowchart diagram (Figure 19). If one cluster head is discarded, other cluster head is elected
by remaining nodes based on their opinions. During the conversations, buffer zones are
formed. When a cluster head transmits packets to the destination, it initially identifies a
nearest cluster head and communicates. Each cluster head maintains the buffer information
and hence can select other node even if one of the nodes is discarded. We are hence reducing
the number of hops by making zone area communications, thereby reduces the transmission
distance and communication patterns. It also reduces routing overhead issues as other nodes
are selected if overhead occurs on one node. Each cluster head contains Sequence ID, Source
port number, Source ID, Next hop ID, Message bits, Destination port number, Destination
ID. Port numbers are used to maintain communication between other cluster heads.

Figure 19. Flowchart for EAODV algorithm
6.1. DEFINITIONS
So far we have discussed about the enhancement theoretically. But coming to the practical
approach, enhancement procedure includes the changes to be made at the back-end, i.e. is the
C++ code has to be changed. Before practically working on it, we need to have a basic
knowledge about few arguments.
a) PACKET ROUTINES :
This is the main class to deal with packets. It is connected with the Tcl and takes arguments
from there.

 Pkt_create()
This function creates a fresh new packet and initializes as much as it knows by attaching
common header, IP header and EAODV header.
 Pkt_copy()
This function copies an entire packet to another by copying all items one by one.
 Pkt_send()
This function sends a packet, i.e. schedule it for sometime in future to the target of EAODV.
This packet is unicasted only to the "addressee" (destination). It also increments the
transmitted / sent packets.
 Pkt_broadcast()
This function broadcasts the packet to all its neighboring nodes.
 Find_next_hop()
This function returns the address of the next hop on the route list of a packet. In case of any
error, it returns the first node on the list.
 Send_next_hop()
This function sends the packet to next hop on the route list of a packet.
 Find_prev_hop()
This function returns the address of the previous hop on the route list of a packet. If any error
occurs it returns the current node's address.
 Send_prev_hop()
This function sends the packet to the previous hop on the route list of a packet.
 Zdrop()
This function drops the packet after properly free dynamic memory allocation.
 Add_outer_route()
This function adds an outer route to destination "daddr" to a route list in a packet.

b) EAODV PROTOCOL :
The EAODV pro-actively and periodically distributes route information among the members
of a zone, defined as the nodes that are up to and including radius R hops away.
 Do_update()
This function actually does the work for doing link update, and re-computes route table.
 Update_outer_route()
This function updates the list of outer routes for any changes to the local routes.
 Add_local_route()
This function adds the route to packet in case if local route to “daddr” exists. It returns true if
local route exists otherwise returns false.
 Recv()
This function receives incoming packet, determines if it is an EAODV packet or not. If it is
an EAODV packet, it is processed by EAODV (IERP) at recvEAODV. If it is not an EAODV
packet, that means the packet is coming from the upper layer, and the packet needs to be
routed using route_pkt.
 RecvEAODV()
This function processes the received EAODV type packet.
 Originate_request()
This function is called by EAODV to start a request from source node.
 Route_pkt()
This function routes the packet, first it checks if there is a local route. If so, it adds the route
to packet and sends the packet. Otherwise it checks if there is an outer route, adds the route
and sends the packet. Else it originates the request.
 NDP Table
In this project the EAODV relies on information from the routing table to track neighbors and
link states with neighbors. EAODV uses a beacon and acknowledgment packets to obtain link
states. New neighbors or expired entries in the neighbor table trigger an immediate update to
the entire zone, and periodic link updates keep the entire zone appraised of each other's states.

 Neighbor_add()
This function adds neighbor with address "addr" to NDP table if it is not already there. If
neighbor already exists, it returns false otherwise it returns true.
c) ROUTING TABLE :
 Erase()
This function erases the route and peripheral tables.
 Compute_routes()
This function computes minimum hop routes to all nodes that are "radius" hops or less with
respect to node “myadd”, given the link state table.
 Get_entry()
This function looks up the node with address "id" in route table, and returns index into table
if it exists, otherwise sets to “NotInTable”.
 Route_exists()
This function looks up node with address "id" in route table. This function returns TRUE if
that node is in the table, otherwise false.
 Node_exists()
This function looks up node with address "node id" in route table, and returns the index if it is
in the table, otherwise -1.
 Add_drop()
This function adds one more entry to route tree if this node "entree" is found to be one hop
away from an entry already in route tree, i.e. if node is equal to source or destination of this
link, "lnk". If it is matched, this link is marked as covered for next pass. If no match found,
then the function will return, and caller will continue iterating through link state table.

6.2. EAODV ALGORITHMS
These algorithms are defined to explain detailed transmission of packets from source to
destination through intermediate nodes.
ALGORITHM 1: SOURCE NODE
1. Broadcast ‘RREQ, H = 1 and max j’
2. Listen to broadcast packet (such as RREQ, RREP)
3. If the packet is a duplicate then
4. Discard it
5. Else, wait until a RREP is received
6. Broadcast the ‘stop instruction’ and H to everyone within the ring where it sent
following conventional TTL scheme
7. Use the 1st RREP for the data packet and save 2nd RREP as a backup
8. Drop any later RREPs
9. End if
ALGORITHM 2: INTERMEDIATE NODES
1. Listen to RREQ
2. Check the max j after receiving the RREQ
3. If the H is bigger than the max j then,
4. Drop the RREQ
5. Else
6. Check the route cache after receiving the RREQ
7. If there is route information in the cache (i.e. being the Route Node) then,
8. Send a RREP and H to the source node
9. Else wait for a period of ‘waiting time’ (i.e. 2 × HopNumber)
10. While waiting
11. If receives a ‘stop instruction’ then,
12. Call the blocking procedure (see Algorithm 4)
13. Erase the source-destination pair in the route cache
14. Else if receives a ‘RREP’ then
15. Forward it to the source node
16. End if
17. End while
18. If receives no ‘stop instruction’ then
19. Increase the hop serial number by 1 and rebroadcast RREQ
20. End if
21. End if (ending checking of route information)
22. End if (ending checking of H number)

ALGORITHM 3: DESTINATION NODE (ROUTE)
1. Wait for the first arriving RREQ
2. If receive a RREQ then
3. Send the RREP and the H to the source route (contained in the RREQ packet)
4. End if
ALGORITHM 4: PROCEDURE OF BLOCKING
1. Compare Hr with H
2. If Hr is bigger then,
3. Forward the stop instruction and
5. Else
6. Drop the stop instruction and
7. Stop rebroadcasting and
9. End if
6.3. PRACTICAL APPROACH
As discussed earlier, any changes to AODV protocol has to be done at the back end. So we
need to change the C++ code. We write our C++ code in /usr/local/ns-allinone-2.35/ns-
2.35/eaodv folder
To include the C++ code into NS-2,
STEP 1 :
Edit /usr/loal/ns-allinone-2.35/ns-2.35/Makefile.in
Add following line in OBJ_CC section
eaodv/eaodv.o
STEP 2 :
Edit /usr/loal/ns-allinone-2.35/ns-2.35/common/packet.h
To define any new packet type we have to modify packet.h file.
a) Add the following line to packet_t section
static const packet_t PT_EAODV = 62;
static packet_t PT_NTYPE = 63; // This MUST be the LAST one

b) Add the following line in class p_info section
static packetClass classify(packet_t type) {
if (type == PT_DSR ||
type == PT_MESSAGE ||
type == PT_TORA ||
type == PT_AODV ||
type == PT_EAODV)
c) Add the following line in class p_info section
name_[PT_AOMDV]= "AOMDV";
name_[PT_NEWRP]="EAODV";
name_[PT_NTYPE]= "undefined";
STEP 3 :
Edit /usr/local/ns-allinone-2.35/ns-2.35/tcl/lib/nspacket.tcl
To configure routing agent , ADD protocol Name (line no : 175)
EAODV
STEP 4 :
Edit /usr/local/ns-allinone-2.35/ns-2.35/tcl/lib/nslib.tcl
Add the following line in switch -exact $routingAgent_ section (line no : 632)
EAODV {
set ragent [$self create-eaodv-agent $node]
}
The following code should be added in same ns-lib.tcl at the end of the file
Simulator instproc create-eaodv-agent { node } {
# Create eaodv routing agent
set ragent [new Agent/EAODV [$node node-addr]]
$self at 0.0 "$ragent start"
$node set ragent_ $ragent
return $ragent
}
STEP 5 :
Edit /usr/local/ns-allinone-2.35/ns-2.35/tcl/lib/nsagent.tcl
Add the following code at the end of the file
Agent/EAODV instproc init args {
$self next $args
}
Agent/EAODV set sport_ 0
Agent/EAODV set dport_ 0

STEP 6 :
Recompiling NS-2.
At the terminal, go to /usr/local/ns-allinone-2.35/ns-2.35/ directory and do
./configure
make clean
make
make install
This way, we can successfully enhance the AODV protocol and name the enhanced version
as EADOV protocol. Now let us consider few example scenarios.
6.4. EXAMPLE SCENARIOS
Let us consider few scenarios for EAODV routing in NS2.
a) 10 nodes b) 20 nodes c) 30 nodes d) 40 nodes e) 50 nodes
Figure 20. EAODV routing in 10 mobile nodes

These scenarios are considered for evaluating the performance metrics and inter
dependencies. In the later sections, we use these simulation results for comparisons.

7. PERFORMANCE METRICS
There are different kinds of parameters for the performance evaluation of the routing
protocols. These have different behaviours of the overall network performance. We will
evaluate four parameters for the comparison of our study on the overall network performance.
These parameters are delay, packet delivery ratio, routing overhead, and throughput for
protocols evaluation. These parameters are important in the consideration of evaluation of the
routing protocols in a communication network. These protocols need to be checked against
certain parameters for their performance. To check protocol effectiveness in finding a route
towards destination, we will look to the source that how much control messages it sends. It
gives the routing protocol internal algorithm’s efficiency. If the routing protocol gives much
end to end delay so probably this routing protocol is not efficient as compare to the protocol
which gives low end to end delay. Similarly a routing protocol offering low network load is
called efficient routing protocol. The same is the case with the throughput as it represents the
successful deliveries of packets in time. If a protocol shows high throughput so it is the
efficient and best protocol than the routing protocol which have low throughput. These
parameters have great influence in the selection of an efficient routing protocol in any
communication network.
7.1 DELAY
The packet end-to-end delay is the time of generation of a packet by the source up to the
destination reception. So this is the time that a packet takes to go across the network. This
time is expressed in sec. Hence all the delays in the network are called packet end-to-end
delay, like buffer queues and transmission time. Sometimes this delay can be called as
latency; it has the same meaning as delay. Some applications are sensitive to packet delay
such as voice is a delay sensitive application. So the voice requires a low average delay in the
network. The FTP is tolerant to a certain level of delays. There are different kinds of
activities because of which network delay is increased. Packet end-to-end delay is a measure
of how sound a routing protocol adapts to the various constraints in the network to give
reliability in the routing protocol. We have several kinds of delays which are processing
delay (PD), queuing delay (QD), transmission delay (TD) and propagation delay (PD). The
queuing delay (QD) is not included, as the network delay has no concern with it.
Mathematically it can be shown as equation.
dend-end = N[dtrans + dprop + dproc]
where,
dend-end = End to End Delay
dtrans = Transmisson Delay
dprop = Propagation Delay
dproc = Processing Delay

Suppose if there are n number of nodes, then the total delay can be calculated by taking the
average of all the packets, source destination pairs and network configuration.
7.2 ROUTING OVERHEAD
Nodes often change their location within network. So, some stale routes are generated in the
routing table which leads to unnecessary overhead called the routing overhead. In MANET,
every node requires to participate as a router, maintaining individually routes to other nodes.
If the number of nodes grows largely, the number of routes will increase rapidly. This effect
together with the mobility of nodes may increase the overhead due to the maintenance of the
routes, consuming the scarce bandwidth in the MANET and therefore reducing the
throughput. The efficient network can easily cope with large traffic coming in, and to make a
best network, many techniques have been introduced. High overhead affects the MANET
routing packets and slow down the delivery of packets for reaching to the channel and it
results in increasing the collisions of these control packets.
7.3 THROUGHPUT
Throughput is defined as the ratio of the total data reaches a receiver from the sender. The
time it takes by the receiver to receive the last message is called as throughput. Throughput is
expressed as bytes or bits per sec (byte/sec or bit/sec). Some factors affect the throughput as;
if there are many topology changes in the network, unreliable communication between nodes,
limited bandwidth available and limited energy. A high throughput is absolute choice in
every network. Throughput can be represented mathematically as in equation,
Throughput = Number of delivered packets*packet size*8
Total duration of simulation
7.4 PACKET DELIVERY RATIO
Packet delivery ratio (PDR) is one of the most important parameters we use to measure the
network performance. It is defined as the ratio between the total data packets received to that
of the total data packets sent.
Mathematically it can be expressed as,
PDR = Total data packets received / Total data packets sent.

8. RESULTS AND ANALYSIS
A. Simulation Environment:
The simulation experiment is carried out in LINUX platform (Ubuntu Operating
System). The detailed simulation model is based on network simulator-2 (ver-2.35), is
used in the evaluation. The NS instructions can be used to define the topology
structure of the network and the motion mode of the nodes, to configure the service
source and the receiver, to create the statistical data track file and so on.
B. Traffic Model:
Continuous bit rate (CBR) traffic sources are used. The source-destination pairs are
spread randomly over the network.
C. Mobility Model:
The mobility model used is Random waypoint mobility model because it models the
random movement of the mobile nodes.
We have used five scenarios to compare AODV and EAODV, using the performance metrics.
The example scenarios we consider are:
i. 10 nodes
ii. 20 nodes
iii. 30 nodes
iv. 40 nodes
v. 50 nodes
Let us colour these graphs and allot green colour for EAODV protocol and red for AODV
protocol
EAODV Green
AODV Red
8.1 NUMBER OF TRANSMITTED PACKETS vs TIME
Before starting our comparison between them using performance metrics, let us compare
these two protocols using Number of transmitted packets vs. Time.
Now we simulate the graphs for AODV & EAODV which shows the Number of transmitted
packets on y-axis and Simulation time on x-axis.

Figure 25. No of Transmitted packets vs Time for 10 nodes in AODV & EAODV

From these graphs, we found that the overall numbers of transmitted packets are increasing
with increase in number of nodes for EAODV. It is found that the transmitted packets are
almost similar for AODV and EAODV in case of 10nodes and 20nodes. It is because these
cases have lesser routing overheads and hence lesser link breakages. Anyways, our proposed
protocol EAODV is quite efficient in transmitting more number of packets from sender to
destination for higher number of nodes and higher mobilities. The graph is almost logarithmic
increase in nature, whereas AODV is attenuated for higher nodes.

8.2 AVERAGE END-TO-END DELAY vs NO. OF NODES
A specific packet is transmitting from source to destination node and calculates the difference
between send times and received times. Delays due to route discovery, queuing, propagation
and transfer time are included in the delay metric. We have Average end-to-end delay on y-
axis and Number of nodes on x-axis.
Figure 30. Average end-to end delay vs No. of nodes
In AODV, the time taken to establish a route is high. Hence the delay increases with increase
in number of nodes and increase in mobilities. Therefore there is a linear increase in delay in
case of AODV. In our proposed protocol EAODV, routes are established quicker. Hence the
delays are also comparatively very less. In EAODV, the delay goes into saturation after 40
nodes. At 50 nodes, when AODV and EAODV are compared for delays, AODV has more
than twice the delay of EAODV.

8.3 AVERAGE THROUGHPUT vs NO. OF NODES
Throughput is the number of packet that is passing through the channel in a particular unit of
time. This performance metric shows the total number of packets that have been successfully
delivered from source node to destination node.
Figure 31. Average throughput vs No. of nodes
At each scenario, when average throughput is considered, EAODV increases with an average
ratio of 1.15 times to that of AODV. It is due to a better rote management scheme. More
number of packets are reached to the destination with lesser attenuation.

8.4 PACKET DELIVERY RATIO vs NO. OF NODES
Packet delivery ratio is the ratio between the number of packets sent by Constant Bit Rate
(CBR) at application layer and the number of packets received by the CBR sink at
destination. It can also be defined as the ratio of data packets received by the destinations to
those generated by the sources.
Figure 32. Packet delivery ratio vs No. of nodes
From the graph, it is found that EAODV has better packet delivery ratio compared to AODV.
It is mainly due to the formation of a stable path between source and destination. At each
scenario, EAODV’s PDR value is almost 1.16 times greater than that of AODV.

8.4 ROUTING OVERHEAD vs NO. OF NODES
In a MANET, nodes often change their location within network. So, some stale routes are
generated in the routing table which leads to unnecessary overhead called the routing
overhead.
Figure 33. Routing overhead vs No. of nodes
Routing overhead is a major factor in defining the efficiency of protocol. In AODV protocol,
due to continuous route discoveries, we have more number of overheads forming at each
node. But in EAODV, as the broadcast range increases, we have lesser number of hops for
packet transmission, which in result reduces the routing overhead. Therefore analysing the
graph, as the number of nodes increase, EAODV decrease the overhead by almost 3 times
than that of AODV.

9. CONCLUSION AND FUTURE WORK
The thesis report is broadly divided into two parts, one is theoretical and logical study; and
other is a simulation study. From the first part of the study it was comprehended that routing
mechanisms in this scientific era of wireless communication, internet systems and in
telecommunications systems play an imperative role to enhance the communication between
end users. Varied routing protocols have multiple features based on their environmental
scenarios. Choosing a protocol as per the network requirement is really important as an
efficient protocol increases the reliability of that network.
The simulation study of our project consisted of two routing protocols AODV and enhanced
AODV, i.e. EAODV deployed over MANET using CBR traffic analyzing their behavior with
respect to four parameters, delay, routing overhead, packet delivery ratio and throughput. Our
motive was to check the performance of these two routing protocols in MANET in the above
mentioned parameters and prove that EAODV is a better routing protocol compared to
AODV. In this project, we proposed to reduce the routing overhead in MANET by
introducing probabilistic rebroadcast mechanism based on neighbor coverage knowledge
which includes additional coverage ratio and connective factor. The project was focused on
mechanism that would have good performance when the network is in high density or the
traffic load is high. The proposed system will generate less rebroadcast traffic that used to
occur in flooding. Because of less redundant rebroadcast, the proposed work will mitigate the
network collision and contention; this will increase the packet delivery ratio and reduce the
average end to end delay. Although the network is in high density or the traffic is heavily
loaded, the proposed work will have good performance.
The future work can also be done to compare the protocols with TCP traffic and if needed,
we do further modification to improve its performance. The Security research area is still
open as many of the provided solutions are designed keeping a limited size scenario and
limited kind of attacks.

REFERENCES
1. Lesiuk, Camberon B., "Routing in Ad Hoc Networks of Mobile Hosts," Directed Study,
Department of Mechanical Engineering, University of Victoria, Victoria BC, Canada, 2
December 1998.
2. Perkins, Charles E., Royer, Elizabeth M., "Ad-hoc On-Demand Distance Vector Routing,"
Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications,
New Orleans, LA, February 1999.
3. Gerla, M., Lee, S. J., Toh, C. K., "A Simulation Study of Table-Driven and On- Demand
Routing Protocols for Mobile Ad Hoc Networks," IEEE Network, Vol 13 Issue 4, Jul-Aug
1999.
4. Das, Samir R., Perkins, Charles E., Royer, Elizabeth M., "The Ad-hoc On- Demand
Distance Vector Routing Protocol (AODV) for Ad Hoc Networks," Internet Draft, draft-ietf-
manet-aodv-06.txt, July 2000.
5. Chlamtac, I., Conti, M., and Liu, J. J.-N. Mobile ad hoc networking: imperatives and
challenges. Ad Hoc Networks, 1(1), 2003, pp. 13–64.
6. Perkins, E. Belding-Royer, and S. Das, Ad Hoc On-Demand Distance Vector (AODV)
Routing, IETF RFC 3561, 2003.
7. S. Demers and L. Kant, “MANETs: Performance Analysis and Management”, Military
Communications Conference, MILCOM, 2006, pp.1 – 7
8. D. Kiwior and L. Lam, “Routing Protocol Performance over Intermittent Links” Military
Communications Conference, MILCOM, IEEE, 2007.
9. M Vijayalaskhmi, A Patel, L Kulkarni, QoS parameter Analysis on AODV and DSDV
protocols in Wireless, Network,International Journal of Communication Network & Security,
Volume-1, Issue-1, 2011.
10. Sachin Kumar Gupta & R.K. Saket, PERFORMANCE METRIC COMPARISON OF
AODV AND DSDV ROUTING PROTOCOLS IN MANETs USING NS-2, IJRRAS Volume
7 Issue 3 , June 2011.
11. Ambarish R. Bhuyar, Prof. V. T. Gaikwad, “A Review on Reducing Routing Overhead in
Mobile Ad Hoc Network using Probabilistic Rebroadcast Mechanism”, (IJCSIT)
International Journal of Computer Science and Information Technologies, Vol. 5 (1), 2014.
12. www.tcl.activestate.com/man/tcl8.5/tutorial/Tcl0.html
13. www.enggedu.com/source_code/ns2/ns2_wireless_network__samples.php
14. www.cs.virginia.edu/~cs757/slidespdf/cs757-ns2-tutorial-exercise.pdf
15. www.isi.edu/nsnam/ns/doc-stable/node1.html

APPENDIX A : TCL SCRIPTS FOR AODV
i. AODV code for 10 nodes
Phy/WirelessPhy set freq_ 2.472e9
Phy/WirelessPhy set RXThresh_ 2.62861e-09; #100m radius
Phy/WirelessPhy set CSThresh_ [expr 0.9*[Phy/WirelessPhy set RXThresh_]]
Phy/WirelessPhy set bandwidth_ 11.0e6
Mac/802_11 set dataRate_ 11Mb
Mac/802_11 set basicRate_ 2Mb
set val(chan) Channel/WirelessChannel ;
set val(prop) Propagation/TwoRayGround ;
set val(netif) Phy/WirelessPhy ;
set val(mac) Mac/802_11 ;
set val(ifq) Queue/DropTail/PriQueue ;
set val(ll) LL ;
set val(ant) Antenna/OmniAntenna ;
set val(ifqlen) 30 ;
set val(nn) 10 ;
set val(rp) AODV ;
set val(x) 200 ;
set val(y) 200 ;
set val(stop) 50 ;
set ns [new Simulator]
set tracefd [open AODV_10.tr w]
set winFile [open CwMaodv_10 w]
set namtracefd [open namwrls.nam w]
$ns trace-all $tracefd
$ns use-newtrace
$ns namtrace-all-wireless $namtracefd $val(x) $val(y)
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
$ns node-config -adhocRouting $val(rp)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-ifqLen $val(ifqlen)
-antType $val(ant)

-propType $val(prop)
-phyType $val(netif)
-channelType $val(chan)
-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns node]
}
$node_(0) set X_ 1.0
$node_(0) set Y_ 50.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 60.0
$node_(1) set Y_ 50.0
$node_(2) set X_ 25.0
$node_(2) set Y_ 65.0
$node_(3) set X_ 70.0
$node_(3) set Y_ 40.0
$node_(4) set X_ 80.0
$node_(4) set Y_ 30.0
$node_(5) set X_ 90.0
$node_(5) set Y_ 20.0
$node_(6) set X_ 100.0
$node_(6) set Y_ 10.0
$node_(7) set X_ 110.0
$node_(7) set Y_ 100.0
$node_(8) set X_ 120.0
$node_(8) set Y_ 1.0

$node_(9) set X_ 130.0
$node_(9) set Y_ 5.0
$ns at 10.0 "$node_(2) setdest 135.0 65.0 8.0"
set tcp [new Agent/TCP]
set sink [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp
$ns attach-agent $node_(2) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 0.1 "$ftp start"
$ns initial_node_pos $node_($i) 10
}
$ns at $val(stop) "$node_($i) reset"
}
$ns at $val(stop) "stop"
proc plotWindow {tcpSource file} {
global ns
set time 0.1
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file" }
$ns at 0.1 "plotWindow $tcp $winFile"
proc stop {} {
global ns tracefd namtracefd
$ns flush-trace
close $tracefd
close $namtracefd
exec nam namwrls.nam &
exit 0
}
$ns run

ii. AODV code for 20 nodes
set val(ll) LL ;
set val(nn) 20 ;
set val(rp) AODV ;
set val(x) 200 ;
set val(y) 200 ;
set val(stop) 50 ;
$ns use-newtrace
create-god $val(nn)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF
}
$node_(0) set X_ 95.0
$node_(0) set Y_ 50.0
$node_(1) set X_ 60.0
$node_(1) set Y_ 50.0
$node_(2) set X_ 25.0
$node_(2) set Y_ 190.0
$node_(3) set X_ 135.0
$node_(3) set Y_ 155.0
$node_(4) set X_ 105.0
$node_(4) set Y_ 180.0
$node_(5) set X_ 110.0
$node_(5) set Y_ 200.0
$node_(6) set X_ 55.0
$node_(6) set Y_ 75.0
$node_(7) set Y_ 20.0

$node_(8) set X_ 175.0
$node_(8) set Y_ 90.0
$node_(9) set X_ 115.0
$node_(9) set Y_ 115.0
$node_(10) set X_ 75.0
$node_(10) set Y_ 175.0
$node_(10) set Z_ 0.0
$node_(11) set X_ 150.0
$node_(11) set Y_ 135.0
$node_(11) set Z_ 0.0
$node_(12) set X_ 45.0
$node_(12) set Y_ 90.0
$node_(12) set Z_ 0.0
$node_(13) set X_ 10.0
$node_(13) set Y_ 45.0
$node_(13) set Z_ 0.0
$node_(14) set X_ 90.0
$node_(14) set Y_ 1.0
$node_(14) set Z_ 0.0
$node_(15) set X_ 110.0
$node_(15) set Y_ 100.0
$node_(15) set Z_ 0.0
$node_(16) set X_ 160.0
$node_(16) set Y_ 120.0
$node_(16) set Z_ 0.0
$node_(17) set X_ 180.0
$node_(17) set Y_ 20.0
$node_(17) set Z_ 0.0
$node_(18) set X_ 120.0
$node_(18) set Y_ 10.0
$node_(18) set Z_ 0.0
$node_(19) set X_ 190.0
$node_(19) set Y_ 1.0
$node_(19) set Z_ 0.0

}
}
global ns
set time 0.1
set now [$ns now]
proc stop {} {
$ns flush-trace
close $tracefd
close $namtracefd
exit 0
}
$ns run

iii. AODV code for 30 nodes
set val(ll) LL ;
set val(nn) 30 ;
set val(rp) AODV ;
set val(x) 300 ;
set val(y) 300 ;
set val(stop) 50 ;
$ns use-newtrace
create-god $val(nn)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF
}
$node_(0) set X_ 95.0
$node_(0) set Y_ 50.0
$node_(1) set X_ 60.0
$node_(1) set Y_ 50.0
$node_(2) set X_ 25.0
$node_(2) set Y_ 190.0
$node_(3) set X_ 135.0
$node_(3) set Y_ 155.0
$node_(4) set X_ 105.0
$node_(4) set Y_ 180.0
$node_(5) set X_ 110.0
$node_(5) set Y_ 200.0
$node_(6) set X_ 55.0
$node_(6) set Y_ 75.0
$node_(7) set Y_ 20.0
$node_(8) set X_ 175.0
$node_(8) set Y_ 90.0
$node_(9) set X_ 115.0
$node_(9) set Y_ 115.0

$node_(10) set X_ 75.0
$node_(10) set Y_ 175.0
$node_(10) set Z_ 0.0
$node_(11) set X_ 150.0
$node_(11) set Y_ 135.0
$node_(11) set Z_ 0.0
$node_(12) set X_ 45.0
$node_(12) set Y_ 90.0
$node_(12) set Z_ 0.0
$node_(13) set X_ 10.0
$node_(13) set Y_ 45.0
$node_(13) set Z_ 0.0
$node_(14) set X_ 90.0
$node_(14) set Y_ 1.0
$node_(14) set Z_ 0.0
$node_(15) set X_ 110.0
$node_(15) set Y_ 100.0
$node_(15) set Z_ 0.0
$node_(16) set X_ 160.0
$node_(16) set Y_ 120.0
$node_(16) set Z_ 0.0
$node_(17) set X_ 180.0
$node_(17) set Y_ 20.0
$node_(17) set Z_ 0.0
$node_(18) set X_ 120.0
$node_(18) set Y_ 10.0
$node_(18) set Z_ 0.0
$node_(19) set X_ 190.0
$node_(19) set Y_ 1.0
$node_(19) set Z_ 0.0
$node_(20) set X_ 150.0
$node_(20) set Y_ 135.0
$node_(20) set Z_ 0.0
$node_(21) set X_ 45.0
$node_(21) set Y_ 190.0
$node_(21) set Z_ 0.0
$node_(22) set X_ 200.0
$node_(22) set Y_ 45.0

$node_(23) set X_ 275.0
$node_(23) set Y_ 1.0
$node_(23) set Z_ 0.0
$node_(24) set X_ 260.0
$node_(24) set Y_ 100.0
$node_(24) set Z_ 0.0
$node_(25) set X_ 245.0
$node_(25) set Y_ 120.0
$node_(25) set Z_ 0.0
$node_(26) set X_ 230.0
$node_(26) set Y_ 225.0
$node_(26) set Z_ 0.0
$node_(27) set X_ 215.0
$node_(27) set Y_ 220.0
$node_(27) set Z_ 0.0
$node_(28) set X_ 300.0
$node_(28) set Y_ 200.0
$node_(28) set Z_ 0.0
$node_(29) set X_ 290.0
$node_(29) set Y_ 210.0
$node_(29) set Z_ 0.0

}
}
global ns
set time 0.1
set now [$ns now]
proc stop {} {
$ns flush-trace
close $tracefd
close $namtracefd
exit 0
}
$ns run

iv. AODV code for 40 nodes
set val(ll) LL ;
set val(nn) 40 ;
set val(rp) AODV ;
set val(x) 400 ;
set val(y) 400 ;
set val(stop) 50 ;
$ns use-newtrace
create-god $val(nn)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF
}
$node_(0) set X_ 95.0
$node_(0) set Y_ 50.0
$node_(1) set X_ 60.0
$node_(1) set Y_ 50.0
$node_(2) set X_ 25.0
$node_(2) set Y_ 190.0
$node_(3) set X_ 135.0
$node_(3) set Y_ 155.0
$node_(4) set X_ 105.0
$node_(4) set Y_ 180.0
$node_(5) set X_ 110.0
$node_(5) set Y_ 200.0
$node_(6) set X_ 55.0
$node_(6) set Y_ 75.0
$node_(7) set Y_ 20.0
$node_(8) set X_ 175.0
$node_(8) set Y_ 90.0
$node_(9) set X_ 115.0
$node_(9) set Y_ 115.0

$node_(10) set X_ 75.0
$node_(10) set Y_ 175.0
$node_(10) set Z_ 0.0
$node_(11) set X_ 150.0
$node_(11) set Y_ 135.0
$node_(11) set Z_ 0.0
$node_(12) set X_ 45.0
$node_(12) set Y_ 90.0
$node_(12) set Z_ 0.0
$node_(13) set X_ 10.0
$node_(13) set Y_ 45.0
$node_(13) set Z_ 0.0
$node_(14) set X_ 90.0
$node_(14) set Y_ 1.0
$node_(14) set Z_ 0.0
$node_(15) set X_ 110.0
$node_(15) set Y_ 100.0
$node_(15) set Z_ 0.0
$node_(16) set X_ 160.0
$node_(16) set Y_ 120.0
$node_(16) set Z_ 0.0
$node_(17) set X_ 180.0
$node_(17) set Y_ 20.0
$node_(17) set Z_ 0.0
$node_(18) set X_ 120.0
$node_(18) set Y_ 10.0
$node_(18) set Z_ 0.0
$node_(19) set X_ 190.0
$node_(19) set Y_ 1.0
$node_(19) set Z_ 0.0
$node_(20) set X_ 150.0
$node_(20) set Y_ 135.0
$node_(20) set Z_ 0.0
$node_(21) set X_ 45.0
$node_(21) set Y_ 190.0
$node_(21) set Z_ 0.0

$node_(22) set X_ 200.0
$node_(22) set Y_ 45.0
$node_(23) set X_ 275.0
$node_(23) set Y_ 1.0
$node_(23) set Z_ 0.0
$node_(24) set X_ 260.0
$node_(24) set Y_ 100.0
$node_(24) set Z_ 0.0
$node_(25) set X_ 245.0
$node_(25) set Y_ 120.0
$node_(25) set Z_ 0.0
$node_(26) set X_ 230.0
$node_(26) set Y_ 225.0
$node_(26) set Z_ 0.0
$node_(27) set X_ 215.0
$node_(27) set Y_ 220.0
$node_(27) set Z_ 0.0
$node_(28) set X_ 300.0
$node_(28) set Y_ 200.0
$node_(28) set Z_ 0.0
$node_(29) set X_ 290.0
$node_(29) set Y_ 210.0
$node_(29) set Z_ 0.0
$node_(30) set X_ 15.0
$node_(30) set Y_ 335.0
$node_(30) set Z_ 0.0
$node_(31) set X_ 390.0
$node_(31) set Y_ 390.0
$node_(31) set Z_ 0.0
$node_(32) set X_ 200.0
$node_(32) set Y_ 350.0
$node_(33) set X_ 375.0
$node_(33) set Y_ 310.0
$node_(33) set Z_ 0.0
$node_(34) set X_ 360.0
$node_(34) set Y_ 100.0

$node_(34) set Z_ 0.0
$node_(35) set X_ 345.0
$node_(35) set Y_ 320.0
$node_(35) set Z_ 0.0
$node_(36) set X_ 330.0
$node_(36) set Y_ 375.0
$node_(36) set Z_ 0.0
$node_(37) set X_ 315.0
$node_(37) set Y_ 220.0
$node_(37) set Z_ 0.0
$node_(38) set X_ 400.0
$node_(38) set Y_ 200.0
$node_(38) set Z_ 0.0
$node_(39) set X_ 390.0
$node_(39) set Y_ 210.0
$node_(39) set Z_ 0.0

}
}
global ns
set time 0.1
set now [$ns now]
proc stop {} {
$ns flush-trace
close $tracefd
close $namtracefd
exit 0
}
$ns run

v. AODV code for 50 nodes
set val(ll) LL ;
set val(nn) 50 ;
set val(rp) AODV ;
set val(x) 500 ;
set val(y) 500 ;
set val(stop) 50 ;
$ns use-newtrace
create-god $val(nn)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

$node_(8) set X_ 175.0
$node_(8) set Y_ 90.0
$node_(9) set X_ 115.0
$node_(9) set Y_ 115.0
$node_(10) set X_ 75.0
$node_(10) set Y_ 175.0
$node_(10) set Z_ 0.0
$node_(11) set X_ 150.0
$node_(11) set Y_ 135.0
$node_(11) set Z_ 0.0
$node_(12) set X_ 45.0
$node_(12) set Y_ 90.0
$node_(12) set Z_ 0.0
$node_(13) set X_ 10.0
$node_(13) set Y_ 45.0
$node_(13) set Z_ 0.0
$node_(14) set X_ 90.0
$node_(14) set Y_ 1.0
$node_(14) set Z_ 0.0
$node_(15) set X_ 110.0
$node_(15) set Y_ 100.0
$node_(15) set Z_ 0.0
$node_(16) set X_ 160.0
$node_(16) set Y_ 120.0
$node_(16) set Z_ 0.0
$node_(17) set X_ 180.0
$node_(17) set Y_ 20.0
$node_(17) set Z_ 0.0
$node_(18) set X_ 120.0
$node_(18) set Y_ 10.0
$node_(18) set Z_ 0.0
$node_(19) set X_ 190.0
$node_(19) set Y_ 1.0
$node_(19) set Z_ 0.0
$node_(20) set X_ 150.0

$node_(20) set Y_ 135.0
$node_(20) set Z_ 0.0
$node_(21) set X_ 45.0
$node_(21) set Y_ 190.0
$node_(21) set Z_ 0.0
$node_(22) set X_ 200.0
$node_(22) set Y_ 45.0
$node_(23) set X_ 275.0
$node_(23) set Y_ 1.0
$node_(23) set Z_ 0.0
$node_(24) set X_ 260.0
$node_(24) set Y_ 100.0
$node_(24) set Z_ 0.0
$node_(25) set X_ 245.0
$node_(25) set Y_ 120.0
$node_(25) set Z_ 0.0
$node_(26) set X_ 230.0
$node_(26) set Y_ 225.0
$node_(26) set Z_ 0.0
$node_(27) set X_ 215.0
$node_(27) set Y_ 220.0
$node_(27) set Z_ 0.0
$node_(28) set X_ 300.0
$node_(28) set Y_ 200.0
$node_(28) set Z_ 0.0
$node_(29) set X_ 290.0
$node_(29) set Y_ 210.0
$node_(29) set Z_ 0.0
$node_(30) set X_ 15.0
$node_(30) set Y_ 335.0
$node_(30) set Z_ 0.0
$node_(31) set X_ 390.0
$node_(31) set Y_ 390.0
$node_(31) set Z_ 0.0
$node_(32) set X_ 200.0

$node_(32) set Y_ 350.0
$node_(33) set X_ 375.0
$node_(33) set Y_ 310.0
$node_(33) set Z_ 0.0
$node_(34) set X_ 360.0
$node_(34) set Y_ 100.0
$node_(34) set Z_ 0.0
$node_(35) set X_ 345.0
$node_(35) set Y_ 320.0
$node_(35) set Z_ 0.0
$node_(36) set X_ 330.0
$node_(36) set Y_ 375.0
$node_(36) set Z_ 0.0
$node_(37) set X_ 315.0
$node_(37) set Y_ 220.0
$node_(37) set Z_ 0.0
$node_(38) set X_ 400.0
$node_(38) set Y_ 200.0
$node_(38) set Z_ 0.0
$node_(39) set X_ 390.0
$node_(39) set Y_ 210.0
$node_(39) set Z_ 0.0
$node_(40) set X_ 390.0
$node_(40) set Y_ 435.0
$node_(40) set Z_ 0.0
$node_(41) set X_ 490.0
$node_(41) set Y_ 290.0
$node_(41) set Z_ 0.0
$node_(42) set X_ 450.0
$node_(42) set Y_ 350.0
$node_(42) set Z_ 0.0
$node_(43) set X_ 475.0
$node_(43) set Y_ 310.0
$node_(43) set Z_ 0.0
$node_(44) set X_ 460.0
$node_(44) set Y_ 300.0

$node_(44) set Z_ 0.0
$node_(45) set X_ 445.0
$node_(45) set Y_ 420.0
$node_(45) set Z_ 0.0
$node_(46) set X_ 430.0
$node_(46) set Y_ 475.0
$node_(46) set Z_ 0.0
$node_(47) set X_ 415.0
$node_(47) set Y_ 420.0
$node_(47) set Z_ 0.0
$node_(48) set X_ 499.0
$node_(48) set Y_ 400.0
$node_(48) set Z_ 0.0
$node_(49) set X_ 390.0
$node_(49) set Y_ 410.0
$node_(49) set Z_ 0.0

}
}
global ns
set time 0.1
set now [$ns now]
proc stop {} {
$ns flush-trace
close $tracefd
close $namtracefd
exit 0
}
$ns run

APPENDIX B : TCL SCRIPTS FOR EAODV
i. EAODV code for 10 nodes
set val(ll) LL ;
set val(nn) 10 ;
set val(rp) EAODV ;
set val(x) 200 ;
set val(y) 200 ;
set val(stop) 50 ;
set tracefd [open EAODV_10.tr w]
set winFile [open eaodv_10 w]
$ns use-newtrace
create-god $val(nn)
$ns node-config -adhocRouting EAODV
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

ii. EAODV code for 20 nodes
set val(ll) LL ;
set val(nn) 20 ;
set val(rp) EAODV ;
set val(x) 200 ;
set val(y) 200 ;
set val(stop) 50 ;
set winFile [open CwMeaodv_20 w]
$ns use-newtrace
create-god $val(nn)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF
}
$node_(0) set X_ 95.0
$node_(0) set Y_ 50.0
$node_(1) set X_ 60.0
$node_(1) set Y_ 50.0
$node_(2) set X_ 25.0
$node_(2) set Y_ 190.0
$node_(3) set X_ 135.0
$node_(3) set Y_ 155.0
$node_(4) set X_ 105.0
$node_(4) set Y_ 180.0
$node_(5) set X_ 110.0
$node_(5) set Y_ 200.0
$node_(6) set X_ 55.0
$node_(6) set Y_ 75.0
$node_(7) set Y_ 20.0
$node_(8) set X_ 175.0

$node_(8) set Y_ 90.0
$node_(9) set X_ 115.0
$node_(9) set Y_ 115.0
$node_(10) set X_ 75.0
$node_(10) set Y_ 175.0
$node_(10) set Z_ 0.0
$node_(11) set X_ 150.0
$node_(11) set Y_ 135.0
$node_(11) set Z_ 0.0
$node_(12) set X_ 45.0
$node_(12) set Y_ 90.0
$node_(12) set Z_ 0.0
$node_(13) set X_ 10.0
$node_(13) set Y_ 45.0
$node_(13) set Z_ 0.0
$node_(14) set X_ 90.0
$node_(14) set Y_ 1.0
$node_(14) set Z_ 0.0
$node_(15) set X_ 110.0
$node_(15) set Y_ 100.0
$node_(15) set Z_ 0.0
$node_(16) set X_ 160.0
$node_(16) set Y_ 120.0
$node_(16) set Z_ 0.0
$node_(17) set X_ 180.0
$node_(17) set Y_ 20.0
$node_(17) set Z_ 0.0
$node_(18) set X_ 120.0
$node_(18) set Y_ 10.0
$node_(18) set Z_ 0.0
$node_(19) set X_ 190.0
$node_(19) set Y_ 1.0
$node_(19) set Z_ 0.0

}
}
global ns
set time 0.1
set now [$ns now]
proc stop {} {
$ns flush-trace
close $tracefd
close $namtracefd
exit 0
}
$ns run

iii. EAODV code for 30 nodes
set val(ll) LL ;
set val(nn) 30 ;
set val(rp) EAODV ;
set val(x) 300 ;
set val(y) 300 ;
set val(stop) 50 ;
set winFile [open CwMeaodv_30 w]
$ns use-newtrace
create-god $val(nn)
-llType $val(ll)
-macType $val(mac)
-ifqType $val(ifq)
-antType $val(ant)

-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace OFF
-movementTrace OFF
}
$node_(0) set X_ 95.0
$node_(0) set Y_ 50.0
$node_(1) set X_ 60.0
$node_(1) set Y_ 50.0
$node_(2) set X_ 25.0
$node_(2) set Y_ 190.0
$node_(3) set X_ 135.0
$node_(3) set Y_ 155.0
$node_(4) set X_ 105.0
$node_(4) set Y_ 180.0
$node_(5) set X_ 110.0
$node_(5) set Y_ 200.0
$node_(6) set X_ 55.0
$node_(6) set Y_ 75.0
$node_(7) set Y_ 20.0
$node_(8) set X_ 175.0
$node_(8) set Y_ 90.0

eaodv

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to eaodv

Similar to eaodv (20)

eaodv