ADHOC Simulator

8/7/2019 ADHOC Simulator

http://slidepdf.com/reader/full/adhoc-simulator 1/48

ADHOC Simulator

Chapter-1

Preamble

Department of CSE,

PDA College of Engineering, Gulbarga. - 1 -



ADHOC Simulator

Introduction AODV

Route Requests (RREQs), Route Replies (RREPs), and Route

Errors(RERRs) are the message types defined by AODV. These

message types are received via UDP, and normal IP header

processing applies. So, for instance, the requesting node is

expected to use i ts IP address as the Originator IP address for the

messages. For broadcast messages, the IP limited broadcast

address (255.255.255.255) is used. This means that such messages

are not bl indly forwarded. However, AODV operation does require

certain messages (e.g., RREQ) to be disseminated widely, perhaps

throughout the ad hoc network. The range of dissemination of such

RREQs is indicated by the TTL in the IP header. Fragmentation is

typically not required.

As long as the endpoints of a communication connection have

valid routes to each other, AODV does not play any role. When a

route to a new destination is needed, the node broadcasts a RREQ

Department of CSE,PDA College of Engineering, Gulbarga. - 2 -



ADHOC Simulator

to find a route to the destination. A route can be determined when

the RREQ reaches either the destination itself, or an intermediate

node with a 'fr esh enou gh' rout e to the dest inat ion . A 'fre sh

enough' route is a valid route entry for the destination whose

associated sequence number is at least as great as that contained in

the RREQ. The route is made available by unicasting a RREP back

to the or ig ina t ion of the RREQ. Each node rece iv ing the reques t

caches a route back to the or ig ina tor of the reques t , so tha t the

RREP can be unicas t from the des tinat ion a long a pa th to that

or ig ina tor, or l ikewise f rom any in termedia te node tha t i s ab le to

satisfy the request.

Nodes moni tor the l ink s ta tus of next hops in ac t ive routes .

When a l ink break in an act ive route is detected, a RERR message

is used to notify other nodes that the loss of that link has occurred.

The RERR message indicates hose destinations (possibly subnets)

which are no longer reachable by way of the broken l ink. In order

to enable this report ing mechanism, each node keeps a "precursor

list", containing the IP address for each its neighbors that are likelyto use it as a next hop towards each destination. The information in

the recursor l is ts is most easi ly acquired during the processing for

generation of a RREP message, which by definition has to be sent to

a node in a precursor list. If the RREP has a nonzero prefix length,

then the originator of the RREQ which solicited the RREP

information is included among the precursors for the subnet route

not specifically for the particular destination).

AODV is a routing protocol, and it deals with route table

management. Route table information must be kept even for short-

lived routes, such as are created to temporarily store reverse paths




ADHOC Simulator

towards nodes originat ing RREQs. AODV uses the fol lowing f ields

with each route table entry:

- Destinati on IP Address

- Destination Sequence Number

- Valid Destination Sequence Number flag

- Other state and routing flags (e.g., valid, invalid, repairable, being

repaired)

- Network Interface

- Hop Count (number of hops needed to reach destination)

- Next Hop

- List of Precursors- Lifetime (expiration or deletion time of the route)

Managing the sequence number is crucial to avoiding routing

loops, even when l inks break and a node is no longer reachable to

supply its own informati on about its sequence number. A

destination becomes unreachable when a link breaks or is

deactivated. When these conditions occur, the route is invalidatedby operations involving the sequence number and marking the route

table entry state as invalid.

AODV Terminology:-

This protocol specifica tion uses conventio nal meanings for

capitalized words such as MUST, SHOULD, etc., to indicate

require ment levels for various protocol features. This section

defines other terminology used with AODV that is not already

defined in.

Department of CSE,




ADHOC Simulator

Active route or valid route

A route towards a des t ina t ion tha t has a rout ing table ent ry

that is marked as val id. Only act ive routes can be used to forward

data packets.

Broadcast

Broadcast ing means transmitt ing to the IP l imited broadcast

Address, 255.255.255.255. A broadcast packet may not be bl indly

forwarded, but broadcasting is useful to enable dissemination of

AODV messages throughout the ad hoc network.

DestinationAn IP address to which da ta packets a re to be t ransmit ted .

Same as "destination node". A node knows it is the destination node

for a typical data packet when its address appears in the appropriate

field of the IP header. Routes for destination nodes are supplied by

act ion of the AODV protocol , which car r ies the IP address of the

desired destination node in route discovery messages.

Forwarding node

A node tha t agrees to forward packets des t ined for another

node , by re t ransmit t ing them to a next hop tha t i s c loser to the

unicast destination along a path that has been set up using routing

control messages.

Forward route

A route set up to send data packets from a node originat ing a

Route Discovery operation towards its desired destination.

Invalid route

Department of CSE,




ADHOC Simulator

A route that has expired, denoted by a state of invalid in the

routing table entry. An invalid route is used to store previously valid

route information for an extended period of t ime. An invalid route

cannot be used to forward data packets, but it can provide

information useful for route repairs, and also for future RREQ

messages.

Originating node

