A Survey of Ad Hoc Network Simulators
Mahua Dasgupta
AST
TCS Innovation Labs
Kolkata
Ph.: +91 978749903
mahua.dasgupta@tcs.com
ABSTRACT
In distributed ad hoc networks, the main challenge of developing
a protocol is its evaluation and verification in all the network
scenarios for network tear-up, traffic conditions and network tear-
down. This paper discusses about the various network simulators
available and most popular among protocol developers for
wireless distributed ad hoc network.
1. INTRODUCTION
In ad hoc networks, end-to-end connectivity cannot be
guaranteed. Indeed mobile ad hoc networks may be partitioned
and nodes may be sporadically present in the network. In addition,
the topology of the network changes over time because of the
mobility of the stations. Then, the way the communication
primitives were implemented in the context of wired networks is
no longer applicable. It was hence necessary to propose new
algorithms to take those primitives into account. The design and
implementation of such communication schemes, and more
generally of mobile ad hoc network applications, can be achieved
using two different ways: either by building a real network, or by
resorting to modelling and simulation.
Theoretical approaches failed at modeling the inherent complexity
of mobile ad hoc networks in a comprehensive manner. Indeed, ad
hoc networks are decentralised systems which are ruled by a
variety of elements including radio signal, network traffic,
mobility, collaborative behavior, etc. If theoretical approaches
certainly are useful for represent one or the other elements, they
do not suit the modelling of a system as a whole.
In the situation today, real mobile ad hoc networks are not yet
developed at a city-scale, conducting research on mobile ad hoc
networks is achievable either by using experimentation networks
(called “testbeds”) or by resorting to software simulation, of
which simulators are more popular due to the expense incurred on
testbeds. Ad hoc protocol designer can then follow two directions,
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. To copy otherwise, or republish, to post on
servers or to redistribute to lists, requires prior specific permission
and/or a fee.
TACTiCS – TCS Technical Architects’ Conference’10
Copyright 2010
depending on their needs: either using one of the simulators made
available to the community or developing a custom simulator
tailored to their purpose.
Network simulators are used by people from different areas such
as academic researchers, industrial developers, and Quality
Assurance (QA) to design, simulate, verify, and analyze the
performance of different networks protocols. They can also be
used to evaluate the effect of the different parameters on the
protocols being studied. Generally a network simulator will
comprise of a wide range of networking technologies and
protocols and help users to build complex networks from basic
building blocks like clusters of nodes and links. With their help,
one can design different network topologies using various types of
nodes such as end-hosts, hubs, network bridges, routers, optical
link-layer devices, and mobile units.
2. RELATED WORKS
The world of simulators is largely dominated by ns-2. ns was
originally targeted at the simulation of wired networks. Its
subsequent versions, ns-2, came with an extension for mobile ad
hoc networks. Less popular, simulators like GloMoSim or
Qualnet have advantages like the possibility to distribute the
simulation over a cluster or to provide commercial support.
3. SIMULATORS
The few network simulators that are widely used for simulation of
mobile ad hoc networks are detailed below.
3.1 Ns-2
3.1.1 Features
Ns-2 is the de facto standard for network simulation. Its behavior
is highly trusted within the networking community. ns-2 is a
discrete-event simulator organized according to the OSI model
and primarily designed to simulate wired networks. The core of
ns-2 is a monolithic piece of C++ code. It is extendable by adding
C++ modules. The configuration relies on OTCL [REF] scripts.
Ns-2 then appears to the user as an OTCL interpreter. More
precisely, it reads scenarios files written in OTCL and produces a
trace file in its own format. This trace needs to be processed by
user scripts or converted and rendered using the NAM tool [REF].
This simulator is best if a protocol requires a high precision
physical layer.
Page 1 of 4
3.1.2 Weakness
Unfortunately it suffers from its lack of modularity as well as from
its inherent complexity. Indeed, adding components/protocols or
modifying existing ones is not as straightforward as it should be.
ns-2 is also infamous for its high consumption of computational
resources. A harmful consequence is that ns-2 lacks scalability,
which impedes the simulation of large networks. The wireless ad
hoc version of ns-2 can handle a few hundred nodes, but the
simulation time grows at least quadratically so at most 50 nodes
can be tested with more accuracy.
3.2 GloMoSim
3.2.1 Features
GloMoSim [REF] was developed at UCLA. GloMoSim is written
in Parsec and hence a benefit from the latter’s ability to run on
shared-memory symmetric processor (SMP) computers. New
protocols and modules for GloMoSim must be written in Parsec
too. GloMoSim respects the OSI standard. GloMoSim uses a
message-based approach to discrete-event simulation. More
precisely, network layers are represented as objects called
“entities”. Events are represented as timestamped messages
handled by entities. A java-based visualization tool is provided.
3.2.2 Weakness
GloMoSim is said to suffer from a lack of a good and in-depth
documentation. The language also makes it more difficult to add
customized modules into the simulator code.
3.3 OpNET
3.3.1 Features
Optimized Network Engineering Tools [REF] is a discrete-event
network simulator first proposed by MIT in 1986. It is a well-
established and professional commercial suite for network
simulation. OpNET Modeler features an interactive development
environment allowing the design and study of networks, devices,
protocols, and applications. OPNet is written in C++. OPNET
offers relatively much powerful visual or graphical support for the
users. The graphical editor interface can be used to build network
topology and entities from the application layer to the physical
layer.
3.3.2 Weakness
In spite of its wide adoption, some doubts remain regarding the
dependability of its MANETs simulation engine. More precisely,
Cavin and al. [CSS02b] simulated a broadcasting process on the
OPNet, ns-2 and GloMoSim simulators (each of them is detailed
in this section). It came out that the results obtained using OPNet
were barely comparable to those harvested out of ns-2 and
GloMoSim, which exhibited similar behaviors. The divergences
were quantitative but also qualitative (not the same general
behavior).
3.4 OMNET++
3.4.1 Features
OMNet++ [REF SI01] is a well-designed simulation package
written in C++. OMNET++ is actually a general-purpose
simulator capable of simulating any system composed of devices
Copyright 2010
interacting with each others. It can then perfectly be used for
MANETs simulation.
3.4.2 Weakness
The mobility extension for OMNeT++ [DSH+03] is intended to
support wireless and mobile simulations. This support is said to
be fairly incomplete. OMNet++ is used in the context of academic
research and education.
3.5 GTNets
3.5.1 Features
GTNetS [Ril03] is developed at GeorgiaTech institute (Atlanta,
USA). According to its authors, the design philosophy of GTNetS
is to create a simulation environment that is structured much like
actual networks are structured. More precisely, in GTNetS, there
is clear and distinct separation of protocol stack layers and the
network programming interface used by applications use function
calls similar to the ubiquitous POSIX standard. Another benefit of
GTNetS is that the simulator gathers statistics regarding its own
performance.
3.5.2 Weakness
It does not support changing network topology.
3.6 NAB
3.6.1 Features
NAB (Network in A Box) [ISI04]is a discrete event simulator
developed at EPFL (Lausanne,Switzerland). NAB is dedicated to
MANETs simulation. According to its author, NAB was born out
of the inability to simulate large ad hoc networks with existing
tools, and some impatience in dealing with their internal
complexity, which tended to make implementing new
functionality a lengthy and bug-ridden task. NAB’s design is
node-oriented (as well as object-oriented); that is each node is
represented by an object. It is written in OCaml and is actually the
only simulator written in a language whose syntax is not derived
from C.
3.6.2 Weakness
When the number of nodes increases beyond 50, NAB
experiences performance degradation.
3.7 SWANS
3.7.1 Features
SWANS [Bar04], is a Java-based wireless network simulator built
atop the JiST discrete event platform. SWANS boasts a highly
efficient sequential simulation engine. It has been compared to
GloMoSiM, in terms of quality. JiST relies on the concept of
virtual-machine simulation. SWANS appears to the user as a
framework. It must be programmed in plain Java, using an
application programming interface. SWANS is developed in Java.
3.7.2 Weakness
This simulator suffers less modularization and hence the
granularity is very low. Due to this, integrating this simulator with
a test protocol becomes fairly difficult.
Page 2 of 4
3.8 J-Sim
3.8.1 Features
J-Sim [CL] (formerly known as JavaSim) is a component-based,
compositional simulation environment. Initially designed for
wired network simulation, its Wireless Extension proposes an
implementation of the IEEE802.11 MAC—which is the only
MAC supported so far. This extension turns J-Sim to a viable
MANETs simulator. J-Sim is written in Java.
3.8.2 Weakness
This is more suitable for wired networks than wireless networks.
3.9 Jane
3.9.1 Features
Jane [FGLS03, LGFS04] consists of both a simulation
environment and an execution platform. Its main interestingness is
that it allows the simulation code to be migrated to the real
devices without any modification. Jane also features an emulation
mode that allows real devices to participate to simulations. In
addition to that, Jane features high-level concepts (such as the
notions of service, message, etc) that are suitable to the simulation
of applications-level services. It also makes use of GPS
information, what turns it to an appealing tool for the simulation
location-based services. Jane is written in Java.
3.9.2 Weakness
This simulator provides only application level granularity.
3.10 DIANEmu
3.10.1 Features
DIANEmu [Kle03] is a discrete-event simulator developed at
Karlsruhe University (Germany). It aims to enable the simulation
of ad hoc applications in realistic contexts. So far, most simulators
have been designed to permit simulations at a protocol-level.
DIANEmu’s approach is different: it assumes that the lowest
network layers (up to the fourth one) are available. DIANEmu
then focuses on the application model. DIANEmu belongs to a
new class of simulators which allow the large-scale simulation of
high-level applications such as gaming and e-business. DIANEmu
provides a complete environment for application design. Its
simulation engine is closely coupled to its graphical interface.
DIANEmu is written in Java.
3.10.2 Weakness
This does not support mobility of nodes.
4. Decisive factors
A proper simulator is supposed to:

Simulate large populations

Provide models for heterogeneous PHY layers

Provide a programming model for ad hoc applications
including modularity of code making it comfortable for the
researcher or developer to introduce his protocol layer in the
protocol stack of the simulator

Provide mobility models allowing the representing the nodes

Propose a graphical user interface which provides geometric
views of the simulated networks and applications, and both
Copyright 2010
numerical and graphical representations of the effectively helps
the development of ad hoc applications, by allowing the user to
have precise views of what happens within the simulated
applications.

Provide sufficient statistics

Provide proper data from the application layer without loss
of data which would make tracing layer-specific errors more
difficult.

Should be able to accommodate physical layer variations in
power, sensitivity or as per the need of the protocol being
verified.
5. Verification of Protocol Using Simulator
A network simulator usually has the different layers following the
OSI model. The simulators described above can be modularized
with the figure below.
Application
Transport
IP
Network Layer
MAC
PHY
Physical Channel
Fig 1: Simulator Protocol Stack
When we require the simulator to test our network, we have to
identify the layer where we require inserting our code. A typical
example for verification of a MAC protocol is provided below.
This shows that when we require verifying the MAC layer of our
product, we will typically use the other layers from the simulator
and will integrate our MAC layer with the simulator. The rest of
the layers need to be used and configured for the type of traffic we
require like bursty data or continuous streaming data, the type of
transmission we require like unicast, multicast or broadcast, the
type of routing we require like AODV/DSDV or whatever may be
available with the simulator and so on. The configuration
parameters will include a lot more and will be specific as provided
by the simulator that we choose.
Page 3 of 4
 Application
