1.

ABSTRACT: An ADHOC network is a set of wireless vibrant mobile nodes forming a momentary network; it does not make use of any nearby network communications or any central management for networking. There are a number of routing protocols like the DSR- Dynamic Source Routing, AODV- Adhoc on Demand Distance Vector Routing, DSDV- Dynamic Sequenced Distance Vector, RSVP Resource Reservation Protocol, TORA- Temporally Ordered Routing Algorithm, OLSR- Optimized Link State Routing Protocols & so on In our project we are comparing the performance of routing protocols based on mobility and QOS, in NS2. The three protocols under consideration are 1. DSR 2. AODV 3. OLSR protocol A network simulator is popularly known as NS-2. A NS is also a distinct occasion simulator. As the name itself suggests it is used as a replication for routing. It is majorly used in Mobile Adhoc Networking (MANETS). It is also used for multicast protocols. NS does simulation of Transfer Control Protocol (TCP), multicast protocols for wired & wireless network. In our project we would be comparing the effect of mobility for the above three protocols and have comparison for throughput, end to end delay, packet delivery ratio. NS2 is based on UNIX primarily. It uses TCL & OTCL for its scripting language. It is one of the most important tool in networking. An ad hoc network consists of mobile nodes which may be static or dynamic, but they are often mobile, these nodes behave as routers & thus help in discovery of new paths or routes in a network. With parameters like bandwidth, delay, jitter in the network layer; it is one challenging aspect in communication world to achieve good Quality of service. In a network mobile nodes may be vibrant, they are not static, and thus the topology also changes drastically. There is also a shortcoming in a wireless ad hoc network for the non existence of a federal control to administer & dispense possessions. In a wireless network routing protocols may have problems of bare or unknown terminal [1]. A classic example of a wireless ad hoc network is a Bluetooth.

INDEX WORDS: DSR, AODV, OLSR, QoS, Delay & Bandwidth 2. INTRODUCTION: NETWORK SIMULATOR A Network Simulator [2] is a packet level simulator. It is a centric distinct event simulator & an event scheduler to schedule events like packets. In a network simulator events are carried one by one & it cannot handle events at the same time in factual. In a network simulator the events are fleeting or short lived. NS2 handles and implements a various number of network components & protocols. In the CMU monarch project [3] it says Nodes cannot wander considerably over a particular distance for a long time for receiving or transmitting packets. This is applicable only for mobile nodes which are quite vibrant & have low speed. If we have a node which sends data at 10Kbps & moves at 10m/s the receiving packet is 1500B the node would move at 12m. This may lead to response failure . Node velocity is compared to the velocity of light It is targeted for network based researches; Network Simulator 2 is event simulator of discrete type. Sufficient support for simulation of routing, TCP, multicast protocols for wireless (both local and satellite based) and over wired network is provided efficiently in Network Simulator 2. Since 1989 when the idea of NS 2 was conceived, it has been used widely by industry, academics and government projects. NS 2 itself is a constantly developing project which has underwent several enhancements, the best part of NS 2 lies in the ability, that developers can use it to investigate network performance almost in same manner as if being deployed in a real world scenario. NS2 provides collaborative simulation environment, and is freely distributed and open source, which supports NT research and education Protocol design, traffic analysis etc. [4] Here is a simplified structure of NS 2:

Fig 1: A schematic for the NS-2, and this is probably the simplest way to understand the working and architecture of the NS 2. [4] 3. AIM: In our project we are comparing the performance of routing protocols based on mobility and QOS, in NS2. The three protocols under consideration are 1. DSR 2. AODV 3. OLSR protocol The performance parameters that we are using for comparison are throughput, end to end delay, packet delivery ratio, etc related to mobility We are also looking towards having QoS with respect to delay, bandwidth and jitter. 3.1 OBJECTIVE:

Wireless ad-hoc networking [5] is most commonly used in computer communications and is a dynamic collection of wireless mobile nodes. It forms a temporary network and does not use any existing network infrastructure or centralized administration.

The ad-hoc network consists of multiple nodes connected by links. Each node that is a part of the network acts both as a host and router. This node forwards packet to other nodes. Hence it is necessary to have an efficient routing protocol for the Adhoc network to deliver messages on a decentralized environment. Routing Protocol is categorized as follows: a. Table Driven (Proactive) b. On Demand (Reactive) c. Hybrid (both proactive and reactive) It is important to use modeling and simulation (using extensive parameter sweeping and what-if analysis) in adhoc networks to foresee a variety of possible situations that can occur. The goal of this master thesis is as follows: 1. Get a general understanding of ad-hoc networks. 2. Generate a simulation environment that could be used for further studies. 3. Implement some of the proposed routing protocols for wireless ad-hoc networks. 4. Analyze the protocols theoretically and through simulation. 5. Produce a classification of the protocols with respect to applicability in combinations of small/large networks, and mobile/semi-mobile nodes. 6. Recommend protocols for specific network scenarios.

