A Reactive Route Discovery Protocol For Device Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This thesis presents simulation of cognitive device which seamlessly integrates between different networks like GSM, Dialup, Ethernet etc .Based on Reactive routing approach, a route discovery algorithm will be analyzed which will help device in finding route to particular location based on network type. Analysis of AODV will be done on device supporting multiple physical interfaces.

Table of Contents

List of Figures

Chapter 1: Introduction

Cognition is a process that involves sensing, reasoning, understanding and reacting. Application of cognition to wireless network results in highly dynamic ecosystems. Cognitive network is defined as a network that can distinguish current network conditions and can act upon those conditions. It also learns from its consequences [2].

A cognitive radio is an intelligent communication network that is aware of its environment and capabilities. Cognitive wireless networks are capable of reconfiguring of their infrastructure. They are capable of continuously adapting to a volatile network characteristic.

A secure Cognitive network device (SCND) is device which is based on cognitive cross layer architecture. This device integrates a HF, VHF, UHF and 802.11 based mobile ad hoc network with GSM and Satellite networks. In this thesis, we need to define a routing protocol which works across cross layer architecture of SCND.

1.1 Thesis Outline:

We have organized the thesis into 7 chapters. Chapter 1 describes MANET and cognitive wireless networks in general in terms of motivation then follows by state of art and finally the whole thesis outline. In Chapter 2, we discuss the architecture of secure cognitive device. In Chapter 3, we discuss the different routing strategies for MANET.

AODV protocol in detail will be discussed in chapter 4.It covers the description of protocol modes and working, structure of various packets being transferred; procedures followed by the nodes in the particular modes. Chapter 5 discusses simulation tool (Ns-2).

Chapter 6 describes the simulation setup, analysis and results. Chapter 7 summarizes the conclusions drawn in the thesis along with future research directions.

Chapter 2: Secure Cognitive network device

Secure Cognitive network device is device which is based on cognitive cross layer architecture. It integrates a HF, VHF, UHF and 802.11 based mobile ad hoc network with GSM and Satellite networks. The controller in the device is based on cognitive cross-layer design. It automatically selects and switches to most optimal network technology based on pre-defined Quality of Service criteria. An interface table is maintained in SCND, this table consists of link status and their QoS values. For optimum connectivity link with best QoS parameter is selected.


Secure cognitive network device (SCND) architecture seamlessly integrates HF, VHF, UHF and 802.11 based mobile ad hoc network with two GSM/GPRS and Satellite networks for extended coverage.

Below is the system level diagram of secure cognitive network device [2].

Figure 2.1: System Level diagram of SCND

Following is the brief explanation of SCND layers.

2.1.1 Application and Services Layer:

SCND's first layer is 'application management and configuration' layer. This layer maintains the configuration of the services like location updates, GIS features, route guidance, congestion avoidance, internet service, weather forecasting and service area information etc

2.1.2 Crypto Engine Layer:

The main objective of crypto engines is to encrypt and decrypt data. Crypto engine layer consists of three type of engine, it includes authentication engine, cipher engine and key generation engine. Hashing algorithms like MD5, SHA-1, SHA256, SHAH384, SHA512, RIPEMD-128, RIPEMD-192 and TIGER are supported by authentication engine. The cipher engine can be configured for DES, 3-DES or AES. The main purpose of Key Generation engine is key generation and digital signature generation.

2.1.3 Cognitive controller layer:

The SCND architecture integrates heterogeneous networking technologies by a cognitive controller. The PHY and its corresponding MAC represents a complete radio that can be a HF, VHF, UHF, 802.11, 802.16, Ethernet, GSM or satellite. A customized MAC is proposed for HF, VHF and UHF radios in order to integrate with the cognitive controller. Cross-layer protocol design in cognitive controller is the extension of the layered network protocol architecture. The cross-layer mechanism gathers information by exchanging parameters between non-adjacent layers and thus controlling the offered flexibility of each protocol layer to adapt to the actual needs of communication. Cross-layer interactions among layers are achieved by a cross-layer information module, which in turn supports vertical communications among the layers.

Cognitive Network Management:

The following steps describe the detailed procedure of our cognitive network management.

Step 1: The application configures cognitive controller for QoS parameters, security levels and network interface priorities.

Step 2: The cognitive controller configures cryptographic parameters of crypto engines and sets QoS parameters and network interface priorities in the interfaces table.

Step 3: The proposed routing protocols dynamically maintain and update GPS info and Link State Table to form the routing table. The routing protocols provide decision variables like end-to-end delay, route errors, route replies etc. The PHY and MAC of all the radios send their corresponding SNR and traffic information to cognitive layer.

Step 4: The Cognitive layer decides the action to enhance performance and reconfigures the relevant routing parameters. The Interface Selection Logic of the Cognitive Controller selects the optimum link for data communication, based on the QoS parameters and interface priorities updated in the Link State Table.

