OMNeT++ is a C++ framework for discrete event simulation. It consists of an open-source simulation kernel, a library of extensible C++ components, and a suite of tools to facilitate statistics collection, results analysis, graphical debugging, etc.
It is technically not a simulator in and of itself, but rather a simulation framework
et al. [57] provide a good overview of OMNeT++’s design objectives. OMNeT++ is also well documented and the reader is encouraged to consult the publicly available user manual for more complete and up-to-date information. Here we provide a brief overview of the relevant features needed to understand our simulator.
The OMNeT++ architecture consists of several components. First, there is a simula-tion kernel that contains all of the machinery necessary to support simulasimula-tion, such as the event queue, random number generators, statistics collection tools, etc. Second, there is a model component library that includes both a set of standard OMNeT++
components as well as any user-defined components. The simulation kernel inter-faces with one of two environments; a graphical user environment, called TKENV, or a command line environment, called CMDENV. TKENV is useful for graphical debugging and visual demonstrations whereas CMDENV is more suited to running large batches of automated simulations. Finally, the last component is the simulation model which is executed by the simulation kernel and displayed by the environment.
Simulation Model
The simulation model is the primary component supplied by the user. OMNeT++
is built around the notion of modules, which are simple reusable components that can be extended by the user. Modules can be connected together and interact via message passing and they form the basis of the simulation model.
Modules
There are two types of modules; simple modules and compound modules. Simple modules are the basic building blocks of a simulation model and can be connected together to create compound modules. Each simple module corresponds to a C++
class that derives from OMNeT++’s cSimpleModule base class. While the C++
class determines how the module behaves, the modules themselves are defined using OMNeT++’s “Network Description Language” (NED). The NED description for a simple module contains two sections. First, is the parameters section which defines any configurable properties and settings that the module may have. Second, is the gates section which defines the “ports” that allow modules to exchange messages with other modules. Compound modules include several additional sections to define the submodules that they contain and the internal connections between submodules.
Note that submodules may be either simple modules or other compound modules.
Finally, a compound module can be defined as a “network” which is the top level module that contains all of the other modules in the simulation model.
Channels
The connections between modules are called channels. The primary purpose of chan-nels is to deliver messages between modules. While OMNeT++ is not specifically designed to simulate communication networks, it does provide several types of chan-nels such as “DelayChannel” and “DatarateChannel” which are intended to represent physical links in a communication network.
Messages
Every event in simulation is represented by a message and all messages are instances of objects derived from the cMessage class that OMNeT++ provides. When a mes-sage arrives at a module, it uses the mesmes-sage properties to determine the type of event that occurs. Thus to simulate any event, a module must first send a message which causes the message to be placed on the event queue. To schedule an event to occur at a specific time, a module can send a message to itself and specify the time at which the message should arrive. A module can also trigger an event to occur in another module by sending a message out one of its ports. In this case, the module that re-ceives the message is determined by what is on the other end of the channel connected to the module’s outgoing port. Similarly, the time of message arrival depends on the type and properties of the channel and message. For example, OMNeT++ provides a cPacket class that extends cMessage. When it is sent over a DatarateChannel, the time of arrival is determined by the packet size and the channel’s data rate prop-erty. New message types can also be created using OMNeT++’s message definition language. OMNeT++ automatically reads the resulting .msg files and produces the corresponding C++ class which the user may optionally extend.
Experiments
Since a user will often want to conduct many different experiments using the same simulation model, OMNeT++ enforces a strict separation of the simulation model from specific simulation experiments. The simulation model consists of all the NED files, message files, and C++ code for the modules and messages in the simulation. An experiment, by contrast, is defined by a special INI configuration file and is considered separate from the model. The configuration file specifies which network module to
use, how the various module parameters should be set, which statistics to collect, as well as all of the general simulation parameters, such as the simulation run time, the warmup interval, the number of repetitions to perform, the seeds to use for the random number streams, and so forth.