A node that initiates an AODV route discovery message to be

processed and possibly retransmitted by other nodes in the adhoc

network. For instance , the node initiat ing a Route Discover y

process and broadcasting the RREQ message is called theoriginating node of the RREQ message.

Reverse route

A route set up to forward a reply (RREP) packet back to the

originator from the destination or from an intermediate node having

a route to the destination.

Sequence number

A monotonically increasing number maintained by each

originating node. In AODV routing protocol messages, it is used by

other nodes to determine the freshness of the information contained

from the originating node.

Applicability Statement:-

The AODV routing protocol is designed for mobile ad hoc

networks with populations of tens to thousands of mobile nodes.

AODV can handle low, moderate, and relatively high mobility rates,




ADHOC Simulator

as well as a variety of data traffic levels. AODV is designed for use

in networks where the nodes can all trust each other, either by use

of precon figu red keys, or because it is know n that ther e are no

malicious intruder nodes. AODV has been designed to reduce the

dissemination of control traffic and eliminate overhead on data

traffic, in order to improve scalability and performance.

Department of CSE,




ADHOC Simulator

1.1 Statement of the problem

The problem can be defined as to develop a .Net based ADHOC simulator to

study the behavior of the MANET. As the system is implemented in .Net, it hould

be capable of consider a large area for simulation and it should be capable of

carry out the simulation amongst a large group of mobiles. The simulator ust be

capable of depict the behevior of the system under high mobile condition.

Department of CSE,




ADHOC Simulator

1.2 Objective of the study

A mobile ad hoc network (MANET) is an infrastructureless and highly

dynamic network. Routes in such a network may fail frequently because of node

mobility or other issues. Stability therefore can be an important element in the

design of routing protocols. Stable routes, also called the long-lived routes, can

be discovered and used to reduce the overhead resulted from route maintenance

in ad hoc networks. The challenge becomes much more prominent when larger

set of data is considered. In this work we propose the possible design schema for

AODV simulator, which could be, build to simulate all kind of routing algorithm for

AODV protocol. First a RREQ would be generated corresponding to all the

receivers. The path will be established following the shortest path rule. Once the

path is formed, a random way point model will be selected for the movement of

the nodes. In this algorithm a node will select another node randomly and move

towards it with a predefined speed. Once it reaches there, waits for a specificperiod of time and would start moving again by selecting another node. Data

would be transmitted and the amount of data that is delivered would be counted.

Thus the throughput would be calculated. This would be a performance

evaluation for the network.




ADHOC Simulator

1.3 Scope of the study

Through this project the infrastructure less networks can adopt mesh based

routing schema and can make sure that the nodes participating in the routing be

stable and the probability of break-down of the link due to the movement of the

nodes be minimized. Hence it would improve the throughput of the network and

increase the longevity of the network.

The study can also be used as a platform to analyze the relative positional model

of the nodes in a group. It can be a base model for broadcast based routingmodel. Even though the bandwidth requirement is bit higher still the algorithm

would be the best when throughput is greater criteria than the bandwidth.

This can also give the overall lifetime of a route and the longevity of the links in

the communication.

Department of CSE,




ADHOC Simulator

1.4 Methodology

The work is designed to achieve the performance analysis of the Multicast-

AODV algorithm and compare the performance with the AODV protocol.

Therefore the design objective clearly demands two independent platforms as

follows.

1) Network Architecture As ADHOC is an infrastructure less network, the

mobiles do not form any distinct architectural hierarchy. Therefore a network

needs to be designed with the nodes being scattered in the area. Such mobiles

may keep on be moving with high mobility or can more or less be stable. As thereis no fixed base station, each node has the capability to act as a router in some

path. Therefore the network model needs to be suitably designed. For this very

purpose, a random distribution of the mobiles is considered. It is assumed that all

the nodes initially generate a hello packet to know the distances of the other

node. If some node is at long enough distance it may not respond to the Hello

packet request or their response is delayed enough to be considered as un-

reachable. Therefore the simulation model assigns a distance table to each node

with an entry in terms of hop distance for every other node. The distribution is

considered to be pure random one in this case. As the aim of the work is to study

the behavior of the link stability of such a network, the network would be

considered to be a dynamic network with very high mobility. Due to high enough




ADHOC Simulator

mobility (Random way point algorithm), the network hierarchy would constantly

change during the course of the simulation.

2) Communication Once the network is set up the next responsibility is to

initiate communication sessions between the transmitter and the receiver.

Therefore randomly set of transmitters and the receivers are selected. It is made

sure that a node, which is already a transmitter or a receiver of a particular

session, is not transmitter or receiver of any other session. But there are no suchboundaries being set as par as router selection is concerned.

3) Path Determination Once the transmitter-receiver pair or the session is

decided, each source node generates a RREQ packet, which traverse through

the network. Every RREQ would have the session ID. A node will process it if

only it had not processed the request for the same path previously. Then the

paths corresponding to all the sessions are generated following the AODVconcept. But in the current work rather than nodes preferring to choose the

shortest path it would prefer the stable path. This is done by relativity model. It

