CHAPTER

INTRODUCTION
1.1(a)AIM AND OBJECTIVE
Present Scenario of real life is fully or partially based on science and technology. Today,
every activity in each area such as commerce, manufacturing, transportations and education
are frequently using computer networks to the ease of share the data over different places.
Data communication and networking are changing the way to do business, for safety purpose,
traffic experience and the way of living life. Since their emergence in the 1970s, wireless
networks have become increasingly popular in the computing industry. This is particularly
true within the past decade, which provides possibility of wireless networks being adapted to
enable mobility.
Wireless communication is one of the fastest-growing technologies. The demand for
connecting devices without the use of cables is increasing everywhere. Wireless LANs can be
found on college campuses, in the office buildings, on the roads and in many public areas.
The increasing demand of wireless communication and the needs of new wireless devices
have tend to research on self-organizing healing networks without the interference of
centralized or pre-established infrastructure/authority. The networks with the absence of any
centralized infrastructure are called Ad-hoc networks. Ad-hoc networks are collection of selfgoverning mobile nodes.
The aim of this research is to investigate what is the best way to support QOSin a MANET
containing malicious nodes. To make the investigation feasible within the given time-frame,
it is assumed in this thesis that malicious nodes only perform packet forwarding attacks on
data packets. The reason for this is that data packets are not typically transmitted during the
route discovery phase of routing protocol operation; and this thesis is concerned with the
QOS that the data packets, rather than protocol control packets, receive. Research on
supporting the delivery of routing protocol control packets in the presence of attacker nodes
is a substantial research area in and of itself. The above aim is supported by the following
have objectives.
1. To investigate and analyze MANET characteristics and security threats in this
environment, and understand their implications on the provision of QOS.
2. To analyze and specify design requirements for a QOS solution to support effective and
efficient QOS provisioning (including security related requirements) in a MANET containing
malicious nodes.
3. To analyze critically existing MANET QOS solutions against the specified requirements to
identify limitations, weaknesses, and missing features in their support for QOS provisioning.
4. To design a solution to support QOS in the presence of node mobility and malicious
attacks. The design will be guided by the requirements specified in (2) and based on the
existing state-of-the-art analyzed in (3), harvesting their strengths and overcoming their
limitations and weaknesses.
5. To perform a performance evaluation of the proposed solution, and to compare its
performance with related work.
1

1.1(b) HISTORY
We can characterized the life cycle of mobile ad hoc network into first, second and third
generation. Present ad-hoc network are considered the third generation [2][3]. The first
generation of ad hoc network can be traced back to 1970s. In 1970s, these are called Packet
Radio Network (PRNET) [4]. The Defense Advanced Research Project Agency (DARPA)
initiated research of using packet- switched radio communication to provide reliable
communication between computers and urbanized PRNET. Basically PRNET uses the
combination of Areal Location of Hazardous Atmospheres (ALOHA) and Carrier Sense
Multiple Access (CSMA) for multiple access and distance vector routing [5][2][3]. The
PRNET is then evolved into the Survivable Adaptive Radio Network (SURAN) in the early
1980s. SURAN provides some benefits by improving the radio performance (making them
smaller, cheaper and power thrifty). This SURAN also provides resilience to electronic
attacks. Around the same time, United State Department of Defense (DOD) continued
funding for programs such Globe Mobile Information System (GloMo) and Near Term
Digital Radio (NTDR). GloMo make use of CSMA/CA and TDMA molds, and provides selforganizing and self-healing network (i.e. ATM over wireless, Satellite Communication
Network). The NTDR make use of clustering and link state routing and organized an ad hoc
network. NTDR is worn by US Army. This is the only real ad hoc network in use. By the
growing interest in the ad hoc networks, a various other great developments takes place in
1990s.
The functioning group of MANET is born in Internet Engineering Task Force (IETF) who
worked to standardized routing protocols for MANET and gives rise to the development of
various mobile devices like PDAs , palmtops, notebooks, etc . Meanwhile the Development
of Standard IEEE 802.11 (i.e. WLANs) benefited the ad hoc network. Some other standards
are also developed that provide benefits to the MANET like Bluetooth and HIPERLAN.

1.2 A LITTLE BACKGROUND

A Mobile ad hoc network (MANET) is a collection of autonomous mobile nodes which
communicate with one another using wireless links. They co-operate a distributed fashion to
provide network functionality in the absence of fixed network infrastructure. Nodes are
typically small, light-weight, and battery powered. They usually have fewer resources and are
less capable than a desktop or portable computer. The network topology is dynamic due to
node mobility. The autonomy and self-sufficiency of MANETs enables them to be deployed
as stand alone networks which do not require network infrastructure .MANETs can also play
an important role in accessing networked services in the Internet. MANETs, as edge
networks, could facilitate Internet service access to broader groups of users. For example,
emergency responders in a disaster relief scenario may require Internet connectivity to
communicate with their head-quarters, or to access resources available on the Internet. An
Internet-based Mobile Ad Hoc Network (MANET) interfaces a MANET into the wired
Internet backbone by adding one or more points of attachment to the Internet, thus connecting
the two network components.1 In MANETs can provide a seamless mobile extension to the
Internet and allow ubiquitous mobile access to a large number of services that are available
on the Internet . This implies that a greater number of applications and diverse data types
should be supported in the MANET component of the MANET.

FIGURE 1.1 OVERVIEW OF MOBILE AD-HOC NETWORK

1.2.1 CHARACTERISTICS OF MANET

1.In MANET, every node can act as both host as well as a router. So, it has an autonomous
behavior.
2.Whenever the source and destination are not reachable, MANETs are capable of multi-hop
routing.
3.It has a circulated nature of operation for security, directing and host setup. An unified
farewell is missing here.
4.The hubs can join or leave the system at whatever time, making the system topology
changing in nature.
5.Versatile hubs are described with characteristics such as light weight, less memory and
power.
6. The unwavering quality, productivity, security and limit of remote connections are
frequently subpar when contrasted and wired connections. This shows the fluctuating
connection transfer speed of remote connections.
7. Mobile and spontaneous conduct which requests least human intercession to arrange the
system.
8.All hubs have indistinguishable characteristics with comparative obligations and
proficiencies and thus it structures a totally nature.

9.High client thickness and extensive level of client portability. Nodal integration is
discontinued.

1.2.2 CHALLENGES OF MANET

1. Mobility
2. Bandwidth constraint
3. Error-prone and shared channel
4. Location-dependent contention
5. Other resource constraints
6. Limited power supply
7. Security
8. Traffic
9. Path distance
10. Delay
Regardless of the attractive applications, the features of MANET introduce several challenges
that must be studied carefully before a wide commercial deployment can be expected. These
include [6,7].
Dynamic topologies: Nodes are free to move arbitrarily; thus, the network topology--which
is typically multi hop, may
change randomly and rapidly at unpredictable times, and may consist of both bidirectional
and unidirectional links.
Routing: Since the topology of the network is constantly changing, the issue of routing
packets between any pair of nodes
be-comes a challenging task. Most protocols should be based on reactive routing instead of
proactive. Multi cast routing is another challenge because the multi cast tree is no longer
static due to the random movement of nodes within the network. Routes between nodes may
potentially contain multiple hops, which is more complex than the single hop communication.
Device discovery- Identifying relevant newly moved in nodes and informing about their
existence need dynamic update to facilitate automatic optimal route selection.
Bandwidth-constrained-variable capacity links: Wireless links will continue to have
significantly lower capacity than their hardwired counterparts.
Power-constrained and operation: Some or all of the nodes in a MANET may rely on
batteries or other exhaustible means for their energy. For these nodes, the most important
system design criteria for optimization may be energy conservation. For most of the lightweight mobile terminals, the communication-related functions should be optimized for lean
power consumption. Conservation of power and power-aware routing must be taken into
consideration.
Security and Reliability: In addition to the common vulnerabilities of wireless connection,
an ad hoc network has its particular security problems due to e.g. nasty neighbor relaying
packets. The feature of distributed operation requires different schemes of authentication and
key management. Further, wireless link characteristics introduce also reliability problems,
4

because of the limited wireless transmission range, the broadcast nature of the wireless
medium (e.g. hidden terminal problem), mobility-induced packet losses, and data
transmission errors. Mobile wireless networks are generally more prone to physical security
threats than are fixed-cable nets. The increased possibility of eavesdropping, spoofing, and
denial-of-service attacks should be carefully considered.
Quality of Service (QOS): Providing different quality of service levels in a constantly
changing environment will be a challenge. The inherent stochastic feature of communications
quality in a MANET makes it difficult to offer fixed guarantees on the services offered to a
device. An adaptive QOS must be implemented over the traditional resource
reservation to support the multimedia services.
Inter-networking: In addition to the communication within an ad hoc network, internetworking between MANET and fixed networks (mainly IP based) is often expected in
many cases. The coexistence of routing protocols in such a mobile device is a challenge for
the harmonious mobility management.
Multicast: Multicast is desirable to support multiparty wireless communications. Since the
multicast tree is no longer static, the multicast routing protocol must be able to cope with
mobility including multicast membership dynamics (leave and join).
IP-Layer Mobile Routing-An improved mobile routing capability at the IP layer can provide
a benefit similar to the intention of the original Internet, viz. "an interoperable
internetworking capability over a heterogeneous networking infrastructure".
Diffusion hole problem: The nodes located on boundaries of holes may suffer from
excessive energy consumption since the geographic routing tends to delivers data packets
along the hole boundaries by perimeter routing if it needs to bypass the hole. This can enlarge
the hole because of excessive energy consumption of the node boundaries nodes
Node Mobility
The mobility of nodes, which are also routers, presents a challenge to smooth network
operation. MANET nodes are typically mobile. They roam in and out of one another's
wireless transmission range. This results in a dynamically changing network topology. This
means that a path established between a source node and a destination node may be shortlived. If the underlying network is not able to respond to such dynamic topological changes in
a timely manner it may result in significant periods of service disruption, e.g., delay and lost
packets. Supporting QOS in this dynamic environment is therefore a challenging issue.
Device Heterogeneity, Limited Node Capabilities, and Limited Channel Bandwidth
Devices (nodes) participating in a MANET are typically heterogeneous and their
specifications may vary considerably. A wireless node usually has lower resource capabilities
(CPU, memory, etc.) than a desktop or laptop computer. Table 2.1 shows a comparison of
processing and memory capabilities of a selection of mobile devices including a sensor [13],
a PDA (Personal Digital Assistant) [14], a smartphone [15] and a laptop [23]. The range of
capabilities is considerable. For example, the memory available on the laptop (3072MB) is
approximately 48 times greater than that on the sensor (64KB). The specification of a device
may limit the resources it is able to dedicate to the servicing of other nodes' packet flows.
In addition to potentially limited node resources, wireless networks have lower bandwidth
availability than their wired counterparts. Bandwidth availability may often actuate in a
5