2.1.4 Multiple Network Layer:

Figure2.2: Multiple Layer Architecture

The multi layer architecture of SCND is shown in figure 2.2[3]. Each layer represents a particular media type or a communication link. Each node in the network has multiple projections on all physical layers. Dotted lines in figure indicate the connectivity with the corresponding media type. The devices exchanging information over multiple links are said to be communicating in a hybrid network. The layer at the top represents Satellite network and layer 2 to layer 4 indicate UHF, VHF and 802.11 networks. The layer 4 indicates 802.16 networks while bottom two layers show the GPRS network. The devices can form hybrid networks between any layers. Though each layer has its own routing protocol but the overall network has the capability to perform across network routing utilizing different networks while meeting connectivity and QoS constraints. The objective of multi layer network architecture and the proposed routing protocols is to provide ubiquitous connectivity in self-forming self-healing heterogeneous networking environment.

Chapter 3: Mobile Ad-Hoc Networks (MANETs)

Collection of systems sharing information with each other is defines as 'Network'. Network can be classified as wired or wireless. In wireless network there is no physical connectivity between nodes.

Ad-Hoc Network is a type of wireless network in which nodes use multi hop link to communicate with each other. Each node itself acts as a router to send and receive packets to and from other nodes.

A Mobile Ad-Hoc Network (MANET) is an infrastructure less collection of mobile nodes that can arbitrarily change their physical locations.

MANET nodes are equipped with wireless transmitters and receivers. At a given time depending on the nodes positions and their transmitter and receiver coverage patterns and transmission power levels, a wireless connectivity in the form of a random, multi hop graph or ad-hoc network exists between the nodes. This ad-hoc topology may change with time as the nodes move or change their transmission and reception parameters.

The current applications of MANETs are in defense operations, emergency search and-rescue operations, meetings and conventions and other scenarios where quick sharing of information is desired without any fixed infrastructure available.

Bluetooth is the first commercial realizations of ad-Hoc wireless networks. In Bluetooth a piconet is formed by establishment of a single-hop (master node) point-to-point wireless link among group of nodes. A scatternet formed by multiple piconets (master nodes) can establish a multi-hop wireless network.

Mobile ad hoc networks (MANET) standards are being developed by the Internet Working Tasking Force (IETF) MANET working group.

3.1Routing in MANETs:

In MANET, each mobile node not only acts like a host but also acts like a router.As a router ,each mobile node forwards packets for other mobile nodes in the network.

Due to frequent topological changes in wireless networks, it is difficult to find and maintain routes.

Conventional routing protocols based on distance vector or link state algorithms cannot be applied here, since the amount of routing related traffic would waste a large portion of the wireless bandwidth, and such discovered routes would soon become obsolete due to mobility of nodes.

In Ad-hoc wireless networks, mobile node share same frequency channel. Therefore overall network capacity is less. That's why routing protocols for MANET should be bandwidth efficient.

Based on techniques of route discovery and route maintenance , MANETs routing protocols are classified in two categories:

(a) Proactive routing protocols such as DSDV, FSR, WRP , CGSR ,GSR .

(b) Reactive or On-demand routing protocols such as DSR, AODV, TORA , ABR etc.

3.1.1 Proactive Routing Protocols:

In the proactive routing protocols nodes continuously search for routing information within the network, so that when a route is needed it is already available. In Reactive routing protocols a route is searched when it is needed.

In the proactive routing protocols as compared to the on-demand routing protocols, a constant propagation of routing information is involved, which incurs substantial routing related traffic. Moreover such protocols require each mobile node to maintain routes to each possible target in the MANET, which most likely exceeds the requirements of any node and thus the routing overhead expended in establishing such unrequired routes is wasted. Since bandwidth is a scarce resource in MANETs, these limitations imposed by proactive routing protocols make them less attractive as compared to on-demand routing protocols in a bandwidth constrained MANET environment. ZRP presents a hybrid behavior of proactive and reactive routing schemes which has advantages and disadvantages of both the schemes, depending on the value chosen for zone radius parameter used to limit the scope of proactive scheme.

3.1.2 Reactive or on-demand routing protocols:

The on-demand routing protocols suggested for MANETs, such as Dynamic Source Routing (DSR) Protocol, Ad-Hoc On-Demand Distance Vector (AODV) Routing , Temporally Ordered Routing Algorithm (TORA) and Associativity Based Routing (ABR) etc are all basically make use of broadcast based methods for route discovery. They differ in their routing packet formats, data structures maintained by each node, various optimizations applied in route discovery and in their approach for maintaining routes.