works as bellow.

Once all the paths to all the destinations are find out source would start a mesh

generation through which all the nodes would be knowing about the details of the

other nodes in the group and multicast the packet to all the group members.

Each member would drop any duplicate packet being received from different

nodes.

4) Data Transmission Once path are determined, number of data to be

transmitted through the path are randomly selected. The data would be

transferred in a packet of maximum 10 units. As the packets are transmitted,




ADHOC Simulator

each node looses some energy depending upon the packet strength. Therefore if

a particular node looses huge amount of energy (an amount which is over

threshold) the node is removed from the network. It doesn’t notify about the

breakdown to the source node. No route maintenance is considered here.

Therefore if majority of the nodes break down, and the receiver is unreachable

all the subsequent data through the path (or paths) comprising the broken-down

node would be lost.

5) Statistical Data Collection As the communication begins the nodes

generates the hello packets and on the course checks the closeness of all the

possible node entries. It thus calculates the older nodes and the newer nodes.

The nodes, Thus the nodes woul be monitoring the stability of the group.

5) Performance Monitoring Throughput is considered to be the major

performance criteria in the study. Therefore number of data level will be varied

and the throughput would be calculated for the same set data. By varying the

number of nodes or the network density, the performance is observed.

Department of CSE,




ADHOC Simulator

1.5 Review of Literature

No research can be accomplished without referring to the literatures and papers

in the concerned subjects. The core logic of this work was extracted from

“Finding Stable Routes in Mobile ADHOC Networks” by Chun-Yen-Hsu and

Jean-Lien C. This paper provides the mathematical model for the work. The

random mobility model concept was referred from “Spatial Node Distribution in

the Random waypoint mobility model” by Esa Hyyti, Pasi Lassila, Laura

Nieminen and Jorma Virtamo. It explains the mathematical and

implemental model for the random way point algorithm.

As the project was coded in C#.Net, an indepth knowledge and

reference in C# was important. “C#.Net” by Andrew Trolson

provided all the required information. Graphics algorithms were tken

from “Computer Graphics” by haeren Backer.




ADHOC Simulator

1.6 Limitations

The simulator is one of the most preliminary works in the direction of developing

a full simulator for AODV protocol simulation. This is implemented on the .Net

platform. But as the study is at it’s initial stages lot of constraints are overlooked.

Beside the study doesn’t take into consideration about the multicast or the

broadcast routing. This scenarios are required for larger simulation and

complicated simulation model.

Department of CSE,




ADHOC Simulator

Chapter-2

Introduction to AODV Protocol

General Concepts2.1 Ad-hoc Networking

There are two approaches that allow two wireless stations to communicate with

each other. The first one is to introduce a third fixed party (a base station) that

will hand over the offered traffic from a station to another, as illustrated in Figure

3. This same entity will regulate the attribution of radio resources, for instance.

When a node S wishes to communicate with a node D, the former notifies the

base station, which eventually establishes the communication with the

destination node. At this point, the communicating nodes do not need to know of

a route for one to each other. All that matters is that both nodes source and

destination are within the transmission range of the base station. If one of them

fails to fulfill this condition, the communication will abort.

Question: what happens if the base station is unavailable? Or what happens if

we are in situation where such an infrastructure does not exist at the first place?Answer: we simply do not communicate! Actually, we can thanks to the second

approach that is introduced bellow.




ADHOC Simulator

Note however that this form of centralized administration is very popular among

wide cellular networks such as GSM, UMTS, etc.

Figure 1 Infrastuctured network

The second approach, called ad-hoc, does not rely on any stationary

infrastructure. The concept behind these infrastructureless networks is the

collaboration between its participating members, i.e., instead of making data

transit through a fixed base station, nodes consequentially forward data packets

from one to another until a destination node is finally reached. Typically, a packetmay travel through a number of network points before arriving at its destination.

Figure 4 illustrates a simple 3-node ad-hoc network. In this figure, a source node

S wants to communicate with a destination node D. S and D are not within

transmission range of each other. Therefore, they both use the relay node R to

forward packets from one to another. So, even though R is primarily a host, R isacting as a router at the same time.




ADHOC Simulator

Figure 2 Infrastructureless networks

By definition, a router is an entity that determines the path to be used in order to

forward a packet toward its final destination. The router chooses the next node to

which a packet should be forwarded according to its current understanding of the

state of the network.

Because of the improvised nature of ad-hoc networks, routes are built

dynamically as and when nodes are regrouping (Discovery). Hence, ad-hoc

networks are more responsive to topology changing than any wired networks.

Consequently, routing protocols for ad-hoc networks should be able to cope with

link breakages and make sure that the network wont collapse as nodes aremoving or shutting down (Maintenance).

The following section is dedicated to ad-hoc routing protocols.

2.2 Routing protocols for Ad-hoc Networks

2.2.1 Actual Needs

Department of CSE,


S DR



ADHOC Simulator

As we previously mentioned, ad-hoc networks have certain characteristics that

put a lot of stress on the routing layer. Some of these characteristics are listed

bellow:

• Nodes in a MANET are connected by wireless links with a constrained

