Conference PaperPDF Available

Dynamic Source Routing (DSR) Protocol Implementation in ns-3

Authors:

Abstract and Figures

Routing protocols are essential to the performance of wireless networks especially in mobile ad-hoc scenarios. The development of new routing protocols requires comparing them against well-known protocols in various simulation environments. In this paper, we present an overview of the well-known MANET routing protocols and the implementation details of the DSR routing protocol in the ns-3 network simulator. We verify DSR routing performance under various scenarios and compare its performance against other protocols implemented in ns-3: AODV, DSDV, and OLSR. Our results show that the performance of DSR shares similar characteristics with AODV yet has slightly higher overall performance results in terms of the routing metrics we use.
Content may be subject to copyright.
Dynamic Source Routing (DSR)
Protocol Implementation in ns-3
Yufei Cheng, Egemen K. Çetinkaya, and James P.G. Sterbenz
Information and Telecommunication Technology Center
Department of Electrical Engineering and Computer Science
The University of Kansas, Lawrence, KS 66045, USA
{yfcheng, ekc, jpgs}@ittc.ku.edu
ABSTRACT
Routing protocols are essential to the performance of wire-
less networks especially in mobile ad-hoc scenarios. The
development of new routing protocols requires comparing
them against well-known protocols in various simulation en-
vironments. In this paper, we present an overview of the
well-known MANET routing protocols and the implementa-
tion details of the DSR routing protocol in the ns-3 network
simulator. We verify DSR routing performance under var-
ious scenarios and compare its performance against other
protocols implemented in ns-3: AODV, DSDV, and OLSR.
Our results show that the performance of DSR shares simi-
lar characteristics with AODV yet has slightly higher overall
performance results in terms of the routing metrics we use.
Categories and Subject Descriptors
I.6 [Simulation and Modeling]: General, Model Devel-
opment, Model Validation and Analysis; C.2.2 [Computer-
Communication Networks]: Network Protocols — rout-
ing protocols
General Terms
Implementation, Analysis, Testing, Verification
Keywords
DSR implementation, MANET, mobile ad hoc routing pro-
tocol, ns-3, AODV, DSDV, OLSR
1. INTRODUCTION
Mobile ad hoc networks (MANETs) [5] are self-configuring
networks with mobile nodes connected by wireless links to
form an arbitrary topology without an infrastructure. In
MANETs, nodes self-organise and act as both end and in-
termediate systems. The two major challenges for routing
in MANETs are the dynamic topologies caused by mobil-
ity, and maintaining connectivity with wireless channels and
nodes moving out of range from one another.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Wns3 2012 March 23, Desenzano, Italy.
Copyright 2012 .
Many routing protocols for MANETs have been proposed
with four of them arguably the most prominent ones in the
research community: AODV [18, 16], DSDV [17], DSR [8,
9], and OLSR [4], due to their early emergence and varied
characteristics. The operational characteristics and perfor-
mance of these four protocols provide an important baseline
with which new protocols should be compared.
Simulation has become the backbone for MANET research,
since the simulation environment provides easily accessible
resources to study new protocols or models [5, 10]. As an
open-source simulator, ns-2 [13] has been widely employed
in the academic research community. However, in response
to a number of deficiencies, the ns-3 discrete event network
simulator [14] is proposed as its successor and is still un-
der development, providing greater flexibility, evolvability,
modularity, and the support of heterogeneity including hy-
brid wired and wireless models.
Despite its advantages, ns-3 is relatively new with lim-
ited number of protocol models incorporated into its release
distribution [19]; existing built-in MANET routing proto-
cols are limited to the optimised link state routing (OLSR)
and ad hoc on-demand distance vector (AODV) protocols.
We have implemented destination-sequenced distance vector
(DSDV) protocol and incorporated it in the distribution [11].
To have a fairly complete set of protocols for performance
comparison, we have developed an ns-3 implementation of
the dynamic source routing (DSR) protocol1. DSR is one
of the major MANET routing protocols proposed [9], and it
provides a baseline reactive source routing for performance
comparison and for reproduction of previous results (e.g. [1])
in the ns-3 environment.
In this paper, we present our ns-3 implementation of the
DSR routing protocol and compare its performance with
other existing MANET routing protocol models in ns-3. The
rest of the paper is organised as follows: Section 2 presents
background and related work on MANET protocols. Sec-
tion 3 presents the implementation details of DSR in ns-
3. Performance evaluation and comparison of DSR against
AODV, DSDV, and OLSR are presented in Section 4. Fi-
nally, Section 5 is our conclusions and future work.
2. BACKGROUND AND RELATED WORK
In this section, we present background information about
MANETs, and briefly describe the four MANET routing
protocols simulated in this paper: DSR, AODV, DSDV, and
OLSR.
1Source code is at http://code.nsnam.org/tomh/ns-3-dsr-2
3HUPLVVLRQWRPDNHGLJLWDORUKDUGFRSLHVRIDOORUSDUWRIWKLVZRUNIRU
SHUVRQDORUFODVVURRPXVHLVJUDQWHGZLWKRXWIHHSURYLGHGWKDWFRSLHV
DUHQRWPDGHRUGLVWULEXWHGIRUSURILWRUFRPPHUFLDODGYDQWDJHDQGWKDW
FRSLHVEHDUWKLVQRWLFHDQGWKHIXOOFLWDWLRQRQWKHILUVWSDJH7RFRS\
RWKHUZLVHWRUHSXEOLVKWRSRVWRQVHUYHUVRUWRUHGLVWULEXWHWROLVWV
UHTXLUHVSULRUVSHFLILFSHUPLVVLRQDQGRUDIHH
:160DUFK'HVHQ]DQRGHO*DUGD,WDO\
&RS\ULJKWk,&67
'2,LFVWVLPXWRROV
3HUPLVVLRQWRPDNHGLJLWDORUKDUGFRSLHVRIDOORUSDUWRIWKLVZRUNIRU
SHUVRQDORUFODVVURRPXVHLVJUDQWHGZLWKRXWIHHSURYLGHGWKDWFRSLHV
DUHQRWPDGHRUGLVWULEXWHGIRUSURILWRUFRPPHUFLDODGYDQWDJHDQGWKDW
FRSLHVEHDUWKLVQRWLFHDQGWKHIXOOFLWDWLRQRQWKHILUVWSDJH7RFRS\
RWKHUZLVHWRUHSXEOLVKWRSRVWRQVHUYHUVRUWRUHGLVWULEXWHWROLVWV
UHTXLUHVSULRUVSHFLILFSHUPLVVLRQDQGRUDIHH
:160DUFK'HVHQ]DQRGHO*DUGD,WDO\
&RS\ULJKWk,&67
'2,LFVWVLPXWRROV