In a broadcast based method, when an originator node wants to send data packets to a target node, and it does not have a valid route to this target node, it broadcasts a route request packet to its neighbors. These neighbors forward the route request packet to their neighbors and this process goes on until either the target node or an intermediate node with a valid route to target node is located. Each node receiving a particular route request packet broadcasts it only once to its neighbors, and it discards the subsequent receptions of the same route request packet, to minimize routing overhead. Duplicate receptions are detected using sequence numbers associated with route request packets. This method of route discovery floods the entire network with the route request packets thus this method of route discovery is also called Flooding Method. The shortcoming of Flooding Method is that it floods the entire network with the route requests even when the target node is just a few hops away from the originator node.

Figure 3.1 shows different routing approaches for Adhoc-Networks.

Routing Protocols for

Ad Hoc Wireless Networks

Miscellaneous Classification Based on Utilization of Specific Resources

Based on Topology Information Organization

Based on Use of Temporal Information for Routing

Based On

Routing Information

Update Mechanism

Routing Using Geographical information

Power Aware Routing

Routing with Flooding






Path SelectionUsing Path Prediction


Path Selection Using Past History













































Figure 3.1: List of Routing Protocols

Chapter 4: AODV

4.1 Ad hoc On Demand Distance Vector (AODV) routing algorithm:

The Ad hoc On Demand Distance Vector (AODV) routing algorithm is designed for ad hoc mobile networks. AODV supports both unicast and multicast routing. AODV builds routes between nodes only when desired by source nodes. It maintains these routes as long as they are necessary. Additionally, AODV forms trees which connect multicast group members. The trees are composed of the group members and the nodes needed to connect the members. AODV uses sequence numbers to ensure the freshness of routes. It is loop-free, self-starting, and scales to large numbers of mobile nodes.

AODV Properties:

It does not maintain routes from every node.

Routes are discovered on demand and maintained as long as they are necessary.

It is loop free at all times because it uses sequence numbers

Every node maintains its sequence number. Sequence number ensures that only the latest route is selected

It Provides unicast, multicast and broadcast communication.

Capable of operating on both wireless and wired media.

Route table stores the destination number, next-hop IP and destination sequence number.

Each multicast group has its own sequence number.This sequence number is maintained by the multicast group leader.

For each destination the node maintains a list of ancestor nodes.

The destination route is maintained for the purpose of route maintenance if the link breaks.

Lifetime is associated with each route, which is updated each time the route is used.

Builds routes with only a small amount of overhead.

Requires nodes to maintain only next-hop routing information, thereby decreasing the storage requirement at each mobile node.

4.1.1 Route Establishment:

When a node needs a route to a destination, it broadcasts a RREQ. Node having the destination route information sends RREP back to the source. Destination node also sends RREP to the source node

This procedure sets up a reverse path pointing towards the source. AODV assumes symmetric (bi-directional) links. Route information is maintained by each node in its route table. Information obtained through RREQ and RREP message is kept with other routing information in the route table.

Sequence numbers are used to eliminate the stale routes. Routes with old sequence numbers are aged out of the system. When the intended destination receives a Route Request, it replies by sending a Route Reply (RREP).Route Reply travels along the reverse path set-up when Route Request is forwarded.

4.1.2 Route Discovery:

Route discovery is the process of finding route to destination node. In the first step, source node checks its route table for destination node entry. If it finds,it send packet to next hop poiting to destination node.Other wise it needs to determine route to destination node.For this purpose it creates RREQ packet which contains following field:

Source node IP address

Current sequence number

Destination IP address

Destination last known sequence number

Broadcast ID, which is incremented for each RREQ

RREQ is uniquely identified by Broadcast ID and source IP address.

When a node receives a RREQ, it checks whether source IP address and broadcast ID pair. Each node keeps this record for a specified length of time. If the receiving node has already received RREQ from same node, it silently discards the packet, otherwise, it process the received RREQ packet.

To process the RREQ, the node sets up a reverse route entry for the source node in its route table, this reverse route entry contains

Source IP address

Sequence number

Number of hops to the source node

IP address of the neighbor from which the RREQ was received (next hop towards the source)

Life time - if this route entry is not used within the specified lifetime, it is deleted

The response of RREQ is RREP packet. This RREP is unicasted to source node.RREP is only sent to source node if it have an unexpired entry for the destination in its route table or the sequence number associated with that destination must be at least as great as that indicated in the RREQ. This prevents the formation of routing loop by ensuring that the route returned is never old enough to point to a previous intermediate node.

If it is unable to satisfy the RREQ, it increments the RREQ's hop count .It broadcasts the packet to its neighbors. If RREQ is lost, the source node retries route discovery mechanism .After rreq_retries additional attempts , it is required to notify the application that the destination is unreachable.

Source node sets the TTL value to an initial ttl_start value. If no reply is received within the discovery period, the next RREQ is broadcast with an increased value of TTL.This process repeats until TTL value reaches its threshold value. Beyond which the RREQ is broadcast across the entire network up to rreq_retries more times.

Route Requests in AODV

Figure 4.1: Route Request in AODV

Figure 4.2: Transmission of RREQ

4.1.3 Reverse Path Setup in AODV

