69

CHAPTER 3

AODV PROTOCOL

In this model the sensor networks energy is reckon in this base

protocol by routing the packets and its energy is observed. In order to
improvise the performance of the energy level of the nodes the proposed
techniques is incorporated and observed. The Ad-Hoc On-Demand Distance
Vector (AODV) routing protocol is the combination of both the reactive and
proactive protocols. It is having maximum characteristics of reactive protocol
and minimum characteristics of proactive protocol. The Routes are
established only there is a need (i.e on-demand basis). However a route once
established is maintained till it is in need. Reactive routing protocol works
by finding the path between the source and destination only there is a need of
data to be exchange between them.

The main advantage and disadvantage of this approach is that it

greatly reduces the overhead of the routing , but its making large delay from
the time of the route is needed (a packet is ready to send) until the route gets
acquired. In AODV, the network maintains silent until a connection is
needed. The node which needs the connection should broadcast the request to
other nodes. Other AODV nodes hear this request and record the node where
they hear from, thus making an explosion of temporary routes back to the
needy node. When the desired route is available with a node in the network,
then it sends a message to needy node through the temporary route. The
needy node then begins using the route that has the least number of hops
 70

through other nodes. After certain time the unused entries in the routing tables
are recycled.

3.1 OVERVIEW

There are three types of messages defined by AODV, they are

Route Requests (RREQs), Route Replies (RREPs) and Route Errors
(RERRs). These message types are received at port 654, over UDP, and
normal IP header processing applies. The requesting node should use it IP
address as the source IP address for sending the messages to other nodes. The
IP limited broadcast address is used for broadcasting the messages and it
should not forwarded blindly. However, AODV operation requires that
certain messages (e.g..,RREQ) have to be disseminated widely and
throughout the ad-hoc network. The range value of such flooding RREQs is
indicated by the TTL in IP header. Fragmentation is not required.

AODV has no work when the connection between the endpoints is

reliable. The node uses a broadcast RREQs to find a route to the destination
when there is a need.

A route can be determined when the RREQs reaches the destination

itself or an intermediate node with a „fresh enough‟ route to the destination.

A 'fresh enough' route is an unexpired route passage for the

destination whose related sequence number is in any event as extraordinary as
that contained in the RREQ. The route is made accessible by unicasting a
RREP back to the wellspring of the RREQ. Every node accepting the request
reserves a route back to the originator of the solicitation, so that the RREP can
be unicast from the destination along a way to that originator, or similarly
from any intermediate node that has the capacity fulfill the request.
 71

Nodes screen the connection status of next hops in dynamic routes.

At the point when a connection soften up a dynamic route is identified, a
RERR message is utilized to tell other node that the loss of that connection
has happened. The RERR message demonstrates which destinations are
presently inaccessible because of the loss of the connection, to empower this
reporting component, every node keeps a "precursor list", containing the IP
address for every its neighbors that are prone to utilize its a next bounce
towards the destination which is currently inaccessible. The data in the
precursor list is most procured amid the handling for era of a RREP message,
which by definition must be sent to a node in precursor list.

A RREQ might likewise be gotten for a multicast IP address. In this

report, full handling for such messages is not determined. For instance, the
source of such a RREQ for a multicast IP location may need to take after
exceptional principles. Be that as it may, it is critical to empower right
multicast operation by transitional nodes that are not empowered as source or
destination nodes for IP multicast addresses, and in like manner are not
prepared for any exceptional multicast convention handling. For such
multicast-unconscious nodes, preparing for a multicast IP address as a
destination IP address must be done in the same path concerning some other
destination IP address.

AODV is a routing protocol and it manages route table

administration. Route table data must be kept notwithstanding for fleeting
routes, for example, to briefly store reverse ways towards nodes starting
RREQs. AODV utilizes the accompanying fields with every route.

 Destination IP Address

 Destination Sequence Number

 Interface
 72

3.2 AODV OPERATION

This segment portrays the situations under which nodes produce

Route Request (RREQ), Route Reply (RREP) and Route Error (RERR)
messages for unicast communication towards a destination, and how the
messages information are taken care of. Keeping in mind the end goal to
process the messages effectively, certain state data must be kept up for the
route table entries for the destinations of hobby.

All AODV messages are sent to port 654 using UDP.