MANET. This may be due to (1) MANET-specific factors such as node mobility and (2)
general factors such as a variable network load. A QOS solution for the wireless environment
should therefore use the limited bandwidth efficiently and effectively.
Device Processor
Sensor
PDA
Smartphone
Laptop
Desktop

Speed
12 MHz
624 MHz
1 GHz
2 GHz
2.93 GHz

Available Memory
64 KB
64MB
576 MB
3072 MB
4096 MB

Table 1.1: A Comparison of Processing and Memory Specifications of Heterogeneous

Devices.
A Lack of Infrastructural Support
A MANET is devoid of infrastructure and does not have any central authority, coordination,
or control. The responsibility of operating a network therefore falls on the communicating
nodes participating in the network. This distributed approach to providing network services
prompts a shift from one-hop wireless communications to multi-hop wireless
communications. Nodes have the responsibility of providing routing services for other nodes.
This is in addition to the communication of their own data flows. However, nodes may
exploit their position as routers to affect the QOS they over to other nodes' packet flows.
Security Threats
A number of threats to network operations are introduced as a result of delegating routing
responsibilities to MANET participant nodes. Having such responsibility places these nodes
in a position to launch security attacks. For example, a node could discard or delay any traffic
it is required to forward. If no counter-measures are provided these security threats may
significantly innocence the QOS the data flows receive. An additional security threat,
although non-malicious, is the issue of device fallibility. It is significant in this environment
where peer nodes act as routers. Hardware failures and depleted batteries, for example, can
lead to path unavailability and routing disruption [21]. These genuine failures can be difficult
to differentiate from node miss behavior [22]. This is because failures and miss behavior may
both have the same consequence, i.e., packet loss. Whilst these failures do not result from
malicious activity, maintaining path and network availability remains a security issue [19].
Security mechanisms designed to combat insecurity in a MANET may themselves be
exploited to the advantage of malicious nodes. For example, the time and resource costs of
processing a security mechanism could be used as the basis of an attack to tie-up a node's
limited resources and to prevent it from participating in the network [16]. This will adversely
affect network operations as time and resources will be dedicated to security processing
rather than routing. The level of security employed and the way the security is provided are
therefore significant to the QOS that the network can support. All of these factors and
considerations illustrate the association between security and QOS, and reinforce the notion
that security concerns need to be addressed in order to support QOS.

1.2.3 APPLICATIONS OF MANET

MANETs over an important alternative to traditional infrastructure-based networks. Their
ability to support communications without infrastructure, in locations devoid of infrastructure
or where it has been destroyed, makes them ideal for use in responding to natural disasters or
6

in battlefield scenarios. A MANET can also extend the range of the Internet by serving as an
edge network. This can enable mobile users to share and access data and resources on the
Internet, where it would have not previously been possible. Tele-medicine is an application
scenario which may benefit from MANET and Internet integration and the provision of QOS
in this context. This section presents three application scenarios disaster relief, battlefield, and
telemedicine to illustrate that providing QOS in MANETs is necessary and that security
should be considered as an integral part of QOS provisioning.
1.Disaster Relief
Hurricane Katrina wreaked havoc across the USA and Gulf Coast in 2005. Parts of the
communications infrastructure were damaged or destroyed, and this hindered the federal
response [188]. Some of those affected by the disaster established a mesh network
comprising a number of static nodes distributed over a large geographic area. This enabled
communications between rescuers, officials, and civilians [13]. Mesh networks are related to
MANETs: both are types of wireless network which may have dynamic topologies, e.g., as a
sequence of lossy links, but MANET topologies are determined ad hoc and may also be
affected by node mobility [10, 58]. Another use of ad hoc networks in disaster relief is to
provide a communications platform for rescue robots. Autonomous and semi-autonomous
rescue robots can be sent into damaged buildings which may be hazardous to rescue workers.
Rescue workers operating the robotic platform in [92] use streaming video and static images
to control a robot and to assess a disaster scenario remotely. These data are communicated to
the robot's operator over an ad hoc network. The robot also uses an array of sensors for
location tracking and obstacle detection. Thus the real-time streaming video, images, sensor
data, robot control data, and routing protocol data must co-exist within the network.
2.Battle-Field
Another use of robots and ad hoc networks is by the military on the battlefield. Robots can be
controlled remotely over a MANET by soldiers. Using a MANET as the communications
platform allows the robots to be deployed quickly and conveniently in urban environments
[20]. For example, the work in [14] shows the integration of robots into a military mission. A
robot is tele-operated by a soldier. The soldier navigates the robot using a real-time video
feed. This feed is captured by the robot and streamed over a MANET to the soldier's control
unit. The video data must co-exist in the network with the robot control data and routing
protocol control data. There is therefore a requirement to support the requirements of
different data types simultaneously. Additionally, these data must be secured so that they
cannot be accessed by an enemy.
3. Tele-Medicine
Tele-medicine is the delivery of healthcare and medical expertise using communication
technologies [15]. These technologies enable medical information to be exchanged and
medical and healthcare services to be delivered between geographically distributed entities
(individuals and health service providers) [16]. For example, through the use of
communication networks healthcare and medical treatments can be provided to patients in
remote areas, or in areas where there is a lack of medical expertise or infrastructural support
(e.g., for disaster relief). Mobile wireless devices, when connected to the Internet, can allow
access to medical expertise or expert treatment anywhere and at any time. For example, prehospital treatment can be provided or enhanced in a mobile context; and expert treatment or
diagnoses are possible while a patient is en route to a hospital in an ambulance. The
monitoring of the patient's health data (vital signs such as heart rate, blood pressure, etc.) can
be undertaken in the ambulance and transmitted in real-time to the hospital [13, 20, 22].
7

Other real-time and non-real-time medical data, such as high-quality video, still images (Xrays), and electronic patient records [19], can also be transmitted, so that experts, regardless
of their locations, can make a visual inspection of these data and provide a diagnosis prior to
the patient's arrival at the hospital. From the above it can be seen that communication
technologies can play an important role in supporting healthcare. This applies in both mobile
and static contexts as well as in locations with and without infrastructure. There exists a need
to support a wide-range of applications and provide resilient communications between
different health professionals, regardless of their locations, from first contact with a patient to
his or her arrival at and departure from a hospital.

1.2.4 MANET ROUTING PROTOCOL

As the nodes in a wireless ad-hoc network can be connected in a dynamic and arbitrary
manner, the nodes themselves must behave as routers and take part in discovery and
maintenance of routes to other nodes in the network. The goal of a routing algorithm is to
devise a scheme for transferring a packet from one node to another. One challenge is to
define/choose which criteria upon which to base the routing decisions. Examples of such
criteria include hop length, latency, bandwidth and transmission power. Lists some of the
challenges in designing a routing protocol for ad-hoc wireless networks, and a brief overview
of these is given below.
Mobility The network needs to adopt to rapid changes in the topology due to the movement
of the nodes, or the network as a whole.
Resource constraints Nodes in a wireless network typically have limited battery and
processing power, and these resources must be managed optimally by the routing protocol.
Error-prone channel state The characteristics of the links in a wireless network typically
vary, and this calls for an interaction between the routing protocol and the MAC protocol to,
if necessary, find alternate routes.
MANET routing protocols are typically subdivided into two main categories: Proactive
routing protocols and Reactive on-demand routing protocols.
Proactive protocols
In networks utilizing a proactive routing protocol, every node maintains one or more tables
representing the entire topology of the network. These tables are updated regularly in order to
maintain up-to-date routing information from each node to every other node. To maintain upto-date routing information, topology information needs to be exchanged between the nodes
on a regular basis which in turn leads to relatively high overhead on the network. The
advantage is that routes will always be available on request.
Reactive protocols
Unlike proactive routing protocols, reactive routing protocols do not make the nodes initiate a
route discovery process until a route is required. This leads to higher latency than with
proactive protocols, but lower overhead. Ad-hoc On-Demand Distance-Vector routing
protocol (AODV).

Hybrid protocols
These types of protocols combine proactive and reactive protocols to exploit their strengths.
One approach is to divide the network into zones, and use one protocol within the zones, and
another between them.

1.3 NETWORK QUALITY OF SERVICE (QOS)

When multiple data types are involved there is a need to address the issue of Quality of
Service (QOS). QOS is the process of differentiating traffic so that a certain set of
requirements can be satisfied in terms of a set of constraints[4]. In other words, QOS is a
process of discriminating different packet types to provide them with an appropriate level of
service. Data within a MANET may have different priority requirements, just as they do in
traditional fixed networks. These requirements are typically satisfied by servicing higherpriority traffic before lower-priority traffic. For example, in existing QOS approaches, real
time voice traffic has a higher transmission priority than best-effort traffic from Websites. As
a MANET can be used to extend the Internet, it should therefore aim to provide a comparable
level of QOS. However, the characteristics of a MANET may present a challenge to the way
in which QOS can be provided. In traditional networks QOS is supported by the presence of
infrastructure, which includes routers [15,16]. The position of a router is fixed in such
networks. In infrastructure-less MANETs, routers, which are peer communication nodes, are
also mobile. The dynamic nature of MANETs therefore presents a significant challenge to
QOS provisioning. In addition, the issue of QOS provisioning is further complicated by the
fact that not all communication nodes may be able or willing to participate in the routing
(packet forwarding) process.
1.3.1 QOS Routing
Another category of efforts on supporting QOS provisioning in MANETs is by designing
QOS routing protocols. These protocols are designed to satisfy some specified QOS
requirements by adding relevant QOS parameters into the routing table of each node. When a
path is required the corresponding QOS parameter values associated with each path are
calculated, and the path with the best value is chosen. End-to-end delay and bandwidth are
the commonly used QOS parameters in early QOS routing protocols such as QOS-AODV
[23] and Quality of Service AODV [17].Other QOS routing protocols have started using other
additional information, e.g., energy, as QOS parameters to make routing decisions energyaware. The Stability-based, QOS capable AODV (SQ-AODV) protocol [19] is an example of
an energy-aware QOS routing protocol. It defines a new QOS parameter, called residual node
energy, and uses it to govern path selections. It uses a cross-layer approach to estimate
residual node energy and feeds this estimation into the path selection and maintenance
process, thus minimizing connection interruptions due to battery depletion.
1.3.2 Rising necessity for QOS provision
In the past decades mobile traffic, which by definition refers to data generated by handsets,
laptops and mobile broadband gateways, has been growing rapidly annually. According to a
survey by Cisco, mobile data in 2010 was triple the volume of the entire global Internet
traffic in 2000. The growth rate in the previous year was 159%, which is10% higher than
anticipated in 2009. This rapid growth in mobile data is forecast to continue for the next five
years with an average annual growth of 92% [21].

