Secure Routing Algorithm For Ad-Hoc Sens PDF

ARAB ACADEMY FOR SCIENCE, TECHNOLOGY AND MARITIME TRANSPORT
College of Engineering and Technology
SECURE ROUTING ALGORITHM

FOR AD-HOC SENSOR MOBILE NETWORKS
by
Mehemed Bashir Aliwa
A Thesis
Submitted in Partial Fulfillment to the Requirements
for the Master's Degree in
Computer Engineering
Supervisor
Prof. Dr. Mohamed Hashem Abd El-Aziz Dr. Mohamed T.EL-Sonni

Head of Information System Dep.-Faculty Arab Academy for Science and
of Computers & Information Sciences- Technology & Maritime
Ain Shams University Transport
MARCH 2008
‫اﻷﻛﺎدﳝﻴﺔ اﻟﻌﺮﺑﻴﺔ ﻟﻠﻌﻠﻮم واﻟﺘﻜﻨﻮﻟﻮﺟﻴﺎ واﻟﻨﻘﻞ اﻟﺒﺤﺮى‬
‫ﻛﻠﻴ ـﺔ اﳍﻨﺪﺳ ـﺔ واﻟﺘﻜﻨﻮﻟﻮﺟﻴ ـﺎ‬
‫ﻗﺴﻢ ﻫﻨﺪﺳﺔ اﳊﺎﺳﺒﺎت‬
‫ﺧﻮارزﻣﯿﺔ اﻟﺘﻮﺟﯿﮫ اﻵﻣﻦ ﻟﺸﺒﻜﺎت ذاﺗﯿﺔ اﻟﺘﻨﻈﯿﻢ )‪(Ad-Hoc‬‬

‫ﻟﻠﻤﺤﺴﺴﺎت اﻟﻤﺘﻨﻘﻠﺔ‬
‫رﺳﺎﻟﺔ ﻣﻘﺪﻣﺔ ﻹﲤﺎم ﻣﺘﻄﻠﺒﺎت اﳊﺼﻮل ﻋﻠﻰ درﺟﺔ اﳌﺎﺟﺴﺘﲑ‬

‫ﰲ‬
‫ﻫﻨﺪﺳــﺔ اﳊﺎﺳﺒﺎت‬
‫ﻣﻘدم ﻣن ‪:‬‬
‫أﳏﻤﺪ ﺑﺸﲑ أﺑﺮاﻫﻴﻢ ﻋﻠﻴﻮة‬
‫إﺷراف‬
‫د‪ .‬ﳏﻤـﺪ اﻟﻄﺎﻫـﺮ اﻟﺴـﲏ‬ ‫أ‪.‬د‪ .‬ﳏﻤﺪ ﻫﺎﺷﻢ ﻋﺒﺪ اﻟﻌﺰﻳﺰ أﲪـﺪ‬
‫اﻷﻛﺎدﳝﻴﺔ اﻟﻌﺮﺑﻴﺔ ﻟﻠﻌﻠﻮم واﻟﺘﻜﻨﻮﻟﻮﺟﻴﺎ واﻟﻨﻘﻞ‬ ‫أﺳﺘﺎذ ورﺋﻴﺲ ﻗﺴﻢ ﻧﻈﻢ اﳌﻌﻠﻮﻣﺎت ﻛﻠﻴﺔ اﳊﺎﺳﺒﺎت‬
‫اﻟﺒﺤﺮى ﻛﻠﻴﺔ اﳍﻨﺪﺳﺔ واﻟﺘﻜﻨﻮﻟﻮﺟﻴﺎ‬ ‫واﳌﻌﻠﻮﻣﺎت ﺟﺎﻣﻌﻪ ﻋﲔ ﴰﺲ‬
‫ﻣﺎرس ‪2008‬‬
Secure Routing Algorithm for Ad Hoc Sensor Mobile Networks
Abstract
Ad-hoc networking is a concept in computer communications, which means that
users wanting to communicate with each other form a temporary network, without
any form of centralized administration and without any physical connections. In these
networks there is no fixed topology due to the mobility of nodes. Each node
participating in the network acts both as host and a router and must therefore be
willing to forward packets for other nodes. Hence a dynamic routing protocol is
needed for these networks to function properly. Many Routing protocols have been
developed by researchers for accomplishing this task. Consequently, there is a need
for evaluation.
The wide array of uses for ad-hoc networks creates many different levels of
security requirements. So secure routing is an important area of research in
developing secured routing protocols. Although researchers have proposed several
secure routing protocols, their resistance towards various types of security attacks and
efficiency is a primary point of concern in implementing these protocols.
The purpose of this master thesis is to use a simulator to support the mobility wireless
sensor network simulation to implemented secure routing algorithm protocol in
simulator Ns-2, evaluation, comparison and performance analysis the secure routing
algorithm protocol compared with traditional routing algorithm protocols as:
First: survey of ad-hoc sensory network and study simulator network (Ns-2) which
supports wireless sensor network and has been designed as analyzer module used to
analyze the simulation output results with 6 performance metrics an a two new
performance metrics (drop packets at routing overhead and drop packets at end of
simulation time(trace files format).
Second: simulator Ns-2 is used for evaluation, comparison, performance analysis
between three routing algorithm for sensor mobile ad-hoc networks protocol
(Classification of flat routing protocols), Destination-Sequenced Distance Vector
(DSDV), Ad-Hoc On-Demand Distance Vector (AODV) and Dynamic Source
Routing (DSR) which are currently implemented in Ns-2 simulator. The first one is a
proactive protocol depending on routing tables which are maintained at each node.
The second and third are reactive protocol, which find a route to a destination on
demand, when every communication is needed.
Third: secure routing algorithm is implemented for sensor mobile ad-hoc networks
protocol (SEAD: secure efficient distance vector routing for mobile sensor ad-hoc
networks) in simulator network Ns-2, simulation with environment of attackers,
performance analysis and compared secure routing algorithm protocol with traditional
DSDV routing algorithm for sensor mobile ad-hoc network protocol.
‫اﻟﻣﻠﺧـــــص‬
‫ﯾﺗﻧﺎول اﻟﻣﺷروع‬
‫اﻟﮭدف ﻣن ھذا اﻟﻣﺷروع ‪ ,‬أوﻻ ً ‪ :‬ﺑﺣث ﺷﺎﻣل ﻋن ﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪(Ad-Hoc‬‬
‫ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ‪ ,‬وأﺳﺗﺧدام اﻟﻣﺣﺎﻛﻲ )‪ (Ns-2‬ودراﺳﺔ ﻛﯾﻔﯾﺔ أﺳﺗﺧﻼص اﻟﻧﺗﺎﺋﺞ ﻣﻧﮫ‬
‫وذﻟك ﺑﺄﻋداد ﺑرﻧﺎﻣﺞ ﻟﺗﺣﻠﯾل اﻟﻧﺗﺎﺋﺞ ﻣﻧﮫ‪.‬‬
‫ﺛﺎﻧﯾﺎ‪ :‬ﻣﻘﺎرﻧﮫ وﺗﺣﻠﯾل اﻟﻧﺗﺎﺋﺞ ﺑﯾن ﺛﻼﺛﺔ ﺧوارزﻣﯾﺎت ﻟﻠﺗوﺟﯾﺔ )‪(DSDV, DSR, ADOV‬‬
‫ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ ﺑﺄﺳﺗﺧدم اﻟﻣﺣﺎﻛﻲ )‪(Ns-2‬‬
‫واﻟﺑرﻧﺎﻣﺞ اﻟذي ﺗم أﻋــداده ﻟﺗﺣﻠﯾل اﻟﻧﺗﺎﺋﺞ‪.‬‬
‫ﺛﺎﻟﺛﺎ‪ :‬ﺑرﻣﺟﺔ ﺧوارزﻣﯾﺔ اﻟﺗوﺟﯾﺔ اﻵﻣن )‪ (SEAD‬ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪(Ad-Hoc‬‬
‫ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ ﻓﻲ اﻟﻣﺣﺎﻛﻲ )‪ (Ns-2‬وﻣﻘﺎرﻧﺗﮭﺎ ﻣﻊ ﺧوارزﻣﯾﺔ اﻟﺗوﺟﯾﺔ )‪(DSDV‬‬
‫ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ وذﻟك ﻟﻛﻲ ﯾﺑﯾن ﻟﻧﺎ ﻣدي ﻛﻔﺎءة‬
‫ﺧوارزﻣﯾﺔ اﻟﺗوﺟﯾﺔ اﻵﻣن )‪ (SEAD‬ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت‬
‫اﻟﻣﺗﻧﻘﻠﺔ‪.‬‬
‫ﯾﻌرض ﻧﺑذة ﻋن ﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ‪,‬‬ ‫اﻟﻔﺻل اﻷول‬

‫وﻣﻘدﻣﺔ ﻋن اﻟﻣﺷروع وﺗﻌرﯾف ﺑﺎﻟﻐرض ﻣﻧﮫ واﻟطرق اﻟﻣﺳﺗﺧدﻣﺔ‬
‫ﻟﻠوﺻول إﻟﻰ اﻟﻧﺗﺎﺋﺞ ﺑﺄﺳﺗﺧدم اﻟﻣﺣﺎﻛﻲ )‪.(Ns-2‬‬
‫اﻟﻔﺻل اﻟﺛﺎﻧﻲ ﻣﻘدﻣﺔ ﻋن اﻟﺗوﺟﯾﺔ ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ‬

‫و ﯾﺷرح ﺧوارزﻣﯾﺎت اﻟﺗوﺟﯾﺔ ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪(Ad-Hoc‬‬
‫ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ‪ ,‬وﻣﻘدﻣﺔ ﻋن اﻵﻣﺎن ﻓﻲ اﻟﺷﺑﻛﺎت واﻟﮭدف ﻣﻧﮭﺎ ‪,‬‬
‫وﯾﻌرض ﺧوارزﻣﯾﺎت اﻟﺗوﺟﯾﺔ اﻵﻣن ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪(Ad-Hoc‬‬
‫ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ وﻛﯾﻔﯾﺔ ﻋﻣﻠﮭﺎ‪.‬‬
‫اﻟﻔﺻل اﻟﺛﺎﻟث ﯾﻌرض ﻧﺗﺎﺋﺞ ﺗﺣﻠﯾل اﻟﻣﻘﺎرﻧﮫ اﻟﺗﻲ ﺗم أﺳﺗﺧﻼﺻﮭﺎ ﻣن اﻟﻣﺣﺎﻛﻲ )‪(Ns-2‬‬
‫ﻟﺧوارزﻣﯾﺎت اﻟﺗوﺟﯾﺔ )‪ (DSDV, DSR, ADOV‬ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ‬
‫اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ ‪ ,‬وﻛﻣﺎ ﯾﻌرض اﻟﻔﺻل ﺷرح‬
‫ﻋن ﻛﯾﻔﯾﺔ أﺳﺗﺧﻼص اﻟﻧﺗﺎﺋﺞ ﻣن اﻟﻣﺣﺎﻛﻲ )‪ (Ns-2‬وذﻟك ﺑﺄﻋداد ﺑرﻧﺎﻣﺞ‬
‫ﻟﺗﺣﻠﯾل اﻟﻧﺗﺎﺋﺞ‪ .‬وﻣﻘدﻣﺔ ﻋن اﻟﻣﺣﺎﻛﻲ )‪.(Ns-2‬‬
‫ﯾﺷرح ﺧوارزﻣﯾﺔ اﻟﺗوﺟﯾﺔ اﻵﻣــن )‪ (SEAD‬ﻟﺷﺑﻛﺎت ذاﺗﯾـﺔ اﻟﺗﻧظﯾم‬ ‫اﻟﻔﺻل اﻟراﺑﻊ‬

‫)‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ و ﺑرﻣﺟﺗﮫ ﻓﻲ اﻟﻣﺣﺎﻛﻲ )‪, (Ns-2‬‬
‫وﻣﻘﺎرﻧﺗﮫ ﻣـﻊ ﺧوارزﻣﯾﺔ اﻟﺗوﺟﯾﺔ )‪ (DSDV‬ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم‬
‫)‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ ‪ ,‬وأﺳﺗﺧﻼص اﻟﻧﺗﺎﺋﺞ ﻣن اﻟﻣﺣﺎﻛﻲ‬
‫)‪ (Ns-2‬ﻣﻊ ﺗﺣﻠﯾﻠﮭﺎ‪.‬‬
‫اﻟﻔﺻل اﻟﺧﺎﻣس ﯾﺷﻣل اﻟﺧﺎﺗﻣﺔ واﻟﻌﻣل اﻟﻣﺳﺗﻘﺑﻠﻲ‪.‬‬

ACKNOWLEDGEMENT
First, I thank ALLAH the most merciful and compassionate for giving me the
power and the desire to finish this project.
Second, I would like to present my deep special thanks to my supervisors

Prof.Dr. Mohamed Hashem Abd El-Aziz and Dr. Mohammed T.EL-Sonni for
their valuable support during all the stages of this project including, but not limited
to, teaching me the professional way of thinking, providing me with necessary
references and helping me in the final appearance of this project. Their honest and
precise review was really helpful to trace points of weakness in the project and
strengthen them.
Third, I am very grateful to my professors were always supporting me to learn and

study and to all my family members who gave me spiritual support to complete
this project successfully.
Table of Contents
Chapter 1 ......................................................................................................................12
Introduction..................................................................................................................12
1.1 Overview of Mobile Ad-hoc Sensor Network .......................................................12
1.1.2. Sensor Nodes .................................................................................12
1.1.3. Sensor Node Components..............................................................................13
1.1.4. Characteristics and Requirements of Sensor Nodes ......................................14
1.1.3. Classified of Wireless Networks....................................................................15
1.1.3.1. Infrastructure Networks ..........................................................................15
1.1.3.2. Infrastructure less (Ad-hoc) Networks....................................................16
1.1.4. Common Architectures of Mobile Network ..................................................17
1.1.5. Application of Mobile Ad-Hoc Networks .....................................................18
1.1.6. Characteristics of Mobile Ad Hoc Networks.................................................20
1.2 Scope......................................................................................................................20
1.3 Objective ................................................................................................................21
1.4 Methodology ..........................................................................................................21
1.5 Thesis Structure and Layout ..................................................................................22
Chapter 2 ......................................................................................................................25
Routing & Secure Algorithm for Ad-hoc Networks....................................................25
2.1. Introduction...........................................................................................................25
2.2. Least-Cost Algorithms ..........................................................................................25
2.2.1. Dijkstra's algorithm .................................................................................25
2.2.2. Bellman-Ford algorithm.................................................................................27
2.3. Routing Algorithm in Wired Networks ................................................................27
2.3.1. Distance vector ..................................................................................28
2.3.2. Link state Routing .................................................................................29
2.3.3. Flooding ..................................................................................30
2.4. Routing Algorithm in a Mobile Ad-hoc Networks ...............................................31
2.4.1. Introduction ................................................................................31
2.4.2. Classification of Routing Protocols in MANETs ..........................................31
2.4.3. Problems with Routing in Mobile Ad-hoc Networks ....................................31
2.4.4. Proactive and Reactive Routing Protocols.....................................................32
2.4.4.1. Table Driven (DSDV) Routing Protocols...............................................33
2.4.5.2. On-Demand Routing Protocols...............................................................37
2.4.5.2.1. DSR Routing Protocol .....................................................................37
2.4.5.2.2. AODV Routing Protocol..................................................................40
2.5. Security .................................................................................................................45
2.5.1. Security Goals ..................................................................................46
2.5.2. Attacks in Networks .................................................................................46
2.5.2.1. Passive attacks ........................................................................................47
2.5.2.2. Active attacks..........................................................................................47
2.5.3. Adversary Model .................................................................................48
2.5.4. Attack Patterns of Sensor Mobile Ad-Hoc Networks....................................48
2.5.5. Secure Routing Protocol in Mobile Ad-hoc Networks ..................................50
2.6. Summary ...............................................................................................................51
1
Chapter 3 ......................................................................................................................54
Comparison and Performance Analysis of Ad-hoc Routing Protocols & Results.......54
3.1. Introduction...........................................................................................................54
3.2. Analysis the Simulation Traces File Format.........................................................56
3.2.1. Sent packet ..................................................................................57
3.2.2. Received packet ................................................................................57
3.2.3. Routing packets sent .................................................................................58
3.2.4. Duration of packets .................................................................................58
3.2.5. Drop packets at routing overhead ..................................................................59
3.2.6. Drops packet at End of time...........................................................................59
3.2.7. Movement Node .................................................................................59
3.3. Performance Metrics .............................................................................................59
3.3.1. Packet delivery fraction ratio .........................................................................60
3.3.2 Average End-to-End delay of data packets.....................................................60
3.3.3. Normalized routing load ................................................................................60
3.3.4. Routing packet overhead................................................................................60
3.3.5. Drop packets at routing overhead ..................................................................60
3.3.6. Drop of packets .................................................................................60
3.4. Simulation .............................................................................................................61
3.5. Simulation Procedure for Running Scenario ........................................................61
3.5.1. The Traffic sources Model.............................................................................63
3.5.2. The Mobility Model .................................................................................63
3.5.3. Simulation code of Tcl script .........................................................................64
3.5.4. Analyzer module .................................................................................64
3.5.5. Network Animator and Movement Node ......................................................65
3.6. Simulation Summary ............................................................................................66
3.7. Results & Performance Analysis Comparison of Ad-hoc Routing Protocols ......70
3.7.1. Packet delivery Comparison ..........................................................................70
3.7.2. Average End-End Delays Packet delivery.....................................................77
3.7.3. Normalized Routing Load Comparison .........................................................82
3.7.4. Routing Overhead Comparison......................................................................88
3.7.5. Drop Packets at Routing Overhead................................................................93
3.7.6. Drop Packets at End of Simulation Time Comparison ..................................97
3.7.7. Performance Analysis ...............................................................................100
3.7.7.1 Effect of Mobility ..................................................................................101
3.7.7.2 Routing Load Effect:..............................................................................101
3.8. Summary: ............................................................................................................101
Chapter 4 ....................................................................................................................107
Performance Analysis of Secure Routing Algorithm for Ad-hoc Sensor Mobile
Network......................................................................................................................107
4.1. SEAD Routing Protocol......................................................................................107
4.2. Results of simulation & Performance Analysis of Ad-hoc Secure Routing
Protocol ......................................................................................................................113
4.2.1 Packet delivery Comparison .........................................................................113
4.2.2 Average End-End Delays Packet delivery....................................................118
4.2.3 Normalized Routing Load Comparison ........................................................121
4.2.4 Routing Overhead Comparison.....................................................................125
4.2.5 Drop Packets at End Time of Simulation Comparison .................................128
4.2.6 Security Analysis and Evaluation .................................................................132
2
4.1. Summary .............................................................................................................133
Chapter 5 ....................................................................................................................136
Conclusion and Future Work .....................................................................................136
5.1. Conclusion ..........................................................................................................136
5.2. Future Work ........................................................................................................137
References ..................................................................................................................138
Publication .................................................................................................................143
Appendix A................................................................................................................144
Appendix B ................................................................................................................154
Appendix C ................................................................................................................162
Appendix D................................................................................................................170
Appendix E ................................................................................................................188
3
List of Abbreviations
ACK Acknowledge Receipt of a Packet

ADC Analog-to-Digital Converter
AED Average End-to-End delay of data packets
AGT Agent Level Trace
AODV Ad-Hoc On-Demand Distance Vector
API Application Programming Interface
ARAN Authenticated routing for Ad hoc Network
Ariadne Authenticated Routing for Ad-hoc Networks
ARP Address Resolution Protocol
BSS Basic Service Set
Command, Control, Communications, Computing, Intelligence, Surveillance,
C4ISRT
Reconnaissance and Targeting.
CBR Continuous bit rate
CGSR Cluster head-Gateway Switch Routing
CMU Carnegie Mellon University
CPU Central Processing Unit
CTS Clear To Send Packet
DCF Distributed Coordination Function
DoS Denial Of Service
DPEST Drop packets at End of simulation time
DPRO Drop packets at routing overhead
DSDV Destination-Sequenced Distance Vector
DSR Dynamic Source Routing
DV Distance vector protocol
FPGAs Field-Programmable Gate Arrays
FTP File Transfer Protocol
GOD General Operations Director
GPSR Greedy Perimeter Stateless Routing Protocol
HSR Hierarchical State Routing Protocol
info Information
IP Internet Protocol
LAN Local Area Network
LAR Location-aided Routing Protocol
LHAP Lightweight Hop-by-hop Authentication Protocol
LL Link layer
MAC Media Access Control
MANET Mobile ad-hoc network
MDC Manipulation Detection Code.
MEMS Micro-Electro-Mechanical Systems
MIC Message Integrity Check
NAM Network Animator
NDRL Normalized drop routing load ratio
NPDUs Network Protocol Data Units
4
NRL Normalized routing load

Ns-2 Simulator Network
OSI Open Systems Interconnection
OSPF Open Shortest Path First
OTcl Object oriented Tool Command Language
PAN Personal Area Network
Pkt packet
PNs Personal Networks
QoS Quality of Service
RERR Route Error message
RPO Routing packet overhead
RREP Route reply
RREQ Route request
RTR Routing Trace Level
RTS Request to Send Packet
SAODV Secure Ad-hoc On-Demand Distance Vector Routing
SAR Security-AwhereRouting Protocol
SEAD Secure efficient distance vector routing for mobile wireless ad-hoc networks
SIMT Simulation Time
SLSP Secure Link State Protocol
SMT Secure Message Transmission
SPAAR Secure Position Aided Ad hoc Routing
SRP Secure Routing Protocol
STAR Source Tree Adaptive Routing
5
List of Tables
Table 2.1: Dijkstra's algorithm with source node A of network I 26

Table 2.2: Bellman algorithm with source node A of network I 26
Table 2.3: Proactive versus Reactive Protocols 33
Table 2.4: Table Entries 34
Table 2.5: Secure Ad Hoc Routing Protocols Comparison 51
Table 3.1: Sample Ns-2 Trace Formats 57
Table 3.2: Scenario for the simulator Ns-2 experiments 61
Table 3.3: Total of generation Parameters input files of simulator Ns-2 at all
67
Pause time of simulation for all routing protocols
Table 3.4: Generation outputs trace file formats of simulator Ns-2 at simulation
68
time 100s for each routing protocol
68
69
Table 3.7: Total generation outputs trace file formats of simulator Ns-2 at
69
simulation time 100,500,900 second for each routing protocol
Table 3.8: Total of all generation outputs trace file formats of simulator Ns-2 for
70
all routing protocols used
Table 4.1: (a) Routing table node 1, (b) Routing table node 1 after topology
108
change
Table 4.2: Example of One-way hash chains 110
Table 4.3: The attack patterns with SEAD protocol 133
6
List of Figures
Figure 1.1: sensor node hardware 13
Figure 1.2 Infrastructure wireless networks 15
Figure 1.3: Infrastructure network 16
Figure 1.4: Ad-hoc Network (peer to peer) 16
Figure 1.5: A two-tier mobile ad-hoc network. 18
Figure 1.6: A flat mobile ad-hoc network. 18
Figure 1.7: Example applications of MANET 19
Figure 2.1: Steps of Dijkstra's algorithm 26
Figure 2.2: Network I 26
Figure 2.3: Every node maintains a routing table 28
Figure 2.4: Node B broadcasts the new routing information to neighbors 28
Figure 2.5: Broadcasts to update tables of C, B, A with new entry of node D 29
Figure 2.6: Subnet and corresponding link state packets all six routers 29
Figure 2.7: Flooding example (hop count = 3) 30
Figure 2.8: Classification of ad-hoc routing protocols. 32
Figure 2.9: Every mobile node in the network maintains a routing table 34
Figure 2.10: Route Advertisement 35
Figure 2.11: Broken Link 35
Figure 2.12: New node add to topology 36
Figure 2.13: New node contact 36
Figure 2.14: Building of the route record during route discovery 37
Figure 2.15: Propagation of the route reply with route record 38
Figure 2.16: Data delivery 38
Figure 2.17: Route maintenance indicates a source route is broken 39
Figure 2.18: Node S is notified with a ROUTE ERROR packet 39
Figure 2.19: Propagation of the RREQ 41
Figure 2.20: Steps of propagation RREQ and reverse path of RREP 42
Figure 2.21: Path of the RREP and forward path to the source 43
Figure 2.22: Data delivery to the destination node D 43
Figure 2.23: Route maintenance indicates a link failure 44
Figure 2.24: Node is turn propagate the link failure notification 44
Figure2.25. Topology change in ad-hoc networks of nodes D 45
Figure 2.26: The release of message contents 46
Figure 3.1: Simulator usage 54
Figure 3.2: The basic structure of simulator Ns-2 55
Figure 3.3: Simulation procedure for running scenario. 62
Figure 3.4: Visualized in network animator 65
Figure 3.5: Movement node 6 at pause time 0 sec speed 2 m/s 66
Figure 3.6: Movement Node 6 at pause time 0 sec speed 20 m/s 66
Figure 3.7: (a) Packet delivery ratio at movement speed (2m/s and 20m/s) and
73
SIMT100s with 10 sources.
Figure 3.7: (b) Packet delivery ratio at movement speed (2m/s and 20m/s) and
73
Figure 3.7: (c) Packet delivery ratio at movement speed (2m/s and 20m/s) and
74
Figure 3.7: (d) Packet delivery ratio at movement speed (2m/s and 20m/s) and
74
Figure 3.7: (e) Packet delivery ratio at movement speed (2m/s and 20m/s) and
75
Figure 3.7: (f) Packet delivery ratio at movement speed (2m/s and 20m/s) and
75
7
Figure 3.7: (g) Packet delivery ratio at movement speed (2m/s and 20m/s) and
76
Figure 3.7: (h) Packet delivery ratio at movement speed (2m/s and 20m/s) and
76
Figure 3.7: (i) Packet delivery ratio at movement speed (2m/s and 20m/s) and
77
SIMT900s with 30 sources
Figure 3.8: (a) Average End-End delays at movement speed (2m/s and 20m/s) and
78
Figure 3.8: (b) Average End-End delays at movement speed (2m/s and 20m/s) and
78
Figure 3.8: (c) Average End-End delays at movement speed (2m/s and 20m/s) and
79
Figure 3.8: (d) Average End-End delays at movement speed (2m/s and 20m/s) and
79
Figure 3.8: (e) Average End-End delays at movement speed (2m/s and 20m/s) and
80
Figure 3.8: (f) Average End-End delays at movement speed (2m/s and 20m/s) and
80
Figure 3.8: (g) Average End-End delays at movement speed (2m/s and 20m/s) and
81
Figure 3.8: (h) Average End-End delays at movement speed (2m/s and 20m/s) and
81
Figure 3.8: (i) Average End-End delays at movement speed (2m/s and 20m/s) and
82
Figure 3.9: (a) Normalized Routing load at movement speed (2m/s and 20m/s) and
83
Figure 3.9: (b) Normalized Routing load at movement speed (2m/s and 20m/s) and
84
Figure 3.9: (c) Normalized Routing load at movement speed (2m/s and 20m/s) and
84
Figure 3.9: (d) Normalized Routing load at movement speed (2m/s and 20m/s) and
85
Figure 3.9: (e) Normalized Routing load at movement speed (2m/s and 20m/s) and
85
Figure 3.9: (f) Normalized Routing load at movement speed (2m/s and 20m/s) and
86
Figure 3.9: (g) Normalized Routing load at movement speed (2m/s and 20m/s) and
86
Figure 3.9: (h) Normalized Routing load at movement speed (2m/s and 20m/s) and
87
Figure 3.9: (i) Normalized Routing load at movement speed (2m/s and 20m/s) and
87
Figure 3.10: (a) Routing Overhead at movement speed (2m/s and 20m/s) and
89
Figure 3.10: (b) Routing overhead at movement speed (2m/s and 20m/s) and
89
Figure 3.10: (c) Routing overhead at movement speed (2m/s and 20m/s) and
90
Figure 3.10: (d) Routing overhead at movement speed (2m/s and 20m/s) and
90
Figure 3.10: (e) Routing overhead at movement speed (2m/s and 20m/s) and
91
Figure 3.10: (f) Routing overhead at movement speed (2m/s and 20m/s) and SIMT900s
91
with 20 sources.
8
Figure 3.10: (g) Routing overhead at movement speed (2m/s and 20m/s) and
92
Figure 3.10: (h) Routing overhead at movement speed (2m/s and 20m/s) and
92
Figure 3.10: (i) Routing overhead at movement speed (2m/s and 20m/s) and SIMT900s
93
with 30 sources
Figure 3.11: (a) Drop packets at routing overhead at movement speed (2m/s and
94
20m/s) and SIMT100s with 10 sources.
Figure 3.11: (b) Drop packets at routing overhead at movement speed (2m/s and
94
Figure 3.11: (c) Drop packets at routing overhead at movement speed (2m/s and
95
Figure 3.11: (d) Drop packets at routing overhead at movement speed (2m/s and
95
Figure 3.11: (e) Drop packets at routing overhead at movement speed (2m/s and
96
Figure 3.11: (f) Drop packets at routing overhead at movement speed (2m/s and 20m/s)
96
and SIMT900s with 30 sources
Figure 3.12: (a) Drop packets at end of simulation time at movement speed (2m/s and
97
Figure 3.12: (b) Drop packets at end of simulation time at movement speed (2m/s and
98
Figure 3.12: (c) Drop packets at end of simulation time at movement speed (2m/s and
98
Figure 3.12: (d) Drop packets at end of simulation time at movement speed (2m/s and
99
Figure 3.12: (e) Drop packets at end of simulation time at movement speed (2m/s and
99
Figure 3.12: (f) Drop packets at end of simulation time at movement speed (2m/s and
100
20m/s) and SIMT900s with 30 sources
Figure 4.1 (a) Ad-hoc network with 12 nodes. (b) Ad-hoc network with change in
108
location of the node 9.
Figure 4.2: Ad-hoc networks with value of hash in routing table entries for nodes 110
Figure 4.3: Ad-hoc networks with node(A) send update 112
Figure 4.4: Ad-hoc networks with node B detect broken link 112
115
115
116
116
117
117
Figure 4.6: (a) Average End-End delay at movement speed (2m/s and 20m/s) and
118
Figure 4.6: (b) Average End-End delay at movement speed (2m/s and 20m/s) and
119
Figure 4.6: (c) Average End-End delay at movement speed (2m/s and 20m/s) and
119
9
Figure 4.6: (d) Average End-End delay at movement speed (2m/s and 20m/s) and
120
Figure 4.6: (e) Average End-End delay at movement speed (2m/s and 20m/s) and
120
Figure 4.6: (f) Average End-End delay at movement speed (2m/s and 20m/s) and
121
122
122
123
123
124
124
Figure 4.8: (a) Routing overhead at movement speed (2m/s and 20m/s) and SIMT100s
125
with 10 sources.
Figure 4.8: (b) Routing overhead at movement speed (2m/s and 20m/s) and SIMT900s
126
with 10 sources.
Figure 4.8: (c) Routing overhead at movement speed (2m/s and 20m/s) and SIMT100s
126
with 20 sources.
Figure 4.8: (d) Routing overhead at movement speed (2m/s and 20m/s) and SIMT900s
127
with 20 sources.
Figure 4.8: (e) Routing overhead at movement speed (2m/s and 20m/s) and SIMT100s
127
with 30 sources.
128
with 30 sources
Figure 4.9: (a) Drop packets at End of simulation time at movement speed (2m/s and
129
Figure 4.9: (b) Drop packets at End of simulation time at movement speed (2m/s and
129
Figure 4.9: (c) Drop packets at End of simulation time at movement speed (2m/s and
130
Figure 4.9: (d) Drop packets at End of simulation time at movement speed (2m/s and
130
Figure 4.9: (e) Drop packets at End of simulation time at movement speed (2m/s and
131
Figure 4.9: (f) Drop packets at End of simulation time at movement speed (2m/s and
131
10
Chapter 1
Introduction
11
Chapter 1
Introduction
1.1 Overview of Mobile Ad-hoc Sensor Network

Wireless networks use some sort of radio frequencies in air to transmit and receive
data instead of using some physical cables. The most admiring fact in these networks
is that it eliminates the need for laying out expensive cables and maintenance costs.
In recent years wireless sensor networks and advance in micro-electro-mechanical
systems, (MEMS) which are the integrations of mechanical elements, sensors,
actuators and electronics on a common silicon substrate through micro fabrication
technology, have enabled low-cost and low-power in electronics and wireless
communication technology enabled tiny sensor nodes to communicate in short
distance [4].
Wireless Sensor Networks (WSNs) comprise numerous tiny sensor nodes that are
deployed in spatially distributed terrain. Each sensor node is endowed with a limited
amount of processing, but when coordinated with the information from other nodes, it
has the ability to measure the given physical environment in great details or to execute
a task with complex functions. Hence, a sensor network can be described as a
collection of sensor nodes that coordinate with each other to perform some specific
actions. Since each sensor node is fitted with an on-board processor, sensor nodes use
their processing abilities to find out simple computations and transmit only the
required data. These features allow the sensor networks to be used in many
applications, like military, security and environment. Wireless sensor networks can
also be deployed in the ways that the wired sensor system cannot be deployed such as
in the chemical environments that are inaccessible by humans.
1.1.2. Sensor Nodes

A sensor node is composed of a power unit, a processing unit, a sensing unit, and
a communication unit. The processing unit is responsible for collecting and
processing signals captured from sensors and transmitting them to the network. Figure
1.1 illustrates the basic components of the ordinary sensor node. Sensors are devices
that produce a measurable response to a change in a physical condition like
temperature, lightning condition and pressure, etc [4]. The wireless communication
channel provides a medium to transfer signals from sensors to exterior world or a
computer network, and also a mechanism of communication to establish and maintain
a wireless sensor network which is usually ad-hoc [4, 5].
The design of wireless sensor systems has gained increasing importance for a variety
of civil and military applications. Advances in MEMS technology and its associated
interfaces, signal processing, and RF circuitry have enabled the development of
wireless sensor nodes.
12
Figure 1.1: sensor node hardware
1.1.3. Sensor Node Components

As stated previously, the main components of sensors are a sensing unit, a processing
unit, a communication (transceiver) unit, and a power unit. The following is aclear
explanation of these units and their characteristics [5]:
 Sensing Unit: The main functionality of the sensing unit is to sense or measure
physical data from the target area. The analog voltage or signal is generated by the
sensor corresponding to the observed phenomenon. The continual waveform is
digitized by an analog-to-digital converter (ADC) and then delivered to the
processing unit for further analysis. The sensing unit is a current technology
bottleneck because the sensing technologies are much slower than those of the
semi-conductors.
 Processing Unit: The processing unit plays a major role in managing collaboration
with other sensors to achieve the predefined tasks. There are currently several
families of this unit including microcontrollers, microprocessors, and field-
programmable gate arrays (FPGAs). FPGAs consume more energy and wherenot
compatible with traditional programming methodologies. However, they can be
reprogrammable and reconfigurable to eliminate deployment costs. Non-volatile
memory and interfaces such as ADCs can be integrated onto a single integrated
circuit. The processing unit needs storage for tasking and to minimize the size of
transmitted messages by local processing and data aggregation. Flash memory is
widely used due to its cost and storage capacity.
 Communication Unit: There are three deploying communication schemes in
sensors including optical communication (laser), infrared, and radiofrequency.
Laser consumes less energy than radio and provides high security, but requires
line of sight and is sensitive to atmospheric conditions. Infrared, like laser, needs
no antenna but is limited in its broadcasting capacity. RF is the most easy to use
but requires antenna. Various energy consumption reduction strategies have been
developed such as modulation, filtering, and demodulation. Amplitude and
frequency modulation are standard mechanisms. Amplitude modulation is simple
but susceptible to noise.
13
 Power Unit: Power consumption is a major weakness of sensor networks. Any

energy preservation schemes can help extend sensor’s lifetime. Batteries used in
sensors can be categorized into two groups; rechargeable and non-rechargeable.
Often in strong environments, it is impossible to recharge or change a battery.
Current sensors are developed to be able to renew their energy from solar or
vibration energy. Alkaline batteries have a wide voltage range and large physical
size while lithium provides a constant voltage supply but with very low nominal
discharge currents. Nickel Metal Hydride can be recharged but with a significant
decrease in energy density. Two major power saving policies can be found in
literature. Unused devices can be shut down and activated when required. This is
called “Dynamic Power Management (DPM)” which requires support from the
operating system and stochastic analysis to predict future events. In another
approach, Dynamic Voltage Scheduling (DVS), power can be varied to allow for a
non-deterministic workload.
1.1.4. Characteristics and Requirements of Sensor Nodes

At each system, wireless sensor networks are constructed by coming together with
many components. However, these components determine the statics and dynamics of
the entire system. To be able to make general provision about the system, first, the
characteristics and requirements of the components must be analyzed.
 Energy Efficiency: Sensor node must be energy efficient. Sensor nodes have a
limited amount of energy resources that determines their lifetime. Since it is
unfeasible to recharge thousands of nodes, each node should be as energy efficient
as possible. Hence, energy is the major resource being primary metric for many
analyses.
 Low Cost: Sensor nodes should be cheap enough, since many wireless sensor
networks have hundreds or thousands of sensor nodes.
 Distributed Sensing: Using a wireless sensor network, much more data can be
collected from the environment, compared to just one sensor. Even deploying a
sensor with great line of sight could have some prevention. This, distributed
sensing provides robustness to environmental obstacles.
 Wireless Communication: The sensor node needs to have wireless ability. In many
applications, the environment being monitored does not have installed
infrastructure for communications. Thus, the nodes should use wireless
communication channels. A node being wireless also enables the installation of a
network by deploying nodes and can be used in many other applications.
 Multi Hop: A sensor node may not reach the sink or the base station due to the
some reasons. The solution is to communicate through multi hop. So the
availability of the sink or base station is satisfied. Another advantage is that it can
be more energy economic to transmit many short distance messages than one-long
distance message.
 Distributed Processing: Each sensor node should be able to process local data,
using filtering and data fusion algorithms to collect data from environment
through its sensors and aggregate this data, transforming it to information which is
useful for the application.
14
1.1.3. Classification of Wireless Networks

Wireless networking is an emerging technology that allows users to access
information and services electronically, regardless of their geographic position.
Wireless networks can be classified in two types:
1.1.3.1. Infrastructure Networks

The infrastructure network called BSS mode consists of a network with fixed and
wired gateways. A mobile host communicates with a bridge in the network called
base station within its communication radius called traditionally infrastructure-based
as shown in figure 1.2 with an Access Point and its network cell [34].
Figure 1.2 Infrastructure wireless networks
The mobile unit can move geographically while it is communicating. When it goes
out of range of one base station, it connects with a new base station and starts
communicating through it. This is called handoff. In this approach the base stations
are fixed [12]. The example in figure 1.3 shows a typical infrastructure network.
Serial data leaves the PC in an Ethernet frame, bound for the IP address of the
destination Wireless Device Server (WDS). It traverses a Local Area Network (LAN)
and is then converted to Wireless Ethernet at the Access Point. This data is received
by the WDS, which strips away the Ethernet header and presents the serial data to the
COM port. Multiple WDS could be used in the sphere of influence of each Access
Point [32].
15
Figure 1.3: Infrastructure network
1.1.3.2. Infrastructure less (Ad-hoc) Networks

In ad-hoc networks, all nodes are mobile and can be connected dynamically in an
arbitrary manner. All nodes of these networks behave as routers and take part in
discovery and maintenance of routes to other nodes in the network as shown in
figure1.4 which shows a simple ad-hoc network with three nodes. The outermost
nodes are not within transmitter range of each other. However, the middle node can be
used to forward packets between the outermost nodes. The middle node is acting as a
router and the three nodes have formed an ad-hoc network.
.
Figure 1.4: Ad-hoc Network (peer to peer)
16
Ad-hoc networks are very useful in emergency search and rescue operations, meetings
or conventions in which persons wish to quickly share information and in data
acquisition operations in inhospitable terrain. Mobile ad-hoc networks (MANET) are
a new paradigm of wireless communication for mobile hosts. Hosts are always
represented as different nodes in the mobile ad-hoc networks. There is a number of
differences between mobile ad-hoc networks and traditional networks. Ad-hoc
networks do not rely on any fixed infrastructure. They rely on each other to keep the
network connected. Also, the topology of ad-hoc networks is dynamically changing
and its communication is based on wireless links. The definition of Mobile ad-hoc
network is a collection of wireless mobile nodes dynamically forming a temporary
network without the use of any existing network infrastructure or centralized
administration called peer to peer or ad hoc mode as shown in figure 1.4. Due to the
limited transmission range of wireless network interfaces, multiple hops may be
needed for one node to exchange data with another across the network [1], Ad-hoc
wireless networks are also self-organizing and adaptive, this means that a formed
network can be de-formed on the fly without the need for any system administration.
The term “ad-hoc” tends to imply that it can take different forms and that it can be
mobile, standalone, or networked [2]. There is a number of characteristics in mobile
ad-hoc networks. One of them is that there are dynamic topologies. Nodes are free to
move arbitrarily. Thus, the network topology is typically multi-hop (which means that
intermediate hosts must relay messages between hosts not in direct contact of each
other, which is called forwarding), so it may change randomly and rapidly at
unpredictable times. Another characteristic is bandwidth constrain. Wireless links will
continue to have significantly lower capacity than their hardwired counterparts. Also,
there is energy-constrained in the networks. Some or all of the nodes in a mobile ad-
hoc network may rely on batteries or other exhaustible means for their energy.
Finally, there is limited physical security. Mobile wireless networks are generally
more prone to physical security threats than are fixed-cable nets. The increased
possibility of eavesdropping, spoofing, and denial-of-service attacks should be
carefully considered [3].
1.1.4. Common Architectures of Mobile Network

There are two common architectures of a mobile ad hoc network:
 Hierarchical network architecture: Each sub-network dynamically interconnects
with other sub-networks through its gateways. All traffic to and from a sub-
network must pass through its gateways. It could be a feasible network model for
personal networks (PNs), in which multiple clusters belonged to the same or
different persons could form big mobile ad-hoc networks dynamically [33]. An
example of such mobile ad-hoc networks is shown in figure 1.5.
 Flat network Architecture: In this architecture, all nodes are treated equally, and
there is no gateway in a cluster [33]. An example of flat mobile ad hoc networks is
shown in figure1.6.
17
Figure 1.5: A two-tier mobile ad-hoc network [33].
Figure 1.6: A flat mobile ad-hoc network [33].
1.1.5. Application of Mobile Ad-Hoc Networks

Wireless ad-hoc networks can be deployed in areas where a wired network
infrastructure may be undesirable due to reasons such as cost or convenience. It can
be rapidly deployed to support emergency requirements, short-term needs, and
coverage in undeveloped areas. So, there is a plethora of applications for wireless ad-
hoc networks. As a matter of fact, any day-to-day application such as electronic email
and file transfer can be considered to be easily deployable within an ad-hoc network
environment. It is thus significant to emphasize the wide range of military
applications [4] possible with ad-hoc networks. Not to mention, the technology was
initially developed keeping in mind the military applications, such as battlefield in an
unknown territory where an infrastructure network is almost impossible to have or to
maintain. In such situations, the ad-hoc networks having self-organizing capability
can be effectively used where other technologies either fail or cannot be deployed
18
effectively. As a result, as shown in figure 1.7 some well-known ad-hoc network

applications [3, 4] are:
Figure 1.7: Example applications of MANET [72]
 Military applications: Wireless sensor networks can be an integral part of military

command, control, communications, computing, intelligence, surveillance,
reconnaissance and targeting (C4ISRT) systems. The rapid deployment, self-
organization and fault tolerance characteristics of sensor networks make them a
very promising sensing technique for military C4ISRT. Since sensor networks are
based on the dense deployment of disposable and low-cost sensor nodes,
destruction of some nodes by hostile actions does not affect a military operation as
much as the destruction of a traditional sensor, which makes sensor networks
concept a better approach for battlefields.
 Collaborative Work: For some business environments, the need for collaborative
computing might be more important outside office environments than inside. After
all, it is often the case where people do need to have outside meetings to cooperate
and exchange information on a given project. for example of potential practical
use of mobile ad-hoc networks may be a group of people with laptop computers at
a conference that may wish to exchange files and data without mediation of any
additional infrastructure in-between.
 Health applications: Tracking and monitoring doctors and patients inside a
hospital: Each patient has small and light weight sensor nodes attached to them.
Each sensor node has its specific task. For example, one sensor node may be
detecting the heart rate while another is detecting the blood pressure. Doctors may
also carry a sensor node, which allows other doctors to locate them within the
hospital.
 Personal Area Networking and Bluetooth: A personal area network (PAN) is a
short- range, localized network where nodes are usually associated with a given
person. These nodes could be attached to someone’s pulse watch, belt, and so on.
In these scenarios, mobility is only a major consideration when interaction among
several PANs is necessary [37].
19
1.1.6. Characteristics of Mobile Ad Hoc Networks

Mobile ad-hoc networks have some specific characteristics that arementioned briefly
[3,33,39]:
 Wireless: Nodes communicate wirelessly and share the same media (radio,
infrared, etc.).
 Ad-hoc-based: A mobile ad-hoc network is a temporary network formed
dynamically in an arbitrary manner by a collection of nodes as need arises.
 Autonomous and infrastructure less: MANET does not depend on any established
infrastructure or centralized administration. Each node operates in distributed peer
-to-peer mode, acts as an independent router, and generates independent data
 Mobility: Each node is free to move about while communicating with other nodes.
The topology of such an ad-hoc network is dynamic in nature due to constant
movement of the participating nodes, causing the intercommunication patterns
among nodes to change continuously.
 Dynamic network topologies: Nodes are free to move arbitrarily. Thus, the
network topology may change randomly and rapidly at unpredictable times, and
may consist of both bidirectional and unidirectional links.
 Bandwidth-constrained, variable capacity links: Wireless links will continue to
have significantly lower capacity than their hardwired counterparts. In addition,
the realized throughput of wireless communications, after accounting for the
effects of multiple access, fading, noise, and interference conditions, is often much
less than a radio's maximum transmission rate.
 Energy-constrained operation: Some or all of the nodes in a MANET may rely on
batteries or other exhaustible means for their energy. For these nodes, the most
important system design optimization criteria may be energy conservation.
 Multi-hop routing: No dedicated routers are necessary; every node acts as a router
and forwards each others’ packets to enable information sharing between mobile
hosts.
 Limited Physical Security: Mobile wireless networks are generally more prone to
physical security threats than fixed-cable nets. The increased possibility of
eavesdropping, spoofing, selfish behavior and denial-of-service attacks should be
carefully considered. These characteristics and challenges create a set of
underlying assumptions and performance concerns for protocol design which
extend beyond those guiding the design of routing within the higher-speed, semi-
static topology of the fixed Internet.
1.2 Scope
As wireless sensor networks have been used in a lot of applications, monitoring nodes
in the network are needed for some applications. The important functions which need
to be monitored are the communicated data between each node, the movement of
nodes, etc.
The Scope of this master thesis is to use a simulator Ns-2 to support the mobility
wireless sensor network simulation, study simulator and has been designed as
analyzer module used to analyze the simulation output results with 6 performance
metrics an a two new performance metrics (drop packets at routing overhead and drop
packets at end of simulation time (trace files format). and to implement secure
routing algorithm protocol in simulator Ns-2, simulation, performance analysis and
comparing secure routing algorithm protocol with traditional routing algorithm
protocol and comparing between three routing algorithm of mobile ad-hoc network
20
protocols, [Destination-Sequenced Distance Vector (DSDV), Ad-Hoc On-Demand

Distance Vector (AODV) and Dynamic Source Routing (DSR)] by simulation and
performance analysis.
1.3 Objective
To achieve the scopes of this master thesis, some steps are required. The first: is
survey of ad-hoc sensory network, description of the operation of (routing algorithm
for ad-hoc networks and Security of Secure Routing algorithm protocol) and studying
simulator Ns-2 to analyze the output simulation results of trace file formats and design
analyzer module of performance metrics. Second: simulator Ns-2 is used in to
evaluation, comparison and performance analysis, between three mobile ad-hoc
routing algorithm protocols classification of flat routing protocols. Destination-
Sequenced Distance Vector (DSDV), Ad-Hoc On-Demand Distance Vector (AODV)
and Dynamic Source Routing (DSR), were currently implemented in simulator Ns-2.
Third: secure routing protocol SEAD: secure efficient distance vector routing for
mobile wireless ad-hoc networks is implemented in simulator network Ns-2,
simulation, performance analysis and comparing secure routing algorithm protocol
with traditional DSDV routing protocol. Finally comes the conclusion and suggestion
for future work.
1.4 Methodology
The research methodologies on sensor mobile ad-hoc routing algorithm protocols and
secure routing protocol evaluation has three parts:
First part Survey of ad-hoc sensory network and using simulator Ns-2, which
supports wireless networks is implemented to be used with the wireless sensor
network. This simulator is used to test different routing algorithms as one part of
simulation and to analyze the simulation output results of trace file formats in Ns-2
simulator that contained the data of our simulation to analyze the performance metrics
by design analyzer module, that can be shown in both text and graphical interface for
the events and for the illustration of network topology with the physical environment
as background.
Second part Ns-2 based simulator is used for evaluation, comparing different
simulation times (100s, 500s and 900s), connectivity sources (10, 20, 30 and 40) and
with two different maximum speeds of node movement 2meters per second &
20meters per second using Ns-2 simulator, simulation and performance analysis
between three different sensor mobile ad-hoc routing algorithm protocols
(Classification of flat routing protocols). Destination-Sequenced Distance Vector
(DSDV), Ad-Hoc On-Demand Distance Vector (AODV) and Dynamic Source
Routing (DSR). Which are currently implemented in Ns-2 simulator for sensor mobile
ad-hoc networking.
Third part One of the secure routing algorithm protocol is chosen SEAD: secure
efficient distance vector routing for mobile wireless ad-hoc networks and implement
the algorithm of protocol to simulator network Ns-2, simulation and performance
analysis with compared for different simulation times (100s and 900s), connectivity
sources (10, 20, 30 and 40), two different maximum speeds of node movement
2meters per second & 20meters per second and compared with traditional DSDV
routing protocol.
Finally Conclusion and future work.
21
1.5 Thesis Structure and Layout

The thesis consists of 5 chapters. The rest of the 4 chapters are structured as follows:
Chapter 2 describes the detailed methodologies of routing algorithm for ad-hoc

networks introduction to describe the least-cost algorithms with routing algorithm in
wired network and routing algorithm of a Mobile Ad-hoc Networks (MANETs). It
includes introduction, classification of routing protocols in MANETs and problems
with routing in MANETs and it describes the detailed operation chosen for three
routing protocols (Table Driven Routing Protocols (DSDV) On-Demand Routing
Protocols (AODV and DSR)). It also describes the security & Secure Routing
protocol introduction with security goals, attacks, adversary Model and study against
attack patterns in MANETs.
Chapter 3 Comparison and Performance Analysis of Ad-hoc Routing Protocols &

Results includes introduction of Simulator Ns-2 and implementation of analyzer trace
file formats & Simulation to produce the total number of (sent packet, received
packet, routing packets sent, duration of packets, drop packets at routing overhead,
drop packets at end of time and movement node at each simulation time). From
analyzing trace file formats it can be compared among the routing protocols with
respect to the following network performance metrics as (packet delivery fraction
ratio(PDF), Average End-to-End delay of data packets (AED), Normalized routing
load (NRL), Routing packet overhead (RPO), Normalized drop routing load ratio
(NDRL), drop packets at End of simulation time (DPEST)). It describes the
Simulation environments for scenario of the simulator Ns-2 experiments and the
simulation procedure for running Scenario include traffic sources model, mobility
mode, simulation code of Tcl script, analyzer module, Network animator and shows
the movement node used mobility random waypoint model by analyzer module to
record the movement source node and the movement of all source node at each
simulation time and experimental results and performance analysis of ad-hoc routing
protocols (DSDV, DSR and AODV) based on the performance metrics used, and it
gives the interpretations of the results obtained and discussed. The simulation results
are discussed and compared.
Chapter 4 Performance Analysis of Secure Routing Algorithm for Ad-hoc Sensor

Mobile Network, describes the detailed operation and implementation of secure
routing algorithm protocol (SEAD: Secure Efficient Ad-hoc Distance Vector Routing
Protocol) with simulation results and performance analysis of ad-hoc secure routing
protocol (SEAD) based on the performance metrics used, and gives the interpretations
of the results obtained. The simulation results are discussed and the results compared
between SEAD secure routing protocol with traditional DSDV routing protocol.
Finally, chapter 5 concludes the thesis and outlines future work. It summarizes the results
reported in chapter 3,4 and describes the achievements of this thesis and suggests future
work.
List of References, Glossary and Published Paper.
Appendix A attached implementation code C/C++ program to compute least coast

path of nodes in networks, for Dijkstra Algorithm and Bellman Ford Algorithm using
22
three networks, Network I, Network II and example of Book to test our

implementation code.
Appendix B attached implementation code Tcl script of simulation used to run Ns-2
simulator ver 2.31 and simulate (DSDV, DSR and AODV) routing protocols and
(SEAD) secure routing protocol for Ad-hoc sensor mobile networks.
Appendix C attached code of design analyzer module of new trace file formats for
Simulator Ns-2 ver 2.31. First implementations Java code to analyzer module of Trace
File Formats to records of the packets and computation of the performance metrics.
Second C/C++ Code to analyzer module the trace file formats records the movement
source node and movement of all source nodes at each simulation time.
Appendix D attached implementation code C/C++ of SEAD: Secure Efficient Ad-hoc

Distance Vector Routing Protocol in Ns-2 Simulator ver 2.31 with environment of
attackers.
Appendix E Simulator Ns-2.
23
Chapter 2
Routing & Secure Algorithm for

Ad-hoc Networks
24
Chapter 2
Routing & Secure Algorithm for Ad-hoc Networks
2.1. Introduction
The term Routing is the process of choosing the path that individual packets should
follow through the network. The methodology used to decide the best route is called
the routing algorithm. The protocol used to exchange routing information between
nodes is called the routing protocol. To emphasize the special characteristics of a
MANET routing protocol, the following gives a brief overview of examining least-
cost algorithms that are a central part of routing in packets in networks and traditional
routing protocols for wired networks, these latter topics cover issues that are relevant
to routing algorithms.
2.2. Least-Cost Algorithms

Given a network of nodes connected by bidirectional links, where each link has a cost
associated with it in each direction, defines the cost of a path between two nodes as
the sum of the costs of the links traversed. For each pair of nodes, find the path with
the least cost. Most least-cost routing algorithms in use in packet networks are
variations of one of two common algorithms, known as Dijkstra's algorithm and the
Bellman-Ford algorithm [43].
2.2.1. Dijkstra's algorithm

Dijkstra can be defined as follows: Find the shortest paths from a given source node to
all other nodes by developing the paths in order of increasing path length [43].
Dijkstra's algorithm creates labels associated with vertices. These labels represent the
distance (cost) from the source vertex to that particular vertex. Within the graph, there
exist two kinds of labels: temporary and permanent as shown in figure 2.9. The
temporary labels are given to vertices that have not been reached. The value given to
these temporary labels can vary. Permanent labels are given to vertices that have been
reached and their distance (cost) to the source vertex is known. The value given to
these labels is the distance (cost) of that vertex to the source vertex. For any given
vertex, there must be a permanent label or a temporary label, but not both [53].
The algorithm begins by initializing any vertex in the graph (vertex A, for example) a
permanent label with the value of 0, and all other vertices a temporary label with the
value of 0 as shown in figure 2.1(a).
The algorithm then proceeds to select the least cost edge connecting a vertex with a
permanent label (currently vertex A) to a vertex with a temporary label (vertex B, for
example). Vertex B's label is then updated from a temporary to a permanent
label. Vertex B's value is then determined by the addition of the cost of the edge with
vertex A's value as shown in figure 2.1(b).
The next step is to find the next least cost edge extending to a vertex with a temporary
label from either vertex A or vertex B (vertex C, for example), change vertex C's label
to permanent, and determine its distance to vertex A as shown in figure 2.1(c).
This process is repeated until the labels of all vertices in the graph are permanent as
shown in figure 2.1(d). Another good way to practice the algorithm is to use the Web
site [49,50,51 and 52]. With the Web site, one can construct any graph used in this
activity by creating vertices and undirected. Dijkstra’s algorithm is implemented by
25
programming language C++ tested program code c++ for three networks, each link is
labeled with its cost in both directions (see Appendix A).
Figure 2.1: Steps of Dijkstra's algorithm [53]
For example, networks I as shown in figure 2.2. Ech link labeled with its cost in
both directions, the least cost of network I using Dijkstra’s algorithm as shown by the
result of applying this algorithm in Table 2.1 with source node A at each step, the
final iteration, the least-cost path (L) to each node and the cost of that path, have been
developed. The same procedure can be used with node B as source node, and so on.
Where T set of nodes.
Figure 2.2: Network I
26
I T L[B] path L[C] path L[D] path L[E] path L[F] path
0 A 1 A-B 0 ----- 4 A-D 0 ----- 0 -----
1 A,B 1 A-B 4 A-B-C 4 A-D 2 A-B-E 0 -----
2 A,B,E 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 6 A-B-E-F
3 A,B,E,C 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 5 A-B-E-C-F
4 A,B,E,C,D 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 5 A-B-E-C-F
5 A,B,E,D,C,F 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 5 A-B-E-C-F
Table 2.1: Dijkstra's algorithm with source node A of network I
2.2.2. Bellman-Ford algorithm

Bellman-Ford is, in its basic structure, very similar to Dijkstra's algorithm. The
Bellman-Ford algorithm can be stated as follows: Find the shortest paths from a given
source node subject to the constraint that the paths contain, at most, one link, then find
the shortest paths with a constraint of paths of , at most , two links , and so on [43].
table 2.2 has shown the least cost of the network for bellman algorithm as shown by
the result of applying this algorithm to figure 2.2. The source node A at each step, the
least-cost paths with a maximum number of links equal to h are found. After the final
iteration, the least-cost path to each node and the cost of that path have been
developed.
h Lh[B] path Lh[C] path Lh[D] path Lh[E] path Lh[F] path
0 ∞ --- ∞ --- ∞ --- ∞ --- ∞ ---
1 1 A-B ∞ --- 4 A-D ∞ --- ∞ ---
2 1 A-B 4 A-B-C 4 A-D 2 A-B-E ∞ ---
3 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 6 A-B -C-F
4 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 5 A-B-E-C-F
5 1 A-B 3 A-B-E-C 3 A-B-E-D 2 A-B-E 5 A-B-E-C-F
Table 2.2: Bellman algorithm with source node A of network I
Another good way to practice the algorithm is to use the Web site [49]. With the Web
site, one can construct any graph used in this activity by creating vertices and
undirected. Bellman algorithm is implemented by programming language C++ tested
program code c++ for three networks; each link is labeled with its cost in both
directions (see Appendix A).
2.3. Routing Algorithm in Wired Networks

To understand routing principles in a MANET, it is a good idea to take a look at
conventional routing algorithms such as distance vector and link state. This is because
many of the routing protocols for a MANET have roots in traditional routing concept
as underlying algorithm.
27
2.3.1. Distance vector

Distance vector (DV) protocol [40, 41, 42, and 46] technique is based on that every
node maintains a forwarding table with the best route to every node in a network as
shown in figure 2.3. In a certain time interval the information is sent to every
neighboring node in the network. These nodes then conduct a comparison between their
own routing table and the received one. If the distance between any node in the
received table is smaller compared to the one at hand, the node updates the routing table
with the new value. If the value that is in the forwarding table is from the node that now
is sending a new value, the node updates the forwarding table even if the value is bigger
than the existing one. This procedure is continuous so that each and every node has an
updated forwarding table with the shortest path to all nodes in the network as shown in
figure 2.4 where node B broadcasts the new routing information to neighbors. Also is
the same update as shown in figure 2.5 which shows broadcasts to update tables of C,
B, A with new entry of node D .To estimate the best path to a destination, a node uses
the distributed Bellman Ford algorithm [43] (we implement code c++ Bellman Ford
algorithm see Appendix A) based on the contents of the neighbor table.
Figure 2.3: Every node maintains a routing table
Figure 2.4: Node B broadcasts the new routing information to neighbors
28
Figure 2.5: Broadcasts to update tables of C, B, A with new entry of node D
2.3.2. Link state Routing

Link state protocols [43, 44, 45] also known as open Shortest Path First (OSPF)[43,
45] requires global topology knowledge (i.e. they must learn the presence of every
other participating router). The global topology knowledge is accomplished through
flooding (i.e. sending to every other router). Each router maintains a graph structure
of the network topology with a cost for each link. Obtaining a route to a destination
can then be accomplished by running a shortest-path algorithm such as the well
known Dijkstra [43], we implement code c++ Dijkstra algorithm (see Appendix B).
For example as shown in figure 2.6, once the information needed for the exchange
has been collected, the next step is for each router to build a packet containing all the
data. The packet starts with the identity of the sender, followed by (a sequence
number and age and a list of neighbors).
Figure 2.6: Subnet and corresponding link state packets all six routers [44]
29
2.3.3. Flooding
With this technique [43] every packet is sent to every node in the network and is
broadcasted by the receiving nodes exactly once [38]. Each node receiving the packet
broadcasts it to every neighboring node (in the wireless case, this means all nodes that
are within transmitter range), except the one it received it from. These neighboring
nodes in term do the same and so on as shown in figure 2.7. To avoid retransmitting
the same packet twice, every packet is tagged with a source address and a sequence
number which serve as a unique identifier. With these identifiers each node keeps
track of which packets they have transmitted. This approach has a very high
consumption of network resources since every packet is sent to every possible node to
ensure that the packet arrives to its destination. On the other hand, it results in an
extremely high delivery ratio.
Figure 2.7: Flooding example (hop count = 3)
30
2.4. Routing Algorithm in a Mobile Ad-hoc Networks
2.4.1. Introduction
Within a mobile ad-hoc network, a node's radio transmission range typically cannot
cover the whole network. In order to enable a node to communicate with other nodes
out of its radio coverage, a route generally contains several intermediate nodes, and
this is why ad-hoc networks are also referred to as multi-hop networks. For data
communication in a network, a node must depend on routing protocols to discover
routes to the specific destinations. A mobile device is generally limited by its
available resources, such as computation capability and memory capacity. Moreover,
these devices are likely to be battery powered, so energy constraint is another
important issue that must be considered. Because of these resource limitations, routing
protocols designed for mobile ad-hoc networks must take special requirements into
account. Therefore, the existing routing protocols designed for wired networks are not
suitable for mobile ad-hoc networks, and new routing protocols have been designed
recently. So, it has become clear that routing in a MANET is fundamentally different
from traditional routing found on infrastructured networks [46]. Routing in a MANET
depends on many factors including topology, selection of routers and initiation of
request and specific underlying characteristic that could serve as a heuristic in finding
the path quickly and efficiently. The low resource availability in these networks
demands efficient utilization and hence the motivation for optimal routing in ad-hoc
networks. Also, the highly dynamic nature of these networks imposes severe
restrictions on routing protocols specifically designed for them.
2.4.2. Classification of Routing Protocols in MANETs

Classification of routing protocols in MANETs can be done in many ways, but most
of these are done depending on routing strategy and network structure [12, 47].
According to the routing strategy, the routing protocols can be categorized as table-
driven and source initiated, while depending on the network structure these are
classified as flat routing, hierarchical routing and geographic position assisted routing
[47]. There is a number of routing protocols have been developed for mobile ad-Hoc
networks as shown in Figure 2.8 [12, 47]. That Destination Sequenced Distance
Vector (DSDV) [8, 9, and 46] belongs to the table-driven protocols. The most popular
protocols nowadays are the Ad-Hoc on Demand Distance Vector Routing (AODV) [6,
7, and 46] and Dynamic Source Routing (DSR) [36, 38, and 46] protocols. Both of
them belong to the source-initiated on-demand protocols. We will briefly describe
DSR, AODV and DSDV protocols in the following, thus motivating the study,
analysis and compared three protocols (DSR, AODV and DSDV) and performance
analysis, which aim at achieving routing stability.
2.4.3. Problems with Routing in Mobile Ad-hoc Networks

Asymmetric links: Most of the wired networks rely on the symmetric links which are
always fixed. But this is not a case with ad-hoc networks as the nodes are mobile and
constantly changing their position within network. For example, consider a MANET
(Mobile Ad-hoc Network) where node B sends a signal to node A, but this does not
tell anything about the quality of the connection in the reverse direction [25].
Routing Overhead: In wireless ad-hoc networks, nodes often change their location
within network. So, some stale routes are generated in the routing table which leads to
unnecessary routing overhead.
31
Interference: This is the major problem with mobile ad-hoc networks as links come
and go depending on the transmission characteristics, one transmission might interfere
with another one and node might overhear transmissions of other nodes and can
corrupt the total transmission.
Dynamic Topology: This is also the major problem with ad-hoc routing since the
topology is not constant. The mobile node might move or medium characteristics
might change. In ad-hoc networks, routing tables must somehow reflect these changes
in topology and routing algorithms have to be adapted. For example, in a fixed
network routing table updating takes place for every 30 sec [25]. This updating
frequency might be very low for ad-hoc networks.
Figure 2.8: Classification of ad-hoc routing protocols.
2.4.4. Proactive and Reactive Routing Protocols

Ad-hoc routing protocols can be broadly classified as being Proactive (or table-
driven) or Reactive (on-demand). In a proactive routing protocol, all the routes to each
destination are kept in an up to date table. Changes in the network topology are
continually updated as they occur. In the reactive routing protocol, a connection
between two nodes is only created when it is asked for by a source. When a route is
found, it is kept by a route maintenance procedure until the destination no longer
exists or is needed. The following table 2.33 presents a comparison between proactive
and reactive routing protocols.
32
Protocol
Reactive Proactive
Points
 Lower bandwidth is used for
maintaining routing tables.
A route can be selected
Advantages  More energy-efficient.
immediately without delay.
 Effective route maintenance.
Produces more control traffic.

Have higher latencies when it Takes a lot of bandwidth.
Disadvantages
comes to route discovery. Produces network congestion.
Table 2.3: Proactive versus Reactive Protocols
2.4.4.1. Table Driven (DSDV) Routing Protocols

In Table-driven routing protocols, each node maintains one or more tables containing
routing information to every other node in the network. All nodes update these tables
so as to maintain a consistent and up-to-date view of the network. When the network
topology changes the nodes propagate update messages throughout the network in
order to maintain consistent and up-to-date routing information about the whole
network. These routing protocols differ in the method by which the topology changed
information is distributed across the network and the number of necessary routing-
related tables. The following discusses existing table-driven ad-hoc routing protocols.
DSDV Routing Protocol

The Destination Sequenced Distance Vector Routing protocol (DSDV) described
in [8] is a table-driven algorithm based on the classical Bellman-Ford routing
mechanism [3]. The improvements made to the Bellman-Ford algorithm include
freedom from loops in routing tables. Every mobile node in the network maintains a
routing table in which all of the possible destinations within the network range and the
number of hops to each destination is recorded as shown in figure 2.9. The entire table
contains the Sequence number originated from destination. Ensures loop freeness,
install time when entry was made (used to delete stale entries from table), Stable Data
Pointer to a table holding information on how stable a route is used to damp
fluctuations in network and Metric the number of hops to each destination as Table
2.4. Each entry is marked with a sequence number assigned by the destination node.
The sequence numbers enable the mobile nodes to distinguish stale routes from new
ones, thereby avoiding the formation of routing loops. Routing table updates are
periodically transmitted throughout the network in order to maintain table consistency
as shown in figure 2.9. To help alleviate the potentially large amount of network
traffic that such updates can generate, route updates can employ two possible types of
packets. The first is known as a full dump. This type of packet carries all available
routing information and can require multiple network protocol data units (NPDUs).
During periods of occasional movement, these packets are transmitted infrequently.
Smaller incremental packets are used to relay only that information which has
changed since the last full dump. Each of these broadcasts should fit into a standard-
size NPDU, thereby decreasing the amount of traffic generated. The mobile nodes
maintain an additional table where they store the data sent in the incremental routing
information packets. New route broadcasts contain the address of the destination, the
number of hops to reach the destination, the sequence number of the information
33
received regarding the destination, as well as a new sequence number unique to the
broadcast [8].
Figure 2.9: Every mobile node in the network maintains a routing table
Destination Next hop Metric Seq. # Install Time Stable Data
A A 0 A-550 001000 Ptr_A
B B 1 B-102 001200 Ptr_B
C B 3 C-588 001200 Ptr_C
D B 4 D-312 001200 Ptr_D

Table 2.4: Table Entries
The route labeled with the most recent sequence number is always used. In the
event that two updates have the same sequence number, the route with the smaller
metric is used in order to optimize (shorten) the path. Mobiles also keep track of the
settling time of routes, or the weighted average time that routes to a destination will
fluctuate before the route with the best metric is received. By delaying the broadcast
of a routing update by the length of the settling time, mobiles can reduce network
traffic and optimize routes by eliminating those broadcasts that would occur if a better
route was discovered. The basic mechanisms each DSDV node maintains a routing
table listing the “next hop” for each reachable destination. DSDV tags each route with
a sequence number and considers a route R more favorable than R if R has a greater
sequence number, or if the two routes have equal sequence numbers but R has a lower
metric. Each node in the network advertises a monotonically increasing even
sequence number for itself as shown in figure 2.10 where node B advertises increases
Seq.# from 100 to 102 node B broadcasts routing information to neighbors node A,
C including destination sequence numbers with comparing to table inters in figure
2.9.
34
Figure 2.10: Route Advertisement
When a node B decides that its route to a destination node C has broken, it
advertises the route to node C with an infinite metric and a sequence number one
greater than its sequence number for the route that has broken (making an odd
sequence number) as shown in figure 2.11.
Figure 2.11: Broken Link
This causes any node A routing packets through B to incorporate the infinite-metric
route into its routing table until node A hears a route to node C with a higher sequence
number. When respond to topology changes the immediate node advertisements
information on new routes, broken links, and metric change is immediately
propagated to neighbor's node to full update or incremental update where full update
sends all routing information from its own table and incremental update send only
entries that have changed (make it fit into one single packet). For example, new node
35
D adds to the dynamic network topology then the node D broadcast the for first time
and sends sequence number D-000 to neighbor node C, where node C insert entry for
D with sequence number D-000, then immediately broadcasts its own table to node B
, etc. As shown in figure 2.12. When node D contact the node C increases its
sequence number to C-592 then broadcasts its new table, where node B gets this new
information and updates its table and etc. As shown in figure 2.13.
Figure 2.12: New node add to topology
Figure 2.13: New node contact
Advantages:
Simple (almost like Distance Vector), loop free through destination seq. numbers and
no latency caused by route discovery.
Disadvantages:
No sleeping nodes, bi-directional links required, overhead most routing information
never used, scalability is a major problem.
36
2.4.5.2. On-Demand Routing Protocols

These protocols take a lazy approach to routing. In contrast to table-driven routing
protocols, all up-to-date routes are not maintained at every node, instead the routes are
created as and when required. When a source wants to send to a destination, it invokes
the route discovery mechanisms to find the path to the destination. The route remains
valid till the destination is reachable or until the route is no longer needed. The
following part discusses AODV and DSR on-demand routing protocols.
2.4.5.2.1. DSR Routing Protocol

The Dynamic Source Routing (DSR), is an on-demand routing protocol that is based
on the concept of source routing mobile nodes that are to perform a Route Discovery.
The source node S broadcasts a ROUTE REQUEST packet with the Time-to-Live
field of the IP header initialized to 1[10],[11]. This type of ROUTE REQUEST is
called a non-propagating ROUTE REQUEST and allows node S to inexpensively
query the route caches of each of its neighbors for a route to the destination as shown
by the stapes of building route discovery in figure 2.14.
Figure 2.14: Building of the route record during route discovery
37
When destination node D receives ROUTE REQUEST, then the destination node D
sends ROUTE REPLY (RREP) to the source node S as shown in figure 2.15. Where
Route replies by reversing the route (as illustrated), it works only if all the links along
the route are bidirectional. Then, the source node S delivers data to the destination
node D as shown in figure 2.16 in the same row of route reply.
Figure 2.15: Propagation of the route reply with route record
Figure 2.16: Data delivery
If no REPLY is returned, node S transmits a propagating ROUTE REQUEST that is

flooded through the network in a controlled manner and is answered by a ROUTE
REPLY packet from either the destination node or another node that knows a route to
the destination. To reduce the cost of Route Discovery, each node maintains a cache
of source routes it has learned or overheard, which it aggressively uses to limit the
frequency and propagation of ROUTE REQUESTs.
38
Route Maintenance is the mechanism by which a packet’s sender S detects if the

network topology has changed so that it can no longer use its route to the destination
D because two nodes listed in the route have moved out of range of each other. When
Route Maintenance indicates that a source route is broken, where node J moves (out
of range of node G) as shown in figure 2.17, the node G send Route Error message
(RERR) as shown in figure 2.18 to the source node S. When receiving the Route Error
message, the source node S removes the broken link from its cache. It then tries to
another route stored in its cache; if none, it initializes a new route discovery to find a
new route.
Figure 2.17: Route maintenance indicates that a source route is broken
Figure 2.18: Node S is notified with a ROUTE ERROR packet

Optimization of route discovery needed to route caching the principle of each node
caches a new route it learns by any means, for example, when node S finds route (S,
E, G, J, D) to D, it also learns route (S, E, G) to node G , in the same way, node E
learns the route to D. Same phenomenon when transmitting route replies.
39
2.4.5.2.2. AODV Routing Protocol

The Ad-Hoc On-Demand Distance Vector (AODV) routing protocol described in [6]
builds on the DSDV algorithm previously described. AODV is an improvement on
DSDV because it typically minimizes the number of required broadcasts by creating
routes on a demand basis, as opposed to maintaining a complete list of routes as in the
DSDV algorithm. The authors of AODV classify it as a pure on-demand route
acquisition system, since nodes that are not on a selected path do not maintain routing
information or participate in routing table exchanges [6]. When a source node desires
to send a message to some destination node and does not already have a valid route to
that destination, it initiates a path discovery process to locate the other node. It
broadcasts a route request (RREQ) packet to its neighbors, which then forward the
request to their neighbors, and so on, until either the destination or an intermediate
node with a “fresh enough” route to the destination is located [9].
Figure 2.19(a) shows how the route to the destination is found by AODV routing
protocol. The step by step explanation as shown in figure 2.20 is as follows:
1. Source node S has to send data to destination.
2. Node S sends RREQ to its neighbors A, B, C, Q.
3. Node B finds the path in its routing table (with destination seq-number s1 and
hop count c1) and sends RREP to S.
4. Node C sets up reverse path.
5. Node C propagation RREQ to its neighbor's nodes A, B, E, F, N,R.
6. Node F sets up reverse path.
7. Node F propagation RREQ to its neighbors nodes E,G, I, and N.
8. Node F supposes deletes the reverse path after a time out period as it does not
receive any RREPs from E,G, I, and N .
9. Node N sets up reverse path.
10. Node N propagation RREQ to its neighbors nodes R,F,I,H and J.
11. Node J sets up reverse path.
12. Node J propagation RREQ to its neighbors nodes H,I,K,L,M,D.
13. Node D finds the path (with destination seq-number s2 which is greater than s1
and hop count c1) in its routing table and sends RREP to C.
14. Node C receives RREP from node N and sets up forward path and forwards
RREP to source node S.
15. A sets reverse path; forwards RREQ to its neighbors; receives RREP sets
forward path; and forwards this RREP to source node S.
16. Source node S receives a path information from node C (with destination seq-
number s2 and hop count c2), another path information from node B (with
destination seq-number s1 and hop count c1), and another path information
from node A (with destination seq-number x which is less than s1 and s2 and
hop count c2 which is less than c1).
17. Source node S chooses path information from node C (which was originated
from node D), giving first priority to the path with greatest destination
sequence number and then second priority to the path with smallest hop
count. Though path given by node A is of smallest hop count, it is ignored
because the destination sequence number is greater than the path from node C.
Figure 2.19(a) and (b) illustrate the propagation of the broadcast RREQs across the
network. Each node in the network maintains a routing table with the routing
information entries to its neighboring nodes, and two separate counters: (a node
sequence number and a broadcast-id). When a node (say, source node S ) has to
communicate with another (say, destination node D), it increments its broadcast-id
40
and initiates path discovery by broadcasting a route request packet RREQ to its
neighbors. The RREQ contains the following fields:
 source-addr
 source-sequence# :to maintain freshness information about the route to the
source.
 dest-addr: of destination node
 dest-sequence# - specifies how fresh a route to the destination node must be
before it is accepted by the source.
 hop-counter
Where the (source-addr and broadcast-id) pair is used to identify the RREQ uniquely.
Then the dynamic route table entry establishment begins at all the nodes in the
network that are on the path from S to D.
Figure 2.19: Propagation of the RREQ
41
Figure 2.20: Steps of propagation RREQ and reverse path of RREP
Intermediate nodes can reply to the RREQ only if they have a route to the destination
whose corresponding destination sequence number is greater than or equal to that
contained in the RREQ. During the process of forwarding the RREQ, intermediate
42
nodes record in their route tables the address of the neighbor from which the first copy
of the broadcast packet is received, thereby establishing a reverse path. If additional
copies of the same RREQ are later received, these packets are discarded. Once the
RREQ reaches the destination or an intermediate node with a fresh enough route, the
destination/intermediate node responds by uncasting a route reply (RREP) packet
back to the neighbor from which it first received the RREQ as shown in figure 2.21.
As the RREP is routed back along the reverse path, nodes along this path set up
forward route entries in their route tables which point to the node from which the
RREP came as shown in figure 2.21. These forward route entries indicate the active
forward route. Associated with each route entry is a route timer which will cause the
deletion of the entry if it is not used within the specified lifetime. Because the RREP
is forwarded along the path established by the RREQ, the source node S delivers data
to the destination node D as shown in figure 2.22, the same row of forward path,
AODV, only supports the use of symmetric links.
Figure 2.21: Path of the RREP and forward path to the source
Figure 2.22: Data delivery to the destination node D
43
Routes maintenance work when indicates a link failure as shown in figure 2.23, where
a source node moves, it is able to reinitiate the route discovery protocol to find a new
route to the destination. Or if a node along the route moves, its upstream neighbor
notices the move and propagates a link failure notification message (an RREP with
infinite metric) to each of its active upstream neighbors to inform them of the erasure
of that part of the route.
These nodes in turn propagate the link failure notification to their upstream neighbors,
and so on until the source node is reached by route reply RREP with infinite metric
(∞) and increment dest-sequence# one as shown in figure 2.24.
The source node may then choose to reinitiate route discovery for that destination if a
route is still desired
Figure 2.23: Route maintenance indicates a link failure
Figure 2.24: Node is turn propagate the link failure notification

.
44
2.5. Security
Ad-hoc networks are a new paradigm of wireless communication for mobile hosts.
No fixed infrastructure such as base stations is mobile switching .Nodes within each
other radio range communicate directly via wireless links while these which are far
apart rely on other nodes to relay messages. Node mobility causes frequent changes in
topology. Figure 2.25 shows such an example: nodes A, B, C, D, E, and F constitute
an ad-hoc network. The circle represents the radio range of node A. Initially nodes A
and D have a direct link between them. When D moves out of A’s radio range, the
link is broken. However, the network is still connected, because A can reach D
through C, E, and F.
Figure2.25. Topology change in ad-hoc networks of nodes D [57]
Security is a fundamental issue that needs resolution before ad-hoc networks will
experience large scale deployment [57]. The characteristics of mobile ad-hoc
networks, as given in Chapter 2 Section 2.4.2, pose numerous challenges to achieving
conventional security goals. Since the nodes are responsible for basic network
functions, like packet forwarding and routing, network operations can be easily
jeopardized if countermeasures are not integrated into these network functions at the
early stages of design. For example, some existing routing protocols given in Chapter
2 for mobile ad-hoc networks may be able to manage the dynamic network topology
of mobile ad-hoc networks, but none of these protocols incorporate mechanisms to
prevent, tolerate or defend against attacks from malicious adversaries. Due to the
close relationship between security and the characteristics of ad-hoc networks these
protocols will have to be fundamentally altered or re-designed to effectively
incorporate security mechanisms. This is clear if one considers the number of secure
routing protocols (Ariadne [58], SEAD [55], ARAN [59], and SRP [60]) that followed
the insecure routing protocols.
Security support is of grave importance to military communications, for military
tactical operations are still the main application of ad-hoc networks today that we
need for secure routing protocol. For example, military units (e.g., soldiers, tanks, or
planes), equipped with wireless communication devices, could form an ad-hoc
network when they roam in a battlefield. Ad-hoc networks can also be used for
emergency, law enforcement, and rescue missions. Since an ad-hoc network can be
deployed rapidly with relatively low cost, it becomes an attractive option for
commercial uses such as sensor networks or virtual classrooms.
45
2.5.1. Security Goals

The security objectives for ad-hoc networks are similar to those of conventional
networks. Ad-hoc network security should consider the following fundamental
attributes adapted from [57, 62, 69 and 73]:
Availability: Ensures survivability despite Denial of Service DOS attacks. On
physical and media access control layer attacker can use jamming techniques to
interfere with communication on physical channel. On network layer the attacker can
disrupt the routing protocol.
Confidentiality: Ensures certain information is never disclosed to unauthorized
entities. It provides the ability for a message to be exchanged without eavesdropping.
Data integrity: Message being transmitted is never corrupted. It provides the ability
for receiver of a message to verify that the message has not been modified in transit.
An intruder should not be able to substitute a false message for a legitimate one.
Authentication: Enables a node to ensure the identity of the peer node it is
communicating with. Without which an attacker would impersonate a node, thus
gaining unauthorized access to resource and sensitive information and interfering with
operation of other nodes. So it provides the ability for the receiver of a message to
ascertain the origin of the message. An intruder should not be able to masquerade as
someone else.
Non-repudiation: Ensures that the origin of a message cannot deny having sent the
message. it provides the ability to ensure that a sender cannot falsely deny later that he
sent a message. A sender should not be able to falsely deny later that he sent a
message.
2.5.2. Attacks in Networks

Network security provides general types of security attacks to help organizations and
users understand some of the attacks against a wireless local area networks (WLANs)
as shown in figure 2.26 adapted from [63, 65]
Figure 2.26: The release of message contents
46
2.5.2.1. Passive attacks

The release of message contents is easily understood as a telephone conversation, an
electronic mail message, and a transferred file may contain sensitive or confidential
information. It is imperative to prevent an opponent from learning the contents of
these transmissions.
A second type of passive attack, traffic analysis, is subtler. Suppose that there is a
way of masking the contents of messages or other information traffic so that
opponents, even if they captured the message, could not extract the information from
the message. The common technique for masking contents is encryption. If there is
encryption protection in place, an opponent might still be able to observe the pattern
of these messages. The opponent could determine the location and identity of
communicating hosts and could observe the frequency and length of messages being
exchanged. This information might be useful in guessing the nature of the
communication that is taking place.
Passive attacks are very difficult to detect because they do not involve any alteration
of the data. Typically, the message traffic is sent and received in an apparently normal
fashion and neither, the sender nor receiver is awherethat a third party has read the
messages or observed the traffic pattern. However, it is feasible to prevent the success
of these attacks, usually by means of encryption. Thus, the emphasis in dealing with
passive attacks is on prevention rather than detection.
2.5.2.2. Active attacks

Active attacks involve some modification of the data stream or the creation of a false
stream and can be subdivided into four categories:
1. Masquerade
2. Replay
3. Modification of messages
4. Denial of service.
Masquerade: Masquerade takes place when one entity pretends to be a different

entity. A masquerade attack usually includes one of the other forms of active attack.
For example, authentication sequences can be captured and replayed after a valid
authentication sequence has taken place, thus enabling an authorized entity with few
privileges to obtain extra privileges by impersonating an entity that has those
privileges.
Replay: Replay involves the passive capture of a data unit and its subsequent
retransmission to produce an unauthorized effect.
Modification of messages: Modification of massages simply means that some
portion of a legitimate message is altered, or that messages are delayed or reordered,
to produce an unauthorized effect. For example, a message meaning "Allow John
Smith to read confidential file accounts" is modified to mean "Allow Fred Brown to
read confidential file accounts."
Denial of service: The DoS prevents or inhibits the normal use or management of
communications facilities. This attack may have a specific target, for example, an
entity may suppress all messages directed to a particular destination (e.g., the security
audit service). Another form of service denial is the disruption of an entire network,
either by disabling the network or by overloading it with messages so as to degrade
performance.
47
Note that the active attacks present the opposite characteristics of passive attacks.
Whereas passive attacks are difficult to detect, measures are available to prevent their
success. On the other hand, it is quite difficult to prevent active attacks absolutely,
because of the wide variety of potential physical, software, and network
vulnerabilities. Instead, the goal is to detect active attacks and to recover from any
disruption or delays caused by them. If the detection has a deterrent effect, it may also
contribute to prevention.
2.5.3. Adversary Model

Threats to ad-hoc networks or attacks on ad-hoc networks can be launched by
malicious nodes as an outsider or insider with respect to the network. A clear
distinction should be made between outsider and insider adversaries, since each may
use different tactics to circumvent security mechanisms and should be dealt with
accordingly. Any security protocol can only guarantee defence against an adversary
that has been captured by its adversary model (adapted from [69]).
 Outsider Adversaries: Insider adversaries are the most common adversaries; nodes
that do not belong to the network with the intent of harming the network operation.
Since an outsider does not have access to important network information, the attacks
are normally based on the exploitation of the characteristics of the network or
weaknesses in the underlying protocols.
 Insider Adversaries: Insider adversaries are significantly more difficult to defend
against than outsider adversaries. These are malicious authorized nodes performing
unauthorized actions. With a strong non-repudiation service, an advantage of
defending against insider adversaries in contrast to outsider adversaries is that the
insider (malicious user) is more easily identified if detected and held accountable for
malicious or unauthorized actions. On the other hand, an insider has access to
additional information (for example keying material, routing information) and is
possibly trusted by other network nodes, making it easier for the node to breach
confidentiality, corrupt fundamental network function and manipulate the content of
messages without detection. In “open” or fully self-organized MANET all malicious
nodes can be regarded as insider adversaries.
2.5.4. Attack Patterns of Sensor Mobile Ad-Hoc Networks

The unique characteristics of MANET give an adversary the opportunity to launch
numerous attacks against ad-hoc networks. When designing protocols for MANET it
is important to be are of existing attacks. In open or fully self-organized MANET, an
adversary may take on as many identities as needed, the number being limited only by
its available resources. It is anticipated that future research will identify new attacks
on open MANET or at least nullify defence mechanisms against existing attacks. For
example, holding nodes accountable for their actions is temporary in open MANET. If
the node is excluded due to misbehavior the attacker can rejoin the network with a
new identity.
 Eavesdropping/Traffic analysis: Eavesdropping is the most common attack where
a passive adversary listens in on the communication called passive link intrusion
capability. An adversarial node at this level is an external adversary that poses threat
to wireless link. Only the adversary knows and actualizes all network protocols and
functions. It can eavesdrop and record wireless packets [68]. This attack can be
successfully implemented in most networks, however in wireless networks it
becomes easier as the adversary does not have to physically connect to the medium,
48
but can monitor the traffic between communication entities from a safe distance
[68]. Since the adversary in general (and particularly in the case of commercial
networks) can obtain the necessary communication equipment to demodulate the
signal, encryption remains the most effective solution to defend against
eavesdropping.
 Denial of Service: In denial of service (DoS) the attack results when the network
bandwidth is hijacked by a malicious node. It has many forms: the classic way is to
flood any centralized resource so that the network no longer operates correctly or
crashes. For instance, a route request is generated whenever a node has to send data
to a particular destination. A malicious node might generate frequent unnecessary
route requests to make the network resources unavailable to other nodes [72]. Also,
in denial of service attacks, the adversary prevents the normal use or management of
network facilities or functionality. DoS attacks can be launched at any layer of an
ad-hoc network to exhaust node resources [57]. On the physical and medium access
control layers a DoS attack, for example jamming, can be employed to impair
network availability. Jamming occurs when a malicious node deliberately emanates
a signal from a wireless device in order to overwhelm legitimate wireless signals
[65, 67]. On the network layer, an adversary could disrupt the routing fabric by
manipulating routing control packets. On higher layers, an adversary could attack
essential services, such as the key management protocol. DoS can also be caused by
the constant request of network services by an adversary even if these services are
denied. For example, hello flooding can be seen as a type of DoS attack. An attacker
can use traffic diversion to cause large amounts of data to be sent to a victim node
from some set of nodes controlled by the attacker called a Stealth Attacks [66].
 Impersonation: A malicious node may impersonate another node while sending the
control packets to create an anomaly update in the routing table [72]. Without strong
authentication mechanisms in place, insider or outside adversaries can masquerade
as an authorized user and attempt to access network services [73]. This problem
becomes even more difficult to solve in open fully self-organized MANETs which
do not have any form of access control.
 Cryptanalytic Attacks: Cryptanalysis is the study of mathematical techniques and
procedures used to break cryptographic techniques, procedures and algorithms, i.e.
defeating the objective of the intended service [69] called breaking an information
security service. Adversaries exploit cryptanalytic techniques to discover
cryptographic keys or derive confidential information from the recorded encrypted
data sent between communication entities. These types of attacks are however
seldomly used due to cryptanalytic complexity and/or vast computational and
memory requirements. The probability of a security hole existing elsewhere is
generally much higher depending on what cryptographic algorithms are used. A
careful analysis is still essential when selecting cryptographic algorithms to avoid a
cryptanalytic attack. Factors to consider when choosing a cryptographic scheme are:
Is the algorithm widely used? How important is the information it is protecting?
And does it have a good history of cryptanalysis? Successful cryptanalysis can also
be made more difficult by limiting the amount of information available for
cryptanalysis.
 Wormhole Attacks: The wormhole attack is a severe attack against the routing
protocols of ad-hoc networks made possible by the shared wireless medium. In a
wormhole attack, an adversary records packets (routing information) at one location
in the network, tunnels the recorded data via a private network or connection to
another location in the network, and re-transmits the recorded data into the network
49
[70, 71]. This disrupts the routing infrastructure and consequently prevents a routing
protocol, without a protection mechanism, from finding routes more than one or two
hops from the node requesting routing services.
 Sink hole and Black hole Attacks: During a black hole attack, a malicious node
uses the routing protocol to advertise itself as having the shortest path to the node
whose packets it wants to intercept. We provide a detailed description herein [63,
72]. The black hole attack: The attacker forms part of the network and interferes in
the route discovery phase of the routing protocol [58]. By sending forged routing
packets the attacker routes all packets for another destination to itself. The attacker
then disrupts the routing protocol by creating a routing black hole or sink hole in
which all packets are dropped. The attacker could also selectively drop packets by
creating a gray hole, for example, by forwarding all routing packets but no data
packets [58].
 Routing table overflow Attacks: The attacker attempts to create routes to
nonexistent nodes. The goal is to have enough routes so that creation of new routes
is prevented or the implementation of routing protocol is overwhelmed [63].
 Replay Attacks: In a replay attack on the routing infrastructure an adversary sends
old route advertisements to a node causing it to update its routing table with stale
routes [75]. The attacker may also record packets sent between legitimate network
nodes on the application layer and replay these recorded packets in order to gain
unauthorized access to network services or overload a node with outdated
information resulting in denial of service.
 Energy consummation: Energy is a critical parameter in the MANET. Battery-
powered devices try to conserve energy by transmitting only when absolutely
necessary. An attacker can attempt to consume batteries by requesting routes or
forwarding unnecessary packets to a node [72].
2.5.5. Secure Routing Protocol in Mobile Ad-hoc Networks

The contemporary routing protocols for ad-hoc networks cope well with
dynamically changing topology but are not designed to accommodate defense against
malicious attackers. No single standard protocol can capture common security threats
and provide guidelines to secure routing protocol. Routers exchange network topology
informally in order to establish routes between nodes, another potential target for
malicious attackers who intend to bring down the network. External attackers
injecting erroneous routing information, replaying old routing information or
distorting routing information in order to partition a network or overload a network
with retransmissions and inefficient routing. Internal compromised nodes - more
severe detection and correction more difficult routing information signed by each
node won't work since compromised nodes can generate valid signatures using their
private keys. Detection of compromised nodes through routing information is also
difficult due to dynamic topology of ad-hoc networks. Can make use of some
properties of ad-hoc networks to facilitate secure routing, routing protocols for Ad-
hoc networks must handle outdated routing information to accommodate dynamic
changing topology. False routing information generated by compromised nodes can
also be regarded as outdated routing information. As long as there are sufficient no. of
valid nodes, the routing protocol should be able to bypass the compromised nodes,
this however needs the existence of multiple, possibly disjoint routes between nodes.
Routing protocol should be able to make use of an alternate route if the existing one
appears to have been faulted. There are several secure routing protocols proposed
basing on the working principles of the ad-hoc protocols as follows:
50
 SEAD (Secure Efficient Ad-hoc Distance Vector Routing) [55].

 Ariadne (Authenticated Routing for Ad-hoc Networks) [58].
 ARAN (Authenticated routing for Ad hoc Network) [59].
 SAODV (Secure Ad-hoc On-Demand Distance Vector Routing).
 SRP (Secure Routing Protocol [60].
 SAR (Security-AwhereRouting Protocol) [77].
 LHAP (Lightweight Hop-by-hop Authentication Protocol).
 SLSP (Secure Link State Protocol).
 SMT (Secure Message Transmission).
 SPAAR (Secure Position Aided Ad hoc Routing).
 TESLA (Time Efficient Stream Loss-tolerant Authentication).
As a result, in the following table 2.5, a comparison between some of the most
established secure routing protocols with respect to some performance and security
parameters is given so as to facilitate the choice of one of them to work on[78]:
Performance
ARAN ARIADNE SAODV SAR SEAD SLSP SRP
Parameters
Type Reactive Reactive Reactive Reactive Proactive Proactive Reactive

MANET AODV/
DSR AODV AODV DSDV ZHLS DSR/ZRP
Protocol DSR
Authentication Yes Yes Yes Yes Yes Yes Yes
Confidentiality Yes No No No No No No
Integrity Yes Yes Yes Yes No No Yes
Non-repudiation Yes No Yes Yes No Yes No
Dos Attacks No Yes No No Yes Yes Yes

Table2.5: Secure Ad Hoc Routing Protocols Comparison [78]
As a result of this comparison, the researcher has ended up choosing to work with
(SEAD): Secure efficient ad-hoc distance vector routing protocol, as the selected
secure routing protocol. It will be shown how this SEAD protocol was built based
upon the early above mentioned security requirements and will be secure routing
algorithm protocol (SEAD) implemented in simulator Ns-2, simulation, performance
analysis and using secure routing algorithm protocol (SEAD) compared with
traditional routing algorithm protocol (DSDV). See Chapter 4 section 4.1, where the
operation and implementation of SEAD are described.
2.6. Summary
In this chapter there was a discussion of existing routing protocols so as to understand
routing principles in a MANET. It is a good idea to take a look at a brief overview of
examined least-cost algorithms that are a central part of routing in packets in networks
51
and conventional routing algorithms such as distance vector, link state and flooding
routing. This is because many of the routing protocols for a MANET have roots in
traditional routing concept as underlying algorithm. In mobile ad-hoc networks
routing protocols are classified as routing protocols in MANET can be done in many
ways, but most of these are done depending on routing strategy and network structure,
as flat routing, hierarchical routing, geographic position assisted routing and security
routing and their existing proactive, reactive advantages and disadvantages were
presented. Then, three routing algorithm protocols (DSDV, DSR and AODV) were
chosen and their operation described. Ad-hoc network security should consider the
following fundamental attributes requirements for designing a secure routing protocol
to defend against security breaches were mentioned, some adversary models and the
different types of attacks targeting MANET routing protocols were explored. Then
comparison between some of the existing secure mobile ad-hoc routing protocols was
given. One of the secure routing protocols was built following the fundamental secure
routing protocol design methodology, the secure efficient ad-hoc distance vector
routing protocol (SEAD).
52
Chapter 3
Comparison and Performance Analysis

of Ad-hoc Routing Protocols & Results
53
Chapter 3
Comparison and Performance Analysis of Ad-hoc Routing
Protocols & Results
3.1. Introduction
Simulator Ns-2 is used because this simulation environment consists of a set of
wireless and mobile networking extensions, Also, Ns-2 simulator is used because its
network a popular and powerful simulation environment, and the number of Ns-2
users has increased greatly in recent years. Although it was originally designed for
wired networks, Ns-2 has been extended to work with wireless networks, including
wireless LANs, mobile ad-hoc networks MANET, and sensor networks and can
simulate several network protocols such as TCP, UDP, multicast routing, etc;
however, the Network Animator (NAM) for Ns-2 is used as a visualization tool [28].
Ns-2 is primarily useful for simulating local and wide area networks usage (see figure
3.1 [27]). More recently, support has been added for simulation of large satellite and
ad-hoc wireless networks.
Figure 3.1: Simulator usage [27]

Ns-2 is an open source discrete event simulator used by the research community for
research in networking [13]. The Ns-2 simulation software was developed at the
University of California at Berkeley [13] and the Virtual Inter Network Test bed
(VINT) Project was in fall 1997 [16]. The basic structure of Ns-2 is shown in figure
3.2 [48]. It is constantly under development by an active community of researchers.
The standard Ns-2 distribution runs on Linux. However, a package for running Ns-2
on cygwin (Linux Emulation for Windows) is available [30]. The latest version at the
time is ns-2.31 free download from web page [30]. The old versions are 2.29, 2.28,
2.27, 2.26, 2.1b9, 2.1b8, 2.1b7, 2.1b6, 2.1b5, 2.1b4, 2.1b3, 2.1b2, 2.1b1, 2.0 and
2.0b17. It can run both in UNIX and Windows. But to run in Windows, it requires
installing first cygwin [30, 79] to set the computer environment as UNIX environment
and second installing Ns-2. More details can be found in [14, 26, 30, 48, 79, 22 and
76]. These extensions provide a detailed model of the physical and link layer behavior
54
of a wireless network and allow arbitrary movement of nodes within the network. At
the physical layer, a realistic modeling of factors is provided such as free space and
ground reflection propagation, transmission power, antenna gain, receiver sensitivity,
propagation delay, and carrier sense. At the link layer with model there are the
complete Distributed Coordination Function (DCF), Media Access Control (MAC),
protocol of the IEEE 802.11, wireless LAN protocol standard IEEE 1997, along with
the standard Internet Address Resolution Protocol (ARP) Plummer 1982. These
wireless and mobile networking extensions are available from the Carnegie Mellon
University Monarch Project [19] and have been widely used by other researchers; a
version of them have also now been adopted as a part of the standard VINT release of
Ns-2. That has done a simulation Ns-2 study with this environment, analyzing the
behavior and performance of routing protocols and comparing it to other proposed
routing protocols for ad-hoc networks [1, 20, 21].
Figure 3.2: The basic structure of simulator Ns-2 [48]
To setup and run a simulation, a user writes an OTcl script (object-oriented Tool
command language) [17], which is a simulation program to initiate an event
scheduler, set up the network topology using the network objects and plumbing
functions in the library, and to tell traffic sources when to start and stop transmitting
packets through the event scheduler. When Ns-2 which works as OTcl interpreter
receives the OTcl script, it will set environment parameters following the received
script. If a user wants to make a new network object, it will be easy to make a
compound object from the object library, and plumb the data path through the object
rather than write a new one. When the simulation is finished, the simulation results
are produced in one or more text-based output files that contain detailed simulation
data, which can be used to analyze directly or can be used in the graphical user
interface NAM [28]. This graphical user interface shows the simulation result in an
easy way. The language that is written in Ns-2 is not only OTcl but also C++. The
event scheduler and the basic network component objects in the data path are written
and compiled using C++ to reduce packet and event processing time. These compiled
objects need the OTcl linkage to create a matching OTcl object for each of the C++
objects to be able to work with OTcl interpreter. It can run both in Unix and
Windows, (for more details see appendix E).
55
3.2. Analysis Simulation of Traces File Format

It is an important step in the present experiment to analyze the output results of
simulation. The following shows the sample of output trace file format, (more details
in [14,18,76]).
Sample Wireless Trace file format DSR routing protocol
s -t 12.786100000 -Hs 18 -Hd -2 -Ni 18 -Nx 274.68 -Ny 149.81 -Nz 0.00 -Ne -1.000000 -Nl AGT -Nw
--- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 18.0 -Id 19.0 -It cbr -Il 1024 -If 0 -Ii 0 -Iv 32 -Pn cbr -Pi 0 -Pf 0 -Po 0
r -t 12.786100000 -Hs 18 -Hd -2 -Ni 18 -Nx 274.68 -Ny 149.81 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw
--- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 18.0 -Id 19.0 -It cbr -Il 1024 -If 0 -Ii 0 -Iv 32 -Pn cbr -Pi 0 -Pf 0 -Po 0
s -t 12.790995225 -Hs 18 -Hd -1 -Ni 18 -Nx 274.68 -Ny 149.81 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw
--- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 18.255 -Id 19.255 -It DSR -Il 32 -If 0 -Ii 1 -Iv 32 -P dsr -Ph 1 -Pq 1 -
Ps 1 -Pp 0 -Pn 1 -Pl 0 -Pe 0->0 -Pw 0 -Pm 0 -Pc 0 -Pb 0->0
r -t 12.791807459 -Hs 40 -Hd -1 -Ni 40 -Nx 339.20 -Ny 122.05 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw
--- -Ma 0 -Md ffffffff -Ms 12 -Mt 800 -Is 18.255 -Id 19.255 -It DSR -Il 32 -If 0 -Ii 1 -Iv 32 -P dsr -Ph 1
-Pq 1 -Ps 1 -Pp 0 -Pn 1 -Pl 0 -Pe 0->0 -Pw 0 -Pm 0 -Pc 0 -Pb 0->0
f -t 12.872979638 -Hs 33 -Hd -1 -Ni 33 -Nx 424.81 -Ny 246.62 -Nz 0.00 -Ne -1.000000 -Nl RTR -Nw
--- -Ma 0 -Md ffffffff -Ms 12 -Mt 800 -Is 18.255 -Id 19.255 -It DSR -Il 48 -If 0 -Ii 3 -Iv 32 -P dsr -Ph 2
-Pq 1 -Ps 2 -Pp 0 -Pn 2 -Pl 0 -Pe 0->0 -Pw 0 -Pm 0 -Pc 0 -Pb 0->0
d -t 13.186985188 -Hs 18 -Hd 4 -Ni 18 -Nx 275.08 -Ny 149.78 -Nz 0.00 -Ne -1.000000 -Nl IFQ -Nw
ARP -Ma 0 -Md 0 -Ms 12 -Mt 800 -Is 18.0 -Id 19.0 -It cbr -Il 1076 -If 0 -Ii 0 -Iv 32 -Pn cbr -Pi 0 -Pf 0
-Po 0
After the simulation we obtain the trace file format, which contains the packet dump
from the simulation, each simulation trace files records the traffic and node
movements are generated. These files need to be analyzed in order to extract the
information needed to measure the performance metrics. The new trace format was
used for analyzing the trace file format for DSDV, DSR and ADOV protocols. For
example, the new trace format looks like:
s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 –Ne -1.000000 -Nl RTR -Nw --
- -Ma 0 -Md 0 -Ms 0 -Mt 0 –Ii 20 -Is 0.255 -Id -1.255 –It
The format of this trace file for ad-hoc wireless networks is as N: Node Property, I: IP
Level Packet Information, H: Next Hop Information, M: MAC Level Packet
Information, P: Packet Specific Information. Here, from the above trace file format
and table 3.1, we see that a packet was sent (s) at time (t) 0.267662078 sec, from
source node (Hs) 0 to destination node (Hd) 1. The source node id (Ni) is 0, its x-
coordinate (Nx) is 5.00, its y-coordinate (Ny) is 2.00, its z-coordinate (Nz) is 0.00, its
energy level (Ne) is 1.000000, the trace level (Nl) is RTR and the node event (Nw) is
blank. The MAC level information is given by duration (Ma) 0, destination Ethernet
address (Md) 0, the source Ethernet address (Ms) is 0 and Ethernet type (Mt) is 0. The
IP packet level information like packet id (Ii), source address. Source port number is
given by (Is) while the destination address. Destination port number is (Id).
56
Evet Abbreviation Flag Type Value

-t double Time (* For Global Setting)
-Ni int Node ID
-Nx double Node X Coordinate
-Ny double Node Y Coordinate
-Nz double Node Z Coordinate
-Ne double Node Energy Level
Network trace Level (AGT, RTR, MAC,
-Nl string
s: Send etc.)
Wireless r: Receive -Nw string Drop Reason
Event d: Drop
f: Forward -Hs int Hop source node ID
-Hd int Hop destination Node ID, -1, -2
-Ma hexadecimal Duration
-Ms hexadecimal Source Ethernet Address
-Md hexadecimal Destination Ethernet Address
-Mt hexadecimal Ethernet Type
-P string Packet Type (arp, dsr, imep, tora, etc.)
-Pn string Packet Type (cbr, tcp)
Table 3.1: Sample Ns-2 Trace Formats [18]
3.2.1. Sent packet

Calculate of the numbers of sent packets from trace file format for three protocols
(DSDV, DSR and ADOV) are as follows:
/^s *- Nl AGT.*-Is (\d{1,3})\.\d{1,3} -Id (\d{1,3})\.\d{1,3}.*-It cbr.*-Ii (\d{1,6})/
AGT => Agent Level Trace

cbr=> Continuous bit rate
Function java code used (see our implementation code to analysis trace file format in
Appendix C) as:
if(tokens[0].equals("s")&&tokens[18].equals("AGT")&&tokens[34].equals ("cbr"))
sends++;
3.2.2. Received packet

Calculate of the numbers of received packets from trace file format for three protocols
(DSDV, DSR and ADOV) are as follows:
/^r -t (\d{1,3}\.\d{9}).*-Nl AGT.*-Is (\d{1,3})\.\d{1,3} -Id (\d{1,3})\.\d{1,3}.*-It cbr.*-

Ii (\d{1,6})/
r=> receive
Function java code used (see our implementation code to analysis trace file format in
Appendix C) is as follow:
57
if(tokens[0].equals("r")&&tokens[18].equals("AGT")&&tokens[34].equals("cbr"))
receives++;
3.2.3. Routing packets sent

Calculate of the numbers of routing packet sent from trace file format for three
protocols (DSDV, DSR and ADOV) are as follows:
/^[s|f].*-Nl RTR.*-It (?:AODV|DSR|message) -Il (\d{1,4})/
S=> send
f = > forward
RTR=> Routing Trace Level
Function java code used (see our implementation code to analysis trace file in
Appendix C) as:
if((tokens[0].equals("s")||tokens[0].equals("f"))&&tokens[18].equals("RTR")&&(toke
ns[34].equals("AODV")||tokens[34].equals("DSR")||tokens[34].equals("message")))
routing_packets++;
3.2.4. Duration of packets

To calculate the packet duration from trace file format for three protocols (DSDV,
DSR and ADOV) by sum of (time packet received – time packet sent). For each
packet with id (Ii) of trace level (AGT) and type (cbr), calculate the send(s) time (t), at
receive (r) time (t) and average it.
Appendix C) as:
-t=> time
if (tokens[0].equals("s")||tokens[0].equals("r")||tokens[0].equals("f"))
{
// parse the time
if(tokens[1].equals("-t"))time=Float.valueOf(tokens[2]).floatValue();
// parse the packet_id
if(tokens[39].equals("-Ii"))packet_id= Integer.valueOf(tokens[40]).intValue();
// calculate the sent packets
if(tokens[0].equals("s")&&tokens[18].equals("AGT")&&tokens[34].equals("cbr"))
sends++;
// find the number of packets in the simulation
if(packet_id >highest_packet_id) highest_packet_id = packet_id;
// set the start time, only if it is not already set
if (start_time[packet_id]==0) start_time[packet_id]=time;
// calculate the receives and end-end delay
if(tokens[0].equals("r")&&tokens[18].equals("AGT")&&tokens[34].equals("cbr"))
{
receives++;
end_time[packet_id]=time;
}
else end_time[packet_id] = -1;
}
58
//calculate the packet duration for all the packets

for (packet_id = 0; packet_id <= highest_packet_id ; packet_id++)
{
packet_duration = end_time[packet_id] - start_time[packet_id];
if (packet_duration >0) end_to_end_delay += packet_duration;
}
3.2.5. Drop packets at routing overhead

Calculate of the numbers of drops at routing packet sent from trace file format for
three protocols (DSDV, DSR and ADOV) are as follows:
/^[d].*-Nl RTR.*-It (?:AODV|DSR|message) -Il (\d{1,4})/
d = > drop
RTR = > Routing Trace Level
Appendix C) as:
if(tokens[0].equals("d")&&tokens[18].equals("RTR")&&(tokens[34].equals("AODV"
)||tokens[34].equals("DSR")||tokens[34].equals("message")))routing_drops++;
3.2.6. Drops packet at End of time

Calculate of the numbers of drops packet at End of simulation time from trace file
format for three protocols (DSDV, DSR and ADOV) are as follows:
/^[d].*-Nl IFQ .*-It (?:AODV|DSR|message) -Il (\d{1,4})/

d = > drop
IFQ=>interface queue
Appendix C) as:
if(tokens[0].equals("d") && tokens[18].equals("IFQ")) dpIFQ++;
3.2.7. Movement Node

To plot the movement node, we need to sort the Nx and Ny of any source node Hs at
each pause time of simulation from trace file formats:
S & r & d & f / -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00
S= send. & r= received & f= forward & d=drop
See function C++ code used of our implementation code to analysis trace file in
Appendix C.
3.3. Performance Metrics

All protocols are run on identical movement and communication scenarios. The first 6
important performance metrics are evaluated for each simulation run. Have been
designed Module analyzer with new two performance metrics (drop packets at
routing overhead and drop packets at end of simulation time) with movement node
module, our code used to analyze performance metrics from trace file in (Appendix
59
C). As the first two metrics are the most important for best effort traffic, the routing
load metric evaluates the efficiency of the routing protocol. Note, however, that these
metrics are not completely independent. For example, lower packet delivery fraction
means that the delay metric is evaluated with fewer samples. In the conventional
wisdom, the longer the path lengths, the higher the probability of a packet drops.
Thus, with a lower delivery fraction, samples are usually biased in favor of smaller
path lengths and thus have less delay. So that another metrics is used to evaluate all
routing protocols for each simulation run in section 3.3.5, 3.3.6. The code program
used to analyze the trace files format is added to Appendix-C. This file is used to
record the packets and compute the following metrics
3.3.1. Packet delivery fraction ratio

The ratio of the data packets delivered to the destinations to those generated by the
CBR sources [20, 25].
3.3.2 Average End-to-End delay of data packets

This includes all possible delays caused by buffering during route discovery latency,
queuing at the interface queue, retransmission delays at the MAC, and propagation
and transfer times[20,25].
3.3.3. Normalized routing load

The number of routing packets transmitted per data packet delivered at the
destination. Each hop-wise transmission of a routing packet is counted as one
transmission [21, 31].
3.3.4. Routing packet overhead

Routing Packet overhead RPO is the total number of transmissions routing packets [1, 5].
3.3.5. Drop packets at routing overhead

The DPRO is the total number of drop packets at transmissions of routing by the
source nodes.
3.3.6. Drop of packets

All drop of packets at end of simulation time is called DPEST.
60
3.4. Simulation
A detailed simulation model based on Ns-2 simulator is used in the evaluation. To use
simulator Ns-2 to support the mobility wireless sensor network simulation first:
implement analyzer module of simulation result (output trace file format) that can
make comparison and performance analysis between three mobiles ad-hoc routing
algorithm protocols (Classification of flat routing protocols). Destination-Sequenced
Distance Vector (DSDV), Ad-Hoc On-Demand Distance Vector (AODV) and
Dynamic Source Routing (DSR) are implemented already in Ns-2. The first one is a
proactive protocol depending on routing tables which are maintained at each node.
The second and third is a reactive protocol, which finds a route to a destination on
demand, when every communication is needed. Considering the bandwidth,
throughput and packet loss, in DSDV, DSR and AODV routing protocols, DSDV is
best suited for only smaller networks, DSR and AODV is suited for general ad-hoc
networks. Second: implement secure routing algorithm protocol in simulator Ns-2 that
can evaluate, compare and analyze of the secure routing algorithm protocol which is
compared to traditional routing algorithm protocol. The parameters used for our
simulation are given in table 3.2.
Parameter Value
Number of Nodes 50
Area size of the topography x(m) 1000m
Area size of the topography y(m) 1000m
Traffic type Cbr
Wireless range 150 m
Number of traffic sources 10 , 20 , 30
Send rate of Traffic 1 packets/ Second
Speed 2 m/s & 20 m/s
Packet size 512 byte
Simulation Time (Second) 100 s ,500s, 900 s
Pause Time (s) at time simulation 100s 0 , 10 , 20 , 40 ,100 Second
Pause Time (s) at time simulation 500s 0 , 50 , 100 , 200 , 300 , 400 ,500 Second
Pause Time (s) at time simulation 900s 0 , 50 , 100 , 300 , 600 , 800 ,900 Second
Table 3.2: Scenario for the simulator Ns-2 experiments
3.5. Simulation Procedure for Running Scenario

The procedure for running the scenario based experiments, as shown in figure 3.3,
from simulation procedure to produce the performance results graphs and by NAM
tool provides a graphical animation of the nodes in the simulated network and traffic
between. So For any experiment, there is a set of control parameters which are
specified by the user and a set of output parameters which are needed to investigate
upon. In the scenario based experiments, the set of input parameters are the
parameters for the definition of the scenario and the specification of the traffic pattern.
These parameters are defined in the following sections.
61
Figure 3.3: Simulation procedure for running scenario, where the block (analyzer module of our
code) has been designed with 6 performance metrics including two new performance metrics
(drop packets at routing overhead and drop packets at end of simulation time), movement node
module and added implementation of secure routing protocol (SEAD), where simulator Ns-2 is
not supported for any secure routing protocols in MANET.
62
3.5.1. The Traffic sources Model

The traffic sources is called [14] Communication Model. As the goal of our
simulation was to compare the performance of each routing protocol, we choose our
traffic sources to be constant bit rate (CBR) sources. When defining the parameters of
the communication model, we experimented with sending rates of 1 packets per
second, and only 512-byte data packets are used .Varying the number of CBR source
was approximately equivalent to varying the sending rate. The number of source-
destination pairs and the packet sending rate in each pair is varied to change the
offered load in the network. Since the Ns-2 simulator package comes with a traffic
generator utility, which can be found in the folder?
/home/administrator/ns-allinone2.31/ns-2.31/indep-utils/cmu-scen-gen/
This utility is used to generate trace files for specifying the type, duration and the rate
of traffic flow in the network. The utility can be invoked by calling the Tcl script
cbrgen.tcl as follows:
$ ns cbrgen.tcl [list of parameters]
So the command line [14] looks like the following:

$ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] [-mc connections][-rate rate]
List of Parameters:
 Type of traffic: CBR or TCP
 Seed: starting number for random number generator
 nn: number of node
 mc: maximum number of connection
 rate: number of packet per second (bit rate)
The output values can be written to a file using the > directive on the command line.
This file can be used as an input to the Tcl script which is described in figure 3.44.
For the simulations carried out, traffic models were generated for 50 nodes with cbr
traffic sources, with maximum connections of 10,20,30 at a rate of 1 packets/s.
3.5.2. The Mobility Model

There are several mobility models supported, namely
 The Random Waypoint model.
 Random walk with reflection.
 Restricted random waypoint.
 The Random trip model.
 The Gauss-Markov model.
 The Manhattan Grid model.
 The Reference Point Group Mobility model.
More information on these mobility models can be found at [23, 74]. So we used
mobility model random waypoint model [23] in a rectangular field. The field
configurations used is 1000 m x 1000 m field with 50 nodes. We download the
implementation of this paper (random trip models) [23] in Ns-2 of the model random
waypoint which can be obtained freely from [24] to generate the scenario mobility
files for different pause times and for all simulation times as shown by table 3.7 with a
velocity uniformly chosen between 2m/s and 20m/s. Here, each packet starts its
63
journey from a random location to a random destination with a randomly chosen

speed (uniformly distributed between 0–2 m/s and 0–20 m/s) called a node starts at a
random position, waits for a duration called the pause time, and then chooses a new
random location and moves there with a velocity uniformly chosen between 0 and
vmax. When it arrives, it waits for the pause time and repeats the process. Like much
previous work in evaluating ad-hoc network routing protocols e.g., [1, 15], once the
destination is reached, another random destination is targeted after a pause. The pause
time, which affects the relative speeds of the mobiles, is varied. Simulations are run
for 100, 500, 900s simulated. Identical mobility and traffic scenarios are used across
protocols to gather fair results.
3.5.3. Simulation code of Tcl script

The data files input for Ns-2 is a Tcl script file. Each script file corresponds to one
specific experiment scenario and has the extension .tcl, to edit your script file to use
any Windows editor such as textpad, editplus, notepad, etc. To run the Tcl script using
ns type, the following at the command prompt as:
$ ns filename.tcl
Some small scripts can also be run in command line mode. For this, just type ns and
enter your commands line by line. So in this section we present a walkthrough of the
script which is used to run the simulation for analyzing the performance of routing
protocols in MANET. The script can be used to simulate any kind of routing protocol
desired. We are writing the Tcl code to set up the wireless simulation components:
network components types, parameters like the type of antenna, the radio-propagation
model, the type of ad-hoc routing protocol, traffic models and node movement models
used by mobile nodes etc. Our Implementation of simulation code Tcl script used to
simulate (DSDV, DSR and AODV) routing protocols and (SEAD) secure routing
protocol is available in the Appendix B.
3.5.4. Analyzer module

After each simulation, trace files recording the traffic and node movements are
generated. These files need to be analyzing in order to extract the information needed
to measure the performance metrics. Having been designed with 6 performance
metrics with two new performance metrics (drop packets at routing overhead and
drop packets at end of simulation time), our code program to analyze the trace files
is added to Appendix C. This file is used to record the packets and compute the
following metrics:
 Number of data packets sent by source.
 Number of data packets received by the destination host
 Routing packet overhead
 Normalized routing load ratio of routing packets over data packets received.
 Packet delivery fraction ratio of received packets over sent packets.
 Average End to end delay average time for a data packet delivered from host
to destination.
 Drop packets at routing overhead
 Drop packets at end of simulation time
It writes these values to a text file which can be imported into an Excel spread sheet to
obtain the performance graphs.
64
3.5.5. Network Animator and Movement Node

The output trace file format of network animator may also be visualized in network
animator nam tool, to run the (Nam.tr) file using nam type the following at the
command prompt as:
$ nam filename.tr
We have shown the movement node and the connectivity of network in figure 3.4.
Figure 3.4: Visualized in network animator
The output trace file format of network simulator Ns-2 can be analyzed to obtain the
movement of nodes so that we used mobility model called random waypoint model
[23] in a rectangular field. The field configurations used is 1000 m x 1000 m field
with 50 nodes as shown in table 3.7. From analyzing trace file format it is shown that
the movement node at simulation time 900s of different pause time and movement
speed (2m/s and 20m/s) is as shown in figure (3.5 and 3.6), which show the
movement of the random waypoint mobility model, each mobile node begins at a
random location and moves independently during the simulation. Each node remains
stationary for a specified period that we call the pause time and then moves in a
straight line to some new randomly chosen location at a randomly chosen speed up to
some maximum speed. Once reaching that new location, the node again remains
stationary for the pause time, and then chooses a new random location to proceed to at
some new randomly chosen speed, and the node continues to repeat this behavior
throughout the simulation run. Our implementation code C/C++ is used as analyzer
module to record the movement source node and movement of all source node at each
simulation time is attached to Appendix C.
65
Figure 3.5: Movement node 6 at pause time 0 sec speed 2 m/s
Figure 3.6: Movement Node 6 at pause time 0 sec speed 20 m/s
3.6. Simulation Summary

The goal was to measure the ability of the routing protocols (DSDV, DSR, and
ADOV) and implemented SEAD: Secure efficient ad-hoc distance vector routing
protocol in Ns-2 simulator to react to network topology change while continuing to
successfully deliver data packets to their destinations. To measure this ability, a
simulated network and a variety of workloads were applied, in effect testing with each
data packet originated by some sender whether the routing protocol can at that time
66
route to the destination of that packet. We were not attempting to measure the
protocols’ performance on a particular workload taken from real life, but rather to
measure the protocols’ performance under a range of 6 metrics. The routing protocols
(DSDV, DSR, and ADOV) and SEAD: Secure efficient ad-hoc distance vector
routing protocol evaluations are based on the simulation of 50 wireless nodes forming
an ad-hoc network, moving about over a rectangular (1000m×1000m) flat space for
different simulation time as in table 3.2. We choose a space in order to force the use
of longer routes between nodes. The physical radio characteristics of each mobile
node’s network interface, include the antenna gain, transmit power, and receiver
sensitivity. In order to enable direct, fair comparisons between the protocols, it was
critical to challenge the protocols with identical loads and environmental metrics.
Each run of the simulator accepts as input a scenario file that describes the exact
motion of each node and the exact sequence of packets originated by each node,
together with the exact time at which each change in motion or packet origination is to
occur. We pre-generated 38 different scenario files with varying movement patterns
of mobility model at all pause time of simulation used random waypoint model [23,
24] for each movement speed (at the lower movement speed of 2 meter/second & at
the higher movement speed of 20 meter/second) and four files traffic loads as shown
in table 3.3, and then run simulator Ns-2 for three routing protocols (DSDV, DSR,
and ADOV) and SEAD: Secure efficient ad-hoc distance vector routing protocol
against each of these scenario files. Since each protocol was challenged in an identical
fashion, we can directly compare the performance results of the three routing
protocols and SEAD: Secure efficient ad-hoc distance vector routing protocol.
Speed 2m/s and 20m/s Total

Generation files Pause
100
200
300
400
500
600
800
900
10
20
40
50
13
0
Time
Scenario parameter files with 5x2
0,10,20,40,100s
varying movement patterns of 7x2x2
0,50,100,200,300,400,500s
mobility model used random
0,50,100,300,600,800,900s
waypoint model 38
Number of traffic sources 10 20 30
Traffic pattern parameters
4 3
load files
Table 3.3: Total of generation Parameters input files of simulator Ns-2 at all Pause
time of simulation for all routing protocols
We run simulator Ns-2 by writing the simulation code tcl script files which is
available in Appendix B and more details of tcl script (Tool command language) see
the tutorial of network simulator Ns-2 [26] , to set up the wireless simulation
components: network components types, parameters like the type of antenna, the
radio-propagation model, the type of ad-hoc routing protocol, traffic models and node
movement models used by mobile nodes etc. with movement patterns generated for 5
different pause times: 0 , 10 , 20 , 40 , and 100 seconds for simulation time 100
seconds , 7 different pause times: 0 , 50 , 100 , 200 , 300 , 400 and 500 seconds for
simulation time 500 seconds and 7 different pause times: 0 , 50 , 100 , 300 , 600 , 800
and 900 seconds for simulation time 900 seconds. A pause time of 0 seconds
corresponds to continuous motion, and a pause time of 100 (the length of the
67
simulation) corresponds to no motion at simulation time 100 seconds and a pause time
of 500 and 900 (the length of the simulation) corresponds to no motion at simulation
time 500 and 900 seconds. Because the performance of the protocols is very sensitive
to movement pattern, we generated movement pattern scenario 38 files, for each value
of pause time, with each movement speed (at the lower movement speed of 2 m/s & at
the higher movement speed of 20 m/s) and four traffic communication sources model
files of 10, 20, 30 sources as in table 3.3, for all three routing protocols and SEAD:
Secure efficient ad-hoc distance vector routing protocol, was run on the same
movement patterns within environment of attackers. We experimented with two
different maximum speeds of node movement. We primarily report in this thesis data
from simulations using a maximum node speed of 2 meters per second, but also
compare this to simulations using a maximum speed of 20 meter per second. From
table (3.4, 3.5 and 3.6) after running simulator Ns-2, we produce generation outputs
trace file formats at simulation time 100s, 30 trace file formats, at simulation time
500s, 42 trace file formats and at simulation time 900s, 42 trace file formats for each
routing protocol. From table 3.7 the total generation outputs trace file formats of
simulator Ns-2 at simulation time 100,500,900 seconds for each routing protocols are
114 trace file formats and animator file formats, for only one simulation of routing
protocol at each pause time and the number of traffic pattern parameters load files and
scenario parameters file with varying movement patterns of mobility model used
random waypoint model.

Pause Time
Generation files 0 10 20 40 100 5
At simulation time 100s
Scenario parameters file with varying movement
patterns of mobility model used random waypoint 5 10
model
Traffic pattern parameters load files 4 4
Generate outputs trace file formats of simulator =5x3x2
5 5 5
Ns-2 30
Table 3.4: Generation outputs trace file formats of simulator Ns-2 at simulation time
100s for each routing protocol

Pause Time
Generation files At simulation 0 50 100 200 300 400 500 7
time 500s
Scenario parameters file with
varying movement patterns of
7 14
waypoint model
Generate outputs trace file formats =7x3x2
7 7 7
of simulator Ns-2 42
68

Generation Pause Time
files At simulation 0 50 100 300 600 800 900 7
time 900s
Scenario parameters file with
varying movement patterns of
7 14
waypoint model
Traffic pattern parameters load
3 3
files
Generate output trace file =7x3x2
7 7 7
formats of simulator Ns-2 42
Generation files Total

Scenario parameters file with varying
movement patterns of mobility model used 38
random waypoint model
Simulation time 100s 500s 900s
Generate outputs trace file formats of =30+42+42
30 42 42
simulator Ns-2 114
Table 3.7: Total generation outputs trace file formats of simulator Ns-2 at simulation
time 100,500,900 second for each routing protocol
finally, from running simulator Ns-2 the simulation results of all routing protocols
(DSDV, DSR, ADOV and SEAD) are as shown in table 3.8, where the DSDV routing
protocol produces generation 128 output trace file formats for all simulation time and
animator file formats for all simulation time used, the DSR routing protocol produces
generation 128 output trace file formats and animator file formats for all simulation
time used, the AODV routing protocol produces generation 128 output trace file
formats and animator file formats for all simulation time used but for SEAD: Secure
efficient ad-hoc distance vector routing protocol produces generation 72 output trace
file formats and animator file formats for all simulation time used.
The total of all generation 456 output trace file formats and animator file formats,
at each simulation time depending of the time simulation of routing protocols used as
shown in table 3.8. The trace files format outputs most important step in our
experiment is to analyze the output file formats from the simulation. After the
simulation, we obtain the trace file which contains the packet dump from the
simulation. The format of this trace file for ad-hoc wireless networks, depending on
the packet type, the trace file may log additional information [14, 29]. By using our
code to analyzer module attached to Appendix C, to analyzer the 456 output trace file
formats to record the packets and compute the performance metrics graphs that are
described in section 3.3, and the output trace files may also be visualized in network
animator (nam) that is described in section 3.5.5.
69
Simulation Time & Number of Traffic Sources Generate

Routing 100s 500s 900s outputs
Protocols trace file
10 20 30 10 20 30 10 20 30
formats
DSDV Yes Yes Yes Yes Yes Yes Yes Yes Yes 128
DSR Yes Yes Yes Yes Yes Yes Yes Yes Yes 128
AODV Yes Yes Yes Yes Yes Yes Yes Yes Yes 128
SEAD Yes Yes Yes Yes Yes Yes 72
All Generation output trace file formats of simulator Ns-2 456

Table3.8: Total of all generation outputs trace file formats of simulator Ns-2 for all
routing protocols used
3.7. Results & Performance Analysis Comparison of Ad-hoc Routing

Protocols
First, an attempt was made to compare the three routing protocols (DSDV, DSR and
AODV) under the same simulation environment. All the simulations, the same
movement models were used; the number of traffic sources was fixed in table 3.2, the
maximum speed of the nodes was set to 2m/s and 20m/s where the pause time was
varied as shown in table 3.2. Scenario for the simulator Ns-2 experiments for routing
protocols, figures 3.7, 3.8, 3.9, 3.10, 3.11 and 3.12, highlight the relative performance
of the three routing protocols. All of the protocols deliver a greater percentage of the
originated data packets when there is little node mobility (i.e., at large pause time),
converging to 100% delivery when there is no node motion with time simulation 100s
as shown in figures 3.7(a , d and g) . in figures 3.7, 3.8, 3.9, 3.10, 3.11 and 3.12, each
graph represents the random way movement and communication scenarios for the
given pause time. At a pause time of 0 (on the left-hand-side of each graph), all nodes
in the network are in constant motion, and as the pause time increases from left to
right, the node movement rate in the network decreases. at a pause time of 100
seconds (on the right-hand-side of each graph), all nodes are stationary, since each
simulation was run for 100 simulated seconds of operation of the ad-hoc network at
the lower movement speed of 2meter/second and high movement speed of 20
meter/second.
3.7.1. Packet delivery Comparison

Packet delivery ratio is important as it describes the loss rate that will be seen by the
transport protocols, which in turn affects the maximum throughput that the network
can support. This metric characterizes both the completeness and correctness of the
routing protocol.
a)- Simulation time 100 seconds
At the lower movement speed of 2meter/second, the on-demand protocols, DSR and
AODV performed particularly well, delivering over 95% of the data packets
regardless of mobility rate as shown in figures 3.7(a, d and g) with the lower
movement speed of (2meter/second) for 10, 20 and 30 sources which were very
70
similar for both protocols at lower pause times with higher mobility. So for DSR and
AODV, packet delivery ratio is independent of offered traffic load, with both
protocols delivering between 95% and 100% of the packets.
The on-demand protocols, AODV and DSR perform better than the table-driven
DSDV protocol. Where DSDV delivering over 70% of the data packets regardless of
mobility rate as shown in figures 3.7(a, d and g) with the lower movement speed of
(2m/s) for 10,20 and 30, but DSDV loses about 50% more packets than AODV and
DSR for lower 10s pause times (higher mobility) at 10 and 20 sources. Nearly all of
the dropped packets are lost because a stale routing table entry directed them to be
forwarded over a broken link.
At the higher movement speed of 20 meter/second as shown in figures 3.7(a, d and g),
the on-demand protocols, DSR and AODV performed particularly well, delivering
over 90% of the data packets regardless of mobility rate at pause time 40s as shown in
figures 3.7(a, d and g) with the high movement speed of (20 meter/second) for 10,20
and 30 sources which were very similar for both protocols at high pause times with
lower mobility. So for DSR and AODV, packet delivery ratio is independent of
offered traffic load, with both protocols delivering between 75% and 90% of the
packets at 10 sources, but at 20 and 30 sources both protocols delivering between 80%
and 90% of the packets.
DSDV protocol. DSDV delivers over 70% of the data packets regardless of mobility
rate as figures 3.7(a, d and g) with the high movement speed of (20m/s) for 10,20 and
30, but DSDV loses about 20% more packets than AODV and DSR for lower 40s
pause times (higher mobility) at 10 and 30 sources. Nearly all of the dropped packets
are lost because a stale routing table entry directed them to be forwarded over a
broken link.
b)- Simulation time 500 seconds
At the lower movement speed of 2 meter/second, the On-demand protocols, DSR and
AODV performed particularly well, delivering over 95% of the data packets
regardless of mobility rate as shown in figures 3.7 (b, e and h) with the lower
movement speed of (2 meter/second) for 10, 20 and 30 sources which were very
similar for both protocols at lower pause times with higher mobility. So for DSR and
DSDV protocol. Where DSDV delivering over 70% to 80% of the data packets of
mobility rate as shown in figures 3.7(b and e) with the lower movement speed of
(2m/s) for 10 and 20, but DSDV loses about 40% more packets than AODV and DSR
for lower 10s pause times (higher mobility) at 10 and 20 sources. Nearly all of the
dropped packets are lost because a stale routing table entry directed them to be
forwarded over a broken link. At 30 sources the DSDV delivers over 80% to 90% of
the data packets of mobility rate as shown in figure 3.7(h) with the lower movement
speed of (2m/s).
At the higher movement speed of 20meter/second as shown in figures 3.7(b, e and h),
the on-demand protocols, DSR and AODV performed particularly well, delivering
over 90% of the data packets of mobility rate at pause time 100s as shown in figures
3.7(b and e) with the high movement speed of (20 meter/second) for 10 and 20
sources which were very similar for both protocols at high pause times with lower
mobility. So for DSR and AODV, packet delivery ratio is independent of offered
traffic load, with both protocols delivering between 85% to 100% for AODV and 90%
71
to 100% for DSR of the packets at 10 sources, but at 20 and 30 sources both protocols
deliver between 90% and 100% of the packets at pause time 200s to 500s with lower
mobility as shown in figures 3.7(e and h).
DSDV protocol. Where DSDV delivering over 55% of the data packets of mobility
rate as figures 3.7(b, e and h) with the high movement speed of (20m/s) for 10,20 and
30, but DSDV loses about 25% more packets than AODV and DSR for lower 40s
pause times (higher mobility) at 10 sources. Nearly all of the dropped packets are lost
because a stale routing table entry directed them to be forwarded over a broken link.
c)- Simulation time 900 seconds
At the lower movement speed of 2 meter/second as shown in figures 3.7(c, f and i), the
on-demand protocols, DSR and AODV performed particularly well, delivering over
95% of the data packets regardless of mobility rate as shown in figure 3.7(c) with the
lower movement speed of (2 meter/second) for 10 sources which were very similar for
both protocols at lower pause times with higher mobility and DSR performed
particularly well, delivering over 98% of the data packets regardless of mobility rate
as shown in figure 3.7(i) with the lower movement speed of (2 meter/second) for 30
sources. But DSDV delivering over 80% of the data packets regardless of mobility
rate as shown in figure 3.7(i) with the lower movement speed of (2 meter/second) for
30 sources at lower pause times with higher mobility and 90% at higher pause times
with lower mobility as shown in figures 3.7(c, i) for 10, 30 sources . So for DSR and
At the higher movement speed of 20 meter/second as shown in figures 3.7(c, f and i),
the on-demand protocols, DSR delivers over 95% of the data packets regardless of
mobility rate from pause time 0s to pause time 600s as shown in figure 3.7(c) with
the high movement speed of (20 meter/second) for 10 sources which were very
similar for AODV protocol at pause time 100s to pause time 600s as shown in figure
3.7(c) for pause times with lower mobility. However, DSR delivers over 25% of the
data, AODV delivering over 85% of the data and DSDV delivering over 65% of the
data as shown in figures 3.7(i) with the higher movement speed of (20 meter/second)
for 30 sources at lower pause times where higher mobility. But DSDV, DSR and
AODV are very similar at 300s to 900s pause time. As shown in figures 3.7(c, f) the
on-demand protocols, AODV and DSR perform better than the table-driven DSDV
protocol, where as DSDV delivers over 65% of the data packets regardless of mobility
rate with the high movement speed of (20m/s) for 10 sources.
72
Packet Delivery Ratio (10 sources)

1
DSR speed 20m/s
0.9
# data pakets received/#data packets
0.8 AODV speed 20m/s

0.7
sent (packets)
DSDV speed 20m/s

0.6
0.5
DSR speed 2m/s
0.4
0.3 AODV speed 2m/s
0.2
DSDV speed 2m/s
0.1
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
1
0.9 DSR speed 20m/s

0.8
AODV speed 20m/s
0.7
sent (packets)
0.6 DSDV speed 20m/s

0.5
DSR speed 2m/s
0.4
0.3 AODV speed 2m/s
0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500
Pause Time (sec)
73
1
0.9
0.8
DSR speed 20m/s
0.7
sent (packets)
AODV speed 20m/s

0.6
0.4
DSR speed 2m/s
0.3
AODV speed 2m/s
0.2
0.1 DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)

1
DSR speed 20m/s
0.9
# data pakets received/#data packets sent

0.7

(packets)
0.5
DSR speed 2m/s
0.4
0.3 AODV speed 2m/s
0.2
DSDV speed 2m/s
0.1
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(Sec)
74
1
0.9 DSR speed 20m/s

0.8
AODV speed 20m/s
0.7
(packets)
0.5
DSR speed 2m/s
0.4
0.3 AODV speed 2m/s
0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500
Pause Time(sec)
Packet Delivery Ratio(20 sources)
0.9
0.8 DSR speed 20m/s
0.7
AODV speed 20m/s
sent (packets)
0.6
DSDV speed 20m/s
0.5
0.4 DSR speed 2m/s
0.3 AODV speed 2m/s

0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
75

1
DSR speed 20m/s
0.9
0.7
DSDV speed 20m/s
0.6
(packets)
0.5 DSR speed 2m/s

0.4
AODV speed 2m/s
0.3
0.2
DSDV speed 2m/s
0.1
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(Sec)
Figure 3.7: (g) Packet delivery ratio at movement speed (2m/s and 20m/s) and
1
0.9
# data pakets received/#data
DSR speed 20m/s

packets sent (packets)
0.8

0.5
0.4 DSR speed 2m/s
0.3 AODV speed 2m/s

0.2
0.1 DSDV speed 2m/s
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.7: (h) Packet delivery ratio at movement speed (2m/s and 20m/s) and
76
Packet Delivery Ratio(30 sources)
1
0.9
DSR speed 20m/s
0.8
sent (packets)

0.5
DSR speed 2m/s
0.4
0.3 AODV speed 2m/s
0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.7: (i) Packet delivery ratio at movement speed (2m/s and 20m/s) and
3.7.2. Average End-End Delays Packet delivery

The average end-to-end delay of packet delivery at the lower movement speed of 2
meter/second was higher in AODV as compared to both DSR and DSDV at the 10
sources. But very similar for both protocols DSR and ADOV at 20 and 30 sources the
average end-to-end delay of packet delivery was higher at pause time 10 seconds as
shown in figures 3.8(a , d and g). At the higher movement speed of 20 meter/second
as was higher in DSR as compared to both AODV and DSDV at the 10 sources as
shown in figure 3.8(a), higher in DSDV as compared to both AODV and DSR at the
20 sources as shown in figures 3.8(d), higher in DSR as compared to both AODV and
DSDV at the 30 sources as shown in figure 3.8(g). But very similar from pause time
20s with high pause times and lower mobility for protocols DSR and AODV at 20
sources as shown figure 3.8(d).
The average end-to-end delay of packet delivery as shown in figures 3.8(b , e and h)
at the lower movement speed of 2meter/second was higher in DSR as compared to
both AODV and DSDV at the 10, 20 and 30 sources as shown in figures 3.8(b , e and
h). But very similar for both protocols DSR and ADOV at 20 and 30 sources in
figures 3.8(e and h), the average end-to-end delay of packet delivery was higher at
pause time 300s to 500s for 10, 20 and 30 sources as shown in figures 3.8(b , e and h).
At the higher movement speed of 20meter/second was higher in DSR as compared to
both AODV and DSDV at the 20 and 30 sources as shown in figures 3.8(e and h), was
higher in DSDV as compared to both AODV and DSR at the 10 sources as shown in
figures 3.8(b). But very similar from pause time 200s with high pause times where
lower mobility for protocols DSR and AODV and DSDV at 10 and 20 sources as
shown in figure 3.8(b and e), where DSDV and AODV are nearly very similar
average end-to-end delay of packet delivery at speed of 20m/s of 10, 20 and 30
sources.
77
c)- Simulation time 900 seconds

The average end-to-end delay of packet delivery in figures 3.8(c , f and i) at the lower
movement speed of 2 meter/second was higher in DSR as compared to both DSDV
and AODV at the 10 and 30 sources as shown in figures 3.8(c and i). But very similar
for both protocols DSDV and ADOV at 30 sources as shown in figures 3.8(i). At the
higher movement speed of 20 meter/second as was higher in DSDV as compared to
both AODV and DSR at the 10 sources as shown in figure 3.8(c) and higher in DSR
as compared to both AODV and DSR protocols at the 30 sources as shown in figure
3.8(i), where both AODV and DSR protocols have a similar scale of average end-to-
end delays of packet delivery.
Average End-End delay(10 sources)

2
1.8 DSR speed 20m/s
1.6
Average End-End delay (sec)
AODV speed 20m/s

1.4
1
DSR speed 2m/s
0.8
0.6 AODV speed 2m/s

0.4
DSDV speed 2m/s
0.2
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 3.8: (a) Average End-End delays at movement speed (2m/s and 20m/s) and
1.4
1.2 DSR speed 20m/s

Average End-End delay(sec)
1 AODV speed 20m/s
0.8
DSDV speed 20m/s
DSR speed 2m/s

0.6
AODV speed 2m/s

0.4
DSDV speed 2m/s
0.2
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.8: (b) Average End-End delays at movement speed (2m/s and 20m/s) and
78
Average End-End delay (10 sources)

1
DSR speed 20m/s

0.8
AODV speed 20m/s

0.6
DSDV speed 20m/s
DSR speed 2m/s

0.4
AODV speed 2m/s
0.2 DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.8: (c) Average End-End delays at movement speed (2m/s and 20m/s) and

2
1.8 DSR speed 20m/s
1.6
AODV speed 20m/s

1.4
1
DSR speed 2m/s
0.8
0.6 AODV speed 2m/s
0.4
DSDV speed 2m/s
0.2
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(Sec)
Figure 3.8: (d) Average End-End delays at movement speed (2m/s and 20m/s) and
79
2.5
DSR speed 20m/s
AODV speed 20m/s

2
DSDV speed 20m/s

1.5
DSR speed 2m/s
1 AODV speed 2m/s
DSDV speed 2m/s

0.5
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.8: (e) Average End-End delays at movement speed (2m/s and 20m/s) and
DSR speed 20m/s

0.8
AODV speed 20m/s
DSR speed 2m/s
0.4
AODV speed 2m/s
DSDV speed 2m/s

0.2
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.8: (f) Average End-End delays at movement speed (2m/s and 20m/s) and
80

2
DSR speed 20m/s
1.8
1.6 ADOV speed 20m/s

1.4
DSDV speed 20m/s
1.2
1 DSR speed 2m/s
0.8
AODV speed 2m/s
0.6
0.4 DSDV speed 2m/s
0.2
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 3.8: (g) Average End-End delays at movement speed (2m/s and 20m/s) and
8
7.5
7
DSR speed 20m/s
6.5
6
AODV speed 20m/s
5.5
5
DSDV speed 20m/s
4.5
4
DSR speed 2m/s
3.5
3
AODV speed 2m/s
2.5
2
DSDV speed 2m/s
1.5
1
0.5
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.8: (h) Average End-End delays at movement speed (2m/s and 20m/s) and
81
DSR speed 20m/s

0.8
AODV speed 20m/s
DSR speed 2m/s
0.4
AODV speed 2m/s
DSDV speed 2m/s

0.2
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.8: (i) Average End-End delays at movement speed (2m/s and 20m/s) and
3.7.3. Normalized Routing Load Comparison

a) - Simulation time 100 seconds
In all cases at the lower movement speed of 2meter/second, DSR demonstrates
significantly lower routing load than AODV and DSDV as shown in figures 3.9 (a, d
and g) with the factor increasing a growing number of sources. The routing load was
higher in DSDV at 10 sources as compared to both DSR and ADOV, where as routing
load at 20 and 30 sources was higher in ADOV as compared to both DSR and DSDV.
In figures 3.9 (a, d and g) at the higher movement speed of 20meter/second, the DSR
demonstrates significantly lower routing load than AODV and DSDV as shown in
figures 3.9 (a and d) with 10 and 20 sources. But the DSDV demonstrates
significantly lower routing load than AODV and DSR as shown in figure 3.9 (g) with
30 sources.
b) - Simulation time 500 seconds
In all cases at pause time 0s to 40s with lower movement speed of 2meter/second,
AODV demonstrates significantly higher routing load than DSR and DSDV as shown
in figures 3.9 (b, e and h) with the factor increasing a growing number of sources. But
in all cases at 20 and 30 sources AODV demonstrates significantly higher routing load
than DSR and DSDV as shown in figures 3.9 (b, e and h). The routing load was
higher in DSDV at 10 sources as compared to both DSR and ADOV from pause time
40s to 500s as shown in figure 3.9 (b), where as routing load at 10 and 20 sources was
lower in DSR as compared to both AODV and DSDV as shown in figures 3.9 (b and
e). In figures 3.9 (b, e and h) at the higher movement speed of 20meter/second, the
DSR demonstrates significantly lower routing load than AODV and DSDV as shown
in figure 3.9 (b) with 10 sources. In figures 3.9 (b, e and h) at the higher movement
speed of 20m/s, the DSDV demonstrates significantly lower routing load than AODV
and DSR with 20 and 30 sources as shown in figure 3.9 (e and h). But AODV
demonstrates significantly higher routing load than DSDV and DSR as shown in
82
figures 3.9 (b) with 10 sources. The similar routing load at pause time 200s to 500s as
shown in figure 3.9 (b) with 10 sources.
c) - Simulation time 900 seconds
The normalized routing load at the lower movement speed of 2meter/second, DSR
protocol is lower routing load than AODV and DSDV as shown in figures 3.9 (c, f
and i) with the factor increasing a growing number of sources. The normalized routing
load was higher in DSDV at 10 sources as compared to both DSR and ADOV as
shown in figure 3.9 (c); where as the normalized routing load at 30 sources was higher
in ADOV as compared to both DSR and DSDV protocols as shown in figure 3.9 (i).
But the normalized routing load at 30 sources had a very similar scale plotted for both
protocols DSDV and DSR as shown in figure 3.9 (i). In figures 3.9 (c, f and i) at the
higher movement speed of 20 meter/second, the normalized routing load at 10 sources
had a very similar scale plotted for both protocols DSDV, DSR and AODV as shown
in figure 3.9 (c). But the DSR protocol is higher at lower pause time with 30 sources
at higher mobility as shown in figure 3.9 (i), but it was very similar with both
protocols DSDV and AODV at higher pause time, with lower mobility speed.
Normalized Routing Load (10 sources)
14
DSR speed 20m/s
Normalized Routing Load(packets)
12
ADOV speed 20m/s
10
DSDV speed 20m/s
8
DSR speed 2m/s

6
4 ADOV speed 2m/s
2 DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
83

14
12
DSR speed 20m/s

10
AODV speed 20m/s
8 DSDV speed 20m/s
DSR speed 2m/s

6
AODV speed 2m/s
4
DSDV speed 2m/s
0
0 100 200 300 400 500
Pause Time(sec)

20
18
DSR speed 20m/s
Normalized Routing Load (packets)
16
14 AODV speed 20m/s
12 DSDV speed 20m/s

10
DSR speed 2m/s
8
ADOV speed 2m/s
6
4 DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
84
14
DSR speed 20m/s
12
AODV speed 20m/s
10
DSDV speed 20m/s

8
6 DSR speed 2m/s
4 AODV speed 2m/s
2
DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
14
12 DSR speed 20m/s
10 AODV speed 20m/s
8 DSDV speed 20m/s
6 DSR speed 2m/s
4 AODV speed 2m/s
2 DSDV speed 2m/s

0
0 100 200 300 400 500
Pause Time(sec)
85

75
70
65
Normalized Routing Load (packats)
DSR speed 20m/s

60
55 AODV speed 20m/s
50
45 DSDV speed 20m/s
40
35 DSR speed 2m/s
30
25 AODV speed 2m/s
20
15 DSDV speed 2m/s
10
5
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Normalized Routing Load ( 30 sources)
14 DSR speed 20m/s
12
AODV speed 20m/s
10
DSDV speed 20m/s
DSR speed 2m/s

6
AODV speed 2m/s

4
2 DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 3.9: (g) Normalized Routing load at movement speed (2m/s and 20m/s) and
86
14
12 DSR speed 20m/s
10 AODV speed 20m/s
8 DSDV speed 20m/s
DSR speed 2m/s

6
AODV speed 2m/s

4
DSDV speed 2m/s

2
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.9: (h) Normalized Routing load at movement speed (2m/s and 20m/s) and

75
70
65 DSR speed 20m/s
60
55 AODV speed 20m/s
50
45 DSDV speed 20m/s
40
35 DSR speed 20m/s
30
25 AODV speed 20m/s
20
15 DSDV speed 20m/s
10
5
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.9: (i) Normalized Routing load at movement speed (2m/s and 20m/s) and
87
3.7.4. Routing Overhead Comparison

The routing overhead as shown in figures 3.10 (a, d and g) is the number of routing
overhead packets generated by routing protocols to achieve this level of data packet
delivery. At the lower movement speed of 2 meter/second for 10 sources the DSR
and DSDV are plotted on the same scale like each other, but AODV is plotted on a
different scale to best show the effect of pause time and offered load on overhead.
DSR and AODV are on-demand routing protocols, so as the number of sources
increases, we expect the number of routing packets sent to increase because there are
more destinations to which the network must maintain working routes.
In figures 3.10 (a, d and g) at the higher movement speed of 20 meter/second, the
DSR, DSDV and AODV with 10 sources are plotted on the same scale as each other
as shown in figure 3.10 (a), but in figures 3.10 (d and g) DSDV is plotted on a low
routing overhead packets generated to achieve this level of data packet delivery at 20
and 30 sources with comparison of routing overhead for DSR and AODV protocols.
The routing overhead as shown in figures 3.10 (b, e and h) is the number of routing
delivery. At the lower movement speed of 2meter/second for 10 sources the AODV,
DSR and DSDV are plotted on a the same scale like each other as shown in figures
3.10(b), but AODV is plotted on different scale to best show the effect of pause time
and offered load on overhead was higher routing overhead as shown in figure 3.10 (e
and h) as the number of sources 20 and 30, we expect the number of routing packets
sent to increase because there are more destinations to which the network must
maintain working routes. In all cases, the DSDV is lower routing overhead as shown
in figures 3.10 (b, e and h).
In figures 3.10 (b, e and h) at the higher movement speed of 20 meter/second, the
DSR, DSDV and AODV with 10 sources are plotted on a the same scale like each
other as shown in figure 3.10 (b) at pause time 100s to 500s with 10 sources. But in
figures 3.10 (e and h) DSDV is plotted on a low routing overhead packets generated
to achieve this level of data packet delivery at 20 and 30 sources with comparison of
routing overhead for DSR and AODV protocols. Where as DSR as shown in figures
3.10 (e and h) is plotted on a higher routing overhead packets generated at pause time
0s to 150s data packet delivery at 20 and 30 sources with comparison of routing
overhead AODV protocol. Where as AODV as shown in figures 3.10 (e and h) is
plotted a higher routing overhead packets generated at pause time 200s to 500s data
packet delivery at 20 and 30 sources with comparison of routing overhead DSR
protocol.
c) - Simulation time 900 seconds
The number of routing overhead packets generated by routing protocols as shown in
figures 3.10 (c, f and i) to achieve this level of data packet delivery.
At the lower movement speed of 2meter/second for 10 sources the DSR are plotted on
the lower overhead as shown in figure 3.10 (c), but DSDV is plotted higher overhead.
Where as at 30 sources as shown in figure 3.10 (i), the DSR and DSDV have a very
similar scale plotted at pause time 100s to 800s and the DSR are plotted the lower
overhead, but AODV is plotted higher overhead at 30 sources as shown in figure 3.10
(i). In figures 3.10(c, f and i) at the higher movement speed of 20 meter/second, the
DSR, DSDV and AODV with 10 sources are plotted on a the same scale like each
other as shown in figure 3.10(c), but in figure 3.10 (i) DSDV is plotted on a low
routing overhead packets generated to achieve this level of data packet delivery at 30
88
sources with comparison of routing overhead for DSR and AODV protocols. But the
AODV, DSR and DSDV have a very similar scale plotted at pause time 500s to 900s
at lower nodes mobility speed.
Routing Over head (10 sources)
4800
DSR speed 20m/s
4000
AODV speed 20m/s
Routing Overhead(packets)
3200
DSDV speed 20m/s
2400
DSR speed 2m/s
1600
ADOV speed 2m/s
800
DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 3.10: (a) Routing Overhead at movement speed (2m/s and 20m/s) and
Routing Over head(10 sources)
120000
DSR speed 20m/s
110000
100000
AODV speed 20m/s

90000
80000 DSDV speed 20m/s

70000
60000 DSR speed 2m/s

50000
40000 AODV speed 2m/s

30000
20000
DSDV speed 2m/s
10000
0 100 200 300 400 500

Pause Time(sec)
Figure 3.10: (b) Routing overhead at movement speed (2m/s and 20m/s) and
89

450000
DSR speed 20m/s

400000
350000
AODV speed 20m/s
Routing Overhead (packets)
300000
DSDV speed 20m/s
250000
150000
AODV speed 2m/s
100000
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.10: (c) Routing overhead at movement speed (2m/s and 20m/s) and

20000
18000 dsr speed 20m/s
16000
ADOV speed 20m/s
14000
10000
DSR speed 2m/s
8000
6000 ADOV speed 2m/s
4000
DSDV speed 2m/s
2000
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.10: (d) Routing overhead at movement speed (2m/s and 20m/s) and
90
Routing Over head(20 sources)

200000

160000
120000
DSR speed 2m/s
100000
80000
AODV speed 2m/s
60000
40000
DSDV speed 2m/s
20000
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.10: (e) Routing overhead at movement speed (2m/s and 20m/s) and

450000
350000
AODV speed 20m/s

300000
DSDV speed 20m/s
250000
150000
AODV speed 2m/s
100000
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.10: (f) Routing overhead at movement speed (2m/s and 20m/s) and
91
Routing Overhead (30 sources)

20000
DSR speed 20m/s

18000
16000
AODV speed 20m/s
14000
DSDV speed 20m/s
12000
8000
ADOV speed 2m/s
6000
2000
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.10: (g) Routing overhead at movement speed (2m/s and 20m/s) and
Routing Overhead(30 sources)

200000

Routing Overhead(sec)
160000
120000
DSR speed 2m/s
100000
80000
AODV speed 2m/s
60000
40000
DSDV speed 2m/s
20000
0
0 100 200 300 400 500
Pause Time(sec)
Figure 3.10: (h) Routing overhead at movement speed (2m/s and 20m/s) and
92
Routing Overhead (30 sources)
DSR speed 20m/s

480000
ADOV speed 20m/s

400000
DSDV speed 20m/s

320000
80000
DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 3.10: (i) Routing overhead at movement speed (2m/s and 20m/s) and
3.7.5. Drop Packets at Routing Overhead

The drop Packets at routing overhead and lower movement speed of 2meter/second as
shown in figures 3.11 (a, c and e) is the number of drop Packets at routing overhead
packets generated by routing protocols to achieve this level of data packet delivery. At
the lower movement speed of 2 meter/second for 10, 20 and 30 sources the DSR and
DSDV are plotted on the same scale as each other are low drop packets as shown in
figures 3.11 (a, c and e), but AODV is plotted on a different scale as shown in the
effect of the pause time and offered drop packets on overhead. At the higher
movement speed of 20meter/second as shown in figures 3.11(a, c and e), for 10 and 20
sources the DSR and DSDV are plotted on a the same scale as each other are low drop
packets as shown in figures 3.11 (a, c and e), but AODV is plotted on a different scale
as shown the effect of the pause time and offered drop packets on overhead. But for
30 sources the DSR and DSDV are plotted on a different scale as low drop packets,
but AODV is plotted on different scale as shown in figure 3.11 (e). Also see the
different compression between movement speed of 2m/s and 20m/s for AODV
protocol at the higher movement speed of 20meter/second as shown in figures 3.11 (a,
c and e), the drop packets at routing overhead for increasing pause time to higher
where lower mobility see low drop Packets at routing overhead with compared for the
lower movement speed of 2meter/second.
In all cases, at the lower movement speed of 2meter/second and higher movement
speed of 20meter/second the AODV protocol is higher drop packets at routing
overhead than DSR and DSDV protocols as shown in figures 3.11 (b, d and f) with
the factor increasing a growing number of sources. The drop packets at routing
overhead are lower in DSDV at 10, 30 sources as compared to both DSR and ADOV
as shown in figures 3.11 (b and f).
93
Drop packets at Routing Over head (10 sources)
480
Drop packets at Routing Over head (packets)
DSR speed 20m/s
400
DSDV speed 20m/s
320
AODV speed 20m/s
240
DSR speed 2m/s
160
DSDv speed 2m/s
80
AODV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Tim e (sec)
Figure 3.11: (a) Drop packets at routing overhead at movement speed (2m/s and
20000
DSR speed 20m/s
18000
Drop packets at Routing Over head

14000
AODV speed 20m/s
(packets)
12000
8000
DSDV speed 2m/s
6000
4000
AODV speed 2m/s
2000
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.11: (b) Drop packets at routing overhead at movement speed (2m/s and
94
630 DSR speed 20m/s

Drop packets at Routing Over head (packets)
540
DSDV speed 20m/s
450
AODV speed 20m/s
360
DSR speed 2m/s

270
180 DSDV speed 2m/s
90
Aodv speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.11: (c) Drop packets at routing overhead at movement speed (2m/s and

18000
14000
AODV speed 20m/s
(packets)
12000
8000
DSDV speed 2m/s
6000
2000
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.11: (d) Drop packets at routing overhead at movement speed (2m/s and
95
880
800 DSR speed 20m/s
Drop packets at Routing Over head(packets)
720
DSDV speed 20m/s
640
560 ADOV speed 20m/s
480
400 DSR speed 2m/s
320
DSDV speed 2m/s
240
160 AODV speed 2m/s
80
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.11: (e) Drop packets at routing overhead at movement speed (2m/s and
Drop packets at Routing Over head (30sources)

18000

14000
AODV speed 20m/s
12000
(packets)

8000
DSDV speed 2m/s
6000
2000
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.11: (f) Drop packets at routing overhead at movement speed (2m/s and
96
3.7.6. Drop Packets at End of Simulation Time Comparison

The drop packets at end of simulation time at the lower and higher movement speeds
of 2m/s and 20m/s as shown in figures 3.12 (a , c and e), were low in AODV as
compared to both DSR and DSDV protocols figures 3.12 (a , c and e). The DSR and
DSDV at the higher movement speed of 20meter/second have a very similar scale
plotted of drop packets at increasing of 40s pause times (higher mobility) at 10 and 20
sources as shown in figures 3.12 (a and c). Nearly all of the dropped packets are lost
at end of simulation time.
The drop packets at end of simulation time at the lower and higher movement speeds
of 2m/s and 20m/s were low in AODV as compared to both DSR and DSDV
protocols as shown in figures 3.12 (b , d and f), which the DSR protocol is higher in
all cases.
Drop packets at End of simulation Time (10 sources)

300
DSR speed 20m/s
250
DSDV speed 20m/s
Drop packets(packets)
200
AODV speed 20m/s
150
DSR speed 2m/s
100
DSDV speed 2m/s
50 AODV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.12: (a) Drop packets at end of simulation time at movement speed (2m/s and
97
Drop packets at End of simulation time (10 sources)

600
DSR speed 20m/s
500
DSDV speed 20m/s
Drop packets (packets)
400
AODV speed 20m/s
300
DSR speed 2m/s
200
DSDV speed 2m/s
100
AODV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.12: (b) Drop packets at end of simulation time at movement speed (2m/s and

300
DSR speed 20m/s

250
DSDV speed 20m/s
200
ADOV speed 20m/s
150
DSR speed 2m/s
100
DSDV speed 2m/s
50
AODV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.12: (c) Drop packets at end of simulation time at movement speed (2m/s and
98
Drop packets at End of simulation time (20sources)

600
DSR speed 20m/s
500
DSDV speed 20m/s
400
AODV speed 20m/s
300
DSR speed 2m/s
200
DSDV speed 20m/s
100
AODV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.12: (d) Drop packets at end of simulation time at movement speed (2m/s and
500
450 DSR speed 20m/s
400
DSDV speed 20m/s

350
300
AODV speed 20m/s
250
200 DSR speed 2m/s
150
DSDV speed 2m/s
100
50 ADOV speed 2m/s

0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 3.12: (e) Drop packets at end of simulation time at movement speed (2m/s and
99
56000
DSDV speed 20m/s

48000
AODV speed 20m/s
40000
24000
DSDV speed 2m/s
16000
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 3.12: (f) Drop packets at end of simulation time at movement speed (2m/s and
3.7.7. Performance Analysis

The simulation results bring out some important characteristic differences between the
routing protocols. The presence of high mobility implies frequent link failures and
each routing protocol reacts differently during link failures. The different basic
working mechanism of these protocols leads to differences in performance. The lower
and higher movement speeds of 2m/s and 20m/s, with differences simulation times
(100s and 900s), when the number of sources is low, the performance of DSR and
AODV is similar regardless of mobility. With large numbers of sources, AODV starts
outperforming DSR for high-mobility scenarios. As the data from the varying sources
demonstrate, AODV starts outperforming DSR at a lower load with a larger number
of nodes. DSR always demonstrates a lower routing load than AODV. The major
contribution to AODV routing overhead is from route requests, while route replies
constitute a large fraction of DSR routing overhead. Furthermore, AODV has more
route requests than DSR. At the higher movement speed of 20 meter/second, in figure
3.7(g, h and i) DSDV is plotted a low routing overhead packets generated to achieve
this level of data packet delivery at 30 sources with comparison of routing overhead
for DSR and AODV protocols. DSDV fails to converge below lower pause times. At
higher rates of mobility (lower pause times), DSDV does poorly, dropping to a 70%
packet de-livery ratio at the lower movement speeds of 2m/s and 20% packet delivery
ratio at the higher movement speeds of 20m/s for simulation time 100s , where at
simulation time 900s dropping to a 90% packet delivery ratio at the lower movement
speeds of 2m/s and 70% packet delivery ratio at the lower movement speeds of 20m/s.
Nearly all of the dropped packets are lost because a stale routing table entry directed
them to be forwarded over a broken link. DSDV maintains only one route per
destination and consequently, each packet that the MAC layer is unable to deliver is
dropped since there are no alternate routes. For DSR and AODV, packet delivery ratio
100
is independent of offered traffic load, with both protocols delivering between 85% and
100% of the packets in all cases at simulation time 100s, where at simulation time
900s with the lower movement speeds of 2m/s both protocols delivering between 90%
and 100% of the packets in all cases and with the higher movement speeds of 20m/s
both protocols delivering between 80% and 100% of the packets for 10 sources,
where DSR protocol delivering between 30% and 100% of the packets as shown in
figure 3.7(a, b and c). Since DSDV uses the table-driven approach of maintaining
routing information, it is not as adaptive to the route changes that occur during high
mobility. In contrast, the lazy approach used by the on-demand protocols, AODV and
DSR to build the routing information as and when they are created make them more
adaptive and result in better performance (high packet delivery fraction and lower
average end-to-end packet delays).
3.7.7.1 Effect of Mobility

In the presence of high mobility, link failures can happen very frequently. Link
failures trigger new route discoveries in AODV since it has at most one route per
destination in its routing table. Thus, the frequency of route discoveries in AODV is
directly proportional to the number of route breaks. The reaction of DSR to link
failures in comparison is mild and causes route discovery less often. The reason is the
abundance of cached routes at each node. Thus, the route discovery is delayed in DSR
until all cached routes fail. But with high mobility, the chance of the caches being
stale is quite high in DSR. Eventually when a route discovery is initiated, the large
number of replies received in response is associated with high MAC overhead and
causes increased interference to data traffic. Hence, the cache staleness and high
MAC overhead together result in significant degradation in performance for DSR in
high mobility scenarios.
In lower mobility scenarios, DSR often performs better than AODV, because the
chances of finding the route in one of the caches is much higher. However, due to the
constrained simulation environment (lesser simulation time and lesser mobility
models), the better performance of DSR over AODV couldn’t be observed, where in
higher mobility scenarios the routing overhead of DSDV protocol perform better than
AODV and DSR.
3.7.7.2 Routing Load Effect:

DSR has a lower routing load in all cases of 10, 20 sources than AODV and DSDV
protocols. This can be attributed to the caching strategy used by DSR, DSR which is
more likely to find a route in the cache, and hence resorts to route discovery less
frequently than AODV and DSDV.
3.8. Summary:
The researcher has chosen three existing ad-hoc routing protocols (DSR, AODV
and DSDV) to understand routing principles in a MANET. It is a good idea to take a
look at a brief overview of examined least-cost algorithms that are a central part of
routing in packets in networks and conventional routing algorithms such as distance
vector, link state and flooding routing. This is because many of the routing protocols
for a MANET have roots in traditional routing concept as underlying algorithm. In
mobile ad-hoc networks, routing protocols are classified of routing protocols in
MANET which can be done in many ways, but most of these are done depending on
101
the routing strategy and network structure, as flat routing, hierarchical routing and
geographic position assisted routing. The simulation results have shown that:
 There certainly is a need for a special ad-hoc routing protocol when mobility
increases. More conventional routing protocols like DSDV have a dramatic
decrease in performance when mobility is high. Two of the proposed protocols
are DSR and AODV. They perform very well when mobility is high.
However, the researcher has found that a routing protocol that entirely
depends on messages at the IP-level will not perform well. Some sort of
support from the lower layer, for instance link failure detection or neighbor
discovery is necessary for high performance. The size of the network and the
offered traffic load affects protocols based on source routing, like DSR, to
some extent. A large network with many mobile nodes and high offered load
will increase the overhead for DSR quite drastically. In these situations, a hop-
by-hop based routing protocol like AODV is more desirable.
 The simulations have shown that there certainly is a need for a special ad-hoc
routing protocol when the mobility increases. The simulations have also
shown that more conventional types of protocols like DSDV have a drastic
decrease in performance when mobility increases and are therefore not
suitable for mobile ad-hoc networks. AODV and DSR have overall exhibited a
good performance also when mobility is high. DSR is however based on
source routing, which means that the overhead in each packet can affect the
overhead in the network quite drastically when the load offered to the network
and the size of the network increases. In these situations, a hop-by-hop based
routing protocol like AODV is more desirable. One advantage with the source
routing approach is however that in its route discovery operation it learns more
routes. Source routing is however not desirable in ordinary forwarding of data
packets because of the large overhead.
 Another key aspect when evaluating these protocols is to test them in realistic
scenarios. the researcher has tested them in 38 types of scenarios. DSR had the
best performance, but the large overhead caused by the source route in each
packet makes AODV a good alternate candidate. It has almost as good
performance.
 DSR & AODV PDF is in the range of 95%-100% at lower rate of mobility for
all SIMT.
 DSR & AODV PDF is in the range of 95%-100% at lower rate of mobility for
all SIMT.
 DSDV: PDF is in the range of 70%-90% at lower rate of mobility with
10sources of each SIMT (100s, 500s, and 900s).
 DSR & AODV good output performance than DSDV protocol for each SIMT.
 DSR & AODV the PDF is not good performance in higher mobility with
increase number of sources for each SIMT, where as at SIMT 500s :
- AODV PDF= 70%-92%.
- DSR PDF= 20%-97%.
- DSDV PDF= 58%-92%.
So AODV outperforms DSR, however, consistently generates less routing
load than AODV. The poor performances of DSR are mainly attributed to
aggressive use of caching, and lack of any mechanism to expire stale
routes or determine the freshness of routes when multiple choices are
available. Aggressive caching, however, seems to help DSR at low loads
and also keeps its routing load down.
102
 The average end-to-end delay of packet delivery at the lower mobility was
higher in AODV as compared to both DSR and DSDV at SIMT 100s with 10
sources
• DSDV was lower average end-to-end delay of packet delivery at the lower
mobility.
• DSR was higher average end-to-end delay of packet delivery at the higher
mobility.
• Note: the average end-to-end delay of packet delivery was sensitive of
different (SMIT and mobility).
• In all cases at lower mobility, DSR has lower normalized routing load than
AODV and DSDV at higher mobility lower with 10,20 sources.
• At lower mobility the normalized routing load was higher in DSDV at 10
sources as compared to both DSR and ADOV for all different SIMT.
• At lower mobility the normalized routing load at 20 and 30 sources was higher
in ADOV as compared to both DSR and DSDV.
 DSDV has lower normalized routing load at higher and lower mobility with
increasing grow number of sources 30.
 AODV has higher routing overhead at lower & higher mobility with 10, 20
sources.
 DSR has higher routing overhead at lower & higher mobility with 30 sources
 DSDV has lower routing overhead at lower & higher mobility with 30 sources
 The Drop packets at routing overhead in all cases were higher in AODV.
 In all case AODV has lower drop packets at end of simulation time.
 DSDV, each node maintains routing information for all known destinations.
 DSDV, connectivity information needs periodical update throughout the whole
network, do the best performance when node mobility rate and movement
speed are low.
 DSDV, approximately constant overhead.
 DSDV, packet loss is mainly caused by stale routing entries.
 DSDV is effective for creating ad-hoc networks for small of mobile nodes.
 AODV & DSR are effective for creating ad-hoc networks for large of mobile
nodes.
 DSDV limits the number of nodes that can join the network.
 DSDV, when every topology of a network changes, DSDV is unstable until
update packets propagate through the network.
 DSDV need of bandwidth and the size of tables grow simultaneously with
mobility and number of nodes.
- Overhead for maintaining and updating tables will increase.
- Heavy routing overhead will degrade the performance of network
- Traffic overhead even if there is no change in network topology
- Overhead: most routing information never used.
 DSDV, maintains routes which are never used.
 DSDV, no sleeping nodes, where routing information must be updated
periodically
 DSR & AODV, good performance at all mobility rates
 AODV overhead is higher and still requires transmission of many routing
overhead packets.
 AODV higher drop packet routing overhead drops.
103
 For sending data to a particular destination, there is no need to find a route as

DSDV routing protocol maintains all the routes in the routing tables for each
node, while AODV has to find a route before sending a data.
 DSR strengths are manifest at :
- Routes are set up and maintained only between nodes that need to
communicate.
- Route caching can further reduce the effort of route discovery.
- A single route discovery may provide several routes to the destination.
 DSR weaknesses are manifest if route requests were tend to flood the network
and generally reach all the nodes of the network.
 DSR weaknesses include source routes in data packet headers, because the
source routing, the packet header size grows with the route length.
 Large packet headers in DSR risk of poor performance if the number of hops
is high.
 DSDV is a proactive routing protocol, which maintains routes to each and
every node in the network, while AODV is a reactive routing protocol which
finds the path on demand or whenever the route is required.
 Broadcasting in DSDV is done periodically to maintain routing updates and in
AODV, only hello messages are propagated to their neighbors to maintain
local connectivity.
 DSDV routing algorithm maintains a sequence number concept for updating
the latest information for a route. Even, the same concept is adapted by AODV
routing protocol.
 The periodic updates being broadcasted in DSDV bandwidth are wasted when
the nodes are stationary. But, this is not the case with AODV, as it propagates
only hello messages to its neighbors.
 For sending data to a particular destination, there is no need to find a route as
DSDV routing protocol maintains all the routes in the routing tables for each
node, while AODV has to find a route before sending a data.
 Overhead in DSDV is more when the network is large and it becomes hard to
maintain the routing tables at every node. But, in AODV overhead is less as it
maintains small tables to maintain local connectivity.
 DSR has the advantage of learning routes by scanning for information in
packets that are received. A route from A to C through B means that A learns
the route to C, but also that it will learn the route to B. The source route will
also mean that B learns the route to A and C and that C learns the route to A
and B. This form of active learning is very good and reduces overhead in the
network. However, each packet carries a slight overhead containing the source
route of the packet. This overhead grows when the packet has to go through
more hops to reach the destination. So the packets sent will be slightly bigger,
because of the overhead.
 DSDV cannot handle mobility at high speeds due to lack of alternative routes,
hence, routes in routing table is stale. While in AODV this is the other way, as
it finds the routes on demand.
 DSR has support for unidirectional links by the use of piggybacking the source
route a new request.
 DSR uses the key advantage of source routing. Intermediate nodes do not need
to maintain up-to-date routing information in order to route the packets they
forward. There is also no need for periodic routing advertisement messages,
104
which will lead to reduce network bandwidth overhead, particularly during

periods when little or no significant host movement is taking place. Battery
power is also conserved on the mobile hosts, both by not sending the
advertisements and by not needing to receive them; a host could go down to
sleep instead.
 Throughput decreases comparatively in DSDV as it needs to advertise periodic
updates and even-driven updates. If the node mobility is high, occurrence of
event driven updates are more. But in AODV it doesn’t advertise any routing
updates and hence the throughput is stable.
105
Chapter 4
Performance Analysis of Secure

Routing Algorithm for Ad-hoc
Sensor Mobile Network
106
Chapter 4
Performance Analysis of Secure Routing Algorithm for
Ad-hoc Sensor Mobile Network
4.1. SEAD Routing Protocol

Secure efficient ad-hoc distance vector routing protocol (SEAD) is designed based on
the DSDV protocol, as described in chapter 2 section 2.4.4.1, SEAD was proposed by
Yih-Chun Hu, David B. Johnson and Adrian Perrig, [Yih-Chun, David, Adrian;
WMCSA ,2002] [55].
DSDV: Destination Sequenced Distance Vector routing protocol is one of the first
protocol proposed for ad-hoc wireless networks. It was developed based on the
distributed Bellman-Ford algorithm where each node maintains a table that contains
the shortest distance and the first node on the shortest path to every other node in the
network. It is a table driven routing protocol. Routes to all destinations are readily
available at every node at all times. The tables are exchanged between neighbors at
regular intervals to keep an up-to-date view of the network topology. Whenever there
is a change in the network topology, the table entries are updated. We discussed the
working principle of DSDV in Chapter 3 section 4.4.
Consider the example as shown in the figure 4.1(a) and table 4.1 which illustrates the
dynamic network topology and table entry updates. The routing table entries for node
(1) as shown in tables 4.1(a), ‘Dest’ is the destination node, with node (1) as the
source node. Next node is the next neighbor node, to node (1) for that corresponding
destination node. The table entry distance is measured as a hop count, (i.e. how many
nodes are in between the source and destination node including the destination node).
The distance metric shows the routing length for that destination node. The sequence
number entry in the routing table corresponds to the number encapsulated in each
routing table update message. At a given time, all nodes try to keep the routing table
entries with the highest known sequence number. Figure 4.1 (a) shows ad-hoc
network with 12 nodes participating in the network. Let us consider that node (1) is
the source node and node 12 is the destination node. Table 4.1 (a) shows the table
entries of the node (1) and the shortest routes to all other nodes in the network. The
nodes communicate with each other if there is a change in the location of a particular
node. The changed node sends routing table update message with an increased
sequence number. The neighbor nodes propagate the update message to the whole
network with an increased sequence number. At any given time, all the nodes try to
keep the latest route information with respect to the dynamic topology of the network.
Figure 4.1 (b) shows the change in location of the node (9) in the example network
shown in figure 4.1 (a). Table 4.1 (b) shows the table entries for the node (1) with
respect to the change in network topology.
107
Figure 4.1 (a) Ad-hoc network with 12 nodes. (b) Ad-hoc network with change in
location of the node 9.
(a) (b)
Table 4.1: (a) Routing table node 1, (b) Routing table node 1 after topology change
SEAD used destination sequence numbers, as in DSDV; we also use these destination
sequence numbers to provide replay protection of routing update messages in SEAD.
SEAD incorporates One-Way Hash function to authenticate in the routing update
mechanism to enhance the routing security. A one-way hash chain is built on a one-
way hash function. Like a normal hash function, a one-way hash function, H, maps an
input of any length to a fixed-length bit string. Thus,
108
H :{0, 1}* →{0, 1}P
Where P is the length in bits of the output of the hash function, function H should be
simple to compute yet must be computationally infeasible in general to invert. A more
formal definition of one-way hash functions has many names: compression function,
contraction function, message digest, fingerprint, cryptographic checksum, message
integrity check (MIC), and manipulation detection code (MDC). Whatever one calls
it, it is central to modern cryptography. One-way hash functions are another building
block for many protocols [56]. To create a one-way hash chain, a node chooses a
random initial value x, where xє{0, 1}P and computes the list of values
h0, h1, h2, h3, h4,..…..hn
Where h0= x, and hi= H( ً◌hi-1) for 0 < i ≤ n, for some n.

The node at initialization generates the elements of its hash chain as shown above,
from (left to right) (in order of increasing subscript i) and then over time uses certain
elements of the chain to secure its routing updates. In using these values, the node
progresses from (right to left) (in order of decreasing subscript i) within the generated
chain.
Given an existing authenticated element of a one-way hash chain, it is possible to
verify elements later in the sequence of use within the chain (further to the ‘‘left’’, or
in order of decreasing subscript).
For example, given an authenticated hi value, a node can authenticate hi-3 by

computing H(H(H(hi-3)) verifying that the resulting value equals hi.
To use one-way hash chains for authentication, we assume some mechanism for a
node to distribute an authentic element such as hn from it hash chain is generated. A
traditional approach for this key distribution is for a trusted entity to sign public-key
certificates for each node; each node can then use its public-key to sign a new hash
chain element for itself. Let us consider ‘m’ is the number of nodes in the network, so
the upper bound for the hop counts is < m-1.
Let the hash chain values calculated using H be (h1, h2,..., hn), where n is divisible by
m, then for a routing table entry with sequence number i, let k=((n/m)-i). If the
metric j (distance) is used to authenticate the routing update entry, then h(km+j) is used
to authenticate the table update entry for that sequence number i and distance j.
Where 0 < i ≤ (m-1) and n=(m-1)×m. The group of elements used for routing
update with sequence number i is:
hkm, hkm+1, hkm+2, … , hkm+m-1
For example: seq =1 hn-m, hn-m+1, hn-m+2, … , hn-1

seq =2 hn-2m, hn-2m+1, hn-2m+2, … , hn-m-1
So that one-way hash chains, for example we use m=5, were i=sequence number, j=
distance, m=network diameter, n=length of hash chain as shown in table 4.2 one-way
hash chain elements are used for authentication in reverse order. as 0 < i ≤ (m-1) and
n = (m-1) × m = 20.
109
Note that from the above example a node generates its hash chain so that n is divisible
by m. When a node first enters the network, or after a node has used most of its
available hash chain elements, it can pick a new random x, generate a new hash chain
from this x, and send the new generated hn = h19 value to a trusted entity or an
alternative authentication and distribution service. Each node’s routing table is tagged
with the destination nodes address, next hop node address, hash value, sequence
number and metric as shown in figure 4.2
j
0 1 2 3 4
i
1 h15 h16 h17 h18 h19
2 h10 h11 h12 h13 h14
3 h5 h6 h7 h8 h9
4 h0 h1 h2 h3 h4
Table 4.2: Example of One-way hash chains
Figure 4.2: Ad-hoc networks with value of hash in routing table entries for nodes
110
In the example given above for sequence number i, the node sets the hash value in that
entry to its hkm= h15. If the node lists an entry for some other destination in that
update, it sets the (address in that entry to that destination nodes address, the metric
and sequence number) to the values for that destination in its routing table, and the its
hash value to the hash of the hash value received in the routing update entry from
which it learned that route to that destination.
So that nodes receiving any routing update can easily authenticate each entry in the
update, given any earlier authentic hash element from the same hash chain, the group
of elements used for routing update with sequence number i is:
hkm, hkm+1, hkm+2, … , hkm+m-1
A malicious node can modify h(km+j) only if it knows the value of h(km+j-1), which is
impossible to calculate. So the hashing technique is used to authenticate the nodes
participating in the ad-hoc network.
The attacker can never forge better distances or sequence numbers, attacker can only
generate worse distances or sequence numbers, however, other information such as
node name or next hop can be forged.
They differ from DSDV in that they do not use an average weighted settling time in
sending triggered updates. To reduce the number of redundant triggered updates, each
node in DSDV tracks, for each destination, the average time between when the node
receives the first update for some new sequence number for that destination, and when
it receives the best update for that sequence number for it (with the minimum metric
among those received with that sequence number), when deciding to send a triggered
update, each DSDV node delays any triggered update for a destination for this
average weighted settling time, in the hope of only needing to send one triggered
update, with the best metric, for that sequence number. SEAD does not use such a
delay, in order to prevent attacks from nodes that might maliciously not use the delay.
Since a node selects the first route it receives with highest sequence number and
lowest metric as shown in figure 4.3, an attacker could attempt to cause more traffic to
be routed through itself, by avoiding the delay in its own triggered updates. Such an
attack could put the attacker in a position to eavesdrop on, modify, or discard other
nodes' packets.
In addition, unlike DSDV, when a node detects that its next-hop link to some
destination is broken, the node does not increment the sequence number for that
destination in its routing table when it sets the metric in that entry to infinity as shown
in figure 4.4.
Since higher sequence numbers take priority, this node's routing update with this
new sequence number must be authenticated, but we did not include a mechanism for
authenticating these larger sequence numbers. Instead, the node flags its routing table
entry for this destination to not accept any new updates for this same sequence
number, effectively preventing the possible routing loop.
111
Figure 4.3: Ad-hoc networks with node(A) send update
Figure 4.4: Ad-hoc networks with node B detect broken link
112
4.2. Results of Smulation & Performance Analysis of Ad-hoc Secure

Routing Protocol
An attempt was made to implement SEAD: Secure efficient ad-hoc distance vector
routing protocol in Ns-2 simulator with environment of attacker and compare with the
DSDV under the same simulation environment, the same movement models were
used, number of traffic sources was fixed in table 3.2, maximum speed of the nodes
was set to at the lower movement speed of 2meter/second and at the higher movement
speed of 20meter/second, while pause time was varied as table 3.2 scenario for the
simulator Ns-2 experiments for protocol, with different simulation time (SIMT) 100s
and 900s simulated.
The results of our performance study of SEAD with DSDV are shown in figures 4.5,
4.6, 4.7, 4.8 and 4.9 below as a function of pause time in the random waypoint
mobility model with different simulation times, connectivity sources and lower and
higher movement speed of 2 meter/second and 20 meter/second using ns-2 simulator
with environment of attackers (reply, routing tables overflow, blackhole, warmhole).
The packet delivery ratios for SEAD and DSDV are shown in figure 4.5 below of
delivered application-level packets for these simulations are shown. Surprisingly,
SEAD consistently outperforms DSDV in terms of packet delivery ratio, but SEAD
also increases packet overhead (the number of transmissions of routing packets) and
normalized routing load (the number of routing packets transmitted per data packet
delivered at the destination. Each hop-wise transmission of a routing packet is counted
as one transmission) at the lower and higher movement speed of 2 meter/second and
20 meter/second, both due to this increased number of routing advertisements, and
due to the increase in size of each advertisement from the addition of the hash value
on each entry for authentication. This increased overhead is shown in figure 4.8
below. Where SEAD also lower scale plotted of average end-to-end delay of data
packets (this includes all possible delays caused by buffering during route discovery
latency, queuing at the interface queue, retransmission delays at the MAC, and
propagation and transfer times) as shown in figure 4.6 below than DSDV protocol.
Where SEAD protocol delivers a greater percentage of the originated data packets
when there is little node mobility (i.e., at large pause time), converging to 100%
delivery of SEAD protocol when there is no node motion with time simulation 100s.
in figures 4.5, 4.6, 4.7, 4.8 and 4.9 each graph represents the random way movement
and communication scenarios for the given pause time. At a pause time of 0s (on the
left-hand-side of each graph), all nodes in the network are in constant motion, and as
the pause time increases from left to right, the node movement rate in the network
decreases. at a pause time of 100second (on the right-hand-side of each graph), all
nodes are stationary, since each simulation was run for 100s and 900s simulated
seconds of operation of the ad-hoc network at the lower movement speed of 2m/s and
high movement speed of 20m/s.
4.2.1 Packet delivery Comparison

Packet delivery ratio is important as it describes the loss rate that will be seen by the
transport protocols, which in turn affect the maximum throughput that the network
can support. This metric characterizes both the completeness and correctness of the
routing protocol.
At the lower movement speed of 2m/s, the SEAD: Secure efficient ad-hoc distance
vector routing protocol performed particularly well, delivering over 95% of the data
113
packets regardless of mobility rate as shown in figures 4.5 (a , c and e) with the lower
movement speed of (2meter/second) for 10, 20, 30 and 40 sources. So for SEAD,
packet delivery ratio is independent of offered traffic load, delivering between 95%
and 100% of the packets.
The SEAD: Secure efficient ad-hoc distance vector routing protocol perform better
than the table-driven DSDV protocol. Where DSDV delivering over 70% of the data
packets regardless of mobility rate as shown in figures 4.5 (a , c and e) with the lower
movement speed of (2 m/s) for 10, 20 and 30, but DSDV loses about 50% more
packets than SEAD for lower 10s pause times (higher mobility) at 10 and 20 sources.
Nearly all of the dropped packets are lost because a stale routing table entry directed
them to be forwarded over a broken link.
At the higher movement speed of 20 meter/second as shown in figures 4.5 (a , c and
e), the SEAD: Secure efficient ad-hoc distance vector routing protocol performed
particularly well, delivering over 70% of the data packets regardless of the mobility
rate at pause time 0s as shown in figures 4.5(a , c and e) with the high movement
speed of (20 meter/second) for 10, 20 and 30 sources, where as at high pause times
with lower mobility it delivers over 80% of the data packets. So for SEAD, packet
delivery ratio is independent of offered traffic load, with both protocols delivering
between 70% and 85% of the packets at 10, 20 and 30 sources.
The SEAD: Secure efficient ad-hoc distance vector routing protocol perform better
than the table-driven DSDV protocol. the DSDV delivers 20% of the data packets
regardless of the mobility rate at pause time 0s as shown in figures 4.5 (a, c and e)
with the high movement speed of (20 meter/second) for 10, 20, 30 and 40 sources
while at high pause times with lower mobility it delivers over 70% of the data
packets, but DSDV loses about 40% more packets than SEAD for lower 40s pause
times (higher mobility) at 10, 20 and 30 sources. Nearly all of the dropped packets are
lost because a stale routing table entry directed them to be forwarded over a broken
link.
At the lower movement speed of 2 meter/second as shown in figures 4.5 (b, d and f),
the SEAD: Secure efficient ad-hoc distance vector routing protocol performed
particularly well, delivering over 95% of the data packets regardless of the mobility
rate as shown in figure 4.5 (b) with the lower movement speed of (2 meter/second)
for 10 sources, SEAD performed particularly well, delivering over 85% of the data
packets regardless of the mobility rate as shown in figures 4.5 (d and f) with the lower
movement speed of (2 meter/second) for 20 and 30 sources at pause time 800, with
another pause time are delivering 95% data packets of mobility rate. However, DSDV
delivers over 82% to 90% of the data packets regardless of the mobility rate as shown
in figures 4.5 (b, d and f) with the lower movement speed of (2 meter/second) for 10,
20 and 30 sources at lower pause times with higher mobility and 90% at higher pause
times with lower mobility. So for SEAD, packet delivery ratio is independent of
offered traffic load, delivering between 85% and 90% of the packets at 20 and 30
sources, but delivering between 92% and 98% of the packets at 10 sources.
At the higher movement speed of 20 meter/second as shown in figures 4.5 (b, d and f),
the SEAD: Secure efficient ad-hoc distance vector routing protocol 80% of the data
packets regardless of the mobility rate from pause time 0s to pause time 50s as shown
in figures 4.5 (b, d and f), with the high movement speed of (20 meter/second) for 10,
20 and 30 sources where very similar for DSDV protocol at pause time 300s to pause
time 900s as shown in figures 4.5(d and f) for pause times with lower mobility at 20
and 30 sources. However, in all cases SEAD delivers over 80% of the data, and
114
DSDV delivers over 65% of the data as shown in figures 4.5 (b, d and f), with the
higher movement speed of (20 meter/second) for 10, 20 and 30 sources at lower pause
times with higher mobility. But SEAD and DSDV are very similar at 300s to 900s
pause times, so that SEAD: Secure efficient ad-hoc distance vector routing protocol
perform better than the table-driven DSDV protocol. Where as DSDV delivers over
65% of the data packets regardless of the mobility rate with the high movement speed
of (20 m/s) for 10 sources.
8500
SEAD speed 20m/s

7500
6500
DSDV speed 20m/s

5500
4500
SEAD speed 2m/s

3500
2500
DSDV speed 2m/s

1500
500
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
1
# data pakets received/#data packets sent (packets)
0.9 SEAD speed 20m/s
0.8
0.7
DSDV speed 20m/s
0.6
0.5
0.4 SEAD speed 2m/s
0.3
0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
115
8500
SEAD speed 20m/s
7500
6500
DSDV speed 20m/s
5500
4500
SEAD speed 2m/s

3500
2500
1500
DSDV speed 2m/s
500
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
0.9
SEAD speed 20m/s

0.8
0.7
DSDV speed 20m/s
0.6
(packets)
0.5
0.4 SEAD speed 2m/s

0.3
0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
116
8500
SEAD speed 20m/s
7500
6500
DSDV speed 20m/s
5500
4500
SEAD speed 2m/s
3500
2500
DSDV speed 2m/s
1500
500
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
1
# data pakets received/#data packets sent (packets)

0.8
0.7
DSDV speed 20m/s
0.6
0.5
0.4 SEAD speed 2m/s
0.3
0.2
DSDV speed 2m/s
0.1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
117
4.2.2 Average End-End Delays Packet delivery

meter/second is higher in SEAD: Secure efficient ad-hoc distance vector routing
protocol as compared to DSDV in all cases as shown in figures 4.6 (a , c and e). But
SEAD is low than DSDV at pause time 0s as shown in figure 4.60(e) at 10 sources.
The average end-to-end delay of packet delivery at the higher movement speed of 20
meter/second is higher in DSDV as compared to SEAD: Secure efficient ad-hoc
distance vector routing protocol at the 20 and 30 sources as shown in figures 4.6(c and
e). But the SEAD protocol is higher at pause time 20s to 40s than DSDV protocol
with 10 sources as shown in figure 4.6(a), and from pause time 50s to 100s at the end
of simulation time are similar average end-to-end delay of both protocols (SEAD and
DSDV) at 10 sources.
meter/second is higher in SEAD: Secure efficient ad-hoc distance vector routing
protocol as compared to DSDV at pause time from 600s to 900s end simulation time
for the 10, 20 and 30 sources as shown in figures 4.6 (b, d and f) and SEAD in all case
is lower at pause time 300s.
The average end-to-end delay of packet delivery at the higher movement speed of 20
meter/second is higher in DSDV as compared to SEAD at the 10 sources as shown in
figure 4.6 (b) at pause time from 0s to 500s and higher from 700s to 900s as compared
to SEAD protocol at the 10 sources as shown in figure 4.6 (b).
In all cases, the SEAD is lower average end-to-end delay of packet delivery at pause
time 0s to 300s and from 800s to 900s as shown in figures 4.6 (b, d and f) at the
higher movement speed of 20 m/s.
0.8
0.7
DSDV speed 20m/s
0.6
0.5
SEAD speed 2m/s

0.4
0.3
0.2 DSDV speed 2m/s
0.1
0
0 10 20 30 40 50 60 70 80 90 100
Pause Tim e(sec)
Figure 4.6: (a) Average End-End delay at movement speed (2m/s and 20m/s) and
118
0.63
0.54
DSDV speed 20m/s
0.45
0.36
SEAD speed 2m/s
0.27
0.18
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 4.6: (b) Average End-End delay at movement speed (2m/s and 20m/s) and
SEAD speed 20m/s

0.8
DSDV speed 20m/s

0.6
0.4 SEAD speed 2m/s
0.2
DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 4.6: (c) Average End-End delay at movement speed (2m/s and 20m/s) and
119
0.72
SEAD speed 20m/s
0.63
0.54
DSDV speed 20m/s
0.45
0.36
SEAD speed 2m/s
0.27
0.18
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 4.6: (d) Average End-End delay at movement speed (2m/s and 20m/s) and
SEAD speed 20m/s

0.8
DSDV speed 20m/s

0.6
0.4 SEAD speed 2m/s
0.2
DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 4.6: (e) Average End-End delay at movement speed (2m/s and 20m/s) and
120
0.72
SEAD speed 20m/s
0.63
0.54
DSDV speed 20m/s
0.45
0.36
SEAD speed 2m/s
0.27
0.18
DSDV speed 2m/s

0.09
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 4.6: (f) Average End-End delay at movement speed (2m/s and 20m/s) and
4.2.3 Normalized Routing Load Comparison

In all cases, at the lower movement speed of 2meter/second, DSDV demonstrates
significantly lower routing load than SEAD: Secure efficient ad-hoc distance vector
routing protocol as shown in figures 4.7 (a, c and e) with the factor increasing a
growing number of sources.
In figures 4.7 (a, c and e) at the higher movement speed of 20meter/second, the SEAD
demonstrates significantly lower routing load than DSDV as figures 4.7 (a, c and e) at
pause time from 55s to 100s end of simulation time, it is higher at pause time from 5s
to 45s in all cases. But the DSDV demonstrates significantly lower routing load than
SEAD as shown in figures 4.7 (a, c and e) at pause time from 5s to 45s in all cases.
The normalized routing load at the lower movement speed of 2 meter/second, DSDV
protocol is lower routing load than SEAD: Secure efficient ad-hoc distance vector
routing protocol as shown in figures 4.7 (b, d and f) with the factor increasing a
growing number of sources. The normalized routing load was higher in SEAD as
compared to DSDV protocol.
The normalized routing load as shown in figures 4.7 (b, d and f), at the higher
movement speed of 20 meter/second, the SEAD: Secure efficient ad-hoc distance
vector routing protocol is higher routing load than DSDV protocol as shown in figures
4.7 (b, d and f) with the factor increasing a growing number of sources.
121
20
18
SEAD speed 20m/s
16
14
12 DSDV speed 20m/s
10
8
SEAD speed 2m/s
6
4
DSDV speed 2m/s
2
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
10
9
SEAD speed 20m/s
7
DSDV speed 20m/s
6
4 c SEAD speed 2m/s
2
DSDV speed 2m/s
1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
122

20
18
SEAD speed 20m/s
16
14
DSDV speed 20m/s
12
10
8 SEAD speed 2m/s

6
4
DSDV speed 2m/s
2
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)

10
9
SEAD speed 20m/s
8
7
DSDV speed 20m/s
6
4 SEAD speed 2m/s
2
DSDV speed 2m/s
1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
123
20
18
SEAD speed 20m/s
16
14
DSDV speed 20m/s
12
10
8 SEAD speed 2m/s
6
4
DSDV speed 2m/s
2
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)

10
9 SEAD speed 20m/s
8
7
DSDV speed 20m/s
6
4 SEAD speed 2m/s
2
DSDV speed 2m/s
1
0
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
124
4.2.4 Routing Overhead Comparison

The routing overhead as shown in figures 4.8 (a, c and e) is the number of routing
delivery.
In all cases, at the lower movement speed of 2 meter/second, DSDV demonstrates
significantly lower routing overhead than SEAD: secure efficient ad-hoc distance
vector routing protocol as shown in figures 4.8 (a, c and e) with the factor increasing a
growing number of sources.
In figures 4.8 (a, c and e) at the higher movement speed of 20meter/second, the SEAD
demonstrates significantly higher routing overhead than DSDV as shown in figures
4.8 (a, c and e) with the factor increasing a growing number of sources.
The routing overhead at the lower movement speed of 2 meter/second, DSDV
protocol is lower routing overhead than SEAD: Secure efficient ad-hoc distance
vector routing protocol as shown in figures 4.8 (b, d and f) with the factor increasing a
growing number of sources. The routing overhead was higher in SEAD as compared
to DSDV protocol.
The routing overhead as shown in figures 4.8 (b, d and f), at the higher movement
speed of 20 meter/second, the SEAD: secure efficient ad-hoc distance vector routing
protocol is higher routing overhead than DSDV protocol as shown in figures 4.8 (b, d
and f) with the factor increasing a growing number of sources.
8500
SEAD speed 20m/s

7500
6500
DSDV speed 20m/s

5500
4500
SEAD speed 2m/s

3500
2500
DSDV speed 2m/s

1500
500
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 4.8: (a) Routing overhead at movement speed (2m/s and 20m/s) and SIMT100s
with 10 sources.
125
49000
SEAD speed 20m/s

41000
33000
DSDV speed 20m/s
25000
SEAD speed 2m/s

17000
9000
DSDV speed 2m/s
1000
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 4.8: (b) Routing overhead at movement speed (2m/s and 20m/s) and SIMT900s
with 10 sources.
8500
SEAD speed 20m/s
7500
6500
DSDV speed 20m/s
5500
4500
SEAD speed 2m/s

3500
2500
1500
DSDV speed 2m/s
500
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 4.8: (c) Routing overhead at movement speed (2m/s and 20m/s) and SIMT100s
with 20 sources.
126
49000
SEAD speed 20m/s

41000
25000
SEAD speed 2m/s

17000
9000
DSDV speed 2m/s
1000
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
Figure 4.8: (d) Routing overhead at movement speed (2m/s and 20m/s) and SIMT900s
with 20 sources.
8500
SEAD speed 20m/s
7500
6500
DSDV speed 20m/s
5500
4500
SEAD speed 2m/s
3500
2500
DSDV speed 2m/s
1500
500
0 10 20 30 40 50 60 70 80 90 100
Pause Time(sec)
Figure 4.8: (e) Routing overhead at movement speed (2m/s and 20m/s) and SIMT100s
with 30 sources.
127

49000
SEAD speed 20m/s

41000
33000
DSDV speed 20m/s
25000
SEAD speed 2m/s

17000
1000
0 100 200 300 400 500 600 700 800 900
Pause Time(sec)
with 30 sources
4.2.5 Drop Packets at End Time of Simulation Comparison

The drop packets at end simulation time at the lower and higher movement speeds of
2 m/s and 20 m/s as shown in figures 4.9 (a, c and e) were lower in SEAD: secure
efficient ad-hoc distance vector routing protocol as compared to DSDV protocol.
Nearly all of the dropped packets are lost at the end of simulation time.
The drop packets at end simulation time at the lower and higher movement speeds of
2 m/s and 20 m/s were lower in SEAD: Secure efficient ad-hoc distance vector
routing protocol as compared to DSDV protocol as shown in figures 4.9(b, d and f),
nearly all of the dropped packets are lost at the end of simulation time.
128
600
DSDV speed 20m/s

500
400 SEAD speed 20m/s
300
SEAD speed 2m/s
200
100 DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 4.9: (a) Drop packets at End of simulation time at movement speed (2m/s and
Drop packets at End time of simulation time (10 sources)

600
DSDV speed 20m/s

500
400 SEAD speed 20m/s
300
SEAD speed 2m/s

200
100 DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 4.9: (b) Drop packets at End of simulation time at movement speed (2m/s and
129
600
DSDV speed 20m/s

500
400
SEAD speed 20m/s
300
SEAD speed 2m/s

200
100
DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 4.9: (c) Drop packets at End of simulation time at movement speed (2m/s and

600
DSDV speed 20m/s

500
400
SEAD speed 20m/s
300
SEAD speed 2m/s

200
100
DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 4.9: (d) Drop packets at End of simulation time at movement speed (2m/s and
130

600
DSDV speed 20m/s

500
400
SEAD speed 20m/s
300
SEAD speed 2m/s

200
100
DSDV speed 2m/s
0
0 10 20 30 40 50 60 70 80 90 100
Pause Time (sec)
Figure 4.9: (e) Drop packets at End of simulation time at movement speed (2m/s and

600
DSDV speed 20m/s

500
400
SEAD speed 20m/s
300
SEAD speed 2m/s

200
100 DSDV speed 2m/s
0
0 100 200 300 400 500 600 700 800 900
Pause Time (sec)
Figure 4.9: (f) Drop packets at End of simulation time at movement speed (2m/s and
131
4.2.6 Security Analysis and Evaluation

Analysis and evaluation SEAD protocol (see figure 4.5) shows the results of the
performance metric, packet delivery ratio. A higher value of PDF indicates that most
of the packets are being delivered to the higher layers and is a good indicator of the
protocol performance. SEAD consistently outperforms DSDV in terms of packet
delivery ratio at lower pause times in the simulation. This shows that the route
discovery is faster in SEAD than in DSDV and the number of routing advertisements
sent by SEAD are more than DSDV. So at lower pause time SEAD contains more up
to date routing information than DSDV. At higher pause times, the PDF graph for
DSDV increases gradually. Figure 4.8 shows the simulation results of the
performance metric, packet overhead. Packet overhead graph for SEAD is higher than
in DSDV. PDF graph for SEAD plotted scale is the same scale and DSDV mostly the
same level but is lower scale value. Where as SEAD is higher because is increased
packet overhead in SEAD, due to this increased number of routing advertisements,
and due to the increase in size of each advertisement from the addition of the hash
value on each entry for authentication. This increased overhead as shown in figure 4.8
in SEAD causes some congestion in the network in these simulations, at all pause
times, due to the decreased available network capacity from the increased overhead in
SEAD. Figure 4.6 shows the simulation results of the performance metric, average
end-to-end delay. A higher value of end-to-end delay means that the network is
congested and hence the routing protocol doesn’t perform well. SEAD graph for AED
shows that at lower simulation time, AED values are lesser and they increase with the
increase in simulation pause time.
SEAD was developed based on DSDV and incorporates One-Way Hash function, to
authenticate in the routing update mechanism in order to enhance the routing security.
Securing a table driven protocol is harder than securing an on demand protocol due to
the existence of predefined routes. Distance vector protocols encapsulate the route
information into a hop count value and a next hop. An attacker cannot create a valid
route with a larger sequence number that it received due to the properties of hash
function.
From table 4.3, we can see that some types of security attacks are possible in SEAD
routing protocols with a compromised node we used in simulation environment of
attackers (reply, routing tables overflow, blackhole, warmhole). If no compromised
malicious nodes exist in the network, SEAD is robust against uncoordinated attack
patterns through neighbor authentication. Routing loops can only be possible when
there is more than one malicious node in the network. The confidentiality of the
network topology with respect to participating nodes is maintained with neighbor
authentication. The impersonation attacks a malicious node may impersonate another
node, while sending the control packets to create an anomaly update in the routing
table is not possible because the SEAD does not allow for new nodes to join the
network. The wormhole attacks are possible because can attacker records packets
(routing information) at one location in the network or from tunnel and re-transmits
the recorded data into the network, causes disrupts to the routing information. The
black hole attacks are possible because the attacker forms part of the network and
interferes in the route discovery phase of the routing protocol, by sending forged
routing packets the attacker routes all packets for another destination to itself. Routing
table overflow attacks are not possible because the attacker attempts to create routes
to nonexistent nodes. Replay attacks are possible old route advertisements are sent to
a node causing it to update its routing table with stale routes or record packets and re-
transmits. SEAD do not use an average weighted settling time in sending triggered
132
updates. To reduce the number of redundant triggered updates to prevent DoS attacks
by causing other attackers (reply, warmhole). Each node in DSDV tracks, for each
destination, the average time between when the node receives the first update for
some new sequence number for that destination, and when it receives the best update
for that sequence number for it (with the minimum metric among those received with
that sequence number), when deciding to send a triggered update, each DSDV node
delays any triggered update for a destination for this average weighted settling time,
in the hope of only needing to send one triggered update, with the best metric, for that
sequence number. SEAD does not use such a delay, in order to prevent attacks from
nodes that might maliciously not use the delay.
Since a node selects the first route it receives with highest sequence number and
lowest metric as shown in figure 4.3, an attacker could attempt to cause more traffic to
be routed through itself, by avoiding the delay in its own triggered updates. Such an
attack could put the attacker in a position to eavesdrop on, modify, or discard other
nodes' packets.
Attack patterns Ad-hoc Security SEAD Protocol

DoS No
reply Yes
Impersonation No
Blackhole No
Warmhole Yes
Routing tables overflow attacks No
Table 4.3: The attack patterns with SEAD protocol
4.1. Summary
In security is a fundamental issue that needs resolution before ad-hoc networks will
experience large scale deployment. The characteristics of mobile ad-hoc networks,
pose numerous challenges in achieving conventional security goals. Since the nodes
are responsible for basic network functions, like packet forwarding and routing,
network operations can be easily jeopardized if countermeasures are not integrated
into these network functions at the early stages of design, some existing routing
protocols given in Chapter (2,3) for mobile ad-hoc networks may be able to manage
the dynamic network topology of mobile ad-hoc networks, but none of these protocols
incorporate mechanisms to prevent, tolerate or defend against attacks from malicious
adversaries. Due to the close relationship between security and the characteristics of
ad-hoc networks these protocols will have to be fundamentally altered or redesigned
to effectively incorporate security mechanisms. This is clear if one considers the
number of secure routing protocols as (Ariadne, SEAD, ARAN, and SRP) that
followed in the secure routing protocols in MANET. Security support is of grave
importance to military communications.
The simulation results have shown that the securing ad-hoc environments are a
challenging task. The main purpose of this thesis was to acquire in depth knowledge
of ad-hoc routing protocols and secure routing protocols. Security evaluation of the
secure routing protocol is done using SEAD: secure efficient distance vector routing
for mobile wireless ad-hoc networks and implement the algorithm of protocol to
simulator network Ns-2 and performance evaluation of ad-hoc secure routing protocol
133
SEAD and compared with DSDV protocol was done with most commonly identified
performance metrics.
 SEAD: PDF is in the range of 90%-100% at lower rate of mobility with 10sources
of each SIMT (100s, 900s).
 DSDV: Packet delivery ratio is in the range of 70%-90% at lower rate of mobility
with 10sources of each SIMT (100s, 900s).
 SEAD: PDF is in the range of 70%-80% at higher rate of mobility with 10sources of
SIMT (100s).
 DSDV: PDF is in the range of 20%-69% at higher rate of mobility with 10sources
of SIMT (100s).
 SEAD: PDF is in the range of 80%-100% at higher rate of mobility with 10sources
of SIMT (900s).
 DSDV: Packet delivery ratio is in the range of 65%-98% at higher rate of mobility
with 10sources of SIMT (900s).
 So the SEAD good output performance than DSDV protocol for each Simulation
where the PDF is in the range of 90%-100% at higher rate of mobility with SIMT
900S at 100s 70%-80%. At lower mobility 90%-100% for each SIMT.
 The average end-to-end delay of packet delivery at the lower mobility SEAD higher
as compared to DSDV in all cases, but at higher mobility it was higher in DSDV as
compared to SEAD for each SIMT
 In all cases at the lower & higher mobility, DSDV lower normalized routing load
than SEAD.
 In all cases at the lower & higher mobility, the routing overhead packets generated
by routing protocol to achieve the level of data packet delivery, where as in SEAD
they are constant and higher as compared with DSDV protocol.
 In all cases at the lower & higher mobility, SEAD protocol has lower drop packets
at end of simulation time as compared with DSDV protocol, so nearly all of the
dropped packets are lost at end of simulation time.
 SEAD outperforms DSDV in terms of packet delivery ratio and at drop packets at
end of simulation time.
 SEAD does not allow for new nodes to join the network.
 SEAD use efficient one-way hash function to prevent sequence number and hop
count from being modified by malicious node.
 Hash chains are consumed very fast; these constructs would also satisfy the low
power requirement.
 SEAD is robust against uncoordinated attacks.
 SEAD is unable to defend against a simple collusion attack, involving two attacker
nodes, sharing information via a tunnel. (Sending the routing information as data).
This attack can be used to achieve a wormhole between the two bad nodes. This
causes a lot of communication to pass through them. This situation can then be
exploited. In the secure routing protocol, most of the security attacks are possible
with a compromised node. From the study results, it concludes that table driven
protocol is more prone to security attacks. The performance evaluation of SEAD
and DSDV shows that, SEAD out performs DSDV in all the performance metrics.
But it is important to see that at lower simulation pause times SEAD outperforms
DSDV. This is due to the routing mechanism involved in these protocols. SEAD
encapsulates routing information in routing tables, so at lower pause time SEAD out
performs DSDV.
134
Chapter 5
Conclusion and Future Work
135
Chapter 5
Conclusion and Future Work
5.1. Conclusion
This thesis first, compared the performance of DSDV, AODV and DSR routing
protocols for ad-hoc networks using ns-2 simulations and second, implemented secure
routing algorithm protocol of sensor MANET (SEAD) and compared to traditional
DSDV routing protocol with environment attackers, by performance analysis.
First: DSDV uses the proactive table-driven routing strategy while both AODV and
DSR use the reactive On-demand routing strategy. Both AODV and DSR perform
better under high mobility simulations than DSDV. High mobility results in frequent
link failures and the overhead involved in updating all the nodes with the new routing
information as in DSDV is much more than that involved in AODV and DSR, where
the routes are created as and when required.
DSR and AODV both use on-demand route discovery, but with different routing
mechanics. In particular, DSR uses source routing and route caches, and does not
depend on any periodic or timer-based activities. DSR exploits caching aggressively
and maintains multiple routes per destination. AODV, on the other hand, uses routing
tables, one route per destination, and destination sequence numbers, a mechanism to
prevent loops and to determine freshness of routes. The general observation from the
simulation is that for application-oriented metrics such as packet delivery ratio and
delay are DSR & AODV good output performance than DSDV protocol for each
SIMT. The PDF for DSR & AODV are not good performance in higher mobility with
the increase of the number of sources for each SIMT, where AODV PDF= 70%-92%,
DSR PDF= 20%-97%, DSDV PDF= 58%-92%, So AODV, outperforms DSR. DSR,
however, consistently generates less routing load than AODV. The poor performances
of DSR are mainly attributed to aggressive use of caching, and lack of any mechanism
to expire stale routes or determine the freshness of routes when multiple choices are
available. Aggressive caching, however, seems to help DSR at low loads and also
keeps its routing load down.
Second: Securing ad-hoc environments is a challenging task. The main purpose of this
thesis was to acquire in-depth knowledge of ad-hoc routing protocols and secure
routing protocol. Security evaluation of the secure routing protocol SEAD with
traditional routing protocol DSDV use the most commonly identified attack patterns
in ad-hoc networks. Performance evaluation of ad-hoc secure routing protocol SEAD
and DSDV was done with the most commonly identified performance metrics added
two new performance metrics. In the secure routing protocol, most of the security
attacks are possible with a compromised node. SEAD based on the design of the
destination-sequenced distance vector protocol. SEAD use efficient one-way hash
function to prevent sequence number and hop count from being modified by
malicious node and consumed very fast, These constructs would also satisfy the low
power requirement. SEAD is robust against uncoordinated attacks. SEAD does not
allow for new nodes to join the network.
From the simulation results, it is concluded that the performance evaluation of SEAD
and DSDV shows that, SEAD outperforms DSDV in all the performance metrics. But
it is important to see that at lower simulation pause times SEAD outperforms. This is
due to the routing mechanism involved in these protocols. SEAD encapsulates routing
information in routing tables, so at lower pause time SEAD good outperforms DSDV.
136
5.2. Future Work

In the future, extensive complex simulations could be carried out using this thesis
code, like comparison with:
• Different number of nodes.
• Different mobility models.
• In order to gain a more in-depth performance analysis of the ad-hoc routing
protocols and more routing protocols, for instance as Temporally Ordered
Routing Algorithm (TORA) protocol.
Security research in the area of ad-hoc secure routing protocols is still actively done.
Due to the time constraint and code limitations, the current work has only focused on
evaluating and analyzing secure routing protocol SEAD with some selected
performance metrics. The implementation and evaluation of other ad-hoc secure
routing protocol, like Ariadne work with some more performance metrics will be
considered as future research work.
137
References
[1]. Josh Broch, David A Maltz, David B Johnson, Yih-Chun Hu and Jorjeta
Jetcheva, A performance comparison of multi-hop wireless ad-hoc network
routing protocols. Proceedings of the Fourth Annual ACM/IEEE International
Conference on Mobile Computing and Networking, October 25–30, 1998.
[2]. Website: Wireless Security Courses, Useful Definitions,
http://www.kjhole.com/Definitions.html
[3]. J. Macker and S. Corson. Mobile ad-hoc networking (manet): Routing protocol
performance issues and evaluation considerations. University of Maryland,
Network Working Group Request for Comments: 2501, Jan 1999.
[4]. I.F. Akyildiz, W. Su, Y. Sankarasubramaniam and E. Cayirci. Wireless sensor
networks: a survey, Broadband and Wireless Networking Laboratory, School of
Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta,
GA 30332, USA, 20 December 2001.
[5]. Website: Ismail Akturk, Come491 GRADUATION PROJECT Wireless Sensor
Networks, Center for Computation & Technology, Louisiana State University,
USA, November 27- 2007, http://www.ismailakturk.com/wsn.html
[6]. Charles Perkins and Elizabeth Royer, Ad-hoc on-demand distance vector
routing. In Proceedings of the 2nd IEEE Workshop on Mobile Computing
Systems and Applications, New Orleans, LA, February 1999, pp. 90-100.
[7]. Elizabeth M. Royer and Charles E. Perkins. An Implementation Study of the
AODV Routing Protocol. Proceedings of the IEEE Wireless Communications
and Networking Conference, Chicago, IL, September 2000.
[8]. Charles E. Perkins and Pravin Bhagwat. Highly Dynamic Destination-
Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, IBM,
T.J.Watson Research Center, Computer Science Department university of
Maryland, 1994.
[9]. Chai-Keong Toh, Elizabeth M. Royer and Santa Babara. A review of current
routing protocols for ad-hoc mobile wireless networks, IEEE Personal
Communications, April 1999.
[10]. David A. Maltz Josh Broch David B. Johnson, Experiences Designing and
Building a Multi-HopWireless Ad-Hoc Network Testbed, DRAFT PAPER The
CMU , Monarch Project , Computer Science Department , Carnegie Mellon
University , Pittsburgh, PA 15213 , http://www.monarch.cs.cmu.edu/
[11]. Dave Johnson, NASA Ad-hoc Networking Demonstration, Computer Science
Department, Rice University, 30 September 2003.
[12]. Yi Wang. An Overview of Wireless Ad-hoc Networks:Challenges and Future.
Department of Electronic Engineering , Tsinghua University, Beijing, P. R.
China, 100084, (Student No. 034820)
[13]. Ns-2 network simulator installation, http://www.isi.edu/nsnam/ns/
[14]. The Ns-2 Manual, (formerly ns Notes and Documentation) The VINT Project A
Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox
PARC, August 23-2006, http://www.isi.edu/nsnam/ns/.
[15]. Yih-Chun Hu and David B. Johnson. Caching Strategies in On-Demand Routing
Protocols for Wireless Ad-Hoc Networks. In Proceedings of the Sixth Annual
IEEE/ACM International Conference on Mobile Computing and Networking,
pages 231–242, August 2000.
138
[16]. Web site: VINT, Virtual InterNetwork Testbed Project simulation framework
builds, A Collaboration among USC/ISI, Xerox PARC, LBNL and UCB,
October 19, 1997, http://www.isi.edu/nsnam/vint/.
[17]. Practical Programming in Tcl and Tk, Fourth Edition, June 10-2003, By
Brent B. Welch, Ken Jones, Jeffrey Hobbs.
[18]. Web site: Ns-2 Trace Formats, http://nsnam.isi.edu/nsnam/index.php/NS-
2_Trace_Formats
[19]. Web site: The Rice University Monarch Project: Mobile Networking
Architectures, http://www.monarch.cs.cmu.edu/.
[20]. Samir R. Das, Charles E. Perkins, Elizabeth M. Royer and Mahesh K. Marina.
Performance Comparison of Two On-demand Routing Protocols for Ad-hoc
Networks, IEEE Personal Communications Magazine special issue on Ad-hoc
Networking, February 2001, p. 16-28.
[21]. Samir R. Das, Charles E. Perkins, and Elizabeth M. Royer. Performance
Comparison of Two On-demand Routing Protocols for Ad-Hoc Networks."
Proceedings of the IEEE Conference on Computer Communications
(INFOCOM), Tel Aviv, Israel, March 2000, p. 3-12.
[22]. E. Altman, T. Jimenez, Ns Simulator for beginners, univ.de Los Andes, Merida,
Venezuela and ESSI, Sophia-Antipolis, France, December 4-2003.
[23]. J.-Y. Le Boudec and M. Vojnovic. Perfect Simulation and Stationarity of a Class
of Mobility Models, IEEE Infocom 2005, Miami, FL, 2005
http://lcawww.epfl.ch/Publications/LeBoudec/lebvoj04.pdf.
[24]. Web site: Ns-2 Code for Random Trip Mobility Model, by S. PalChaudhuri,
Rice University, http://www.cs.rice.edu/~santa/research/mobility/.
[25]. Yongwei Wang, Venkata C. Giruka, and Mukesh Singhal. A Truthful
Geographic Forwarding Algorithm for Ad-hoc Networks with Selfish Nodes,
Department of Computer Science, University of Kentucky, Lexington, KY
40506, USA , International Journal of Network Security, Vol.5, No.3, PP.252–
263, Nov. 2007.
[26]. Web site: Tutorial for the Network simulator Ns-2,
http://www.isi.edu/nsnam/ns/tutorial/.
[27]. Stuart Kurkowski, Tracy Camp, Neil Mushell and Michael Colagrosso, A
Visualization and Analysis Tool for Ns-2 Wireless Simulations: iNSpect,
Colorado School of Mines skurkows, tcamp, nmushell, January15, 2006,
http://toilers.mines.edu/pub/Public/PublicationList/MCS-06-01.pdf,
http://www.cl.cam.ac.uk/~sos22/p50-kurkowski.pdf.
[28]. Web site: NAM: Network Animator, http://www.isi.edu/nsnam/nam/
[29]. Web site: Ns-2 Trace Formats, http://nsnam.isi.edu/nsnam/index.php/NS-
2_Trace_Formats.
[30]. Web site: Running Ns-2 and Nam Under Windows 9x/2000/XP Using Cygwin,
http://www.isi.edu/nsnam/ns/ns-cygwin.html.
[31]. YUAN Peiyan and LI Layuan. Performance Evaluation and Simulations of
Routing Protocols in Ad-Hoc Networks, International Workshop on Broadband
Wireless Access for ubiquitous Networking, Alghero, Italy, September 20-2006.
[32]. Web site: Industrial Ethernet Book Issue, http://wireless.industrial-
networking.com/articles/articledisplay.asp?id=224
[33]. Qi Xu, Secure Forwarding in Personal Ad-Hoc Networks, Master Thesis,
Design and Analysis of Communication Systems , Faculty of Electrical
Engineering, Mathematics and Computer Science , University of Twente, May-
2005.
139
[34]. Web site: Elizabethtown, Mt. Joy and the Entire Pennsylvania Central Valley,
Serving Computer Wellness Center, 2006 E~Town Computers,
http://www.etowncomputers.com/networking.htm
[35]. Web site: Daniele Raffo. Security Schemes for the OLSR Protocol for Ad-Hoc
Networks, PhD Thesis, Universite , 15 SEP 2005,
http://perso.crans.org/~raffo/papers/phdthesis/thesisch1.html
[36]. D. Johnson and D. Maltz. Dynamic source routing in Ad-hoc wireless networks.
Computer Science Department Carnegie Mellon University, 1996.
[37]. John Donne, Personal Area Networking, Technical Manager TDK Systems
Europe Ltd http://www.tdksystems.com/download/wp/BLUETOOTH-
PERSONAL%20AREA%20NETWORKING.pdf.
[38]. Josh Broch, David Johnson, and David Maltz. The dynamic source routing
protocol for mobile ad-hoc networks. Computer Science Department Carnegie
Mellon University Pittsburgh, PA 5213-3891, http://www.monarch.cs.cmu.edu/
[39]. Mobile Ad-hoc Networking, Copyright 2004, by Stefano Basagni, Marco Conti,
Silvia Giordano and Ivan Stojmenovic, by the Institute of Electrical and
Electronics Engineers.
[40]. Computer Networks, Fourth Edition, by Andrew s, Tanenbaum.
[41]. Web site: Freesoft. Distance Vector Algorithms,
http://www.freesoft.org/CIE/RFC/1058/6.htm.
[42]. Web site: Wikipedia, The free Encyclopedia.
http://en.wikipedia.org/wiki/Distance- vector_routing_protocol.
[43]. Data and computer communications, fifth Edition, 1997, by William Stallings.
[44]. Web site: Douglas E. Comer, The Interior Gateway Routing Protocol: OSPF,
http://www.it.iitb.ac.in/xnet/ospf/info/ospf0.html
[45]. Web site: Freesoft. Distance Vector Algorithms,
http://www.freesoft.org/CIE/RFC/1058/6.htm.
[46]. Mobile ad-hoc networks, from wireless lan to 4g networks, copyright 2005 ,by
George Aggelou.
[47]. Xiaoyan Hong, Kaixin Xu, and Mario Gerla. Scalable routing protocols for
mobile Ad-hoc networks, University of California at Los Angeles IEEE
Network, August 2002.
[48]. Web site: Jae Chung and Mark Claypool, Ns-2 by Example, Worcester
Polytechnic Institvte, Computer Science, http://nile.wpi.edu/NS/
[49]. Web site: Graph Theory illustrating Dijkstra’s algorithm Applet,
http://links.math.rpi.edu/applets/appindex/graphtheory.html
[50]. Web site: JavaTM applet illustrating Dijkstra’s algorithm at the Website,
http://www.lupinho.de/gishur/html/DijkstraApplet.html
[51]. Web site:Use Dijkstra’s algorithm to find the shortest path between two cities:
http://www.unf.edu/~wkloster/foundations/DijkstraApplet/DijkstraApplet.htm
[52]. Web site: illustrating Dijkstra’s algorithm Applet
http://www.dgp.toronto.edu/people/JamesStewart/270/9798s/Laffra/DijkstraApp
let.html
[53]. Web site: Dijkstra's Algorithm,
http://www.cs.usask.ca/resources/tutorials/csconcepts/1999_8/tutorial/advanced/
dijkstra/dijkstra.html
[54]. Web site: Simulation of Bellman's Algorithm,
http://www.laynetworks.com/Simulation%20of%20Bellman%20Algorithm.htm
140
[55]. Y. Hu, D. Johnson, and A. Perrig. SEAD: Secure Efficient Distance Vector
Routing for Mobile Wireless Ad-hoc Networks. In proceedings of the 4th IEEE
Workshop on Mobile Computing Systems and Applications (WMCSA), 2002
[56]. Applied Cryptography, Second Edition: Protocols Algorthms and Source Code
in C. 01/01/1996, by Bruce Schneier.
[57]. L. Zhou and Z. J. Haas. Securing Ad-Hoc Networks. IEEE Network: special
issue on network security, vol. 13, no. 6, pp. 24–30, 1999.
[58]. Y.-C. Hu, D. B. Johnson, and A. Perrig. Ariadne: A Secure On Demand Routing
Protocol for Ad-Hoc Networks. In proc. Eighth ACM International Conf. on
Mobile Computing and Networking, September 2002.
[59]. B. Dahill, E. Levine, E. Royer, and C. Shields. A Secure Routing Protocol for
Ad-Hoc Networks. University of Massachusetts, Technical Report UM-CS-
2001-037, August 2001.
[60]. P. Papadimitratos and Z. J. Haas. Secure Routing for Mobile Ad-Hoc Networks.
In proc. SCS Communication Network and Distributed System Modeling and
Simulation Conf. (CNDS’02), January, 27-31 2002.
[61]. Gregory S. Yovanof and Kerem,Ericsi. Performance Evaluation of Security-
AwhereRouting Protocols for Clustered Mobile Ad-Hoc Networks, Athens
Information Technology, Int’l Workshop on Wireless Ad-Hoc Networks,
Finland, 1 June 2004.
[62]. Web site: Bryan J. Byerly. SIP Security Requirements. Internet Engineering
Task Force, January 8-2001, http://www.softarmor.com/wgdb/docs/draft-ietf-
sip-security-requirements-00.txt
[63]. Janne Lundberg. Routing Security in Ad-Hoc Networks. Helsinki University of
Technology Telecommunications Softwhereand Multimedia Laboratory, HUT
TML 2000.
[64]. Cryptography and Network Security Principles and Practices, Fourth Edition,
Nov 2005, by William Stallings.
[65]. T. Karygiannis and L. Owens. Wireless Network Security 802.11, Bluetooth and
Handheld Devices. National Institute of Standards and Technology, US
Department of Commence, Technical Report NIST Special Publication 800-48,
November 2002. http://www.csrc.nist.gov/ publications/ nistpubs/ 800-48/
NIST_SP_800-48.pdf
[66]. M. Jakobsson, W. S and Y. B. Stealth Attacks on Ad-Hoc Wireless Networks. In
proc. Vehicular Technology Conf., October, 6-9.2003.
http://www.informatics.indiana.edu/markus/papers/router.pdf
[67]. Timothy X Brown, Jesse E. James and Amita Sethi. Jamming and Sensing of
Encrypted Wireless Ad-Hoc Networks. University of Colorado at Boulder,
Technical Report CU-CS-1005-06, Department of Computer Science,
http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1005-
06.pdf
[68]. Jiejun Kong, Xiaoyan Hong and Mario Gerla. A NEW SET OF PASSIVE
ROUTING ATTACKS IN MOBILE AD-HOC NETWORKS. Computer
Science Department, University of California, Los Angeles, CA 90095,
http://www.cs.ucla.edu/NRL/wireless/uploads/milcom03-jkong.pdf
[69]. Web site: Handbook in Applied Cryptography. 5th printing in august 2001.
October 1996, by A. Menezes, P. van Oorschot, and S. Vanstone,
http://www.cacr.math.uwaterloo.ca/hac/
[70]. Yih-Chun Hu, Adrian Perrig and David B. Johnson. Wormhole Detection
in Wireless Ad-Hoc Networks. Technical Report TR01-384, Department
141
of Computer Science, Rice University, December 2001.

http://www.monarch.cs.rice.edu/monarch-papers/tikreport.pdf
[71]. J. Kong, Z. Ji, W. Wang, M. Gerla, R. Bagrodia, and B. Bhargava. Low-cost
Attacks against Packet Delivery, Localization and Time Synchronization
Services in Under-Water Sensor Networks. In proc. ACM Workshop on
Wireless Security, September, 2-2005.
http://people.eecs.ku.edu/~weichaow/Research/papers/WiSe05-uwsn.pdf
[72]. Hongmei Deng, Wei Li, and Dharma P. Agrawal. Routing Security in Wireless
Ad-Hoc Networks. University of Cincinnati, TELECOMMUNICATIONS
NETWORK SECURITY, IEEE Communications Magazine October 2002,
http://wise.cm.nctu.edu.tw/wise_lab/course/mobile05/paper/Routing%20security
%20in%20wireless%20ad%20hoc%20networks.pdf
[73]. V. Karpijoki. Security in Ad-Hoc Networks. Helsinki University of Technology,
Telecommunications Softwhereand Multimedia Laboratory, HUT TML, 2000,
http://www.hut.fi/~vkarpijo/netsec00/netsec00_manet_sec.ps
[74]. T. Camp, J. Boleng, and V. Davies. A Survey of Mobility Models for Ad-Hoc
Network Research. Appeared in Wireless Communication & Mobile Computing
: Special issue on Mobile Ad Hoc Networking: Research, Trends and
Applications, vol. 2, no. 5, pp. 483-502, 2002-
http://toilers.mines.edu/papers/pdf/Models.pdf
[75]. Patroklos Argyroudis. Current state of secure routing for mobile ad-hoc
networks. http://ntrg.cs.tcd.ie/~argp/public/adhoc-secure-routing-slides.pdf
[76]. Web site: Bo Wang, Cherry Lane, Apt.G Network Simulator Ns-2, Ns-2
Notebook, http://www.cse.msu.edu/~wangbo1/ns2/
[77]. Seung Yi, Prasad Naldurg and Robin Kravets, A Security-AwhereRouting
Protocol for Wireless Ad-Hoc Networks, Dept. of Computer Science, University
of Illinois at Urbana-Champaign.
[78]. Asad Amir Pirzada, Amitava Datta and Chris McDonald. Propagating Trust in
Ad-hoc Networks for Reliable, Routing. School of Computer Science &
SoftwhereEngineering, University of Western Australia.
http://www.cwc.oulu.fi/iwwan2004/slides/IWWAN04.pdf
[79]. Cygwin User’s Guide, http://www.cygwin.com/
142
Publication
Performance Evaluation Routing Algorithm Protocols of Ad-Hoc Sensor Mobile

Networks Using Ns-2 simulator, Proceedings of the first International Conference on
Information Systems and Technology (ICIST), Department of information technology
(MES) college of engineering, Kuttipuram, December 2007, PID 33, Theme WSN
http://mesengg.ac.in/icist-a.htm.
143
Appendix A
Implementation of Least Cost Path of Nodes
A.1. Dijkstra Algorithm

Our implementation code C/C++ program to compute least coast path of nodes for
Dijkstra Algorithm using simple networks as shown above of Network I, Network II
and book example to test our implementation code.
#include<iostream.h>
#include<stdio.h>
#include<conio.h>
void printtable(int,int);
void printheader(int);
void Read_Example();
void Read_NetworkI();
void Read_NetworkII();
void Read_Any_Network();
int N,final[10],l[10],pred[10],ENF=200,w[10][10];
main(){
int s,recent,stop,i,j,n,newlabel;
int counter,y,x,add,exit=1;
144
while (exit==1)
{ stop=1; counter=0; add=0;
cout<<" This program to find short path using"<<"\n";
cout<<" <<<<< Dijkstra Algorithm >>>>>"<<"\n\n";
cout<<" <<< Eng. Mehmed Bisheer Aliwa spring 20-1-2007 >>>\n\n";
cout<<">Master Thesis "<<"\n\n";
cout<<" To run Book Example References [43] page 298-299(enter 1)"<<"\n";
cout<<" run Network I (enter 2)"<<"\n";
cout<<" run Network II (enter 3)"<<"\n";
cout<<" Run any Network (enter 4)"<<"\n";
cin>>x;
switch(x)
{ case 1:Read_Example();break;
case 2:Read_NetworkI();break;
case 3:Read_NetworkII();break;
default:Read_Any_Network();
}
cout<<" Please enter Source Node "<<"\n";
cin>>s;
/////////////////for initialize////////////
for(n=1;n<=N;n++)
{ l[n]=ENF;
final[n]=0;
pred[n]=1;
}
l[s]=0;
final[s]=1;
recent=s;
///////////////////////////////////////////
printheader(s);
while(stop==1)
{ for(n=1;n<=N;n++)
if((w[recent][n]<ENF)&&(w[recent][n]!=0)&&(final[n]==0))
{
newlabel=l[recent]+w[recent][n];
add++;
if(newlabel<l[n])
{ l[n]=newlabel;
pred[n]=recent;
}
}
counter++;
printtable(counter,s);
int temp=ENF;
for(int x=1;x<=N;x++)
if((final[x]==0)&&(l[x]<temp))
{y=x;
temp=l[x];
}
if(temp<ENF)
145
{final[y]=1;
recent=y;
}
else
stop=0;
}
cout<<"\n\n\n .......<<<Eng. Mehmed Bisheer Aliwa>>>.......>spring 20-1-2007 \n";
cout<< "\n To exit press any key ";
cout<<"\n AND to Continue press ( 1 )\n";
cin>>exit;
}
return 0;
}
//////////////////////////////////////////////////////
void printheader(int s)
{ int i,x,y;
cout<<"\n"<<"itre"<<" "<<"T";
for(i=1;i<=N;i++)
if (i!=s)
{ if(N>6)
if((i==1)||(i==2))
cout<<" "<<"L["<<i<<"]";
else
cout<<" "<<"L["<<i<<"]";
else
cout<<" "<<"L["<<i<<"]";
x=wherex();
y=wherey();
gotoxy(x-=3,++y);
cout<<"path";
gotoxy(x+=3,--y);
}
cout<<"\n";
}
//////////////////////////////////////////////////////
void printtable(int counter,int s)
{ int i,j,arrive,path[10],k,x,y,x1,y1;
cout<<"\n\n";
x=wherex();
y=wherey();
x=x+14;
cout<<counter<<" "<<"[";
for(i=1;i<=N;i++)
if (final[i]==1)
cout<<i;
cout<<"]";
for(j=1;j<=N;j++)
if (j!=s)
{ i=0;
gotoxy(x,y);
146
if (l[j]==ENF)
cout<<"ENF"<<" "<<"-";
else
{ cout<<l[j]<<" ";
arrive=pred[j];
path[i]=j;
path[++i]=arrive;
while(arrive!=s)
{ arrive=pred[arrive];
path[++i]=arrive;
}
x1=wherex();
y1=wherey();
gotoxy(x1-=2,++y1);
for(k=i;k>=0;k--)
{cout<<path[k];
if(k!=0)
cout<<",";
}
gotoxy(x1+=2,--y1);
}
if(N>6)
x=x+7;
else
x=x+10;
}
}
//////////////Read any given network//////////////////////////
void Read_Any_Network()
{int i,j,n;
cout<<" Please enter Number of Nodes (max N=10)"<<"\n";
cin>>N;
cout<<" Please enter wait (for no link enter 0)"<<"\n";
for(i=1;i<=N;i++)
for(j=1;j<=N;j++)
if(i!=j)
{ cout<<"\n"<<"w["<<i<<"]["<<j<<"]=";
cin>>n;
if(n!=0)
w[i][j]=n;
else w[i][j]=ENF;
}
else w[i][j]=0;
}
////////////////////Read Exampl of Book///////////////////////

void Read_Example()
{
N=6;
147
w[1][1]=0;w[1][2]=2;w[1][3]=5;w[1][4]=1;w[1][5]=ENF;w[1][6]=ENF;
w[2][1]=3;w[2][2]=0;w[2][3]=3;w[2][4]=2;w[2][5]=ENF;w[2][6]=ENF;
w[3][1]=8;w[3][2]=6;w[3][3]=0;w[3][4]=3;w[3][5]=1;w[3][6]=5;
w[4][1]=7;w[4][2]=2;w[4][3]=3;w[4][4]=0;w[4][5]=1;w[4][6]=ENF;
w[5][1]=ENF;w[5][2]=ENF;w[5][3]=1;w[5][4]=1;w[5][5]=0;w[5][6]=2;
w[6][1]=ENF;w[6][2]=ENF;w[6][3]=8;w[6][4]=ENF;w[6][5]=4;w[6][6]=0;
}
///////////////////////////////
void Read_NetworkI()
{
N=6;
w[1][1]=0;w[1][2]=1;w[1][3]=ENF;w[1][4]=4;w[1][5]=ENF;w[1][6]=ENF;
w[2][1]=1;w[2][2]=0;w[2][3]=3;w[2][4]=ENF;w[2][5]=1;w[2][6]=ENF;
w[3][1]=ENF;w[3][2]=3;w[3][3]=0;w[3][4]=ENF;w[3][5]=1;w[3][6]=2;
w[4][1]=4;w[4][2]=ENF;w[4][3]=ENF;w[4][4]=0;w[4][5]=1;w[4][6]=ENF;
w[5][1]=ENF;w[5][2]=1;w[5][3]=1;w[5][4]=1;w[5][5]=0;w[5][6]=4;
}
////////////////////////////////////////
void Read_NetworkII()
{
N=10;
w[1][1]=0;w[1][2]=1;w[1][3]=ENF;w[1][4]=ENF;w[1][5]=1;w[1][6]=ENF;w[1][7]=
ENF;w[1][8]=ENF;w[1][9]=ENF;w[1][10]=ENF;
w[2][1]=1;w[2][2]=0;w[2][3]=1;w[2][4]=ENF;w[2][5]=ENF;w[2][6]=ENF;w[2][7]=
w[3][1]=ENF;w[3][2]=1;w[3][3]=0;w[3][4]=ENF;w[3][5]=ENF;w[3][6]=3;w[3][7]=
1;w[3][8]=ENF;w[3][9]=ENF;w[3][10]=4;
w[4][1]=ENF;w[4][2]=ENF;w[4][3]=ENF;w[4][4]=0;w[4][5]=5;w[4][6]=ENF;w[4][
7]=ENF;w[4][8]=1;w[4][9]=1;w[4][10]=2;
w[5][1]=1;w[5][2]=ENF;w[5][3]=ENF;w[5][4]=5;w[5][5]=0;w[5][6]=ENF;w[5][7]=
1;w[5][8]=ENF;w[5][9]=ENF;w[5][10]=ENF;
w[6][1]=ENF;w[6][2]=ENF;w[6][3]=3;w[6][4]=ENF;w[6][5]=ENF;w[6][6]=0;w[6][
7]=ENF;w[6][8]=ENF;w[6][9]=1;w[6][10]=ENF;
w[7][1]=ENF;w[7][2]=ENF;w[7][3]=1;w[7][4]=ENF;w[7][5]=1;w[7][6]=ENF;w[7][
7]=0;w[7][8]=1;w[7][9]=ENF;w[7][10]=ENF;
w[8][1]=ENF;w[8][2]=ENF;w[8][3]=ENF;w[8][4]=1;w[8][5]=ENF;w[8][6]=ENF;w[
8][7]=1;w[8][8]=0;w[8][9]=ENF;w[8][10]=ENF;
w[9][1]=ENF;w[9][2]=ENF;w[9][3]=ENF;w[9][4]=1;w[9][5]=ENF;w[9][6]=1;w[9][
7]=ENF;w[9][8]=ENF;w[9][9]=0;w[9][10]=ENF;
w[10][1]=ENF;w[10][2]=ENF;w[10][3]=4;w[10][4]=2;w[10][5]=ENF;w[10][6]=EN
F;w[10][7]=ENF;w[10][8]=ENF;w[10][9]=ENF;w[10][10]=0;
}
148
A.2. Bellman Ford Algorithm

Our implementation code C/C++ program to compute least coast path of nodes for
Bellman Ford Algorithm using simple networks as shown above of Network I,
Network II and book example to test our implementation code.
#include<stdio.h>
#include<conio.h>
int printtable(int,int);
void printheader(int);
void Read_Example();
void Read_NetworkI();
void Read_NetworkII();
void Read_Any_Network();
int N,final[10],l[10],pred[10],predl[10],w[10][10],ENF=200;
main(){
int s,h,n,i,j,newlabel,path_num=ENF,x,min=ENF,pred1,exit=1,add;
while (exit==1)
{ h=0;pred1=0,add=0;
cout<<" This program to find short path using"<<"\n";
cout<<" <<<<< Bellman Ford Algorithm >>>>>"<<"\n";
cout<<" <<< Eng. Mehmed Bisheer Aliwa >>>\nDATE:20 - 1 - 2007 \n\n";
cout<<">Master Thesis"<<"\n\n";
cout<<" To run Book Example References [43] page 298-299(enter 1)"<<"\n";
cout<<" Run Network I in assignment (enter 2)"<<"\n";
cout<<" Run Network II in assignment (enter 3)"<<"\n";
cout<<" Run any Network (enter 4)"<<"\n";
cin>>x;
switch(x)
{ case 1:Read_Example();break;
case 2:Read_NetworkI();break;
case 3:Read_NetworkII();break;
default:Read_Any_Network();
}
cout<<" Please enter Source Node "<<"\n";
cin>>s;
/////////////////for initialize////////////
for(n=1;n<=N;n++)
{ l[n]=ENF;
final[n]=ENF;
pred[n]=1;
predl[n]=1;
}
l[s]=0;
final[s]=0;
///////////////////////////////////////////
printheader(s);
path_num=printtable(h,s);
while(h<=path_num)
{
149
for(i=1;i<=N;i++)
{ min=ENF;
pred1=0;
if(i!=s)
{
for(j=1;j<=N;j++)
if((w[j][i]<ENF)&&(i!=j))
{ newlabel=l[j]+w[j][i];
add++;
if(newlabel<min)
{ min=newlabel;
pred1=j;
}
}
final[i]=min;
pred[i]=pred1;
}
}
for(i=1;i<=N;i++)
l[i]=final[i];
path_num=printtable(++h,s);
for(i=1;i<=N;i++)
predl[i]=pred[i];
}
cout<<"\n\n\n .......<<<Eng. Mehmed Bisheer Aliwa>>>.......> spring 20-1-2006 \n";
cout<< "\n To exit press any key ";
cout<<"\n AND to Continue press ( 1 )\n";
cin>>exit;
}
return 0;
}
//////////////////////////////////////////////////////
void printheader(int s)
{ int i,x,y;
cout<<"\n"<<"h";
for(i=1;i<=N;i++)
if (i!=s)
{ if(N>6)
if((i==1)||(i==2))
cout<<" "<<"L["<<i<<"]";
else
cout<<" "<<"L["<<i<<"]";
else
cout<<" "<<"L["<<i<<"]";
x=wherex();
y=wherey();
gotoxy(x-=3,++y);
cout<<"path";
gotoxy(x+=3,--y);
}
150
cout<<"\n";
}
//////////////////////////////////////////////////////
int printtable(int counter,int s)
{ int i,j,arrive,path[10],k,x,y,x1,y1,max=1;
cout<<"\n\n";
x=wherex();
y=wherey();
x=x+6;
cout<<counter<<" ";
for(j=1;j<=N;j++)
if (j!=s)
{ i=0;
gotoxy(x,y);
if (l[j]==ENF)
cout<<"ENF"<<" "<<"-";
else
{ cout<<l[j]<<" ";
arrive=pred[j];
path[i]=j;
path[++i]=arrive;
while(arrive!=s)
{ arrive=predl[arrive];
path[++i]=arrive;
}
x1=wherex();
y1=wherey();
gotoxy(x1-=2,++y1);
for(k=i;k>=0;k--)
{cout<<path[k];
if(k!=0)
cout<<",";
}
gotoxy(x1+=2,--y1);
}
if(i>max)
max=i;
if(N>6)
x=x+8;
else
x=x+10;
}
return(max);
}
//////////////Read any given network//////////////////////////
void Read_Any_Network()
{int i,j,n;
cout<<" Please enter Number of Nodes (max N=10) "<<"\n";
cin>>N;
cout<<" Please enter wait (for no link enter 0)"<<"\n";
151
for(i=1;i<=N;i++)
for(j=1;j<=N;j++)
if(i!=j)
{ cout<<"\n"<<"w["<<i<<"]["<<j<<"]=";
cin>>n;
if(n!=0)
w[i][j]=n;
else w[i][j]=ENF;
}
else w[i][j]=0;
}
////////////////////Read Exampl of Book///////////////////////
void Read_Example()
{
N=6;
w[1][1]=0;w[1][2]=2;w[1][3]=5;w[1][4]=1;w[1][5]=ENF;w[1][6]=ENF;
w[2][1]=3;w[2][2]=0;w[2][3]=3;w[2][4]=2;w[2][5]=ENF;w[2][6]=ENF;
w[3][1]=8;w[3][2]=6;w[3][3]=0;w[3][4]=3;w[3][5]=1;w[3][6]=5;
w[4][1]=7;w[4][2]=2;w[4][3]=3;w[4][4]=0;w[4][5]=1;w[4][6]=ENF;
w[5][1]=ENF;w[5][2]=ENF;w[5][3]=1;w[5][4]=1;w[5][5]=0;w[5][6]=2;
}
///////////////////////////////
void Read_NetworkI()
{
N=6;
w[1][1]=0;w[1][2]=1;w[1][3]=ENF;w[1][4]=4;w[1][5]=ENF;w[1][6]=ENF;
w[2][1]=1;w[2][2]=0;w[2][3]=3;w[2][4]=ENF;w[2][5]=1;w[2][6]=ENF;
w[3][1]=ENF;w[3][2]=3;w[3][3]=0;w[3][4]=ENF;w[3][5]=1;w[3][6]=2;
w[4][1]=4;w[4][2]=ENF;w[4][3]=ENF;w[4][4]=0;w[4][5]=1;w[4][6]=ENF;
w[5][1]=ENF;w[5][2]=1;w[5][3]=1;w[5][4]=1;w[5][5]=0;w[5][6]=4;
}
////////////////////////////////////////
void Read_NetworkII()
{
N=10;
w[1][1]=0;w[1][2]=1;w[1][3]=ENF;w[1][4]=ENF;w[1][5]=1;w[1][6]=ENF;w[1][7]=
w[2][1]=1;w[2][2]=0;w[2][3]=1;w[2][4]=ENF;w[2][5]=ENF;w[2][6]=ENF;w[2][7]=
w[3][1]=ENF;w[3][2]=1;w[3][3]=0;w[3][4]=ENF;w[3][5]=ENF;w[3][6]=3;w[3][7]=
1;w[3][8]=ENF;w[3][9]=ENF;w[3][10]=4;
w[4][1]=ENF;w[4][2]=ENF;w[4][3]=ENF;w[4][4]=0;w[4][5]=5;w[4][6]=ENF;w[4][
7]=ENF;w[4][8]=1;w[4][9]=1;w[4][10]=2;
w[5][1]=1;w[5][2]=ENF;w[5][3]=ENF;w[5][4]=5;w[5][5]=0;w[5][6]=ENF;w[5][7]=
1;w[5][8]=ENF;w[5][9]=ENF;w[5][10]=ENF;
w[6][1]=ENF;w[6][2]=ENF;w[6][3]=3;w[6][4]=ENF;w[6][5]=ENF;w[6][6]=0;w[6][
7]=ENF;w[6][8]=ENF;w[6][9]=1;w[6][10]=ENF;
152
w[7][1]=ENF;w[7][2]=ENF;w[7][3]=1;w[7][4]=ENF;w[7][5]=1;w[7][6]=ENF;w[7][
7]=0;w[7][8]=1;w[7][9]=ENF;w[7][10]=ENF;
w[8][1]=ENF;w[8][2]=ENF;w[8][3]=ENF;w[8][4]=1;w[8][5]=ENF;w[8][6]=ENF;w[
8][7]=1;w[8][8]=0;w[8][9]=ENF;w[8][10]=ENF;
w[9][1]=ENF;w[9][2]=ENF;w[9][3]=ENF;w[9][4]=1;w[9][5]=ENF;w[9][6]=1;w[9][
7]=ENF;w[9][8]=ENF;w[9][9]=0;w[9][10]=ENF;
w[10][1]=ENF;w[10][2]=ENF;w[10][3]=4;w[10][4]=2;w[10][5]=ENF;w[10][6]=EN
F;w[10][7]=ENF;w[10][8]=ENF;w[10][9]=ENF;w[10][10]=0;
}
Note: from the above code C/C++ to run Dijksta's/Bellman program using Borland
C++ V 4.5 will appear four chosen:-
 To run Example of Book that shown above (enter 1)
 To run Network I that shown above (enter 2)
 To run Network II that shown above (enter 3)
 To run any Network that shown above (enter 4)
If enter 1 the wait of example in first page will be using by the program, wherethe
program will need to enter the start node (source node). The table of shortest path and
their cost will appear (first column iteration, second the node will be used, third each
node their cost and below each code their path). The same thing if enter 2 or 3.
But if enter 4, the program will request number of node less than 10. The program
will request to enter wait for all nodes with each other. If no connect between nodes
enter 0 and max wait 199. The program will request the start or source node. The table
of shortest path and their cost will appear.
153
Appendix B
Implementation of Simulation Tcl

Code for Ns-2 Simulator
This code program is simulation code Tcl script used to run Ns-s and simulate
(DSDV, DSR and AODV) routing protocols and (SEAD) secure routing protocol for
Ad-hoc sensor mobile networks
B.1. Simulation Code Tcl Script of AODV Protocol:

#==================================================
# Define options
# ==================================================
set opt(chan) Channel/WirelessChannel
set opt(prop) Propagation/TwoRayGround
set opt(netif) Phy/WirelessPhy
set opt(mac) Mac/802_11
set opt(ifq) Queue/DropTail/PriQueue ;
set opt(ll) LL
set opt(ant) Antenna/OmniAntenna
set opt(x) 1000 ;# X dimension of the topography
set opt(y) 1000 ;# Y dimension of the topography
set opt(ifqlen) 50 ;# max packet in ifq
set opt(seed) 1.0
set opt(tr) final_sources0.tr ;# trace file
set opt(adhocRouting) AODV;
set opt(nn) 50 ;# how many nodes are simulated
set opt(cp) "../scenarios/cbr-50-20"
set opt(sc) "../scenarios/s-0-2"
set opt(stop) 100.0 ;# simulation time
# nam trace file
set opt(nt) nam-0-1.tr
#start debugger
#==================================================
# Main Program
#==================================================
# Initialize Global Variables
# create simulator instance
set ns_[new Simulator]
# set wireless channel, radio-model and topography objects
set wtopo [new Topography]
# create trace object for ns and nam
set tracefd [open $opt(tr) w]
$ns_ trace-all $tracefd
# use new trace file format
$ns_ use-newtrace
set namtrace [open nam-50-1.tr w] ;# for nam tracing
$ns_ namtrace-all-wireless $namtrace 1000 1000
# define topology
154
$wtopo load_flatgrid $opt(x) $opt(y)

# Create God
set god_ [create-god $opt(nn)]
# define how node should be created
#global node setting
$ns_ node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topoInstance $wtopo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF
# Create the specified number of nodes [$opt(nn)] and "attach" them
# to the channel.
for {set i 0} {$i < $opt(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0 ;# disable random motion
}
# Define node movement model
puts "Loading connection pattern..."
source $opt(cp)
# Define traffic model
puts "Loading scenario file..."
source $opt(sc)
# Define node initial position in nam
for {set i 0} {$i < $opt(nn)} {incr i} {
# 20 defines the node size in nam, must adjust it according to your scenario
# The function must be called after mobility model is defined
$ns_ initial_node_pos $node_($i) 20
}
# Tell nodes when the simulation ends
$ns_ at $opt(stop).000000001 "$node_($i) reset";
}
# tell nam the simulation stop time
$ns_ at $opt(stop) "$ns_ nam-end-wireless $opt(stop)"
$ns_ at $opt(stop).000000001 "puts \"NS EXITING...\" ; $ns_ halt"
puts "Starting Simulation..."
$ns_ run
155
B.2. Simulation Code Tcl Script of DSR Protocol:

#==================================================
# Define options
# ==================================================
set opt(ifq) CMUPriQueue;
set opt(ll) LL
set opt(seed) 1.0 ;
set opt(adhocRouting) DSR;
set opt(sc) "../scenarios/s-100-2"
# nam trace file
#start debugger
#
#==================================================
# Main Program
#==================================================
$ns_ use-newtrace
# define topology
# Create God
-llType $opt(ll) \
156
-agentTrace ON \
-routerTrace ON \
-macTrace OFF
# to the channel.
}
source $opt(cp)
source $opt(sc)
}
}
$ns_ run
B.3. Simulation Code Tcl Script of DSDV Protocol:

#==================================================
# Define options
# ==================================================
set opt(ll) LL
157

set opt(seed) 1.0 ;
set opt(adhocRouting) DSDV;
set opt(sc) "../scenarios/s-200-2 "
# nam trace file
#start debugger
#
#==================================================
# Main Program
#==================================================
$ns_ use-newtrace
# define topology
# Create God
-llType $opt(ll) \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF
# to the channel.
158

}
source $opt(cp)
source $opt(sc)
}
}
$ns_ run
B.4. Simulation Code Tcl Script of SEAD Protocol:

#==================================================
# Define options
# ==================================================
set opt(ll) LL
set opt(seed) 1.0 ;
set opt(adhocRouting) SEAD;
set opt(sc) "../scenarios/s-300-2 "
# nam trace file
#start debugger
#
159
#
#==================================================
# Main Program
#==================================================
$ns_ use-newtrace
# define topology
# Create God
-llType $opt(ll) \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF
# to the channel.
}
source $opt(cp)
source $opt(sc)
160

}
}
$ns_ run
161
Appendix C
Analyzer Module of Trace File Format for
Simulator Ns-2 ver 2.31
C.1- Java Code of Analyzer the Trace Files Format:

This code program is used to design analyzer module to records the packets and
computes the performance metrics.
import java.util.*;
import java.lang.*;
import java.io.*;
class tesst{
public class m{
}
public static void main(String arg[]){
System.out.println("Result of trace file format of simulator Ns-2 of Mobility Ad-Hoc
Networks ----2007");
String s,thisLine,currLine,thisLine1;
int j=0;
FileInputStream fin,fin1;
FileOutputStream fout,fout1;
//+++++++++++++++++++++++++++++++++
final int FILES=4;
//+++++++++++++++++++++++++++++++++
final int MAX_PACKETS=3799999;
try{
int i=0,sends=0, receives=0, packet_id=0, highest_packet_id = 0, line_count=0,
current_line=0, routing_packets=0;
int count=0, dropAGT=0, routing_drops=0, dpIFQ=0, dpRTR=0, dp=0;
float pdfraction, pdratio=0, time=0, packet_duration=0, end_to_end_delay=0,
avg_end_to_end_delay=0, dropratio=0;
float start_time[] = new float[MAX_PACKETS];
float end_time[] = new float[MAX_PACKETS];
float sent_packets[] = new float[MAX_PACKETS];
float received_packets[] = new float[MAX_PACKETS];
String tokens[] = new String[100];
// initialize the start time
for (i=0; i<MAX_PACKETS ; i++)
{
start_time[i] = 0;
}
fout =new FileOutputStream ("trace-output.txt");
DataOutputStream op = new DataOutputStream(fout);
op.writeBytes("Send - Received - Pdfraction - Pdratio - Routing overhead -
Normalized routingload - AverageEnd-End delay");
op.writeBytes(" - DropAGT - Dropratio - Droprouting overheadpackets -
Normalizedroutingload of Droppackets R & S - DropIFQ ");
162
op.writeChar('\n');
op.writeChar('\n');
for (int h=0;h<FILES+1;h++)
{
j=0;
sends=0;
dpIFQ=0;
dropAGT=0;
routing_drops=0;
receives=0; routing_packets=0;
highest_packet_id = 0;
end_to_end_delay=0;
for (i=0; i<MAX_PACKETS ; i++)
{ start_time[i] = 0; end_time[i]=0;
}
fin = new FileInputStream ("final_sources"+h+".tr");
while ((thisLine = br.readLine()) != null)
{
// scan it line by line
java.util.StringTokenizer st = new java.util.StringTokenizer(thisLine, " ");
i=0;
while(st.hasMoreElements())
tokens[i++]= st.nextToken();
if (tokens[0].equals("s") || tokens[0].equals("r") || tokens[0].equals("f") ||
tokens[0].equals("d"))
{
// analyze the time
if (tokens[1].equals("-t")) time = Float.valueOf(tokens[2]).floatValue();
// analyze the packet_id
if (tokens[39].equals("-Ii")) packet_id = Integer.valueOf(tokens[40]).intValue();
/// calculate the sent packets
if (tokens[0].equals("s")&&tokens[18].equals("AGT")&& tokens[34].equals("cbr"))
sends++;
//--------------------------------------------------------------------------------------
// calculate the drops packets IFQ
if (tokens[0].equals("d") && tokens[18].equals("IFQ")) dpIFQ++;
if (tokens[0].equals("d") && tokens[18].equals("RTR")) dpRTR++;
/// calculate the drop packets at application layer
if (tokens[0].equals("d") && tokens[18].equals("AGT") &&
tokens[34].equals("cbr")) dropAGT++;
// calculate the drops at routing packets
if (tokens[0].equals("d") && tokens[18].equals("RTR") &&
(tokens[34].equals("AODV") || tokens[34].equals("DSR") ||
tokens[34].equals("message")))
routing_drops++;
//--------------------------------------------------------------------------------------
// find the number of packets in the simulation
if (packet_id >highest_packet_id) highest_packet_id = packet_id;
// set the start time, only if its not already set
if (start_time[packet_id] == 0) start_time[packet_id] = time;
163
// calculate the receives and end-end delay

if (tokens[0].equals("r") && tokens[18].equals("AGT") && tokens[34].equals("cbr"))
{
receives++;
end_time[packet_id] = time;
}
else end_time[packet_id] = -1;
// calculate the routing packets
if ((tokens[0].equals("s") || tokens[0].equals("f")) &&
tokens[18].equals("RTR")&&(tokens[34].equals("AODV") ||
tokens[34].equals("DSR")|| tokens[34].equals("message") ))
routing_packets++;
}
}
// calculate the packet duration for all the packets
for (packet_id = 0; packet_id <= highest_packet_id ; packet_id++)
{
packet_duration = end_time[packet_id] - start_time[packet_id];
if (packet_duration >0) end_to_end_delay += packet_duration;
}
// calculate the average end-end packet delay
avg_end_to_end_delay = end_to_end_delay / (receives );
// calculate the packet delivery fraction
pdfraction = ((float)receives/(float)(sends))*100;
pdratio = ((float)receives/(float)(sends));
// calculate the drop packet delivery ratio
dropratio = ((float)dropAGT/(float)(sends));
dp=dpIFQ-dpRTR ;
System.out.println(" \n Sends = "+sends);
System.out.println(" Receives = "+receives);
System.out.println(" PDfraction = " +pdfraction);
System.out.println(" PDratio = " +pdratio);
System.out.println(" Routing overhead (packets) = "+ routing_packets);
System.out.println(" Normalized routing load =
"+(float)routing_packets/(float)receives);
System.out.println(" Avg End-End delay = " +avg_end_to_end_delay);
System.out.println(" DropAGT = "+dropAGT);
System.out.println(" Dropratio = "+dropratio);
System.out.println(" DropRouting overhead (packets) = "+routing_drops);
System.out.println(" Normalized Drop packets at routing load with R =
"+(float)routing_drops/(float)receives);
System.out.println(" Normalized Drop packets at routing load with S=
"+(float)routing_drops/(float)sends);
System.out.println(" Drop IFQ = "+dpIFQ);
System.out.println(" Drop RTR = "+dpRTR);
System.out.println(" Drop IFQ = "+dp);
//--------------------------------------------------------------------------------------
op.writeBytes(" " +sends);
op.writeBytes(" "+receives);
op.writeBytes(" " +pdfraction);
164
op.writeBytes(" " +pdratio);

op.writeBytes(" "+ routing_packets);
op.writeBytes(" "+(float)routing_packets/(float)receives);
op.writeBytes(" " +avg_end_to_end_delay);
op.writeBytes(" " +dropAGT);
op.writeBytes(" " +dropratio);
op.writeBytes(" " +routing_drops);
op.writeBytes(" " +(float)routing_drops/(float)receives);
op.writeBytes(" " +(float)routing_drops/(float)sends);
op.writeBytes(" " +dpIFQ);
op.writeChar('\n');
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
//------------------------------------------------------------------------------------
C.2- C/C++ Code of Analyzer the Trace File Format:

This C/C++ code program is used analyzer module to records the movement source
node and movement all source node at each simulation time.
#include<stdio.h>
#include<conio.h>
#include<math.h>
void nxy()
{
clrscr();
FILE *inFile;
FILE *copy;
int i = 0;
char w ,ww ;
int nod,pq,pn,pw,f2,node,r,rr;
float tt ,f3,fx,fy,pp,x,y;
char f1, h;
inFile = fopen("tracefile.tr", "r");
copy = fopen("xy.txt", "w");
fprintf(copy, "\n (x,y) = movement node \n");
cout<<"enter number of node ";
scanf("%d",&node);
tt=0 ;
r=1 ;
rr=1 ;
tt=0 ;
while(feof)
165
{
fscanf(inFile, "%c", &f1);
if (r==rr){
ww='-';
if(ww==f1){
ww='t';
if(ww==f1){
fscanf(inFile, "%f", &f3);
tt=f3;
//fprintf(copy, "\n time= %f", tt);
}
}
}
ww='H';
if (ww==f1)
{
w='s' ;
if (w==f1)
{
fscanf(inFile, "%d", &f2);
nod=f2 ;
if(node==nod){
fprintf(copy, "\n time= %f node= %d",tt,nod);
for (i=1;i<2000;i++){
ww='-';
if(ww==f1){
ww='t';
if(ww==f1){
tt=f3;
rr=1 ;
break;
}
else
ww='N';
if (ww==f1){
w='x' ;
if (w==f1){
fscanf(inFile, "%f", &fx);
x=fx ;
fprintf(copy, " x= %f ", x);
}
w='y' ;
if (w==f1){
fscanf(inFile, "%f", &fy);
166
y=fy ;
fprintf(copy, " y= %f ", y);
}
}
}
}
}
}
}
if(feof(inFile)) break;
}
fclose(inFile);
fclose(copy);
cout<<"\n.......................................................................\n";
cout<<"\n\n\nwe make (x,y) = Movement for node in file\n\n\n The name of file:
xy.txt\n\n\npress Enter to return menu";
getch();
}
//-----------------------------------------------------------------------------
void nxxy()
{
clrscr();
FILE *inFile;
FILE *copy;
int i = 0;
char w ,ww ;
int nod,pq,pn,pw,f2,node,r,rr;
float tt ,f3,fx,fy,pp,x,y;
char f1, h;
inFile = fopen("r.tr", "r");
copy = fopen("xy-all.txt", "w");
fprintf(copy, "\n (x,y) = movement node \n");
tt=0 ;
r=1 ;
rr=1 ;
tt=0 ;
while(feof)
{
if (r==rr){
ww='-';
if(ww==f1){
ww='t';
if(ww==f1){
tt=f3;
}
}
}
167
ww='H';
if (ww==f1)
{
w='s' ;
if (w==f1)
{
fscanf(inFile, "%d", &f2);
nod=f2 ;
fprintf(copy, "\n time= %f node= %d",tt,nod);
for (i=1;i<2000;i++){
ww='-';
if(ww==f1){
ww='t';
if(ww==f1){
tt=f3;
rr=1 ;
break;
}
else
ww='N';
if (ww==f1){
w='x' ;
if (w==f1){
fscanf(inFile, "%f", &fx);
x=fx ;
fprintf(copy, " x= %f ", x);
}
w='y' ;
if (w==f1){
fscanf(inFile, "%f", &fy);
y=fy ;
fprintf(copy, " y= %f ", y);
}
}
}
}
}
}
if(feof(inFile)) break;
}
fclose(inFile);
fclose(copy);
cout<<"\n.......................................................................\n";
cout<<"\n\n\nwe make (x,y) = Movement for node in file\n\n\n The name of file:
xy-all.txt\n\n\npress Enter to return menu";
168
getch();
}
//...........................................................................................................
//This the main program to do all function by call using switch case
//...........................................................................................................
void main (void)
{
clrscr();
int j=30;
while(j>0)
{
clrscr();
cout<<"*****************************************************";
cout<<"\n This program for \nDATE: 2007 \n Movement Node analysis form
Trace file format Ns-2 Simulator \n";
cout<<"******************************************************";
cout<<" \n\n......... Movement Node .......";
cout<<"\n\n->To Run program choose( 0 , 1 , 2 )\n\n(1)-> Movement source Node Enter(1)";
cout<<"\n\n(2)-> Movement All Node Enter(2)";
cout<<"\n\n(0)-> Exit";
cout<<"\n****************************************************";
cout<<"\n\n Enter number--->>: " ;
cin>>j;
switch(j)
{
case 1:
{
nxy();
break;
}
case 2:
{
nxxy();
break;
}
}
}
}
169
Appendix D
Implementation Code C/C++ of SEAD Secure

Routing Protocol in Ns-2 Simulator
/*
SEAD.cc, of Ns-2 Ver: 2.31
*/
extern "C" {
#include <stdarg.h>
#include <float.h>
};
#include "/home/administrator/ns/ns-2.31/dsdv/dsdv.h"
#include "/home/administrator/ns/ns-2.31/dsdv/rtable.h"
#include "priqueue.h"
#include <random.h>
#include <cmu-trace.h>
#include <address.h>
#include <mobilenode.h>
#define TESLA
#define DSDV_STARTUP_JITTER 2.0 // secs to jitter start of periodic activity from
#define DSDV_ALMOST_NOW 0.1 // jitter used for events that should be
effectively
// instantaneous but are jittered to prevent synchronization
#define DSDV_BROADCAST_JITTER 0.01 // jitter for all broadcast packets
#define DSDV_MIN_TUP_PERIOD 1.0 // minimum time between triggered updates
#define IP_DEF_TTL 32 // default TTTL
#undef TRIGGER_UPDATE_ON_FRESH_SEQNUM
static inline double
jitter (double max, int be_random_)
{
return (be_random_ ? Random::uniform(max) : 0);
}
void DSDV_Agent::trace (char *fmt,...)
{
va_list ap;
if (!tracetarget)
return;
va_start (ap, fmt);
vsprintf (tracetarget->pt_->buffer (), fmt, ap);
tracetarget->pt_->dump ();
va_end (ap);
}
void
DSDV_Agent::tracepkt (Packet * p, double now, int me, const char *type)
{
char buf[1024];
unsigned char *walk = p->accessdata ();
int ct = *(walk++);
170
int seq, dst, met;

snprintf (buf, 1024, "V%s %.5f _%d_ [%d]:", type, now, me, ct);
while (ct--)
{
dst = *(walk++);
met = *(walk++);
seq = *(walk++);
seq = seq << 8 | *(walk++);
seq = seq << 8 | *(walk++);
seq = seq << 8 | *(walk++);
snprintf (buf, 1024, "%s (%d,%d,%d)", buf, dst, met, seq);
}
if (verbose_)
trace ("%s", buf);
}
void
DSDV_Agent::output_rte(const char *prefix, rtable_ent * prte, DSDV_Agent * a)
{
a->trace("DFU: deimplemented");
printf("DFU: deimplemented");
prte = 0;
prefix = 0;
#if 0
printf ("%s%d %d %d %d %f %f %f %f 0x%08x\n",prefix, prte->dst, prte->hop, prte-
>metric, prte->seqnum,prte->udtime, prte->new_seqnum_at, prte->wst, prte-
>changed_at, (unsigned int) prte->timeout_event);
a->trace ("VTE %.5f %d %d %d %d %f %f %f %f 0x%08x",
Scheduler::instance ().clock (), prte->dst, prte->hop, prte->metric,
prte->seqnum, prte->udtime, prte->new_seqnum_at, prte->wst, prte->changed_at,
prte->timeout_event);
#endif
}
class DSDVTriggerHandler : public Handler {
public:
DSDVTriggerHandler(DSDV_Agent *a_) { a = a_; }virtual void handle(Event *e);
private:
DSDV_Agent *a;
};
void
DSDVTriggerHandler::handle(Event *e)
{
Scheduler & s = Scheduler::instance ();
Time now = s.clock ();
rtable_ent *prte;
int update_type; // we want periodic (=1) or triggered (=0) update?
Time next_possible = a->lasttup_ + DSDV_MIN_TUP_PERIOD;
for (a->table_->InitLoop(); (prte = a->table_->NextLoop()); )
if (prte->trigger_event == e) break;
if (!prte) {
delete e;
171
return;
}
assert(prte && prte->trigger_event == e);
if (now < next_possible)
{
s.schedule(a->trigger_handler, e, next_possible - now);
a->cancelTriggersBefore(next_possible);
return;
}
update_type = 0;
Packet * p = a->makeUpdate(/*in-out*/update_type);
if (p != NULL)
{
if (update_type == 1)
{
s.cancel(a->periodic_callback_);
s.schedule (a->helper_, a->periodic_callback_,
a->perup_ * (0.75 + jitter (0.25, a->be_random_)));
if (a->verbose_) a->tracepkt (p, now, a->myaddr_, "PU");
}
else
{
if (a->verbose_) a->tracepkt (p, now, a->myaddr_, "TU");
}
assert (!HDR_CMN (p)->xmit_failure_);
s.schedule (a->target_, p, jitter(DSDV_BROADCAST_JITTER, a->be_random_));
a->lasttup_ = now;
}
for (a->table_->InitLoop (); (prte = a->table_->NextLoop ());)
if (prte->trigger_event && prte->trigger_event == e)
{
prte->trigger_event = 0;
delete e;
}
}
void
DSDV_Agent::cancelTriggersBefore(Time t)
{
struct rtable_ent *prte;
for (table_->InitLoop (); (prte = table_->NextLoop ());)
if (prte->trigger_event && prte->trigger_event->time_ < t)
{
s.cancel(prte->trigger_event);
delete prte->trigger_event;
prte->trigger_event = 0;
}
}
void
DSDV_Agent::needTriggeredUpdate(rtable_ent *prte, Time t)
172
{
Scheduler & s = Scheduler::instance();
Time now = Scheduler::instance().clock();
assert(t >= now);
if (prte->trigger_event)
s.cancel(prte->trigger_event);
else
prte->trigger_event = new Event;
s.schedule(trigger_handler, prte->trigger_event, t - now);
}
void
DSDV_Agent::helper_callback (Event * e)
{
double now = s.clock ();
rtable_ent *prte;
rtable_ent *pr2;
int update_type;
if (periodic_callback_ && e == periodic_callback_)
{
update_type = 1;
Packet *p = makeUpdate(/*in-out*/update_type);
if (verbose_)
{
trace ("VPC %.5f _%d_", now, myaddr_);
tracepkt (p, now, myaddr_, "PU");
}
assert (!HDR_CMN (p)->xmit_failure_); // DEBUG 0x2
s.schedule (target_, p, jitter(DSDV_BROADCAST_JITTER, be_random_));
s.schedule (helper_, periodic_callback_, perup_ * (0.75 + jitter (0.25, be_random_)));
lasttup_ = now;
return;
}
if (prte->timeout_event && (prte->timeout_event == e))
break;
if (prte)
{
if (verbose_)
{
trace ("VTO %.5f _%d_ %d->%d", now, myaddr_, myaddr_, prte->dst);
}
for (table_->InitLoop (); (pr2 = table_->NextLoop ()); )
{
if (pr2->hop == prte->dst && pr2->metric != BIG)
{
if (verbose_)
trace ("VTO %.5f _%d_ marking %d", now, myaddr_, pr2->dst);
pr2->metric = BIG;
pr2->advertise_ok_at = now;
173
pr2->advert_metric = true;
pr2->advert_seqnum = true;
#ifndef TESLA
pr2->seqnum++;
#endif
needTriggeredUpdate(pr2, now);
}
}
// OK the timeout expired, so we'll free it. No dangling pointers.
prte->timeout_event = 0;
}
else
{
fprintf(stderr,"DFU: unknown queue event\n");
abort();
}
if (e)
delete e;
}
void
DSDV_Agent::lost_link (Packet *p)
{
hdr_cmn *hdrc = HDR_CMN (p);
rtable_ent *prte = table_->GetEntry (hdrc->next_hop_);
if(use_mac_ == 0) {
drop(p, DROP_RTR_MAC_CALLBACK);
return;
}
if (verbose_ && hdrc->addr_type_ == NS_AF_INET)
trace ("VLL %.8f %d->%d lost at %d",
Scheduler::instance().clock(),
hdr_ip::access(p)->saddr(), hdr_ip::access(p)->daddr(), myaddr_);
if (!use_mac_ || !prte || hdrc->addr_type_ != NS_AF_INET)
return;
if (verbose_)
trace ("VLP %.5f %d:%d->%d:%d lost at %d [hop %d]",
Scheduler::instance ().clock (),
hdr_ip::access (p)->saddr(),
hdr_ip::access (p)->sport(),
hdr_ip::access (p)->daddr(),
hdr_ip::access (p)->dport(),
myaddr_, prte->dst);
if (prte->timeout_event)
{
Scheduler::instance ().cancel (prte->timeout_event);
helper_callback (prte->timeout_event);
}
else if (prte->metric != BIG)
{
assert(prte->timeout_event == 0);
174
prte->timeout_event = new Event ();

helper_callback (prte->timeout_event);
}
// Queue these packets up...
recv(p, 0);
#if 0
while (p2 = ((PriQueue *) target_)->filter (prte->dst))
{
if (verbose_)
trace ("VRS %.5f %d:%d->%d:%d lost at %d", Scheduler::instance ().clock (),
hdr_ip::access (p2)->saddr(),
hdr_ip::access (p2)->sport(),
hdr_ip::access (p2)->daddr(),
hdr_ip::access (p2)->dport(), myaddr_);
recv(p2, 0);
}
while (p2 = ll_queue->filter (prte->dst))
{
if (verbose_)
trace ("VRS %.5f %d:%d->%d:%d lost at %d", Scheduler::instance ().clock (),
hdr_ip::access (p2)->saddr(),
hdr_ip::access (p2)->sport(),
hdr_ip::access (p2)->daddr(),
hdr_ip::access (p2)->dport(), myaddr_);
recv (p2, 0);
}
#endif
}
static void
mac_callback (Packet * p, void *arg)
{
((DSDV_Agent *) arg)->lost_link (p);
}
Packet *
DSDV_Agent::makeUpdate(int& periodic)
{
Packet *p = allocpkt ();
hdr_ip *iph = hdr_ip::access(p);
double now = Scheduler::instance ().clock ();
rtable_ent *prte;
unsigned char *walk;
int change_count; // count of entries to go in this update
int rtbl_sz; // counts total entries in rt table
int unadvertiseable; // number of routes we can't advertise yet
// The packet we send wants to be broadcast
hdrc->next_hop_ = IP_BROADCAST;
hdrc->addr_type_ = NS_AF_INET;
iph->daddr() = IP_BROADCAST << Address::instance().nodeshift();
iph->dport() = ROUTER_PORT;
175
change_count = 0;
rtbl_sz = 0;
unadvertiseable = 0;
for (table_->InitLoop ();
(prte = table_->NextLoop ()); )
{
rtbl_sz++;
if ((prte->advert_seqnum || prte->advert_metric)
&& prte->advertise_ok_at <= now)
change_count++;
if (prte->advertise_ok_at > now) unadvertiseable++;
}
if (change_count * 3 > rtbl_sz && change_count > 3)
{ // much of the table has changed, just do a periodic update now
periodic = 1;
}
if (periodic)
{
change_count = rtbl_sz - unadvertiseable;
assert(change_count >= 1);
#if 0
trace("DAM %.5f _%d_ sz %d cc %d unat %d", now, myaddr_, rtbl_sz,
change_count, unadvertiseable);
#endif
rtable_ent rte;
bzero(&rte, sizeof(rte));
seqno_ += 2;
rte.dst = myaddr_;
rte.hop = Address::instance().get_nodeaddr(iph->saddr());
rte.metric = 0;
rte.seqnum = seqno_;
rte.advertise_ok_at = 0.0;
rte.advert_seqnum = true;
rte.changed_at = now;
rte.new_seqnum_at = now;
rte.wst = 0;
rte.timeout_event = 0;
rte.q = 0;
table_->AddEntry (rte);
}
if (change_count == 0)
{
Packet::free(p); // allocated by us, no drop needed
return NULL; // nothing to advertise
}
//* ****** make the update packet.... ***********
assert(rtbl_sz <= (1500 / 12));
p->allocdata ((change_count * 6) + 1);
walk = p->accessdata ();
*(walk++) = change_count;
176
#ifdef TESLA
hdrc->size_ = change_count * 22 + IP_HDR_LEN;
#else
hdrc->size_ = change_count * 12 + IP_HDR_LEN;
#endif
#if 0
int jjj = 0;
#endif
{
#if 0
jjj++;
trace("DAM %.5f _%d_ jjj %d cc %d -dst %d ok at %f",
now, myaddr_, jjj, change_count, prte->dst,
prte->advertise_ok_at );
#endif
if (periodic && prte->advertise_ok_at > now)
{
continue;
}
if (periodic || ((prte->advert_seqnum || prte->advert_metric)
&& prte->advertise_ok_at <= now))
{
if (!periodic && verbose_)
trace ("VCT %.5f _%d_ %d", now, myaddr_, prte->dst);
assert (prte->dst < 256 && prte->metric < 256);
*(walk++) = prte->dst;
*(walk++) = prte->metric;
*(walk++) = (prte->seqnum) >> 24;
*(walk++) = ((prte->seqnum) >> 16) & 0xFF;
*(walk++) = ((prte->seqnum) >> 8) & 0xFF;
*(walk++) = (prte->seqnum) & 0xFF;
prte->last_advertised_metric = prte->metric;
prte->advert_seqnum = false;
if (periodic)
{
prte->advert_seqnum = false;
prte->advert_metric = false;
}
change_count--;
}
}
assert(change_count == 0);
return p;
}
void
DSDV_Agent::updateRoute(rtable_ent *old_rte, rtable_ent *new_rte)
{
int negvalue = -1;
assert(new_rte);
177

char buf[1024];
snprintf (buf, 1024, "%c %.5f _%d_ (%d,%d->%d,%d->%d,%d->%d,%f)",
(new_rte->metric != BIG&& (!old_rte || old_rte->metric != BIG)) ? 'D' : 'U',now,
myaddr_, new_rte->dst,old_rte ? old_rte->metric : negvalue, new_rte->metric,old_rte
? old_rte->seqnum : negvalue, new_rte->seqnum,old_rte ? old_rte->hop : -1,
new_rte->hop,new_rte->advertise_ok_at);
table_->AddEntry (*new_rte);
if (trace_wst_)
trace ("VWST %.12lf frm %d to %d wst %.12lf nxthp %d [of %d]",now, myaddr_,
new_rte->dst, new_rte->wst, new_rte->hop,new_rte->metric);
if (verbose_)
trace ("VS%s", buf);
}
void
DSDV_Agent::processUpdate (Packet * p)
{
hdr_ip *iph = HDR_IP(p);
int i;
unsigned char *d = p->accessdata ();
unsigned char *w = d + 1;
rtable_ent rte;
rtable_ent *prte; // ptr to entry *in* routing tbl
for (i = *d; i > 0; i--)
{
bool trigger_update = false; // do we need to do a triggered update?
nsaddr_t dst;
prte = NULL;
dst = *(w++);
if ((prte = table_->GetEntry (dst)))
{
bcopy(prte, &rte, sizeof(rte));
}
else
{
}
rte.dst = dst;
rte.metric = *(w++);
rte.seqnum = *(w++);
rte.seqnum = rte.seqnum << 8 | *(w++);
if (rte.metric != BIG) rte.metric += 1;
if (rte.dst == myaddr_)
{
178
if (rte.metric == BIG && periodic_callback_)

{
s.cancel (periodic_callback_);
s.schedule (helper_, periodic_callback_, 0);
}
continue;
}
if (prte)
{
if (prte->seqnum == rte.seqnum)
{
rte.wst = prte->wst;
rte.new_seqnum_at = prte->new_seqnum_at;
}
else
{
#ifdef TESLA
rte.wst = 0;
#else
rte.wst = alpha_ * prte->wst + (1.0 - alpha_) * (prte->changed_at - prte-
>new_seqnum_at);
#endif
}
}
else
{ // inititallize the wst for the new route
#ifdef TESLA
rte.wst = 0;
#else
rte.wst = wst0_;
#endif
}
// Now that we know the wst_, we know when to update...
if (rte.metric != BIG && (!prte || prte->metric != BIG))
rte.advertise_ok_at = now + (rte.wst * 2);
else
rte.advertise_ok_at = now;
/*********** decide whether to update our routing table *********/
if (!prte)
{
if (rte.metric < BIG)
{
rte.advert_metric = true;
trigger_update = true;
}
updateRoute(prte,&rte);
}
else if ( prte->seqnum == rte.seqnum )
179
{
if (rte.metric < prte->metric)
{
if (rte.metric == prte->last_advertised_metric)
{
rte.advert_metric = false;
trigger_update = false;
}
else
{
}
}
else
{
}
}
else if ( prte->seqnum < rte.seqnum )
{
if (rte.metric == prte->last_advertised_metric)
{
rte.advert_metric = false;
}
else
{
}
#ifdef TRIGGER_UPDATE_ON_FRESH_SEQNUM
#else
trigger_update = false;
#endif
}
else if ( prte->seqnum > rte.seqnum )
{
if (rte.metric == BIG && prte->metric != BIG)
{
prte->advertise_ok_at = now;
prte->advert_metric = true;
needTriggeredUpdate(prte,now);
}
else
{
}
}
else
180
{
fprintf(stderr,"%s DFU: unhandled adding a route entry?\n", __FILE__);
abort();
}
if (trigger_update)
{
prte = table_->GetEntry (rte.dst);
assert(prte != NULL && prte->advertise_ok_at == rte.advertise_ok_at);
needTriggeredUpdate(prte, prte->advertise_ok_at);
}
if (rte.q && rte.metric != BIG)
{
Packet *queued_p;
while ((queued_p = rte.q->deque()))
recv(queued_p, 0); // give the packets to ourselves to forward
delete rte.q;
rte.q = 0;
table_->AddEntry(rte); // record the now zero'd queue
}
}
prte = table_->GetEntry(Address::instance().get_nodeaddr(iph->saddr()));
if (prte)
{
if (prte->timeout_event)
s.cancel (prte->timeout_event);
else
{
prte->timeout_event = new Event ();
}
s.schedule (helper_, prte->timeout_event, min_update_periods_ * perup_);
}
else
{
rte.dst = Address::instance().get_nodeaddr(iph->saddr());
rte.metric = 1;
rte.seqnum = 0;
rte.advertise_ok_at = now + 604800; // check back next week... :)
rte.wst = wst0_;
rte.timeout_event = new Event ();
rte.q = 0;
updateRoute(NULL, &rte);
s.schedule(helper_, rte.timeout_event, min_update_periods_ * perup_);
}
Packet::free (p);
}
int
181
DSDV_Agent::diff_subnet(int dst)
{
char* dstnet = Address::instance().get_subnetaddr(dst);
if (subnet_ != NULL) {
if (dstnet != NULL) {
if (strcmp(dstnet, subnet_) != 0) {
delete [] dstnet;
return 1;
}
delete [] dstnet;
}
}
return 0;
}
void
DSDV_Agent::forwardPacket (Packet * p)
{
int dst;
rtable_ent *prte;
hdrc->direction() = hdr_cmn::DOWN;
dst = Address::instance().get_nodeaddr(iph->daddr());
if (diff_subnet(iph->daddr())) {
prte = table_->GetEntry (dst);
if (prte && prte->metric != BIG)
goto send;
dst = node_->base_stn();
goto send;
else {
fprintf(stderr, "warning: Route to base_stn not known: dropping pkt\n");
Packet::free(p);
return;
}
}
{
goto send;
}
else if (prte)
{ /* must queue the packet */
if (!prte->q)
{
prte->q = new PacketQueue ();
}
182
prte->q->enque(p);
if (verbose_)
trace ("VBP %.5f _%d_ %d:%d -> %d:%d", now, myaddr_, iph->saddr(),
iph->sport(), iph->daddr(), iph->dport());
while (prte->q->length () > MAX_QUEUE_LENGTH)
drop (prte->q->deque (), DROP_RTR_QFULL);
return;
}
else
{ // Brand new destination
rtable_ent rte;
double now = s.clock();
rte.dst = dst;
rte.hop = dst;
rte.metric = BIG;
rte.seqnum = 0;
rte.advertise_ok_at = now + 604800; // check back next week... :)
rte.new_seqnum_at = now; // was now + wst0_, why??? XXX -dam
rte.wst = wst0_;
rte.timeout_event = 0;
rte.q = new PacketQueue();
rte.q->enque(p);
assert (rte.q->length() == 1 && 1 <= MAX_QUEUE_LENGTH);
table_->AddEntry(rte);
if (verbose_)
trace ("VBP %.5f _%d_ %d:%d -> %d:%d", now, myaddr_,
iph->saddr(), iph->sport(), iph->daddr(), iph->dport());
return;
}
send:
hdrc->addr_type_ = NS_AF_INET;
hdrc->xmit_failure_ = mac_callback;
hdrc->xmit_failure_data_ = this;
if (prte->metric > 1)
hdrc->next_hop_ = prte->hop;
else
hdrc->next_hop_ = dst;
if (verbose_)
trace ("Routing pkts outside domain: \
VFP %.5f _%d_ %d:%d -> %d:%d", now, myaddr_, iph->saddr(),iph->sport(), iph-
>daddr(), iph->dport());
assert (!HDR_CMN (p)->xmit_failure_ || HDR_CMN (p)->xmit_failure_ ==
mac_callback);
target_->recv(p, (Handler *)0);
return;
}
void
DSDV_Agent::sendOutBCastPkt(Packet *p)
183
{
s.schedule (target_, p, jitter(DSDV_BROADCAST_JITTER, be_random_));
}
void
DSDV_Agent::recv (Packet * p, Handler *)
{
hdr_cmn *cmh = HDR_CMN(p);
int src = Address::instance().get_nodeaddr(iph->saddr());
int dst = cmh->next_hop();
if( src == myaddr_ && cmh->num_forwards() == 0) {
// * Add the IP Header
cmh->size() += IP_HDR_LEN;
iph->ttl_ = IP_DEF_TTL;
}
else if( src == myaddr_) {
drop(p, DROP_RTR_ROUTE_LOOP);
return;
}
// * Packet I'm forwarding...
else {
if(--iph->ttl_ == 0) {
drop(p, DROP_RTR_TTL);
return;
}
}
if (( src != myaddr_) && (iph->dport()== ROUTER_PORT))

{
processUpdate(p);
}
else
{
forwardPacket(p);
}
}
static class DSDVClass:public TclClass
{
public:
DSDVClass ():TclClass ("Agent/DSDV")
{
}
TclObject *create (int, const char *const *)
{
return (new DSDV_Agent ());
}
} class_dsdv;
DSDV_Agent::DSDV_Agent (): Agent (PT_MESSAGE), ll_queue (0), seqno_ (0),
myaddr_ (0), subnet_ (0), node_ (0), port_dmux_(0),
184
periodic_callback_ (0), be_random_ (1), use_mac_ (0), verbose_ (1), trace_wst_

(0), lasttup_ (-10), alpha_ (0.875), wst0_ (6), perup_ (15),
min_update_periods_ (3) // constants
{
table_ = new RoutingTable ();
helper_ = new DSDV_Helper (this);
trigger_handler = new DSDVTriggerHandler(this);
bind_time ("wst0_", &wst0_);
bind_time ("perup_", &perup_);
bind ("use_mac_", &use_mac_);
bind ("be_random_", &be_random_);
bind ("alpha_", &alpha_);
bind ("min_update_periods_", &min_update_periods_);
bind ("verbose_", &verbose_);
bind ("trace_wst_", &trace_wst_);
//DEBUG
address = 0;
#ifdef TESLA
wst0_ = 0;
#endif
}
void
DSDV_Agent::startUp()
{
rtable_ent rte;
rte.dst = myaddr_;
rte.hop = myaddr_;
rte.metric = 0;
rte.seqnum = seqno_;
seqno_ += 2;
rte.advertise_ok_at = 0.0; // can always advert ourselves
rte.wst = 0;
rte.timeout_event = 0; // Don't time out our localhost :)
rte.q = 0; // Don't buffer pkts for self!
table_->AddEntry (rte);
periodic_callback_ = new Event ();
Scheduler::instance ().schedule (helper_, periodic_callback_,jitter
(DSDV_STARTUP_JITTER, be_random_));
}
int
DSDV_Agent::command (int argc, const char *const *argv)
{
if (argc == 2)
{
185
if (strcmp (argv[1], "start-dsdv") == 0)

{
startUp();
return (TCL_OK);
}
else if (strcmp (argv[1], "dumprtab") == 0)
{
Packet *p2 = allocpkt ();
hdr_ip *iph2 = HDR_IP(p2);
rtable_ent *prte;
printf ("Table Dump %d[%d]\n----------------------------------\n",
iph2->saddr(), iph2->sport());
trace ("VTD %.5f %d:%d\n", Scheduler::instance ().clock (),
iph2->saddr(), iph2->sport());
Packet::free (p2);
output_rte ("\t", prte, this);
printf ("\n");
return (TCL_OK);
}
else if (strcasecmp (argv[1], "ll-queue") == 0)
{
if (!(ll_queue = (PriQueue *) TclObject::lookup (argv[2])))
{
fprintf (stderr, "DSDV_Agent: ll-queue lookup of %s failed\n", argv[2]);
return TCL_ERROR;
}
return TCL_OK;
}
}
else if (argc == 3)
{
if (strcasecmp (argv[1], "addr") == 0) {
int temp;
temp = Address::instance().str2addr(argv[2]);
myaddr_ = temp;
return TCL_OK;
}
TclObject *obj;
if ((obj = TclObject::lookup (argv[2])) == 0)
{
fprintf (stderr, "%s: %s lookup of %s failed\n", __FILE__, argv[1],
argv[2]);
return TCL_ERROR;
}
if (strcasecmp (argv[1], "tracetarget") == 0)
{
tracetarget = (Trace *) obj;
return TCL_OK;
}
186
else if (strcasecmp (argv[1], "node") == 0) {

node_ = (MobileNode*) obj;
return TCL_OK;
}
else if (strcasecmp (argv[1], "port-dmux") == 0) {
port_dmux_ = (NsObject *) obj;
return TCL_OK;
}
}
return (Agent::command (argc, argv));
}
187
Appendix E
Network Simulator Ns-2
E.1. Introduction
The simulation environment consists of a set of wireless and mobile networking
extensions that we have created Broch 1998, also, Ns-2 simulator is used because its
network simulator ns-2 is a popular and powerful simulation environment, and the
number of NS-2 users has increased greatly in recent years. Although it was originally
designed for wired networks, NS-2 has been extended to work with wireless
networks, including wireless LANs, mobile ad-hoc networks MANET, and sensor
networks and can simulate several network protocols such as TCP, UDP, multicast
routing, etc; however, the Network Animator (NAM) for NS-2 is used as a
visualization tool NS-2 is primarily useful for simulating local. More recently, support
has been added for simulation of large satellite and ad-hoc wireless networks. Ns-2 is
an open source discrete event simulator used by the research community for research
in networking. The ns-2 simulation software are developed at the University of
California at Berkeley and the Virtual Inter Network Test bed (VINT) Project Fall
1997. It is constantly under development by an active community of researchers. The
standard ns-2 distribution runs on Linux. However, a package for running ns-2 on
cygwin (Linux Emulation for Windows) is available. The latest version at the time is
ns-2.31, Where the old version as 2.29, 2.28, 2.27, 2.26, 2.1b9, 2.1b8, 2.1b7, 2.1b6,
2.1b5, 2.1b4, 2.1b3, 2.1b2, 2.1b1, 2.0 and 2.0b17. It can run both in UNIX and
Windows. But to run in Windows, it requires installing first cygwin to set the
computer environment as UNIX environment and second installing ns-2. These
extensions provide a detailed model of the physical and link layer behavior of a
wireless network and allow arbitrary movement of nodes within the network. At the
physical layer, we provide realistic modeling of factors such as free space and ground
reflection propagation, transmission power, antenna gain, receiver sensitivity,
propagation delay, carrier sense. At the link layer, with model the complete
Distributed Coordination Function (DCF) Media Access Control (MAC) protocol of
the IEEE 802.11 wireless LAN protocol standard IEEE 1997, along with the standard
Internet Address Resolution Protocol (ARP) Plummer 1982. These wireless and
mobile networking extensions are available from the Carnegie Mellon University
Monarch Project and have been widely used by other researchers; a version of them
have also now been adopted as a part of the standard VINT release of Ns-2. That has
done a simulation Ns-2 study with this environment, analyzing the behavior and
performance of routing protocols and comparing it to other proposed routing protocols
for ad-hoc networks. To setup and run a simulation, a user writes an OTcl script
(object-oriented Tool command language), which is a simulation program to initiate
an event scheduler, set up the network topology using the network objects and
plumbing functions in the library, and to tell traffic sources when to start and stop
transmitting packets through the event scheduler. When NS-2 which works as OTcl
interpreter receives the OTcl script, it will set environment parameters following the
received script. If a user wants to make a new network object, it will be easy to make
a compound object from the object library, and plumb the data path through the object
rather than write a new one. When the simulation is finished, the simulation results
are produced in one or more text-based output files that contain detailed simulation
data, which can be used to analyze directly or can be used in the graphical user
interface NAM. This graphical user interface shows the simulation result in an easy
188
way. The language that is written in NS-2 is not only OTcl but also C++. The event
scheduler and the basic network component objects in the data path are written and
compiled using C++ to reduce packet and event processing time. These compiled
objects need the OTcl linkage to create a matching OTcl object for each of the C++
objects to be able to work with OTcl interpreter. It can run both in Unix and
Windows.
E.2. Wireless Sensor network simulator

They are several simulators that have been used in sensor network research, some
simulators that can be used to evaluate the wireless sensor networks:
E.2.1. SensorSim:
SensorSim, which has been built on NS-2, is a simulation framework for sensor
networks (SensorSim). It provides sensor channel models, energy consumers;
lightweight protocol stacks for wireless micro sensors, scenario generation and hybrid
simulation. The sensor channel models the dynamic interaction between the sensor
nodes and the physical environment. At each node, energy consumers are said to
control the power in multiple modes to efficiently use the power and prolong the
nodes lifetime. But this simulator is no longer developed, therefore, no more
available.
E.2.2. J-Sim:
J-Sim (formerly known as JavaSim), is an object-oriented, component-based,
compositional simulation environment written in Java. The key benefits of J-Sim are
that modules can be easily added and deleted in a plug-and-play manner, and it is also
useful both for network simulation and emulation by incorporating one or more real
sensor devices. J-Sim provides supporting target, sensor and sink nodes, sensor
channels and wireless communication channels, physical media, power models and
energy models.
E.2.3. GloMoSim:
GloMoSim (Global Mobile Information system Simulate), which is a scalable
simulation environment written both in C and Parsec, is capable of parallel discrete-
event simulation. GloMoSim is a collection of library modules each of which
simulates a specific wireless communication protocol in the protocol stack.
GloMoSim is widely used to simulate Ad-hoc and Mobile wireless networks.
E.2.4. SENS:
SENS (Sensor, Environment, and Network Simulator) is a high level sensor network
simulator for wireless sensor network applications. It consists of application, network
and physical components which are interchangeable and extensible. Application
components are used to simulate the execution on a sensor node, network components
are used to simulate the packet to send and receive functions of a sensor node, and
physical components are use to model sensors, actuators and power and interact with
the environment. Users can modify these existing environments. SENS features the
application portability to enable direct portability between the simulator and real
sensor nodes.
E.2.5. OMNeT++:
OMNeT++ (Objective Modular Network Test-bed in C++) is a wireless sensor
network simulator which is based on the discrete event simulation framework. As the
OMNeT++ model collects hierarchy modules, it is possible to capture the complex
system. These modules are separated into two types which are simple and compound.
Simple modules are programmed in C++, while compound modules which consist of
simple modules are programmed in a high-level language. To communicate between
189
modules, the exchanging messages which represent the packets in the network are
used. OMNeT++ supports users to study the effect of scale, node level architecture,
energy efficiency, communication architecture, system architecture, protocols etc.
E.3. Network Components of Ns-2 in a mobile node

Mobile Node is the basic Ns-2 Node object as shown in figure 1 with added
functionalities like movement, ability to transmit and receive on a channel that allows
it to be used to create mobile, wireless simulation environments. The class Mobile
Node is derived from the base class Node. Mobile Node is a split object. The mobility
features including node movement, periodic position updates, maintaining topology
boundary etc are implemented in C++ while plumbing of network components within
Mobile Node itself (like classifiers, dmux , LL, Mac, Channel etc) have been
implemented in Otcl.
Figure 1: General Architecture of a mobile node in Ns-2
E.3.1. Link Layer:

The link layer (LL) used by mobile node is has an Address Resolution Protocol (ARP)
module connected to it which resolves all IP to hardware (Mac) address conversions.
Normally for all outgoing (into the channel) packets, the packets are handed down to
the LL by the Routing Agent. The LL hands down packets to the interface queue. For
all incoming packets (out of the channel), the mac layer hands up packets to the LL
which is then handed off at the node_entry_ point.
E.3.2. Address Resolution Protocol:
The Address Resolution Protocol (APR) module receives queries from Link layer. If
ARP has the hardware address for destination, it writes it into the Mac header of the
packet. Otherwise it broadcasts an ARP query, and caches the packet temporarily. For
190
each unknown destination hardware address, there is a buffer for a single packet.
Incase additional packets to the same destination is sent to ARP, the earlier buffered
packet is dropped. Once the hardware address of a packet’s next hop is known, the
packet is inserted into the interface queue.
E.3.3. Interface Queue:
The class PriQueue is implemented as a priority queue which gives priority to routing
protocol packets, inserting them at the head of the queue. It supports running a filter
over all packets in the queue and removes those with a specified destination address.
E.3.4. Mac Layer:
The IEEE 802.11 distributed coordination function (DCF) Mac protocol has been
implemented. It uses a RTS/CTS/DATA/ACK pattern for all unicast packets and
simply sends out DATA for all broadcast packets. The implementation uses both
physical and virtual carrier sense.
E.3.5. Network Interfaces (Physical layer):

The Network Interphase layer serves as a hardware interface which is used by mobile
node to access the channel. The wireless shared media interface is implemented as
class Phy/WirelessPhy. This interface subject to collisions and the radio propagation
model receives packets transmitted by other node interfaces to the channel. The
interface stamps each transmitted packet with the meta-data related to the transmitting
interface like the transmission power. This meta-data in pkt header is used by the
propagation model in receiving network interface to determine if the packet has
minimum power to be received and/or captured and/or detected (carrier sense) by the
receiving node.
E.3.6. Radio Propagation Model:
These models are used to predict the received signal power of each packet. At the
physical layer (phy) of each wireless node, there is a receiving threshold. When a
packet is received, if its signal power is below the receiving threshold, it is marked as
error and dropped by the MAC layer. NS supports the free space model (at near
distances), two-ray ground reflection model (at far distances) and the shadowing
model (includes fading).
E.3.7. Antenna:
An omni-directional antenna having unity gain is used by mobile nodes.
E.3.8. Routing Agents:
All packets destined for the mobile node is routed directly by the address de-
multiplexer to it is port de-multiplexer. The port de-multiplexer hands the packets to
the respective destination agents. A port number of 255 is used to attach routing agent
in mobile nodes. The mobile nodes also use a default-target in their classifier (or
address de-multiplexer). In the event a target is not found for the destination in the
classifier (which happens when the destination of the packet is not the mobile node
itself), the packets are handed to the default-target which is the routing agent. The
routing agent assigns the next hop for the packet and sends it down to the link layer.
The only four different ad-hoc routing protocols are currently implemented in Ns-2
simulator for mobile networking. They are DSDV, DSR, AODV and TORA.
E.3.4. Conceptual model in Ns-2 network simulator:

NS-2 is built as a number of simulation layers that strongly resembles the Open
Systems Interconnection (OSI) reference model. This is no coincidence the
modularization of protocols enables users of NS-2 to combine the protocol suite that
suits their needs (for instance TCP over IP over wired Ethernet). The layering
191
architecture of NS-2 is shown in figure 2. NS-2 is developed in C++ with the

exception of the simulation control module which is in TCL (Tool Command
Language). The simulation control module uses a scripting language like Tcl, because
this enables user to specify advanced and highly customized simulations without
tampering with the C++ code. Where File Transfer Protocol FTP is a commonly used
protocol for exchanging files over any network that supports the TCP/IP protocol
Figure 2: The layering architecture of NS-2 network simulator
E.3.5.5. Running a New Routing Protocol

A new routing protocol for ns-2 has to be coded in C/C++ (there is no support for
Java yet). The output for this file can be incorporated into the simulator by specifying
the file name in the Make file (/home/administrator/ns-allinone-2.31/ns-2.31) and
building Ns-2 again. If the routing protocol involves a different packet format than
what is defined in packet.h, this must also be specified in the header file. More details
can be found in tutorial.
E.4. Setup of Installing Ns-2

The standard Ns-2 distribution runs on Linux. However, a package for running Ns-2
on cygwin (Linux Emulation for Windows) is available. In this mode, Ns-2 runs in the
Windows environment on top of cygwin as shown in the figure 3.
Ns-2 ver. 2.31

Cygwin 1.3.12
WindowsXP
Figure 3: Ns-2 over cygwin
192
Procedure for installation ns-2 over cygwin, installing ns-2 can be time-consuming for
beginners, especially when building it in a cygwin environment. The detailed
instructions for downloading and building Ns-2 on cygwin.
E.4.1. Installing Cygwin under WindowsXp

To be able to use the Network Simulator you have to run it in a Linux platform. As
the computers we have used did not have a LINUX platform installed we have used a
simulator of LINUX over Windows. This emulator is called cygwin and let us to
installed NS-2 over it. When installing cygwin with the setup.exe program, you'll
have to consider some points:
 Make sure your cygwin installation directory does not contain any spaces
(C:\Cygwin). Spaces in the root directory seem to be causing a lot of problems
 Make sure you don't have spaces in your login name in windows. If you do,
change your login name.
 Install all packages in cygwin like the following packages as: gcc, gcc-g++,
gawk, tar, gzip, make, patch, perl, and w32api. Any missing packages can be
added with cygwin's setup.exe.
E.4.2. Building Ns-2 ver 2.31 under Cygwin
Download ns-allinone-2.31.tar.gz and unpack it to a directory reachable from cygwin.
Start the cygwin Shell (bash), cd into your ns directory and issue:
./install
At the command prompt the installer will check if all prerequisites are met, and if so,
will build the whole package. The installation is similar to Unix install, so at the end
of the build process you're advised to set some environment variables. This step is
required for ns to work. You might want to add these variables to your ~/.bashrc, so
you don't have to retype them every time. Finally, you might want to check your
installation with
./validate
E.5. Network Animator

Network Animator (NAM) is an animation tool for viewing network simulation traces
and real world packet traces. It supports topology layout, packet level animation and
various data inspection tools. Before starting to use NAM, trace files need to be
created. This trace file is usually generated by NS-2. It contains topology information,
e.g. nodes and links, as well as packet traces. During a simulation, the user can
produce topology configurations, layout information and packet traces using tracing
events in Ns-2. Once the trace file is generated, NAM can be used to animate it. Upon
startup, NAM will read the trace file, create topology, pop up a window, do layout if
necessary and then pause at time 0s. Through it is user interface; NAM provides
control over many aspects of animation.
193

Secure Routing Algorithm For Ad-Hoc Sens PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Secure Routing Algorithm For Ad-Hoc Sens PDF

Hochgeladen von

Copyright:

Verfügbare Formate

ARAB ACADEMY FOR SCIENCE, TECHNOLOGY AND MARITIME TRANSPORT

College of Engineering and Technology

SECURE ROUTING ALGORITHM

Prof. Dr. Mohamed Hashem Abd El-Aziz Dr. Mohamed T.EL-Sonni

‫ﺧﻮارزﻣﯿﺔ اﻟﺘﻮﺟﯿﮫ اﻵﻣﻦ ﻟﺸﺒﻜﺎت ذاﺗﯿﺔ اﻟﺘﻨﻈﯿﻢ )‪(Ad-Hoc‬‬

‫رﺳﺎﻟﺔ ﻣﻘﺪﻣﺔ ﻹﲤﺎم ﻣﺘﻄﻠﺒﺎت اﳊﺼﻮل ﻋﻠﻰ درﺟﺔ اﳌﺎﺟﺴﺘﲑ‬

‫أﳏﻤﺪ ﺑﺸﲑ أﺑﺮاﻫﻴﻢ ﻋﻠﻴﻮة‬

‫ﯾﻌرض ﻧﺑذة ﻋن ﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ‪,‬‬ ‫اﻟﻔﺻل اﻷول‬

‫اﻟﻔﺻل اﻟﺛﺎﻧﻲ ﻣﻘدﻣﺔ ﻋن اﻟﺗوﺟﯾﺔ ﻟﺷﺑﻛﺎت ذاﺗﯾﺔ اﻟﺗﻧظﯾم )‪ (Ad-Hoc‬ﻟﻠﻣﺣﺳﺳﺎت اﻟﻣﺗﻧﻘﻠﺔ‬

‫ﯾﺷرح ﺧوارزﻣﯾﺔ اﻟﺗوﺟﯾﺔ اﻵﻣــن )‪ (SEAD‬ﻟﺷﺑﻛﺎت ذاﺗﯾـﺔ اﻟﺗﻧظﯾم‬ ‫اﻟﻔﺻل اﻟراﺑﻊ‬

‫اﻟﻔﺻل اﻟﺧﺎﻣس ﯾﺷﻣل اﻟﺧﺎﺗﻣﺔ واﻟﻌﻣل اﻟﻣﺳﺗﻘﺑﻠﻲ‪.‬‬

Second, I would like to present my deep special thanks to my supervisors

Third, I am very grateful to my professors were always supporting me to learn and

4.1. Summary .............................................................................................................133

ACK Acknowledge Receipt of a Packet

NRL Normalized routing load

Table 2.1: Dijkstra's algorithm with source node A of network I 26

1.1 Overview of Mobile Ad-hoc Sensor Network

1.1.2. Sensor Nodes

Figure 1.1: sensor node hardware

1.1.3. Sensor Node Components

 Power Unit: Power consumption is a major weakness of sensor networks. Any

1.1.4. Characteristics and Requirements of Sensor Nodes

1.1.3. Classification of Wireless Networks

1.1.3.1. Infrastructure Networks

Figure 1.2 Infrastructure wireless networks

Figure 1.3: Infrastructure network

1.1.3.2. Infrastructure less (Ad-hoc) Networks

Figure 1.4: Ad-hoc Network (peer to peer)

1.1.4. Common Architectures of Mobile Network

Figure 1.5: A two-tier mobile ad-hoc network [33].

Figure 1.6: A flat mobile ad-hoc network [33].

1.1.5. Application of Mobile Ad-Hoc Networks

effectively. As a result, as shown in figure 1.7 some well-known ad-hoc network

Figure 1.7: Example applications of MANET [72]

 Military applications: Wireless sensor networks can be an integral part of military

1.1.6. Characteristics of Mobile Ad Hoc Networks

protocols, [Destination-Sequenced Distance Vector (DSDV), Ad-Hoc On-Demand

1.5 Thesis Structure and Layout

Chapter 2 describes the detailed methodologies of routing algorithm for ad-hoc

Chapter 3 Comparison and Performance Analysis of Ad-hoc Routing Protocols &

Chapter 4 Performance Analysis of Secure Routing Algorithm for Ad-hoc Sensor

List of References, Glossary and Published Paper.

Appendix A attached implementation code C/C++ program to compute least coast

three networks, Network I, Network II and example of Book to test our

Appendix D attached implementation code C/C++ of SEAD: Secure Efficient Ad-hoc

Appendix E Simulator Ns-2.

Routing & Secure Algorithm for

2.2. Least-Cost Algorithms

2.2.1. Dijkstra's algorithm

Figure 2.1: Steps of Dijkstra's algorithm [53]

Figure 2.2: Network I

2.2.2. Bellman-Ford algorithm

2.3. Routing Algorithm in Wired Networks

2.3.1. Distance vector

Figure 2.3: Every node maintains a routing table

Figure 2.4: Node B broadcasts the new routing information to neighbors

Figure 2.5: Broadcasts to update tables of C, B, A with new entry of node D

2.3.2. Link state Routing

Figure 2.7: Flooding example (hop count = 3)

2.4. Routing Algorithm in a Mobile Ad-hoc Networks

2.4.2. Classification of Routing Protocols in MANETs

2.4.3. Problems with Routing in Mobile Ad-hoc Networks

/^s - Nl AGT.-Is (\d{1,3})\.\d{1,3} -Id (\d{1,3})\.\d{1,3}.-It cbr.-Ii (\d{1,6})/

/^r -t (\d{1,3}\.\d{9}).-Nl AGT.-Is (\d{1,3})\.\d{1,3} -Id (\d{1,3})\.\d{1,3}.-It cbr.-

/^[s|f].-Nl RTR.-It (?:AODV|DSR|message) -Il (\d{1,4})/

/^[d].-Nl RTR.-It (?:AODV|DSR|message) -Il (\d{1,4})/

/^[d].-Nl IFQ .-It (?:AODV|DSR|message) -Il (\d{1,4})/