A Project on

Design and Analysis of Modified AODV

Submitted for partial fulfillment of award of

BACHELOR OF TECHNOLOGY
degree

In
Computer Science & Engineering

By
Ragini Tiwari(1235210083)
Shubhanshi Sharma(1235210096)
Surabhi Sharma(1235210102)

Name of Guide
Mr. Prashant Kumar Mishra

DR. A.P.J. ABDUL KALAM TECHNICAL UNIVERSITY,

LUCKNOW, INDIA
MAY, 2016
 CERTIFICATE

This is to certify that Ragini Tiwari, Shubhanshi Sharma

and Surabhi Sharma have carried out the B. Tech. Final Year
Project work presented in this report entitled “Design and Analysis
of Modified AODV” for the award of Bachelor of Technology
from Dr. A.P.J. Abdul Kalam Technical University, Lucknow under
my supervision. The project embodies result of original work and
studies carried out by student herself and the contents of the project
do not form the basis for the award of any other degree to the
candidate or to anybody else.

Mr. Prashant Kumar Mishra

(Supervisor & Head of Department)
CSE Department,
Krishna Institute of Technology,
Kanpur

Date:

i
 DECLARATION

This is to certify that report entitled “Design and Analysis of

Modified AODV” which is submitted by Ragini Tiwari, Shubhanshi
Sharma and Surabhi Sharma, in partial fulfillment of the award of
Bachelor of Technology in Computer Science to Department of
Computer Science and Engineering, KRISHNA INSTITUTE OF
TECHNOLOGY, KANPUR. It comprises of our original work and due
acknowledgement has been made in the text to all other materials used.

Ragini Tiwari (1235210083)

Shubhanshi Sharma(1235210096)

Surabhi Sharma (1235210102)

ii
 ACKNOWLEDGEMENT

We wish to express our deep sense of gratitude and indebtedness

to our mentor Mr. Prashant Kumar Mishra for introducing the present
topic and for his inspiring guidance, constructive criticism and valuable
suggestions throughout this project work. His continuous interest of the
research was a great source of motivation for us.

We also share the responsibility for the content presented in the

report and regret any omissions of our mistakes on our part that may
have inadvertently crept in.

In the end we would like to thank our friends, family for bearing
with us, supporting us emotionally thereby helping us to finish the
project.

Ragini Tiwari

Shubhanshi Sharma

Surabhi Sharma

iii
 ABSTRACT

The growth of wireless technology has developed since the

invention of wireless devices. With the recent introduction of
smartphones, and other latest mobile devices, the growing need for
networking is limitless. This calls for a more efficient adhoc network
formed on the go. The goal is to improve the MANET type of adhoc
networks. This infrastructure-less network has routing protocols to route
the packets to the intended recipient in an organized manner. AODV
protocol chooses the best part to the destination based on the hop count
as metric, it has no power, stability and bandwidth optimization.

Considering the current need, the resources need to be utilized in

an efficient manner so that the requests are met in a timely manner. This
research proposes a stable, energy aware, bandwidth, optimized-metric
to load balance the traffic between available non-overlapping channels
in 802.11[1] standards. The proposed protocol i.e. modified AODV has
proved to have 50% better performance. It has avoided additional
overhead for the control packet and accounted for another important
broadcast storm problem by avoiding HELLO (used as keep alive)
packets used to discover neighboring nodes.

In this project, we have studied and compared traditional AODV

with the modified AODV to obtain better results regarding the link
breakage time to enhance the performance and QoS (Quality of Service)
provisioning to provide better services.

iv
 TABLE OF CONTENTS

CHAPTER PAGE NO.

CERTIFICATE i
DECLARATION ii
ACKNOWLEDGEMENT iii
ABSTRACT iv
LIST OF TABLES vii
LIST OF FIGURE vii
LIST OF ABBREVIATIONS viii

1. INTRODUCTION 1

1.1 Introduction to the project 1

1.2 Challenges faced in Ad hoc Network 3
1.3 Problem Identification 4
1.4 Proposed Solution 5
1.5 Organization of the Project Report 5

2. Background of Routing Protocol 6

2.1 Centralized approach or Infrastructure Network 7
2.2 Decentralized approach or Infrastructure-less Networks 7
2.3 Challenges faced by MANET 8
2.4 Ad hoc On Demand Distance Vector (AODV) 10
2.4.1 Algorithm of AODV 11
2.4.2 Technical Description 13
2.5 Distance Sequenced Destination Vector (DSDV) 15
2.6 Dynamic Source Routing Protocol 17
2.7 Modified Ad hoc On Demand Distance Vector 18
2.7.1 Algorithm of M-AODV 19
v
 2.8 Link Prediction Algorithm 20
2.8.1 Prediction of Link Breakage Time 20
2.8.2 Link Breakage Time Evaluation 21
2.8.3 Implementation of Prediction Algorithm 22
2.9 Simulator 22
2.9.1 Network Simulator 2 23
2.9.2 TCL: The Scenario Interface 25
2.9.3 Implementation of NS2 26

3. Methodology 27
4. Result 28
4.1 Parameters 28
4.2 Performance of AODV 29
4.3 Performance of Modified AODV 29
5. Analysis of Results 30
5.1 Graphical comparison of AODV & Modified AODV 30
5.1.1 Packet Delivery Ratio in AODV&Modified AODV 30
5.1.2 End to End Delay in AODV & Modified AODV 31
5.1.3 Generated Packets in AODV & Modified AODV 32
6. Conclusion & Future Works 34
6.1 Summary of Work done 34
6.2 Conclusion 34
6.3 Future Works 35
6. Appendix-1: Code Snippet 36
8. Appendix-2: User Interface Design 65
9. References 67

vi
 LIST OF TABLES

Table 4.1: Parametric Analysis of AODV 38

Table 4.2: Parametric Analysis of Modified AODV 38

LIST OF FIGURES

Figure 1.1: Overview of Ad hoc Network 11

Figure 2.1: Challenges faced at the different layers of MANET 18
Figure 2.2: Categorization of Mobile Adhoc Network 18
Figure 2.3: Route Discovery in AODV 20
Figure 2.4: AODV flow chart in NS2 22
Figure 2.5: NS2 Overview 33
Figure 2.6: TCL File format 34
Figure 2.7: NS2 Implementation 35
Figure 5.1: Packet Delivery Ratio vs. No. of mobile nodes 39
Figure 5.2: End-to-End Delay vs. No. of mobile nodes 40
Figure 5.3: Generated Packets vs. No. of mobile nodes 41
Figure 7.1: Running aodv.tcl file 74
Figure 7.2: Communication between nodes in AODV 74
Figure 7.3: Modified AODV Parameter 75

vii
 LIST OF ABBREVIATIONS

AODV : Ad hoc On Demand Distance Vector

DSDV : Destination Sequenced Distance Vector
MANET : Mobile Ad hoc Network
DSR : Dynamic Source Routing
TORA : Temporally Ordered Routing Algorithm
FORP : Flow Oriented Routing Protocol
CGSR : Cluster Gateway Switching Routing
WRP : Wireless Routing Protocol
IETF : Internet Engineering Task Force
OSI : Open Systems Interconnection
LMR : Label Based Multipath Routing
SSR : Scalable Source Routing
RREQ : Route Request
RREP : Route Reply
RRER : Route Error
TTL : Time To Live
NPDU : Network Protocol Data Unit
TCL : Tool Command Language
NS 2 : Network Simulator 2
PDR : Packet Delivery Ratio

viii
 CHAPTER-1

INTRODUCTION

1.1 Introduction to the project

The deployment of ad-hoc networks is increasing at a rapid pace and

accelerated by the availability due to the use of mobile devices like PDA’s, laptops,
smartphones, Bluetooth etc.

Acknowledging the benefits of ad-hoc networks, more and more research is

being conducted to increase the efficiency and reliability of such networks. Ad hoc
networks lack all the properties of wired networks such as reliability, fixed network
structure, etc. therefore the existing routing protocols for ad-hoc networks are
modified to meet the requirements of the consumers and give them the results
similar to that of wired networks. The research that is being conducted in this
domain continues to provide vital information and contributes to the development in
ad hoc internetworking. Ad hocs are decentralized in nature.

The different types of protocols in ad-hoc network include Mobile Adhoc

Network (MANET), Destination Sequence Distance Vector (DSDV), Dynamic
Source Routing (DSR), Adhoc on-demand Distance Vector (AODV), Temporally
Ordered Routing Algorithm (TORA), Flow Oriented Routing Protocol(FORP),
Cluster Gateway Switching Routing (CGSR) etc.

1
 Fig1.1 Overview of Ad-hoc Networks

Some of the following characteristics of ad-hoc network mandate the need

for more research in optimizing packet delivery in existing Adhoc networks to meet
future requirements.

 Mobility-The sheer nature of adhoc networks that allow mobility cause