4. Literature Review: Wireless networking (communication) [5] is an emerging technology that allows users to access information and services electronically, irrespective of geographic position. This is due to recent technological advances in laptop computers and wireless data communication devices (such as wireless modems and wireless LANs). The rapid continuing growth of mobile computing has lead to lower prices and higher data rates. Following are the two ways for enabling wireless communication between two hosts: 1. Allowing the existing cellular network infrastructure to carry data as well as voice. 2. Forming an ad-hoc network among users to communicate with each other. The advantages of ad-hoc networks to traditional cellular systems are: 1. On-demand setup 2. Fault tolerance 3. Unconstrained connectivity The benefits of ad-hoc network are: 1. Ad-hoc networks do not rely on any pre-established infrastructure. Therefore it is possible to deploy in places with no infrastructure. 2. Ad-hoc network is useful in disaster recovery situations and places with non-existing or damaged communication infrastructure where rapid deployment of a communication network is needed. 3. Ad-hoc networks are also useful on conferences where people participating in the conference can form a temporary network without engaging the services of any pre-existing network.

To make decisions when nodes are forwarding packets to each other it is important to have a routing protocol. Currently there is no standard routing protocol for an ad-hoc network. In a network simulation; simulation is defined an inference or a copy of performance of different events in the real world. It makes use of multifaceted math models in which the combinations are few. Thus a model is formed & the output is different values in the realistic world which are going to take place. One cannot determine the succession of events due to change which is a result of performance of others concerned [6]

We can make use of simulation for analyzing multifaceted systems, evaluate design options for non existing schema and further analyze the result of alternation for an existing system.

If the assumptions made are simple in understanding then by using math & algorithm one can get perfect results. There are different types of simulators like GloMoSim, NS2, OPNET etc. which are used quite a lot these days. We would be using NS2 for evaluating the routing protocols AODV, DSR, OLSR in an open source & the programming languages used are OTcL, Tcl & C++.

The network Simulator was developed by VINT (Virtual Interwork Test Bed) group. NS supports simulation for UDP & TCP & even MAC protocols with varied routing & multicast protocols for wired & wireless networks.

Fig 2: Simplified Users view for NS [8] As per the users requirement the simulations are stored in a trace file which can be taken as plug-in for scrutinizing by dissimilar components. A NAM trace file is used in the Network Animator to produce the simulated field A trace files uses X graph [8] & is used to generate graphical results. The Fig:2 shows a beginners view for NS. It is object oriented Tcl (OTcl) script predictor & it has simulation event scheduler & network component object libraries, a network setup. To use NS we use OTcl script language. When a user sets up & runs a simulation in a network he has to write the OTcl script which initiates an event scheduler to setup the topology for the network, with the help of the functions in the library, it would explain when to start & stop packet transmission via the event scheduler. The simulator further uses the developed script during simulation. Plumbing in the network means setting up a network by plumbing possible paths among the network object and setting up the packet to its correct destination. Thus NS energizes through plumbing

Once the simulation is done; the results are obtained in a text based o/p file which has the entire information for simulation of data. This can be used to analyze data & packets in the network; also it would help us to plot the graphs for the GUI (Graphical User Interface) in a NAM [9]. The results in a graphical user interface are much easier & simpler form. The language is OTcl but C++ is also used. To reduce the packet loss or event processing time the data path in the network is written using C++ The resultant uses OTcl to create corresponding OTcl object for each C++ object to funcion with OTcl interpreter. 4.1 ARCHITECTURE FOR NS2

NS2 architecture is comprises of 5 parts: 1. Event Scheduler 2. Network Components 3. Tclcl 4. OTcl Library 5. Tcl 8.0 script language

Fig: 3. Architecture for NS [10] Fig: 3 show a graphical representation of a Network Simulator. The user is assumed to be on the left hand bottom corner, who is organizing & scheming simulations in Tcl using simulator objects in OTcl library. The event scheduler & network components are running in C++ since it is more effective. This is obtainable to OTcl through OTcl linkage.

The above 5 components make a Network Simulator. This is an object oriented comprehensive Tcl analyst with NS library [10] Tool Command Language Tcl: The Tool Command Language [11] is a dominant interpreted programming language. This was developed by John Ouster at University of California. It is used widely in the network and desktop relevance, testing & administration purpose. Tcl is a fractious platform. This is an extensible language & is compatible with C programming Language. The Tcl library can be interoperated in C programs [11] NAM: The Network Animator provides GUI (Graphical User Interface) for simulation background depending on parameters provided by the user. The X graph produces a graphical result for input data or trace file The nam interprets a trace file through indexed network events. A NS simulation generates a trace file. A NAM can also generate a trace from a live network. This works offline & uses traces stored on CD. The NAM can generate traces from any running program from the desktop or any platform. All the information required for animation is contained in NAM trace file. The information can be both for a static network or dynamic network like packet arrival, departure, loss of packets. The plug in for NAM can be information about nodes, nodes location & packet movement.