There are several reasons why mobile traffic has grown so quickly. Firstly, mobile video,
which requires high bit rates, is considered to lead to the increase of mobile traffic. It is
reported that mobile video reached as high as 49.8% of total mobile traffic in 2010 and will
account for two thirds of mobile traffic by 2015 [19]. Moreover, Internet gaming, which
consumes, on average, 63 PB per month in 2009, also results in a growth in mobile traffic and
it is expected to achieve an annual growth of 37% in the coming five years [4]. Last but not
the least, Voice over IP (VoIP) which includes phone-based VoIP services direct from or
transported by a third party to a service provider, and software-based internet VoIP such as
Skype, leads to the expansion of mobile traffic. Many of those applications described above
are real-time applications which demand certain guarantees for performance metrics for
acceptable operation.
Those metrics specify the Quality of Service.
1.3.3 Quality of Service in Mobile Ad hoc Networks
A mobile ad hoc network can be seen as an autonomous system or a multi-hop wireless
extension to the Internet. As an autonomous system, MANET should provide its own routing
protocols and network management mechanisms. As a multi-hop wireless extension, it should
provide a flexible and seamless communication among the users or access to the Internet.
Recently, due to increasing popularity of multimedia applications and pending commercial
deployment of MANETs, the quality of service(QOS) support in MANETs has become an
important requirement. However, the QOS support in a MANET is unlike that of the wire line
network or the cellular network because wireless bandwidth is shared among neighboring
nodes and the network topology continuously changes with node mobility. This condition
requires extensive collaboration between the nodes, both to establish the route and to secure
the resources necessary to provide the QOS.
According to RFC2386 [2], QOS is defined as a set of service requirements to be met by the
network while transporting a packet stream from source to destination. Intrinsic to the notion
of QOS is an agreement or a guarantee by the network to provide a set of measurable prespecified service attributes to the user in terms of delay, jitter, available bandwidth, packet
loss, and so on. As in the Internet, mobile ad hoc network share designed to support the besteffort service with no guarantees of associated QOS.
Therefore, when a packet is lost in a mobile ad hoc network, the sender simply retransmits
the lost packet. This is an efficient method for applications requiring no QOS, but simple endto-end retransmission is inadequate for real-time applications that are sensitive to packet loss,
delay, bandwidth availability, etc. Although a lot of work has been done in supporting QOS in
the Internet, they are not readily applicable to MANET due to their resource constraints and
frequent topology changes. For example, current QOS routing algorithms for the Internet
require accurate link state and topology information, but the time-varying capacity of
wireless links and mobility make it almost impossible to provide accurate global information
in MANETs. Knowing these limitations, researchers are attempting to provide new QOS
components tailored to MANETs. This research effort includes QOS routing, QOS signaling
schemes (e.g., resource reservation), QOS-based MACs, and soon.
The QOS routing is different from the resource reservation (i.e., QOS signaling)and they
have two distinct responsibilities that can be either coupled or decoupled in QOS
architectures. The QOS routing protocol is used to find a path that meets the QOS needs, but
it is the QOS signaling that reserves, maintains, and releases resources in the network. The
QOS signaling will work better if it coordinates with QOS routing but most QOS routing
algorithms are too complicated or too expensive (i.e., substantial overhead) to be
implemented in MANET. The QOS signaling still works even without support of a QOS
10

routing but the resource reservation may fail because the selected path may not have enough
resources.
As of now, the Resource Reservation Protocol (RSVP) [3] and Session Initiation Protocol
(SIP) are the widely accepted standard signaling protocols for the Internet. However, they are
not directly applicable to MANETs because the signaling overhead is too high when network
topology changes. These signaling control messages will contend with data packets for the
channel and cost a large amount of bandwidth. In addition, RSVP and SIP are not adaptive
enough for MANETs because they have no mechanism to rapidly respond to the topology
change. In particular, when the network topology changes, the signaling entity that has to
manage resource reservations in the network often fails to de-allocated resources on the old
path due to lack of connectivity to the targeted nodes .
The QOS MAC protocol is an essential component in QOS support in MANETs. All upperlayer QOS components (i.e., QOS routing and QOS signaling) are dependent on the QOS
MAC and the ability to provide QOS is dependent on how well there sources are managed at
the MAC layer. Although many MAC protocols (e.g., MACA [4], MACAW [5], FAMA [6],
MACA-BI [7]) have been proposed for wireless networks, they are primarily designed to
solve medium contention, hidden/exposed terminal problems but do not incorporate the
notion of QOS. Recently, the Group Allocation Multiple Access with Packet-Sensing
(GAMA-PS) protocol [8] and the Black-Burst contention mechanism [9] have been proposed
to support QOS guarantees to real-time traffic in a distributed wireless environment.
However, their QOS support[7]is valid only in a wireless LAN environment where every host
can sense each other's transmission without any hidden terminals. In fact, all aforementioned
MAC protocols show some level of inadequacy for QOS support or multi-hop wireless
networking.
Consequently, the IEEE 802.11 is the de facto standard MAC for MANETs. Various research
studies have proven that the IEEE 802.11 is capable of supporting multi-hop wireless
networking, effectively eliminates the hidden terminals, and provides the collision avoidance
feature through its distributed control function (DCF).However, the IEEE 802.11 DCF only
supports best effort service. To incorporate the notion of QOS, several researchers have
proposed some modifications to the IEEE 802.11 DCF to support differentiated service. Note
that the signaling protocol is the control center that coordinates the behaviors of routing,
MAC, and other components (e.g., admission control, scheduling). Hence, better QOS can be
provided if the signaling component coordinates with other QOS modules. However, since
realization of QOS components such as QOS routing and QOS MAC are often prohibitively
complex and impractical in MANET environment, we need to consider implementing generic
QOS measures that are not reliant on a QOS routing or a specific MAC.
1.3.4 Congestion in Mobile Ad hoc Networks
Traditionally, congestion occurs when the total volume of traffic offered to the network or
part of the network exceeds the resource availability. Congestion typically manifests itself in
excessive end-to-end delay and packet drops due to buffer overflow. There are a variety of
conditions that can contribute to congestion and they include but are not limited to traffic
volume, the underlying network architecture, and the specification of devices in the network
(e.g., buffer space, transmission rate, processing power, etc).As in the Internet, a mobile ad
hoc network is also afflicted by diverse degrees of congestion. However, the cause and
characteristics of congestion conditions in MANET are somewhat different from that of the
Internet. This was discovered while evaluating the performance of the QOS signaling
protocol discussed in this dissertation. This observation led us to study the simulation results
and test bed experiments for the identification and the solution for the congestion conditions
11

in MANET. It was observed that the many congestion conditions in MANET are not
necessarily due to the presence of excessive workloads in the network. In fact, we can
observe congestions under all loading conditions, even in the lightly loaded networking
condition. After a careful study of this intriguing phenomenon, it was found that the route
selection convention widely implemented in MANET routing protocols is one of the key
reasons for these peculiar congestion conditions. Being a mobile network, the network
topology of a MANET may change and cause a flow to reroute multiple times during the
lifetime of an on-going session. The route discovery or rerouting procedure of many ondemand MANET routing protocols allows intermediate nodes to reply to route requests
leading to a small number of routes becoming overused throughout the network. The
mechanism to reduce the impact of flooding caused by route request packets inadvertently
fosters a small number of routes to be overused, creating a unique congestion condition in
MANET. In fact, we observe patches of heavily congested areas in MANETs that entail
packet loss, delay spikes, and unbalanced resource consumption. While some researchers
have broadly discussed congestion issues [10] in mobile ad-hoc networks, there is no
comprehensive approach to this problem. This led us to investigate a generic solution that can
be applied to all existing MANET protocols.
QOS is usually defined as a set of services that should be supported during packet
transmission. A QOS enabled protocol is expected to support several parameters in
terms of end-to-end throughput, delay, and jitter as well packet delivery ratio.
End-to-End Throughput
End-to-End throughput, , is defined as the ratio of the payload of effectively delivered
data packets, Ped, over the elapsed time, telapsed.

=Ped/telapsed
Chapter (Next) Section 1Equation Chapter (Next) Section 1

the basic unit of is b/s or B/s. Effectively delivered data packets refers to data packets that
are successfully delivered, excluding any duplicated packets.
Since the available bandwidth in a network is fairly well known, it is helpful to obtain the
actual throughput achieved which reveals the bandwidth usage efficiency. The higher the
average throughput is, the better the bandwidth is utilized.
Delay (or Latency)
Delay, , sometimes refers to as end-to-end delay, is the time between the originating node
sending a packet and that packet reaching the destination. It may vary dramatically because
of long queue time or a congested network environment.

Figure 1.2 Delay components

As shown in Figure 1.2, delay is additive in the sense that it is built up over relay nodes
12

 = tS+ t1+ t2+...+ tn-1+ tn+ tD

where tS and tD denote processing time at the source and destination respectively. The
buffering time of a packet is of great importance for delay. If the buffering time in an
individual node is set to a higher value, it could imply that packets could stay in the buffer for
a long period of time when link breakages occur which will may reduce the packet dropping
rate [26]. In this case, the delay is higher. On the contrary, if the buffering time is shorter, the
performance of delay will improve but the packet dropping rate will increase. Delay and
packet delivery ratio are traded off in different applications.
Delay can be computed in multiple layers (e.g., application layer, transport layer network
layer and link layer) and thus it is layer-dependent. For the sake of synchronization, round
trip delay is used in some literature while others use single trip delay. In this thesis one-way
delay is computed in the application layer by using a timestamp in the packet header

= R t St
where Rt and St denote time at the source and destination for a given packet respectively,
assuming suitably synchronized clocks in the transmitter and receiver. In some cases,
excessive delay can render some time sensitive applications such as VoIP or online gaming
unusable.
Jitter
Jitter was originally used in signal processing where it measures the deviation of some pulses
in a digital signal and can be expressed in terms of phase, amplitude or width of the signal
pulse. In the context of mobile ad hoc networks, the term jitter is defined as the average of
difference between instantaneous delay and average delay.

Where n denotes number of effective received data packets, i is symbolizes delays for
different data unit and n represents the average delay. It is reported that jitter can degrade live
video quality nearly as much as packet loss rate.
Packet delivery ratio
The effective delivery ratio of data packets, , is defined as:
= ENDP/TNTP
where ENDP and TNTP denote number of effectively received and total data packets
respectively. Retransmission degrades the packet delivery ratio because it increases the
denominator. A high packet delivery ratio is desirable, especially in MANETs, since the
bandwidth available is limited for wireless links.

1.4 PROBLEM STATEMENT

Most on demand routing protocols for Ad hoc networks concentrate on the single path from a
source to a destination. Exhaustive use of a single path increases unbalance of traffic load and
intensively consumes energy of the nodes on the path. Therefore, distributing traffic load and
energy demand amongst all of the nodes of network is an important issue on Ad hoc
networks. Distributing energy demand not only means that energy is reduced for whole
13