bandwidth. Thus, an appropriate routing protocol for MANETs should imply a

reasonable over-head in order to preserve the limited bandwidth. Message

complexity must be kept very low.

• Nodes in a MANET are likely to be hand-held devices and laptops with

relatively constrained resources. These resources include namely storage

capacity and battery power and should be used in a smart way. Therefore, a

suitable routing protocol for MANETs should not make an excessive use of

flooding or periodic update messages.

• Nodes in a MANET are likely to be mobile. In order to cope with such a

rapidly changing topology, a routing protocol for ad-hoc networks should be

able to find alternate routes very quickly. Rapid convergence is the ultimate

goal for an ad-hoc routing protocol.

In the next sections, we will see how classic protocols do not fulfill the newdemands that were established by ad-hoc networks. Also, we will see how this

has led to the appearance of a new generation of protocols wholly dedicated to

MANETs.

2.2.2 Classic Protocols

Two routing algorithms, link-state and distance-vector , have been traditionally

used in packet-switched networks. They both allow a node to determine the next

hop along the “shortest path” toward a given destination. The shortest path is

computed according to a specific cost, which is usually the distance in number of

hops.

Department of CSE,




ADHOC Simulator

2.2.2.1 Link State Protocols

In the link-state approach, each node collects the state (cost) of its outgoing links

(links toward neighboring nodes) and diffuses it to every other node in the

network in the form of link state packets (LSPs). This is done periodically or

whenever a change is detected in one of the outgoing links. Also, LSPs are

tagged with a sequence number in order to indicate their freshness (most recent

LSPs have greater sequence numbers).

On the other hand, as a node receives the LSPs, it updates its global view of the

network topology in terms of link states. Given this map, the node runs a shortestpath algorithm (usually, Dijkstra’s shortest path algorithm) and determines the

optimal next hop for each destination in the network. Only the next hop and route

cost for each destination are stored in the routing table.

Note however that nodes do not update their tables at the same time (due to the

propagation time of LSPs). This can lead to the formation of some short-lived

loops, which will disappear by the time the LSPs have reached every other nodein the network.

2.2.2.2 Distance Vector Protocols

The distance vector algorithm, also called the Bellman-Ford algorithm, is based

on a different approach. Each node advertises its entire routing table to its

immediate neighbors only. As a node receives the routing information of its

neighboring nodes, it updates its own routing table by looking at its neighbors’

routing table. Basically, for each destination, a node looks at each of its

neighbor’s distance for that destination (distance from neighbor to destination)

and increments it by the link cost to reach this same neighbor. The node, then,

picks up the neighbor via which the distance is the smallest. Each node keeps




ADHOC Simulator

track of its neighbor’s distances and modifies its local vector if any changes

occur.

The Bellman-Ford algorithm suffers from both short-lived and long-lived loops.

Also, it is known for its “counting-to-infinity” problem, which occurs in case of link

failure.

2.2.2.3 Critique

Both algorithms link-state and distance-vector have proven their efficiency in

case of networks with very low mobility. However, they both collapse when it

comes to frequently changing topology networks. They not only take a long timeto converge, but they also consume a big part of the available resources in

finding routes that would probably never be used. Plus, some sort of mechanism

should be added in order to avoid the formation of neither short nor long-lived

loops.

2.2.3 Enhanced Protocols for MANETs

With the growing interest for mobile ad-hoc networks, a large set of IP-based

routing protocols was proposed to the MANET working group. No standard has

been adopted yet, but some promising protocols are enthusiastically under study.

One of the rising protocols is the subject of this report. It is called Ad-hoc On

Demand Distance Vector (AODV) and finds some of its inspiration in the

Destination Sequenced Distance Vector (DSDV) protocol.

2.2.3.1 Destination Sequenced Distance Vector Protocol

Department of CSE,




ADHOC Simulator

As the name indicates, DSDV is originally based on the distance-vector

algorithm.

Two major modifications were added in order to make the protocol suitable more

for mobile ad-hoc networks. The first modification was added to cope with the

“counting to infinity” and “loop formation” issues. The idea is very simple and

consists of tagging each route with a sequence number in order to indicate its

freshness. Basically, a route with a greater sequence number is a route that was

issued later in the time and has therefore more chances to be accurate with

regard to the current topology of the network. The destination sequence number

is originally issued by the destination node. This number is maintained within

each node by incrementing it whenever a change occurs along this same route.The sequence number and the cost route are included in the update messages.

Thus, when a node receives an update message for a given route, it first checks

the sequence number that is included in it and compares it with the one that is

stored in the routing table. Only update messages with greater sequence number

are taken into account. In case of equality, the route with smaller metric is to be

considered.

The second improvement that was added to the original algorithm aims at

reducing the over-head generated by the protocol. It consists of the introduction

of two types of update messages: full dump and incremental . A full dump packet

is used to advertise all available routing information whereas an incremental

packet has smaller size and is used to advertise only the changes between two

full dumps.

Indeed, DSDV is much more stable than the basic Bellman-Ford algorithm.