Fig: 4 Block Diagram for NAM. [11] NAM is Graphical User Interface for replaying simulation & specifies position of nodes in the script. NAM provides information about the movement of packets in the network. The traces of packet movement & network simulation traces are generated in a Tcl based animation tool

To use NAM we would require trace file. The trace file has data about network topology like the nodes, links & packet traces. The trace file is generated by Network Simulator. Once the trace file is created it can be used by NAM for animation. Once the trace file is sent to NAM it reads the Trace File. It will further develop a topology; a window further pops up to do the required tracing. The process takes a halt for first trace packet in the trace file. The NAM has control for a wide range of animation application. [12] 4.1 Platforms supported by NS-2

Most UNIX and UNIX-like systems, FreeBSD, Linux and Solaris are supported. Also supports Windows 98/2000/2003/XP; however Cygwin is must in such case. So, it can be said that NS 2 basically supports the operating systems like UNIX and the other flavors of UNIX, namely Free BSD, Linux, etc. It can be deployed on some Windows variants as well, provided that the Windows variants have the availability of UNIX environment, In order to get the UNIX environment on a Windows system the Cygwin can be used. [7] 4.2 Components of NS 2 1. NS Simulator 2. NAM Network Animator 3. Pre-processing 4. Post analysis If viewed from the user perspective - users perspective, NS2 is an OTcl interpreter that takes an OTcl script as input and produces a trace file as output.

Fig: 5 OTcl scripts are fed as input, which later are given to the OTcl interpreter, this interpreter in the presence of C++ libraries does the job, and the simulation results are received as output. As said earlier as well, it is a Discrete Event Simulator, hence physical activities are translated to events, events are processed and queued in order to the scheduled occurrences, events are progressed as the time progresses.

Fig: 6 Shows each network object using an event scheduler. Network components that simulate packet-handling delay or that need timers are the users of an event scheduler. Here it should be noted that a network object that issues an event is the one who handles the event later at scheduled time. Also path of data between network objects is different from the event path. [13]

Fig: 7 The Event Scheduler list consists of Non-Real Time Schedulers, Real Time Schedulers. Basic use of an event scheduler is to schedule simulation events like, when to start FTP application, when to finish it, or in general for simulation scenario generation before the actual simulation run. [13] Shown below is the schematic diagram of the NS 2 Hierarchy:

Fig: 8 the NS 2 Hierarchy However there is a certain set of limitations in the latest release of Network Simulator 2, which should be kept in mind while using the NS 2, these limitations are as follows

a) The NS 2 is a full TCP simulator, i.e. no persist states or 2MSL-wait, no RESET. Validation test suite for full TCP is not available. b) Explicit Congestion Notification This data has been taken from the official NS 2 Website Limitation page. [14] 4.3 Features of NS 2 1. Supported Protocols are TCP, UDP, HTTP, and several routing algorithms as well. 2. CBR, VBR, Web, etc. are the Traffic models supported by a NS 2 3. It also supports the Error models, like burst, uniform, etc. [15] 4. It supports network for MANETS 5. It enables routing along multiple paths. 6. It has a wireless channel module. 4.4 Reasons to choose NS 2 for simulation 1. No costly equipment is required in this process of using NS 2. 2. NS 2 has the ability to test complex scenarios easily. 3. Quick results can be obtained. 4. It isnt tough to modify and re-test if required. 5. The user gets the ability to control the test environment. Simulator helps in easily verifying the protocols investing less time and money. NS 2 also offers a support for verifying and simulation of different protocols. However, the issue which goes unaddressed to a great extent is that the real system is too complex to be modeled. [15] Using NS 2 as a simulator for the network based researches a great idea, in spite of the fact that it is pretty far from the original real world scenario, it has been observed that the implementations done on NS 2 simulator tend to act the same way when deployed in a real world scenario. The simple interface of NS 2, where the backend programming requires the user to be well aware of C++ concepts makes it easy to use as a simulator. The fact that no

high end technology is used for making a NS 2 work is another attraction and pretty good reason to use NS 2. A Network Simulator is a distinct result oriented simulator. As mentioned above it is used for simulation of Transfer Control Protocol (TCP). An NS2 uses C++ & OtCL++ C++ is a programming language used to execute protocols & is used to maneuver bytes OtCL++ is used to simulate configurations where changes are to be done promptly. Both C++ & OtCL++ are linked to each other through TclCL

