![Installation
NS2 is a free simulation tool, which can be obtained from [1]. It runs on various platforms including UNIX (or
Linux), Windows, and Mac systems. Being developed in the UNIX environment, with no surprise, NS2 has the
smoothest ride there, and so does its installation. NS2 source codes are distributed in two forms: the all-in-one
suite and the component-wise. With the all-in-one package, users get all the required components along with some
optional components. This is basically a recommended choice for the beginners. This package provides an “install”
script which configures the NS2 environment and creates NS2 executable file using the “make” utility.
The current all-in-one suite consists of the following main components:
• NS release 2.35,
• Tcl/Tk release 8.4.13,
• OTcl release 1.12, and
• TclCL release 1.18.
And the following are the optional components:
• NAM release 1.12: NAM is an animation tool for viewing network simulation traces and packet traces.
• Zlib version 1.2.3: This is the required library for NAM.
• Xgraph version 12.1: This is a data plotter with interactive buttons for panning, zooming, printing, and selecting
display options.
The idea of the component-wise approach is to obtain the above pieces and install them individually. This option
save considerable amount of downloading time and memory space. However, it could be troublesome for the
beginners, and is therefore recommended only for experienced users.
Installing an All-In-One NS2 Suite on Unix-Based Systems
The all-in-one suite can be installed in the Unix-based machines by simply running the install script and following
the instructions therein. The only requirement is a computer with a C++ compiler installed. The following commands
show how the all-in-one NS2 suite can be installed and validated, respectively:
shell>./install
shell>./validate
Validating NS2 involves simply running a number of working scripts that verify the essential functionalities of the
installed components.
[1]http://en.sourceforge.jp/projects/sfnet_nsnam/downloads/allinone/ns-allinone-2.35/ns-allinone-2.35.tar.gz/
Directories
Suppose that NS2 is installed in directory nsallinone-2.35. Below Figure shows the directory structure under
directory nsallinone-2.35. Here, directory nsallinone-2.35 is on the Level 1. On the Level 2, directory tclcl-1.18
contains classes in TclCL (e.g., Tcl, TclObject, TclClass). All NS2 simulation modules are in directory ns-2.35 on
the Level 2. Hereafter, we will refer to directories ns-2.35 and tclcl-1.18 as ˜ns/ and ˜tclcl /, respectively.
On Level 3, the modules in the interpreted hierarchy are under directory tcl. Among these modules, the frequently-
used ones (e.g., ns-lib.tcl, ns-node.tcl, ns-link.tcl) are stored under directory lib on Level 4. Simulation modules in
the compiled hierarchy are classified in directories on Level 2. For example, directory tools contains various helper
classes such as random variable generators. Directory common contains basic modules related to packet
forwarding such as the simulator, the scheduler, connector and packet. Directories queue, tcp and trace contain
modules for queue, TCP (Transmission Control Protocol), and tracing respectively.](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-7-320.jpg)
![Running NS2 Simulation
NS2 Program Invocation
After the installation and/or recompilation (see Section 2.7), an executable file ns is created in the NS2 home
directory. NS2 can be invoked by executing the following statement from the shell environment:
>>ns [<file>] [<args>]
where <file> and <args> are optional input argument. If no argument is given, the command will bring up an NS2
environment, where NS2 waits to interpret commands from the standard input (i.e., keyboard) line-by-line.
If the first input argument <file> is given, NS2 will interpreted the input scripting <file> (i.e., a so-called Tcl
simulation script) according to the Tcl syntax. The detail for writing a Tcl scripting file is given in Appendix A.1.
Finally, the input arguments <args>, each separated by a white space, are fed to the Tcl file <file>. From within the
file <file>, the input argument is stored in the built-in variable argv (see Appendix A.1.1).
Main NS2 Simulation Steps
The followings show the three key step guideline in defining a simulation
scenario in a NS2:
Step 1: Simulation Design
The first step in simulating a network is to design the simulation. In this step, the users should determine the
simulation purposes, network configuration and assumptions, the performance measures, and the type of expected
results.
Step 2: Configuring and Running Simulation
This step implements the design in the first step. It consists of two phases:
• Network configuration phase: In this phase network components (e.g. node, TCP and UDP) are created and
configured according to the simulation design. Also, the events such as data transfer are scheduled to start at a
certain time.
• Simulation Phase: This phase starts the simulation which was configured in the Network Configuration Phase. It
maintains the simulation clock and executes events chronologically. This phase usually runs until the simulation
clock reached a threshold value specified in the Network Configuration Phase.
In most cases, it is convenient to define a simulation scenario in a Tcl scripting file (e.g., <file>) and feed the file as
an input argument of an NS2 invocation (e.g., executing “ns <file>”).
Step 3: Post Simulation Processing
The main tasks in this steps include verifying the integrity of the program and evaluating the performance of the
simulated network. While the first task is referred to as debugging, the second one is achieved by properly
collecting and compiling simulation results.](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-8-320.jpg)
![the packets it just sent by overhearing. If the packet is not forwarded within a certain period, the neighbor is
regarded as misbehaving in this transaction. The overhearing ability is shown below:
Steps For Adding Malicious Node In AODV Protocol Of MANETS
Adding a malicious node is ns2 using aodv protocol. The node which is declared as malicious will simply drop the
router packet (DROP_RTR_ROUTE_LOOP).
Two files have to be modified.
1. aodv.h
2. aodv.cc
aodv.h file changes
Declare a boolean variable malicious as shown below in the protected scope in the class AODV
bool malicious;
aodv.cc file changes
1. Initialize the malicious varible with a value "false". Declare it inside the constructor as shown below
AODV::AODV(nsaddr_t id):Agent(PT_AODV)...
{
.......
malicious = false;
}
2. Add the following statement to the aodv.cc file in the "if(argc==2)" statment.
if(strcmp(argv[1], "malicious") == 0) {
malicious = true;
return TCL_OK;
}
3. Implement the behavior of the malicious node by setting the following code in the rt_resolve(Packet *p) function.
The malicious node will simply drop the packet as indicated below.
if(malicious==true)
{
drop(p,DROP_RTR_ROUTE_LOOP);
}
Recompiled the Ns2 given below:](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-15-320.jpg)
![Open Terminal -> Go to ~ns-2.35/ directory and type the command make to compile
$ cd /home/ambii/Downloads/ns-allinone-2.35/ns-2.35/
$ make clean
$ make
$ sudo make install
Once the compilation is done, set any one node as malicious node. The command to set the malicious node is
$ns at 0.0 "[$n(1) set ragent_] malicious"
The variable referred for node2 is n1 (set n(1) [$ns node]).
For Tcl Script I used the following code for setting nodes and showing output in MANETS:
#======================================================================
# Define options
#======================================================================
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(ant) Antenna/OmniAntenna ;# Antenna type
set val(ll) LL ;# Link layer type
set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type
set val(ifqlen) 50 ;# max packet in ifq
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(nn) 6 ;# number of mobilenodes
set val(rp) AODV ;# routing protocol
set val(x) 800
set val(y) 800
set ns [new Simulator]
#ns-random 0
set f [open out.tr w]
$ns trace-all $f
set namtrace [open out.nam w]
$ns namtrace-all-wireless $namtrace
$val(x) $val(y)
set topo [new Topography]
$topo load_flatgrid 800 800
create-god $val(nn)
set chan_1 [new $val(chan)]
set chan_2 [new $val(chan)]
set chan_3 [new $val(chan)]
set chan_4 [new $val(chan)]
set chan_5 [new $val(chan)]
set chan_6 [new $val(chan)]](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-16-320.jpg)
![# CONFIGURE AND CREATE NODES
$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)
#-channelType $val(chan)
-topoInstance $topo
-agentTrace ON
-routerTrace ON
-macTrace ON
-movementTrace OFF
-channel $chan_1
proc finish {} {
global ns namtrace
$ns flush-trace
close $namtrace
exec nam -r 5m out.nam &
exit 0
}
# define color index
$ns color 0 blue
$ns color 1 red
$ns color 2 chocolate
$ns color 3 red
$ns color 4 brown
$ns color 5 tan
$ns color 6 gold
$ns color 7 black
set n(0) [$ns node]
$ns at 0.0 "$n(0) color blue"
$n(0) color "0"
$n(0) shape "circle"
set n(1) [$ns node]
$ns at 0.0 "$n(1) color red"
$n(1) color "blue"
$n(1) shape "circle"
set n(2) [$ns node]
$n(2) color "tan"
$n(2) shape "circle"
set n(3) [$ns node]
$n(3) color "red"
$n(3) shape "circle"
set n(4) [$ns node]
$n(4) color "tan"
$n(4) shape "circle"
set n(5) [$ns node]
$ns at 0.0 "$n(5) color blue"
$n(5) color "red"
$n(5) shape "circle"](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-17-320.jpg)
![for {set i 0} {$i < $val(nn)} {incr i} {
$ns initial_node_pos $n($i) 30+i*100
}
#$ns at 0.0 "[$n(1) set ragent_] malicious"
$ns at 0.0 "$n(0) setdest 100.0 100.0 3000.0"
$ns at 0.0 "$n(1) setdest 200.0 200.0 3000.0"
$ns at 0.0 "$n(2) setdest 300.0 200.0 3000.0"
$ns at 0.0 "$n(3) setdest 400.0 300.0 3000.0"
$ns at 0.0 "$n(4) setdest 500.0 300.0 3000.0"
$ns at 0.0 "$n(5) setdest 600.0 400.0 3000.0"
# CONFIGURE AND SET UP A FLOW
set sink0 [new Agent/LossMonitor]
set sink1 [new Agent/LossMonitor]
set sink2 [new Agent/LossMonitor]
set sink3 [new Agent/LossMonitor]
set sink4 [new Agent/LossMonitor]
set sink5 [new Agent/LossMonitor]
$ns attach-agent $n(0) $sink0
$ns attach-agent $n(1) $sink1
$ns attach-agent $n(2) $sink2
$ns attach-agent $n(3) $sink3
$ns attach-agent $n(4) $sink4
$ns attach-agent $n(5) $sink5
#$ns attach-agent $sink2 $sink3
set tcp0 [new Agent/TCP]
$ns attach-agent $n(0) $tcp0
set tcp1 [new Agent/TCP]
$ns attach-agent $n(1) $tcp1
set tcp2 [new Agent/TCP]
$ns attach-agent $n(2) $tcp2
set tcp3 [new Agent/TCP]
$ns attach-agent $n(3) $tcp3
set tcp4 [new Agent/TCP]
$ns attach-agent $n(4) $tcp4
set tcp5 [new Agent/TCP]
$ns attach-agent $n(5) $tcp5
proc attach-CBR-traffic { node sink size interval } {
#Get an instance of the simulator
set ns [Simulator instance]
#Create a CBR agent and attach it to the node
set cbr [new Agent/CBR]
$ns attach-agent $node $cbr
$cbr set packetSize_ $size
$cbr set interval_ $interval
#Attach CBR source to sink;
$ns connect $cbr $sink
return $cbr
}
set cbr0 [attach-CBR-traffic $n(0) $sink5 1000 .030]
$ns at 0.5 "$cbr0 start"
$ns at 5.5 "finish"](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-18-320.jpg)
![puts "Start of simulation.."
$ns run
For implementing Watchdog mechanism, promiscuous mode should be enabled so that nodes in
MANETS could overhear their nest hop neighborhood nodes for monitoring the packet transmission so I
used the following code enabling promiscuous mode in MANETS:
1)In ns-allinone-2.34/ns-2.34/aodv/aodv.h, I made changes shown in blue:
#include <mac.h>
class AODV: public Tap, public Agent {
public:
void tap(const Packet *p);
......
protected:
Mac *mac_;
......
}
2 ns-allinone-2.34/ns-2.34/aodv/aodv.cc
int
AODV::command(int argc, const char* const * argv) {
......
else if(argc == 3) {
......
else if (strcmp(argv[1], "install-tap") == 0) {
mac_ = (Mac*)TclObject::lookup(argv[2]);
if (mac_ == 0) return TCL_ERROR;
mac_->installTap(this);
return TCL_OK;
}
}
return Agent::command(argc, argv);
}
void
AODV::tap(const Packet *p) {
}
3) ns-allinone-2.34/ns-2.34/tcl/lib/ns-mobilenode.tcl
Node/MobileNode instproc add-target { agent port } {
$self instvar dmux_ imep_ toraDebug_ mac_
......
# Special processing for AODV
set aodvonly [string first "AODV" [$agent info class]]
if {$aodvonly != -1 } {
$agent if-queue [$self set ifq_(0)] ;
# ifq between LL and MAC
$agent install-tap $mac_(0)
}](https://image.slidesharecdn.com/1a7f9668-054d-4e15-8824-a9ded5a9cf4a-150629120450-lva1-app6891/85/Final-Report-Routing_Misbehavior-19-320.jpg)
Final Report(Routing_Misbehavior)
- 1. 4/25/2015 Final Report Simulation of Routing Misbehavior in MANETS & Its Mitigation Using NS-2 Submitted To: Mr. Shua Hussain Course : Advance Computer Networks Course ID : 69135 Submitted By : Ambreen Zafar Registration No : 57337
- 2. Acknowledgement I found Advance Computer Networks is quite interesting course. Our instructor Mr. Shua Hussain gave the in-depth knowledge of computer networks especially in Mobile Networks which also created an interest in me to do any project regarding Mobile Ad hoc Networks through which I could learn and gain more knowledge of Network’s setup and its behavior in different scenarios. Therefore, detailed knowledge of mobile networks influenced me to adopt a scenario which gave me the opportunity to learn new and advance mobile networks protocols and their characteristics and performance in certain conditions.
- 3. Abstract A Mobile Ad hoc Network (MANET) is a collection of wireless mobile nodes which may form a temporary network, without the use of any fixed infrastructure or centralized administration. Nodes rely on multi-hop routing protocols to forward data packets sent from a source node to a destination node which is out of its transmission range. Every node may function as both a data source and a router that forward data for other nodes. Routing protocols for MANETs are designed based on the assumption that all participating nodes are fully cooperative. However, due to the open structure and scarcely available battery-based energy, node misbehaviors may exist. One such routing misbehavior is that some selfish nodes will participate in the route discovery and maintenance processes but refuse to forward data packets. To mitigate this problem, I categorized misbehaving nodes based upon their dynamically measured behavior. I used a watchdog that identifies misbehaving nodes and a path rater that helps routing protocols avoid these nodes. Through simulation in NS-2, I have evaluated watchdog and path rater using packet throughput, percentage of overhead (routing) transmissions. When used together in a network with moderate mobility, the two techniques increase throughput by 17% in the presence of 40% misbehaving nodes, while increasing the percentage of overhead transmissions from the standard routing protocol's 9% to 17%. During extreme mobility, watchdog and path rater can increase network throughput by 27%, while increasing the overhead transmissions from the standard routing protocol's 12% to 24%.
- 4. Introduction There has been a tremendous growth in the use of wireless communication in the past few decades. Mobile Ad hoc Network (MANET) is one of the most important one among various wireless communication mechanisms. In MANET, each node in a network performs as both a transmitter and a receiver. They rely on each other to store and forward packets. Its unique infrastructure less network and self-configuring capability makes it ideal for many mission critical applications, including military use and remote exploration. However, these characteristics also make MANET vulnerable to passive and active attacks due to its open medium, changing topology and lack of centralized monitoring. Nodes rely on multi-hop routing protocols to forward data packets sent from a source node to a destination node which is out of its transmission range. Every node may function as both a data source and a router that forward data for other nodes. The problem of all the current ad hoc routing protocols is that they trust all nodes and assume that they behave properly; therefore they are vulnerable to attacks launched by misbehaving nodes. Nodes misbehave because they are malfunctioning, selfish or malicious. Malfunctioning nodes are simply suffering from hardware failure or software errors. Selfish nodes can agree to forward packets on behalf of other nodes but silently drop the packets in attempt to save their resources (energy and bandwidth). Malicious nodes may try to sabotage other nodes or even the whole network, for example one malicious node can advertise itself as having the shortest path to all nodes in the network then it can cause Denial of Service (DoS) by dropping all the received packets, in Black hole attack, or selectively dropping packets in Gray hole attack.
- 5. Simulation Environment All the simulation work has been carried out on Intel 4th generation Core i3 1.9 GHz Guest Linux Virtual machine(VM Ware) having Ubuntu 14.0.4 operating system installed and running. The network simulator NS2 version 2.35 is used for simulating Ad hoc routing protocols (AODV). The languages used for writing the simulation script was tcl and well known C++ language. Beside these, other tools which proved helpful during simulation and trace file analysis are XGraph. Below Table shows the summary of these parameters used in carrying out all the simulation experiments. Factor Value Processor 4th Gen. Core i3, 1.90 GHZ Operating System Ubuntu 14.0.4 Guest Simulation Environment NS-2.35 Programming Language TCL Extra Xgraph, NAM NS-2 The Network Simulator (NS-2) is a most widely used network simulator. Network Simulator (Version 2), known as NS2, is simply an event driven simulation tool that has proved useful in studying the dynamic nature of communication networks. Simulation of wired as well as wireless network functions and protocols (e.g., routing algorithms, TCP, UDP) can be done using NS2. In general, NS2 provides users with a way of specifying such network protocols and simulating their corresponding behaviors. Due to its flexibility and modular nature, NS2 has gained constant popularity in the networking research community since its birth in 1989. Ever since, several revolutions and revisions have marked the growing maturity of the tool. NS2 consists of two key languages: C++ and Object-oriented Tool Command Language (OTcl). While the C++ defines the internal mechanism (i.e. a backend) of the simulation objects, the OTcl sets up simulation by assembling and configuring the objects as well as scheduling discrete events (i.e., a frontend). The C++ and the OTcl are linked together using TclCL. Mapped to a C++ object, variables in the OTcl domains are sometimes referred to as handles. Conceptually, a handle (e.g., n as a Node handle) is just a string (e.g._o10) in the OTcl domain, and does not contain any functionality. Instead, the functionality (e.g., receiving a packet) is defined in the mapped C++ object (e.g., of class Connector). In the OTcl domain, a handle acts as a frontend which interacts with users and other OTcl objects. It may defines its own procedures and variables to facilitate the interaction. Note that the member procedures and variables in the OTcl domain are called instance procedures (instprocs) and instance variables (instvars), respectively. Before proceeding further, the readers are encouraged to learn C++ and OTcl languages. NS2 provides users with an executable command ns which takes on input argument, the name of a Tcl simulation scripting file. Users are feeding the name of a Tcl simulation script (which sets up a simulation) as an input argument of an NS2 executable command ns. In most cases, a simulation trace file is created, and is used to plot graph and/or to create animation.
- 6. Simulation Overview A general simulation methodology by using network simulator is given through flow chart in Figure below, which shows three major phases of NS-2 simulation including phase before the simulation, phase during the execution and phase after the simulation. All the phases are discussed in the following subsection. Pre-Simulation Phase Pre-simulation phase consists of the process of generating the scenario file which explains the number of nodes, topology, model of movement of the nodes and etc. This includes the generation of communication file which explains the traffic model in the network, the final step is to write Tcl script for the simulation of the particular Protocol. Ns-2 Execution Phase Execution phase gets input through the Tcl script written in preceding phase and generates a rough form of data called trace file. This file contains the results obtained through simulation execution and gives the complete information of time of execution; participating nodes; how much data and control packets arrived; transmitted, Forwarded and dropped. Post-Simulation phase The major goal of the post-simulation procedure is to extract the useful information from a rough and huge data file which is the previously discussed trace file generated in execution phase. Scripting languages like awk and perl can be utilized to convert the trace file in that format which is suitable for XGraph.
- 7. Installation NS2 is a free simulation tool, which can be obtained from [1]. It runs on various platforms including UNIX (or Linux), Windows, and Mac systems. Being developed in the UNIX environment, with no surprise, NS2 has the smoothest ride there, and so does its installation. NS2 source codes are distributed in two forms: the all-in-one suite and the component-wise. With the all-in-one package, users get all the required components along with some optional components. This is basically a recommended choice for the beginners. This package provides an “install” script which configures the NS2 environment and creates NS2 executable file using the “make” utility. The current all-in-one suite consists of the following main components: • NS release 2.35, • Tcl/Tk release 8.4.13, • OTcl release 1.12, and • TclCL release 1.18. And the following are the optional components: • NAM release 1.12: NAM is an animation tool for viewing network simulation traces and packet traces. • Zlib version 1.2.3: This is the required library for NAM. • Xgraph version 12.1: This is a data plotter with interactive buttons for panning, zooming, printing, and selecting display options. The idea of the component-wise approach is to obtain the above pieces and install them individually. This option save considerable amount of downloading time and memory space. However, it could be troublesome for the beginners, and is therefore recommended only for experienced users. Installing an All-In-One NS2 Suite on Unix-Based Systems The all-in-one suite can be installed in the Unix-based machines by simply running the install script and following the instructions therein. The only requirement is a computer with a C++ compiler installed. The following commands show how the all-in-one NS2 suite can be installed and validated, respectively: shell>./install shell>./validate Validating NS2 involves simply running a number of working scripts that verify the essential functionalities of the installed components. [1]http://en.sourceforge.jp/projects/sfnet_nsnam/downloads/allinone/ns-allinone-2.35/ns-allinone-2.35.tar.gz/ Directories Suppose that NS2 is installed in directory nsallinone-2.35. Below Figure shows the directory structure under directory nsallinone-2.35. Here, directory nsallinone-2.35 is on the Level 1. On the Level 2, directory tclcl-1.18 contains classes in TclCL (e.g., Tcl, TclObject, TclClass). All NS2 simulation modules are in directory ns-2.35 on the Level 2. Hereafter, we will refer to directories ns-2.35 and tclcl-1.18 as ˜ns/ and ˜tclcl /, respectively. On Level 3, the modules in the interpreted hierarchy are under directory tcl. Among these modules, the frequently- used ones (e.g., ns-lib.tcl, ns-node.tcl, ns-link.tcl) are stored under directory lib on Level 4. Simulation modules in the compiled hierarchy are classified in directories on Level 2. For example, directory tools contains various helper classes such as random variable generators. Directory common contains basic modules related to packet forwarding such as the simulator, the scheduler, connector and packet. Directories queue, tcp and trace contain modules for queue, TCP (Transmission Control Protocol), and tracing respectively.
- 8. Running NS2 Simulation NS2 Program Invocation After the installation and/or recompilation (see Section 2.7), an executable file ns is created in the NS2 home directory. NS2 can be invoked by executing the following statement from the shell environment: >>ns [<file>] [<args>] where <file> and <args> are optional input argument. If no argument is given, the command will bring up an NS2 environment, where NS2 waits to interpret commands from the standard input (i.e., keyboard) line-by-line. If the first input argument <file> is given, NS2 will interpreted the input scripting <file> (i.e., a so-called Tcl simulation script) according to the Tcl syntax. The detail for writing a Tcl scripting file is given in Appendix A.1. Finally, the input arguments <args>, each separated by a white space, are fed to the Tcl file <file>. From within the file <file>, the input argument is stored in the built-in variable argv (see Appendix A.1.1). Main NS2 Simulation Steps The followings show the three key step guideline in defining a simulation scenario in a NS2: Step 1: Simulation Design The first step in simulating a network is to design the simulation. In this step, the users should determine the simulation purposes, network configuration and assumptions, the performance measures, and the type of expected results. Step 2: Configuring and Running Simulation This step implements the design in the first step. It consists of two phases: • Network configuration phase: In this phase network components (e.g. node, TCP and UDP) are created and configured according to the simulation design. Also, the events such as data transfer are scheduled to start at a certain time. • Simulation Phase: This phase starts the simulation which was configured in the Network Configuration Phase. It maintains the simulation clock and executes events chronologically. This phase usually runs until the simulation clock reached a threshold value specified in the Network Configuration Phase. In most cases, it is convenient to define a simulation scenario in a Tcl scripting file (e.g., <file>) and feed the file as an input argument of an NS2 invocation (e.g., executing “ns <file>”). Step 3: Post Simulation Processing The main tasks in this steps include verifying the integrity of the program and evaluating the performance of the simulated network. While the first task is referred to as debugging, the second one is achieved by properly collecting and compiling simulation results.
- 9. Network Animation (NAM) Trace NAM trace is records simulation detail in a text file, and uses the text file the play back the simulation using animation. NAM trace is activated by the command “$ns namtrace-all $file”, where ns is the Simulator handle and file is a handle associated with the file (e.g., out.nam in the above example) which stores the NAM trace information. After obtaining a NAM trace file, the animation can be initiated directly at the command prompt through the following command: >>nam filename.nam Many visualization features are available in NAM. These features are for example animating colored packet flows, dragging and dropping nodes (positioning), labeling nodes at a specified instant, shaping the nodes, coloring a specific link, and monitoring a queue. Mobile Ad Hoc Networks (MANETs) MANETS provide more flexibility in the creation of a network in situations like where there is no possibility or less Possibility in setting up the predefined infrastructure. Unlike a node in an infrastructure based network, all the nodes in a MANET cooperate with each other to perform routing. Because the radio transmission range is very less, there is a lot of overhead involved with respect to routing, security in particular. This is because the nodes are more prone to failures and compromises in ad hoc networks because of their mobility. MANET is a wireless ad-hoc network which is also a self-configuring network of mobile routers (and associated hosts) that are connected by wireless links, and all these together form an arbitrary topology. The network’s topology changes very rapidly and unpredictably. This type of network can easily act as a standalone network as well as has the capability to connect to the internet. With this feature, MANET s can be widely used for commercial purposes very easily. MANET s are very self- organizing and adaptive. Networks are formed on the fly and devices can leave and join the network at any time. The communication between the devices in this wireless network which are in their radio range will be in a peer- peer fashion. Intermediate devices can be used if the devices wish to communicate with those that are out of the radio range. Every device acts as a host when providing any information or requesting from /to any other node in the network. These devices acts as routers while discovering and maintaining routes for other nodes in the network. Mobile ad hoc networks became a popular for research as laptops and 802.11/Wi-Fi wireless networking became widespread from 1990s. Many researchers are evaluating the protocols with different degrees of mobility within a bounded space, usually with all nodes within a few hops of each other, and usually with nodes sending data at a constant rate. The packet drop rate, the overhead introduced by the routing protocol, and other measures are also evaluated for different protocols. Characteristics of Mobile Ad Hoc Networks 1. MANETs doesn’t depend on any fixed infrastructure for the operation of mobile nodes. 2. Any node or device can freely join and leave the network at any time, which accounts 3. They can be easily attached to any internet or cellular networks as they need not operate in standalone mode Only. 4. It can be rapidly deployed with user intervention. 5. In MANET, each node act as both host and router. That is it is autonomous in behavior. 6. Multi-hop radio relaying- When a source node and destination node for a message is out of the radio range, the MANETs are capable of multi-hop routing. 7. Distributed nature of operation for security, routing and host configuration. A centralized firewall is absent here. 8. Mobile nodes are characterized with less memory, power and light weight features. 9. The reliability, efficiency, stability and capacity of wireless links are often inferior when compared with wired links. This shows the fluctuating link bandwidth of wireless links. 10. Mobile and spontaneous behavior which demands minimum human intervention to configure the network 11. All nodes have identical features with similar responsibilities and capabilities and hence it forms a completely symmetric environment. 12. High user density and large level of user mobility.
- 10. 13. Nodal connectivity is intermittent. MANET Challenges A MANET environment has to overcome certain issues of limitation and inefficiency. It includes: The wireless link characteristics are time-varying in nature: There are transmission impediments like fading, path loss, blockage and interference that adds to the susceptible behaviour of wireless channels. The reliability of wireless transmission is resisted by different factors. Limited range of wireless transmission – The limited radio band results in reduced data rates compared to the wireless networks. Hence optimal usage of bandwidth is necessary by keeping low overhead as possible. Packet losses due to errors in transmission – MANETs experience higher packet loss due to factors such as hidden terminals that results in collisions, wireless channel issues (high bit error rate (BER)), interference, and frequent breakage in paths caused by mobility of nodes, increased collisions due to the presence of hidden terminals and unidirectional links. Route changes due to mobility- The dynamic nature of network topology results in frequent path breaks. Frequent network partitions- The random movement of nodes often leads to partition of the network. This mostly affects the intermediate nodes. Types of Attack In MANET The application of this wireless network is limited due to the mobile and ad hoc nature. Similarly, the lack of a centralized operation prevents the use of firewall in MANETs. It also faces a multitude of security threats just like wired networks. It includes spoofing, passive eavesdropping, denial of service and many others. The attacks are usually classified on the basis of employed techniques and the consequences. Applications of MANET’s With the increase of portable devices as well as progress in wireless communication, ad-hoc networking is gaining importance with the increasing number of widespread applications. Ad-hoc networking can be applied anywhere where there is little or no communication infrastructure or the existing infrastructure is expensive or inconvenient to use. Ad hoc networking allows the devices to maintain connections to the network as well as easily adding and removing devices to and from the network. The set of applications for MANET is diverse, ranging from large-scale, mobile, highly dynamic networks, to small, static networks that are constrained by power sources. Besides the legacy applications that move from traditional infra structured environment into the ad hoc context, a great deal of new services can and will be generated for the new environment. Typical applications include: 1. Military Battlefield: Military equipment now routinely contains some sort of computer equipment. Ad- hoc networking would allow the military to take advantage of commonplace network technology to maintain an information network between the soldiers, vehicles, and military information headquarters. The basic techniques of ad hoc network came from this field.
- 11. 2. Commercial Sector: Ad hoc can be used in emergency/rescue operations for disaster relief efforts, e.g. in fire, flood, or earthquake. Emergency rescue operations must take place where non-existing or damaged communications infrastructure and rapid deployment of a communication network is needed. Information is relayed from one rescue team member to another over a small hand held. Other commercial scenarios include e.g. ship-to- ship ad hoc mobile communication, law enforcement, etc. 3. Local Level: Ad hoc networks can autonomously link an instant and temporary multimedia network using notebook computers or palmtop computers to spread and share information among participants at e.g. conference or classroom. Another appropriate local level application might be in home networks where devices can communicate directly to exchange information. Similarly in other civilian environments like taxicab, sports stadium, boat and small aircraft, mobile ad hoc communications will have many applications. 4. Personal Area Network (PAN): Short-range MANET can simplify the intercommunication between various mobile devices (such as a PDA, a laptop, and a cellular phone). Tedious wired cables are replaced with wireless connections. Such an ad hoc network can also extend the access to the Internet or other networks by mechanisms e.g. Wireless LAN (WLAN), GPRS, and UMTS. The PAN is potentially a promising application field of MANET in the future pervasive computing context.8.5 MANET-VoVoN: A MANET enabled version of JXTA peer-to-peer, modular, open platform is used to support user location and audio streaming over the JXTA virtual overlay network. Using MANET-JXTA, a client can search asynchronously for a user and a call setup until a path is available to reach the user. The application uses a private signalling protocol based on the exchange of XML messages over MANETJXTA communication channels. 5. Limitations of MANET’s 1. Most of the nodes constantly change their positions in the network which makes routing discovery very complex. 2. Out-of date routes are also generated in the network, which adds more overhead. 3. Most of the links are asymmetric in ad hoc networks. 4. As links come and go depending on their transmission characteristics, one transmission may interfere with other, which causes lot of interruptions in the entire network. 5. Because of the dynamic topology, the medium characteristics also change frequently, and more complex routing algorithms have to be employed. Routing protocols for MANET’s There are many ways of classifying the routing protocols but most of them rely on routing strategy and network structure. Mainly these are classified as Flat, hierarchical, and Geographic position based routing protocols. Another major classification is based on whether they are on-demand or table-driven. Flat routing protocols are further divided into several types based on whether the routing table is generated statically before itself or whether it is generated only ion demand as when the need comes so as to make a routing decision. Examples of table- driven protocols are a) Optimized Link state Routing (OLSR) b) Fish-eye state routing (FSR) c) Destination -Sequenced Distance Vector Routing (DSDV) d) Cluster-head Gateway Switch Routing Protocol (CGSR) Examples of on-demand routing protocols are: a)Ad-hoc on demand Distance Vector(AODV) b) Dynamic source Routing Protocol (DSR) c) Temporally ordered Routing Algorithm (TORA) d) Associativity based routing (ABR) e) Signal Stability based Associative Routing (SSAR) f) Location –Aided Routing Protocol (LAR) Several hybrid protocols are also used to find a balance between the above two types which take the domain information into account. Examples of hybrid routing protocols are Zone routing protocol and Wireless ad hoc routing protocol. As the size of the network increases, flat routing protocols does not perform well because of the lot of overhead incurred . In such cases hierarchal routing algorithms perform better. Examples of such algorithms are a) Hierarchical state routing b) Zone routing protocol c) Cluster head Gateway switch routing protocol d) Landmark ad hoc routing protocol Another class of routing protocols are based on te location information and takes the geographic co-ordinates into account and maintain reference points to compute the routes. Examples of such algorithms are Geocast
- 12. (geographic addressing and routing), DREAM (Distance Routing effect algorithm for mobility) and GPSR (Greedy perimeter stateless routing). AODV: Ad-hoc On Demand Distance Vector History: Ad hoc On-Demand Distance Vector (AODV) Routing is a routing protocol for mobile ad hoc networks (MANETs) and other wireless ad hoc networks. It is jointly developed in Nokia Research Center, University of California, Santa Barbara and University of Cincinnati by C. Perkins, E. Belding-Royer and S. Das. Characteristics and Features: AODV is a distance vector type routing. The basic feature of AODV is that the active nodes need not maintain the routes to destinations. AODV works well when the communication end points have correct routes to the router. Mechanism: With AODV algorithm multi hop, self-starting, dynamic routing can be enabled between the mobile nodes that wish to maintain and establish an ad hoc network. It permits and helps mobile nodes in acquiring routes rapidly for new destinations, and does not oblige devices to keep up routes to destinations that are not in dynamic communication. This protocol enables mobile devices to react to the changes in network topology and link breakages in a timely and efficient way. In case if a link breaks, AODV helps in notifying the set of nodes that are affected so that the routes using the lost link can be invalidated. UDP is used to receive messages and some sort of IP header processing is also applied. It makes use of a destination sequence number for each route entry. The destination sequence number is created by the destination for any information it sends to request nodes. These are used to know which new routes are found on the way, of the many routes available. A route with the highest sequence number is chosen from multiple routes available for the node. In AODV, four control messages are defined for maintaining routes to the destination. These control messages include RREQ (Route Request) message, Hello message, RERR (Route Error) message and RREP (Route Reply). Periodically a hello message is broadcasted by every node in the network to all its neighbors to tell that it is alive. Whenever a neighboring node receives a hello message, the neighbor node includes the data about the Node which sends a hello message into its routing table. If a node want to communicate with some other node, the source node will check destination node in its routing table. Route request (RREQ) packet is broadcasted by the source node to all its neighbors in case if the routing table does not contain destination node. Every neighboring node likewise rebroadcasts the gained route request (RREQ) messages to its neighbors. Through along these lines
- 13. over and over until the destination node is reached. If the neighbor node accepts the route reply packet (RREP), it likewise replies conversely the Route reply packet to the former neighbor node as per the data in its routing table. The transmission path can be created at the point when the route reply (RREP) message is sent again to the originating node. Throughout the information transmission, if in this transmission way a node is not able to communicate with the neighbor nodes, then a route error(RERR) message is sent by this node to the source node and the data that belongs to this transmission way is deleted from its routing table. The source node will retransmit RREQ packet for building a new transmission path when it receives a route error (RRER) message considering that the transmission path to the desired destination node has broken. The main drawback of this AODV is that there is no provision to handle unidirectional links. On-Demand Protocol Advantage & Disadvantage: The AODV (Ad-Hoc On-Demand Distance Vector) routing protocol is a reactive routing protocol that uses some characteristics of proactive routing protocols. Routes are established on-demand, as they are needed. However, once established a route is maintained as long as it is needed. Reactive (or on-demand) routing protocols find a path between the source and the destination only when the path is needed (i.e., if there are data to be exchanged between the source and the destination). An advantage of this approach is that the routing overhead is greatly reduced. A disadvantage is a possible large delay from the moment the route is needed (a packet is ready to be sent) until the time the route is actually acquired. In AODV, the network is silent until a connection is needed. At that point the network node that needs a connection broadcasts a request for connection. Other AODV nodes forward this message, and record the node that they heard it from, creating an explosion of temporary routes back to the needy node. When a node receives such a message and already has a route to the desired node, it sends a message backwards through a temporary route to the requesting node. The needy node then begins using the route that has the least number of hops through other nodes. Unused entries in the routing tables are recycled after a time. Uses The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers Quick adaptation to dynamic link conditions, low processing and Memory overhead, low network utilization, and determines unicast Routes to destinations within the ad hoc network. It uses Destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), Avoiding problems (such as "counting to infinity") associated with Classical distance vector protocols. MISBEHAVING NODES MODEL Routing protocols provide two main functions: Routing function and data forwarding function. The former is concerned with routes discovery and routes maintenance. The latter is concerned with data packets relaying toward the destination through the established route. Both routing and data forwarding can be affected by misbehaving nodes presence; misbehaving nodes can lead the network into malfunction by not following routing and packets forwarding functions. We consider two kinds of misbehaving nodes: selfish nodes and malicious nodes. We consider the following parameters that may govern the severity of an attack: • Time: start and stop time, • Degree: the probability (P) of misbehavior, • Target: victims’ nodes (all nodes, a subset of nodes). A. Selfish nodes Selfish nodes try to save their own resources since resources are very constrained in wireless devices. So selfish nodes may decide to not consume their resource in forwarding data packets for other nodes: this can be achieved in two ways: 1) Selfish node type 1 Theses nodes participate correctly in routing function but not forward data packets it receive for other node; so data packets may be dropped instead of being forwarded to their destination. 2) Selfish node type 2: Theses nodes do not participate correctly in routing function by not advertising available routes, for example: in DSR selfish node may drop all RREQ they received or not forward a RREP to some destination. Consequently, this selfish node will not participate in the requested routes. B. Malicious nodes
- 14. Unlike, selfish nodes, malicious nodes don’t preserve their resource and try to sabotage other nodes by trying to participate in all established routes. Consequently, the malicious nodes can force other nodes to use a “dangerous” route which is under their control. The man oeuvre that the malicious nodes may take is protocol-dependent. In the context of DSR routing protocol, a malicious node can claim to have a route to some destination and reply with false information to the received Watchdog: The watchdog method is a strategy proposed before in other studies that detects misbehaving nodes acting alone by maintaining a buffer that contains recently sent packets. When a node forwards a packet, the node’s watchdog ensures that the next node in the path also forwards the packet. The watchdog does this by listening all nodes promiscuously. If the next node does not forward the packet then it is termed as misbehaving. In other words, in this scheme, every packet that is overheard by the watchdog is compared with the packet in the buffer to see if there is a match. A match confirms that the packet has been successfully delivered and it is removed from the buffer. If a packet has remained in the buffer beyond the timeout period, then a failure counter for the node responsible for forwarding the packet is incremented. If this counter exceeds a predetermined threshold then the node is termed as malicious and the network is informed accordingly by a message sent by the node that detects the problem. The Bayesian Watchdog has also been developed, a tool that merge the watchdog with Bayesian filters. It is more robust against environmental noise but consume more CPU resources. The benefit of the Watchdog protocol is that, they make use of only local information and are proficient to spot the malicious node. They can resolve the predicament of black hole attack which demonstrate the way to denial of service attack (DOS) in MANET network. Watchdog protocol act as a very good intrusion detection system mechanism in the network. However, there are certain disadvantages regarding to this protocol such that it decreases the network performance in terms of throughput, it does not support mobility with high number of nodes, and it doesn’t detect the actual reason of the packet loss. To overcome these disadvantages of this Watchdog protocol, the improved Watchdog mechanism is proposed which perfectly distinguishes the packet loss due to congestion or due to the presence of a malicious node in the network. The improved Watchdog protocol also supports a high degree of the mobility and enhances the performance. Watchdog Monitoring System Normal Watchdog is a kind of behavior monitoring mechanism which is the base of many trust systems in ad hoc and wireless sensor networks. In general, trust mechanism works in the following three stages 1) node behavior monitoring, 2) trust measurement, and 3) insider attack detection. Watchdog is a popular monitoring mechanism for node behavior monitoring. The basic idea of Watchdog is a node monitors whether its next-hop neighbor forwards
- 15. the packets it just sent by overhearing. If the packet is not forwarded within a certain period, the neighbor is regarded as misbehaving in this transaction. The overhearing ability is shown below: Steps For Adding Malicious Node In AODV Protocol Of MANETS Adding a malicious node is ns2 using aodv protocol. The node which is declared as malicious will simply drop the router packet (DROP_RTR_ROUTE_LOOP). Two files have to be modified. 1. aodv.h 2. aodv.cc aodv.h file changes Declare a boolean variable malicious as shown below in the protected scope in the class AODV bool malicious; aodv.cc file changes 1. Initialize the malicious varible with a value "false". Declare it inside the constructor as shown below AODV::AODV(nsaddr_t id):Agent(PT_AODV)... { ....... malicious = false; } 2. Add the following statement to the aodv.cc file in the "if(argc==2)" statment. if(strcmp(argv[1], "malicious") == 0) { malicious = true; return TCL_OK; } 3. Implement the behavior of the malicious node by setting the following code in the rt_resolve(Packet *p) function. The malicious node will simply drop the packet as indicated below. if(malicious==true) { drop(p,DROP_RTR_ROUTE_LOOP); } Recompiled the Ns2 given below:
- 16. Open Terminal -> Go to ~ns-2.35/ directory and type the command make to compile $ cd /home/ambii/Downloads/ns-allinone-2.35/ns-2.35/ $ make clean $ make $ sudo make install Once the compilation is done, set any one node as malicious node. The command to set the malicious node is $ns at 0.0 "[$n(1) set ragent_] malicious" The variable referred for node2 is n1 (set n(1) [$ns node]). For Tcl Script I used the following code for setting nodes and showing output in MANETS: #====================================================================== # Define options #====================================================================== set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/TwoRayGround ;# radio-propagation model set val(ant) Antenna/OmniAntenna ;# Antenna type set val(ll) LL ;# Link layer type set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type set val(ifqlen) 50 ;# max packet in ifq set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(nn) 6 ;# number of mobilenodes set val(rp) AODV ;# routing protocol set val(x) 800 set val(y) 800 set ns [new Simulator] #ns-random 0 set f [open out.tr w] $ns trace-all $f set namtrace [open out.nam w] $ns namtrace-all-wireless $namtrace $val(x) $val(y) set topo [new Topography] $topo load_flatgrid 800 800 create-god $val(nn) set chan_1 [new $val(chan)] set chan_2 [new $val(chan)] set chan_3 [new $val(chan)] set chan_4 [new $val(chan)] set chan_5 [new $val(chan)] set chan_6 [new $val(chan)]
- 17. # CONFIGURE AND CREATE NODES $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) #-channelType $val(chan) -topoInstance $topo -agentTrace ON -routerTrace ON -macTrace ON -movementTrace OFF -channel $chan_1 proc finish {} { global ns namtrace $ns flush-trace close $namtrace exec nam -r 5m out.nam & exit 0 } # define color index $ns color 0 blue $ns color 1 red $ns color 2 chocolate $ns color 3 red $ns color 4 brown $ns color 5 tan $ns color 6 gold $ns color 7 black set n(0) [$ns node] $ns at 0.0 "$n(0) color blue" $n(0) color "0" $n(0) shape "circle" set n(1) [$ns node] $ns at 0.0 "$n(1) color red" $n(1) color "blue" $n(1) shape "circle" set n(2) [$ns node] $n(2) color "tan" $n(2) shape "circle" set n(3) [$ns node] $n(3) color "red" $n(3) shape "circle" set n(4) [$ns node] $n(4) color "tan" $n(4) shape "circle" set n(5) [$ns node] $ns at 0.0 "$n(5) color blue" $n(5) color "red" $n(5) shape "circle"
- 18. for {set i 0} {$i < $val(nn)} {incr i} { $ns initial_node_pos $n($i) 30+i*100 } #$ns at 0.0 "[$n(1) set ragent_] malicious" $ns at 0.0 "$n(0) setdest 100.0 100.0 3000.0" $ns at 0.0 "$n(1) setdest 200.0 200.0 3000.0" $ns at 0.0 "$n(2) setdest 300.0 200.0 3000.0" $ns at 0.0 "$n(3) setdest 400.0 300.0 3000.0" $ns at 0.0 "$n(4) setdest 500.0 300.0 3000.0" $ns at 0.0 "$n(5) setdest 600.0 400.0 3000.0" # CONFIGURE AND SET UP A FLOW set sink0 [new Agent/LossMonitor] set sink1 [new Agent/LossMonitor] set sink2 [new Agent/LossMonitor] set sink3 [new Agent/LossMonitor] set sink4 [new Agent/LossMonitor] set sink5 [new Agent/LossMonitor] $ns attach-agent $n(0) $sink0 $ns attach-agent $n(1) $sink1 $ns attach-agent $n(2) $sink2 $ns attach-agent $n(3) $sink3 $ns attach-agent $n(4) $sink4 $ns attach-agent $n(5) $sink5 #$ns attach-agent $sink2 $sink3 set tcp0 [new Agent/TCP] $ns attach-agent $n(0) $tcp0 set tcp1 [new Agent/TCP] $ns attach-agent $n(1) $tcp1 set tcp2 [new Agent/TCP] $ns attach-agent $n(2) $tcp2 set tcp3 [new Agent/TCP] $ns attach-agent $n(3) $tcp3 set tcp4 [new Agent/TCP] $ns attach-agent $n(4) $tcp4 set tcp5 [new Agent/TCP] $ns attach-agent $n(5) $tcp5 proc attach-CBR-traffic { node sink size interval } { #Get an instance of the simulator set ns [Simulator instance] #Create a CBR agent and attach it to the node set cbr [new Agent/CBR] $ns attach-agent $node $cbr $cbr set packetSize_ $size $cbr set interval_ $interval #Attach CBR source to sink; $ns connect $cbr $sink return $cbr } set cbr0 [attach-CBR-traffic $n(0) $sink5 1000 .030] $ns at 0.5 "$cbr0 start" $ns at 5.5 "finish"
- 19. puts "Start of simulation.." $ns run For implementing Watchdog mechanism, promiscuous mode should be enabled so that nodes in MANETS could overhear their nest hop neighborhood nodes for monitoring the packet transmission so I used the following code enabling promiscuous mode in MANETS: 1)In ns-allinone-2.34/ns-2.34/aodv/aodv.h, I made changes shown in blue: #include <mac.h> class AODV: public Tap, public Agent { public: void tap(const Packet *p); ...... protected: Mac *mac_; ...... } 2 ns-allinone-2.34/ns-2.34/aodv/aodv.cc int AODV::command(int argc, const char* const * argv) { ...... else if(argc == 3) { ...... else if (strcmp(argv[1], "install-tap") == 0) { mac_ = (Mac*)TclObject::lookup(argv[2]); if (mac_ == 0) return TCL_ERROR; mac_->installTap(this); return TCL_OK; } } return Agent::command(argc, argv); } void AODV::tap(const Packet *p) { } 3) ns-allinone-2.34/ns-2.34/tcl/lib/ns-mobilenode.tcl Node/MobileNode instproc add-target { agent port } { $self instvar dmux_ imep_ toraDebug_ mac_ ...... # Special processing for AODV set aodvonly [string first "AODV" [$agent info class]] if {$aodvonly != -1 } { $agent if-queue [$self set ifq_(0)] ; # ifq between LL and MAC $agent install-tap $mac_(0) }
- 20. For Watchdog: $ cd ns-allinone-2.35/ $ patch -p0 < watchdog-bayesian2.0_ns235.patch $ export CC=gcc-4.4 CXX=g++-4.4 && ./install d) $ cd ns-2.34/ e) $ cp ns ns-watchdog-bayesian f) # cp ns-watchdog-bayesian /usr/local/bin/ ..... Run simulations with : $ ns-watchdog-bayesian <file>.tcl Network Throughput: The below figure shows the total network throughput, calculated as the fraction of data packets generated that are received, versus the fraction of misbehaving nodes in the network for the combinations of extensions. In the case where the network contains no misbehaving nodes, all four curves achieve around 95% throughput. After the 0% misbehaving node case, the graphs diverge.
- 21. Ad hoc networks are an increasingly promising area of research Conclusion Adhoc networks are an increasingly promising area of research with practical applications, but they are vulnerable in many settings to nodes that misbehave when routing packets. For robust performance in an untrusted environment, it is necessary to resist such routing misbehavior. In this paper we analyze extension to AODV to mitigate the effects of routing misbehavior in ad hoc networks, the watchdog. We show that the two techniques increase throughput by 17% in a network with moderate mobility, while increasing the ratio of overhead transmissions to data transmissions from the standard routing protocol's 9% to 17%. During extreme mobility, watchdog can increase network throughput by 27%, while increasing the percentage of overhead transmissions from 12% to 24%. These results show that we can gain the benefits of an increased number of routing nodes while minimizing the effects of misbehaving nodes. In addition we show that this can be done without a priori or trust or excessive overhead..