2.1 Routing Protocol Types
MANET routing protocols can be classified into two cat-
egories based on their update mechanisms: proactive and
reactive. We briefly these types; a more detailed explana-
tion is presented in our companion paper on DSDV [11].
2.1.1 Proactive Table-Driven Routing Protocols
Proactive routing protocols maintain updated routing in-
formation of all the nodes in the network by periodically
distributing routing tables among each other. The advan-
tage is that the routes to any destination are ready to use
when needed. However, routing tables grow with the size
and node density of the network, rather than the number of
routes actually needed. The overhead of flooding route ad-
vertisements to maintain convergence is a major drawback
of proactive protocols. Destination-sequenced distance vec-
tor (DSDV) [17] and optimised link state routing (OLSR) [4]
are two major proactive routing protocols. DSDV maintains
a routing table with entries for all the nodes. In order to
reduce the amount of overhead, two types of update packets
are used, with one type carrying all the available routing
information while the other one carries only the informa-
tion changed since the previous full update. In order to
avoid routing loops, a sequence number is used. OLSR is
a point-to-point protocol based on the traditional link-state
algorithm. It uses HELLO messages at each node to dis-
cover neighbor information and select a set of multipoint
relays (MPRs). Only MPRs are allowed to rebroadcast the
received messages. OLSR floods topology data frequently
enough over the network to make sure all nodes are syn-
chronised with link state information.
2.1.2 Reactive On-Demand Routing Protocols
Unlike proactive routing protocols, reactive routing pro-
tocols construct routes only when needed for data transmis-
sion. When a route to a new destination is required, the
node initiates a route request and must wait until the route
is discovered. There is no need to distribute their rout-
ing information periodically or to maintain routes for all
the nodes in the network. The disadvantage is the delay in
finding routes to new destinations. Dynamic source routing
(DSR) [9] specified in RFC 4728 [8] and ad hoc on-demand
distance vector (AODV) [18, 16] are two well-studied reac-
tive routing protocols. DSR is an on-demand routing pro-
tocol based on the source routing concept. It contains two
major working phases: route discovery and route mainte-
nance. When a node initiates packets to one destination, it
first searches its route cache for saved route entries. If not
found, it initialises the route request process. DSR carries
the full routing information from the source to the destina-
tion in the packet header. Route maintenance is the process
to validate the source route and is managed using either
route error messages or acknowledgements. AODV is a dis-
tance vector routing protocol that operates only on demand.
When a route does not exist to a give destination, a route
request (RREQ) message is flooded by the source and by the
intermediate nodes that do not have previous routes in their
routing table. Once the RREQ message reaches the destina-
tion, the node responds by unicasting a route reply (RREP)
message. This way nodes along this path set up forward-
ing entries in their routing tables and form the whole route.
AODV uses sequence numbers created by the destination for
each route entry to avoid routing loops.
2.2 Previous DSR Implementations
DSR has been implemented and analysed in a number of
simulation tools. Most of the previous performance com-
parisons use the ns-2 network simulator [13]; including per-
formance comparison with DSR, AODV, and DSDV [1, 7].
However, there are also studies that use different simula-
tion tools. AODV and DSR performance comparison is per-
formed using GloMoSim [12], QualNet [15], and ns-2 [2, 6].
Although being the predecessor of ns-3, the ns-2 implemen-
tation of DSR cannot be ported to the ns-3 environment
due to the significantly different simulation architecture and
code structure, however, the ns-2 implementation was used
to provide insight and guide design decisions for our ns-3
implementation.
3. DSR MODULE FOR ns-3
This section describes our implementation of DSR. The
two major components of the DSR operation are route dis-
covery and route maintenance. All the major attributes used
in this implementation are listed in Table 1. The relation
among all the classes implemented in this module is shown
in Figure 1.
We implemented the DSR routing protocol ns3::dsr::Dsr
Routing in ns-3 by extending from the abstract base class
ns3::Ipv4L4Protocol.Thens3::dsr::DsrFsHeader and
ns3::dsr::DsrOptionHeader is extended from ns3::Header,
and they are essentially shim headers between the transport
layer and network layer. We have also declared ns3::dsr::
RouteCache to store all the routes that have been discovered
in previous route discovery process. Similarly, we have de-
clared the ns3::dsr::SendBuffer class to store all unsent
data packets and ns3::dsr::RreqTable to avoid duplicate
route requests as well as control the rate of consecutive route
requests for one destination. The ns3::dsr::MaintainBuff
is used to store the data packet when sent out from the send
buffer and waiting for delivery of acknowledgment from the
next hop node. An in-depth explanation of all these classes
is presented in the following sections.
Most of the other routing protocol implementations in ns-
3 are IP dependent, which render plugging-in DSR as a shim
between IP and the transport layer protocol problematic.
In the current implementation of DSR in ns-3, it acts as
ns3::Ipv4L4Protocol, which uses the services of IP. There-
fore, DSR should bypass IP’s forwarding callback mecha-
nism implemented in ns-3 and implement its own. To do
this, the destination address in IP header is always set as
the gateway address that is the next hop for the packet,
and the real destination address will be shown in the DSR
header. Figure 2 shows how DSR packets are encapsulated
within IP in ns-3.







Figure 2: DSR header encapsulation within IP

