AN OVERVIEW OF THE OMNeT++ SIMULATION

ENVIRONMENT
András Varga Rudolf Hornig
OpenSim Ltd. OpenSim Ltd.
Szőlő köz 11, 1032 Szőlő köz 11, 1032
Budapest, Hungary Budapest, Hungary
[email protected] [email protected]

ABSTRACT is available on all common platforms including Linux, Mac OS/X

The OMNeT++ discrete event simulation environment has been and Windows, using the GCC tool chain or the Microsoft Visual
publicly available since 1997. It has been created with the C++ compiler.
simulation of communication networks, multiprocessors and other OMNeT++ represents a framework approach. Instead of directly
distributed systems in mind as application area, but instead of providing simulation components for computer networks, queuing
building a specialized simulator, OMNeT++ was designed to be as networks or other domains, it provides the basic machinery and
general as possible. Since then, the idea has proven to work, and tools to write such simulations. Specific application areas are
OMNeT++ has been used in numerous domains from queuing supported by various simulation models and frameworks such as
network simulations to wireless and ad-hoc network simulations, the Mobility Framework or the INET Framework. These models
from business process simulation to peer-to-peer network, optical are developed completely independently of OMNeT++, and
switch and storage area network simulations. This paper presents follow their own release cycles.
an overview of the OMNeT++ framework, recent challenges
brought about by the growing amount and complexity of third Since its first release, simulation models have been developed by
party simulation models, and the solutions we introduce in the various individuals and research groups for several areas
next major revision of the simulation framework.1 including: wireless and ad-hoc networks, sensor networks, IP and
IPv6 networks, MPLS, wireless channels, peer-to-peer networks,
storage area networks (SANs), optical networks, queuing
KEYWORDS networks, file systems, high-speed interconnections (InfiniBand),
discrete simulation, network simulation, simulation tools, and others. Some of the simulation models are ports of real-life
performance analysis, computer systems, telecommunications, protocol implementations like the Quagga Linux routing daemon
hierarchical, integrated development environment or the BSD TCP/IP stack, others have been written directly for
OMNeT++. A later section of this paper will discuss these
1. INTRODUCTION projects in more detail. In addition to university research groups
OMNeT++[1][2] is a C++-based discrete event simulator for and non-profit research institutions, companies like IBM, Intel,
modeling communication networks, multiprocessors and other Cisco, Thales and Broadcom are also using OMNeT++
distributed or parallel systems. OMNeT++ is public-source, and successfully in commercial projects or for in-house research.
can be used under the Academic Public License that makes the
software free for non-profit use. The motivation of developing
OMNeT++ was to produce a powerful open-source discrete event 2. THE DESIGN OF OMNeT++
simulation tool that can be used by academic, educational and OMNeT++ was designed from the beginning to support network
research-oriented commercial institutions for the simulation of simulation on a large scale. This objective lead to the following
computer networks and distributed or parallel systems. OMNeT++ main design requirements:
attempts to fill the gap between open-source, research-oriented ● To enable large-scale simulation, simulation models
simulation software such as NS-2 [11] and expensive commercial need to be hierarchical, and built from reusable
alternatives like OPNET [16]. A later section of this paper components as much as possible.
presents a comparison with other simulation packages. OMNeT++
● The simulation software should facilitate visualizing
Permission to make digital or hard copies of part or all of this work for and debugging of simulation models in order to reduce
personal or classroom use is granted without fee provided that copies are debugging time, which traditionally takes up a large
not made or distributed for profit or commercial advantage and that
percentage of simulation projects. (The same feature set
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ICST must be is also useful for educational use of the software.)
honored. Abstracting with credit is permitted. To copy otherwise, to
● The simulation software itself should be modular,
republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
customizable and should allow embedding simulations
into larger applications such as network planning
SIMUTools, March 03 – 07, 2008, Marseille, France. software. (Embedding brings additional requirements
ISBN 978-963-9799-20-2 about the memory management, restartability, etc. of the
simulation).
1
The 4.0 release is scheduled to appear in Q1 2008.
 ● Data interfaces should be open: it should be possible to structure of the model, messages typically travel through a chain
generate and process input and output files with of connections, to start and arrive in simple modules. Compound
commonly available software tools. modules act as 'cardboard boxes' in the model, transparently
relaying messages between their inside and the outside world.
● Should provide an Integrated Development Properties such as propagation delay, data rate and bit error rate,
Environment that largely facilitates model development can be assigned to connections. One can also define connection
and analyzing results. types with specific properties (termed channels) and reuse them in
The following sections go through the most important aspects of several places.
OMNeT++, highlighting the design decisions that helped achieve Modules can have parameters. Parameters are mainly used to pass
the above main goals. configuration data to simple modules, and to help define model
topology. Parameters may take string, numeric or boolean values.
2.1 Model Structure Because parameters are represented as objects in the program,
An OMNeT++ model consists of modules that communicate with parameters – in addition to holding constants – may transparently
message passing. The active modules are termed simple modules; act as sources of random numbers with the actual distributions
they are written in C++, using the simulation class library. Simple provided with the model configuration, they may interactively
modules can be grouped into compound modules and so forth; the prompt the user for the value, and they might also hold
number of hierarchy levels is not limited. Messages can be sent expressions referencing other parameters. Compound modules
either via connections that span between modules or directly to may pass parameters or expressions of parameters to their
their destination modules. The concept of simple and compound submodules.
modules is similar to DEVS [46][47] atomic and coupled models.
Both simple and compound modules are instances of module 2.2 The Design of the NED Language
types. While describing the model, the user defines module types; The user defines the structure of the model (the modules and their
instances of these module types serve as components for more interconnection) in OMNeT++'s topology description language,
complex module types. Finally, the user creates the system NED. Typical ingredients of a NED description are simple module
module as a network module which is a special compound module declarations, compound module definitions and network
type without gates to the external world. When a module type is definitions. Simple module declarations describe the interface of
used as a building block, there is no distinction whether it is a the module: gates and parameters. Compound module definitions
simple or a compound module. This allows the user to consist of the declaration of the module's external interface (gates
transparently split a module into several simple modules within a and parameters), and the definition of submodules and their
compound module, or do the opposite, re-implement the interconnection. Network definitions are compound modules that
functionality of a compound module in one simple module, qualify as self-contained simulation models.
without affecting existing users of the module type. The feasibility The NED language has been designed to scale well, however,
of model reuse is proven by the model frameworks like INET recent growth in the amount and complexity of OMNeT++-based
Framework [1] and Mobility Framework [17][18], and their simulation models and model frameworks made it necessary to
extensions. improve the NED language as well. In addition to a number of
smaller improvements, the following major features have been
network simple modules introduced:

compound module Inheritance. Modules and channels can now be subclassed.

Derived modules and channels may add new parameters, gates,
and (in the case of compound modules) new submodules and
connections. They may set existing parameters to a specific value,
and also set the gate size of a gate vector. This makes it possible,
for example, to take a GenericTCPClientApp module and
Figure 1. Model Structure in OMNeT++. Boxes represent simple derive an FTPApp from it by setting certain parameters to a fixed
modules (thick border), and compound modules (thin border). value; or derive a WebClientHost compound module from a
Arrows connecting small boxes represent connections and gates. BaseHost compound module by adding a WebClientApp
submodule and connecting it to the inherited TCP submodule.
Modules communicate with messages which – in addition to usual
attributes such as timestamp – may contain arbitrary data. Simple Interfaces. Module and channel interfaces can be used as a
modules typically send messages via gates, but it is also possible placeholder where normally a module or channel type would be
to send them directly to their destination modules. Gates are the used, and the concrete module or channel type is determined at
input and output interfaces of modules: messages are sent out network setup time by a parameter. Concrete module types have
through output gates and arrive through input gates. An input and to “implement” the interface they can substitute. For example, the
an output gate can be linked with a connection. Connections are module types ConstSpeedMobility and
created within a single level of module hierarchy: within a RandomWayPointMobility need to implement IMobility
compound module, corresponding gates of two submodules, or a to be able to be plugged into a MobileHost that contains an
gate of one submodule and a gate of the compound module can be IMobility submodule.
connected. Connections spanning across hierarchy levels are not
permitted, as it would hinder model reuse. Due to the hierarchical Packages. To address name clashes between different models and
to simplify specifying which NED files are needed by a specific
simulation model, a Java-like package structure was introduced model and better tooling support. In a generic simulation scenario,
into the NED language. one usually wants to know how the simulation behaves with
different inputs. These variables neither belong to the behavior
Inner types. Channel types and module types used locally by a (code) nor the topology (NED files) as they can change from run
compound module can now be defined within the compound to run. INI files are used to store these values. INI files provide a
module, in order to reduce namespace pollution. great way to specify how these parameters change and enable us
Metadata annotations. It is possible to annotate module or to run our simulation for each parameter combination we are
channel types, parameters, gates and submodules by adding interested in. The generated simulation results can be easily
properties. Metadata are not used by the simulation kernel harvested and processed by the built in analysis tool. We will
directly, but they can carry extra information for various tools, the explore later, in the Result Analysis paragraph, how the INI files
runtime environment, or even for other modules in the model. For are organized and how they can make experimenting with our
example, a module's graphical representation (icon, etc) or the model a lot easier.
prompt string and unit (milliwatt, etc) of a parameter are specified
using properties. 2.5 Simple Module Programming Model
Simple modules are the active elements in a model. They are
The NED language has an equivalent XML representation, that is, atomic elements in the module hierarchy: they cannot be divided
NED files can be converted to XML and back without loss of any further. Simple modules are programmed in C++, using the
data, including comments. This lowers the barrier for OMNeT++ simulation class library. OMNeT++ provides an
programmatic manipulation of NED files, for example extracting Integrated C++ Development Environment so it is possible to
information, refactoring and transforming NED, generating NED write, run and debug the code without leaving the OMNeT++
from information stored in other system like SQL databases, and IDE. The simulation kernel does not distinguish between
so on. messages and events – events are also represented as messages.
2.3 Graphical Editor Simple modules are programmed using the process-interaction
The OMNeT++ package includes an Integrated Development method. The user implements the functionality of a simple module
Environment which contains a graphical editor using NED as its by subclassing the cSimpleModule class. Functionality is
native file format; moreover, the editor can work with arbitrary, added via one of two alternative programming models: (1)
even hand-written NED code. The editor is a fully two-way tool, coroutine-based, and (2) event-processing function. When using
i.e. the user can edit the network topology either graphically or in coroutine-based programming, the module code runs in its own
NED source view, and switch between the two views at any time. (non-preemptively scheduled) thread, which receives control from
This is made possible by design decisions about the NED the simulation kernel each time the module receives an event
language itself. First, NED is a declarative language, and as such, (=message). The function containing the coroutine code will
it does not use an imperative programming language for defining typically never return: usually it contains an infinite loop with
the internal structure of a compound module. Allowing arbitrary send and receive calls.
programming constructs would make it practically infeasible to When using event-processing function, the simulation kernel
write two-way graphical editors which could work directly with simply calls the given function of the module object with the
both generated and hand-made NED files. (Generally, the editor message as argument – the function has to return immediately
would need AI capability to understand the code.) after processing the message. An important difference between the
Most graphical editors only allow the creation of fixed topologies. coroutine-based and event-processing function programming
However, NED contains declarative constructs (resembling loops models is that with the former, every simple module needs an own
and conditionals in imperative languages), which enable CPU stack, which means larger memory requirements for the
parametric topologies: it is possible to create common regular simulation program. This is of interest when the model contains a
topologies such as ring, grid, star, tree, hypercube, or random large number of modules (over a few ten thousands).
interconnection whose parameters (size, etc.) are passed in It is possible to write code which executes on module
numeric-valued parameters. The potential of parametric initialization and finalization: the latter takes place on successful
topologies and associated design patterns have been investigated simulation termination, and finalization code is mostly used to
in [7][9]. With parametric topologies, NED holds an advantage in save scalar results into a file. OMNeT++ also supports multi-
many simulation scenarios both over OPNET where only fixed stage initialization: situations where model initialization needs to
model topologies can be designed, and over NS-2 where building be done in several "waves". Multi-stage initialization support is
model topology is programmed in Tcl and often intermixed with missing from most simulation packages, and it is usually emulated
simulation logic, so it is generally impossible to write graphical with broadcast events scheduled at zero simulation time, which is
editors which could work with existing, hand-written code. a less clean solution.
2.4 Separation of Model and Experiments Message sending and receiving are the most frequent tasks in
It is always a good practice to try to separate the different aspects simple modules. Messages can be sent either via output gates, or
of a simulation as much as possible. Model behavior is captured directly to another module. Modules receive messages either via
in C++ files as code, while model topology (and of course the one of the several variations of the receive call (when using
parameters defining this topology) is defined by the NED files. coroutine-based programming), or messages are delivered to the
This approach allows the user to keep the different aspects of the module in an invocation from the simulation kernel (when using
model in different places which in turn allows having a cleaner the event-processing function). Messages can be defined by
specifying their content in an MSG file. OMNeT++ takes care of
creating the necessary C++ classes. MSG files allow the into a graph data structure, then navigate the graph or apply
OMNeT++ kernel to generate reflection code which enables us to algorithms such as Dijkstra to find shortest paths.
peek into messages and explore their content at runtime.
There are several statistical classes, from simple ones which
It is possible to modify the topology of the network dynamically: collect the mean and the standard deviation of the samples to a
one can create and delete modules and rearrange connections number of distribution estimation classes. The latter include three
while the simulation is executing. Even compound modules with highly configurable histogram classes and the implementations of
parametric internal topology can be created on the fly. the P2 [10] and the k-split [8] algorithms. It is also supported to
write time series result data into an output file during simulation
2.6 Design of the Simulation Library execution, and there are tools for post-processing the results.
The OMNeT++ provides a rich object library for simple module
implementers. There are several distinguishing factors between 2.8 Parallel Simulation Support
this library and other general-purpose or simulation libraries. The OMNeT++ also has support for parallel simulation execution.
OMNeT++ class library provides reflection functionality which Very large simulations may benefit from the parallel distributed
makes it possible to implement high-level debugging and tracing simulation (PDES) feature, either by getting speedup, or by
capability, as well as automatic animation on top of it (as distributing memory requirements. If the simulation requires
exemplified by the Tkenv user interface, see later). Memory leaks, several Gigabytes of memory, distributing it over a cluster may be
pointer aliasing and other memory allocation problems are the only way to run it. For getting speedup (and not actually
common in C++ programs not written by specialists; OMNeT++ slowdown, which is also easily possible), the hardware or cluster
alleviates this problem by tracking object ownership and detecting should have low latency and the model should have inherent
bugs caused by aliased pointers and misuse of shared objects. The parallelism. Partitioning and other configuration can be
requirements for ease of use, modularity, open data interfaces and configured in the INI file, the simulation model itself doesn't need
support of embedding also heavily influenced the design of the to be changed (unless, of course, it contains global variables that
class library. The consistent use of object-oriented techniques prevents distributed execution in the first place.) The
makes the simulation kernel compact and slim. This makes it communication layer is MPI, but it's actually configurable, so if
relatively easy to understand its internals, which is a useful the user does not have MPI it is still possible to run some basic
property for both debugging and educational use. tests over named pipes. The figure below explains the logical
architecture of the parallel simulation kernel:
Recently it has become more common to do large scale network
simulations with OMNeT++, with several ten thousand or more Simulation Model
network nodes. To address this requirement, aggressive memory
optimization has been implemented in the simulation kernel,
Simulation Kernel
based on shared objects and copy-on-write semantics. Parallel simulation subsystem
Until recently, simulation time has been represented as with C's Synchronization
double type (IEEE double precision). Well-known precision Event scheduling,
problems with floating point calculations however, have caused sending, receiving Partition (LP)
problems in simulations from time to time. To address this issue,
simulation time has been recently changed to 64-bit integer-based
Communication
fixed-point representation. One of the major problems that had to
be solved here was how to detect numeric overflows, as the C and
C++ languages, despite their explicit goals of being “close to the communications library (MPI, sockets, etc.)
hardware”, lack any support to detect integer overflows.
Figure 2. Logical Architecture of the OMNeT++ Parallel
2.7 Contents of the Simulation Library Simulation kernel
This section provides a very brief catalog of the classes in the
2.9 Internal Architecture
OMNeT++ simulation class library. The classes were designed to
OMNeT++ executable
cover most of the common simulation tasks.
CMDENV,
OMNeT++ has the ability to generate random numbers from or TKENV
several independent streams. The common distributions are SIM ENVIR (one of the
supported, and it is possible to add new distributions programmed Simulation (simulation (user interface
concrete user
interfaces)
by the user. It is also possible to load user distributions defined by Model kernel) common base)
histograms. main()