4.5

NS programming Structure

NS 2 before deployment needs to be programmed as per the user requirements, the structure for programming the NS 2 is as follows, the first step is to create the event scheduler, which will take care of the events and the schedules as well. Second step consist of tracing, i.e. the user needs to turn on the tracing. Third step is to create a well-defined and organized network topology. Creation of Transport connection, which works as the transporting guidelines as well for the data in the network, is to be designed. Generate traffic for the network and finally error insertion is the final step of this programming structure. [16] NS-2 provides a text based or graphical based simulation result. Using NS2 after simulation the result can be plotted on a graph by a network animator tool

4.6 NETWORK ANIMATOR: A network Animator can be designed or downloaded through Tclq /tk or Otcl.[17] This is used for real world packet trace data. [18]. To use Nam we need to have a trace file. The trace file has topology structure like nodes, links & packet traces. A trace file is generated through a Network Simulator. The fig below shows a snapshot of a network animator.

Fig: Snapshot for NAM [18] The command line options in a Nam are: 1. 2. 3. -g Specifies geometry of the window upon startup. -t Instructs nam to use tkgraph, and specify input file nam for tkgraph. -i [Information for this option may not be accurate] Specify rate (real) milliseconds 4.

as the screen update rate. be used in peer synchronization. 5. 6. 7. 8.

-N Specify the application name of this nam instance. This application name may later -c The maximum size of the cache used to store active objects when doing -f Name of the initialization files to be loaded during startup -a Create a separate instance of nam. -p Print out nam trace file format.

animating in reverse.

9. 10. 11.

-S Enable synchronous X behavior so it is easier for graphics debugging. For <tracefile> is the name of the file containing the trace data to be animated -m Will open all tracefiles in the list <multiple tracefiles>. This entire command

UNIX system running X only.

language for a trace file has been taken from Visualization of NAM the network Animator 4.7 TRACE FILES: To use NAM we need to have a trace file. The NAM should contain data for the network topology. Trace file is used to collect the output data of the simulation and used for output analysis. There are different ways to collect the output trace data, it is generally displayed on the screen or can be stored in a trace file. There are two types of wireless trace formats, they are old trace format and new trace format. In this simulation we have written the output in trace file in new trace format. The new trace format can be implemented by using the command $ns use-newtrace The example of new tracefile format is s -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne-1.000000 -Nl AGT -Nw ---Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp -Il 1000 -If2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 Po 0 r -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne-1.000000 -Nl RTR -Nw --- Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp -Il 1000 -If2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0 Awk file : Awk is small , fast , and simple C-like input language used to process the trace file written by network animator (NAM) . The awk file is a simple C-language used to process simple column-oriented text data , tables and gives an output which is used to plot the graphs based on the output.

Awk <filename.tr> is the command and filename.tr is the trace file used to process. Xgraph :The Xgraph program draws a graph on an X display given data read from either data file. The command line for an x

Fig: shows the graphical representation of a trace file on a NAM. [18]

TRACE FILE FOR NETWORK SIMULATOR. A network simulator can be downloaded for free from the net. Simple TCL script: A TCL Script requires the below command Set ns [new Simulator] Open a file for writing to use for nam trace data. set nf [open out.nam w] The above command opens a file named out.nam for writing the nam file and gives it the file handle 'nf'

$ns namtrace-all $nf The above command line tells the simulator object ns we created above to write all the relevant nam data into this file. We should defined some nodes , links , events etc., to run a nam trace file , set n0 [$ns node] set n1 [$ns node] Above two command lines open two nodes n0 and n1, $ns duplex-link $n0 $n1 1Mb 10ms DropTail The above command line connects two nodes n0 and n1 with a duplex link in between with a bandwidth of 1Mb and a delay of 10ms and DropTail Queue To create a flow of data between two nodes n0 and n1 we need to create two agents, since in ns data can be exchanged only between two agents. We need to create two events and need to attach to two nodes. Set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 The above command creates an agent udp0 and attaches it to node n0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.05 $cbr0 attach-agent $udp0

The above command creates a CBR traffic generator and attaches to agent udp0 . A packet of size 500 bytes are exchanged for every 0.005 seconds

set null0 [new Agent/Null] $ns attach-agent $n1 $null0 The above two command lines create a Null agent which acts as a traffic sink and will be attached to node n1. $ns connect $udp0 $null0 The above command connects both the agents. $ns at 0.5 $cbr0 start $ns at 4.5 $cbr0 stop The above commands tells when the cbr agent starts sending and stopping the packets . Adding 'finish' procedure to close the trace file and starts nam. proc finish {} { global ns nf $ns flush-trace close $nf exec nam out.nam & exit 0 } $ns at 5.0 finish The above command tells the simulator object to finish at 5.0 seconds of simulation time. $ns run The above line tells to start the simulation.