+Send()
+SendPacket()
+SchedulePacketRetry()
+SendRequest()
+SendReply()
+SendAck()
+Receive()
-PromiscReceive()
-requestPeriod
-requestRetries
-maxMaintRexmt
-discoveryHopLimit
-passiveAckTimeout
-maxRequestPeriod
-gratReplyHoldoff
DsrRouting
+GetRreqCnt() : unsigned int
+RemoveRreqEntry()
+FindAndUpdate()
+RemoveLeastExpire()
+FindSrc() : bool
+CheckUniqueRreqId() : unsigned int
+GetRreqSize() : unsigned int
-requestTableSize
-requestIdSize
-maxRreqId
-sourceRreqEntry
-rreqTableEntry : RouteCacheEntry
-maxRequestRexmt
-maxRequestPeriod
-requestPeriod
RequestTable
+AddRoute()
+DeleteRoute()
+LookupRoute()
+DeleteAllRoutesIncludeLink()
+UpdateRouteEntry()
+SetCacheType()
+LookupRoute_Link()
+AddRoute_Link()
+RebuildBestRouteTable()
-link
-routeCacheEntry
-neighbor
-arpCache
RouteCache
+Serialize()
+Deserialize()
+SetDst()
+GetDst()
+SetHopCount()
+GetHopCount() : unsigned int
-dst
-hopCount
-dstSeqNo
DsrFsHeader
Ipv4L4Protocol
+GetRoute()
+SetRoute()
+GetNextHop()
+SetNextHop()
+GetSeqNo()
+SetSeqNo()
-IP_VECTOR
-dst
-expireTime
-reqCount
-ackTimer
RouteCacheEntry
-Table
1
-Entry
*
Header
+Serialize()
+Deserialize()
+SetDst()
+GetDst()
+SetHopCount()
+GetHopCount() : unsigned int
-dst
-hopCount
-dstSeqNo
DsrOptionsHeader
+Enqueue() : bool
+Dequeue() : bool
+DropPacketWithDst() : void
+Find() : bool
+GetMaxQueueLen() : unsigned int
+SetMaxQueueLen() : void
+GetSendBufferTimeout() : signed int
+SetSendBufferTimeout() : void
-packet
-dst
-expire
-protocol
-SendBuffEntry
SendBuffer
+Enqueue() : bool
+Dequeue() : bool
+DropPacketWithNextHop() : void
+Find() : bool
+GetMaxQueueLen() : unsigned int
+SetMaxQueueLen() : void
+GetMaintainBufferTimeout()
+SetMaintainBufferTimeout()
+PromiscEqual() : bool
-packet
-ourAddress
-nextHop
-src
-dst
-segmentsLeft
-expire
-MaintainBuffEntry
MaintainBuffer
Figure 1: DSR class diagram
3.1 Routing Functions
The routing functions of DSR consist of two parts: route
discovery and route maintenance. We illustrate these two
mechanisms in detail as follows.
3.1.1 Route Discovery
When a node S has a packet to send to some destination
node D but does not currently have a route to that node
in its route cache, the node S saves the data packet in its
send buffer and initiates route discovery process to find a
route. To prevent from buffering the packets indefinitely,
packets are dropped if they wait in the send buffer for more
than MaxSendBuffTime (the default is 30 s). For route dis-
covery, S transmits route request packets as local broadcast
messages, specifying the target address and a unique request
identifier. The node receiving the route request packet will
check its identifier and target address in the request header;
if the same one has been received before, the packet will be
recognised as a duplicate and silently dropped. Otherwise,
it appends its own node address to a list in the route request
header and rebroadcasts it. When the route request packet
reaches its destination, the target node sends a route reply
packet back to the initiator of the request, including a copy
of the accumulated list of node addresses in its reply header.
When the route reply reaches the initiator of the request, it
caches the new route in its route cache. Upon receiving the
route reply message, node S will use the source route from
route reply to send the data packet to D. Furthermore, all
the intermediate nodes receiving route reply packet will cut
the route from their own to the destination and save it in
their own route cache.
Another feature of the route request packet is that when
an intermediate node receives a packet, it searches the route
cache for route to the destination address. If there is an
existing route, the node attaches the route found to the route
received from route request header, which forms a full route
from the source to the destination. Then the node sends
back a route reply packet to the source with the full route.
3.1.2 Route Maintenance
Route maintenance is the mechanism by which the source
node or any intermediate node is able to detect link break-
age when the network topology has changed such that the
source route in the source route header no longer works. This
is a hop-by-hop operation and there are three mechanisms
to verify the delivery of data packets to the next hop as
discussed in Section 3.2. If the data packet fails to de-
liver to the next hop, the sender will retransmit the data
packet. After MaintenanceRetries times of retransmission
fails, a route error packet will be sent out. The packet will
not be dropped immediately; instead, a salvage mechanism
will start by searching the route cache for alternative routes
to the destination. If no alternative route is found, or the
data packet has already been salvaged for MaxSalvageCount
times, this data packet will be dropped.
DSR has a mechanism of removing stale route entries from
the node’s route cache. If a node does not use the route
for a period of time, that route entry will be expired and
removed from the route cache. In our implementation, DSR
waits for RouteCacheTimeout before removing the entries,
with default value as 300 s.
3.2 Acknowledgment Mechanisms
There are three types of acknowledgement mechanisms
specified in the RFC 4728: link-layer, passive, and network-
layer acknowledgement. If the media access control (MAC)
protocol in use can provide feedback for the successful de-
livery of data packets, then it should be used to notify the