The class library offers queues and various other container

classes. Queues can also operate as priority queues. Model Component
Library
Messages are objects which may hold arbitrary data structures and (simple & compound
other objects (through aggregation or inheritance), and can also module types, etc.)
embed other messages.
OMNeT++ supports routing traffic in the network. This feature Figure 3. Logical Architecture of an OMNeT++ Simulation
provides the ability to explore actual network topology, extract it Program
OMNeT++ simulation programs possess a modular structure. The
logical architecture is shown on Figure 3.
The Model Component Library consists of the code of compiled
simple and compound modules. Modules are instantiated and the
concrete simulation model is built by the simulation kernel and
class library (Sim) at the beginning of the simulation execution.
The simulation executes in an environment provided by the user
interface libraries (Envir, Cmdenv and Tkenv) – this environment
defines where input data come from, where simulation results go
to, what happens to debugging output arriving from the simulation
model, controls the simulation execution, determines how the
simulation model is visualized and (possibly) animated, etc.
Embedding Application

OMNeT++ subsystem

other parts of the

SIM embedding application
Simulation (sim. kernel)
Model
Figure 5. Screenshot of the Tkenv User Interface of OMNeT++

Model Component Simple modules may write textual debugging or tracing

Library information to a special output stream. Such debug output appears
in module output windows. It is possible to open separate
windows for the output of individual modules or module groups,
Figure 4. Embedding OMNeT++
so compared to the traditional printf()-style debugging, module
By replacing the user interface libraries, one can customize the output windows make it easier to follow the execution of the
full environment in which the simulation runs, and even embed an simulation program.
OMNeT++ simulation into a larger application (Figure 4). This is
Further introspection into the simulation model is provided by
made possible by the existence of a generic interface between Sim
object inspectors. An object inspector is a GUI window
and the user interface libraries, as well as the fact that all Sim,
associated with a simulation object. Object inspectors can be used
Envir, Cmdenv and Tkenv are physically separate libraries. It is
to display the state or contents of an object in the most
also possible for the embedding application to assemble models
appropriate way (i.e. a histogram object is displayed graphically,
from the available module types on the fly – in such cases, model
with a histogram chart), as well as to manually modify the object.
topology will often come from a database.
In OMNeT++, it is automatically possible to inspect every
simulation object; there is no need to write additional code in the
2.10 Real-Time Simulation, Network simple modules to make use of inspectors.
Emulation
Network emulation, together with real-time simulation and It is also possible to turn off the graphical user interface
hardware-in-the-loop like functionality, is available because the altogether, and run the simulation as a pure command-line
event scheduler in the simulation kernel is pluggable too. The program. This feature is useful for batched simulation runs.
OMNeT++ distribution contains a demo of real-time simulation
and a simplistic example of network emulation. Interfacing 2.12 Visualizing Dynamic Behavior
OMNeT++ with other simulators (hybrid operation) or HLA is The behavior of large and complex models is usually hard to
also largely a matter of implementing one's own scheduler class. understand because of the complex interaction between different
modules. OMNeT++ helps to reduce complexity by mandating the
2.11 Animation and Tracing Facility communication between modules using predefined connections.
An important requirement for OMNeT++ was easy debugging and The graphical runtime environment allows the user to follow
traceability of simulation models. Associated features are module interactions to a certain extent: one can animate, slow
implemented in Tkenv, the GUI user interface of OMNeT++. down or single-step the simulation, but sometimes it is still hard
Tkenv uses three methods: automatic animation, module output to see the exact sequence of the events, or to grasp the timing
windows and object inspectors. Automatic animation (i.e. relationships (as, for practical reasons, simulation time is not
animation without any programming) in OMNeT++ is capable of proportional to real time; also, when single-stepping through
animating the flow of messages on network charts and reflecting events, events with the same timestamp get animated
state changes of the nodes in the display. Automatic animation sequentially).
perfectly fits the application area, as network simulation OMNeT++ helps the user to visualize the interaction by logging
applications rarely need fully customizable, programmable interactions between modules to a file. This log file can be
animation capabilities. processed after (or even during) the simulation run and can be
used to draw interaction diagrams. The OMNeT++ IDE has a
sequence chart diagramming tool which provides a sophisticated
view of how the events follow each other. One can focus on all, or
just selected modules, and display the interaction between them. run – or actual run: one instance of running the simulation; that
The tool can analyze and display the causes or consequences of an is, a run can be characterized with an exact time/date and the
event, and display all of them (using a non-linear time axis) on a computer (e.g. the host name).
single screen even if time intervals between events are of different
OMNeT++ supports the execution of whole (or partial)
magnitudes. One can go back and forth in time and filter for
experiments as a single batch. After specifying the model
modules and events.
(executable file + NED files) and the experiment parameters (in
the INI file) one can further refine which measurements one is
interested in. The simulation batch can be executed and its
progress monitored from the IDE. Multiple CPUs or CPU cores
can be exploited by letting the launcher run more than one
simulation at a time. The significance of running multiple
independent simulations concurrently is often overlooked, but it is
not only a significantly easier way of reducing overall execution
time of an experiment than distributed parallel simulation (PDES)
but also more efficient (as it guarantees linear speedup which is
not possible with PDES).