3.3 MAINTAINING SEQUENCE NUMBERS

AODV relies on upon every node in the network to possess and

keep up a sequence number to ensure the loop-freedom of all routes towards
that node. A node augmentations its own sequence number in two
circumstances.

Instantly before a node starts a RREQ flood, it MUST

augmentation its own sequence number. This averts issues with erased reverse
routes to the originator of a RREQ.

Instantly before a destination node starts a RREP in light of a

RREQ, it must redesign its own sequence number to the most extreme of its
present sequence number and the destination grouping number in RREQ
packet.

Each route table section at each node must incorporate the most
recent data accessible about the sequence number for the IP location of the
destination node for which the route table passage is kept up. This sequence
number is known as the "destination sequence number".
 73

It is overhauled at whatever point a node gets new data about the

sequence number from RREQ,RREP, or RERR messages that may be gotten
identified with that destination.

The main other condition in which a node may change the

destination number in one of its route table passages is in light of a broken or
terminated connection to the following bounce towards that destination. The
node can undoubtedly figure out which destination utilizes a broken next
bounce by counseling its precursor lists for the following jump. For this
situation, for every destination which utilizes the following jump, the node
augments the grouping number and puts the Hop Count to be "vastness".

3.4 MAINTAINING ROUTE TABLE ENTRIES AND ROUTE

UTILIZATION RECORDS

The route which are valid is maintained by the node that containing
a finite Hop count metric as a routing table entry, thus the precursors list are
also maintains by node that forwarding packets on this route. The intimation
is send to the precursors if loss of the next hop link is detected. The route
reply is generated or forwarded for the neighboring nodes which present in
list of precursor in a routing table.

When AODV control packet is sent from neighbor to a node, it will

verify its route table for an entry to that neighbor. In the event where there is
no corresponding entry for that neighbor, an entry is created. The sequence
number is found from the information contained in the control packet, or it
will initialize to zero if the sequence number for that node cannot be found.
The lifetime for the routing table entry is either determined from the control
packet (i.e., the neighbor is the originator of RREP for itself,) or it started to
MY_ROUTE_TIMEOUT. The hop count to the neighbor is marked as one.
 74

Every time the route that used to forward a data packet, its
validation time field is updated to be no less than the current time plus
ACTIVE_ROUTE_TIMEOUT. Thus the route between source and
destination in the network are expected to be symmetric, the validation time
for the previous hop, along the reverse path back to the IP source, is also
updated to not less than the current time plus ACTIVE_ROUTE_TIMEOUT.

3.5 PATH DISCOVERY

The Path Discovery process is initiated whenever a source node

needs to communicate with another node in the network for which it has no
routing information in its table every node maintains two separate counters a
node sequence number and a broadcast id the source node initiates path
discovery by broadcasting a route request RREQ packet to its neighbors the
RREQ contains the following fields

The pair source addr broadcast id uniquely identities a RREQ

broadcast is incremented whenever the source issues a new RREQ Each
neighbor either satisfies the RREQ by sending a route reply RRE back to the
source see section or it will broadcast again the RREQ to its own neighbors
after increasing the hop CNT Notice that a node may receive multiple copies
of the same route broadcast packet form various neighbors When an
intermediate node receives a RREQ if it has already received a RREq with the
same broadcast id and source address it drops the redundant RREQ and does
not rebroadcast it if a node cannot satisfy the RREQ it keeps track of the
following information in order to implement the reverse path setup as well as
the forward path setup that will accompany the transmission of the eventual
RREP Destination IP address Source IP address Broadcast id.
 75

3.6 REVERSE PATH SETUP

There are two sequence numbers in addition to the broadcast id

included in a RREQ the source sequence number and the last destination
sequence number known to the source. The source sequence number is used
to maintain freshness information about the reverse route to the source and the
destination sequence number specifies how fresh a route to the destination
must be before it can be accepted by the source as the RREQ travels from a
source to various destination it automatically sets up the reverse path from all
nodes back to the source as illustrated to setup a reverse path a node records
the address of the neighbor from which it received the copy of the RREQ.
These reverse path route entries are maintained for at least enough time for
the RREQ to traverse the network and produce a reply to the sender.

Forward path setup Eventually a RREQ will arrive at a node

