sp1.13

8/3/2019 sp1.13

http://slidepdf.com/reader/full/sp113 1/7

Int. J. Advanced Networking and Applications 555Volume: 02, Issue: 02, Pages:555-561 (2010)

Special Issue – NCICT’10 - New Horizon College, Bangalore

Stable Routing Protocol for Mobile Ad-Hoc

NetworksPradeep Surasura

Department of Computer Science & Engineering, Tontadarya College of Engineering, GadagEmail: [email protected]

Sanjeev S. SannakkiDepartment of Computer Science & Engineering, K.L.S.’s Gogte Institute of Technology, Belgaum.

Email: [email protected]

------------------------------------------------------------------ ABSTRACT-------------------------------------------------------------------

A mobile ad-hoc network (MANET) is a self-configuring network of mobile routers connected by wireless links. Stabilityrefers to the fixed boundary and fixed topology with fixed number of mobile nodes with ad-hoc properties. Stable routingprotocol utilizes the existing classes and features of AODV protocol in network simulator (NS2). The main goal of this paperis to design a protocol, which discovers the route from source to destination by using Ad-Hoc on-demand Distance Vector(AODV) routing protocol in a fixed wireless node topology configured with ad-hoc properties. After finding route fromsource to destination, transfer the data packet and measure energy consumed. Finally check for multiple routes to destinationfor comparison of their throughputs.

Keywords:- Ad-Hoc On-demand Distance Vector, ROUTE REPLY, ROUTE REQUEST, Stable Routing, Wireless relatedparameters, Wireless Topology.----------------------------------------------------------------------------------------------------------------------------------------------------------

1. INTRODUCTION

A mobile ad-hoc network (MANET) is a kind of wireless

ad-hoc network, and is a self-configuring network of mobilerouters connected by wireless links. The routers are free tomove randomly and organize themselves arbitrarily.MANETs need efficient distributed algorithms to determinenetwork organization, link scheduling, and routing protocols.Stability refers to the fixed boundary and fixed topologywith fix number of mobile nodes with ad-hoc properties.

Stable routing protocol utilizes the existing classes andfeatures of AODV [1] protocol in network simulator (NS-2).

AODV [6] has the basic route-discovery and route-maintenance of DSR and uses the hop-by-hop routing,sequence numbers and beacons of DSDV. The source nodethat wants to know a route to a given destination generates aROUTE REQUEST from source to destination. The routerequest is forwarded by intermediate mobile nodes that alsocreate a reverse route from source the destination in a hop by

hop fashion. When the request reaches a node with route todestination it generates a ROUTE REPLY containing thenumber of hops requires reaching destination. All nodes thatparticipate in forwarding this reply to the source node createa forward route to destination. This state created from eachnode from source to destination is a hop-by-hop state andnot the entire route as is done in source routing. Everymobile node will be assigned antenna range of hearing itsneighboring node. Based on the distance of each node,

antenna’s range is been divided into the different energylevels of receiving and transmitting energy. After findingroute from source to destination, transfer the data packet andmeasure energy consumed. Finally check for multiple routesto destination for comparison of their throughputs.

2. DESIGN

n this chapter, brief design patterns of Stable routingprotocol which is implemented by utilizing the existingcomponents and classes of AODV protocol in network

simulator are given. Before stable routing protocol design,first the classes of AODV are described in brief. AODV is adestination-based reactive protocol. AODV incorporatesmany novel features for handling mobility, reduced capacitylinks, indeterminate nature of the signaling range of wirelessmedia. AODV has evolved in a number of ways forimproved performance, robustness, and better scalability. It

avoids routing loops by tagging a unique sequence numberto route information for each destination. This sequencenumber is generated or originated by the destination.AODV [1] for its operation assumes symmetric linksbetween neighboring mobile nodes. That is, the links arebidirectional, and should have same properties in bothdirections. AODV routing protocol uses different routingmessages to discover the routes and maintain links.

There following four classes represent the different AODV[6] messages-

• RouteRequestMessage (RREQ) is a route requestmessage used whenever a new route to a destinationis required.

• RouteReplyMessage (RREP) is a reply message fora route request.

• RouteErrorMessage (RERR) is a route errormessage.

• Periodic HELLO messages are broadcast to check the presence of immediate active neighbors.

If a node does not lie along an active route, it neithermaintains routing information nor participates in theexchange of routing information. The following flow chartsummarizes the action of an AODV [3] node whenprocessing an incoming message.

I

8/3/2019 sp1.13




Fig. 1 Flow chart shows the action of an AODV node

The stable routing protocol consists of mainly two basicprocesses:1. Path discovery

2. Path maintenance.

2.1 Path DiscoveryA path discovery process is initiated whenever a source nodeneeds to send data packets to a destination node and doesnot have route information for the destination node. Thensource node initiates a route discovery process bybroadcasting a RREQ packet to its immediate neighbors.Each intermediate node after receiving the first RREQpacket does the following:

• Checks whether it has a current route information

about the destination node

• If it has current route information, it sends a RREPback to the source node

If it does not have current route information, itrebroadcasts the RREQ to its neighboring nodes and keeps arecord of the following information for setting up a reversepath:

• Destination IP address

• Source IP address

• Broadcast ID

• Expiration time for the reverse path entry

• Source node sequence number

Every subsequent RREQ (copies) with the same broadcastID is discarded. All intermediate nodes repeat this operation

of either rebroadcasting or timing out till RREQ reaches thefinal destination. When RREQ reaches the desireddestination node, the node will unicast a RREP messageback to the source through the reverse path setup.

2.1.1 Reverse Path SetupA source sequence number is used to maintain freshnessinformation about the reverse path to the source. RREQ

travels form source node to various active intermediatenodes and when it finally reaches the destination node, itautomatically sets up the reverse path from the destination tosource. To do this reverse path setup every intermediatenode records the address of the active neighbor from whichit received the first copy of the RREQ. These reverse path

entries are maintained for sufficient amount of time so thatthe RREQ packet traverses the network and produce a replyback to the source.

2.1.2 Forward Path SetupAs the RREP travels back to the source using a reverseroute, either from the destination node or an intermediatenode that has current route information about the

destination, each node along this reverse path sets up aforward pointer to the node from which the RREP isreceived. Each node also updates the timeout information forthis source to destination, and records the latest destinationsequence number. The nodes that are not active along thepath determined by the RREP will timeout and delete thereverse pointers. Timeout for an AODV protocol in NS2 is30 milliseconds. Once the forward path is setup and theRREP reaches the source node, source node willimmediately start data transmission.

2.1.3 Route Table ManagementApart from the source and destination sequence numbers asentries in the routing table, there are expiration timersassociated with reverse path entries and route invalidation.The purpose of the timer meant for reverse path entry is togive timeout information for purging of those reverse pathentries in the nodes that do not lie along the path determinedby RREP. This expiration time depends on the size of thead-hoc network.

A neighbor is considered to be active, if it originates orrelays at least one packet for that destination in the timeoutperiod and the address of the active neighbors is also enteredin the table. Hence a node maintains the followinginformation for each route table entry:

• Destination IP address

• Next hop

• Number of hops

• Sequence number for the destination

• Active neighbors for that route

• Expiration time for the route table entry.

If there is more than one route entry for a particulardestination, the node chooses the one with higher sequencenumber. If the sequence numbers are same then a route withsmaller metric is chosen. Finally after route discoveryprocess a packet transfer is done and measures the energy

8/3/2019 sp1.13




consumed, also compare the throughputs of the multipleroutes.

2.2 Path MaintenanceIf a node moves from the current location to a new location

in the network, the routing will not be affected unless thisnode was in the active routing path. When a source nodemoves to a new location in the network and affects the route

of an active session, then the source can re-initiate a routediscovery procedure if a route to the desired destination isstill required. On the other hand, if an intermediate node of an active session moves from its present position, then aspecial RREP is sent to the affected source nodes. PeriodicHELLO messages are used to detect link failures. Link

failures can also be detected if a node is unable to forward apacket to the next hop. Once a link failure is detected, anunconditional RREP with fresh sequence number and hopcount set to infinity is broadcast to active neighbors. Withinsome time all active nodes in the network will know aboutlink failure. The source nodes can restart the discoveryprocess if they still need a route to a destination.

2.2.1 Local Connectivity ManagementNodes learn about their neighbors in two ways. One way iswhenever a node receives a broadcast message from aneighbor it updates its local connectivity. Other way is tobroadcast HELLO messages to its active neighbors. If anode does not receive HELLO messages consecutively, thisindicates that local connectivity is changed. In stable routesthis process is not a complex issue because as we areconsidering the fixed topology and fixed number of nodesbefore route discovery process starts. Since we are notconsidering the dynamic nature of mobile nodes, Localconnectivity is a complex issue in dynamic nature of noderouting techniques.

3. NS-2 TOOL DETAILS AND STABLE

ROUTING PROTOCOL SIMULATION

Simulation of the protocol is done on network simulator

(ns-2). We first describe the details of the NS2, itscharacteristics and NAM features then we give the details of simulation parameters and other implementation details.

3.1 Introduction TO NS-2NS-2 is an object-oriented, discrete event driven network simulator written in C++ and OTcl (Object-oriented Tool

command language). NS-2 is an object-oriented, IP basedsimulator with an Otcl front end. NS supports a classhierarchy in C++ and a similar class hierarchy within theOtcl interpreter. From the users perspective there is a one-to-one connection between a class in the C++ hierarchy and aclass in the Otcl hierarchy. NS-2 provides substantialsupport for simulating wired and wireless networks withnetwork protocols such as TCP and UDP. NS-2 has supportfor, traffic source behavior such as FTP, Web, CBR andVBR, router queue management mechanism such as DropTail, RED and CBQ, standard routing protocols and Link layer protocols for both wired and wireless networks.