2.14 Result Analysis

Analyzing the simulation result is a lengthy and time consuming
process. In most cases the user wants to see the same type of data
Figure 6. for each run of the simulation or display the same graphs for
Screenshot of a Sequence Chart from the OMNeT++ IDE different modules in the model, so automation is very important.
(The user does not want to repeat the steps of re-creating charts
2.13 Organizing and Performing Experiments every time simulations have to be re-run for some reason.) The
The ultimate goal of running a simulation is to obtain results and lack of automation support drives many users away from existing
to get some insight into the system by analyzing the results. GUI analysis tools, and forces them to write scripts.
Thorough simulation studies very often produce large amounts of OMNeT++ solves this by making result analysis rule-based.
data, which are nontrivial to organize in a meaningful way. Simulations and series of simulations produce various result files.
OMNeT++ organizes simulation runs (and the results they The user selects the input of the analysis by specifying file names
generate) around the following concepts: or file name patterns (e.g. "adhoc-*.vec"). Data of interest can be
model – the executable (C++ model files, external libraries, etc.) selected into datasets by further pattern rules. The user completes
and NED files. (INI files are considered to be part of the study and datasets by adding various processing, filtering and charting steps,
experiment rather than the model.) Model files are considered to all using the GUI (Figure 7). Whenever the underlying files or
be invariant for the purposes of experimentation, meaning that if a their contents change, dataset contents and charts are recalculated.
C++ source or NED file gets modified, then it will count as a The editor only saves the "recipe" and not the actual numbers, so
different model. when simulations are re-run and so result files get replaced, charts
are automatically up-to-date. Data in result files are tagged with
study – a series of experiments to study some phenomenon on one meta information: experiment, measurement and replication labels
or more models; e.g. “handover optimization for mobile IPv6”. are added to the result files to make the filtering process easy. It is
For a study one usually performs a number of experiments from possible to create very sophisticated filtering rules, for example,
which conclusions can be drawn. One study may contain “all 802.11 retry counts of host[5..10] in experiment X, averaged
experiments on different models, but one experiment is always over replications”. In addition datasets can use other datasets as
performed on one specific model. their input so datasets can build on each other.
experiment – exploration of a parameter space on a model, e.g.
“the adhocNetwork model’s behavior with
numhosts=5,10,20,50,100 and load=2..5 step 0.1 (Cartesian
product)”; consists of several measurements.
measurement – a set of simulation runs on the same model with
the same parameters (e.g. “numhosts=10, load=3.8”), but
potentially different seeds. May consist of several replications of
whose results get averaged to supply one data point for the
experiment. A measurement can be characterized with the
parameter settings and simulation kernel settings in the INI file,
minus the seeds.
replication – one repetition of a measurement. Very often, one
would perform several replications, all with different seeds. A
replication can be characterized by the seed values it uses. Figure 7. Rule based processing
OMNeT++ supports several fully customizable chart and graph The Simulation Library API can be mapped to programming
types which are rendered directly from datasets (Figure 8). The languages other than C++. There is already 3rd party support for
visual properties of the charts are also stored in the “recipe”. Java and C# which makes it possible to write simple module
behavior in these languages.

