Seminar report on Introduction to OMNeT++
Download as DOCX, PDF1 like1,224 views
The document summarizes an introduction seminar on OMNeT++, a discrete event network simulation framework. It discusses key OMNeT++ concepts like hierarchical modular modeling using modules, gates and messages. Models are built by defining module types and connecting instances in a topology. Simple modules contain algorithms coded in C++. The document outlines modeling concepts such as hierarchical modules, module types, messages/gates/links, and modeling packet transmission. It also briefly introduces the NED language for describing network topology.
![The corresponding NED description would look like this:
The above code defines a network type named Network. The network contains several nodes,
named node1, node2, etc. from the NED module type Node. The second half of the declaration
defines how the nodes are to be connected. The double arrow means bidirectional connection. The
connection points of modules are called gates, and the port++notation adds a new gate to
the port[] gate vector. Nodes are connected with a channel that has a data rate of 100Mbps.
The above code would be placed into a file named Net6.ned. It is a convention to put every NED
definition into its own file and to name the file accordingly, but it is not mandatory to do so.
One can define any number of networks in the NED files, and for every simulation the user has to
specify which network to set up. The usual way of specifying the network is to put
the network option into the configuration (by default the omnetpp.ini file):
[General]
network = Network
3.2.2 Introducing a Channel
It is cumbersome to have to repeat the data rate for every connection. Luckily, NED provides a
convenient solution: one can create a new channel type that encapsulates the data rate setting, and
this channel type can be defined inside the network so that it does not litter the global namespace.](https://image.slidesharecdn.com/seminarreport-141122210031-conversion-gate02/85/Seminar-report-on-Introduction-to-OMNeT-10-320.jpg)
![Compound modules, like simple modules, may have parameters and gates. Our Node module
contains an address parameter, plus a gate vector of unspecified size, named port. The actual
gate vector size will be determined implicitly by the number of neighbours when we create a network
from nodes of this type. The type of port[] is inout, which allows bidirectional connections.
The modules that make up the compound module are listed under submodules.
Our Node compound module type has an app and a routing submodule, plus
a queue[] submodule vector that contains one Queue module for each port, as specified
by [sizeof(port)]. (It is legal to refer to [sizeof(port)] because the network is built in top-down
order, and the node is already created and connected at network level when its submodule
structure is built out.)
In the connections section, the submodules are connected to each other and to the parent module.
Single arrows are used to connect input and output gates, and double arrows connect inout gates,
and a for loop is utilized to connect the routing module to each queue module, and to connect the
outgoing/incoming link (line gate) of each queue to the corresponding port of the enclosing module.
3.2.5 Putting It Together
We have created the NED definitions for this example, but how are they used by OMNeT++? When
the simulation program is started, it loads the NED files. The program should already contain the C++
classes that implement the needed simple modules, App, Routing and Queue; their C++ code is
either part of the executable or is loaded from a shared library. The simulation program also loads the
configuration (omnetpp.ini), and determines from it that the simulation model to be run is
the Network network. Then the network is instantiated for simulation.
The simulation model is built in a top-down preorder fashion. This means that starting from an empty
system module, all submodules are created, their parameters and gate vector sizes are assigned,
and they are fully connected before the submodule internals are built.](https://image.slidesharecdn.com/seminarreport-141122210031-conversion-gate02/85/Seminar-report-on-Introduction-to-OMNeT-14-320.jpg)
Seminar report on Introduction to OMNeT++
- 1. SEMINAR REPORT (Subject: Introduction to OMNeT++) Dharmsinh Desai Institute of Technology (Computer Engineering Department) Created By: Shivang Bajaniya (CE-05) Guided By: Prof. Mrudang Mehta
- 2. Table of Contents 1. Introduction 1.1 What is OMNeT++? 2. Overview 2.1 Modeling Concepts 2.1.1 Hierarchical Modules 2.1.2 Module Types 2.1.3 Messages, Gates, Links 2.1.4 Modeling of Packet Transmission 2.1.5 Topology Description Method 2.2 Programming the algorithms 2.3 Using OMNeT++ 2.3.1 Building and Running Simulations 3. The NED Language 3.1 NED Overview 3.2 NED Quick Start 3.2.1 The Network 3.2.2 Introducing a channel 3.2.3 The App, Routing and Queue Modules 3.2.4 The Node Compound Module 3.2.5 Putting It Together 4. Conclusion 5. References
- 3. 1. Introduction 1.1 What is OMNeT++? OMNeT++ is an object-oriented modular discrete event network simulation framework. It has a generic architecture, so it can be (and has been) used in various problem domains: modeling of wired and wireless communication networks protocol modeling modeling of queuing networks modeling of multiprocessors and other distributed hardware systems validating of hardware architectures evaluating performance aspects of complex software systems In general, modeling and simulation of any system where the discrete event approach is suitable, and can be conveniently mapped into entities communicating by exchanging messages. OMNeT++ itself is not a simulator of anything concrete, but rather provides infrastructure and tools for writing simulations. One of the fundamental ingredients of this infrastructure is a component architecture for simulation models. Models are assembled from reusable components termed modules. Well-written modules are truly reusable, and can be combined in various ways like LEGO blocks. Modules can be connected with each other via gates (other systems would call them ports), and combined to form compound modules. The depth of module nesting is not limited. Modules communicate through message passing, where messages may carry arbitrary data structures. Modules can pass messages along predefined paths via gates and connections, or directly to their destination; the latter is useful for wireless simulations, for example. Modules may have parameters that can be used to customize module behavior and/or to parameterize the model's topology. Modules at the lowest level of the module hierarchy are called simple modules, and they encapsulate model behavior. Simple modules are programmed in C++, and make use of the simulation library. OMNeT++ simulations can be run under various user interfaces. Graphical, animating user interfaces are highly useful for demonstration and debugging purposes, and command-line user interfaces are best for batch execution. The simulator as well as user interfaces and tools are highly portable. They are tested on the most common operating systems (Linux, Mac OS/X, Windows), and they can be compiled out of the box or after trivial modifications on most Unix-like operating systems.
- 4. OMNeT++ also supports parallel distributed simulation. OMNeT++ can use several mechanisms for communication between partitions of a parallel distributed simulation, for example MPI or named pipes. The parallel simulation algorithm can easily be extended, or new ones can be plugged in. Models do not need any special instrumentation to be run in parallel -- it is just a matter of configuration. OMNeT++ can even be used for classroom presentation of parallel simulation algorithms, because simulations can be run in parallel even under the GUI that provides detailed feedback on what is going on. OMNEST is the commercially supported version of OMNeT++. OMNeT++ is free only for academic and non-profit use; for commercial purposes, one needs to obtain OMNEST licenses from Simulcraft Inc. 2. Overview 2.1 Modeling Concepts 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 unlimited. The whole model, called network in OMNeT++, is itself a compound module. Messages can be sent either via connections that span modules or directly to other modules. The concept of simple and compound modules is similar to DEVS atomic and coupled models. In Fig. below, boxes represent simple modules (gray background) and compound modules. Arrows connecting small boxes represent connections and gates. Modules communicate with messages that may contain arbitrary data, in addition to usual attributes such as a timestamp. 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 through output gates and arrive through input gates. An input gate and output gate can be linked by 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 hierarchy levels are not permitted, as
- 5. they would hinder model reuse. Because of the hierarchical structure of the model, messages typically travel through a chain of connections, starting and arriving in simple modules. Compound modules act like "cardboard boxes" in the model, transparently relaying messages between their inner realm and the outside world. Parameters 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 used mainly to pass configuration data to simple modules, and to help define model topology. Parameters can 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. OMNeT++ provides efficient tools for the user to describe the structure of the actual system. Some of the main features are the following: hierarchically nested modules modules are instances of module types modules communicate with messages through channels flexible module parameters topology description language 2.1.1 Hierarchical Modules An OMNeT++ model consists of hierarchically nested modules that communicate by passing messages to each other. OMNeT++ models are often referred to as networks. The top level module is the system module. The system module contains submodules that can also contain submodules themselves. The depth of module nesting is unlimited, allowing the user to reflect the logical structure of the actual system in the model structure. Model structure is described in OMNeT++'s NED language. Modules that contain submodules are termed compound modules, as opposed to simple modules at the lowest level of the module hierarchy. Simple modules contain the algorithms of the model. The user implements the simple modules in C++, using the OMNeT++ simulation class library. 2.1.2 Module Types Both simple and compound modules are instances of module types. In 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 an instance of a previously defined module type; all modules of the network are instantiated as submodules and sub-submodules of the system module. When a module type is used as a building block, it makes no difference whether it is a simple or compound module. This allows the user to split a simple module into several simple modules
- 6. embedded into a compound module, or vice versa, to aggregate the functionality of a compound module into a single simple module, without affecting existing users of the module type. 2.1.3 Messages, Gates and Links Modules communicate by exchanging messages. In an actual simulation, messages can represent frames or packets in a computer network, jobs or customers in a queuing network or other types of mobile entities. Messages can contain arbitrarily complex data structures. Simple modules can send messages either directly to their destination or along a predefined path, through gates and connections. The “local simulation time” of a module advances when the module receives a message. The message can arrive from another module or from the same module (self-messages are used to implement timers). Gates are the input and output interfaces of modules; messages are sent out through output gates and arrive through input gates. Each connection (also called link) is created within a single level of the module hierarchy: within a compound module, one can connect the corresponding gates of two submodules, or a gate of one submodule and a gate of the compound module. Because of the hierarchical structure of the model, messages typically travel through a series of connections, starting and arriving in simple modules. Compound modules act like “cardboard boxes” in the model, transparently relaying messages between their inner realm and the outside world. 2.1.4 Modeling of Packet Transmission To facilitate the modeling of communication networks, connections can be used to model physical links. Connections support the following parameters: data rate, propagation delay, bit error rate and packet error rate, and may be disabled. These parameters and the underlying algorithms are encapsulated into channel objects. The user can parameterize the channel types provided by OMNeT++, and also create new ones. When data rates are in use, a packet object is by default delivered to the target module at the simulation time that corresponds to the end of the packet reception. Since this behavior is not suitable for the modeling of some protocols (e.g. half-duplex Ethernet), OMNeT++ provides the possibility for the target module to specify that it wants the packet object to be delivered to it when the packet reception starts. 2.1.5 Parameters Modules can have parameters. Parameters can be assigned in either the NED files or the configuration file omnetpp.ini. Parameters can be used to customize simple module behavior, and to parameterize the model topology.
- 7. Parameters can take string, numeric or Boolean values, or can contain XML data trees. Numeric values include expressions using other parameters and calling C functions, random variables from different distributions, and values input interactively by the user. Numeric-valued parameters can be used to construct topologies in a flexible way. Within a compound module, parameters can define the number of submodules, number of gates, and the way the internal connections are made. 2.1.6 Topology Description Method The user defines the structure of the model in NED language descriptions (Network Description). 2.2 Programming the Algorithms Simulation objects (messages, modules, queues etc.) are represented by C++ classes. They have been designed to work together efficiently, creating a powerful simulation programming framework. The following classes are part of the simulation class library: module, gate, parameter, channel message, packet container classes (e.g. queue, array) data collection classes Statistic and distribution estimation classes (histograms, P2 algorithm for calculating quintiles etc.) transient detection and result accuracy detection classes The classes are also specially instrumented, allowing one to traverse objects of a running simulation and display information about them such as name, class name, state variables or contents. This feature makes it possible to create a simulation GUI where all internals of the simulation are visible. 2.3 Using OMNeT++ 2.3.1 Building and Running Simulations An OMNeT++ model consists of the following parts: NED language topology description(s) (.ned files) that describe the module structure with parameters, gates, etc. NED files can be written using any text editor, but the OMNeT++ IDE provides excellent support for two-way graphical and text editing. Message definitions (.msg files). You can define various message types and add data fields to them. OMNeT++ will translate message definitions into full-fledged C++ classes. Simple module sources. They are C++ files, with .h/.cc suffix. The simulation system provides the following components: Simulation kernel. This contains the code that manages the simulation and the simulation class library. It is written in C++, compiled into a shared or static library.
- 8. User interfaces. OMNeT++ user interfaces are used in simulation execution, to facilitate debugging, demonstration, or batch execution of simulations. They are written in C++, compiled into libraries. Simulation programs are built from the above components. First, .msg files are translated into C++ code using the opp_msgc. Program. Then all C++ sources are compiled and linked with the simulation kernel and a user interface library to form a simulation executable or shared library. NED files are loaded dynamically in their original text forms when the simulation program starts. The simulation may be compiled as a standalone program executable; thus it can be run on other machines without OMNeT++ being present, or it can be created as a shared library. In this case the OMNeT++ shared libraries must be present on that system. When the program is started, it first reads all NED files containing your model topology, then it reads a configuration file (usually calledomnetpp.ini). This file contains settings that control how the simulation is executed, values for model parameters, etc. The configuration file can also prescribe several simulation runs; in the simplest case, they will be executed by the simulation program one after another. The output of the simulation is written into result files: output vector files, output scalar files, and possibly the user's own output files. OMNeT++ contains an Integrated Development Environment (IDE) that provides rich environment for analyzing these files. Output files are line-oriented text files which makes it possible to process them with a variety of tools and programming languages as well, including Matlab, GNU R, Perl, Python, and spreadsheet programs. 3. The NED Language 3.1 NED Overview The user describes the structure of a simulation model in the NED language. NED stands for Network Description. NED lets the user declare simple modules, and connect and assemble them into compound modules. The user can label some compound modules as networks; that is, self-contained simulation models. Channels are another component type, whose instances can also be used in compound modules. The NED language has several features which let it scale well to large projects: Hierarchical. The traditional way to deal with complexity is by introducing hierarchies. In OMNeT++, any module which would be too complex as a single entity can be broken down into smaller modules, and used as a compound module. Component-Based. Simple modules and compound modules are inherently reusable, which not only reduces code copying, but more importantly, allows component libraries (like the INET Framework, MiXiM, Castalia, etc.) to exist. 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, given a compound module type named MobileHost contains a mobilitysubmodule of the type IMobility (where IMobility is a module interface), the actual type of mobility may be chosen from the module types that implemented IMobility (RandomWalkMobility,TurtleMobility, etc.)
- 9. Inheritance. Modules and channels can 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 anFTPClientApp from it by setting certain parameters to a fixed value; or to derive a WebClientHost compound module from a BaseHost compound module by adding a WebClientApp submodule and connecting it to the inherited TCP submodule. Packages. The NED language features a Java-like package structure, to reduce the risk of name clashes between different models. NEDPATH (similar to Java's CLASSPATH) has also been introduced to make it easier to specify dependencies among simulation models. Inner types. Channel types and module types used locally by a compound module can be defined within the compound module, in order to reduce namespace pollution. Metadata annotations. It is possible to annotate module or channel types, parameters, gates and submodules by adding properties. Metadata are not used by the simulation kernel directly, but they can carry extra information for various tools, the runtime environment, or even for other modules in the model. For example, a module's graphical representation (icon, etc) or the prompt string and measurement unit (milliwatt, etc) of a parameter are already specified as metadata annotations. 3.2 NED Quickstart Our hypothetical network consists of nodes. On each node there is an application running which generates packets at random intervals. The nodes are routers themselves as well. We assume that the application uses datagram-based communication, so that we can leave out the transport layer from the model. 3.2.1 The Network First we'll define the network, then in the next sections we'll continue to define the network nodes. Let the network topology be as in Figure below.
- 10. The corresponding NED description would look like this: The above code defines a network type named Network. The network contains several nodes, named node1, node2, etc. from the NED module type Node. The second half of the declaration defines how the nodes are to be connected. The double arrow means bidirectional connection. The connection points of modules are called gates, and the port++notation adds a new gate to the port[] gate vector. Nodes are connected with a channel that has a data rate of 100Mbps. The above code would be placed into a file named Net6.ned. It is a convention to put every NED definition into its own file and to name the file accordingly, but it is not mandatory to do so. One can define any number of networks in the NED files, and for every simulation the user has to specify which network to set up. The usual way of specifying the network is to put the network option into the configuration (by default the omnetpp.ini file): [General] network = Network 3.2.2 Introducing a Channel It is cumbersome to have to repeat the data rate for every connection. Luckily, NED provides a convenient solution: one can create a new channel type that encapsulates the data rate setting, and this channel type can be defined inside the network so that it does not litter the global namespace.
- 11. The improved network will look like this: 3.2.3 The App, Routing and Queue Simple Modules Simple modules are the basic building blocks for other (compound) modules, denoted by the simple keyword. All active behavior in the model is encapsulated in simple modules. Behavior is defined with a C++ class; NED files only declare the externally visible interface of the module (gates, parameters).In our example, we could define Node as a simple module. However, its functionality is quite complex (traffic generation, routing, etc), so it is better to implement it with several smaller simple module types which we are going to assemble into a compound module. We'll have one simple module for traffic generation (App), one for routing (Routing), and one for queuing up packets to be sent out (Queue). For brevity, we omit the bodies of the latter two in the code below.
- 12. By convention, the above simple module declarations go into the App.ned, Routing.ned and Queue.ned files. Let us look at the first simple module type declaration. App has a parameter called destAddress (others have been omitted for now), and two gates named out and in for sending and receiving application packets. The argument of @display() is called a display string, and it defines the rendering of the module in graphical environments; "i=..." defines the default icon. Generally, @-words like @display are called properties in NED, and they are used to annotate various objects with metadata. Properties can be attached to files, modules, parameters, gates, connections, and other objects, and parameter values have a very flexible syntax.
- 13. 3.2.4 The Node Compound Module Now we can assemble App, Routing and Queue into the compound module Node. A compound module can be thought of as a “cardboard box” that groups other modules into a larger unit, which can further be used as a building block for other modules; networks are also a kind of compound module.
- 14. Compound modules, like simple modules, may have parameters and gates. Our Node module contains an address parameter, plus a gate vector of unspecified size, named port. The actual gate vector size will be determined implicitly by the number of neighbours when we create a network from nodes of this type. The type of port[] is inout, which allows bidirectional connections. The modules that make up the compound module are listed under submodules. Our Node compound module type has an app and a routing submodule, plus a queue[] submodule vector that contains one Queue module for each port, as specified by [sizeof(port)]. (It is legal to refer to [sizeof(port)] because the network is built in top-down order, and the node is already created and connected at network level when its submodule structure is built out.) In the connections section, the submodules are connected to each other and to the parent module. Single arrows are used to connect input and output gates, and double arrows connect inout gates, and a for loop is utilized to connect the routing module to each queue module, and to connect the outgoing/incoming link (line gate) of each queue to the corresponding port of the enclosing module. 3.2.5 Putting It Together We have created the NED definitions for this example, but how are they used by OMNeT++? When the simulation program is started, it loads the NED files. The program should already contain the C++ classes that implement the needed simple modules, App, Routing and Queue; their C++ code is either part of the executable or is loaded from a shared library. The simulation program also loads the configuration (omnetpp.ini), and determines from it that the simulation model to be run is the Network network. Then the network is instantiated for simulation. The simulation model is built in a top-down preorder fashion. This means that starting from an empty system module, all submodules are created, their parameters and gate vector sizes are assigned, and they are fully connected before the submodule internals are built.
- 15. 4. Conclusion From the above discussion we can conclude that OMNeT++ is an object-oriented modular discrete event network simulation framework that is very easy and efficient to use for many networking problems and also creating new networks and simulating them. It has a generic architecture, so it can be (and has been) used in various problem domains. It has user friendly GUI, that puts its use at ease. 5. References https://www.wikipedia.org http://www.omnetpp.org/doc/omnetpp