However, DSDV still relies on periodic messages to maintain its routing

information. Therefore, a final adjustment was needed to minimize the amount of

over-head traffic generated.

Department of CSE,




ADHOC Simulator

2.2.3.2 Ad-hoc On-demand Distance Vector Protocol

AODV[3] brings another brick to the edifice. As an improvement on DSDV, AODV

reduces the amount of control traffic by simply minimizing the number of

enquired routes. Instead of building a route for all possible destinations in the

network, a node only creates and maintains routes that it really needs. When a

route is needed, a node initiates a request in order to locate its interlocutor node.

On the other hand, when a route is no longer used, it is simply expunged from

the routing table. This approach is known as source-initiated on-demand routing

as opposed to table-driven routing. It is also known as reactive as opposed to

proactive . For reasons of scalability, proactive protocols may not find the same

response within the MANET community as reactive protocols, such as AODV,DSR, or OLSR would probably have.

Another adjustment was added as far as route maintenance is concerned. In fact,

in case of link failure, the node upstream immediately broadcast an update

message to the set of nodes that are truly affected. Periodic updates such as full

dump packets in DSDV were completely eradicated.

Of course, AODV uses the same set of sequence numbers as in DSDV, which

guaranties loop-freedom in its routes.

A more thorough description of AODV mechanisms is presented in the next

chapter.

3 AODV Specifications

As we previously mentioned in section 2.2.3.2, the Ad-hoc On demand Distance

Vector protocol uses a whole different approach to build its routing information.

As a matter of fact, route enquiries are initiated on an on-demand basis.

Department of CSE,




ADHOC Simulator

When a node wishes to send a packet to a destination node, it initiates a

discovery process in order to locate it. If no route is found within a specific period

of time, the initiator node assumes that the destination node is unreachable. The

discovery process is aborted and the corresponding data packets are dropped.

On the other hand, if the initiator node receives a route as a response to its

enquiry, it updates its routing table by creating an entry for the destination node.

Once an entry is created, a maintenance process is triggered in order to monitor

the status of the just created route— if a route is no longer used, a node deletes

from its routing table. If a failure occurs along an active route, the node upstream

immediately notifies the earlier hops of such a breakage using a specific type of control packets. In the presence of packets still in need of a route, affected nodes

may re-initiate new discovery activities in order to find a replacement route.

AODV defines the routing information in a distributed table-driven manner. This

means that each node along a particular path has to maintain a routing table

entry for the destination node down that same path. This is opposed to the

source routing approach where only the source node is aware of the complete

path (hop-by-hop) toward the destination. AODV also allows each node to

maintain one and only route per destination. It is good to know then that some

other routing protocols allow multiple route discoveries. In this case, if a primary

route collapses, an alternative one is used.

Routing table entries are defined in AODV in the form of tuples <destination

address, next hop address, sequence number, distance, precursor list, expiration

date>. Sequence numbers are used to guarantee loop-freedom and indicate the

freshness of a route. Distances are expressed in number of hops. Whenever a

route is invalidated, the destination sequence number is incremented by one and

the distance is set to infinity. The precursor list designates the set of neighboring

nodes that are effectively using that entry to forward data packets. Finally, the




ADHOC Simulator

expiration date indicates the time upon which the entry must be deleted. Of

course, the expiration date is extended every time the entry is used.

3.1 Route Discovery

The discovery process is a mechanism that allows each source node

participating in a MANET to locate (given its IP address) a destination node for

which it has a packet to send. Of course, nodes initiate discovery requests only

for nodes that have not been previously located (those for which node has not an

entry in its routing table). If an entry already exists, then data packets are

immediately sent to their destination and the discovery step is skipped.

In order to initiate a discovery process, a node has to broadcast a route request

packet (RREQ) to its neighboring nodes. The packet is propagated by every

other node in the network until a route is found (see Figure 5).

3.1.1 Generating route requests

Basically, if a node source A is looking for a destination node B in a MANET, A

would let every other node in the network know that it is looking for B by

broadcasting a RREQ packet to its neighbors. The RREQ includes the IP

address and sequence numbers of both source and destination. The destination

sequence number refers to the sequence number associated to the last route to

the destination node B that the source node A has been aware of. If no trace of

the sequence number is found, a default value of 0 is used.

Department of CSE,




ADHOC Simulator

Figure 3 RREQ propagation

Each intermediate host which receives the broadcast RREQ has to re-broadcast

it at a certain extent until the RREQ reaches either the destination node B or an

intermediate node which is aware of a fresh enough route (according to the

included destination sequence number) to the destination node B.

Two other fields of a RREQ are the time to live (TTL) and the broadcast ID .

The TTL field allows a discovery initiator to control the degree of dissemination of its RREQ within the network. For instance, a RREQ packet whose TTL field is set

to 2 will travel through 2 hops at most from the source node. When a RREQ is

broadcast, the source node sets its TTL field to an initial value in terms of hops

and waits for a corresponding period of time (RREP_WAIT_TIMEOUT) before

taking any action. If by any chance, a route is received before the waiting period

is finished, then the discovery process is successfully terminated. On the other

