AD HOC NETWORKS

Computer Science and Engineering

Project Guide:
Mr. Hari Mohan Pandey
(Asst. Prof.CSE DEPT)

By

Aditya Kathpalia
College roll no. - A2345916002

Amity school of Engineering and Technology

Amity University, Noida
Sector - 125
 DECLARATION

This is to certify that the project entitled ―AD HOC NETWORK

which is submitted by Aditya Kathpalia from
AMITY SCHOOL OF ENGINEERING AND TECHNOLOGY, AMITY UNIVERSITY
NOIDA CAMPUS SECTOR – 125
Comprises only my original work and due acknowledgement has been made in the text to all
other material used.

Date:
 CERTIFICATE

This is to certify that the project entitled ― AD HOC NETWORKS which is submitted by
Aditya Kathpalia is a record of the candidate work carried out by him under Mr. Hari Mohan
Pandey. The matter embodied in this is original and had successfully done.

Date:
 ACKNOWLEDGMENT

I express my sincere thanks and deep sense of gratitude to Mr. Hari Mohan Pandey, AMITY
UNIVERSITY, NOIDA SECTOR – 125 for his valuable motivation and guidance, without
him this project report would not have been possible. I consider myself fortunate for having
the opportunity to learn and work under his able supervision and guidance during the report.
He left no stone unturned during the completion of this project.

Date:
 TABLE OF CONTENTS

1. Chapter 1: Introduction ………………………

1.1 Mobile Ad hoc Networks……

1.2 Proactive Protocols….

1.3 Reactive Protocol…

1.4 DSR Protocol…

1.4.1 Route discovery…

1.4.2 Route maintenance…

2. Chapter 2. Design…
2.1 DSR route discovery…

2.2 DSR route maintenance…

2.3 Flowchart for leader node selection …

2.3.1 Explanation…

2.4 Flowchart for malicious node detection….

2.4.1 Explanation…

3. Chapter 3. Implementation……
3.1 Network Simulator 2……
3.1.1 NS2 Installation….
3.1.2 The OTCL Linkage…
3.1.3 Event Schedulers…
3.1.4 Steps to set up the simulation for wireless script
3.1.5 Produce some node movements
3.1.6 Set Stop Time and Start Simulation
4. Testing and Evaluation …
4.1 Debugging by Backtracking….

4.2 Debugging by Induction…

5. Chapter 7 Conclusions……

6. References……
 CHAPTER 1: INTRODUCTION

1.1 MOBILE AD HOC NETWORKS

 A Mobile Ad-hoc network is a wireless ad-hoc network which is used to exchange information.
 Each node is willing to forward data to other nodes.
 Does not rely on fixed infrastructure

PROBLEMS IN MANET
 Routing
 Security and Reliability
 Quality of Service
 Internetworking
 Power Consumption
SECURITY
 A major issue in Mobile ad-hoc network is “SECURITY”.
 Routing protocols in ad hoc networks are broadly divided into two categories:
Reactive approach and Proactive approach

1.2PROACTIVE (TABLE-DRIVEN)

. Attempts to prevent an attacker from launching attacks through various cryptographic techniques.The
main disadvantages of such algorithms are:

1. Respective amount of data for maintenance.

2. Slow reaction on the restructuring and
failures. Examples:

DSDV, OLSR, FSR, FSLS

1.3 REACTIVE (ON-DEMAND)

Seeks to detect security threats and react accordingly.One option is to uncast consecutively when forwarding
data while promoting a new link. The main disadvantages of such algorithms are:

1. It takes long time when exploring new routes without a prior knowledge.
May refer to existing traffic to compensate for missing knowledge on routes. Examples: DSR, AODV
1.4 DSR PROTOCOL
 Self Organizing
 It determines how best to move packets around
 Self Configuring
 It determines the routes available
 w/o existing network structure
 w/o administration

Advantages of DSR

 Caching routing information from packets forwarded (ease dropping)

 Routes established on demand lend to scalability