network on average but also implies no node is depleted of energy. In this study, we analyse
the performance of a path-hopping routing based on reverse AODV (R-AODV). In contrast to
the standard AODV routing, R-AODV uses a reverse request rather than AODVs unicast
route reply. R-AODV therefore builds multi-path map to the destination and then adaptively
hops available paths for communications. Hopping paths can also protect data from the
intrusion by malicious nodes. We implement the simulation model of proposed path-hopping
routing using NS-2. Simulation results show benefits of the path hopping routing on
distribution of power consumption and increased security. Increasing of control packet
overhead and slightly decreasing of data delivery rate are disadvantages of path hopping.

1.5 RESEARCH AND MOTIVATION

As described in the previous section, QOS is defined as a set of requirements, such as delay,
delay jitter, bandwidth, and packet delivery rate, which must be met in transporting a data
packet in order to support application functions. In order to facilitate QOS support in
MANETs, it is important to understand the metrics that are used to specify QOS. Bandwidth.
Bandwidth is concave, which means that the end-to-end bandwidth is determined by the
bottleneck bandwidth along the path. Delay and jitter. Delay and jitter are additive. End-toend delay and jitter are the accumulation of each single hop delay/jitter.
Supporting more than one QOS constraint is an NP-complete problem [16]. However, delay
is associated with network load and degree of congestion. When bandwidth is sufficient,
delay is relatively short, but when congestion occurs, delay increases dramatically. The
relationship between bandwidth and delay has been studied in [34]. Therefore, while in this
dissertation we only study the bandwidth constraint, solving the bandwidth problem
inherently helps in solving the delay problem. Data transmission is the collaboration of each
network layer. Thus, a service differentiation model SWAN has been presented in [37] and a
QOS model has been discussed in [38]. However, these designs are not comprehensive
enough to include all network layers into consideration. Especially for MANETs, where
energy and bandwidth are two scarce resources, the requirements for efficiency are more
strict. Hence, a cross layer design QOS architecture could be a solution. Cross-layer design
has been studied in application-specific sensor network protocols [19], application-controlled
routing, and protocol frameworks for active wireless networks [12], and this has proven to be
an efficient approach. However, rather than fusing layers, it may be sufficient to just enable
the sharing of information among the layers of the OSI protocol stack. Thus, the QOS
architecture problem becomes which information should be exchanged among the layers to
support real-time transmissions in MANETs.
Based on an overview design of a QOS architecture, each layers function should be
determined. In the transport layer, UDP is used for transporting real-time data packets.
End-to-end throughput is greatly decreased beyond the maximal achievable when congestion
occurs, which would not happen in wired networks in the single chain topology, Therefore,
we argue for the necessity of using congestion control for best-effort traffic to improve the
performance in MANETs. The idea of UDPC is proposed to demonstrate the requisite of
incorporating a congestion control scheme in best-effort transmission.
In the network layer, an individual nodes total available bandwidth is not a static value. On
the contrary, it depends heavily on the neighborhood data transmission activities. Therefore,
for supporting QOS, incorporating bandwidth estimation into the routing setup procedure is a
key to finding the optimum path. Therefore, we study QOS routing based on bandwidth
estimation for supporting QOS in MANETs. The MAC protocol determines the most
fundamental performance of data transmission, such as fairness, stability and packet loss rate.
Therefore, it is crucial to obtain QOS support from the MAC layer. We utilize the idea of
14

separating the control channel and the data channel for supporting QOS, which is borrowed
from the cellular system.
We study the protocol design issues, the performance and the trade-off to support QOS at the
MAC layer.

1.6RELATED WORK
This section describes the AODV routing protocol. Some details on the route request
mechanism and link sensing are provided, along with an example.
Introduction to AODV
AODV is an on-demand routing algorithm that determines a route only when a node wants to
send a packet to a destination. It is a relative of the Bellman-Ford distant vector algorithm,
but is adapted to work in a mobile environment. Routes are maintained as long as they are
needed by the source. AODV is capable of both unicast and multicast routing.
In AODV every node maintains a table containing information about which direction to send
the packets in order to reach the destination.
Sequence numbers, which are one of the key features of AODV, ensures the freshness of
routes.
Control Messages
Three message types are defined by AODV:
RREQ When a route is not available for the desired destination, a route request packet is
flooded throughout the network. Figure 3.3 shows the format of such a packet.
RREP It a node either is, or has, a valid route to the destination, it unicasts a route reply
message back to the source.
RERR When a path breaks, the nodes on both sides of the link issues a route error to
inform their end nodes of the link break.
Sequence numbers
AODV differs from other on-demand routing protocols in that it uses sequence numbers to
determine an up-to-date path to a destination. Every entry in the routing table is associated
with a sequence number. The sequence numbers act as a route timestamp, ensuring the route
remains up-to-date. Upon receiving a RREQ packet, an intermediate node compares its
sequence number with the sequence number in the RREQ packet. If the sequence number
already registered is greater than that in the packet, the existing route is the most up-to-date.
Counting to infinity
The use of sequence numbers for every route also helps AODV avoid the count to infinity
problem. This problem arises in situations where nodes update each other in a loop. The core
of the problem, as Tanenbaum put it, is that when X tells Y that it has a path somewhere, Y
has no way of knowing whether it itself is on the path. So if Y detects that the link to, say, Z
is down, but X says it has a valid path, Y assumes X in fact does have a path, thus registering
X as the next neighbor toward Z. If the path X assumed is valid runs through Y, X and Y will
start updating each other in a loop.
Route discovery

15

Route discovery is initiated by issuing a RREQ message. The route is established when a
RREP message is received. However, multiple RREP messages may be received, each
suggesting different routes to the destination. The source only updates its path information if
the RREP holds information about a more up-to-date route than already registered. Thus,
every incoming RREP packet is examined to determine the most current route. When a
intermediate node receives either a RREQ or a RREP packet, information about the previous
node from which the packet was received is stored. This way, next time a packet following
that route is received, the node knows which node is the next hop toward the source or
destination, depending on which end node originated the packet.
Example of a Route Discovery
In this example, node A wants to send a packet to node F. Suppose A has no table entry for F.
A then needs to discover a route to F. In our example, we assume that neither of the nodes
knows where F is.
The discovery algorithm works like this:
Node A broadcasts a special ROUTE REQUEST packet on the network. The format of
the ROUTE REQUEST (RREQ) packet is shown in figure 3.3 on the preceding page. Upon
receiving the RREQ packet, B, C and E check to see if this RREQ packet is a duplicate, and
discards it if it is. If not, they proceed to check their tables for a valid route to F. If a valid
route is found, a ROUTE REPLY (RREP) packet is sent back to the source. In the case of the
destination sequence number in the table being less than the destination sequence number in
the RREQ, the route is not considered up-to-date, and thus no RREP packet is sent. Since
they dont know where F is, they increment the RREQ packets hop count, and rebroadcast it.
In order to construct a route back to the source in case of a reply, they also make an entry in
their reverse route tables containing As address. Now, D and G receive the RREQ. These go
through the same process as B, C and E. Finally, the RREQ reaches F, which builds an RREP
packet and unicasts it back to A.
The Expanding Ring search
Since RREQ packets are flooded throughout the network, this algorithm does not scale well
to large networks. If the destination node is located relatively near the source, issuing a
RREQ packet that potentially passes through every node in the network is wasteful. The
optimization AODV uses is the expanding ring search algorithm. The source node searches
successively larger areas until the destination node is found. This is done by incrementing the
time to live(TTL) value carried in every RREQ packet for every RREQ retransmission until a
route is found thus expanding the search ring in which the source is centered.
Link Breakage
When a link breaks, a RERR message is propagated to both the end nodes. This implies that
AODV does not repair broken links locally, but rather makes the end nodes discover alternate
routes to the source. Moreover, link breakage caused by the movement of end nodes also
results in initialization of a route discovery process. When an RERR packet is received by
intermediate nodes, their cached route entries are removed.

16

CHAPTER

RESEARCH METHODOLOGY

2.AD HOC ON-DEMAND DISTANCE VECTOR ROUTING (AODV)

Perkins and Royer developed the AODV routing protocol in 1999 [14,15]. 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 [5,7]. The intent 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
[14]. All routing protocols function at the network layer and the specific region is depicted in
Figure 2.1.

FIGURE 2.1 Protocol Stack for a MANET Node

The following discussion on AODV will focus on four major areas: route discovery, route
table management, path maintenance and local connectivity management as shown in figure
2.2

17

FIGURE 2.2 AODV Routing Protocol

2.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 broad casting a route request
(RREQ) packet to all of its neighbors[1,3]. Figure 2.3 illustrates a source node sending a
broadcast RREQ to destination 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 2.3 Initial Route Request from Node S to Node D

Figure 2.4 depicts the format of the RREQ. The type field indicates the type of traffic:
constant bit rate (CBR) or transmission control protocol (TCP). The reserved field is reserved
for future use. It is currently sent as 0 and ignored on reception. The hop count field indicates
the number of hops from the source IP address to the node handling the request. The
broadcast ID field indicates a unique sequence number identifying the particular request
when taken in conjunction with the source node's IP address. The destination IP address field
indicates the IP address of the destination for which a route is required. The destination
sequence number field indicates the last sequence number that has been received by the
source for any route towards the destination. The source IP address field indicates the IP
address of the node that originated the request. The source sequence number field indicates
the current sequence number for route information generated by the source of the route
request.

18

FIGURE 2.4 Route Request (RREQ) Format

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 as
shown in figure 2.5. If intermediate node receive multiple RREQ packet to same source to
destination node then intermediate node broadcast only first RREQ packet and drop other
redundant RREQ packet.

FIGURE 2.5 RREQ packet broadcast by Intermediate Node

When the RREQ packet reach to destination node then destination node generate RREP
packet. Then make a entry in their route table and unicast the RREP packet to that node from
where destination node receive RREQ packet.

FIGURE 2.6 Destination node unicast RREP packet to source node.

Figure 2.7 shows the format of the RREP. The type field indicates the type of traffic, CBR or
TCP. The 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.
The reserved field is reserved for future use. It is currently sent as 0 and ignored on reception.
The hop count field indicates the number of hops from the source IP address to the
destination IP address. The destination IP address field indicates the IP address of the
19

destination for which a route is supplied. The destination sequence number field indicates the
destination sequence number associated with the route. The lifetime field indicates the 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[8].

FIGURE 2.7 Route Reply (RREP) Format

2.2 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 2.8 depicts the
reverse path setup back to the 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[20].

20

Figure 2.8 Reverse Path Setup to Source Node S.

The reverse path entry is used to forward the RREP back to the source node if one is
received. The expiration time of the reverse path entries is long enough for a RREP to be
received and forwarded and is not a fixed value. Figure 2.9 is a portion of the C++ pseudo
code used for reverse path, setup resident within the Network Simulator 2 (NS2). The pseudo
code describes the process of creating and ensuring the reverse path setup (reverse route) is in
the routing table. Rt0depicts the reverse route and the process that the pseudo code checks to
ensure a valid route exists. If the route is not in route table, an entry is created for the reverse
route.