hand, if the waiting period arrives to its term without having received any

response, the source node re-broadcasts the “same” RREQ packet and again

waits for another period of time. This time, however, the RREQ has a bigger TTL

value and the waiting period is consequently longer. Having a bigger TTL value,

the new RREQ will reach a larger set of nodes and will hopefully lead to a route

reply generation.




ADHOC Simulator

If still no reply is received, the source keeps on re-broadcasting the RREQ with

an incremented TTL up to a maximum number of retries. Upon threshold, the

discovery period is aborted. These mechanisms of broadcast control is also

known as the expanding ring search technique.

Also, each RREQ packets is tagged with a sequence number, called Broadcast

ID. This tag provides a mean for nodes to distinguish the different RREQs

emanating from the same node and is incremented after each broadcast. A

couplet <source IP address, Broadcast ID> uniquely identifies a RREQ and a

RREQ with a greater Broadcast ID is fresher. As an intermediate node processes

a RREQ issued from a particular node, it records the corresponding Broadcast

ID. Later, the intermediate node will only process RREQs from a same sourcenode with a greater Broadcast ID. Other RREQs with smaller Broadcast ID are

simply discarded.

Finally, a RREQ carries a hop count field that records the number of hops that

the RREQ has traveled through.

3.1.2 Forwarding route requests

An intermediate node I receives a RREQ emanating from a source node S which

is requesting a route for a destination node D.

First of all, I checks the Broadcast ID and the source node of the just received

RREQ. If the RREQ is obsolete (smaller or equal Broadcast ID), then R does notprocess it. The RREQ is destroyed.

In case I has to process the RREQ, it first creates or updates a reverse route to

the source node S (Figure 6 illustrates all the reverse routes that were created as




ADHOC Simulator

the RREQ propagated in Figure 5). This route will eventually be used to carry the

route reply back to the source node S . The next hop along this path is the node

from which the RREQ was received and the corresponding sequence number is

the source sequence number that is included in the RREQ.

Once the reverse route is created, I checks if it has a fresh enough route to D. If

this is the case, R generates a route reply packet (see paragraph bellow) and

unicasts back along the reverse route. At this point, the RREQ does no longer

need to be re-broadcast. If R does not have a fresh enough route, it will re-

broadcast the RREQ after having consumed one hop of its time to live (TTL

decremented by one). A RREQ that has expired (TTL = 0) is not re-broadcast. In

case of re-broadcast, the hop count field is also incremented by one.

Figure 4 Reverse route creation

3.1.3 Generating route replies

Department of CSE,




ADHOC Simulator

When a node wants to make a route available (either a destination node or an

intermediate node with a fresh enough route), it unicasts a route reply packet

(RREP) back to the source node that initiated the discovery process.

The RREP contains IP addresses of both source and destinations nodes and the

sequence number of the advertised route. It also includes a hop count field

(similar to the one in RREQ packets) and a lifetime field whose value indicates

the validity period of the advertised route.

3.1.4 Forwarding route replies

As it is illustrated in Figure 7, the forward path (from source to destination) is built

as the route reply packet travels down along the reverse path. Each node

receiving the RREP creates an entry for the destination node D. The destination

sequence number and hop count are copied from the RREP itself and the next

hop along this path is the last node that forwarded the RREP.

Department of CSE,




ADHOC Simulator

Figure 5 Forward route creation

If the RREP has not reached its destination (S) yet, then it has to be forwarded tothe next hop along the reverse path. Of course, the hop count field is

incremented first.

When the RREP finally reaches the source node, it does no longer need to be

forwarded. After S has created a forward entry toward D, it automatically

destroys the RREP packet. The discovery period is terminated and the newly

established route can now be used to send the data packets waiting on the

buffer.

So far, two limitations of AODV were pointed out. First, AODV discovers a single

route between a pair source/destination. Second, AODV discovery procedure

assumes that RREP packets will travel down the same path that RREQ packets

went through, but in the other way. This assumption of bi-directionality makes

AODV not suitable for situations where uni-directional links may exist. Yet, in a

wireless environment, links are unlikely to be symmetric.

3.2 Local Connectivity Management

When a route toward a particular destination is created, a node may use a set of

mechanisms in order to monitor its status. In other words, each node along a

particular path tries to make sure that the next hop toward that destination

remains available and viable as long as needed. If the next hop is active, the

route is still valid. If not, the current node has to notify earlier nodes that the route

is no longer valid, as described in Section 3.3.

Department of CSE,




ADHOC Simulator

Monitoring can be done in two different fashions: proactive or reactive . In the first

approach, some kind of anticipation is introduced. Each node constantly monitors

the actual state of activity of its neighbors by updating its local connectivity map

whenever a broadcast packet is received. Said differently, whenever a broadcast

packet is received the current node updates or creates its routing table entry for

the originator node. This entry would have a short lifetime period which would

correspond to the maximum period of time that a neighboring node is allowed to

remain silent before the current node assumes that it is unavailable. Thus, as

long as the neighboring node is available, the corresponding entry remains valid.