Assumptions & Disadvantages

 Nodes participate fully
 Diameter or number of hops is small (5 – 10)
 Node velocity is small relative to transmission latency
 Errors are detectable and discarded
 Nodes may enable promiscuous receive mode (hardware layer passes packets & power consumption
may be increased)
 Can operate without promiscuous mode on or in networks where it is unavailable.

1.4.1 ROUTE DISCOVERY.

Occurs when a node needs to send a message to another node and the path is not already known.
 Multiple replies are cached for future use
 Caching reduces work on new route requests
 Source and destination in RREQ header
 Route record is initialized as empty list
 Unique route request ID, Hop Count

1.4.2 ROUTE MAINTENANCE

 Somewhat alluded to above: Packet retries, route error RERR responses
 Send buffer is full causes use of other cached routes, if routes don’t work they are pruned
 If no cached routes found Route Discovery performed
Error recovery
 RERR messages are used to update cache where link errors have occurred
 Each node may request a ACK to each message or passive acknowledgement by listening for re-
transmission or knowledge of underling link protocol - allowing the RERR to be generated

This project focuses on detection of two types of malicious behaviour exhibited by the nodes, the first one is
the malicious topology change behaviour and the other one is the malicious packet drop behaviour in DSR
protocol. These attacks (or malicious behaviour) hinder the communication between nodes and makes the
routing process difficult. Hence, these need to be corrected as they are not handled by the standard Dynamic
Source Routing protocol (DSR).
 CHAPTER 2: DESIGN

2.1 BASIC DSR ROUTE DISCOVERY

To initiate the Route Discovery

 First the initiator transmits a “Route Request” as a single local broadcast packet
 Each Route Request identifies the initiator and target of the Route Discovery, and also contains a
unique request identification

 Contains all records of each listing in which the address of each intermediate node is stored and
through which this particular copy of the Route Request has been forwarded.

Neighbor node receiving the Route Request

 Discard the packet if

1. It has recently seen another Route Request message from this initiator bearing this same
request ID and target address, or

2. This node’s own address is already listed in the route record in the Route Request
Otherwise, this node appends its own address to the route record and propagates it by
transmitting it as a local broadcast packet

Target of Route Request

 Route Request returns a “Route Reply” (unicast) to the initiator of the Route Discovery
 When the initiator receives this Route Reply, it caches this route in its Route Cache for using in
sending subsequent packets
2.2 BASIC DSR ROUTE MAINTENANCE:

 E.g. if a node “C” is unable to deliver the packet to the next node “D”, then “C” returns a “Route
Error” to the original sender of the packet (node A)

A B C D E

Route error message: C-D

is broken

Then node “A” tries to remove this broken link from its cache; i.e.; any retransmission of the original
packet can be performed by upper layer protocols

 For sending such a retransmission or other packets to this same destination E:

1. “A” should have in its Route Cache another route to” E”, then only it can send the packet
using the new route immediately

2. Otherwise, node A should perform a new Route Discovery for this target
2.3 FLOWCHART FOR LEADER NODE SELECTION

START

COMPUTE NODE DEGREE

CHECK ALL CIRCULAR LINKS

NO
EXISTS? LEADER NODE

YES

CHECK ALL LOG LINKS

YES

NON LEADER NODE

2.3.1 EXPLANATION OF FLOWCHART FOR THE LEADER NODE
SELECTION

The algorithm first compute the node degree of all the wireless nodes then, it takes a particular node and
checks the circular links for that node, by the checking of circular links we mean that the node arranges its
neighbours in increasing order of their node ID‘s and checks if that particular set of nodes forms circular
links or not (either connected by 1 hop or 2 hops), if all the circular links are not present then the node is
straight away marked as the leader node, otherwise it then checks for the log links , and for that we take the
floor values of the node degree for that node, supposedly it comes ―n‖ then from we check the connectivity
of nodes (either connected by 1 hop or 2 hops) at a distance of n hops away from that node in the circular
fashion that was previously taken.