delivery of data packets and maintain the route validity. It
requires the MAC protocol to be able to provide layer-2 feed-
back to the network layer about the data packet delivery.
However, in ns-3, only AdhocWifiMac supports the layer-2
feedback mechanism. When link-layer acknowledgement is
not available, but passive acknowledgement is, it should be
used when the nodes can put themselves into promiscuous
receive mode. In the absence of the above two acknowl-
edgement mechanisms, the node should use network layer
acknowledgements. When this mechanism is used, acknowl-
edgement request header will be attached to the data packet
before being transmitted. The acknowledgement will be sent
back to the sender to notify the delivery of data packets.
3.3 DSR Optimisation Mechanisms
Several optimisations have been specified in RFC 4728:
salvaging, gratuitous route reply, and increased spreading of
route errors. The salvaging mechanism is triggered when the
forward link is broken and there is an alternative route to the
destination in the node’s route cache. Instead of dropping
the data packet, the node will try to retransmit it with the
newly found route.
The gratuitous route reply is used when the node promis-
cuously received a data packet destined for other nodes but
is named in the later unused portion of the packet’s source
route. Then it can infer that the intermediate nodes before
itself in the source route are no longer necessary, and a gra-
tuitous route reply packet will be sent back to the source
with the shorter route.
The increased spreading of route errors means that when
the node receives the route error for the data packet it orig-
inates, it is the source of the data packet and the node will
piggy-back the route error packet in the next route request
process. This way it ensures that the route error packet
spreads to the neighboring nodes and gets the expired route
entries deleted.
3.4 DSR Data Structures
There are several conceptual data structures that are im-
portant to support the DSR operation. Here we introduce
the essential ones.
RouteCache contains all the routing information collected
from route discovery process. The structure of the DSR
RouteCache is implemented as follows. Each entry imple-
mented by the RouteCacheEntry class corresponds to a node
in the network and the entry is mapped to that node’s IP
address. Every entry stores the following attributes of a
node: the IP addresses from the source to the destination
saved in a vector, the destination address of the route, and
the time-stamp of the route entry when it is initially saved.
The RouteCache will save multiple route cache entries for a
single destination since DSR accepts multiple route replies.
All the route cache entries for a single destination are saved
according to the hop-count and freshness of the route. The
route with least hop count will be saved before others, and
for those routes with same hop count, the route entry that is
newly found will be saved before other routes. The Route-
Cache class has implemented functions to add,delete,update,
look up,andprint entries. Also, unlike other routing proto-
cols, DSR saves the entire source route in the route cache,
indexed only with the final destination. Therefore, when the
direct route to a certain destination is not found, the look up
route function will also search all the intermediate nodes in
every single route entry for the expected destination. If the
originating node finds any intermediate node that matches
the expected destination, the newly found route will be re-
moved from the original route and indexed with the new des-
tination address for future use. All the route cache entries
are governed by a global timeout value RouteCacheTimeout,
with a default value of 300 s. The route cache will be purged
periodically to get rid of outdated routes.
PacketBuffer is used to save data packet whenever there
is no route or the node is waiting for next hop delivery notifi-
cation. There are two types of packet buffers: Send Buffer
and Maintenance Buffer. These both buffer data packets,
the only difference is that the Send Buffer will save the
packet when receiving it from transport layer and if a route is
not found, while the packet will be saved in the Maintenance
Buffer when sent out from the Send Buffer yet is waiting
for the next hop acknowledgment. When DSR receives the
data packet from the transport protocol, it first checks the
RouteCache for previously found route entries. The data
packet is saved to Send Buffer if no existing routes are
found, and the node will initiate the route discovery process
by broadcasting Route Request packets. When the packet
in Send Buffer is sent out with Source Route header, the
data packet will be saved in Maintenance Buffer waiting
for next hop delivery notification from the acknowledgement
mechanism used. After MaxMaintenanceRetries times of re-
transmission without receiving any delivery notification, the
data packet will be removed from the Maintenance Buffer.
RreqTable is used to save route request information. It
keeps track of two parts of route request operations: route
request initiated by the node itself and request received
by this node, which are implemented as RreqRequestEntry
and RreqRequestId,respectively. RreqTableEntry saves the
route requests have been initiated by the node itself. The
fields of the route entries include the destination address
that records the specific destination this node has initiated
route requests to, the time-to-live (TTL) that allows the
node to implement a series of mechanisms to limit the trans-
mission hops of the route request packet, and the request
number that is used to record the number of consecutive
route requests sent for a certain destination. The other entry
RreqTable record is RreqTableId. This entry keeps track of
the route requests this node has received from other nodes,
and drops duplicate route request packets. It is mapped to
the source node that is originating this route request. The
detail entries include the destination address that records
the specific destination for this request, and the identifica-
tion field that keeps track of the identification number of the
route request packet. If the two fields in the RreqTableId
are the same for two entries, the request packet will be recog-
nised as a duplicate one and will be dropped silently.
GratuitousRouteReply class is used to shorten routes.
Whenever a node overhears a transmission that is not des-
tined for itself, but can infer a shorter route to a specific
destination, it will send a gratuitous route reply to the
source of the longer route indicating the shorter route. Its
entry includes three fields: ReplyTo is the address to which
the node originates a gratuitous route reply, ReplyFrom keeps
track of the node from which this node overhears the packet
that triggered the gratuitous route reply, and GratuitousH-
oldoffTime is the remaining time before the expiration of
the entry.