On the other, if a routing table of a neighboring node happens to expire, the

current node assumes that the downstream link has broken and a link failure

notification procedure is immediately called.

Sometimes however, a node’s silence is not an accurate indicator of its

availability. Therefore, AODV makes use of periodic hello message broadcasts.

Basically, if no broadcast packet has been emitted within the last hello interval

period of time, a node advertises its presence by broadcasting a specific RREP

packet containing its identity and sequence number. Hello messages were also

introduced in order to make AODV independent from lower layer platforms—localconnectivity management can rely entirely on hello message exchanges. Lower

layer messages can be ignored.

The second approach is called proactive . This means that a link breakage is only

detected upon a data transmission failure. In this case, a failure may be detected

a bit later. However, a reactive approach induces a quite heavy overhead which

might not be adequate for mobile ad-hoc networking purposes.

3.3 Route Maintenance

Department of CSE,




ADHOC Simulator

When a link failure is detected along a route, the node upstream propagates a

route error (RERR) packet in order to notify earlier nodes down the path of such

a breakage. The RERR contains the list of all lost destinations along with their

sequence numbers incremented by one.

As the RERR travels down the forward path (Figure 8), each affected node

updates its routing table by invalidating the corresponding routes. For each

destination included in the RERR packet, the current node sets the distance

value to infinity and updates the corresponding sequence number by copying it

from the RERR packet. Plus, if the precursor list is not empty, the current

unreachable destination remains within the RERR packet which will be broadcast

to predecessor nodes. Of course, the RERR will be re-broadcast only if at leastone unreachable destination is remaining.

Also, note that each node invalidates its entry for a given destination only if the

RERR was received from its own next hop toward that same destination. For

instance, even though 1’ receives the RERR, 1’ will not invalidate its route for D

because As a matter of fact, 1’ receives the RERR from 2 which is not, according

to its routing table, the next hop toward D. Therefore, the RERR is simplydestroyed.

Figure 6 RERR propagation

Department of CSE,




ADHOC Simulator

3.4 Route expiry and deletion

In keeping with the purely on-demand nature of AODV, each node gets rid of all

the routes which are no longer used. Thus, if an active route is not used within

the last ACTIVE_ROUTE_TIMEOUT period of time, the current node first

invalidates it by incrementing its sequence number and setting the hop count to

infinity. The entry is said to be expired. At this point, the entry has not been

removed from the routing table. In fact, the entry will stay in the expiry state for a

DELETE_PERIOD of time, before being completely expunged from the routing

table.

The reason behind the expiry/deletion mechanism is for a node to keep record of

the sequence number of the expired route as long as possible. As a matter of

fact, if a node deletes a route upon expiry (without transiting through a deletion

period), it would lose track of its sequence number and the default value 0 will be

used. This situation can lead to the formation of loops, as reported in.

But why delete the entry at the first place? In fact, if a node needs to keep trackof the sequence number, it should never delete an expired entry. This would

certainly be safer. However, such a solution may not be practical in a dynamic

network where a node is likely to see lots of nodes for short periods of time. Also,

rebooted nodes would have no recollection of any sequence number whatsoever.

Therefore, a proper deletion mechanism has to be introduced.

ANNEXE II presents the contribution of the University of Pennsylvania to the

earlier draft of AODV. The idea is for each node to keep the expired entry in the

routing table until no predecessor is pointing at it. In other words, a routing table

entry should be deleted from the routing table of each node along the path

around the same time. To do so, the DELETE_PERIOD value is chosen as the

maximum lifetime that an entry could have within the network. Also, each time a




ADHOC Simulator

node receives a packet for which it has an expired route, it not only generates a

RERR but also delays the deletion time for another DELETE_PERIOD seconds.

Thus, the entry will not be deleted until earlier nodes have their entries for that

same destination deleted too.

Department of CSE,




ADHOC Simulator

2.5 Simulation:

In the simulation, AODV routing protocols are considered. We have

assumed an area of 100 x 100 meters, which is divided into 20x20, cells each a

square of 20 meters. At the beginning we have selected maximum number of

mobiles. These mobiles would be places one in a cell randomly. Each mobile will

select another mobile other than itself for it’s movement. Speed needs to be

initializing by the user. Higher the nodes at any given instance of simulation

model, more distance will cover the speed. A source and the destinations

destination are to be manually selected by the user. In the observation period the

mesh table is formed. User selects a data load and speed of the nodes. All the

nodes would move w.r.t their respected speed for the entire transmission period.

Control packet overhead and the throughput is calculated.

Department of CSE,




ADHOC Simulator

Chapter-3 System Analysis

Department of CSE,




ADHOC Simulator

3.1 Functional Requirement

Network Selection:

The proposed routing model for adhoc network is aimed at bringing more stability

to the network under heavy load by distributing the load properly amongst power

efficient nodes. Therefore a primary power model needs to be assumed along

with the network model. A pure random distribution is assumed where number of

nodes in selected by the user and the distribution is initialized in terms of

distances in hops. Before the beginning of the simulation number of paths wouldbe accepted from the user and the source and the destination should be