Node C receives RREQ from G and H, but does not forward it again, because node C has already forwarded RREQ once.

Figure 4.3: Reverse path setup in AODV

In the following figure Node D does not forward RREQ, because node D is the intended target of the RREQ

4.1.4 Forward Path Setup:

Travelling of RREP salong reverse path setup forward links.

Forward links are setup when RREP travels along the reverse path. If the destination node is responding, it places its current sequence number in the packet, initialize the hop count to zero, and places the length of time this route is valid in the RREP's lifetime field. If an intermediate node is responding, it places the record of the destination's sequence number in the packet, sets the hop count equal to its distance from the destination, and calculates the amount of time for which its route table entry for the destination will still be valid. It unicast the RREP toward the source node, using the node from which it received the RREQ as the next hop.

When an intermediate node receives the RREP, it sets up a forward path entry to the destination in its route table.

This forward path entry contains the

Destination IP address

IP address of the neighbor from which the RREP arrived

Hop count to the destination

Life time

which is set to the lifetime contained in the RREP

Each time the route is used this life time is updated

If the route is not used within the specified life time, it is deleted

It is possible that source node get more than one RREP for a same destination. These RREP are sent by more than one neighbor. In this case, it forwards the first RREP receives and forwards a later RREP only if the RREP contains a greater destination sequence number or a smaller hop count. Otherwise, the node discards the packet.

This process ensures that source gets latest and quickest routing information. For better communication,AODV allows source node to start communication on getting first RREP. Source node can update its information if it discovers better route.

Forward Path Setup in AODV:

Forward links are setup when RREP travels along the reverse path.

Figure 4.4: Forward path setup is AODV

Route Request and Route Reply:

Route Request (RREQ) includes the last known sequence number for the destination. Intermediate node may also send a Route Reply (RREP) provided that it knows a more recent path than the one previously known to sender. Intermediate nodes that forward the RREP, also record the next hop to destination. Routing table entry maintaining a reverse path is purged after a timeout interval. Routing table entry maintaining a forward path is purged if not used for an active_route_timeout interval.

4.2 Link Failure Management in AODV:

A neighbor of node X is considered active for a routing table entry if the neighbor sent a packet within active_route_timeout interval which was forwarded using that entry .Neighboring nodes periodically exchange hello message. When the next hop link in a routing table entry breaks, all active neighbors are informed. Link failures are propagated by means of Route Error (RERR) messages, which also update destination sequence numbers.

RERR message is used to notify other nodes about link failure.It also mentions the destinations which are unreachable due to link loss.

When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred .The RERR message indicates those destinations which are no longer reachable by way of the broken link .To enable this each node keeps a "precursor list". This list contains the IP address for each its neighbors that are likely to use it as a next hop towards each destination.

Chapter 5: Introduction to Ns-2

5.1 Simulation:

Shannon defines simulation as the "the process of designing a model of a real system and conducting experiments with this model for the purpose of understanding the behavior of the system and/or evaluating various strategies for the operation of the system."

5.2 What is Ns-2?

Network Simulator (Ns) is a name for series of discrete event simulators, specifically ns-2 and ns-3. Both simulators are used in the simulation of routing protocols .Ns is especially used in ad-hoc networking research..

5.2.1 Basic Architecture of Ns-2:

Ns-2 is an object-oriented simulator .It is developed as part of the VINT project at the University of California in Berkeley. Ns-2 is extensively used by the networking research community. It provides support for simulation of TCP, routing, multicast protocols over wired and wireless (local and satellite) networks, etc.

Basic architecture of NS2 is shown in figure 5.1. NS2 provides users with shell executable command ns.This command takes one input argument, the name of a Tcl scripting. The result of this command is generation of a simulation trace file. This trace file is used to plot graph and/or to create animation.

Figure 5.1: Basic Architecture of NS

NS-2 is written in C++.An Object-oriented Tool Command Language (OTcl) interpreter is provided at front end.Internal mechanism of simulation objects is defined by C++.

C++ defines the internal mechanism of the simulation objects. TclCL provides linkage between C++ and OTcl. Variables in the OTcl domains are referred as handles. OTcl handle does not contain any functionality. Instead, the functionality is defined in the mapped C++ object .In the OTcl domain, a handle acts as a frontend which interacts with users and other OTcl objects. It may define its own procedures and variables to facilitate the interaction.

After the completion of simulation, trace file and animation-based files are generated. NAM(Network AniMator) is used to analyze animation-based files. X-graph, Tracegraph can be used to analyze trace files.


5.3 What is a Network Animator (NAM)?

Network Animator(NAM) takes packet trace data (either from ns or from real network traces) and presents it as a graphical animation of packets flowing on a network.NAM allows to examine interesting events, and to get an intuitive feel for what protocol is actually doing, the effects of queuing, topology. This information is difficult to get from traditional static graphical summaries of the same information.