FIGURE 2.9 Portion of NS2 Pseudo code for the Reverse Path Setup

2.3 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. If an intermediate node receives a RREQ, it determines whether the route is
current by checking the destination sequence number in the RREQ and comparing it to its
21

own routing information concerning the destination node. The 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. Figure 2.10 is a portion
of the C++ pseudo code used for forward path setup resident within the Network Simulator 2
(NS2). The pseudo code describes the process of creating the forward path setup to ensure
that a valid route exists. The RREP contains five key pieces of information: source address,
destination address, destination sequence number, hop count and lifetime.

FIGURE 2.10 Portion of NS2 Pseudo code for the Forward Path Setup
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. As the
RREP traverses intermediate nodes, each node updates its route request expiration timer
information and records the most recent destination sequence number for the destination
node. The route request expiration timer information is used to remove reverse path route
entries for intermediate nodes that are not on the path from the source to the destination node.
This parameter depends on the actual size of the MANET.
Figure 2.11 depicts the forward path setup from the source node S to the destination node D.
Intermediate nodes that are not on the path, as determined by the RREP, will automatically
timeout and delete the reverse pointers. If an intermediate node receives a RREP with a better
metric, it updates its route entry and propagates this RREP towards the source node. If an
intermediate node receives a RREP without a better metric, it suppresses the RREP and
deletes it with no further propagation. The source node can begin transmitting data once it
22

receives the first RREP. Additionally, the source node can update its routing information if it
learns of a better route at any time.

Figure 2.11 Forward Path Setup from Source S to Destination D

2.4 ROUTE TABLE MANAGEMENT

Route table management determines whether a route is still active using four primary
parameters: source sequence numbers, destination sequence numbers, route request
expiration timer and route caching timeout. The first three parameters have previously been
defined. The route caching timeout is the time beyond which a route is no longer considered
to be valid. Each mobile node contains a route table entry with the following information:
destination, next hop, number of hops, sequence number for the destination, active neighbors
for this route and the expiration time for the route table entry. With this information, each
node can determine whether its neighbor is considered active for the particular destination.
The criterion for being active is determined if the neighbor originates or relays at least one
packet for a destination within the most recent active timeout period. This enables all active
source nodes to become informed if a link along a path to the destination fails or breaks. Each
time a route entry is used to transmit data, the expiration time is updated to the current time
plus the active route timeout.
Figure 2.16 is a simple illustration of four nodes communicating together and the associated
routing table each node maintains after the route discovery process. Route entries may be
updated if a route with a greater destination sequence number or a smaller hop count (number
of hops) to the destination node is discovered.

23

Figure 2.12Four Node Scenarios with Routing Table.

2.5PATH MAINTENANCE
Due to the movement of nodes throughout the network, path maintenance is used to ensure
that routes from the source to the specified destination are still valid. Prior to performing path
maintenance, AODV follows a specified criteria. The movement of a node, or nodes, not
along the active path, does not trigger path maintenance since these nodes do not affect the
routing to the specified destination. The movement of the source node does not trigger path
maintenance since the source node can reinitiate route discovery to establish a new route to
the specified destination. The movement of the specified destination or an intermediate node
does trigger path maintenance. When any of these nodes move, nodes upstream of the break
propagate unsolicited RREPs to all active upstream neighbors. The information provided
within the unsolicited RREP includes a fresh sequence number, one different from the
previously known sequence number, and a hop count of infinity. The nodes propagate the
unsolicited RREP until all the active sources receive the unsolicited RREP. The unsolicited
RREP terminates because AODV maintains only loop-free routes and the hop count of
infinity violates the number of nodes in the MANET.

FIGURE 2.13 Link Broken and RRER packet generation

The source node can reinitiate route discovery if a route to the destination is still required.
The source node propagates a new RREQ with a destination sequence number of one greater
than the last known destination sequence number. The new RREQ with a new destination
sequence number is required to ensure that a new route is created and that nodes will not
reply if they still regard the previous information valid to the specified destination. Figure
2.13, provides an illustration on path maintenance. The initial route shows node J moving to a
24

new location J'. Node F, upstream of node J, notices the loss of the link and sends an
unsolicited RREP to node E. Node E forwards this unsolicited RREP to the source node S.
The source node S reinitiates route discovery and finds a new route through node K to the
destination node D. Figure 2.14 is a portion of the C++ pseudo code used for path
maintenance (unsolicited RREP) resident within NS2. The pseudo code describes the process
of broadcasting an unsolicited RREP to the upstream neighbors. In this case, the pseudo code
must also include purging the network interface queues that may have packets destined for
this broken neighbor. Once the upstream neighbors are notified, the source node is informed
of the break. If a node is the source of the packet, it will queue this packet and send a RREQ.
Otherwise, the node will drop the packet: nothing is salvaged by an intermediate node.

FIGURE 2.14 Path Maintenance Setup from Source S to Destination D

FIGURE 2.15 Portion of NS2 Pseudo code for Path Maintenance (unsolicited RREP)

25

2.6 LOCAL CONNECTIVITY MANAGEMENT

Nodes use the local connectivity management to learn who their active neighbors are and to
know if these neighbors are still in range of communication. There are two methods by which
a node can gather information concerning its active neighbor, reception of a broadcast or a
hello message. A broadcast message, RREP or RREQ, is propagated throughout the system in
determining a route to the specified destination. Nodes that receive this broadcast message
update their local connectivity information to include this new neighbor. A node that has not
sent any packets to all of its active downstream neighbors within a hello_interval propagates
a hello message. A hello message is a special unsolicited RREP and contains information
concerning its identity and sequence number. A node that receives a hello message does not
update or change its own sequence number, rather the neighboring nodes update their local
connectivity information to include this new neighbor. Figure 2.15 is a portion of the C++
pseudo code used for local connectivity (adding new neighbors) resident within NS2. The
pseudo code describes the process that the node will use to check its current list of neighbors
and to update its list of neighbors when a change of neighbors is discovered. Either a new
neighbor is added to the list, or a known neighbor is no longer reachable and subsequently
deleted from the list. Its immediate neighbors only receive the hello message, and the

FIGURE 2.16 Portion of NS2 Pseudo code for Local Connectivity

Hello message is not propagated throughout the network because its time to live (TTL) value
is set to one. Nodes verify that routes are used only from neighbors that have received the
node's hello message. Since nodes must hear from active neighbors periodically, failure to
receive a hello message indicates a node is out of range and removed from the node's local
connectivity.

26

2.7 AODV ALGORITHM STEP

Step1. Source node send route request packet to its neighbor nodes.
Step2. Node receive RREQ, if it is not destination then broadcast RREQ and increment hop
count value.
Step3. If it is redundant RREQ, then ignore or drop these packet.
Step4. If node is destination node then..
Step5. Node generate and send RREP (unicast)
Step6. If it is not in table, then create an entry for route-reply.
Step7. If it is fresher seq. no. or less hop count value then update route table.
Step8. Else dont bother.
Step9. If node is not destination, then forward the RREP packet.
Step 10. After receiving RREP, Source node start data transmission.

SUMMARY
Chapter II has presented the AODV protocol and the procedures through which it establishes
a route, maintains a route, adjusts to the movement of nodes into and out of the network, and
manages the routing table and the local connectivity. AODV is a hybrid of DSR and DSDV.
From DSR, AODV incorporates a broadcast discovery mechanism, and from DSDV it
incorporates the most recent routing information between nodes.
AODV minimizes the network load for control and data traffic, is responsive to topology
changes, is capable of adjusting to changes in topology, and ensures loop-free routing even
while repairing broken links.

27

CHAPTER

R-AODV & PHR-AODV

3.1 R-AODV (Reverse AODV)

Analyzing previous protocols, we can say that most of on-demand routing protocols, except
multipath routing, uses single route reply along the first reverse path to establish routing path.
As we mentioned before, in high mobility, pre-decided reverse path can be disconnected and
route reply message from destination to source can be missed. In this case, source node needs
to retransmit route request message. Purpose of our study is to increase possibility of
establishing routing path with less RREQ messages than other protocols have on topology
change by nodes mobility.
Specifically, the proposed R-AODV protocol discovers routes on-demand using a reverse
route discovery procedure. During route discovery procedure source node and destination
node plays same role from the point of sending control messages. Thus, after receiving
RREQ message, destination node floods reverse request (R-RREQ), to find source node.
When source node receives an R-RREQ message, data packet transmission is started
immediately.

FIGURE 3.1 Source node initiate Route Discovery and send RREQ packet

3.1.1 Route Discovery in R-AODV

Since R-AODV is reactive routing protocol, no permanent routes are stored in nodes. The
source node initiates route discovery procedure by broadcasting. The RREQ message
contains following information (Figure 3.2): message type, source address, destination
address, broadcast ID, hop count, source sequence number, destination sequence number,
request time (timestamp).

28

FIGURE 3.2 RREQ Message Format

Whenever the source node issues a new RREQ, the broadcast ID is incremented by one.
Thus, the source and destination addresses, together with the broadcast ID, uniquely identify
this RREQ packet [1, 9]. The source node broadcasts the RREQ to all nodes within its
transmission range. These neighboring nodes will then pass on the RREQ to other nodes in
the same manner. As the RREQ is broadcasted in the whole network, some nodes may
receive several copies of the same RREQ. When an intermediate node receives a RREQ, the
node checks if already received a RREQ with the same broadcast id and source address. The
node cashes broadcast id and source address for first time and drops redundant RREQ
messages. The procedure is the same with the RREQ of AODV. When the destination node
receives first route request message, it generates so called reverse request (R-RREQ) message
and broadcasts it to neighbor nodes within transmission range like the RREQ of source node
does.

FIGURE 3.3 R-RREQ from Destination to Source Node

29

Lets see the same case of AODV, we have mentioned above, in figure 3.3. In RAODV,
destination does not unicast reply along pre-decided shortest reverse path D->3->2->1->S.
Rather, it floods R-RREQ to find source node S. And forwarding path to destination is built
through this R-RREQ. Following paths might be built:
S->4->5->6->D, S->11->10->9->8->7->D, and etc. Node S can choose best one of these
paths and start forwarding data packet. So RREP delivery fail problem on AODV does not
occur in this case, even though node 1 moves from transmission range.
R-RREQ message (Figure 3.4) contains following information: reply source id, reply
destination id, reply broadcast id, hop count, destination sequence number, reply time
(timestamp).
When broadcasted R-RREQ message arrives to intermediate node, it will check for
redundancy. If it already received the same message, the message is dropped, otherwise
forwards to next nodes.

FIGURE 3.4 R-RREQ Message Format

Furthermore, node stores or updates following information of routing table:
Destination Node Address
Source Node Address
Hops up to destination
Destination Sequence Number
Route expiration time and next hop to destination node.
And whenever the original source node receives first R-RREQ message it starts packet
transmission, and late arrived R-RREQs are saved for future use. The alternative paths can be
used when the primary path fails communications.