Attribute Defaults Summary
MaxSendBuffLen 64 Maximumnumberofpacketsthatcanbestoredinsendbuer
MaxSendBuffTime 30 s Maximum time packets can be queued in the send buffer
MaxMaintLen 50 Maximumnumberofpacketsthatcanbestoredinmaintenancebuer
MaxMaintTime 30 s Maximum time packets can be queued in maintenance buffer
MaxCacheLen 64 Maximum number of route entries that can be stored in route cache
RouteCacheTimeout 300 s Maximum time routes can be queued in route cache
SendBuffInterval 1s How often to check send buffer for pending data packets
NodeTraversalTime 100 ms Time it takes to traverse the two neighboring nodes
MaxMaintRexmt 2 Maximum number of retransmissions for data packets
RreqRetries 16 Maximum number of retransmissions for route request discovery
MaintenanceRetries 2 Maximum number of retransmissions for data packets from maintenance buffer
RequestTableSize 64 Maximum number of request entries in the request table
RequestIdSize 16 Maximum number of request Ids in the request table
NonPropRequestTimeout 30 ms Timeout value for non-propagation route requests
DiscoveryHopLimit 255 Maximum route discovery hop limit
MaxSalvageCount 16 Max salvage count for a single data packet
BlacklistTimeout 3s Time for a neighbor to stay in blacklist
GratuitousHoldoffTime 1s Time for gratuitous route reply entry to expire
BroadcastJitter 10 ms Jitter time to avoid collision for broadcast packets
PassiveAckTimeout 100 ms Time for a packet in maintenance buffer to wait for passive acknowledgment
RequestPeriod 500 ms Base time interval between route requests
MaxRequestPeriod 10 s Max time interval between route requests
Table 1: DSR attributes and their default values
3.5 DSR Header Format
The DSR header consists of two parts: DsrFsHeader and
DsrOptionsHeader, as shown in Figure 3. The DsrFsHeader
is fixed in size and used to carry information that must be
present in all DSR packets, while the DsrOptionsHeader is
used to carry information for specific DSR options.
3.5.1 DSR Fixed-size Header
The DsrFsHeader is a fixed size header which contains a
next header field to indicate the immediate header follow-
ing the DSR option header. The payload length field indi-
cates the length of all the option headers following the DsrF-
sHeader.Themessage id,source id,anddestination id are
needed for the ns-3 implementation. These fields are added
(in addition to the header fields from RFC 4728) to differ-
entiate between data and control packets as well as identi-
fying source and destination addresses for post-processing
purposes. The modified header is shown in Figure 3; it
is word aligned and adds four bytes extra overhead. The
header fields are explained in detail below.
|0 |1 |2 |3 |
01234567012345670123456701234567
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |F| Message Id | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id | Dest Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DsrFsHeader format
The next header is a 4-bit field that indicates the upper
layer protocol id, indicating which transport protocol to pass
to. The message id field is also 4 bits in length and indicates
the type of message this DSR header is carrying, message id
number 1indicates a control packet, while id number 2is a
data packet. The source id and destination id are also added
only for ns-3 implementation to indicate the initiator and
the destination of the packet since the source and destination
field in IP header is changed as the packet transmitted hop-
by-hop. The payload length field indicates the payload length
of all the DSR option headers combined.
3.5.2 DSR Options Header
The DsrOptionsHeader includes all the DSR options need-
ed for protocol operation. The route request option, as shown
in Figure 4, is attached to route discovery packet that will
include all intermediate nodes’ IP addresses in the header to
form a full route to the destination. The route reply option
is used to notify the source node with the whole route in its
header with its header format as shown in Figure 5.
The source route option is attached to data packets and
directs the packet from source to destination. It includes
all intermediate nodes to form the full route, as shown in
Figure 6. When a route error occurs, the route error option is
used to indicate the link breakage and the node removes the
erroneous routes from the route cache, as shown in Figure 7.
The acknowledgement request option is used to request
next hop network acknowledgement as shown in Figure 8,
while the acknowledgement option is used to indicate the
successful delivery of data packet to the next hop, as shown
in Figure 9.
4. DSR MODULE EVALUATION
To verify and validate our DSR routing protocol imple-
mentation, first we run nine unit test cases incorporated in
the DSR module of ns-3 and verify its functionality. We in-
vestigate DSR performance with varying number of traffic
sources and different pause times for mobility models and
compare to the other existing MANET routing protocols in
ns-3.12.1: DSDV, OLSR, and AODV. We provided prelim-
inary results of DSR performance for different traffic types
previously [3].

|0 |1 |2 |3 |
01234567012345670123456701234567
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RouteRequestHeader format
|0 |1 |2 |3 |
01234567012345670123456701234567
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: RouteReplyHeader format
|0 |1 |2 |3 |
01234567012345670123456701234567
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |L| Reserved | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SourceRouteHeader format
4.1 Performance Metrics
The performance metrics for the evaluation of DSR rout-
ing protocol are packet delivery ratio (PDR) that is the num-
ber of packets received divided by the number of packets sent
by the application, routing overhead that is the fraction of
bytes used by the protocol to send the DSR control mes-
sages, and delay that is the difference in time between when
the source transmits the packet at the MAC layer and when
theMAClayerofthedestinationreceivesthatdatapacket.
4.2 Simulation Setup
We configure simulation parameters as close as possible
to previous studies [1] in order to have comparable results.
We perform the simulations over an area of 1500 ×300 m2.
All the simulations are averaged over 10 runs with each sim-
ulation running for 1000 s; some are averaged over 20 runs
to increase confidence. Simulations are performed with 50
nodes, and the source-sink traffic pairs are chosen to be 10,
20 and 30. We perform simulations with a packet size of
|0 |1 |2 |3 |
01234567012345670123456701234567
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Error Type |Reservd|Salvage|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Type-Specific Information .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RouteErrorHeader format
|0 |1 |2 |3 |
01234567012345670123456701234567
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: AckRequestHeader format
|0 |1 |2 |3 |
01234567012345670123456701234567
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: AckHeader format
64 bytes to exclude the potential network congestion caused
by large packets. All the nodes are configured to send 4 pack-
ets/s. Using this lower packet rate, we can correctly evaluate
the performance of the routing protocols. We use the ns-
3On-Off application to generate CBR (constant bit rate)
traffic. The 802.11b MAC is the link layer over the Friis
propagation loss model to limit the transmission ranges of
nodes. Previous DSR performance study used a combina-
tion of free space propagation model and a two-ray ground
reflection model [1]. The transmission range of the nodes
is set at 250 m for evaluation. To achieve this transmis-
sion range, the transmit power is set to 8.9048 dBm. The
mobility model used is steady-state random waypoint2with
random velocities from 0.01 – 20.0 m/s and pause times of
0 – 900 s.
DSR has several parameters with some of them intercon-
nected with each other and most of them are prone to change
with different simulation scenarios like mobility model, node
velocities, and node density. When the node velocity in-
creases, the RouteCacheTimeout needs to decrease to get rid
of invalid routes. Furthermore, the NodeTraversalTime is
the time for a packet to traverse the transmission range,
and requires careful consideration since it directly affects
the time to detect link breakage: if set too small, there will
be a possibility of false assumption of undelivered packets,
while if too large it takes too long to respond to link break-
ages. Thus, proper choice of RouteCacheTimeout and Node-
TraversalTime is important in different simulation scenar-
ios. DSR protocol parameters for our simulations are shown
in Table 2. The NodeTraversalTime is set as 2 μstofitthe
250 m transmission range in this case. RouteCacheTimeout
is set as 300 s since this is a case with relatively low mobility
nodes.
Parameter Val u e s
RouteCacheTimeout 300 s
NodeTraversalTime 2μs
MaxSendBuffLen 64
MaxSendBuffTime 30 s
MaxMaintLen 50
MaxMaintTime 30 s
refer PassiveAckTimeout 4μs
Table 2: DSR parameters
2This model eliminates the initial discrepancy of the RWP
model and uses a stationary distribution.