Nam was first written by Steve McCanne in 1990, and functionality was enhanced slowly over time as required. Additional changes were added by Marylou Orayani, and more recently Nam has started to be supported by the VINT project, and significant additional functionality has started to be added. Nam is still in alpha-release form.

5.3.1 Nam's basic model of a network:

A network consists of nodes and links. An interface is simply a link leaving a node. Links can optionally have queues associated. Packets can be inserted into and taken out of queues. Packets are transmitted received on links. Packets can be dropped from queues or links. Agents can be associated with nodes or node-link interfaces. Agents can contain named "features" such as variables, timers, lists, etc. Routing information can also be associated with interfaces.

5.3.2 Nam 1.0 Tracefile generation:

NS 2.0 can generate tracefile directly to be used by Nam 1.0. Some additional commands can be added to the NS TCL script to specify link directions, node shapes and coloures of packets, links, etc. NS then uses this information along with information about propagation delay, link speed, etc to write a tracefile header followed by all the events to trace.

5.4 Ns-2 Trace File format:

N2-s trace file is organized in 12 fields as follows.



From Node

To Node

Pkt type

Pkt Size





Dst addr

Seq num

Pkt id

Explanation of fields is:

1-First field is event type. It can be r(receive),+(enqueued),-(dequeued),d(dropped).

2-Second field is event occurring time.

3-Third field is input node at which event occurs.

4-Fourth field is output node of link at which event occurs.

5-This is packet type. It can be CBR,tcp,udp etc.

6-This is size of packet.

7-These are flags.

8-This is flow id of IPV6 that can be set at the output of OT CL script.

9-This is the source address given in the form of "node.port".

10- This is the destination address given in the form of "node.port".

11-This is the network layer protocol's packet sequence number.

12 - This is unique packet id.

5.4.1 Explanation of AODV Trace format generated by NS-2

Figure 5.2 shows the ns-2 generated trace file for AODV simulation.

s 10.000000000 _1_ AGT --- 0 tcp 40 [0 0 0 0] ------- [1:0 5:0 32 0] [0 0] 0 0

r 10.000000000 _1_ RTR --- 0 tcp 40 [0 0 0 0] ------- [1:0 5:0 32 0] [0 0] 0 0

s 10.000000000 _1_ RTR --- 0 AODV 48 [0 0 0 0] ------- [1:255 -1:255 30 0] [0x2 1 1 [5 0] [1 4]] (REQUEST)

s 10.000115000 _1_ MAC --- 0 AODV 106 [0 ffffffff 2 800] ------- [1:255 -1:255 30 0] [0x2 1 1 [5 0] [1 4]] (REQUEST)

r 10.000963000 _0_ MAC --- 0 AODV 48 [0 ffffffff 2 800] ------- [1:255 -1:255 30 0] [0x2 1 1 [5 0] [1 4]] (REQUEST)

r 10.000963000 _4_ MAC --- 0 AODV 48 [0 ffffffff 2 800] ------- [1:255 -1:255 30 0] [0x2 1 1 [5 0] [1 4]] (REQUEST)

Figure 5.2: AODV trace file

In figure 5.2, the first column, r means "receive", s means "send", d means "drop", and f means "forward". And the second column is the time when event was triggered. The third column is the node number. Fourth column is this event is in which level, "RTR" means in routing level, "AGT" means in agent level, "MAC" means in MAC level. Then, the seventh column is the package type. Eighth column is the event ID.

Following is general form of AODV request packet.

[0x%x %d %d [%d %d] [%d %d]] (REQUEST),.General form of Operation packets (Reply,hello,error) is [0x%x %d [%d %d] %f] (%s) ,where 0x is for hexadecimal type,%d is for Integer value and %s is for string type value. Brief Description of all parameters is shown in following table.


[0x%x %d %d [%d %d] [%d %d]] (REQUEST)

Hexadecimal Type







[0x%x %d [%d %d] %f] %s







5.5 Tracegraph:

Trace graph is a free network trace files analyzer. It is developed for network simulator ns-2. Trace graph can support ns-2 generated trace file. Trace graph can be installed on Windows, Linux, UNIX and MAC OS systems. It requires Matlab 6.0 libraries.

Tracegraph supports following ns-2 trace file formats:



wireless (old and new trace)

new trace


It supports 2D and 3D graphs [5].

Chapter 6: Simulation setup, Analysis and Results

6.1 Simulation Setup:

Following things are required for successful simulation in ns-2.

1) Topological view of the network: The network topology includes the position of nodes with (x, y, z) coordinate, the node movement parameters, the movement starting time, movement direction.

2) Network Flow: This includes information about source/destination nodes, connection and kind of connection between nodes.

3) Configuration of the layered structure of each node in the network: this includes the detail configuration of network components on sensor node, and also we need to drive the simulation, so we need to give out where to give out the simulation results which is the trace file, and how to organize a simulation process.