If all the log links are present then the node is marked as the non-leader node and if even one link is missing
then it is marked as the leader node.
2.4 FLOWCHART FOR MALICIOUS NODE DETECTION

START

CALCULATE MEAN
TIME DIFFERENCE OF
NODES LEAVING THE
NETWORK
NO

BELOW
THRESHOLD?

YES

MALICIOUS NODE
2.4.1 EXPLANATION OF FLOWCHART FOR THE MALICIOUS NODE
DETECTION

The task of malicious node detection is accomplished by running two algorithms in parallel. It calculates the
mean on the time difference of the nodes leaving the network, and this is achieved by storing the timestamp
values whenever the node goes out of the field of the leader node.
 CHAPTER 3: IMPLEMENTATION

3.1 NETWORK SIMULATOR 2

Network simulator is a discrete event simulator targeted at networking research. Ns provides substantial
support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite)
networks.

Background on the ns Simulator

o Based on two languages (an object-oriented simulator (C++), and OTcl (object-oriented
TCU) interpreter.
o Has rich library of network and protocol object
o Compiled C++ hierarchy gives efficiency in simulation and faster execution times.
o With OTcl script provided by user, a network topology is simulated.
o Ns2 is event simulator where the advance of time depends on the timing of events which are
maintained by a scheduler.
o Event – an object in C++ hierarchy.
 unique ID, Scheduled time,
 pointer to an object

o Scheduler – maintains ordered data structure with the events to be executed and fires them
one by one, invoking the handler of the event.
3.1.1 NS2 INSTALLATION

NS2 can be installed on windows, Linux platform and MAC OS. For details refer the link
mentioned in [13]:

OTcl – The User Language (Object Oriented Tool Command Language)

• NS2 is basically an OTcl interpreter with network simulation object libraries

• Very simple syntax and easy integration with other languages.
• Characteristics:
o fast development
o provide graphic interface
o compatible with many platforms o flexible for
integration
o easy to use o free
Example of an OTCL procedure.

• Proc: define a procedure, followed by an procedure name and arguments

• Set: assign a value to a variable
• [expr …]: to make the interpreter calculate the value of expression within the bracket
• To assign to variable x the value that variable a has, then write ―set x $a‖.
• Put: prints out

OUTPUT:
3.1.2 THE OTCL LINKAGE

NS uses two languages because simulator has two different kinds of task which it needs to do. On one hand,
a detailed simulation of protocols requires a systems programming language which can efficiently
manipulate bytes, packet headers, and implement algorithms that run over large data sets. For these tasks
run-time speed is important and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is
less important.

On the other hand, a large part of network research involves slightly varying parameters or configurations,
or quickly exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is
more important. Since configuration runs once (at the beginning of the simulation), run-time of this part of
the task is less important. Ns meets these needs with two languages, C++ and OTcl. C++ runs fast but can be
change slowly, making it suitable for detailed protocol implementation. OTcl runs much slower but can be
changed very quickly (and interactively), making it ideal for simulation configuration.
3.1.3 EVENT SCHEDULERS

Main users of an event scheduler are network components that simulate packet-handling delay or that need
time.
(Fig.5)

Two different types of event schedulers

• Real time: for emulation which allow the simulator to interact with a real network
• Non-real time: three implementations are available (Heap, List, Calendar). The default is set as
Calendar
3.1.4 Steps to set up the simulation for wireless script
 Mobile node at core of mobility model
 Mobile nodes can move in a given topology, receive/transmit signals
from/to wireless signals.
•  Scenario : Simple 2 Nodes Simulation
• Simulate a very simple 2-node wireless scenario
• The topology consists of two mobile nodes
• The mobile nodes move about within 500mX500m area
• A TCP connection is setup between the two
• Mobile nodes.
• Packets are exchanged between the nodes as they come within hearing
range of one another.

Setting Up Variables

 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(rp) DSDV ; # ad-hoc routing protocol
 set val(nn) 2 ; # number of mobilenodes
 set val(x) 500 ; # X dimension of topography
 set val(y) 500 ; # Y dimension of topography

Setting Up Variables

 . Define NS simulator
• set ns_ [new Simulator]
 Define trace file
• set tracefd [open simple.tr w]
• $ns_ trace-all $tracefd
 Create topology object
• set topo [new Topography]
 Topography object with (x=500, y=500)
• $topo load_flatgrid 500 500
God (General Operations Director) Object

 Create God object:

• create-god $val(nn)

God object stores:

 Number of mobile nodes

 Table of shortest number of hops required to reach from one node to another
 Stores smallest number of hops from one node to another
 optimal case to compare routing protocol performance

Simple Configuration For Wireless 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) \
-topoInstance $topo \
-channelType $val(chan) \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace OFF