4.3 Simulation Analysis
In the first scenario, we vary the pause time in steady state
random waypoint mobility model so that we can analyse the
performance of DSR in both mobile and static scenarios.
Our simulation results show similar simulation results with
previous work [1], from where we get our simulation config-
uration. Figure 10 shows the variation of PDR by varying
the pause time. Note that the total number of nodes is 50
for all cases.
packet delivery ratio
pause time [s]
10 flows
20 flows
30 flows
0.0
0.2
0.4
0.6
0.8
1.0
0100 200 300 400 500 600 700 800 900
Figure 10: PDR with varying pause time
We can see that as pause time increases, the packet de-
livery ratio for all three traffic source cases also increases.
When the pause time is 900, the PDR is 100% since the
nodes are stable for the whole process of simulation. The
PDR for 20 flows is greater than that for 30 flows for all
pause times as shown in Figure 10. This is due to the fact
that as the number of flows increase, the routing overhead
also increases and this leads to more collisions in the net-
work.
The routing overhead for different number of traffic flows
with varying pause times is shown in Figure 11. This plot
shows that overhead increases with the increasing number
of flows. This is expected for DSR since as the flow number
increases, more route discovery packets will be sent. The
overhead for the 30 flows case has high overhead when the
pause time is 0 s since as nodes constantly moving, route
error packets will also be transmitted out more often.
average overhead [kb/s]
pause time [s]
10 flows
20 flows
30 flows
50
100
150
200
250
300
0100 200 300 400 500 600 700 800 900
Figure 11: Overhead with varying pause time
Next, we analyse packet delay for the above scenario. Fig-
ure 12 shows the delay decrease as the pause time increases.
This is because as the pause time increases the nodes will be
immobile for longer durations and less route breakage will
occur with fewer number of route discovery cycles needed.
Thedelayincreasesslightlywithanincreaseinthenumber
of traffic flows, since more traffic flows cause more data to
be queued for transmission.
packet delay [ms]
pause time [s]
10 flows
20 flows
30 flows
0
50
100
150
200
250
300
350
400
450
500
0100 200 300 400 500 600 700 800 900
Figure 12: Packet delay with varying pause time
From Figure 13 to Figure 15 we only compare the 10 traffic
flow cases with 50 nodes among the four routing protocols.
In Figure 13, we compare the packet delivery ratio of existing
MANET routing protocols implemented in ns-3 with DSR.
From the plot we can see that OLSR outperforms DSR,
DSDV, and AODV. The performance of DSDV follows the
results from the previous work [1], while the performance
of DSR and AODV has a little decrease compared to those
results. This may be caused by the different MAC modules
they have used.
packet delivery ratio
pause time [s]
OLSR
DSR
DSDV
AODV
0.0
0.2
0.4
0.6
0.8
1.0
0100 200 300 400 500 600 700 800 900
Figure 13: PDR with varying pause time
In our analysis, we also compare the routing overhead in-
volved with all four protocols. The overhead for DSDV and
OLSR stays around 200 kb/s and does not change signifi-
cantly with the pause time increase as shown in Figure 14.
As proactive routing protocols, both DSDV and OLSR need
to initiate route discovery even when there is no need for the
route. The overhead for AODV and DSR decreases as the
pause time increase, because the route breakage decreases.
The overhead for DSR is slightly less than that for AODV
since DSR does not need periodic broadcast messages that
AODV uses.
We analyse the packet delay for these protocols and the
result is shown in Figure 15. The packet delay is greater for
DSR and AODV compared to that for DSDV and OLSR.
This is because as reactive routing protocols, both DSR and
AODV need more time to react to link changes while nodes

average overhead [kb/s]
pause time [s]
AODV
DSDV
OLSR
DSR
50
100
150
200
250
300
350
400
0100 200 300 400 500 600 700 800 900
Figure 14: Overhead with varying pause time
are moving. Furthermore, we note that the variation of de-
lay (shown as the error bar) for both DSR and AODV is
comparably larger since they both rely on the buffering ex-
tensively in the route discovery cycle. As the pause time
increases, the delay for all the protocols decreases since less
link breakage occurs.
packet delay [ms]
pause time [s]
AODV
DSR
OLSR
DSDV
0
50
100
150
200
250
300
350
400
450
0100 200 300 400 500 600 700 800 900
Figure 15: Packet delay with varying pause time
5. CONCLUSIONS
In this paper we presented the implementation of the DSR
MANET routing protocol in ns-3. A detailed explanation of
the components and how each class in the protocol interacts
with one other is also provided along with attributes that
can be modified in the protocol is presented. We analysed
our DSR implementation with varying pause time for steady
state random waypoint mobility model and compared its
performance against DSDV, OLSR, and AODV. Our results
indicate that DSR can achieve high packet delivery ratio
with less routing overhead for low mobility scenarios. For
part of the future work, we will test the performance of the
MANET routing protocols in high mobility scenarios.
Acknowledgments
We would like to acknowledge the assistance of Justin P.
Rohrer, and the members of the ResiliNets research group
for their advice and suggestions which helped us with this
implementation. We would also like to thank Tom Hender-
son and the ns-3 development team for their responsiveness
to issues with ns-3 platform.
6. REFERENCES
[1] J. Broch, D. Maltz, D. Johnson, Y.-C. Hu, and
J. Jetcheva. A Performance Comparison of Multi-hop
Wireless Ad hoc Network Routing Protocols. In
ACM/IEEE MobiCom, pages 85–97, Oct. 1998.
[2] I.Broustis,G.Jakllari,T.Repantis,andM.Molle.A
Comprehensive Comparison of Routing Protocols for
Large-Scale Wireless MANETs. In IEEE SECON,
volume 3, pages 951–956, Sep. 2006.
[3] Y.Cheng,E.K. ¸Cetinkaya,andJ.P.Sterbenz.
Performance Comparison of Routing Protocols for
Transactional Traffic over Aeronautical Networks. In
Intl. Telemetering Conf. (ITC), Oct. 2011.
[4] T. Clausen and P. Jacquet. Optimized Link State
Routing Protocol (OLSR). RFC 3626, Oct. 2003.
[5] M. Conti and S. Giordano. Multihop Ad Hoc
Networking: The Theory. IEEE Communications,
45(4):78–86, Apr. 2007.
[6] H. Jiang and J. Garcia-Luna-Aceves. Performance
Comparison of three Routing Protocols for Ad hoc
Networks. In IEEE ICCCN, pages 547–554, Oct. 2001.
[7] P. Johansson, T. Larsson, N. Hedman, B. Mielczarek,
and M. Degermark. Scenario-based Performance
Analysis of Routing Protocols for Mobile Ad-hoc
Networks. In ACM/IEEE MobiCom, pages 195–206,
Aug. 1999.
[8] D. Johnson, Y. Hu, and D. Maltz. The Dynamic
Source Routing Protocol (DSR) for Mobile Ad Hoc
Networks for IPv4. RFC 4728, Feb. 2007.
[9] D. B. Johnson, D. A. Maltz, and J. Broch. DSR: The
Dynamic Source Routing Protocol for Multihop
Wireless Ad Hoc Networks. In C. E. Perkins, editor,
Ad Hoc Networking, chapter 5, pages 139–172.
Addison-Wesley, Boston, MA, 2001.
[10] S. Kurkowski, T. Camp, and M. Colagrosso. MANET
Simulation Studies: The Incredibles. SIGMOBILE
Mob. Comput. Commun. Rev., 9(4):50–61, Oct. 2005.
[11] H.Narra,Y.Cheng,E.K. ¸Cetinkaya, J. P. Rohrer,
and J. P. Sterbenz. Destination-Sequenced Distance
Vector (DSDV) Routing Protocol Implementation in
ns-3. In ICST SIMUTools Workshop on ns-3 (WNS3),
Barcelona, Mar. 2011.
[12] The GloMoSim.
http://pcl.cs.ucla.edu/projects/glomosim/.
[13] The network simulator: ns-2.
http://www.isi.edu/nsnam/ns/.
[14] The ns-3 network simulator. http://www.nsnam.org.
[15] The QualNet. http://www.scalable-networks.com.
[16] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc
On-Demand Distance Vector (AODV) Routing. RFC
3561, July 2003.
[17] C. E. Perkins and P. Bhagwat. Highly Dynamic
Destination-Sequenced Distance-Vector Routing
(DSDV) for Mobile Computers. In ACM SIGCOMM,
pages 234–244, Oct. 1994.
[18] C. E. Perkins and E. M. Royer. Ad-hoc On-Demand
Distance Vector Routing. In IEEE WMCSA,pages
90–100, Feb. 1999.
[19] E. Weingartner, H. vom Lehn, and K. Wehrle. A
Performance Comparison of Recent Network
Simulators. In IEEE ICC, pages 1–5, Jun. 2009.