4. COMPARISON WITH OTHER

SIMULATION TOOLS
The network simulation scene has changed a lot in the past ten
years, simulation tools coming and going. This section presents an
overview of various commercial and noncommercial network
simulation tools in wide use today, and compares them to
OMNeT++. Specialized network simulators (like TOSSIM, for
TinyOS simulations), and simulation packages not or rarely used
for network simulations (such as Ptolemy or Ptolemy II) are not
considered. Also, the discussion only covers the features and
services of the simulation environments themselves, but not the
availability or characteristics of specific simulation models like
Figure 8. Charts in the OMNeT++ IDE IPv6 or QoS (the reason being that they do not form part of the
OMNeT++ simulation package.)
3. CONTRIBUTIONS TO OMNeT++
Currently there are two major network simulation model 4.1 NS
frameworks for OMNeT++: the Mobility Framework [17][18] and NS-2 [11] is currently the most widely used network simulator in
the INET Framework [1]. academic and research circles. NS-2 does not follow the same
clear separation of simulation kernel and models as OMNeT++:
The Mobility Framework was designed at TU Berlin to provide
the NS-2 distribution contains the models together with their
solid foundations for creating wireless and mobile networks
supporting infrastructure, as one inseparable unit. This is a key
within OMNeT++. It provides a detailed radio model, several
difference: the NS-2 project goal is to build a network simulator,
mobility models, MAC models including IEEE 802.11b, and
while OMNeT++ intends to provide a simulation platform, on
several other components. Other model frameworks for mobile,
which various research groups can build their own simulation
ad-hoc and sensor simulations [26][33][13] have also been
frameworks. The latter approach is what called the abundance of
published (LSU SenSim [25][26] and Castalia [19][20], for
OMNeT++-based simulation models and model frameworks into
example), but they have so far failed to make significant impact.
existence, and turned OMNeT++ into a kind of an “ecosystem”.
Further related simulation models are NesCT for TinyOS [21]
simulations, MACSimulator and Positif [13] which are continued NS-2 lacks many tools and infrastructure components that
in the MiXiM [5] project, EWsnSim, SolarLEACH, ChSim [27], OMNeT++ provides: support for hierarchical models, a graphical
AdHocSim, AntNet, etc. editor, GUI-based execution environment (except for nam),
separation of models from experiments, graphical analysis tools,
The INET Framework has evolved from the IPSuite originally
simulation library features such as multiple RNG streams with
developed at the University of Karlsruhe. It provides detailed
arbitrary mapping and result collection, seamlessly integrated
protocol models for TCP, IPv4, IPv6, Ethernet, Ieee802.11b/g,
parallel simulation support, etc. This is because the NS-2 project
MPLS, OSPFv4, and several other protocols. INET also includes
concentrates on developing the simulation models, and much less
the Quagga routing daemon directly ported from Linux code base.
on simulation infrastructure.
Several authors have developed various extensions for the INET
NS-2 is a dual-language simulator: simulation models are Tcl
Framework. OverSim [22][23][24] is used to model P2P
scripts2, while the simulation kernel and various components
protocols on top of the INET Framework. AODV-UU, DSR is
(protocols, channels, agents, etc) are implemented in C++ and are
also available as an add-on for the INET Framework. IPv6Suite
made accessible from the Tcl language. Network topology is
[45] (discontinued by 2007) supported MIPv6 and HMIPv6
expressed as part of the Tcl script, which usually deals with
simulations over wired and wireless networks.
several other things as well, from setting parameters to adding
The OppBSD [44] model allows using the FreeBSD kernel application behavior and recording statistics. This architecture
TCP/IP protocol stack directly inside an OMNeT++ simulation. makes it practically impossible to create graphical editors for
Other published simulation models include Infiniband [28], NS-2 models3.
FieldBus [14] and SimSANs [43].
NS-3 is an ongoing effort to consolidate all patches and recently
A very interesting application area of OMNeT++ is the modeling developed models into a new version of NS. Although work
of dynamic behavior of software systems based on the UML includes refactoring of the simulation core as well, the concepts
standard, by translating annotated UML diagrams into OMNeT++
2
models. A representative of this idea is the SYNTONY project In fact, OTcl, which is an object-oriented extension to Tcl.
[30][31][32]; similar approach have been reported in [35] where 3
Generating a Tcl script from a graphical representation is of
the authors used UML-RT, and in [34] where performance course possible, but not the other way round: no graphical
characteristics of web applications running on the JBoss editor will ever be able to understand an arbitrary NS-2 script,
Application Server were studied. and let the user edit it graphically.
are essentially unchanged. The NS-3 project goals [36] include As with J-Sim, development of the SSFNet simulation framework
some features (e.g. parallel simulation, use of real-life protocol and models seem to have stalled after 2004 (date of the SSFNet
implementations as simulation models) that have already proven for Java 2.20 release), and little activity can be detected outside
to be useful with OMNeT++. the main web site as well.