Configuring Movement
 Create two nodes
for {set i 0} {$i < $val(nn) } {incr i}
{ set node_($i) [$ns_ node ]
$node_($i) random-motion 0 ;# disable random motion }

 Provide initial (X,Y, for now Z=0) co-ordinates

$node_(0) set X_ 5.0
$node_(0) set Y_ 2.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 390.0
$node_(1) set Y_ 385.0
$node_(1) set Z_ 0.0
3.1.5 Produce some node movements

#Node_(1) starts to move towards node_(0)

$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0"
$ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0”

#Node_(1) then starts to move away from node_(0)

$ns_ at 100.0 "$node_(1) setdest 490.0 480.0 15.0“

 Explanation:
$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0" means at time
50.0s, node1 starts to move towards the destination (x=25,y=20) at
a speed of 15m/s

3.1.6 Set Stop Time and Start Simulation

 Tell nodes when the simulation ends

for {set i 0} {$i < $val(nn) } {incr i}
{ $ns_ at 150.0 "$node_($i) reset"; }
$ns_ at 150.0001 "stop"
$ns_ at 150.0002 "puts \"NS EXITING...\“ ; $ns_ halt"
proc stop {}
{ global ns_ tracefd
close $tracefd }

 Finally, Start The Simulation

puts "Starting Simulation..."
$ns_ run
 CHAPTER 4: TESTING AND EVALUATION

4.1 DEBUGGING

Debugging is a two-step process that begins when we find an error as a result of a successful test case.

Step 1 is the determination of the exact nature and location of the suspected error within the program.

Step 2 consists of fixing the error.

4.2 DEBUGGING BY BACKTRACKING

This approach has been used extensively in the making of the project and is defined as an effective method
for locating errors in programs is to backtrack the incorrect results through the logic of the program until you
find the point where the logic went astray. In other words, start at the point where the program gives the
incorrect result—such as where incorrect data were printed. At this point we deduce from the observed
output what the values of the program's variables must have been. By performing a mental reverse execution
of the program from this point and repeatedly using the process of "if this was the state of the program at
this point, then this must have been the state of the program up here," we can quickly pinpoint the error.
With this process we are looking for the location in the program between the point where the state of the
program was what was expected and the first point where the state of the program was what was not
expected.

4.3DEBUGGING BY INDUCTION

This is the second approach which has been used while making of the project. It should be obvious that
careful thought will find most errors without the debugger even going near the computer. One particular
thought process is induction, where we move from the particulars of a situation to the whole. That is, start
with the clues (the symptoms of the error, possibly the results of one or more test cases) and look for
relationships among the clues.
(Debugging by Induction)
 CHAPTER 5: CONCLUSION

In this project work I have proposed a novel method for the detection of malicious nodes in DSR protocol
this method is named as MD-DSR (Malicious Detection In Dynamic Source Routing) which detects
malicious nodes. The detection of malicious nodes is done by leader nodes these leader nodes monitor all the
nodes in its neighbourhood.

Through simulations done in NS2 the results show that the proposed method MD-DSR is better than the
standard DSR in terms of packet delivery ratio, throughput, etc. The modified version of it detects malicious
nodes which was previously not there, moreover it detects the malicious nodes based on the two different
and exclusive criteria first is the mobility factor and the other one is the forward packet ratio.