... Generally a fresh node in network announces its presence and then acknowledges the announcement broadcast by its neighbours. Every node looks for its neighbours and finds the method to reach them and also it may advertise that how to reach for it [5,6]. There are various routing protocols available in ad-hoc network for performance under different conditions and environments. ...
... These kind of routing protocol takes the benefit of both proactive and reactive routing. For example, in Zone Routing Protocols (ZRP) [5], it combines both IARP and IERP to improve performance over routing. The first routing is done by the IARP i.e. proactively and then IERP acts which serves the demand of additionally activated nodes by the flooding method as done in reactive routing protocols. ...
Article
Full-text available
The Ad hoc network is the different kind of mobile wireless network where a set of mobile nodes form an impermanent network without using any backbone such as base station or infrastructure. However, numbers of routing protocols are there for the ad-hoc network environment, but it is not an easy task to decide which one routing protocol is efficiently best for particular situations. This paper attempts to identify the best routing protocols based on some Quality of Service (QoS) metrics. Here, the research article is subjected to the three different on-demand routing protocols (DYMO, AODV, and DSR) and two different Zone Routing Protocols (IARP, and IERP) with IEEE 802.11 MAC layer protocol in Random_Way_Point Mobility Model and 50 numbers of fixed nodes. These five different routing protocols have been analysed and their performances are compared in this paper. The comparative performance evaluation has been done with the help of performance measuring metrics such as jitter, average end-to-end delay, throughput and packet delivery ratio (pdr) by using MAC and physical layer model. The simulation has been performed for the number of times with different values of pause time such as 0, 20, 40, 60, 80, and 100 seconds for all taken routing protocols. Experimental results have been carried out by using simulation tool QualNet (version-7.1). Further, the excel sheet has been used for preparing the graphs from the collected data for different metrics.
... The Dynamic Source Routing (DSR) [6] is a reactive protocol similar to AODV. However DSR, makes use of a source routing mechanism in which a Route Discovery Phase selects an optimum path between a source and a destination. ...
... We used AODV and DSR as a target for comparison. We used the default parameters as described in [5] and [6] for AODV and DSR respectively. Our MASP implementation uses the following essential parameters: number of zones = 3, alpha value = 0.4, half round time = 80 seconds. ...
Conference Paper
Spatially unbalanced energy consumption among sensors is the most important issue in Wireless Sensor Networks (WSNs). This uneven energy consumption can significantly reduce network lifetime. The use of sink mobility with constrained paths and decreasing the message flood by limiting the flood area can help to improve the energy efficiency in WSNs. Maximum Amount Shortest Path routing (MASP) is an efficient protocol using this idea. MASP is proactive (table-driven) in nature and tries to collect the largest amount of data with least energy. MASP makes use of constrained paths for the trajectories of mobile sinks and divides the deployed sensor nodes into independent zones to construct the routing tables. In this paper we discuss the implementation of MASP and conduct a performance evaluation of it using the ns-3 network simulator.
... Hop-by-hop routing protocols such as on-demand distance vector (AODV) carry only the destination and next-hop addresses in their data packets header, whereas source-based routing protocols such as dynamic source routing (DSR) carry the entire path to the destination [36]. DSR is one of the more generally accepted on-demand routing protocols; itis a well-known dominant source routing protocol that imposes itself as a prerogative routing protocol with such aspects [37], [38], [39]. DSR uses two main mechanisms: route discovery and route maintenance [40]; both these mechanisms operate when there is a demand for a route. ...
Article
Full-text available
The rapid advances in the wireless communication industry have paved the way for the enhancement of wireless mobile ad-hoc networks (MANETs) to support various domains including civilian environments, emergency operations, and military affairs. Source routing in MANETs is subject to some issues such as changes in the network topology, which lead to frequent link breakages that may increase the requests of route discoveries. Thus, this paper aims to enhance on-demand source routing protocols by proposing two mechanisms, a zone-based route discovery mechanism (ZRDM) and a link failure prediction mechanism (LFPM). ZRDM aims to control the flooding of route requests, and LFPM aims to avoid route breakages caused by node mobility. The performance of the proposed mechanisms was evaluated using network simulator 3 in terms of normalized routing load, average end-to-end delay, and packet delivery ratio. The experimental results showed that the proposed mechanisms outperform well-known mechanisms such as the dynamic source routing (DSR) protocol, reliable DSR, and zone-based DSR and segment-based DSR.
... According to the above specifications, the DSR implementation included in ns-3.24 [37] is modified using information from [38] and [39], and a simulation set is executed to investigate the performance of our proposed schemes. Ns-3 is a discrete-event network simulator targeted primarily for research and educational use. ...
Article
Full-text available
Mobile Ad hoc Networks are sensitive to selfish behavior that may occur due to restricted power or other resources. Several approaches have been investigated so far to address this problem. In many of them, upon detection, a selfish node is punished with isolation from network services access and in most cases with no possibility for redemption. In this paper, we show that selfish behavior can be exploited to improve network performance. We modify an existing routing protocol by introducing an altruism coefficient to model the overall satisfaction of every node from the network services. When the altruism coefficient is increased, the selfish behavior is decreased. We extend our approach by introducing a common welfare factor, which actually enforces the nodes to cooperate when the network connectivity is critical. A network simulator is utilized to show the impact of our schemes on the performance of the routing protocol when selfish nodes are present in the network.
... TinyRPL is the RPL implementation in TinyOS [31] . Dynamic source routing (DSR) is a source-initiated reactive routing protocol for MANET; Cheng et al. [32] provide the implementation details of ns-3 module for DSR. However, the design of a generic framework for implementing a reactive routing protocol for LLN in ns-3 is yet to be done. ...
Article
The lightweight on-demand ad hoc distance-vector - next generation (LOADng) is a reactive routing protocol proposed for low-power and lossy networks (LLNs). ITU-T G.9903 standard for power line communication specifies LOADng as its default routing protocol. LOADng establishes bidirectional routes and has routing mechanisms for unicast, multicast and broadcast packets. This paper discusses a general framework for the IPv6 based implementation of a reactive routing protocol in ns-3. The framework is then used to implement LOADng routing protocol in ns-3 as per the latest Internet-draft recommendation. Our implementation of LOADng module in ns-3 is useful to study the potentials and pitfalls of the protocol, to investigate the impact of the various protocol parameters, to derive some non-trivial insights into the protocol behavior, and to compare its performance with other routing protocols proposed for LLNs. Our implementation is flexible enough to be modified and augmented with new features. To reduce the control overhead, the Smart-RREQ concept is incorporated as an extension to the basic framework. Another important feature added to this basic module is the multipath capability. Performance improvements with these new features are verified. The module is also tested for its performance with different route metrics. The framework is useful for implementation of other reactive routing protocols in ns-3.
Article
Full-text available
The Wireless Ad-hoc network or Mobile Ad-Hoc network is multi-hop network and rely on dynamic infrastructure where nodes are generally mobile and require signal as a communication component. Mobile Ad-Hoc Network (MANET) is growing more popular due to its advantages of being adaptable, quick to set up, cost-effective, and durable. On the other hand, it has limitations like limited wireless range, frequently changing routes, packet drop, heterogeneous devices, and limited battery power. Hence, MANET is vulnerable to various types of security attacks unlike the infrastructure-based wired network. One of the most dangerous attack is wormhole attack which causes major impact on routing. In view of the necessity to provide secure routing, identification of malicious node is not enough, isolation of malicious node is necessary without considerable overheads in MANETs. This research work presents Node to Node (N2N) Trust based mechanism for secure routing in MANETs based on Node-to-Node packet delay. It uses aggregated N2N trust to detect source malicious node of wormhole and isolate the malicious node to ensure that the malicious node does not intercept the routing. Thus, the mechanism offers routing of data traffic securely with improved throughput. In this work, we have employed NS3 (Network Simulator-3) simulator for experimental analysis and (Dynamic Source Routing) DSR protocol as reference for implementation of N2N Trust based algorithm.
Chapter
Mobile Ad hoc Networks (MANET) is a wireless network that has varying mobility for the collection of nodes. The communication path is identified by routing protocol that has a predefined procedure to determine the efficient path. It is primarily classified into three types based on the method adapted for the protocol activation. They are (1) proactive, (2) reactive, and (3) hybrid. The Dynamic Source Routing protocol (DSR) is a reactive protocol, and this work investigates the advantages and drawbacks of DSR protocol. The reactive nature of DSR is analyzed for multi-hop wireless mobile ad hoc network scenario. The two main aspects of routing protocol are related with the route. Those are discovery through recording cum matching and maintenance. The overhead of maintaining routing table is eliminated since it is a reactive protocol. The loop formation is also eliminated using host matching with route record. The complete route information of intermediate nodes between source node and target nodes is well known in advance. The two route messages, Route Request message (RREQ) along with Route Reply message (RREP) are used in discovery of route and maintenance. Finally, the performance of the DSR protocol is compared with the well-advanced reactive protocol, Ad hoc On-demand Distance Vector (AODV).
Article
Full-text available
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.
Article
Full-text available
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.
Article
Full-text available
Routing protocols are a critical aspect to performance in mobile wireless networks. The development of new protocols requires testing against well-known protocols in various sim-ulation environments. In this paper we present an overview of several well-known MANET routing protocols and the implementation details of the DSDV routing protocol in the ns-3 network simulator. We analyse DSDV routing perfor-mance under various scenarios and compare its performance with the other protocols implemented in ns-3, AODV and OLSR. Our results verify the implementation of DSDV and show performance comparable to that of OLSR.
Conference Paper
Emerging airborne telemetry networks present several challenges such that traditional MANET proto-cols do not perform well. On the other hand, application traffic characteristics are expected to be identical in this domain. Transactional application traffic performance has been studied for traditional MANETs, however this type of traffic has not been studied for domain-specific MANET scenarios. We present the simulation model for transactional traffic used in highly-mobile environments. Using the ns-3 simulator, we examine the performance of a domain-specific routing protocol, AeroRP, to route transactional traffic over the aeronautical environment and present performance comparison with two reactive (AODV and DSR) and two proactive (DSDV and OLSR) MANET routing protocols.