4.2 J-Sim 4.4 JiST and SWANS

J-Sim [37][38] (formerly known as JavaSim) is a component- JiST [42][6] represents a very interesting approach to building a
based, compositional simulation environment, implemented in high performance Java based simulation environment. It modifies
Java. J-Sim is similar to OMNeT++ in that simulation models are the Java Virtual Machine to run the programs in simulation time
hierarchical and built from self-contained components, but the instead of real time. JiST is basically just a simulation kernel, and
approach of assembling components into models is more like as such, it lacks most of the features present in the OMNeT++
NS-2: J-Sim is also a dual-language simulation environment, in package.
which classes are written in Java, and glued together using Tcl (or SWANS is a scalable wireless network simulator built atop the
Java). The use of Tcl in J-Sim has the same drawback as with JiST platform as a proof of concept model, to prove the efficiency
NS-2: it makes implementing graphical editors impossible. In fact, of the virtual machine based approach. It appears that no further
J-Sim does provide a graphical editor (gEditor), but its native simulation models have been created by the JiST team or
format is XML. Although gEditor can export Tcl scripts, independent groups. Development of JiST/SWANS seems to be
developers recommend that XML files are directly loaded into the halted after 2005.
simulator, bypassing Tcl. This way, XML becomes the equivalent
of OMNeT++ NED. However, the problem with XML as native 4.5 OPNET Modeler
file format is that it is hard to read and write by humans. OPNET Modeler is the flagship product of OPNET Technologies
Simulation models are provided in the Inet package, which Inc. [16]. OPNET Modeler is a commercial product which is
contains IPv4, TCP, MPLS and other protocol models. freely available worldwide to qualifying universities. OPNET has
probably the largest selection of ready-made protocol models
The fact that J-Sim is Java-based has some implications. On one (including IPv6, MIPv6, WiMAX, QoS, Ethernet, MPLS,
hand, model development and debugging can be significantly OSPFv3 and many others).
faster than C++, due to existence of excellent Java development
tools. However, simulation performance is significantly weaker OPNET and OMNeT++ provide rich simulation libraries of
than with C++, and it is also not possible to reuse existing real-life roughly comparable functionalities. The OPNET simulation
protocol implementations written in C as simulation models. (The library is based on C, while the one in OMNeT++ is a C++ class
feasibility and usefulness of the latter has been demonstrated with library. OPNET's architecture is similar to OMNeT++ as it allows
OMNeT++, where simulation models include port of the Quagga hierarchical models with arbitrarily deep nesting (like
Linux routing daemon, the TCP stack from the FreeBSD kernel, OMNeT++), but with some restrictions (namely, the "node" level
the port of the UU-AODV routing package, etc. The NS-3 team cannot be hierarchical). A significant difference from OMNeT++
has similar plans as well.) is that OPNET models are always of fixed topology, while
OMNeT++'s NED and its graphical editor allow parametric
Development of the J-Sim core and simulation models seem to topologies. In OPNET, the preferred way of defining network
have stalled after 2004 when version 1.3 was published; later topology is by using the graphical editor. The editor stores models
entries on the web site are patches and contributed documents in a proprietary binary file format, which means in practice that
only. There are no independent (3rd party) simulation models for OPNET models are usually difficult to generate by program (it
J-Sim. requires writing a C program that uses an OPNET API, while
OMNeT++ models are simple text files which can be generated
4.3 SSFNet e.g. with Perl).
SSFNet [39] (Scalable Simulation Framework) is defined as a
“public-domain standard for discrete-event simulation of large, Both OPNET and OMNeT++ provide a graphical debugger and
complex systems in Java and C++.” The SSFNet standard defines some form of automatic animation which is essential for easy
a minimalist API (which, however, was designed with parallel model development.
simulation in mind). The topology and configuration of SSFNet OPNET does not provide source code to the simulation kernel
simulations are given in DML files. DML is a text-based format (although it ships with the sources of the protocol models).
comparable to XML, but has its own syntax. DML can be OMNeT++ – like NS-2 and most other non-commercial tools –
considered the SSFNet equivalent of NED, however it lacks is fully public-source allowing much easier source level
expressing power and features to scale up to support large model debugging.
frameworks built from reusable components. SSFNet also lacks
OMNeT++'s INI files, all parameters need to be given in the OPNET's main advantage over OMNeT++ is definitely its large
DML. protocol model library, while its closed nature (proprietary binary
file formats and the lack of source code) makes development and
SSFNet has four implementations: DaSSF and CSSF in C++, and problem solving harder.
two Java implementations (Renesys Raceway and JSSF). There
were significantly more simulation models developed for the Java 4.6 Qualnet
versions than for DaSSF. Advantages and disadvantages of using Qualnet [41] is a commercial simulation environment mainly for
Java in SSFNet are the same as discussed with J-Sim. wireless networks, which has a significant client base in the
military. Qualnet has evolved from the Parsec parallel simulation [3] Kaage, U., V. Kahmann, F. Jondral. 2001. An OMNeT++
“language”4 [12] developed at the UCLA Parallel Computing TCP Model. To appear in Proceedings of the European
Laboratory (PCL), and the GloMoSim (Global Mobile system Simulation Multiconference (ESM 2001), June 7-9, Prague.
Simulation) model written on top of Parsec. The Parsec language [4] Wehrle, K, J. Reber, V. Kahmann. 2001. “A Simulation
divides the simulation model into entities, and provides a Suite for Internet Nodes with the Ability to Integrate
minimalistic simulation API (timers, etc) for them. Entities are Arbitrary Quality of Service Behavior”. In Proceedings of
implemented with coroutines. Because coroutine CPU stacks the Communication Networks and Distributed Systems
require relatively large amounts of memory (the manual Modeling and Simulation Conference 2001, Phoenix (AZ),
recommends reserving 200KByte each), it is rarely feasible to USA, January 7-11.
map the natural units of the simulation (say, hosts and routers, or [5] MiXiM home page. http://sourceforge.net/projects/mixim/
protocols) one-to-one onto entities. What GloMoSim and Qualnet [accessed on September, 2007]
models do is implement the equivalent of the OMNeT++ model [6] JiST home page. http://jist.ece.cornell.edu [accessed on
structure in model space, above the Parsec runtime. The Parsec September, 2007]
kernel is only used to provide event scheduling and parallel [7] Varga, A. and Gy. Pongor. 1997. Flexible Topology
simulation services. Description Language for Simulation Programs. In
Proceedings of the 9th European Simulation Symposium
Parsec provides a very efficient parallel simulation infrastructure,
(ESS'97), pp.225-229, Passau, Germany, October 19-22.
and models (GloMoSim and Qualnet simulation models) have
[8] Varga, A and B. Fakhamzadeh. 1997. The K-Split
been written with parallel execution in mind 5, resulting in an
Algorithm for the PDF Approximation of Multi-
excellent parallel performance for wireless network simulations.
Dimensional Empirical Distributions without Storing
Observations. In Proc. of the 9th European Simulation
4.7 Summary Symposium (ESS'97), pp.94-98. October 19-22, Passau,
In this section we have examined the simulation packages most Germany.
relevant for analysis of telecommunication networks, and [9] Varga, A. 1998. Parameterized Topologies for Simulation
compared them to OMNeT++. NS-2 is still the most widely used Programs. In Proceedings of the Western Multiconference
network simulator in the Academia, but it lacks much of the on Simulation (WMC'98), Communication Networks and
infrastructure provided by OMNeT++. The other three Distributed Systems (CNDS'98). San Diego, CA, January
open-source network simulation packages examined (J-Sim, 11-14.
SSFNet and JiST/SWANS), have failed to gain significant [10] Jain, R, and I. Chlamtac. 1985. The P2 Algorithm for
acceptance, and their project web pages indicate near inactivity Dynamic Calculation of Quantiles and Histograms Without
since 2004. Storing Observations. Communications of the ACM, 28, no.
We have examined two commercial products as well. Qualnet 10 (Oct.): 1076-1085.
emphasizes wireless simulations. OPNET has similar foundations [11] Bajaj, S., L. Breslau, D. Estrin, K. Fall, S. Floyd, P. Haldar,
as OMNeT++, but ships with an extensive model library and M. Handley, A. Helmy, J. Heidemann, P. Huang, S. Kumar,
provides several additional programs and GUI tools. S. McCanne, R. Rejaie, P. Sharma, K. Varadhan, Y. Xu, H.
Yu and D. Zappala. 2000. Improving simulation for network
5. CONCLUSIONS research. IEEE Computer. (to appear, a preliminary draft is
In this paper we presented an overview of the OMNeT++ discrete currently available as USC technical report 99-702)
event simulation platform, designed to support the simulation of [12] Bagrodia, R, R. Meyer, M. Takai, Y. Chen, X. Zeng, J.
telecommunication networks and other parallel and distributed Martin, B. Park, H. Song. 1998. Parsec: A Parallel
systems. The OMNeT++ approach significantly differs from that Simulation Environment for Complex Systems. Computer,
of NS-2, the most widely used network simulator in academic and Vol. 31(10), October, pp. 77-85.
research circles: while the NS-2 (and NS-3) project goal is to [13] Consensus home page.
build a network simulator, OMNeT++ aims at providing a rich http://www.consensus.tudelft.nl/software.html [accessed on
simulation platform, and leaves creating simulation models to September, 2007]
independent research groups. The last ten years have shown that [14] FieldBus home page.
the OMNeT++ approach is viable, and several OMNeT++-based http://developer.berlios.de/projects/fieldbus [accessed on
open-source simulation models and model frameworks have been September, 2007]
published by various research groups and individuals. [15] Davis, J, M. Goel, C. Hylands, B. Kienhuis, E.A. Lee, J. Liu,
X. Liu, L. Muliadi, S. Neuendorffer, J. Reekie, N. Smyth, J.
6. REFERENCES Tsay and Y. Xiong. 1999. Overview of the Ptolemy Project.
[1] OMNeT++ Home Page. http://www.omnetpp.org [accessed ERL Technical Report UCB/ERL No. M99/37, Dept. EECS,
on September, 2007] University of California, Berkeley, CA 94720, July.
[2] Varga, A. 2001. The OMNeT++ Discrete Event Simulation [16] OPNET Technologies, Inc. OPNET Modeler.
System. In the Proceedings of the European Simulation http://www.opnet.com [accessed on September, 2007]
Multiconference (ESM2001. June 6-9, 2001. Prague, Czech [17] Mobility Framework. http://mobility-fw.sourceforge.net
Republic). [accessed on September, 2007]
[18] W. Drytkiewicz, S. Sroka, V. Handziski, A. Koepke, and H.
4
It extends the C language with some constructs, and Parsec Karl, A Mobility Framework for OMNeT++. 2003. 3rd
programs are translated into C before compilation. International OMNeT++ Workshop (Budapest University of
5 Technology and Economics, Department of
Lookahead annotations, avoiding central components, etc.
 Telecommunications Budapest, Hungary, January 2003). LR-WPAN for Industrial Applications," Proceedings of 5th
http://www.tkn.tu-berlin.de/~koepke/ IEEE/IFIP Conference on Wireless On demand Network
[19] D. Pediaditakis, S. H. Mohajerani, and A. Boulis. 2007. Systems and Services (IEEE/IFIP WONS 2008), Garmisch-
Poster Abstract: Castalia: the Difference of Accurate Partenkirchen, Germany, January 2008.
Simulation in WSN. 4th European Conference on Wireless [34] A. Hennig, D. Revill and M. Pönitsch. 2003. From UML to
Sensor Networks, (Delft, The Netherlands, 29-31 January Performance Measures - Simulative Performance Predictions
2007). of IT-Systems using the JBoss Application Server with
[20] Castalia: A Simulator for WSN. OMNET++. Proceedings of ESS2003 conference. Siemens
http://castalia.npc.nicta.com.au. [accessed on September, AG, Corporate Technology, CT SE 1.
2007] [35] Michael, J. B., Shing, M., Miklaski, M. H., and Babbitt, J.
[21] NesCT: A language translator. http://nesct.sourceforge.net D. 2004. Modeling and Simulation of System-of-Systems
[accessed on September, 2007] Timing Constraints with UML-RT and OMNeT++. In
[22] OverSim:The Overlay Simulation Framework Proceedings of the 15th IEEE international Workshop on
http://www.oversim.org [accessed on September, 2007] Rapid System Prototyping (Rsp'04) - Volume 00 (June 28 -
[23] Ingmar Baumgart and Bernhard Heep and Stephan Krause. 30, 2004). RSP. IEEE Computer Society, Washington, DC,
2007. OverSim: A Flexible Overlay Network Simulation 202-209. DOI= http://dx.doi.org/10.1109/RSP.2004.30.
Framework. Proceedings of 10th IEEE Global Internet [36] T. R. Henderson, S. Roy, S. Floyd, G. F. Riley. ns3 Project
Symposium (May, 2007). p.79-84. Goals. WNS2 ns-2: The IP Network Simulator, Pisa, Italy -
[24] Ingmar Baumgart and Bernhard Heep and Stephan Krause. Oct. 10, 2006.
2007. A P2PSIP Demonstrator Powered by OverSim. http://www.nsnam.org/docs/meetings/wns2/wns2-ns3.pdf
Proceedings of 7th IEEE International Conference on Peer- [37] Ahmed Sobeih, Wei-Peng Chen, Jennifer C. Hou, Lu-Chuan
to-Peer Computing (P2P2007, Galway, Ireland. Sep, 2007). Kung, Ning Li, Hyuk Lim, Hung-Ying Tyan, and Honghai
pp. 243-244, Zhang,.J-Sim: a simulation and emulation environment for
[25] C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar, R. wireless sensor networks. IEEE Wireless Communications
Kannan, A. Durresi, and S. Sastry. 2005. Simulating Magazine, Vol. 13, No. 4, pp. 104--119, August 2006.
Wireless Sensor Networks with OMNeT++ , submitted to [38] J-SIM home page: http://www.j-sim.org [accessed on
IEEE Computer, 2005 September, 2007]
http://csc.lsu.edu/sensor_web/publications.html [39] Cowie, J. H., Nicol, D. M., and Ogielski, A. T. 1999.
[26] Sensor Simulator. http://csc.lsu.edu/sensor_web [accessed Modeling the Global Internet. Computing in Science and
on September, 2007] Engg. 1, 1 (Jan. 1999), 42-50.
[27] S. Valentin. 2006. ChSim - A wireless channel simulator for DOI=http://dx.doi.org/10.1109/5992.743621
OMNeT++, (TKN TU Berlin Simulation workshop, Sep. [40] X. Zeng, R. Bagrodia, M. Gerla.GloMoSim: a Library for
2006) http://www.cs.uni-paderborn.de/en/research- Parallel Simulation of Large-scale Wireless Networks.
group/research-group-computer- PADS '98, May 26-29, 1998 in Banff, Alberta, Canada.
networks/projects/chsim.html [41] Qualnet home page: http://www.qualnet.com [accessed on
[28] Mellanox Technologies: InfiniBand model: September, 2007]
http://www.omnetpp.org/filemgmt/singlefile.php?lid=133 [42] R. Barr, Z. J. Haas, R. van Renesse. 2004. JiST: Embedding
[29] I. Dietrich, C. Sommer, F. Dressler. Simulating DYMO in Simulation Time into a Virtual Machine. Proceedings of
OMNeT++. Erlangen-Nürnberg : Friedrich-Alexander- EuroSim Congress on Modelling and Simulation, September
Universität. 2007 Internal report. 2004. Computer Science and Electrical Engineering, Cornell
[30] Isabel Dietrich, Volker Schmitt, Falko Dressler and University, Ithaca NY 14853.
Reinhard German, 2007. "SYNTONY: Network Protocol [43] SimSAN home page. http://simsan.storwav.com/ [accessed
Simulation based on Standard-conform UML 2 Models," on September, 2007]
Proceedings of 1st ACM International Workshop on [44] OppBSD home page.
Network Simulation Tools (NSTools 2007), Nantes, France, https://projekte.tm.uka.de/trac/OppBSD [accessed on
October 2007. September, 2007]
[31] I. Dietrich, C. Sommer, F. Dressler, and R. German. 2007. [45] E. Wu, S. Woon, J. Lai and Y. A. Sekercioglu, 2005.
Automated Simulation of Communication Protocols "IPv6Suite: A Simulation Tool for Modeling Protocols of
Modeled in UML 2 with Syntony. Proceedings of GI/ITG the Next Generation Internet", In Proceedings of the Third
Workshop Leistungs-, Zuverlässigkeits- und International Conference on Information Technology:
Verlässlichkeitsbewertung von Kommunikationsnetzen und Research and Education (ITRE 2005), June 2005, Taiwan.
verteilten Systemen (MMBnet 2007), Hamburg, Germany, [46] Zeigler, B. 1990. Object-oriented Simulation with
September 2007. pp. 104-115. Hierarchical, Modular Models. Academic Press, 1990.
[32] Syntony home page. http://www7.informatik.uni- [47] Chow, A and Zeigler, B. 1994. Revised DEVS: A Parallel,
erlangen.de/syntony [accessed on September, 2007] Hierarchical, Modular Modeling Formalism. In Proceedings
[33] Feng Chen, Nan Wang, Reinhard German and Falko of the Winter Simulation conference 1994.
Dressler, 2008. "Performance Evaluation of IEEE 802.15.4