dynamic, unpredicted and frequent topology changes, which would require
an efficient routing protocol.
 Power-Mobile devices are battery operated and the batteries are limited in
capacity. This calls for a routing protocol that would utilize the available
power in a more efficient manner.
 Link Stability-Link stability plays a major role in the mobility of adhoc
networks. As the adhoc networks are mobile, link stability is a major
concern.

2
  Load Balancing-Operating in a single channel might yield various
problems like delay and hidden node problems. Load balancing by making
use of all available channels would optimize channel utilization which would
help reduce delay and hidden terminal problem.

1.2 Challenges faced in Adhoc Network

The following parameters have always been challenging the performance of

ad hoc networks:
 Data Rate Enhancement-Throughput is always a key parameter to
determine the performance of any routing protocol. With the increased
use of wireless devices, there is a need to meet the growing demands of
users. Providing methods to enhance throughput has thus been a
challenge.
 Providing Reliability-.Since ashoc networks are formed on the go,
the link stability for reliable communication is always a challenge in
adhoc network.
 Power Demands-Adhoc devices are battery operated so long lasting
battery power of these devices has always been a challenge. Efficient
usage of remaining power available in the nodes is always a demanding
need for adhoc networks.
 Security-Due to existence of malicious nodes, the available resources
and the data transmitted in adhoc network is greatly exploited. Forming a
secure adhoc network is a fast growing area of research.

3
 1.3 Problem Identification

Ad hoc nodes operating in a single path, single channel model might

experience packet lost and high latency due to congestion caused in the network.
Nodes along the heavy traffic path may reach the maximum bandwidth limit and
experience undesirable amount of packet drop.

In ad hoc networks, nodes are mobile and contain no infrastructure.

Certain emergency messages have to be delivered with very low latency and
high reliability. An efficient routing protocol should ensure reliable packet
delivery in a timely manner.

Battery power plays an important role in determining the duration for

which ad hoc networks will be able to forward packets. An optimized routing
protocol should be able to consider the energy of a node while making routing
decisions. Unlike wired networks, adhoc networks are prone to frequent link
changes which might cause a huge packet loss.

All the above mentioned concerns call for an efficient protocol that
would make efficient routing decisions. Once the aforementioned parameters are
taken into account, reliable and efficient packet delivery to the end nodes is
ensured.

4
1.4 Proposed Solution

Considering the need for the messages to reach the intended recipient
within the stipulated time, the existing routing metric (AODV) is modified to
make use of all the available channels. Based on the composite metric (modified
AODV), the source node selects the best possible route through which it
forwards the packet. These metrics are considered important in ad hoc
environment.

1.5 Organization of the project report

This report begins with a brief introduction of basic MANET protocols

and NS2 in chapter 2. In chapter 3, the link breakage time detection formula is
described that uses the Newton Divided Difference table. Chapter 4 deals with
the implementation of the proposed formula and modification for link break
avoidance in AODV in NS2. Chapter 5 discusses the simulation analysis of
AODV with modified AODV. The report ends with conclusions and suggestions
for future research in chapter 6.

5
 CHAPTER-2

BACKGROUND OF ROUTING PROTOCOLS

A Mobile ad-hoc network (MANETs) is a self-organized, arbitrarily

developed network and can easily adopt in working environment. Basically,
MANET is the collection of wireless mobile nodes that can interact and
communicate with each other, without having the centralized and established
infrastructure. MANETs have converted the dream of getting connected “anywhere
and at any time” in to the reality. The growth of laptops and 802.11/Wi-Fi wireless
networking have made MANET a popular search topic since mid-1990s.
Many academic papers evaluate protocols and their abilities, assuming
varying degrees of mobility within a bounded space, usually with all nodes within a
few hops of each other. Different protocols are then evaluated based on measures
such as the packet drop rate, the overhead introduced by the routing protocol, end-
to-end packet delays, network throughput etc.
MANETs are useful in various application areas such as: communication in
the battlefields, institutions and colleges, military areas, disaster recovery areas, law
and order maintenance, traffic control areas, medical field, conferences and
convocations etc. In MANET, all the nodes are mobile nodes and their topology
changes rapidly. The Internet Engineering Task Force (IETF) created a MANET
working group to deal with the challenges faced during the construction of the
MANET routing protocols.
These protocols are basically classified in to three basic types such as:
reactive (on demand), proactive (table-driven) and hybrid. One of the basic goals
of the mobile ad-hoc network is to establish correct and efficient route between the
mobile nodes so that communication between the sender and receiver is effective.
In Proactive (table driven) routing protocols, each node maintain one or
more routing table which contain information about every other node in a network.

6
 Routing tables are updated by all the nodes in order to maintain a consistent
and up to date view of the network. In table driven routing protocol, continuous
broadcasting of messages is done in order to establish routes and maintain them. For
example: DSDV etc.
In Reactive (on demand) routing protocol, creation of routes is done when it
is required. When some packets are to be send from source to destination, it may
invoke the route discovery mechanism to find the path to the destination. The route
is valid, till the destination is reached or it is no longer be required in the future. For
example: AODV, DSR etc. In hybrid protocol routing, we combine the benefits of
both the reactive as well as proactive. Hybrid protocols are basically dependent on
the network size for their functionality.

2.1 Centralized approach Or Infrastructure Networks

Infrastructure network consists of a network with fixed and wired gateways.

A mobile host communicates with a bridge in the network (called base station)
within its communication radius. The mobile unit can move geographically while it
is communicating.
When it goes out of range of one base station, it connects with new base
station and starts communicating through it. This is called handoff. In this approach
the base stations are fixed.

2.2 Decentralized approach or Infrastructure less (ad-hoc)

Networks

In contrast to infrastructure based wireless network, in ad-hoc networks all

nodes are mobile and can be connected dynamically in an arbitrary manner. A
MANET is a collection of wireless mobile nodes forming a temporary network
without using any existing infrastructure or any administrative support.
7
The wireless ad-hoc networks are self-creating, self-organizing and self-
administrating. The nodes in an ad-hoc network can be a laptop, cell phone, PDA or
any other device capable of communicating with those nodes located within its
transmission range. The nodes can function as routers, which discover and maintain
routes to other nodes. The ad-hoc network may be used in emergency search-and-
rescue operations, battlefield operations and data acquisition in inhospitable terrain.
In ad hoc network, dynamic routing protocols must be needed to keep the record of
high degree of mobile node mobility, which often changes the network topology
dynamically and unpredictably.

2.3 Challenges faced by MANET

MANETs are very much different from the wireless network infrastructures.
MANETs has to face various challenges in order to achieve best Quality of Service
for the underlying network.
Some of these challenges are as follows:
1. Unicast and multicast routing.
2. Topology changes dynamically.
3. Speed and network overhead.
4. Limited power supply and bandwidth.
5. Quality of service and secure routing.
6. Scalable and energy efficient routing.

These challenges are faced at the different layers of MANETs shown in the
figure 1.2. It represents the layered architecture of the OSI model and entitled the
challenges of MANETs regarding these layers.

8
Application Layer 6 Security

Transport Layer Quality of service and secure routing

Network Layer Unicast and multicast routing

Data Link Layer Speed and network overhead

Physical Layer Power control

Fig 2.1 Challenges faced at the different layers of MANETs

AdHoc Routing Protocols

Table Driven Source-Initiated On-

Demand Driven

DSDV
WRP
AODV DSR LMR ABR
CGSR
TORA SSR

Fig 2.2 Categorization of Mobile Ad Hoc Network

9
2.4 Ad hoc On Demand Distance Vector (AODV)

Reactive protocols discover routes only as needed. When a node wishes to

communicate with another node, it checks with its existing information for a valid
route to the destination. If one exists, the node uses that route for communication
with the destination node. If not, the source node initiates a route request procedure,
to which either the destination node or one of the intermediate nodes sends a reply
back to the source node with a valid route . A soft state is maintained for each of
these routes, if the routes are not used for some period of time, the routes are
considered to be no longer needed and are removed from the routing table. Example
of this type algorithm is DSR and AODV.

AODV is a reactive protocol, even though it still uses characteristics of a

proactive protocol AODV takes the interesting parts of DSR and DSDV in the
sense that it uses the concept of route discovery and route maintenance of DSR and
the concept of sequence numbers and sending of periodic hello messages from
DSDV.

The main aim of AODV routing algorithm is to provide reliable and secure
data transmission over the MANETs. In this routing protocol route maintenance
from one node to every other node is not considered in the network. Whereas in
AODV, route are discovered only when they are needed as well as they are
maintained only as long as they are required.

10
 Figure 2.3 Route discovery in AODV

2.4.1 Algorithm of AODV

The key steps used in the AODV algorithm are defined below:

1. Route creation-