International Workshop on Wireless Sensor Networks and
Applications, pages 11–19, September 2003.
[5] Jeremy Elson, Lewis Girod, and Deborah Estrin. Fine-
TCP/UDP grained network time synchronization using reference
broadcasts. SIGOPS Operating Systems Review, 36(SI):147–
Routing
163, 2002.
IP
Packets [6] Kay Roemer, “Time Synchronization in Ad Hoc Networks”,
ACM Mobi-Hoc, October 2001
Routing MAC Process MAC Protocol [7] Khurram Shahzad, Arshad Ali, N.D. Gohar, "ETSP: An
Model Calls  TDMA Energy-Efficient Time Synchronization Protocol for Wireless
(Initialization &
Connections)
Sensor Networks," ainaw, pp.971-976, 22nd International
MAC Conference on Advanced Information Networking and
Applications - Workshops (aina workshops 2008), 2008
Packets
[8] Li, Q., Rus, D.: Global Clock Synchronization in Sensor
PHY Networks. In: Proc. IEEE INFOCOM 2004 Conf. (March
PHY
2004)
Physical Channel [9] Mihail L. Sichitiu and Chanchai Veerarittiphan. Simple,
accurate time synchronization for wireless sensor networks.
Fig 2: Integration with Simulator In IEEE Wireless Communications and Networking
Conference (WCNC’03), March 2003
[10] Miklós Maróti, Branislav Kusy, Gyula Simon, and Ákos
6. CONCLUSION Lédeczi. The flooding time synchronization protocol. In 2nd
In most of the cases, the available simulator is modified to suit the International Conference on Embedded Networked Sensor
requirements of the design and may not provide appropriate Systems (SenSys’04), pages 39–49, New York, NY, USA,
required conditions of the design unless modified. The various November 2004. ACM Press
available network simulators can be customized for verification of [11] P. Verissimo, L. Rodrigues, A. Casimiro, “CesiumSpray: A
the ad hoc network protocol designed as elaborated. Precise and Accurate Global Time Service for Large-Scale
Systems,” Journal of Real-Time Systems, 12(3): 243-294,
7. REFERENCES May 1997.
[1] D. L. Mills, “Internet time synchronization: The Network [12] Philipp Blum, Lennart Meier, and Lothar Thiele. Improved
Time Protocol” In Z. Yang and T.A. Marsland, editors, interval-based clock synchronization in sensor networks. In
Global States and Time in Distributed Systems. IEEE Third International Symposium on Information Processing
Computer Society Press, 1994 in Sensor Networks (IPSN’04), pages 349–358, April 2004
[2] Ganeriwal, S., Kumar, R., Srivastava, M.B.: Timing-Sync [13] Qun Li and Daniela Rus. Global clock synchronization in
Protocol for Sensor Networks. In: Proc. First Intl. Conf. sensor networks. In IEEE InfoCom, 2004
Embedded Networked Sensor Systems (SenSys) (2003)
[14] Weilian Su and Ian F. Akyildiz. Time-diffusion
[3] Hui Dai and Richard Han. Tsync: A lightweight bidirectional synchronization protocol for wireless sensor networks.
time synchronization service for wireless sensor networks. IEEE/ACM Transactionson Networking, 13(2):384–397,
ACM SIGMOBILE Mobile Computing and Communications 2005
Review, 8(1):125–139, January 2004.
[4] Jana van Greunen and Jan Rabaey. Lightweight time
synchronization for sensor networks. In 2nd ACM

Copyright 2010 Page 4 of 4