3.1.1 A C++ and OTcl Linkage in NS-2NS-2 is written in both C++ and OTcl languages, with datapath using C++ and control path using OTcl. In order toreduce the packet and event processing time, the eventscheduler and the basic network component objects are

written and compiled using C++. The OTcl linkage creates amatching OTcl object for each of the C++ objects. Thusgiving the control of the C++ objects to OTcl. NS-2 is

Object-oriented Tcl (OTcl) script interpreter that has asimulation event scheduler, network component objectlibraries, and network setup helping module libraries. Otclhas a simple interface and handles objects similar to C++,which is the programming language of NS-2. The user cancreate C++ objects in NS-2 through Otcl scripts, which are

the input for setting up simulations. NS-2[17] can be viewedas a Tcl shell or exacting a Tcl interpreter. The linkagebetween the C++ objects and the Otcl objects is done by theTclCL component of NS. The Otcl networking objects aredefined as classes in Otcl and C++.

The event scheduler will keep track of simulation time anddump all the events of the event queue scheduled at the

current time, into an output file to generate the trace fileoutput. Thus generated trace file is further processed by userwritten scripts to analyze the simulation results.Alternatively, the simulation results can also be visualizedusing Network Animator (NAM).

3.2 Stable Routing Protocol SimulationBelow table provides simulation details of the parametersrelated for the wireless simulation with ad-hoc properties.To simulate any network topology wired or wireless, it isnecessary to write a Tcl script describing the topology(nodes, agents, applications, etc.).

Table 1 Wireless simulation related parameters

Type Parameter

Channel TypeChannel/WirelessChan

nel

radio-propagationmodel

Propagation/TwoRayGround

network interface type Phy/WirelessPhy/802_15_4

MAC type Mac/802_15_4

interface queue type Queue/DropTail/PriQueue

link layer type LL

antenna model Antenna/OmniAntenna range

maximum packet ininterface queue

100

routing protocol AODV

Set X-axis and Y-axissize of grid or boundary

Maximum Value of the X andY coordinates

Simulation End Time inseconds

Time in seconds

Energy model Value in Joules

Initial Energy Value in Joules

CSTresh_ & RXTresh_

Maximum value of distanceRange for Mobile node

hearing its neighbor node inmeters.

8/3/2019 sp1.13




After assigning the wireless related parameters create asimulator object. After assigning the wireless simulationrelated parameters configure each of the mobile with ad hocproperties this is done by the below script.

$ns node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \

-ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channel [new $val(chan)] \

-topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace OFF \ -energyModel $val(energymodel) \ -initialEnergy $val(initialenergy) \ -rxPower 35.28e-3 \

-txPower 31.32e-3 \ -idlePower 712e-6 \ -sleepPower 144e-9

After configuring each mobile node define the wirelessnetwork topology with source and sink (destination). Eachmobile node is assigned with the antenna range as specifiedin the transmitting and receiving range. Also set thethreshold and initial energy values. As the simulation startsevery node will search randomly for its neighboring nodes.A constant bit rate (CBR) agent is attached to source whichuses Agent trace and router trace parameters are used to findthe route to destination.

The snapshots given below are the illustration of theprotocol with two examples. Example gives a wirelesssimulation of 12 nodes where node 0 is sink or destinationand node 10 is source as shown in first snap short. At time 2seconds the route discovery process begins for routediscovery to node 0, every node in the simulation areasearches for its neighboring nodes as shown in snap short 2and 3. Node 10 hears only node2 and node 2 will multicastto its neighbors, from node 2 to node 8 and from node 8 todestination node 0 as shown in snapshot 2 and 3. Afterfinding the route from source to sink data transferring Snapshort is shown in snap short in 4.

Fig. 2 Snapshot 1: Wireless node simulation with 12 nodes.

Fig. 3 Snapshot 2: Wireless node searching for theirneighbor nodes.

8/3/2019 sp1.13




Fig. 4 Snapshot 3: Wireless node searching for theirneighbor nodes.

Fig. 5 Snapshot 4: Data transfer from node 12 to node 0.

4. TESTING

In this application, testing starts right from the installation

of NS2 tool. All classes, components and hierarchy of thetool are not done completely in the installation process. Assoon as the instillation process completes validation process

starts. Validation process builds all the classes, components,libraries and hierarchy of the tools. All the linkages whichare dependents are made independent so that everyindividual class or component can be utilized independentlyfor further enhancement of the tool to build user

applications.