possibly the destination itself that possesses a current route to the destination.
The receiving node first checks that the RREQ was received over a
bidirectional link If an intermediate node has a route entry for the desired
destination it determines whether the route is current by comparing the
destination sequence number in its own route entry to the destination
sequence number in the RREQ if the RREQs sequence number for the
destination is greater than that recorded by the intermediate node the
intermediate node must not use its recorded route to respond to the RREQ
Instead the intermediate node rebroadcasts the RREQ.

The intermediate node can reply only when it has a route with a
sequence number sequence number that is greater than or equal to that
contained in the RREQ if it does have a current route to the destination and if
the RREQ has not been processed previously the node then unicasts a route
reply packet RREP back to its neighbor from which it received the RREQ A
 76

RREP contains the following information source addr, destaddr, dest

sequence hop count lifetime by the time a broadcast packet arrives at a node
that can supply a route to the destination are verse path has been established
to the source of the RREQ Section as the RREP travels back to the source
each node along the path sets up a forward pointer to the node from which the
RREP came updates its timeout information for route tries to the source and
destination records the latest destination sequence number for the requested
destination figure represents the forward path setup as the RREP travels from
the destination D to the source node S Nodes that are not along the path
determined by the RREP will timeout after ACTIVE ROUTE TIMEOUT
msec and will delete the reverse pointer A node receiving an RREP
propagates the first RREP for a given source node towards that source if it
receives further RREPs it updates its routing in formation and propagates the
RREP only if the RREP.

3.7 PATH MAINTENANCE

Movement of nodes not lying along an active path does not active
the routing to that paths destination if the source node moves during an active
during an active session it can reinitiate the route discovery procedure to
establish a new route to the destination when either the destination or some
intermediate node moves a special RREP is sent to the active source nodes
periodic messages can be used symmetric links as well as to detect link
failures as described in section alternatively and with far less latency such
failures could be detected by using link layer acknowledgments LACKS a
link failure is also indicated if attempts to forward a packet to the next hop
fail once the next hop becomes unreachable the node upstream of the break
propagates an unsolicited RREP with a fresh sequence number a sequence
number that is one greater than the previously known sequence number and
hop count of to all active upstream neighbors.
 77

Those nodes subsequently relay that message to their active

neighbors and son on this process continues until all active source nodes it
terminates because AODV maintains only loop free routes and there are only
a active number of nodes in the adhoc network upon receiving notification of
a broken link source nodes can restart the discovery process if they still
require a route to the destination to determine whether a route is still needed a
node may check whether the route has been used recently as well as inspect
upper level protocol control blocks to see whether connections remain open
using the indicated destination If the source node or any other node along the
previous route decides it would like to route to the destination it sends out an
RREQ with a destination sequence number of one greater than the previously
known sequence number to ensure that it builds a new viable route and that no
nodes reply if they still regard the previous route as valid.

3.8 LOCAL CONNECTIVITY MANAGEMENT

Nodes learn of their neighbors in one of two ways whenever a node

receives a broadcast from a neighbor it updates its local connectivity
information to ensure that it includes this neighbor in the event that a node has
not sent any packets to all of its active downstream neighbors within hello
interval it broadcasts to its neighbors a hello message a special unsolicited
RREP containing its identity and sequence number. The nodes sequence
number is not changed for hello messages transmissions.

This hello message is prevented from being rebroadcast outside the

neighborhood of the node because it contains a time to live TTL value of
Neighbors that receive this packet update their local connectivity information
to the node receiving a broadcast or a hello form a new neighbor or failing to
receive allowed hello loss consecutive hello messages from a node previously
in the neighborhood is an indication that the local connectivity has changed
 78

failing to receive hello messages from inactive neighbors does not trigger any
protocol action.

If the message „hello‟ is not received from the next hop along an
active path the active neighbors using that next hop are sent notification of
link failure as described in section We have determined the optimal value for
allowed hello loss is two as is shown in section the local connectivity
management with hello messages can also be used to ensure that only nodes
with bidirectional connectivity are considered to be neighbors for this purpose
each hello sent by a node lists the nodes from which it has heard each node
checks to make sure that is uses only routes to neighbors that have heard the
nodes hello message to save local bandwidth such checking should be
performed only if explicitly configured into the nodes.