Fig: Data transfer between two nodes n0 & n1 The above figure tells how the data is transferring in between node n0 and n1 in nam file [18] 4.8 Wireless Scenario in NS: A wireless model consists of a mobile node at the core with

some additional features that allow the simulations of multi-hop adhoc networks, and wireless LAN . A mobile node is a basic node with some added wireless functionalities like ability to move within the topology area , ability to transfer and receive the signals from a given wireless channel etc., The only difference between a normal and a mobile nodes are the mobile nodes are not connected to mobile node or other node through the links. A mobile node in a wireless scenario consists of network components like wireless channel , MAC layer , Link Layer , Interface Queue (IFQ) Channel Type: The type of channel used for communication, Wireless channel is the channel we used in this simulation. Radio Propagation Model: The radio propagation model in ns2 is used to predict the signal power of each packet. Each wireless node has a receiving threshold value and if packet has less than the threshold value then packet will be dropped at MAC layer. There are three types of Radio propagation models in ns2 they are free space model, Two Ray ground Model Shadowing Model. In this simulation we are using Two Ray Ground Model. Antenna Type: An Omni directional antenna with a unity gain is used by mobile nodes. Link Layer Type: The link layer object is used for simulating data link protocols. Different protocols like Packet fragmentation, reliable link protocols etc., can be simulated in this link layer. The link layer of a mobile node has an Address Resolution Protocol module connected to it which resolves all IP address into MAC address.

Interface Queue Type (IFQ): Interface Queue in a mobile node is used for giving the priority for the packets in the Queue. It filters the packets in the queue and removes the packets with specified destination address. Some of Queueing models supported in ns2 are Drop Tail (FIFO) , RED buffer management etc., In this simulation we use Drop Tail Queuing method . Network Interface Type: It serves as a hardware interface used by mobile node to access the wireless channel. Each packet transmitted from Interface are stamped with a Meta Data related to the transmitting interface like transmission power etc., and the receiving network interface verifies the meta data and determines whether the packet has sufficient power to be received by receiving node. MAC Type: In ns2 there are two type MAC layers they are 802.11MAC and Preamble based TDMA protocol. In this simulation we use 802.11MAC protocol. Ad Hoc routing protocol : At present there are five ad hoc routing protocols supported by ns 2 they are DSDV , DSR , AODV , TORA , PUMA of which we have chosen three routing protocols in this simulation process they are Destination Sequenced Distance Vector(DSDV) , Dynamic Source Routing (DSR), Ad Hoc on Demand Distance Vector(AODV) . Node movement: A mobile node can be generated by setdest file which can be found under ns/indep-utils/cmu-scen-gen/setdest/ directory . By executing Setdest file with the command line as ./setdest a following arguments will be followed : ./setdest -n <num_of_nodes> -p <pausetime> -s <maxspeed> -t <simtime> <maxy> > <scenario-file> -n : number of mobile nodes in the scenario -P : Pause Time ( the average pause time between the movement of a node) -s : Maximum speed a node is moving -t : total simulation time -x : x-coordinate -y : y-coordinate Generating Traffic Pattern: Traffic between the mobile nodes is generated by a file cbrgen.tcl and tcpgen.tcl which can be under the directory ns/indep-utils/cmu-scen-gen/ cbrgen.tcl and -x <maxx> -y

tcpgen.tcl is used to generate CBR and TCP connections respectively . On executing the file cbrgen.tcl or tcpgen.tcl using a command line ns cbrgen.tcl , you will be followed with some arguments

For CBR connections ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc connections] [-rate rate] For TCP connections ns tcpgen.tcl [-nn nodes] [-seed seed] -type : bbbb type of traffic cbr or TCP -nn : number of nodes in the scenario bb -seed : seed value -mc : Maximum connections between mobile nodes -rate : its inverse value is the interval time between CBR packets Simulation Model: In this thesis we are going to analyze the ad hoc routing protocol performance in two scenarios. The routing protocols we used are AODV, DSR, OLSR . All these three routing protocols are simulated in two given scenarios and the results of each protocol are analyzed in terms of QOS parameters and compared with each other. The two scenarios we used in this report are: Scenario 1: The number of nodes in the network are varied with 20, 30 , 40 , 60 , 80 ,100 keeping the speed of the mobility and pause time constant. Scenario 2 : Keeping the number of nodes in the networks constant to 60 nodes and by varying the mobility speeds of the nodes within the network to 15 , 25 , 35 , 45 , 55 m/s .

5. RESEARCH Protocols under consideration are 1. AODV 2. DSR 3. OLSR protocol

5.1

AODV