Route creation process is initiated when the node wants to send the data
packet to the destination node but does not find the valid route to send the packet.
This process is initiated as such: when a particular node want to send the data packet
to the destination node then, the routing table entries are checked in order to verify
whether there exists a route between the source and destination or not. If the route
exists, then the packet is forwarded to the next hop towards the destination.
When the route does not exists, and then the route discovery process is
initiated. AODV starts the route discovery process using the route request (RREQ)
and route reply (RREP).

11
 The source node will create the route request packet(RREQ) containing its
sequence number, its IP address , destination node sequence number, destination IP
address and broadcasting ID. Whenever the source node initiates the RREQ, the
broadcast ID is incremented each time. As the sequence number is used to identify
the timeliness of each data packet and broadcast ID and the IP address identify the
unique identifier for route request so that they can uniquely identify each of the
request. The data packet sends the request using the RREQ message and gets back
the reply in the form of RREP message if the route is discovered between the nodes.
The source node sends the RREQ packet to its neighbors as well as set the timer in
order to wait for the RREP message.

In order to describe RREQ, reverse route entry is set up by the node in its
routing table. This enables us to know how we can forward the route reply (RREP)
to the source. Moreover, a time period is associated with the reverse route entry and
if this route entry is not used within the given time period then only the route
information is deleted. If in any case RREQ is lost during the transfer of packet then
the source node again initiates route discovery mechanism.

2. Route maintenance-

Route that has been created by the source node and destination node is being
maintained as long as it is needed by the source node. Since nodes in the MANETs
are mobile and if the source node is in the mobile state during the active session, it
again restarts the route discovery mechanism in order to establish new routes from
source to destination. Otherwise, if some of the intermediate node or the destination
node is in the mobile state during the active session, then the nodes initiates the
RERR message that affects the above neighbors and the nodes.

12
 As a result of which these nodes forward the RERR message to the
predecessor nodes and can be continued until the source node is reached. When
RERR is received by the source node, then the node stop sending the data or it can
again start the route discovery mechanism by sending the RREQ message.

Fig 2.4 AODV flow chart in NS-2

2.4.2 Technical Description

 The AODV Routing Protocol uses an on-demand approach for finding routes,
that is, a route is established only when it is required by a source node for
transmitting data packets. It employs destination sequence numbers to identify
the most recent path. The major difference between AODV and Dynamic Source
Routing (DSR) stems out from the fact that DSR uses source routing in which a
data packet carries the complete path to be traversed.

13
 However, in AODV, the source node and the intermediate nodes store the next-
hop information corresponding to each flow for data packet transmission. In an
on-demand routing protocol, the source node floods the RouteRequest packet in
the network when a route is not available for the desired destination. It may
obtain multiple routes to different destinations from a single RouteRequest.

The major difference between AODV and other on-demand routing

protocols is that it uses a destination sequence number (DestSeqNum) to
determine an up-to-date path to the destination. A node updates its path
information only if the DestSeqNum of the current packet received is greater or
equal than the last DestSeqNum stored at the node with smaller hop count.

 A RouteRequest carries the source identifier (SrcID), the destination

identifier (DestID), the source sequence number (SrcSeqNum), the destination
sequence number (DestSeqNum), the broadcast identifier (BcastID), and the time
to live (TTL) field. DestSeqNum indicates the freshness of the route that is
accepted by the source. When an intermediate node receives a RouteRequest, it
either forwards it or prepares a RouteReply if it has a valid route to the
destination. The validity of a route at the intermediate node is determined by
comparing the sequence number at the intermediate node with the destination
sequence number in the RouteRequest packet. If a RouteRequest is received
multiple times, which is indicated by the BcastID-SrcID pair, the duplicate copies
are discarded. All intermediate nodes having valid routes to the destination, or the
destination node itself, are allowed to send RouteReply packets to the source.
Every intermediate node, while forwarding a RouteRequest, enters the previous
node address and its BcastID. A timer is used to delete this entry in case a
RouteReply is not received before the timer expires. This helps in storing an
active path at the intermediate node as AODV does not employ source routing of
data packets.

14
 When a node receives a RouteReply packet, information about the previous node
from which the packet was received is also stored in order to forward the data
packet to this next node as the next hop toward the destination.

Advantages-

• Loop free routing.

• Optional multicast.
• Reduced control overhead.

Disadvantages-
• Bi-directional connection needed in order to detect a unidirectional link.
• Delay caused by the route discovery process.

2.5 Destination-sequenced distance vector (DSDV)

DSDV is one of the most well-known table-driven routing algorithms for

MANETs. The DSDV routing algorithm is based on the classical Bellman-Ford
Routing Algorithm (BFRA) with certain improvement. Every mobile station
maintains a routing table with all available destinations along with information like
next hop, the number of hops to reach to the destination, sequence number of the
destination originated by the destination node, etc. DSDV uses both periodic and
triggered routing updates to maintain table consistency.
Triggered routing updates are used when network topology changes are
detected, so that routing information is propagated as quickly as possible. Routing
table updates can be of two types – full dump and incremental. Full dump packets
carry all available routing information and may require multiple Network Protocol
Data Units (NPDU); incremental packets carry only information changed since the
last full dump and should fit in one NPDU in order to decrease the amount of traffic
generated.

15
Mobile nodes cause broken links when they move from place to place. When a link
to the next hop is broken, any route through that next hop is immediately assigned
infinity metric and an updated sequence number. This is the only situation when any
mobile node other than the destination node assigns the sequence number. Sequence
numbers assigned by the origination nodes are even numbers, and sequence numbers
assigned to indicate infinity metrics are odd numbers. When a node receives infinity
metric, and it has an equal or later sequence number with a finite metric, it triggers a
route update broadcast, and the route with infinity metric will be quickly replaced by
the new route. When a mobile node receives a new route update packet; it compares
it to the information already available in the table and the table is updated based on
the following criteria:

 If the received sequence number is greater, then the information in the table
is replaced with the information in the update packet.
 Otherwise, the table is updated if the sequence numbers are the same and the
metric in the update packet is better.
DSDV introduces the large amount of overhead to the network due to the
requirement of periodic update messages. Hence, this protocol is not suitable for the
large network because large portion of the network bandwidth is used for the
updating of messages.

Advantages-
• Guarantees loop free path.
• Count to infinity problem is reduced in DSDV.
• With incremental updates, we can avoid extra traffic.
• DSDV maintains the best possible path instead of maintaining the multiple paths
to the destination this reduces the amount of space in the routing table.

16
Disadvantages-
• It does not support the multipath routing.
• Difficult to determine the delay for the advertisement of routes.
• Unnecessary advertising of routing information can result in the
wastage of bandwidth.

2.6 Dynamic Source Routing Protocol (DSR)

The DSR is a source routed on-demand routing protocol. A node maintains a

route cache containing source route that it is aware of.
The node updates entries in the route cache as and when it learns about new routes.
The two major phases of the protocol are: route discovery and route
maintenance. When the source node wants to send a packet to destination, it looks
up at its route cache to determine if it already contains a route to the destination. If it
finds an unexpired route to the destination then it uses this route to send the packet,
but if the node does not have such a route, then it initiates the route discovery
process by broadcasting a route request packet.
The route request packet contains the address of the source, the destination
and a unique identification number. Each intermediate node checks whether it
knows the route to the destination.
If it does not, it appends its address to the route record of the packet and forwards
the packet to its neighbors. To limit the number of route requests propagated, a node
processes a route request packet only if it has not already seen the packet and its
address is not present in the route record of the packet. A route reply is generated
when either the destination or an intermediate node with current information about
the destination receives the route request packet. A route request packet reaching
such a node already contains, in its route record the sequence of hops taken from the
source from this node.

17
 A route reply is generated by the destination, then it places the route record
from the route request packet into the route reply packet.
On the other hand, if the node generating the route reply is an intermediate node,
then it appends its cached route to the destination to the route record of the route
request packet and puts that into the route reply packet being sent by the destination
itself.
To send the route reply packet, the responding node must have a route to the
source. If it has a route to the source in its route cache, it can use that route.The
reverse of route record can be used if symmetric links are supported. In case
symmetric links are not supported, the node can initiate route discovery to the source
and piggyback the route reply on this new route request.
DSR uses two types of packets for route maintenance: Route Error packet
and acknowledgements.
When a node encounters a fatal transmission problem at its data link layer, it
generates a route error packet. When a node receives a node error packet, it removes
the hop in error from its route cache.
All routes that contain the hop in error are truncated at that point. Acknowledgement
packets are used to verify the correct operation of the route links. This also includes
passive acknowledgements in which a node hears the next hop forwarding the
packet along the route.

2.7 Modified Ad hoc On Demand Distance Vector

The proposed protocol has all the characteristics of the original AODV
routing protocol since it follows all the steps of the route discovery and route
maintenance mechanism of the original AODV routing protocol. The modified
AODV is different from the original AODV protocol, in that it modifies the original
AODV to reduce the length of the path of routing messages (RERR and RREQ)
when link breakage occurs. The modification of AODV reduces the protocol
overhead, packet losses and packet transmission time delays.