3.1.2 Route Update and Maintenance

When control packets are received, the source node chooses the best path to update, i.e. first
the node compares sequence numbers, and higher sequence numbers mean recent routes. If
sequence numbers are same, then compares number of hops up to destination, routing path
with fewer hops is selected. Since the wireless channel quality is time varying, the best path
varies over time.
The feedback from the MAC layer can be used to detect the connectivity of the link. When a
node notifies that its downstream node is out of its transmission range, the node generates a
route error (RERR) to its upstream node. If fail occurs closer to destination node, RRER
received nodes can try local-repair, otherwise the nodes forward RRER until it reaches the
source node [1,2]. The source node can select alternative route or trigger a new route
discovery procedure.

30

3.1.2.1 Control Packet Overhead

Intuitively, we can say that R-AODV causes a lot of control packet overhead. However, we
can prove that route discovery procedure based on single reply message may cause even more
packet overhead for some cases. We define the followings:
An ad hoc network has N number of nodes
Required number of control messages to discover routing path for AODV is
AODV(N)
Required number of control messages to discover routing path for R-AODV is
RAODV(N).
Lets say m nodes participate to discover a routing path. Then AODV obtains a routing path
using control message shown in (1), if it does not fail in first try.
AODV(m)= (m1+ t) ,
(1)
Where t is the number of nodes relied on route reply message.
If source node fails in first try, because route reply message could not arrive, the node reinitiates path discovery, the number of control messages increase by the number of tries
expressed in function (2).
AODV(m)= (m-1+t)
(2)
Where c is the number of tries for route discovery.
When we assume that R-AODV has at least one stable path by a RREQ, then the number of
control messages for R-AODV is in function (3). It will require only 2m-2
messages for route discovery.
RAODV(m) = (2m 2) .
(3)
So we can conclude when c>1, then AODV causes more packet overhead than the case of
c=1 on R-AODV routing.

3.1.3 REVERSE AODV ALGORITHM STEP

Route Request from source to destination is same as AODV algorithm.
When first RREQ packet reach to destination.
Step1. Destination node send R-RREQ packet to its neighbor node.
Step2. If node receive R-RREQ packet ,and it is not source node then it forward to their
neighbor node.
Step3. After receiving first R-RREQ, source node start data transmission.
Step4. Source node store other R-RREQ for future use.

3.2 PHR-AODV (Path Hopping Based Reverse AODV)

A mobile ad hoc network is a dynamically self-organizing network without any central
administrator or infrastructure support. If two nodes are not within the transmission range of
each other, other nodes are needed to serve as intermediate routers for the communication
between the two nodes [1, 2]. Moreover, mobile devices wander autonomously and
communicate via temporary links in such an ad hoc wireless net-work.
In ad hoc wireless networks several multipath routing approaches [2, 6, 8, 15, 17] has been
studied recently. SMR [6], which is an extension of DSR hence uses similar route discovery
method as in DSR, builds multiple paths by forwarding duplicate RREQs having different
incoming link than the first RREQ. However, most routing protocols use a single path
intensively. Exhaustive utilization of single path causes high traffic load and fast energy
31

consumption of nodes on the active path. Further-more, using a single path lets malicious
nodes to intrude secret information, violating network confidentiality. Hopping paths may
help to balance the energy consumption and distribute traffic load across network. Also,
distribution of traffic loads helps to decrease transmission delay.
In this study we propose path-hopping routing based on reverse AODV. In R-AODV, which is
an easy multipath searching method, the destination node uses re-verse RREQ to find the
source node rather than a unicast reply. It reduces path fail correction messages and also
source node builds partial or complete non-disjoint multipath from source to destination.
Hopping paths means source node sends each data packet through different paths each time,
therefore traffic is well distributed among paths and intrusion of malicious node effect to
network become weaker.

3.2.1 Disjoint Paths in Multipath Routing

An important point of multipath routing is disjointness of paths. Several studies proposed
various types of disjoint paths, such as [2], [6] and [8]. Generally multipath can be classified
in three categories (Figure 3.4): node-disjoint (complete disjoint), link disjoint, non-disjoint

FIGURE 3.5 Classification of Multipath

Our proposed path-hopping routing (PHR) builds complete or partial node-disjoint according
to topology. Figure 3.5 is an example of partial node-disjoint. In PHR number of paths equals
to source nodes edges[25.26].

32

FIGURE 3.6 Example of Partial Node- Disjoint

As an advantage of node-disjoint path show that node participates only once in multi-paths.
However, partial node-disjoint paths are also very useful to distribute energy consumption
and traffic load as well as avoiding malicious node intrusion. As you can see in figure 2, only
nodes 7 and 8 participate more than once.
In this section we present an overview and practical protocol of proposed path-hopping
method, called path-hopping routing based on reverse AODV (PHR). In PHR the number of
paths from one source to destination is decided as the number of edges from source node.

3.2.2Overview of PHR-AODV
Analyzing previous protocols, we can say that most of on-demand routing protocols based on
unicast route reply along a reverse path to establish a routing path and use complex methods
to build multipath. Our proposed method distinguishes due to its simplicity of building
multipath.
Purpose of our study is to distribute energy and traffic load among multi-paths, and
strengthen security of routing while decreasing possible intrusions of malicious nodes. The
proposed PHR protocol discovers routes using a reverse route discovery procedure of R-AOV
[3]. After receiving RREQ message, the destination node floods reverse request (R-RREQ) to
find the source node. When source node receives R-RREQ messages, the number of
messages becomes the path numbers.

3.2.3 Route Discovery of PHR-AODV

Since PHR is reactive routing protocol, no permanent routes are stored in nodes. A source
node initiates route discovery procedure by broadcasting the RREQ message which contains
information like message type, source address, destination address, broadcast ID, hop count,
source sequence number, destination sequence number, request time (timestamp) [2].

33

The source node broadcasts the RREQ to all nodes within its transmission range. These
neighboring nodes will then pass on the RREQ to other nodes in the same manner as AODV
does [4].

FIGURE 3.7Initial Route Request from Node S to Node D

The RREQ packet format is same as R-AODV RREQ packet. RREQ packet traversal is also
same as R-AODV.
When the destination node receives first route request message, it generates so called reverse
request (R-RREQ) message and broadcasts towards the source. R-RREQ message contains
following information: reply source id, reply destination id, reply broadcast id, hop count,
destination sequence number, reply time (timestamp).

FIGURE 3.8 R-RREQ from Destination to Source Node

When broadcasted R-RREQ message arrives to an intermediate node, it does the same
procedure of RREQ of R- AODV as shown in figure 3.3
Furthermore, the node stores or updates following information of routing table:

Destination Node Address

Source Node Address
Hops up to destination
Destination Sequence Number
Route expiration time and
Next hop to destination node.
34

Figure 3.9Multipath Discovery Process: complete node-disjoint paths

By receiving R-RREQ messages the source node simply builds partial node-disjoint
multipath and sends messages over paths by hopping one by one. The order of path selection
can vary. We just use FCFS in this study.

FIGURE 3.10 PHR ROUTING

In figure 3.10 we see there are three available path from source node S to destination node D.
Path 1, S-> 1-> 4-> D, Path 2, S-> 2->5->7-> D, and last path is S->3->6->8->D.
Then source node arrange into ascending order of their hop count value. And start data
transmission to all available path.

35

During the communication failed paths are eliminated from the path list, and continue the
transmission with available route to destination. When no path remains in a routing table the
source node re-initiates RREQ for establishing new multipath.

3.2.4 PHR-AODV ALGORITHM STEP

In PHR-AODV route request process is same as R-AODV.
Step1. The source node receives R-RREQ packet from its neighbor nodes, it simply builds
partial node disjoint paths.
Step2. Source node stores multiple route reply and arrange into ascending order of their hopcount value.
Step3. Source node sends each data packet through different paths each time, therefore traffic
is well distributed among paths.

3.2.5 Path-hopping Effect on Routing Load and Security

In mobile ad hoc network routing paths fail due to several reasons and most failures occur by
lack of energy, high traffic load or out of transmission range. To make routes live longer
several approaches has been used. Path-hopping multipath is also one of solution for these
problems. Ad hoc path-hopping routing uses paths one by one - not exhaustively. Therefore it
can be effective to distribute routing load and to protect data from malicious node intrusion.

FIGURE 3.11Path-hopping routing

Figure 3.10 shows three paths from source to destination. When we use AODV protocol only
one path S->1->4->D will be used. PHR uses three paths S->1->4->D, S->3->6->8->D, S>2->5->7->D to deliver data packets. Traffic load and energy consumption will be divided by
number of paths. Lower traffic load means lower transmission delay and lower probability of
congestion. We can express average energy consumption of nodes on active paths for two
protocols:

E(PHR) = D/Pn(Tx+Rx) E(AODV) = D(Tx+Rx)(1)

36

Where E is average consumed energy for sending an amount of data, Dis total packets,
Txand Rx is amount of energy required to transmit and to receive a packet, Pn is number of
paths (multi-paths).
Lets assume node 1 is a malicious node. How can this influence on two protocols. Node
intrusion for AODV case will be 100% due to single path. On AODV intrusion of malicious
nodes may cause serious impairment to the security. Node intrusion for PHR will be 33%.
Therefore, we can conclude that more paths reduce malicious node intrusion to network.
Lets assume some parameters: Np is he number of nodes in routing paths, Nall is the number
of all nodes in network, M is the number of malicious nodes, S is the number of paths from a
source to a destination, Pm is probability of active malicious nodes.

(2)
Therefore, we can calculate Pi, malicious node intrusion rate, as follows

(3)

Malicious Node Intruscion Rate varying number of Nodes

0.7
0.6
0.5

10% Pm

0.4

20% Pm

Intrusion Rate 0.3

40% Pm

0.2
0.1
0
20

30

40

50

Number of Nodes

FIGURE 3.12 Malicious Node Intrusion Rate varying number of Nodes

37

CHAPTER

SIMULATION
The Simulation software used in this thesis was NS2, Version 2.1b6 on a Linux platform.
Perkins and Royer's AODV NS2 implementation, originally developed in a Parallel
Simulation Environment for Complex Systems (PARSEC) environment and later converted
to work in UNIX, LINUX and Windows environments, was one of four MANET protocols
available at the time of this work. The other three MANET protocols available are DSR,
DSDV and the Temporally Ordered Routing Algorithm (TORA). The NS2 package was
chosen for this MANET protocol research due to its availability as freeware on the Internet
from the University of California (UCB) at Berkeley and because of the numerous MANET
routing protocols available for evaluation. Other popular simulation software packages used
for MANET protocol simulation include Optimum Network Performance (OPNET),
PARSEC, and the C++ programming language.

4.1 NETWORK SIMULATOR 2 (NS2)