AODV has a lesser number of requisite broadcasts in steering by establishing routes as on stipulate base. This is totally an on demand route acquisition system. Also the nodes that are not in the routing path do not keep any information about routing When a source node has to send some information to the destination node & there is no valid route available then a route discovery path is generated within the network. The route discovery path is done once a valid route has been found. In the route discovery process a route request (RREQ) is sent to the neighboring node which forwards the request ahead to its neighbor. The process continues until a destination node or an intermediate node finds a new route to the destination node has its own sequence number & a broadcast ID. The broadcast ID increases for every RREQ the node sends. The node also has an IP ADDRESS. With the help of this IP address the RREQ is generated. THE broadcast ID, the sequence number are all included in the RREQ. The source node includes in the RREQ for the recent sequence number it has for destination. The adjacent nodes reply to the RREQ only if a valid route to the destination is present. Also the sequence number of the destination should be more than or equal to that from where the intermediate node.

Fig: RREQ packets from source to destination.

The above figure shows a RREQ packet send from source to the destination. When the RREQ is sent to the destination the intermediate nodes record the address of neighbor from where the RREQ of the initial facsimile of the broadcast packet has received. A reverse path as shown on the right side of the above fig has been established. If some packets get delayed & the RREQ is sent later than the packets are dropped

Once the RREQ packet reaches the destination or the intermediate node with an unsullied adequate route the destination node or the intermediate node hits back a ROUTE REPLY (RREP). The route reply moves in the reverse path, nodes down this path deposit to the fore route details about node from where the RREP came. These forward route entries designate a vibrant onward route. Each node has a route entry which has a route timer any delay in arrival of a packet results in dropping of entry since its specified time limit was over. A RREP moves along the route established by RREQ.

AODV maintains routes as follows:

1. If a source node changes its position than a new route has to be found to find route to the new destination 2. If a node in the route changes its place, the upstream adjacent node marks the change & proposes a link failure notification message to the further upstream nodes to indicate the removal of that path of route. The message which was passed to the adjacent or neighboring node further transfers the message to its neighboring node about the failure

of the path, this continues till the source node has reached. Thus the source node initiates a discovery of a new path. [19]

5.1.2

Maximum Delay Extensions:

The maximum delay extension field is used in RREQ & RREP packets. There is a difference in the two. Maximum delay in RREQ refers to maximum time required from present node to the destination node. When a node receives RREQ a maximum delay will be evaluated with node travelling time. This includes queuing delay, processing time & transfer time [16]. If the result is smaller than the RREQ will not be telecasted ahead & if maximum delay is greater than the traveling time than the RREQ will be broadcasted & travelling time is deducted from the maximum delay. Maximum delay in RREP packet the maximum delay is filled with zero & delays will increase from destination along the route. [16]

5.1.3

Minimum Bandwidth Extension

In the minimum bandwidth extension or minimum data rate extension field the RREQ will evaluate data rate with the one required in the extension field & the one that satisfies required stipulation will forward the RREQ ahead. [20] 5.1.4 Session ID

Routes in AODV are chosen as per the target, but in QAODV a protocol called session ID is used. This is used to describe the flow. There may be a single or multiple flows towards the destination, which may or may not have a similar QoS requirement. [20] 5.1.5 List of Sources requesting QoS Guarantees

A QoS lost message is available when quality of service is not achieved. Any change in the source or destination may affect the network and Quality of Service also needs to match. [20]

DSR: Dynamic Source Routing Protocol DSR or Dynamic source routing is a routing protocol which is more self organized & self configuring. A DSR is used in a Multi hop wireless Ad hoc network. This protocol has Route Discovery & Route Maintenance both provide a new route to the destination as well as maintains routes to any arbitrary position respectively in a mobile ad hoc network 5.2 DSR Protocol

This protocol is an on demand protocol & the routing packet changes the routes only if a change persists. The DSR provides multiple routes to the destination & allows sender to select & maintain the route while routing the packets. A DSR provides easy routing in the network changes. A DSR protocol is designed for two hundred nodes & also with high change in the nodes [21] The route from the source to the destination is a whole path where DSR protocol does a source routing & leaves the addresses of the intermediate nodes of the route in packets [22]. There are other reactive protocols which use the hello messages between the nodes to mark the presence. DSR was designed for MANETs with a diminutive distance amid 5 & 10 hops & nodes move at a judicious speed [22] DSR has two tasks Route Discover & Route Maintenance 5.2.1 Route Discovery:

Now consider a network with nodes A.E. Now node A in his route reserve has a route to E, the route is immediately used to deliver packet from A to E, If the route is not present in its reserve than the Route Discovery Process is established: Node A generates a route request packet (RREQ) by sending it to all the nodes in the network If the neighboring node notices another route request to some other target than it would discard the RREQ from A If the neighboring node is the target of the route discovery, it returns a route reply to Node A. The route reply consists of a list of path from the source to destination. When node A receives this route reply it saves this route in its reserve or cache for use in sending subsequent packets from source to destination. If the neighboring node is not the target the request is sent further. 5.2.2 Route maintenance:

Dynamic source routing provides Route maintenance. Each node in the network confirms the next hop the arrival of the packet. A packet is forwarded only once by a node. If a packet cant be received by the next node than then it is transmitted a number of times until a verification is received from the next hop. If there is a drop out or error in the transmission process than an error message is sent to the source. The route is then deleted from its cache. Thus the source will find some other route in its reserve. Again if there is no route than a RREQ packet is generated. This can be explained well in the fig below

Fig 3 [22] The Fig 3 shows if there is no acknowledgement from D to C than after a few transmissions it sends an error request to A. The moment an error message is sent to node A & node A receives

the message the route is deleted from the reserve, & if there is another route from A to E in the cache than the packet is sent immediately from A to E [22]

So we need to write information mostly on these protocols and the performance parameters that we are using for comparison like throughput, end-end delay, packet delivery ratio, etc related to mobility Parameters related to QOS are delay, bandwidth and jitter, kindly check the attached synopsis for more information

5.2.3

End to End path

End to End path is dependent on link accessibility & path consistency. An MPDSR has multiple disjoint paths in data transmission. A QoS for multiple disjoint paths in a DSR can be defined as acyclic path Acyclic Path If P1 & P2 are two acyclic paths & if they have the same source & destination nodes but the transitional nodes are not the same then they have a disjoint path. In a Multiple Path DSR packet transfer fails if disjoint paths fail at the same time [23]. The probability of failure is less with respect to the acyclic path 5.2.4 End to End Reliability

The End to End reliability is Pt & it is the prospect of data transmission between two thriving nodes within time period from
 +t

where

 is

any time instant. [23]

5.2.5

Proposition

The End to End Reliability from source node S to the destination node D, P (t) to route data along a number of disjoint paths either corresponding or unconventional, k is a set of disjoint paths is derived as

5.2.6

Multi Path DSR

A multipath dynamic source routing provides QoS through end to end reliability. A set of multiple disjoint paths is transmitted. When in QoS for MP DSR is used it uses end to end reliability where 0 is greater than or equal to parameters for route discovery & is greater than or equal to 1. MP DSR has two

