Hi everybody. In this video, we're going to review OMNET++. Specifically,
we will learn how OMNET++ works and how ned files and ini
files work together. But first, let's review. So what is OMNET++?
OMNET++ is an object-oriented modular discrete-event network simulator
framework it has generic architecture so that it can be and has been used in
various problem domains. Some of the domains that has been used for is
modeling of wired and wireless communication, networks protocol model
modeling, modeling of queuing networks, modeling processors validating hardware
architecture, evaluating performance aspects for complex software systems
In general, it's just modeling and simulation of any system where there's a
discrete event approach that's suitable and can be conveniently mapped into
entities communicating by exchanging messages. OMNET++ provides
infrastructure and tools for writing simulations and it's really not a
simulator of anything concrete. OMNET++
simulations can run under various user interfaces, these user interfaces include
graphical user interfaces animating user interfaces which are useful for
demonstrating and debugging purposes and then there is command-line user
interfaces which are very useful for batch execution. So I mentioned that
OMNET++ uses modeling. So how does modeling work in OMNET++?
In OMNET++ models are assembled from reusable components which
are termed as modules well-written modules are truly reusable and they can
be combined in a various ways in our net plus plus a model consists of a module
that communicates with message passing the active modules are termed simple
modules so in this diagram here I'm showing these are our simple modules and
these are written in C++ and they used the simulation class library simple
models can be grouped to compound modules this is our group
for a compound module and those can be grouped so on and so forth there's a
number of hierarchy levels and it's unlimited
but overall the entire module is called a network. In OMNET++ the
network itself is a compound module so messages can be sent via connections
that span modules or directly to other models so let's look at how we can use
modeling to describe the structure of a system OMNET++ provides efficient
tools for users to describe the structure of an actual system and some
of the main features are hierarchical models module types message gates links
modeling the packet transmissions parameters and topology description
language. An OMNET++ model consists of hierarchically nested modules and
they communicate by passing messages to each other
the OMNET modules are often referred to as networks
and the top-level module is the system module
the system contains sub modules that can also contain some modules of themselves
as I mentioned before the depth of this module nesting is unlimited
this module structure is described in OMNET++ as ned language which we will
go over further on in this video the modules that contain our sub modules as
we just find before is called compound modules as opposed to our simple modules
at the lowest level of the module hierarchy simple modules contain the
algorithms of the model we the user implement the simple modules in C++
using our OMNET++ simulation class libraries then we have module types both
simple and compound modules are instances of module types when we are
describing the model we defined the module type and instances of module
types serve as components for complex module types all modules of a network
are instantiated as sub modules and sub sub modules of the system module go back
to the picture that I showed earlier these compound modules and these simple
model modules are all sub modules of the network messages gates and links are
used so that modules can communicate by exchanging messages in an actual
simulation messages represent the frames or packets of a in a computer network or
the jobs or customers and a queuing network or any other type of mobile
entities and messages can contain those arbitrary complex data structures simple
modules send messages either directly to their destination or along a predefined
path which would be done through gates and connections gates are the input and
output interfaces of modules and messages are sent through output gates
and arrive through input gates and each connection which also can be called a
link is created with single level of a module hierarchy and within the compound
one module you can connect two corresponding gates of two sub modules or a
gate of one sub module and a gate of a compound module but because of our
hierarchical structure of modules messages typically travel to a series of
connections starting and arriving in our simple modules so we kind of think of
our compound modules as cardboard boxes for the module and they transparently
relay messages between their inner realm and the outside world for using our
modeling we model packet transmissions to facilitate the modeling of
communication networks connections can be used to model physical links
connections support a bunch of different parameters such as data rate propagation
delay the error rate and packet error rate and those can be disabled and these
parameters and the underlying algorithms are encapsulated into channel objects
and users can parameterize the channel types provided by OMNET++ and
also we can create new ones modules can have parameters. Parameters can be
assigned in either the ned file or a corresponding file in the
omnetpp.ini file which is our configuration file parameters can be
used to customize simple module behavior and to parameterize a model's topology
parameters can take string numeric or boolean values and they can contain XML
data trees finally the topology description language so the user, which
is us, defines the structure of a model in the NED language descriptions which
is NED stands for network description. Which leads us to our next talking point,
What is the Ned language? So as I said before Ned stands for network
description, we, the user, described the structure of a simulation model in the
Ned language and the Ned language lets us declare simple models and connect and
assemble them into our compound modules that we learned about earlier we can
then label some compound modules as networks and that means that they're
self-contained simulation models channels are another type of another
component type where the instances can also be used in compound modules the Ned
language has several features which let it scale really well for our large
projects so one of the features is that it's hierarchical in omnec plus plus any
module that's too complex as a single entity can be broken down into smaller
modules and then we use a compound module its component base so simple
modules and compound modules are inherently you reusable which means that
we can reduce our code by copying and more importantly allows component
libraries which means that we're able to use our INET framework, or mixin, or
castella, or veins, etc to exist. There are
interfaces. Module and channel interfaces can be used as placeholders where you
know normally you would have a module or channel type and then you could have a
more concrete module that implements that interface that then gets
substituted in this is really useful we use this a lot in our simulations then
there is inheritance modules and channels can be subclassed and then
those derived modules can add new parameters and gates which is also
something that we use very often in our simulations the NED language has
features that are sort of Java like it has a package structure and this reduces
the risk of name clashes between different modules this has a Ned path
which is similar to the class path and it's been introduced to make it easier
to specify dependencies among simulation modules there is also inner types
these are channel types and module types that are used locally by a compound
module and we defined within the compound module in order to reduce
namespace pollution and then finally we have metadata annotation so it's
possible to annotate modules or channel types parameters or gates and add
different product properties metadata is not used by the simulation kernel
directly but it can carry extra information for various tools and
runtime environment for example the one that I use a lot is a modules graphical
representation which is like the icon then you can also have prompts for like
measurement units as well for the parameter and those are all metadata and
notations so we reviewed on that plus plus and the NED language let's now look
at a working example let's look at our AODV example in here I have already
opened the AODVNetwork.ned this defines our network in the OMNET++
ini file we are actually setting our network to AODVNetwork this is for
the general option remember that you can have different configurations within
OMNET++ on your ini file and if you scroll down to some of our AODV
examples we actually changed the network for example on the config SimpleRREQ2
it changed the network to SimpleRREQ2 so
it can be changed but right now on general it's set to AODV network inside
AODV network we defined several sub modules and each of these sub modules
actually can have their own sub modules as well so in AODV Network we have
radio medium configurator routing table scenario manager and host which has
number of hosts for its size number of hosts is a parameter that actually gets
set in our omnetpp.ini file so in our omnetpp.ini file we're setting
the number of hosts to 20 this is how we're sending all these parameters if
you can see here all these values that we are setting are actually parameters
within the either the AODV network file or its sub modules so let's go further
and look at one of our sub modules so I am looking at AODVRouter which is
off of the host for our host files so AODV router if you wanted to you can
always right-click and go to the declaration in my case I already have
them open so I'm going to AODVRouter this extends AdHocHost within it it
has its own sub module it has AODV as its sub module and it also defines a
connection it defines AODV socket out to go to at which is the message
dispatcher if you hover over it it says that it's the message dispatcher in plus
plus in plus plus is because at.in is a vector and the same idea of with
our socket in it's getting at.outs message dispatcher and it's going into
AODV so this is how it communicates at is the message dispatcher and at is defined
within adhoc host. So adhoc host extends wireless host here's some parameters set
for adhoc host and it has default values if you didn't set these parameters they
would default to a specific value you can do this as well within your ned file
so this ad-hoc host it extends wireless host wireless host extends standard
hosts which extends our application layer node base which defines at the
message dispatcher so that is actually where at lives so now you can actually
see how the hierarchy works how we work with parameters with our ned files and
how connections are created within our ned files the omnetpp ini file sets our
values for our parameters but you can also have those default values as well
on your parameters so you just got a quick overview on OMNET++ and Ned
files and how they interact with our ini files if you liked what you saw please
subscribe to my channel so you can get alerted for more OMNET++ tutorials
and other random tutorials as well