After the validation step completes without any errors thetool is ready to use and build the applications. A broad studyof the tool is done. Initially the tool is verified again bydeveloping some simple wired and wireless applications.Then some more examples are been developed so thatperfectness should achieve with the tool and standardoutputs are been verified.

In stable routing protocol testing phase deals with thewireless related parameters, grid or boundary and ad-hoc

properties with energy levels are verified thoroughly. Basedon the wireless related parameters and ad hoc properties the

route discovery and data transfer, methods are depended.

5. RESULTS AND TRACE ANALYSIS

Topologies in NS2 tool are created randomly by the tool.

Example 1: Observations

Number of nodes = 12Grid or boundary size = 800x800Source = node 10Destination = node 0Antenna range = 40

Wireless topology is given below-

Fig. 6: Wireless topology 1

The main details of .tr file for below topology are givenbelow.s 2.000000000 _10_ RTR --- 0 AODV 48 [0 0 0 0] [energy100.000000 ei 0.000 es 0.000 et 0.000 er 0.000] -------[10:255 -1:255 30 0] [0x2 1 1 [0 0] [10 4]] (REQUEST)

r 2.034619020 _2_ RTR --- 0 AODV 44 [0 2 0 800][energy 99.997984 ei 0.001 es 0.000 et 0.000 er 0.000] ------- [0:255 10:255 30 2] [0x4 1 [0 4] 10.000000] (REPLY)

f 2.034619020 _2_ RTR --- 0 AODV 44 [0 2 0 800][energy 99.997984 ei 0.001 es 0.000 et 0.000 er 0.000] ------- [0:255 10:255 29 10] [0x4 2 [0 4] 10.000000] (REPLY)

r 2.046277484 _10_ RTR --- 0 AODV 44 [0 a 2 800][energy 99.997842 ei 0.001 es 0.000 et 0.000 er 0.001] ------- [0:255 10:255 29 10] [0x4 2 [0 4] 10.000000] (REPLY)

From the above .tr file we observe- At time 2.000000000 source node 10 sends a route

request to sink node 0 with packet id 48 and usingAODV protocol through route trace. But no directroute to destination.

At time 2.034619020 node 10 will reach node 2packet id 44 through route trace using from node 10consuming energy of 99.997984.

At time 2.034619020 node 2 will forward packet tonode 0 with energy 99.997984.

At time 2.046277484 packet id 44 reaches the sink node 0.

In this topology only single path exists todestination from source.

Example 2: ObservationsNumber of nodes = 6

Grid or boundary size = 1200x1200Source = node 11Destination = node 0Antenna range = 40Wireless topology is given below-

8/3/2019 sp1.13


8/3/2019 sp1.13




[13] B.Royer, E.M., and C.-K. Toh. “A review of current routing protocols for ad-hoc mobilewireless networks”, IEEE Personal

Communications Magazine, 46–55.

[14] C. Perkins, Ad hoc on-demand distance vector(AODV) routing, Internet Engineering Task Force:

draft-ietfmanet-aodv-12.txt, November 2002.

[15] A. B. McDonald and T. F. Znati. A pathavailability model for wireless ad-hoc networks.Proceedings of IEEE WCNC, pages 35–40,September 1999.

[16] G. Lim, K. Shin, S. Lee, H. Yoon, and J. Ma. Link stability and route lifetime in ad-hoc wirelessnetworks. International Workshop on Ad Hoc

Networking (IWAHN’02), August 2002.

[17] K.Fall, K.Varadhan. “The ns Manual”, A

Collaboration between researchers at UC

Berkeley, LBL, USC/ISI, and PARC, January 2009.

[18] Perkins, C.E., and P. Bhagwat. “Highly dynamic

destination sequenced distance-vector routing(DSDV) for mobile computers”, Computer

Communications Review pp, 234–244.

Authors Biography

Pradeep Surasura secured B.E. Degree fromB.L.D.E.A’s Dr. P.G. Halakatti’s College of Engg., Bijapur and M.Tech. Degree fromK.L.S’s Gogte Institute of Technology,Belgaum on year 2007 and 2009 respectively.

Currently working as a Lecturer in Tontadarya College of Engg., Gadag. Main area of interest Ad-Hoc NetworksRouting terminologies. Presented one National Level

Technical paper on “MANET Security”. AttendedWorkshop on “Network Simulation Tools” at G.I.T.,Belgaum.

Sanjeev S. Sannakki has completed his postGraduation with the specialization inComputer Networking. His career spans overa decade in the field of teaching, research &other diversified in-depth experience in

academics. He is currently working as Assistant Professor inthe department of CSE Gogte Institute of Technology,Belgaum. He has published a few papers at various National& International conferences. He is also guiding the projectsof UG/PG students of Visveswaraih TechnologicalUniversity.

sp1.13

Documents