6.1.1Explanation of Simple TCL script for AdHoc Wireless Networks:

In NS-2, the network is constructed using nodes which are connected using links. Events are scheduled to pass between nodes through the links. Nodes and links can have various properties associated with them. Agents can be associated with nodes and they are responsible for generating different packets (e.g. TCP agent or UDP agent). The traffic source is an application which is associated with a particular agent (e.g. Telnet application).

This is illustrated in Figure 6.1.


Link (wired, wireless,satellite)




Figure 6.1: NS-2 Network Architecture

The overall structure of an Tcl script is as follows

Event Schedule:

set ns [new Simulator] creates scheduler

$ns at <time> <event> schedule event at given time.

$ns run starts schedule.

Node Creation:

Simulator node object (ns) is used to create a node. 'Set' command is used to create node objects.


set n0 [$ns node]

set n1 [$ns node]

Node links Creation:

Ns-2 supports wireless, wired and satellite links. Wired link can be simplex or duplex.

Example of Simplex link between two nodes is as follows.

$ns simplex-link $n0 $n1 <bandwidth> <delay> <queue_type>

Example of duplex link between two nodes is as follows€ 

$ns duplex-link $n0 $n1 <bandwidth> <delay> <queue_type>

In above examples the link is between node 0 and node 1.Ns-2 supports different queue types FIFO, RED (Random Early Detection), Drop Tail, FQ (Fair Queuing), SFO(Stochastic).

Network Agents:

To send and receive traffic, agents are attatched to nodes.Application runs on top of agent. The application determines the kind of traffic that is simulated.

There are two types of agents in NS-2: UDP and TCP agents.

Example of UDP agent creation:

set udp-agent [new Agent/UDP]

set null-agent [new Agent/NULL]

$ns attach-agent $node1 $udp-agent

$ns attach-agent $node0 $null-agent

$ns connect $udp-agent $null-agent

This code first creates a 'UDP agent' and attaches it to 'udp-agent' using the attach-agent procedure.

It then creates a' Null agent', which acts as a traffic sink and attach it to 'null-agent'. Simulator method 'Connect' is used to connect udp and null agents .

…xample of TCP agent creation:

set tcp-agent [new Agent/TCP]

set tcp_sink [new Agent/TCPSink]

$ns attach-agent $node0 $tcp-agent

$ns attach-agent $node1 $tcp_sink

$ns connect $tcp-agent $tcp_sink

This code first creates a TCP agent and attaches it to the 'tcp-agent' node using the attach-agent procedure. It then creates a TCPSink agent, and attaches it to the node tcp_sink. The two agents are connected using the simulator method connect.

Traffic Applications:

UDP traffic Application:

There are four traffic applications that go on top of a UDP agent to simulate network traffic.

This includes CBR (Constant Bit Rate),Exponential, pareto and traffic generation using a trace file.

TCP traffic application:

Application/FTP and Application/Telnet are simulation application that are used to send traffic on a TCP object.

6.2 Simulation setup for Adhoc Wireless Networks:

The following script shows simple mobile node configuration in ns-2.This mobilenode supports multiple channels.

In NS-2 a mobilenode consists of network components like Link Layer (LL), Interface Queue (IfQ), MAC layer, the wireless channel nodes transmit and receive signals etc. First step of simulation script is the definition of the type network components. Other parameters like the type of antenna, the radio-propagation model, the type of ad-hoc routing protocol used by mobilenodes etc are defined in tcl script.

Wirelesstest.tcl is an example tcl script. It shows the configuration required by mobile node.Each variable is defined by comments in front of it.

6.2.1 Wirelesstest.tcl:

Example script given below starts with definition of network components.

set value(channel) Channel/WirelessChannel ;#Channel Type

set value(propagation) Propagation/TwoRayGround ;# radio-propagation model

set value(netifterface) Phy/WirelessPhy ;# network interface type

set value(mac_802_11) Mac/802_11 ;# MAC type

set value(ifq) Queue/DropTail/PriQueue ;# interface queue type

set value(link_layer) LL ;# link layer type

set value(antenna) Antenna/OmniAntenna ;# antenna model

set value(ifqlength) 50 ;# max packet in ifq

set value(ni) 4 ;#number of interfaces

set value(nn) 13 ;# number of mobilenodes

set value(routingprotocol) AODV ;# routing protocol

set value(x) 500 ;# x -axis

set value(y) 500 ;# y-axis

#Event scheduler creation:

set ns_ [new Simulator]

#Open tracefile for writing.

set tracefd [open im3p1.tr w]

#Procedure trace-all to get simulation trace

$ns_ trace-all $tracefd

#Open nam file for writing nam trace.

set namtrace [open im3p.nam w]

$ns_ namtrace-all-wireless $namtrace $value(x) $value(y)

# topo is a topological object.It records data of movements of mobile nodes in topological area defined by value(x) and value (y)

set topo1 [new Topography]