NS2 version 2.1b6 was created by the Virtual Inter Network Test based (VTNT) project
funded by the Defense Advanced Research Projects Agency (DARPA). The VINT project is a
collaborative project that includes the University of California (UCB) at Berkeley, University
Southern California (USC)/Information Sciences Institute (1ST), Xerox Palo Alto Research
Center (PARC) and the Lawrence Berkeley National Laboratory (LBNL). The purpose of this
project is to build a network simulator that will allow the study of scale and protocol
interaction in the context of current and future network protocols. The simulator is written in
the C++ programming language and the Object Tool Command Language (OTCL). The user
writes an OTCL script that defines the mobile nodes in the network, the traffic in the network
and the routing protocol. The Tool Command Language (TCL) script is also created by the
user that contains the files generated in OTCL and called by the simulator. Appendix A
contains one example of the TCL script files generated by the user, and Appendix B contains
an output trace file used in the simulation. The OTCL script is used by NS2 to perform the
simulation. The result of the simulations is an output trace file that is used for further data
processing (parsing) and to visualize the simulation with a resident program tool in NS2
called the Network Animator (NAM).
Figure 4.1 depicts an overview of how a simulation is performed in NS2 from the user input,
in the OTCL script, to data processing [18]. The user creates node movement and traffic
generation files. A TCL script is used to bridge the OTCL script created by the user with the
C++ code resident in the NS2 simulator to perform the simulation. 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. The output trace file is parsed using a perl script, and the
results of the data processing are analyzed in MATLAB.

38

FIGURE 4.1 Overview of NS2

4.2 PHR-AODV MODEL

The PHR-AODV NS2 model contains two different levels of software programming. The
user level in OTCL, and the specific PHR-AODV model resident in the simulator in the C++
programming language. The user level in OTCL is implemented by generating a mobile node
movement file, generating a traffic pattern file and designating a routing protocol. Each
specific user file generation will be discussed in further detail in the following sections. The
user has flexibility in changing various parameters for each simulation in NS2. For node
movement, these variables include: the number of nodes in the network (-n), the pause time
in between node movements (-p), the maximum speed of each node in meters per second (-s),
the total simulation time in seconds (-t), the boundary in the x axis in meters (-x) and the
boundary in the y axis in meters (-y). For the traffic pattern, these variables include: the type
of traffic (-type, Transmission Control Protocol (TCP) or Constant Bit Rate (CBR)), total
number of nodes in the network (-nn), the maximum number of connections set up between
them in the network (-mc) and the rate of packet distribution in packets per second (-rate).
Figure 4.2 depicts the PHR-AODV design for NS2 in the two software programming levels.
The functions below the OTCL level are resident within NS2 and are written in the C++
programming language. The functions at this level are the default parameters of the PHRAODV model itself and are not normally modified by the user. The major functions are the
PHR-AODV agent, Hdr-PHR-AODV, Request Buffer, PHR-AODV Rtableand PHR-AODV
constants. The PHR-AODV agent handles the various RREQ, RREP, hello, and unsolicited
RREP messages. It also has a send buffer that buffers packets during route discovery, and the
timers that maintain timeouts for route entries and the send buffer are implemented in this
function. The PHR-AODV header (HdrPHR-AODV) defines the specific message format for
the various messages in PHR-AODV. The Request Buffer ensures a node does not process the
same RREQ numerous times and stores processed requests. The PHR-AODV route table
(PHR-AODV Rtable) maintains and updates the routes and implements the active neighbor
list for each route entry. The PHR-AODV constants contains all the defined constants within
the PHR-AODV model that include: hello interval, active route timeout, route reply lifetime,
allowed hello loss, request retries, time between retransmitted requests, time to hold packets
awaiting routes and maximum rate of sending replies for a route.

39

PHR-AODV
OTCL

PHR-AODV_AGENT

HdrPHR-AODV

PHR-AODV
RTable

Request
Buffer

C++

PHR-AODV
Constant

FIGURE 4.2 PHR-AODV Design of Implementation for NS2

4.3 MOBILE NODE MOVEMENT

Each mobile node movement makes use of a routing agent for the purpose of calculating
routes to other nodes within the MANET. Figure 4.3 depicts the mobile node mechanism and
implementation in NS2. Packets are sent from the application and are received by the routing
agent. The agent determines a path that the packet must travel to reach the destination and
stamps it with this information. The packet is then sent down to the link layer. The link layer
uses an Address Resolution Protocol (ARP) to determine the hardware addresses of
neighboring nodes and map IP addresses to the correct interfaces for dissemination. When the
information is known, the packet is sent down to the interface queue and awaits a signal from
the Medium Access Control (MAC) protocol. When the MAC layer determines that it can
send a packet onto the channel, it grabs the packet from the queue and moves it over to the
network interface. The network interface sends the packet onto the radio channel. The packet
is copied and delivered to all network interfaces at the time that the first bit of the packet
would begin arriving at the interface in a physical system. Each network interface stamps the
packet with the receiving interface information and then invokes the propagation model. The
propagation model uses the transmit and receive stamps to determine the receive power for
the interface[27,29].
The above procedure is then reversed on the receiving network. This process happens within
NS2 as information is being disseminated. As previously mentioned, the user creates a
specific node movement with certain parameters. These parameters include: the number of
nodes in the network (-n), the pause time in between node movements (-p), the maximum
speed of each node in meters per second (-s), the total simulation time in seconds (-t), the
boundary in the x axis in meters (-x) and the boundary in the y axis in meters (-y). The shaded
line below depicts the command line input for the generation of mobile node movement file
in NS2 with an associated file for
this input created by the user. Appendix C contains a node movement file generated by the
user in the simulation

./ setdest-n50-p 500-s 1.78-t600-xl500-y 300 > scen50-vell.78-ty

40

FIGURE 4.3A Mobile Node in NS2

4.4 TRAFFIC PATTERN GENERATION

The creation of the random traffic pattern can be established between mobile nodes using a
traffic scenario generator script. Either constant bit rate (CBR) or transmission control
protocol (TCP) traffic connections can be created. The models used in this thesis contained
only CBR connections. A generic CBR generation file is resident (cbrgen.tcl) in NS2 and is
called by the user in the creation of a user specific traffic pattern file. Each traffic pattern file
generated is unique. The user is able to generate a specific traffic connection using the CBR
generation file and set certain variables. These variables include: the type of traffic {-type,
TCP or CBR), total number of nodes in the network (-nn), the maximum number of
connections setup between them in the network (~mc) and the rate of packet distribution in
packets per second (-rate). The shaded line below depicts the command line input for the
generation of the CBR traffic pattern in NS2 with an associated file for this input created by
the user.

Nscbrgen.tcl -type cbr -nn 50 -seed 1.0 -mc 20 -rate 4.0 > cbr-50-rate4-ty

4.5 STATISTICS PRODUCTION

The completion of all simulations in NS2 generates an output trace file. NS2 has no resident
statistic production capability as is available in OPNET. Each output trace file is parsed using
either an awkor perl script command to collect specific data from the output file for analysis.
The output trace files generated by the simulation can exceed several gigabytes of storage
capacity; therefore, only a maximum of 20-30 active connections were used. For example, the
41

calculation for each statistic, packet fraction delay, throughput, etc., is parsed from the output
file using a perl script then dumped into NS2 to organize and produce results for analysis.
Appendix B contains an output trace file generated in the simulation.

SUMMARY
This chapter has provided an introduction of the implementation of NS2 version 2.34 and has
presented the AODV model. NS2 maintains resident features of the AODV model in C++,
and the user is able to generate a specific node movement, traffic pattern and routing protocol
in the OTCL/TCL script. The mobile nodes are modeled to work in a MANET environment
and are executed through a mobile node mechanism as depicted in Figure 4.3. The user has
the ability to change numerous parameters for the mobile node movement and the traffic
pattern. Statistics were collected on each simulation through parsing of the output file then
analyzed in NS2.

42

CHAPTER

RESULTS ANALYSIS
This section explained the simulation model and their performance metrics. This also
describes the results which are analyzed from the simulation.

5.1 SIMULATION MODEL

In this section, the network simulator-2 is used. It supports for simulating a multi-hop
wireless ad-hoc environment completed with physical, data link and medium access control
layer models. The table 5.1 shows the simulation parameter.
Simulation Time

100 Sec

Routing protocols

AODV, R-AODV,PHR-AODV

Area of Terrain

1500*1500

Number of nodes

20,30,40,50,60

Type of Traffic

TCP,UDP

Size of Packet

512 byte

MAC Type

IEEE 802.11

Transmission Range

250 meter

Transmission rate

4Packet/Sec

Antenna Type

Omni Antenna

Propagation Type

Two Ray Ground

Queue Type

Queue/ DropTail/ PriQueue

Queue Length

50

Mobility Model

Random way Point

TABLE 5.1 SIMULATION PARAMETERS

43

5.2 RESULT ANALYSIS

Result analysis is important for system that tells us about performance of system and their
efficiency. Here we consider three kinds of performance metrics, these are given below.
1. Throughput
2. End to End Delay
3. Packet Delivery Ratio
THROUGHPUT
Throughput is the rate of production or the rate at which something can be processed. When
used in the context of communication networks, such as Ethernet or packet radio, throughput
or network throughput is the rate of successful message delivery over a communication
channel. The data these messages belong to may be delivered over a physical or logical link
or it can pass through a certain network node. Throughput is usually measured in bits per
second (bit/s or bps), and sometimes in data packets per second (p/s or pps) or data packets
per time slot.
Transmission Time= File Size / Bandwidth (Sec)
Throughput= File Size / Transmission Time (bps)
END TO END DELAY
End-to-end delay or one-way delay refers to the time taken for a packet to be transmitted
across a network from source to destination.
(Arrival Time-Send Time)
End to End Delay= ----------------------------------- Number of Connection
PACKET DELIVERY RATIO
PDR is the ratio of the number of delivered data packet to the destination. This illustrates the level of
delivered data to the destination.

PDR=

Number of packet receive / Number of packet send

In our thesis we use AODV, R-AODV and PHR-AODV routing protocol and analysis the
performance of protocol and compare the result in terms of throughput, end to end delay and
packet delivery ratio. Performance analysis computes for 20,30,40,50and 60 nodes. In NS2
we perform computation using trace files and awk programs.

44

CONTROL OVERHEAD PACKETS

It is the sum of all control packets transmitted/received during route
discovery and route maintenance.
INTRUSION RATE
It is the percentage of intrusion instances present in the test set.

5.3 Results and Discussions

The packet delivery fraction and average end-to-end delay of R-AODV characterization are
shown in figure 5.1 and 5.2. It is very obvious that above two factors improved as compared
to other two protocols due to R-AODV utilizes multiple recent routes at the source node
which are fresh enough. Also the routing overhead of R-AODV is much larger than AODV
which is clearly shown in figure 5 because R-AODV broadcasts route reply packets whereas
it is unicasted in AODV.

PDR Vs Number of Nodes(TCP Connection)

