● Data interfaces should be open: it should be possible to
generate and process input and output files with
commonly available software tools.
● Should provide an Integrated Development
Environment that largely facilitates model development
and analyzing results.
The following sections go through the most important aspects of
OMNeT++, highlighting the design decisions that helped achieve
the above main goals.
2.1 Model Structure
An OMNeT++ model consists of modules that communicate with
message passing. The active modules are termed simple modules;
they are written in C++, using the simulation class library. Simple
modules can be grouped into compound modules and so forth; the
number of hierarchy levels is not limited. Messages can be sent
either via connections that span between modules or directly to
their destination modules. The concept of simple and compound
modules is similar to DEVS [46][47] atomic and coupled models.
Both simple and compound modules are instances of module
types. While describing the model, the user defines module types;
instances of these module types serve as components for more
complex module types. Finally, the user creates the system
module as a network module which is a special compound module
type without gates to the external world. When a module type is
used as a building block, there is no distinction whether it is a
simple or a compound module. This allows the user to
transparently split a module into several simple modules within a
compound module, or do the opposite, re-implement the
functionality of a compound module in one simple module,
without affecting existing users of the module type. The feasibility
of model reuse is proven by the model frameworks like INET
Framework [1] and Mobility Framework [17][18], and their
extensions.
network
compound module
simple modules
Figure 1. Model Structure in OMNeT++. Boxes represent simple
modules (thick border), and compound modules (thin border).
Arrows connecting small boxes represent connections and gates.
Modules communicate with messages which – in addition to usual
attributes such as timestamp – may contain arbitrary data. Simple
modules typically send messages via gates, but it is also possible
to send them directly to their destination modules. Gates are the
input and output interfaces of modules: messages are sent out
through output gates and arrive through input gates. An input and
an output gate can be linked with a connection. Connections are
created within a single level of module hierarchy: within a
compound module, corresponding gates of two submodules, or a
gate of one submodule and a gate of the compound module can be
connected. Connections spanning across hierarchy levels are not
permitted, as it would hinder model reuse. Due to the hierarchical
structure of the model, messages typically travel through a chain
of connections, to start and arrive in simple modules. Compound
modules act as 'cardboard boxes' in the model, transparently
relaying messages between their inside and the outside world.
Properties such as propagation delay, data rate and bit error rate,
can be assigned to connections. One can also define connection
types with specific properties (termed channels) and reuse them in
several places.
Modules can have parameters. Parameters are mainly used to pass
configuration data to simple modules, and to help define model
topology. Parameters may take string, numeric or boolean values.
Because parameters are represented as objects in the program,
parameters – in addition to holding constants – may transparently
act as sources of random numbers with the actual distributions
provided with the model configuration, they may interactively
prompt the user for the value, and they might also hold
expressions referencing other parameters. Compound modules
may pass parameters or expressions of parameters to their
submodules.
2.2 The Design of the NED Language
The user defines the structure of the model (the modules and their
interconnection) in OMNeT++'s topology description language,
NED. Typical ingredients of a NED description are simple module
declarations, compound module definitions and network
definitions. Simple module declarations describe the interface of
the module: gates and parameters. Compound module definitions
consist of the declaration of the module's external interface (gates
and parameters), and the definition of submodules and their
interconnection. Network definitions are compound modules that
qualify as self-contained simulation models.
The NED language has been designed to scale well, however,
recent growth in the amount and complexity of OMNeT++-based
simulation models and model frameworks made it necessary to
improve the NED language as well. In addition to a number of
smaller improvements, the following major features have been
introduced:
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
derive an FTPApp from it by setting certain parameters to a fixed
value; or derive a WebClientHost compound module from a
BaseHost compound module by adding a WebClientApp
submodule and connecting it to the inherited TCP submodule.
Interfaces. Module and channel interfaces can be used as a
placeholder where normally a module or channel type would be
used, and the concrete module or channel type is determined at
network setup time by a parameter. Concrete module types have
to “implement” the interface they can substitute. For example, the
module types ConstSpeedMobility and
RandomWayPointMobility need to implement IMobility
to be able to be plugged into a MobileHost that contains an
IMobility submodule.
Packages. To address name clashes between different models and
to simplify specifying which NED files are needed by a specific