randomly selected. During the course of the simulation a fixed number of packets

would be transferred between all the paths.

Protocol Selection:

We have derived a new policy for data transmission here. It ensures a more

statistically stable link over a period of time. The protocol eliminates the

conventional path stability routings shortcomings (ABR, LPR).




ADHOC Simulator

Result analysis:

Throughput is considered as the potential parameter for the behavior and the

stability testing for the current protocol. As the goal of the work is to show that

current model has better performance over its AODV counterpart. Therefore the

simulation model design should concentrate on throughput v/s various other

parameters like load, network density etc.

Platform selection

There are various network simulators like NS2 where a network model simulation

can be carried out with optimum results. But the major drawback on such a

system over here was platform dependency and simulation rigid ness. There

were many parameters, which were required to be varied and selected with a trial

and error method. Some works have also modeled such systems in C. But due to

less memory corresponding to C, simulation parameters are restricted.

Therefore C#.Net is chosen as the simulation tool because it is a 64 bit compiler.It makes an easier understanding of the protocol and at the same time can be

used while implementing the algorithm in real time.




ADHOC Simulator

3.2 Hardware Requirement:

a) Minimum Pentium family processor of 1.5 GHz

b) 256 MB RAM

c) IBM compatible display adaptor

d) Minimum 10Gb Disk Space

3.3 Software Requirement:

a) C#.Net 2003b) Windows Xp Service Pack 2.

c) SQL Server 2000

d) .Net GDI+ Package

Department of CSE,




ADHOC Simulator

Chapter-4 System Design

Department of CSE,




ADHOC Simulator

4.1 Algorithm

The algorithm implements Random way point algorithm. Over here a specific

number of nodes is selected and a probability density function is selected for

their movement. Now each node selects another node in the area and starts

moving towards it. At the beginning a path is generated from the source to the

destination. Now if during the course of the motion the a node in the path movesaway from it’s neighbors, it is said to be broken down. Still data can be

communicated through other members. But when the data can not reach the

destination the mesh is said to be broken and the packets are said to be lost.

Source has to find a new path. In this stage the path would be re calculated. By

the end of simulation number of transmitted packet and number of reached

packets would be counted to calculate the throughput. The simulation

parameters would be varied to get the throughput analysis for various situations.

Department of CSE,




ADHOC Simulator

Chapter-5 Implementation

Department of CSE,




ADHOC Simulator

void RouteDiscovery(RREQ req): The function is responsible for routediscovery. A RREQ packet is generated from the source node and is flooded to

all the neighbors. Whichever is short in terms of hops would forward the packet

to their neighbors. But would keep a record of the path in which it is they have

propagated through to the corresponding node. Also they store the sequence

number of the path so that the same does not process any further RREQ

reaches to the node from any other paths. Once it reaches the destination it

sends a reply back through to the reverse path. As the packet reaches the

source node, the source generates a forward path. Subsequent data packets are

sent via this path.

Route maintenance is not considered. Therefore path would be generated only

once during the course of a transmission. If a node goes down while transmitting,

all the subsequent packets would be lost.

NODE SrcPath(NODE RREP, NODE FPATH): This function is used by the

source nodes to calculate the forwared path from RREP packets.

Department of CSE,




ADHOC Simulator

Chapter –6 Interpretation of the result

Department of CSE,




ADHOC Simulator

Department of CSE,




ADHOC Simulator

Chapter-7 ConclusionThe project is an attempt of developing an environment, which could be used by

the researchers to get their study done on AODV. Beside the work can be used

as the base prototype for developing more complicated package for AODV

simulation environment. As all the base modules have problems regarding

testing and modularization so also this work. But with time as the system grows

into a full fledge package, the system can be like a parallel simulator like theNS/2.

Department of CSE,




ADHOC Simulator

References1. Chun-Yen-Hsu and Jean-Lien C ,National Taiwan university of science and

technology. “Finding Stable Routes in Mobile ADHOC Networks”

2. R. Dube, C.D. Rais, K. –Y. Wang and S.K. Tripathi, “Signal stability-based

Adaptive routing (SSA) for Ad Hoc Mobile Networks”, IEEE Personal

Communications, Vol. 4, No. 1, Feb. 1997, pp. 36-45.

3. S. Agarwal, A. Abhuja, J.P. Singh and R. Shorey, “Route-lifetime

Assessment Based Routing (RABR)) protocol for mobile ad-hoc

networks”, In proc. Of IEEE ICC 2000, Vol. 3, June 2000, new Orleans,

USA, pp. 1697-1701.

4. G.Lim, K. Shin J.S. Kim and H. Yoon, “Signal Strength based Link

Stability Estimation in Ad Hoc Wireless Networks”, IEE Electronic Letters,

Mar. 2003, Vol. 39, No. 5, pp. 485-486.

5. Esa Hyyti, Pasi Lassila, Laura Nieminen and Jorma Virtam,

Spatial Node Distribution in the Random Waypoint Mobility Model,

Networking Laboratory, Helsinki University of Technology,

Department of CSE,




ADHOC Simulator

Documents

ADHOC Simulator