120
100
80
Packet Delivery Ratio(%)

TCP- AODV
TCP-R-AODV
TCP-PHR-AODV

60
40
20
0
20 30 40 50 60
Number of Nodes

FIGURE 5.1 PDR Vs Number of Nodes (with TCP Connection)

45

PDR Vs Number of Nodes(UDP Connection)

100
80
UDP-AODV
UDP-R-AODV
UDP-PHR-AODV

60
Packet Delivery Ratio(%)

40
20
0
20 30 40 50 60
Number of Nodes

FIGURE 5.2 PDR Vs Number of Nodes (with UDP Connection)

End to End Delay Vs Number of Nodes(TCP Connection)

800
700
600
500
400
End to End Delay (ms)
300
200
100
0
20 30 40 50 60

TCP-AODV
TCP-R-AODV
TCP-PHR-AODV

Number of Nodes

FIGURE 5.3 End to End Delay Vs Number of Nodes (with TCP Connection)

46

End to End Delay Vs Number of Nodes(UDP Connection)

700
600
500

UDP-AODV
UDP-R-AODV
UDP-PHR-AODV

400
End to End Delay (ms) 300
200
100
0
20 30 40 50 60
Number of Nodes

FIGURE 5.4 End to End Delay Vs Number of Nodes (with UDP Connection)

Control Overhead Vs Number of Nodes(TCP Connection)

50000
40000
30000
Control Overhead Packets 20000

TCP-AODV
TCP-R-AODV
TCP-PHR-AODV

10000
0
2030405060
Number of Nodes

FIGURE 5.5 Control Overhead Vs Number of Nodes (with TCP Connection)

47

Control Overhead Vs Number of Nodes(UDP Connection)

50000
40000
UDP-AODV
UDP-R-AODV
UDP-PHR-AODV

30000
Control Overhead packets

20000
10000
0
20 30 40 50 60
Number of Nodes

FIGURE 5.6 Control Overhead Vs Number of Nodes (with UDP Connection)

Aggregate PDR Vs Routing Protocol

80
70
60
TCP
UDP

50
40
30
20
10
0
AODV

R-AODV

PHR-AODV

FIGURE 5.7 Aggregate PDR Vs Routing Protocols

48

Aggregate Delay Vs Routing Protocol

600
500
400

TCP
UDP

300
200
100
0
AODV

R-AODV

PHR-AODV

FIGURE 5.8 Aggregate Delay Vs Routing Protocols

Aggregate Control Overhead Vs Routing Protocol

25000
20000
TCP
UDP

15000
10000
5000
0
AODV

R-AODV

PHR-AODV

`FIGURE 5.9 Aggregate Control Overhead Vs Routing Protocols

49

In terms of PDR(Packet Delivery Ratio), R-AODV with TCP connection perform better than
AODV and PHR-AODV.
In terms of End to End Delay, R-AODV with TCP connection have less delay than AODV
and PHR-AODV.
In terms of Control Overhead, AODV with UDP connection have less overhead than RAODV and PHR-AODV with TCP and UDP connection.
PERFORMNCE

AODV

R-AODV

PHR-AODV

PDR

LOW

HIGH

MEDIUM

DELAY

HIGH

LOW

MEDIUM

CONTROL

LOW

HIGH

MEDIUM

METRICES

OVERHEAD
TABLE 5.2 Comparison of Routing Protocol

CHAPTER
50

CONCLUSION AND FUTURE SCOPE

Conclusion
Most on demand routing protocols for Ad hoc networks concentrate on the single path from a
source to a destination. Exhaustive use of a single path increases unbalance of traffic load and
intensively consumes energy of the nodes on the path. Therefore, distributing traffic load and
energy demand amongst all of the nodes of network is an important issue on Ad hoc
networks. Distributing energy demand not only means that energy is reduced for whole
network on average but also implies no node is depleted of energy. In this study, we analyse
the performance of a path-hopping routing based on reverse AODV (R-AODV). In contrast to
the standard AODV routing, R-AODV uses a reverse request rather than AODVs unicast
route reply. R-AODV therefore builds multi-path map to the destination and then adaptively
hops available paths for communications. Hopping paths can also protect data from the
intrusion by malicious nodes[17]. We implement the simulation model of proposed pathhopping routing using NS-2. Simulation results show benefits of the path hopping routing on
distribution of power consumption and increased security. Increasing of control packet
overhead and slightly decreasing of data delivery rate are disadvantages of path hopping. It
can also be seen that in case of PHR-AODV, the intrusion rate of malicious nodes decreases
with increase in number of nodes.
Future Scope
In future we will add other algorithm for detection and prevention of malicious node. We can
also modified PHR-AODV for better packet delivery ratio and low control packet overhead.

REFERENCES
51

[1] C. Perkins, E. Belding-Royer Ad hoc on-Demand Distance Vector (AODV) Routing, RFC
3561, July 2003.
[2]Chonggun Kim, ElmurodTalipov, and ByoungchulAhn, A Reverse AODV Routing
Protocol in Ad Hoc Mobile Networks , LNCS 4097, pp. 522 531, 2006.
[3] C. K.-L. Lee, X.-H.Lin, and Y.-K. Kwok, A Multipath Ad Hoc Routing Approach to
Combat Wireless Link Insecurity, Proc. ICC 2003, vol. 1, pp. 448452, May 2003.
[4] S.-J. Lee and M. Gerla, Split Multipath Routing with Maximally Disjoint Paths in Ad
HocNetworks, Proc. ICC 2001, vol. 10, pp. 32013205, June 2001.
[5] M. K. Marina and S. R. Das On-Demand Multi Path Distance Vector Routing in Ad Hoc
Networks, Proc. ICNP 2001, pp. 14 23, Nov. 2001.
[6] NS, The UCB/LBNL/VINT Network Simulator (NS), http://www.isi.edu/nsnam/ns/,
2004.
[7]Zhi Li and Yu-Kwong Kwok, A New Multipath Routing Approach to Enhancing TCP
Security in Ad Hoc Wireless Networks in Proc. ICPPW 2005. [1] Elizabeth M. Royer and
Chai-KeongToh, "A Review of Current Routing Protocols for Ad Hoc Mobile Wireless
Networks," IEEE Personal Communications, Vol. 6, No. 2, pp. 46-55, April 1999.
[8] C.E. Perkins and E. M. Royer, Ad hoc on-demand distance vector routing in Proc.
WMCSA New Orleans, LA, pp. 90100, Feb. 1999.
[9] M. K. Marina and S. R. Das On-Demand Multi Path Distance Vector Routing in Ad Hoc
Networks in Proc. ICNP 2001, pp. 14 23, Nov. 2001.
[10] A. Nasipuri and S. R. Das, On-Demand Multipath Routing for Mobile Ad Hoc
Networks Proc. ICCN 1999, pp. 6470, Oct. 1999.
[11]Tarique, M., Tepe, E., SasanAdibi, and ShervinErfani, Survey of multipath routing
protocols for Mobile Ad-hoc networks, Journal of Network and Computer Applications,
32:1125-1143, 2009.
[12]Chonggun Kim, ElmurodTalipov and ByoungchulAhn, "A Reverse AODV Routing
Protocol in Ad Hoc Mobile Networks," LNCS 4097, pp. 522-531, 2006.International Journal
of Wireless & Mobile Networks (IJWMN) Vol. 6, No. 5, October 2014.
[13]Pravanjan Das and Upena D Dalal, A Comparative Analysis of AODV and R- AODV
Routing Protocols in MANETS, International Journal of Computer Applications 72(21):1-5,
June 2013.
[14]KhafaeiTaleb and KhafaieBehzad, The Effect of Number of Hops per Path on Remind
Energy in MANETs Routing Protocols, International Journal of Computer Applications vol.
43, no. 24, pp. 23-28, April 2012.
[15]HumairaNishat, Vamsi Krishna K, D.SrinivasaRao and Shakeel Ahmed, Performance
Evaluation of On-Demand Routing Protocols AODV and Modified AODV (R-AODV) in
52

MANETS, International Journal of Distributed and Parallel Systems, vol. 2, no. 1, January
2011.
[16]Talipov, Elmurod, Donxue Jin, Jaeyoun Jung, Ilkhyu Ha, YoungJun Choi, and Chonggun
Kim. "Path hopping based on reverse AODV for security." Management of Convergence
Networks and Services, pp. 574-577. Springer Berlin Heidelberg, 2006.
[17] The Network Simulator NS-2, available at http://www.isi.edu/nsnam/ns, 2004.
[18] Anumeha and BhawnaMallick. Enhancing the Performance ofAODV Protocol,
International Journal of Advanced Technologyin Engineering and Science, vol. 3, pp. 110117, Aug. 2015.
[19] Ashraf Abu-Ein and Jihad Nader.An Enhanced AODV routing Protocol for MANETs,
International Journal of Computer Science, vol. 11, pp. 54-58, Jan. 2014.
[20]Loganathan and Ramamoorthy. Performance Analysis is Enhanced AODV Protocol for
Efficient Routing In Wireless Ad Hoc Networks, International Journal of Engineering and
Science, vol. 2, pp. 01-08, April 2013.
[21]Sreedhar, MadhusudhanaVerma and Kasiviswanath.Performance Analysis of Secure
Routing Protocols in Mobile Ad-Hoc Networks, International Journal of Computer Science
and Technology, vol. 3, pp. 693-697, March 2012.
[22]Elizabeth M. Royer and Chai-KeongToh, "A Review of Current Routing
Protocols for Ad Hoc Mobile Wireless Networks," IEEE Personal
Communications, Vol. 6, No. 2, pp. 46-55, April 1999.
[23] C.E. Perkins and E. M. Royer, Ad hoc on-demand distance vector
routing in Proc. WMCSA, New Orleans, LA, pp. 90100, Feb. 1999.
[24] M. K. Marina and S. R. Das On-Demand Multi Path Distance Vector
Routing in Ad Hoc Networks in Proc. ICNP 2001, pp. 14 23, Nov. 2001.
[25] A. Nasipuri and S. R. Das, On-Demand Multipath Routing for Mobile
Ad Hoc Networks Proc. ICCN 1999, pp. 6470, Oct. 1999.
[26] Tarique, M., Tepe, E., SasanAdibi, and ShervinErfani, Survey of
multipath routing protocols for Mobile Ad-hoc networks, Journal of
Network and Computer Applications, 32:1125-1143, 2009.
[27]Chonggun Kim, ElmurodTalipov and ByoungchulAhn, "A Reverse AODV
Routing Protocol in Ad Hoc Mobile Networks," LNCS 4097, pp. 522-531,
2006.International Journal of Wireless & Mobile Networks (IJWMN) Vol. 6,
No. 5, October 2014 174
[28]Pravanjan Das and Upena D Dalal, A Comparative Analysis of AODV
and R- AODV Routing Protocols in MANETS, International Journal of
Computer Applications 72(21):1-5, June 2013.

53