18
2.7.1 Algorithm of the Modified AODV

The proposed protocol (MAODV) follows these steps to rediscover and

modify the broken path:
1. Any node which senses that the link with the next hop on the active route is
broken, initiates and sends the RERR message to the source node, in the
same way as in the original AODV.

2. Any intermediate node which receives the RERR message, then checks its
state flag; if the node is mobile, it then forwards the RERR message to the
next hop towards the source.

3. If the intermediate node is stationary, then it checks if it is a part of an old

route (broken path). If it is not, it forwards the RERR and goes to step 2.

4. In the case that the intermediate node is a part of the old route (and has an
entry for a path to the unreachable destination in its routing table), it must
perform the steps below:
 Discard the RERR message.
 Stop sending the data to the next node.
 Save the received packets from the source node.
 Increment the destination’s sequence number.
 Initiate an RREQ message and broadcast it to all neighbors.
 Wait to receive the RREP from the destination.

5. When the initiator of the RREQ has received the RREP from the destination
or from any node which has a route to the destination, it must perform the
steps below:

19
  Modify the routing table’s entry for the path to the destination according to
the new route.
 Start sending the saved data.

6. MAODV continues to work the same as the original AODV from this step
onwards.
All the rules of the original AODV apply to the MAODV since the MAODV just
decreases the path of the RERR.

2.8 Link Prediction Algorithm

In Mobile Ad Hoc Network, every mobile node is liable to move randomly
that causes frequent route breakage. During route rediscovery and switching to that
route, a large number of packets dropped. Link Prediction algorithm determines link
breakage time using Newton Divided Difference table and bisection method so that
source node can find any alternative route before the link actually breaks.

2.8.1 Prediction of Link Breakage Time

Link prediction algorithm uses Newton Divided Difference method and

bisection method to calculate link breakage time (tbr). Newton divided difference
method is used to calculate signal strength p(t) at time t from the data available in
signal info array.

If calculated power is greater than threshold power then link will be available
till that time otherwise, link may break before time t. Bisection method is used to
calculate the link breakage time (assuming free space propagation model).

20
2.8.2 Link Breakage Time Evaluation

The link breakage time is calculated by following algorithm:-

1. Check how many packets are in signal info array to predict link breakage time

a. If number of packets=2 then we are unable to predict link breakage time.

b. If number of packets=3 then signal power is calculated by-

p(t)=p[2]+(t-t[2])*(A+B)
set tprev=t[2] and tnext=t[2]+1

c. If number of packets=4 then signal power is calculated by