load_flatgrid provides topography object valueues of x and y.

$topo load_flatgrid $value(x) $value(y)

Following for loop is used to create number of interfaces.

for {set i 0} {$i < $value(ni)} {incr i} {

set chan_($i) [new $value(chan)]


"God (General Operations Director) is the object that is used to store global information about the state of the environment, network or nodes that an omniscent observer would have, but that should not be made known to any participant in the simulation." God object stores the total number of mobilenodes and a table of shortest number of hops required to reach from one node to another. Before the start of simulation,movement pattern provides god object next hop information.

The procedure create-god is defined in ~ns/tcl/mobility/com.tcl. A single global instance of the God object can be created during a simulation.

create-god [expr $value(nn)*$value(ni)]

$ns_ node-config -adhocRouting $value(routingprotocol) \

-llType $value(link_layer) \

-macType $value(mac_802_11) \

-ifqType $value(ifq) \

-ifqLen $value(ifqlen) \

-antType $value(antenna) \

-propType $value(propagation) \

-phyType $value(netifterface) \

-channel $chan_(0) \

-topoInstance $topo1 \

-agentTrace ON \

-routerTrace ON \

-macTrace ON \

-movementTrace OFF \

-ifNum $value(ni)

Change-numifs is used to change number of interfaces of a node. These interfaces can be GSM/GPRS,UHF,VHF Ethernet etc.

$ns_ change-numifs 3

$ns_ add-channel 0 $chan_(1)

$ns_ add-channel 1 $chan_(2)

$ns_ add-channel 2 $chan_(3)

set node_(0) [$ns_ node]

$node_(0) random-motion 0

$ns_ change-numifs 1

$ns_ add-channel 0 $chan_(1)

#$ns_ add-channel 1 $chan_(2)

set node_(1) [$ns_ node]

$node_(1) random-motion 0

$ns_ change-numifs 1

$ns_ add-channel 0 $chan_(0)

#$ns_ add-channel 1 $chan_(2)

set node_(2) [$ns_ node]

$node_(2) random-motion 0

for {set i 0} {$i < $value(nn)} {incr i} {

$ns_ initial_node_pos $node_($i) 40


# TCP connections between nodes

set tcp1 [new Agent/TCP]

set sink1 [new Agent/TCPSink]

$ns_ attach-agent $node_(4) $tcp1

$ns_ attach-agent $node_(6) $sink1

$ns_ connect $tcp1 $sink1

set ftp1 [new Application/FTP]

$ftp1 attach-agent $tcp1

$ns_ at 20.0 "$ftp1 start"

$ns_ at 130.0 "$ftp1 stop"

set tcp2 [new Agent/TCP]

set sink2 [new Agent/TCPSink]

$ns_ attach-agent $node_(2) $tcp2

$ns_ attach-agent $node_(3) $sink2

$ns_ connect $tcp2 $sink2

set ftp2 [new Application/FTP]

$ftp2 attach-agent $tcp2

$ns_ at 25.0 "$ftp2 start"

$ns_ at 135.0 "$ftp2 stop"


for {set i 0} {$i < $value(nn) } {incr i} {

$ns_ at 150.0 "$node_($i) reset";#'150.0 is simulation ending time'


$ns_ at 150.0001 "stop_now"

$ns_ at 150.0002 "puts \"NS EXITING...\" ; $ns_ halt"

proc stop_now {} {

global ns_ tracefd

close $tracefd


puts "Starting Simulation..."

$ns_ run

6.3 Analysis and Results:

Now we will discuss performance evaluation of AODV over multi channels. Analysis is being done on the basis of results of nam and trace file.Nam is used to show the simulation. Tracegraph is being used to see 2-D and 3-D graphs.

Following scenarios are simulated:

Scenario 1: There are 13 nodes in simulation. Node or SCND 2, 3, 5 form MANET on UHF. Node 0,6,4,1,7 form MANET on VHF. Nodes 8,12,10,4 form MANET on 802.11.Over node 0 802.11 is also enabled. Nodes 9, 12,11 form MANET on GPRS. Node 12 also has 802.11 interface.Following diagram shows details.





MANET on 802.11




Figure 6.2: Multi layer Architecture

Communication within same MANET do not require multi interface. For across layer communication, node having multi interface is required. Following results shows communication between node 3 ,2 and 4,6.

Following figure shows number of sent bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\scen7_network info.jpg

Figure 6.3: Number of sent bytes

Following graph shows number of received bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\scen6_network info.jpg

Figure 6.4: Number of receive bytes

Following graph shows number of drop bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\scen5_network info.jpg

Figure 6.5: Number of drop bytes

Following graph shows complete simulation information.

C:\Documents and Settings\Sadia\Desktop\scen1\scen4_network info.jpg

Figure 6.6: Simulation Information

Scenario #2:

There are 6 nodes and 3 channels. Node 2 and 3 form MANET over UHF. Node 1 and 4 form MANET over GPRS. Node 0 ,4 and 5 form MANET over VHF.

Communication between node 5 and 1 will be carried using Node 4.

During communication node 4 link over VHF goes down. Communication will lost between node 5 and 1.Following 'nam' animation shows this.

C:\Documents and Settings\Sadia\Desktop\scen1\no_comm_when_node4move.jpg

Figure 6.7 : Communication loss

Following table shows overall simulation information.

Simulation length in seconds: 136.5087906

Number of nodes: 7

Number of sending nodes: 5

Number of receiving nodes: 5

Number of generated packets: 42607

Number of sent packets: 42585

Number of forwarded packets: 5230

Number of dropped packets: 44

Number of lost packets: 5876

Minimal packet size: 28

Maximal packet size: 1118

Average packet size: 176.3121

Packets dropping nodes: 1 4 5

Following graph shows number of sent bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\imnod5mov-1.jpg

Figure 6.8: Number of Sent bytes

Following graph shows number of received bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\imnod6mov-1.jpg

Figure 6.9: Number of received bytes

Following graph shows number of dropped bytes.

C:\Documents and Settings\Sadia\Desktop\scen1\imnod4mov-1.jpg

Figure 6.10: Number of dropped bytes

Following statistics shows, number of sent, received, drop packets across node #1

Number of generated packets: 10639

Number of sent packets: 10638

Number of forwarded packets: 0

Number of received packets: 10491

Number of dropped packets: 14

Number of lost packets: 0

Minimal packet size: 28

Maximal packet size: 1118

Average packet size: 176.4003

Following statistics shows, number of sent, received, drop packets across node #4

Number of generated packets: 21296

Number of sent packets: 21296

Number of forwarded packets: 5230

Number of received packets: 20952

Number of dropped packets: 22

Number of lost packets: 0

Minimal packet size: 28

Maximal packet size: 1118

Average packet size: 218.6972

Following statistics shows, number of sent, received, drop packets across node #5

Number of generated packets: 10652

Number of sent packets: 10652

Number of forwarded packets: 0

Number of received packets: 10481

Number of dropped packets: 8

Number of lost packets: 0

Minimal packet size: 28

Maximal packet size: 1060

Average packet size: 176.2004

Scenario #3:

This scenario is similar to scenario # 2 except that now node '0' also has GPRS capability.

In this case if node 4's GPRS link goes down, communication between node 1 and 5 will be carried through node '0'.Following 'nam' animation shows this.

C:\Documents and Settings\Sadia\Desktop\scen1\comm_when_node4move.jpg

Figure 6.11: communiaction remains active

Following table shows over all simulation information

Simulation length in seconds: 135.2136059

Number of nodes: 8

Number of sending nodes: 7

Number of receiving nodes: 7

Number of generated packets: 176654

Number of sent packets: 176639

Number of forwarded packets: 21752

Number of dropped packets: 33

Number of lost packets: 32570

Minimal packet size: 28

Maximal packet size: 1118

Average packet size: 179.6105

Packets dropping nodes: 1 4 5

Following graph shows number of sent bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\nodemov-sent-bytes2.jpg

Figure 6.12: Number of Sent Bytes

Following figure number of received bytes at all nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\nodemov-receive-bytes1.jpg

Figure 6.13: Number of received bytes

Following figure shows number of drop bytes at all the nodes.

C:\Documents and Settings\Sadia\Desktop\scen1\nodemov-drop-bytes.jpg

Figure 6.14: Number of dropped bytes

Following statistics shows, number of sent, received, drop packets across node #1

Number of generated packets: 44145

Number of sent packets: 44144

Number of forwarded packets: 0

Number of received packets: 43516

Number of dropped packets: 11

Number of lost packets: 0

Minimal packet size: 28

Maximal packet size: 1118

Average packet size: 176.3099

Following statistics shows, number of sent, received, drop packets across node #4

Number of generated packets: 21288

Number of sent packets: 21288

Number of forwarded packets: 5237

Number of received packets: 20971

Number of dropped packets: 14

Number of lost packets: 0

Minimal packet size: 28

Maximal packet size: 1118

Average packet size: 218.7044

Following statistics shows, number of sent, received, drop packets across node #5

Number of generated packets: 44175

Number of sent packets: 44175

Number of forwarded packets: 0

Number of received packets: 43522

Number of dropped packets: 8

Number of lost packets: 0

Minimal packet size: 28

Maximal packet size: 1060

Average packet size: 176.2395

Simulation analysis:

Scenario 2 and 3 both shows devices which have more than one physical interface. But if we increase number of SCND in network, it shows improve results. As shown in results of scenario 2 and 3.For same statistics, scenario# 3 shows better performance and less number of packet drop.

Chapter 7: Future Work

In this simulation, nodes are not capable of selecting outgoing interface based on cost and Qos. In future this option also need to be simulated.