a. Number of paths to be discovered (

b. Lowest path dependability obligation each path must be able to provide to satisfy

: Information in message T: Travelled path : Corresponding path reliability When an intermediate node receives an Route Request packet, it checks for path reliability requirement. > include T & If the result is not so than the intermediate node updates RREQ message to
& forwards several copies of this message to the neighbors. The number of

copies is also circumscribed by

to keep a control of message within the network. When the

destination receives the RREQ it chooses multiple disjoint path & sends to the Route Reply to the source node. The source node sends data along these paths. [23]

OLSR OLSR is a proactive protocol in MANETS. Since this protocol is proactive in nature it establishes paths for the packets whenever required. OLSR is independent of any central article. It does not need any consistent communication of message since the nodes present send a message sporadically OLSR provides optimization for protocols. [24] OLSR has been developed for MANETS & it works as a table driven protocol. Te nodes within the network communicate or exchange information about the topology. The nodes in OLSR choose a set of nodes in its vicinity or the neighboring nodes & determine them as Multi Point Relays (MPR). The nodes which are appointed as MPRs are responsible for transferring packets & maintaining a smooth traffic control forward. The MPRs have effective means in maintaining traffic controls by keeping a controlled diffusion. [24] OLSR has two main functionalities: 1. Neighbor Discovery 2. Topology dissemination Neighbor Discovery: The nodes in the network for OLSR detect the neighboring nodes for MPRs. The nodes send a hello message sporadically to the neighboring nodes. The links for nodes can be symmetric or asymmetric. If there is a two way communication then it is a symmetric & asymmetric provides a one way communication. If the node looses the hello message then the message is moved ahead as a one hop neighbors or a two hop neighbor. The two hop neighbor has a holding time otherwise the message is lost. Thus the nodes can select its own MPR. The MPR is computed if there is a change in one hop or two hop neighbors Topology Dissemination: The nodes in the OLSR network have a topology details provided by Topology Control (TC). For every TC interval a node M selects the MPRs. For any variation in the MPR the next TC is sent earlier. The Topology Control messages are sent to all the nodes in the network & take benefit of having the MPR to reduce the number of retransmissions. The topology details in the network is there for a short while with the nodes & so the nodes have a little hold time

The routes are computed in OLSR through Dijksstras shortest path. The nodes perform optimal as far as the numbers of hops are concerned. NS2 Simulation for OLSR A simulation for OLSR under NS2 has been done. Pt is the transmission power {constant} Transmission range for nodes 250 (nodes will receive packets properly within the transmission range) RXthresh (Receive Threshhold) between 250 & 500 m. The nodes will detect packet in this range but will not receive them properly. 500 m this value is achieved CSthresh ( Carrier Sense threshold) RxPr is distance between sender & receiver packets A two ray ground propagation model is used. If RxPr/Interference fraction is less than a Capture Threshold (CPThres) then a collision takes place. RTS/CTS is in the MAC Layer. It seems that the simulation exists for only 600 sec for the parameters in the table 1. The size of packets I maintained as 1KB. To have a easy simulation we are using manual configuration to achieve maximum bandwidth. The maximum bandwidth between two consecutive nodes is 1.3 Mbps using OLSR. The source node transfers a CBR/UDP to destination which should be in range. MAC bandwidth is 2 Mbps. Bit rate for application layer is 1.3 Mbps. This value is known to all the nodes in the network & is known as maximum available bandwidth Parameter Pt_(W) RXThresh (W) CSThresh (W) CPThresh (db) MAC bandwidth (Mbps) Value 0.28183815 3.652e-10 1.559e-11 10.0 2.0

Ref: [1] Labiod, H. Quidelleur (2002). Vehicular Technology Conference. France: VETECF. [2]The network simulator - ns-2, http://www.isi.edu/nsnam/ns/ [3]The CMU Monarch Projects Wireless and Mobility Extensions to ns, http://www.monarch.cs.cmu.edu/ [4] 10. Derya H. Cansever, Arnold M. Michelson, and Allen H. Levesque. Quality of service support in mobile ad-hoc IP networks. In MILCOM 1999 - IEEE Military Communications Conference, number 1, pages 30.34, [5] C K Toh, 2002 Ad Hoc Mobile Wireless Networks, Prentice Hall Publishers [6] A. Law and W. Kelton, Simulation Modeling and Analysis, McGraw-Hill, 2008 [7]Network Simulator NS2 Internet Technologies 60-375 by Varaprasad Reddy. http://www.scribd.com/doc/53136022/4/Platforms-supported [8] XGraph homepage, URL: http:/www.isi.edu/nsnam/xgraph. [9] NAM: Network Animator, URL: http://www.isi.edu/nsnam/ns/ns-documentation.html [10] Institut fr Parallele und Verteilte Systeme A Comparison of the architecture of network simulators NS-2 and TOSSIM im Rahmen des Seminars Performance Simulation of Algorithms and Protocols [11] TCL Tutorial,URL:http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html [12] Tutorial for the network simulator ns URL: http://www.isi.edu/nsnam/ns/tutorial/ [13] Overview of NS-2; History; Current Status; Platforms Supported; Discrete Event Simulator; NS-2 Environment; NS-2 Hierarchy; NS-2 Architecture [14] Overview of NS-2; History; Current Status; Platforms Supported; Discrete Event Simulator; NS-2 Environment; NS-2 Hierarchy; NS-2 Architecture [15] 11. Introduction to Network Simulator NS2 by Teerawat Issariyakul and Ekram Hossain (http://www.springerlink.com/content/mr5452/front-matter.pdf) [16] Network Simulator 2 (official website) http://www.isi.edu/nsnam/ns/ [17] The ns Manual (formerly ns Notes and Documentation)1, The VINT Project A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC. Kevin Fall kfall@iee.lbl.gov_, Editor. Kannan Varadhan kannan@catarina.usc.edu_Editor. April 14, 2002

[18] Tutorial for network simulator [19] Shan Gong, Quality of Service Aware Routing Protocols for, Mobile Ad Hoc Networks [20] Ad Hoc Mobile Wireless Networks: Protocols and Systems By: C.-K. Toh - Ph.D. [21] RFC 4728 on The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 [22] University of Luxembourg, Faculty of science Technology & communication http://wiki.uni.lu/secan-lab/Route+Discovery.html [23] [18] MP-DSR: A QoS-aware Multi-path Dynamic Source Routing Protocol for Wireless Ad-Hoc Networks Roy Leung, Jilei Liu, Edmond Poon, Ah-Lot Charles Chan, Baochun Li, Department of Electrical and Computer Engineering, University of Toronto, leungr, chanah@comm.toronto.edu, jliu, epoon, bli@eecg.toronto.edu [24] RFC3626: OLSR, section 1.3 (page 8)

For DSR: David B. Johnson, David A. Maltz and Josh Broch, DSR: The Dynamic Source Routing protocol for Multi-Hop Wireless Ad Hoc networks. For AODV: Ian D. Chakeres and Elizabeth M. Belding-Royer, AODV Routing Protocol Implementation Design.