p(t)=p[3]+((t-t[3])*[(A-B)/(t[3]-t[0])*(t-t[1])*(t-t[2])+A*(t-t[2])]
set tprev=t[3] and tnext=t[3]+1

2. If p(tprev)>pthreshold and p(tnext)<pthreshold then the link breakage time will lie
between tprev and tnext and we have apply bisection method consecutively to
find accurate time.

a. tbr=(tprev+tnext)/2;
b. if p(tprev)>pthreshold and p(tbr)<pthreshold then set
tnext=tbr
c. otherwise set tprev=tbr
d. If tbr-(tprev+tnext)/2 <= correctness then the link breakage
time will be
tbr=(tprev+tnext)/2 otherwise, set tbr=(tprev+tnext)/2 and goto
step b.

21
3. Otherwise set tprev=tnext and tnext=tnext+1. If tnext=t[3]<=limit then goto step2
otherwise allot tbr a high value because the link will not break before time
(t[3]+limit).

2.8.3 Implementation of Prediction Algorithm

We consider atleast three data packet that are stored in the signal info array
to predict link breakage time (tbr). Every mobile node maintain signal info array that
holds received power and reception time from its neighbouring mobile node.The
powers and time are updated in following order-
P[3]<p[2]<p[1]<p[0] and t[3]>t[2]>t[1]>t[0]
If only three packets are in signal info then the link breakage time is
calculated using these only three packets. If mobile node are moving closer then the
received power will be greater and in this case no link prediction is necessary.

2.9 Simulator

Simulation is an important tool in the development of mobile ad hoc

networks, it provides an excellent environment and verify routing protocol
correctness. However, simulation does not guarantee that the protocol works in
practice, because simulators contain assumptions and simplified models that may
not actually reflect real network operation. After a protocol is thoroughly tested in
simulation, an implementation is the logical next step. A working implementation is
necessary to validate that the routing protocol specification perform under real
conditions. Otherwise, assumptions made by protocol design cannot be verified as
correct. Additionally, an implementation can be used to perform tested and field
tests.

22
 Creating a working implementation of an ad hoc routing protocol is non-
trivial and more difficult than developing a simulation. In simulation, the developer
controls the whole system, which is in effect only a single component, an
implementation, on the other hand, needs to interoperate with a large, complex
system. Some components of this system are the operating system, sockets, and
network interfaces.
Additional implementation problems surface because current operating
systems are not built to support ad hoc routing protocols. A number of required
events are unsupported; support for these events must be added. Because these
events encompass many systems components, the components and their interactions
must also be explored. For these reasons it takes significantly more effort to create
an ad hoc routing protocol implementation than a simulation.

2.9.1 Network Simulator 2

NS 2 was developed in the California University, by LBL, Xerox PARC,

UCB, and USC/ISI through the VINT project supported by DARPA. Earlier this
simulator was built for fixed network: all links among nodes were wired. That
means that the neighbor had no direct neighbor: if two nodes were very close, they
don’t communicate each other if they don’t have a cable between each other. So,
later an extension for wireless network was developed by UCB Daedelus, CMU
Monarch projects and Sun Microsystems. Nowadays, this simulator is used around
the world, because of the GPL license.

It is a discrete event simulator targeted at networking research. It provides

substantial support for simulation of TCP, routing and multicast protocols over
wired and wireless networks. It consists of two simulation tools. The network
simulator (ns) contains all commonly used IP protocols. The network animator
(nam) is use to visualize the simulations.

23
 NS-2 fully simulates a layered network from the physical radio transmission
channel to high-level applications. The simulator supports a class hierarchy in C++
and a similar class hierarchy within the OTcl interpreter. There is a one-to-one
correspondence between a class in the interpreted hierarchy and one in the compile
hierarchy. The reason to use two different programming languages is that OTcl is
suitable for the programs and configurations that demand frequent and fast change
while C++ is suitable for the programs that have high demand in speed. NS2 is
highly extensible. It not only supports most commonly used IP protocols but also
allows the users to extend or implement their own protocols. The simulator is
composed of two parts:
 The TCL code: It is used to communicate with the simulator, and permits to
define different simulation parameters.
 The C++ code: It is the main part of the project, because it defines how the
simulator has to behave.

Fig 2.5 NS-2 Overview

24
2.9.2 TCL: The Scenario Interface

The main reason for using a TCL language in ns2 is because it is not useful
to use only C++ code. In fact, by this mean, the user does not need to compile the
simulator every time he wants to do a new simulation. The TCL language is
interpreted by the C++ code in ns2, without being compiled. To use a network
simulator, you have to define two things:
 How does the protocol behave? It is done by the C++ code, because it does
not change for every simulation.
 What are the simulation parameters? It is done by the TCL code, because
every simulation is different (number of nodes, positions, speeds, protocol
used).

The TCL code allows the user to choose between fix or wireless network,
and among the different implemented protocols: TORA, AODV, DSR (for wireless
networks). It also contains information about nodes like position and speed, or
information about source and destination, the transmission rate, and a lot of other
parameters. Some tools have been developed to build these scenarios.

Fig 2.6 TCL File Format

25
2.9.3 Implementation in NS2 :

All simulations have been carried out using the NS simulator program
version 2.34 under Linux platform. NS2 is an open source simulator software and
used by a lot of institutes and researchers.
The main goal of the NS2 simulator is to provide support to education and research
in networking. It is one of the best programs in terms of comparing different routing
protocols and designing new ones.
NS2 has been written in two languages: Object oriented variant of Tool
Command Language (OTCL) and object oriented language C++. Here we are using
the OTCL implementation.

Figure 2.7 NS-2 Implementation

26
 CHAPTER-3

METHODOLOGY

The methodology of this work entitled has always been a tedious task as it
requires a lot of analysis work and drawing inferences from the same.

The following shows up the detailed algorithm and methodology of the work
that has been done by us in the due course of this work:

1. Install NS2 2.35 package on any Linux platform (Here we have used Ubuntu
14.04).

2. Design the .tcl files with specifications like number of nodes, node types, the
link specification between the nodes, and design with proper variations.
(refer to the Code Snippet Section of this work).

3. Use it with the ns nam animator to present and gain inferences on the
terminal window. Ex: ns filename.tcl

4. Implement the protocols AODV and DSDV using the packages available
within NS2, run it with the animator of NS and generate the trace file. Ex:
set tracefd [open filename.tr w]

5. Use the awk tool utility to generate the exact statistics of the protocol run
depending upon the various parameters specified.

6. Analyse the various observations and the do the analysis required and give
results.

27
 CHAPTER-4

RESULTS

4.1 Parameters

The performance parameters for the comparison of the two protocols

(AODV & M-AODV) are:

 Packet Delivery Ratio (PDR): It is the ratio of total data bits received
to total data bits sent from source to destination.

 Generated Packets: It is the total number of data bits send from source
to destination.

 Received Packets: It is the total number of data bits received by

destination from source.

 Dropped Packets: It is the total number of data bits dropped in the path.

 Average End-To-End Delay: It refers to the average time taken for a

packet to be transmitted across a network from source to destination.

28
 4.2 Performance of AODV

In this section various results of different parameters have been presented in

a table containing all above listed parameters. These results are calculated by
applying the AODV protocol on different networks like by varying the number of
nodes.

No. of Generated Received Packet Total Average

Mobile Packets Packets Delivery Dropped end- to- end
Nodes Ratio Packets delay(ms)
3 4929 4900 99.4116 6 121.763
5 9879 9852 99.7267 12 18.327
10 19409 19333 99.6089 37 15.6356
30 4591 4387 95.5565 117 102.787

Table 4.1:-Performance of AODV

4.3 Performance of Modified AODV

In this section various results of different parameters have been presented in a

table containing all the parameters. These results are calculated by applying the
Modified AODV protocol on different networks like by varying the number of nodes.

No. of Generated Received Packet Total Average

Mobile Packets Packets Delivery Dropped end- to- end
Nodes Ratio Packets delay(ms)
3 9087 9062 99.7249 1 120.884
5 11558 11531 99.7664 11 17.4887
10 19416 19358 99.7013 30 15.6997
30 7517 7302 97.1398 71 46.4145

Table 4.2:-Performance of Modified AODV

29
 CHAPTER-5

ANALYSIS OF RESULTS

5.1 Graphical Comparison of AODV & Modified AODV

In this section we compare the parametric results of AODV & Modified

AODV through graphs to clearly observe the difference between the performances
of these two protocols. We have used different number of nodes and their
corresponding values of AODV and Modified AODV to find out the conclusion of
the research.

5.1.1 Packet Delivery Ratio in AODV & Modified AODV

Packet Delivery Ratio is basically ratio of received packets and sent packets
in any network.
This graph shows the packet delivery ratios of AODV & DSDV by taking
packet delivery ratio on y-axis and number of mobile nodes on x-axis.

Figure 5.1 Packet Delivery Ratio Vs No Of Mobile Nodes

30
 This graph shows us that on varying the no. of nodes in the network, the
packet delivery ratio of AODV is quite the same but in DSDV it is decreasing with
the increase of no. of mobile node.
Initially when the no of mobile nodes were only 5, they both have almost the
same ratio but gradually the ratio for the DSDV decreases but for AODV there is no
such effect on that. So we can say that the Packet delivery ratio for DSDV depends
on the no of mobile nodes in the network but AODV’s ratio is independent of that.

5.1.2 End-to-End Delay in AODV & Modified AODV

End-to-end delay is the time gap (in ms) taken by the protocol to successfully send
any packet from one node to another. This graph shows the end-to-end delay in
AODV & Modified AODV by taking end-to-end delay on y-axis and number of
mobile nodes on x-axis.

Figure 5.2 End-To-End Delay Vs No. Of Mobile Nodes

This graph shows us that on varying the no. of nodes in the network, the end-
to-end delay of AODV is always higher than that of Modified AODV.
Initially when the no of mobile nodes were only 3, the delay in AODV is less
as we compare it with Modified AODV and that ratio remains the almost same for
increase in nodes as well.

31
5.1.4 Generated Packets in AODV & Modified AODV

Generated packets are mainly the number of packets generated by networks

on applying the protocols AODV & Modified AODV.
This graph shows the generated packets in AODV & Modified AODV by
taking generated packets on y-axis and number of mobile nodes on x-axis.

Figure 5.3 Generated Packets Vs. No. Of Mobile Nodes

This graph shows us that on varying the no. of nodes in the network, the
packets generated in Modified AODV are higher than in AODV. Also we have
observed that the packets generated in AODV are nearly constant while in other it is
not so.

32
 CHAPTER-6

CONCLUSION AND FUTURE WORKS

6.1 Summary Of Work Done

The summary of the overall work done can be characterized as:

1. Study and analysis of the protocol i.e. AODV and Modified AODV.

2. Study and analysis of the simulator used.

3. Determination of the performance metrics.

4. Implementation of the protocols AODV and Modified AODV on the ns2

simulator.

5. Determining the values of the metrics observed through the implementation

results observed.

6. Comparisons and Plotting.

7. Deriving conclusions based on the graphs thus observed.

6.2 Conclusion:

In the project presented, we tried to implement a reactive (AODV &

Modified AODV) on ns2 simulator and thus gasped results accordingly.

33
The conclusions can be stated as:

 If we are Using the Modified AODV and AODV routing Protocol with 30 nodes,
pause time 10 s, varying node speed (20-100 m/s by interval of 20 m/s) then
overall result say that packet delivery fraction and normalized routing load in
1000 m. x 1000 m. of AODV is more optimal than 1000 m. x 1000 m. of
Modified AODV.

 The Packet Delivery Fraction is always low in AODV on varying node speed.
The Average Throughput is greater in AODV on varying node speed.

 The Average end-to-end delay is always low in modified AODV on varying

node speed. So, according to the results the performance of Modified AODV
routing protocol is much better than AODV routing protocol in wireless sensor
network. For some specific applications, the implementation of a new routing
protocol is needed.

 There were some anomalies observed due to the increased loss of packets when
the number of nodes increases from 35 to 40. In this, the throughput was
decreased considerably and that results due to the overhead generated at each
node regarding the updation of the table.

34
6.3 Future Works

In our study, we have tried to carry out all the variations we could do in
order to cover every aspect of the analysis. But as there is always a scope for
betterment, the project offers the following future works to be done.

 The number of parameters could be extended.

 The number of nodes and velocity might be changed and varied to improve
the charges.

 The anomalies that were observed could have been be dealt with more
intense work and study so as to reduce them to a considerable extent.

 More proper charts and figures shall be used for implementation.

35
 APPENDIX-1

CODE SNIPPET

1. AODV Implementation:

1.1 AODV with 3 nodes :

# Define options
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 3 ;# number of mobilenodes
set val(rp) AODV ;# routing protocol
set val(x) 500 ;# X dimension of topography
set val(y) 400 ;# Y dimension of topography
set val(stop) 150 ;# time of simulation end
set ns [new Simulator]
set namtrace [open simwrls.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \

36
-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 \
for {set i 0} {$i < $val(nn) } { incr i } {
set node_($i) [$ns node] }
# Provide initial location of mobilenodes
$node_(0) set X_ 5.0
$node_(0) set Y_ 5.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 490.0
$node_(1) set Y_ 285.0
$node_(1) set Z_ 0.0
$node_(2) set X_ 150.0
$node_(2) set Y_ 240.0
$node_(2) set Z_ 0.0
# Generation of movements
$ns at 1.0 "$node_(0) setdest 250.0 250.0 3.0"
$ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0"
$ns at 10.0 "$node_(0) setdest 480.0 300.0 5.0"
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp

37
 $ns attach-agent $node_(1) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 10.0 "$ftp start"
proc plotWindow {tcpSource file} {
global ns
set time 0.01
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file" }
$ns at 10.1 "plotWindow $tcp $windowVsTime2"
for {set i 0} {$i < $val(nn)} { incr i } {
$ns initial_node_pos $node_($i) 30}
for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";}
# ending nam and the simulation
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "stop"
proc stop {} {
global ns tracefd namtrace
}
$ns run

1.2 AODV with 30 nodes:

# Define options
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model

38
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 30 ;# number of mobilenodes
set val(rp) AODV ;# routing protocol
set val(x) 500 ;# X dimension of topography
set val(y) 400 ;# Y dimension of topography
set val(stop) 150 ;# time of simulation end
set ns [new Simulator]
set tracefd [open simple5.tr w]
set windowVsTime2 [open win5.tr w]
set namtrace [open simwrls5.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
# set up topography object
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) \

39
 -macTrace OFF \
-movementTrace ON
for {set i 0} {$i < $val(nn) } { incr i } {
set node_($i) [$ns node]
}
$node_(0) set X_ 5.0
$node_(0) set Y_ 5.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 490.0
$node_(1) set Y_ 285.0
$node_(1) set Z_ 0.0
$node_(2) set X_ 150.0
$node_(2) set Y_ 240.0
$node_(2) set Z_ 0.0
$node_(3) set X_ 250.0
$node_(3) set Y_ 240.0
$node_(3) set Z_ 0.0
$node_(4) set X_ 100.0
$node_(4) set Y_ 70.0
$node_(4) set Z_ 0.0

# Generation of movements
$ns at 10.0 "$node_(0) setdest 250.0 250.0 10.0"
$ns at 15.0 "$node_(1) setdest 45.0 285.0 10.0"
$ns at 110.0 "$node_(0) setdest 480.0 300.0 10.0"
$ns at 70.0 "$node_(3) setdest 180.0 30.0 10.0"
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2

40
 set sink [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp
$ns attach-agent $node_(1) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 10.0 "$ftp start"
proc plotWindow {tcpSource file} {
global ns
set time 0.01
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file" }
$ns at 10.1 "plotWindow $tcp $windowVsTime2"
# Define node initial position in nam
for {set i 0} {$i < $val(nn)} { incr i } {
# 30 defines the node size for nam
$ns initial_node_pos $node_($i) 30
}
# Telling nodes when the simulation ends
for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";
}
# ending nam and the simulation
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "stop"
$ns at 150.01 "puts \"end simulation\" ; $ns halt"
proc stop {} {

41
 global ns tracefd namtrace
$ns flush-trace
close $tracefd
close $namtrace
#Execute nam on the trace file
exec nam simwrls4.nam &
exit 0
}
$ns run

2. Modified AODV Implementation:

aodv.cc
#ifdef DEBUG
static int route_request = 0;
#endif
int hdr_aodv::offset_;
static class AODVHeaderClass : public PacketHeaderClass {
public:
AODVHeaderClass() : PacketHeaderClass("PacketHeader/AODV",
sizeof(hdr_all_aodv)) {
bind_offset(&hdr_aodv::offset_);
}
} class_rtProtoAODV_hdr;
static class AODVclass : public TclClass {
public:
AODVclass() : TclClass("Agent/AODV") {}
TclObject* create(int argc, const char*const* argv) {
assert(argc == 5);

42
 //return (new AODV((nsaddr_t) atoi(argv[4])));
return (new AODV((nsaddr_t) Address::instance().str2addr(argv[4])));
}
} class_rtProtoAODV;
int
AODV::command(int argc, const char*const* argv) {
if(argc == 2) {
Tcl& tcl = Tcl::instance();
if(strncasecmp(argv[1], "id", 2) == 0) {
tcl.resultf("%d", index);
return TCL_OK;
}
if(strncasecmp(argv[1], "start", 2) == 0) {
btimer.handle((Event*) 0);
#ifndef AODV_LINK_LAYER_DETECTION
htimer.handle((Event*) 0);
ntimer.handle((Event*) 0);
#endif // LINK LAYER DETECTION
rtimer.handle((Event*) 0);
return TCL_OK;
} }
else if(argc == 3) {
if(strcmp(argv[1], "index") == 0) {
index = atoi(argv[2]);
return TCL_OK; }
else if(strcmp(argv[1], "log-target") == 0 || strcmp(argv[1], "tracetarget") == 0) {
logtarget = (Trace*) TclObject::lookup(argv[2]);
if(logtarget == 0)

43
 return TCL_ERROR;
return TCL_OK; }
else if(strcmp(argv[1], "drop-target") == 0) {
int stat = rqueue.command(argc,argv);
if (stat != TCL_OK) return stat;
return Agent::command(argc, argv); }
else if(strcmp(argv[1], "if-queue") == 0) {
ifqueue = (PriQueue*) TclObject::lookup(argv[2]);
if (dmux_ == 0) {
fprintf (stderr, "%s: %s lookup of %s failed\n", __FILE__,
argv[1], argv[2]);
return TCL_ERROR; }
return TCL_OK; } }
return Agent::command(argc, argv);
}
AODV::AODV(nsaddr_t id) : Agent(PT_AODV),
btimer(this), htimer(this), ntimer(this),
rtimer(this), lrtimer(this), rqueue() {
index = id;
seqno = 2;
bid = 1;
LIST_INIT(&nbhead);
LIST_INIT(&bihead);
//rt->rt_seqno++;
agent->rt_down(rt);
#ifdef DEBUG
fprintf(stderr,"Dst - %d, failed local repair\n", rt->rt_dst);
#endif

44
}
Packet::free((Packet *)p);
}
void AODV::id_insert(nsaddr_t id, u_int32_t bid) {
BroadcastID *b = new BroadcastID(id, bid);
assert(b);
b->expire = CURRENT_TIME + BCAST_ID_SAVE;
LIST_INSERT_HEAD(&bihead, b, link);
}
bool AODV::id_lookup(nsaddr_t id, u_int32_t bid) {
BroadcastID *b = bihead.lh_first;
for( ; b; b = b->link.le_next) {
if ((b->src == id) && (b->id == bid))
return true; }
return false; }
void AODV::id_purge() {
BroadcastID *b = bihead.lh_first;
BroadcastID *bn;
double now = CURRENT_TIME;
for(; b; b = bn) {
bn = b->link.le_next;
if(b->expire <= now) {
LIST_REMOVE(b,link);
delete b;
void AODV::sendP_Error(Packet *p)
{
struct hdr_cmn *ch = HDR_CMN(p);
struct hdr_ip *ih = HDR_IP(p);
struct hdr_aodv_p_error *re = HDR_AODV_P_ERROR(p);

45
re->re_type=AODVTYPE_P_RERR;
ch->ptype() = PT_AODV;
ch->size() = IP_HDR_LEN + re->size();
ch->iface() = -2;
ch->error() = 0;
ch->addr_type() = NS_AF_NONE;
ch->next_hop_ = 0;
ch->prev_hop_ = index; // AODV hack
ch->direction() = hdr_cmn::DOWN; //important: change the packet's direction
ih->saddr() = index;
ih->daddr() = IP_BROADCAST;
ih->sport() = RT_PORT;
ih->dport() = RT_PORT;
ih->ttl_ = 1;
// Do we need any jitter? Yes
//printf("Sceduling at sendperror at %d",index);
Scheduler::instance().schedule(target_, p, 0.0);
}
void AODV::recvP_Error(Packet *p)
{
struct hdr_ip *ih = HDR_IP(p);
struct hdr_aodv_p_error *re=HDR_AODV_P_ERROR(p);
aodv_rt_entry *rt;
u_int8_t i;
Packet *prerr= Packet::alloc();
struct hdr_aodv_p_error *nre=HDR_AODV_P_ERROR(prerr);
nre->DestCount=0;
for(i=0; i<re->DestCount; i++){

46
 rt=rtable.rt_lookup(re->linkbreakable_dst[i]);
if(rt &&(rt->rt_hops!=INFINITY2)&&
(rt->rt_nexthop==ih->saddr()))
{
assert(rt->rt_flags==RTF_UP);
rt->rt_flags=P_RTF_UP;
rt->rt_expire=CURRENT_TIME+re->predTime-PerHopTime(rt);
if(!rt->pc_empty()) {
AODV_Precursor *pc=rt->rt_pclist.lh_first;
nre->linkbreakable_dst[nre->DestCount]=re->linkbreakable_dst[i];
nre->DestCount++; }
if(rt->rt_src==index) {
sendAREQ(re->linkbreakable_dst[i]); }}}
nre->predTime=re->predTime-PerHopTime(rt);
Packet::free(p);
if(nre->DestCount>0)
{
sendP_Error(prerr);
}
else
{
Packet::free(prerr);
}}
void AODV::sendAREQ(nsaddr_t id)
{
aodv_rt_entry *rt;
rt=rtable.rt_lookup(id,true);
if(rt==0)
{

47
rt=rtable.rt_add(id,true);
}
rt->rt_src=index;
sendRequest(rt->rt_dst,true);
}

node.cc
#include "parentnode.h"
#define NO_OF_PACKET_FOR_PREDICTION 4
#define PREDICTION_TIME_INFINITY 2000.0
#define HANDOFF_THRESHOLD 4.0e-09
#define SETUP_TIME 1.0
#define TIME 2.000000
#define RThres_3.067e-09
#define CORRECTNESS 0.001
#define VALUE 100
#define DECREMENT 1.0

class SignalPower;
class SignalPower
public:
int No_of_Packets;
int nodeID;
double predictTime;

double receivingTime[NO_OF_PACKET_FOR_PREDICTION];
double receivingPower[NO_OF_PACKET_FOR_PREDICTION];

public:

48
LIST_ENTRY(SignalPower) SignalPower_entry;
//member functions
inline int getNodeid() {return nodeID;}
inline double getPredict() {return predictTime;}
//initial instance variables
SignalPower(int nID) {
nodeID=nID;
No_of_Packets=0;
predictTime=PREDICTION_TIME_INFINITY;
for(int i=0;i<NO_OF_PACKET_FOR_PREDICTION;i++) {
receivingTime[i]=0.0;
receivingPower[i]=-1.0;
}//printf("no of packets=%d id=d......\n",No_of_Packets,nodeID);
}
double getLastpktPower(void)
{
if(No_of_Packets>0)
return receivingPower[No_of_Packets-1];
}
//add the time and power parameters
void addParameter(double aPower,double aTime);
double predTime(void);
double getPower_pkt4(double);
double getPower_pkt3(double);
};
class Node : public ParentNode {
//added for receiving power and time list public:
SignalPower* getSignalPowerObject(int NodeId1);
double predtm(int NodeId1);
};

49
ll.cc

#ifndef lint
static const char rcsid[] =
#endif
#include <errmodel.h>
#include <mac.h>
#include <ll.h>
#include <address.h>
#include <dsr/hdr_sr.h>
int hdr_ll::offset_;
static class LLHeaderClass : public PacketHeaderClass {
public:
LLHeaderClass() : PacketHeaderClass("PacketHeader/LL",
sizeof(hdr_ll)) {
bind_offset(&hdr_ll::offset_); }
}
class_hdr_ll;
static class LLClass : public TclClass {
public:
LLClass() : TclClass("LL") {}
TclObject* create(int, const char*const*) {
return (new LL);
}
} class_ll;
LL::LL() : LinkDelay(), seqno_(0), ackno_(0), macDA_(0), ifq_(0),
mac_(0), lanrouter_(0), arptable_(0), varp_(0),
downtarget_(0), uptarget_(0) {
bind("macDA_", &macDA_); }

50
int LL::command(int argc, const char*const* argv)
{
Tcl& tcl = Tcl::instance();
if (argc == 3) {
if (strcmp(argv[1], "ifq") == 0) {
ifq_ = (Queue*) TclObject::lookup(argv[2]);

return (TCL_OK);
}
if(strcmp(argv[1], "arptable") == 0) {
arptable_ = (ARPTable*)TclObject::lookup(argv[2]);
assert(arptable_);
return TCL_OK; }
if(strcmp(argv[1], "varp") == 0) {
varp_ = (VARPTable*)TclObject::lookup(argv[2]);
assert(varp_);
return TCL_OK;
}
if (strcmp(argv[1], "mac") == 0) {
mac_ = (Mac*) TclObject::lookup(argv[2]);
assert(mac_);
return (TCL_OK); }
if (strcmp(argv[1], "down-target") == 0) {
downtarget_ = (NsObject*) TclObject::lookup(argv[2]);
return (TCL_OK); }
if (strcmp(argv[1], "up-target") == 0) {
uptarget_ = (NsObject*) TclObject::lookup(argv[2]);
return (TCL_OK);
}

51
 if (strcmp(argv[1], "lanrouter") == 0) {
lanrouter_ = (LanRouter*) TclObject::lookup(argv[2]);
return (TCL_OK);
}
}
else if (argc == 2) {
if (strcmp(argv[1], "ifq") == 0) {
tcl.resultf("%s", ifq_->name());
return (TCL_OK); }
if (strcmp(argv[1], "mac") == 0) {
tcl.resultf("%s", mac_->name());
return (TCL_OK); }
if (strcmp(argv[1], "down-target") == 0) {
tcl.resultf("%s", downtarget_->name());
return (TCL_OK); }
if (strcmp(argv[1], "up-target") == 0) {
tcl.resultf("%s", uptarget_->name());
return (TCL_OK); } }
return LinkDelay::command(argc, argv); }
void LL::recv(Packet* p, Handler* /*h*/)
{
hdr_cmn *ch = HDR_CMN(p);
assert(initialized());
}
if(ch->direction() == hdr_cmn::UP) {
//if(mac_->hdr_type(mh) == ETHERTYPE_ARP)
if(ch->ptype_ == PT_ARP)
arptable_->arpinput(p, this);

52
 else
uptarget_ ? sendUp(p) : drop(p);
return; }
ch->direction() = hdr_cmn::DOWN;
sendDown(p);
}
void LL::sendDown(Packet* p)
{ hdr_cmn *ch = HDR_CMN(p);
hdr_ip *ih = HDR_IP(p);
nsaddr_t dst = (nsaddr_t)Address::instance().get_nodeaddr(ih->daddr());
//nsaddr_t dst = ih->dst();
hdr_ll *llh = HDR_LL(p);
char *mh = (char*)p->access(hdr_mac::offset_);
if (tx == 0) {
Scheduler& s = Scheduler::instance();
// let mac decide when to take a new packet from the queue.
s.schedule(downtarget_, p, delay_);
}
}
void LL::sendUp(Packet* p)
{
Scheduler& s = Scheduler::instance();
if (hdr_cmn::access(p)->error() > 0)
drop(p);
else
s.schedule(uptarget_, p, delay_);
}

53
node.cc

static class WFRPHeaderClass : public PacketHeaderClass {

public:
WFRPHeaderClass() : PacketHeaderClass("PacketHeader/WFRP",
sizeof(hdr_all_wfrp)) {
bind_offset(&hdr_wfrp::offset_);
}
} class_rtProtoWFRP_hdr;
static class WFRPclass : public TclClass {
public:
WFRPclass() : TclClass("Agent/WFRP") {}
TclObject* create(int argc, const char*const* argv) {
assert(argc == 5);
return (new WFRP((nsaddr_t)
Address::instance().str2addr(argv[4])));
}
} class_rtProtoWFRP;
int WFRP::command(int argc, const char*const* argv) {
if(argc == 2) {
Tcl& tcl = Tcl::instance();
if(strncasecmp(argv[1], "id", 2) == 0) {
tcl.resultf("%d", index);
return TCL_OK; }
if(strncasecmp(argv[1], "start", 5) == 0) {
rtcTimer.handle((Event*) 0);
return TCL_OK;
}
if(strncasecmp(argv[1], "sink", 4) == 0) {
bcnTimer.handle((Event*) 0);

54
#ifdef DEBUG
printf("N (%.6f): sink node is set to %d, start beaconing \n",
CURRENT_TIME, index);
#endif
return TCL_OK; } }
else if(argc == 3) {
if(strcmp(argv[1], "index") == 0) {
index = atoi(argv[2]);
return TCL_OK; }
else if(strcmp(argv[1], "log-target") == 0 || strcmp(argv[1],
"tracetarget") == 0) {
logtarget = (Trace*) TclObject::lookup(argv[2]);
if(logtarget == 0)
return TCL_ERROR;
return TCL_OK; }
else if(strcmp(argv[1], "drop-target") == 0) {
/* int stat = rqueue.command(argc,argv);
if (stat != TCL_OK)
return stat;
return Agent::command(argc, argv);*/
return TCL_OK; }
else if(strcmp(argv[1], "if-queue") == 0) {
ifqueue = (PriQueue*) TclObject::lookup(argv[2]);
if(ifqueue == 0)
return TCL_ERROR;
return TCL_OK;
}
else if (strcmp(argv[1], "port-dmux") == 0) {

55
dmux_ = (PortClassifier *)TclObject::lookup(argv[2]);
if (dmux_ == 0) {
fprintf (stderr, "%s: %s lookup of %s failed\n",
__FILE__,
argv[1], argv[2]);
return TCL_ERROR; }
return TCL_OK; } }
return Agent::command(argc, argv);}
#ifdef DEBUG
printf("N (%.6f): Routing agent is initialized for node %d \n",
CURRENT_TIME, id);
#endif
index = id;
seqno = 1;
LIST_INIT(&rthead);
posx = 0;
posy = 0;
logtarget = 0;
ifqueue = 0; }
void wfrpRouteCacheTimer::handle(Event*) {
agent->rt_purge();
Scheduler::instance().schedule(this, &intr,
ROUTE_PURGE_FREQUENCY); }
void wfrpBeaconTimer::handle(Event*) {
agent->send_beacon();
Scheduler::instance().schedule(this, &intr,
DEFAULT_BEACON_INTERVAL);
}

56
Void WFRP::send_beacon() {
Packet *p = Packet::alloc();
struct hdr_cmn *ch = HDR_CMN(p);
struct hdr_ip *ih = HDR_IP(p);
struct hdr_wfrp_beacon *bcn = HDR_WFRP_BEACON(p);
ch->ptype() = PT_WFRP;
ch->size() = IP_HDR_LEN + bcn->size();
ch->addr_type() = NS_AF_NONE;
ch->prev_hop_ = index;
ih->saddr() = index;
ih->daddr() = IP_BROADCAST;
ih->sport() = RT_PORT;
ih->dport() = RT_PORT;
ih->ttl_ = NETWORK_DIAMETER;
RouteCache *rt = rt_lookup(bcn->beacon_src);
if (rt == NULL) {
rt_insert(bcn->beacon_src,bcn->beacon_id, ih->saddr(), bcn-
>beacon_posx, bcn->beacon_posy, bcn->beacon_hops);
ih->saddr() = index;
bcn->beacon_hops +=1; // increase hop count
double delay = 0.1 + Random::uniform();
forward(p, IP_BROADCAST, delay); }
else if (bcn->beacon_id > rt->rt_seqno) {
rt->rt_state = ROUTE_FRESH;
rt->rt_hopcount = bcn->beacon_hops;
rt->rt_expire = CURRENT_TIME + DEFAULT_ROUTE_EXPIRE;
ih->saddr() = index;
bcn->beacon_hops +=1; // increase hop count
double delay = 0.1 + Random::uniform();

57
#ifdef DEBUG
printf("F (%.6f): UPDATE ROUTE, forward beacon by %d \n",
CURRENT_TIME, index);
#endif
forward(p, IP_BROADCAST, delay); }
else if ((bcn->beacon_id == rt->rt_seqno) && (bcn->beacon_hops <
rt->rt_hopcount )) {
rt->rt_seqno = bcn->beacon_id;
rt->rt_hopcount = bcn->beacon_hops;
rt->rt_expire = CURRENT_TIME + DEFAULT_ROUTE_EXPIRE;
} }
void WFRP::rt_insert(nsaddr_t src, u_int32_t id, nsaddr_t nexthop, u_int32_t xpos,
u_int32_t ypos, u_int8_t hopcount) {
RouteCache *rt = new RouteCache(src, id);
rt->rt_nexthop = nexthop;
rt->rt_expire = CURRENT_TIME + DEFAULT_ROUTE_EXPIRE;
LIST_INSERT_HEAD(&rthead, rt, rt_link); }
RouteCache*
WFRP::rt_lookup(nsaddr_t dst) {
RouteCache *r = rthead.lh_first;
for( ; r; r = r->rt_link.le_next) {
if (r->rt_dst == dst)
return r; }
return NULL; }
void WFRP::rt_purge() {
RouteCache *rt= rthead.lh_first;
double now = CURRENT_TIME;
for(; rt; rt = rt->rt_link.le_next) {
if(rt->rt_expire <= now)

58
rt->rt_state = ROUTE_EXPIRED; }}
void WFRP::rt_remove(RouteCache *rt) {
LIST_REMOVE(rt,rt_link);
}

aodv_packet.h
#ifndef __aodv_packet_h__
#include <classifier/classifier-port.h>
#define NETWORK_DIAMETER 64
#define DEFAULT_BEACON_INTERVAL 10 // seconds;
#define DEFAULT_ROUTE_EXPIRE
2*DEFAULT_BEACON_INTERVAL // seconds;
#define ROUTE_PURGE_FREQUENCY 2 // seconds
#define ROUTE_FRESH 0x01
#define ROUTE_EXPIRED 0x02
#define ROUTE_FAILED 0x03

class WFRP;
class wfrpBeaconTimer : public Handler {
public:
wfrpBeaconTimer(WFRP* a) : agent(a) {}
void handle(Event*);
private:
WFRP *agent;
Event intr;
};
class wfrpRouteCacheTimer : public Handler {
public:

59
 wfrpRouteCacheTimer(WFRP* a) : agent(a) {}
void handle(Event*);
private:
WFRP *agent;
Event intr; };
class RouteCache {
friend class WFRP;
public:
RouteCache(nsaddr_t bsrc, u_int32_t bid) { rt_dst = bsrc; rt_seqno = bid; }
protected:
LIST_ENTRY(RouteCache) rt_link;
u_int32_t rt_xpos; // x position of destination;
u_int32_t rt_ypos; // y position of destination;
u_int8_t rt_state; // state of the route: FRESH, EXPIRED,
FAILED (BROKEN)
u_int8_t rt_hopcount; // number of hops up to the destination (sink)
double rt_expire; // when route expires };
LIST_HEAD(wfrp_rtcache, RouteCache);
class WFRP : public Agent {
friend class RouteCacheTimer;
public:
WFRP(nsaddr_t id);
void recv(Packet *p, Handler *);
int command(int, const char *const *);
void rt_insert(nsaddr_t src, u_int32_t id, nsaddr_t nexthop,
u_int32_t xpos, u_int32_t ypos, u_int8_t hopcount);
wfrpBeaconTimer bcnTimer;
wfrpRouteCacheTimer rtcTimer;
void send_beacon();

60
 void forward(Packet *p, nsaddr_t nexthop, double delay);
void recv_beacon(Packet *p);
void recv_error(Packet *p);
};

node.h
#ifndef __wfrp_packet_h__
#define __wrfp_packet_h__
#define WFRP_BEACON 0x01
#define WFRP_ERROR 0x02
#define HDR_WFRP(p) ((struct hdr_wfrp*)hdr_wfrp::access(p))
#define HDR_WFRP_BEACON(p) ((struct
hdr_wfrp_beacon*)hdr_wfrp::access(p))
#define HDR_WFRP_ERROR(p) ((struct hdr_wfrp_error*)hdr_wfrp::access(p))
struct hdr_wfrp {
u_int8_t pkt_type;
static int offset_;
inline static int& offset() { return offset_;}
inline static hdr_wfrp* access(const Packet *p) {
return (hdr_wfrp*) p->access(offset_);
} };
struct hdr_wfrp_beacon {
u_int8_t pkt_type; // type of packet : Beacon or Error
u_int8_t beacon_hops; // hop count, increadecreases as beacon is
forwarded
u_int32_t beacon_id; // unique identifier for the beacon
nsaddr_t beacon_src; // source address of beacon, this is sink address
u_int32_t beacon_posx; // x position of beacon source, if available

61
 u_int32_t beacon_posy; // y position of beacon source, if available
double timestamp; // emission time of beacon message
inline int size() {
int sz = 0;
sz = sizeof(struct hdr_wfrp_beacon);
assert(sz>=0);
return sz;
}};
struct hdr_wfrp_error {
u_int8_t pkt_type; // type of packet : Beacon or Error
u_int8_t reserved; // reserved for future use
nsaddr_t error_src; // error packet source node;
nsaddr_t urch_dst; // unreachable destination
double timestamp; // emission time
inline int size() {
int sz = 0;
sz = sizeof(struct hdr_wfrp_error);
assert(sz>=0);
return sz;
}};
// For size calculation of header-space reservation
union hdr_all_wfrp {
hdr_wfrp wfrp;
hdr_wfrp_beacon beacon;
hdr_wfrp_error error;
};

62
 3. AWK Files for calculating the parameters:

para.awk (Containing Generated Packets, Received Packets,

Dropped Packets, Packet Delivery Ratio,End-To-End Delay):
BEGIN {
seqno = -1
droppedPackets = 0
receivedPackets = 0
count = 0
}
{
#packet delivery ratio
if($4 == "AGT" && $1 == "s" && seqno < $6) {
seqno = $6
} else if(($4 == "AGT") && ($1 == "r")) {
receivedPackets++
} else if ($1 == "D" && $7 == "tcp" && $8 > 512){
droppedPackets++
}
#end-to-end delay
if($4 == "AGT" && $1 == "s") {
start_time[$6] = $2
} else if(($7 == "tcp") && ($1 == "r")) {
end_time[$6] = $2
} else if($1 == "D" && $7 == "tcp") {
end_time[$6] = -1
}
}END {
for(i=0 ;i<=seqno ;i++) {
if(end_time[i] > 0) {

63
 delay[i] = end_time[i] - start_time[i]
count++ }
else {
delay[i] = -1 } }
for(i=0; i<count; i++) {
if(delay[i] > 0) {
n_to_n_delay = n_to_n_delay + delay[i] } }
n_to_n_delay = n_to_n_delay/count
print "\n"
print "GeneratedPackets = " seqno+1
print "ReceivedPackets = " receivedPackets
print "Packet Delivery Ratio = "receivedPackets/(seqno+1)*100 "%"
print "Total Dropped Packets = " droppedPackets
print "Average End-to-End Delay = " n_to_n_delay * 1000 " ms"
print "\n"
}

64
 APPENDIX-2

USER INTERFACE DESIGN

Fig 7.1:- Running aodv.tcl file

Fig 7.2:- Parameters generated for tcl code for three nodes
65
Fig 7.3:- Modified AODV Parameters

66
 REFRENCES

1. S.Mohapatra, P.Kanungo, Performance Analysis Of AODV, DSR, OLSR

And DSDV Routing Protocols Using Ns2 Simulators
2. Yinfei Pan, Suny Binghamton, Design Routing Protocol Performance
Comparison In Ns2 : AODV Comparing To DSR As Example.
3. Nisarg Gandhewar, Rahila Patel, Performance Evaluation Of AODV
Protocol In MANET Using Ns2 Simulator
4. Samyak Shah, Amit Khandre, Mahesh Shirole, and Girish Bhole,
Performance Evaluation Of Ad Hoc Routing Protocols Using Ns2
Simulation

67