0% found this document useful (0 votes)
110 views

Omnet

OMNeT++ is an object-oriented modular discrete event network simulation framework. It allows users to hierarchically model communication networks and other complex systems using modules. Modules can be simple or compound, with compound modules containing submodules. Modules communicate by exchanging messages through gates and connections. The framework includes features like parameters, channels to model connections between modules, and the NED language for describing network topology.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
110 views

Omnet

OMNeT++ is an object-oriented modular discrete event network simulation framework. It allows users to hierarchically model communication networks and other complex systems using modules. Modules can be simple or compound, with compound modules containing submodules. Modules communicate by exchanging messages through gates and connections. The framework includes features like parameters, channels to model connections between modules, and the NED language for describing network topology.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

OMNET++

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 queueing networks
◦ Modeling of multiprocessors and other distributed
hardware systems
◦ Validating of hardware architectures
◦ Evaluating performance aspects of complex software
systems
Modeling Concepts
 OMNeT++ provides efficient tools for the
user to describe the structure of the actual
system. Some of the main features are:
◦ Hierarchically nested modules
◦ Modules are instances of module types
◦ Modules communicate with messages through
channels
◦ Flexible module parameters
◦ Topology description language
Hierarchical Modules

 OMNeT++ models are often referred to as


networks.
 The top level module is the system module.
 The system module contains submodules,

which can also contain submodules


themselves
 The depth of module nesting is not limited
 Modules that contain submodules are termed

compound modules
Modules
Communication
 Modules communicate by exchanging message
 Gates
◦ Input and output interfaces of modules
 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
◦ Gate of one submodule and a gate of the compound
module
Connections
 Parameters:
◦ Bit error rate
 Probability that a bit is incorrectly transmitted, and
allows for simple noisy channel modeling.
◦ Propagation Delay
 Amount of time the arrival of the message is delayed
by when it travels through the channel.
◦ Data rate
 used for calculating transmission time of a packet
Parameters
 Modules can have parameters. Parameters
can be assigned either in the NED files or the
configuration file omnetpp.ini.

 Parameters can take


◦ String
◦ Numeric or boolean values
◦ XML data trees.
NED Language
 The topology of a model is specified using
the NED language.
 The NED language facilitates the modular

description of a network.
 Network description may consist of a number

of component descriptions (channels,


simple/compound module types).
Components of a NED Description

 Import directives

 Channel definitions

 Simple and compound module definitions

 Network definitions
Identifiers
 Identifiers are the names of modules,
channels, networks, submodules, parameters,
gates, channel attributes and functions.
◦ Reserved words should not be used.

 The network description and all identifiers in


it are case sensitive.
◦ For example, TCP and Tcp are two different names.
Channel Definition
 A channel definition specifies a connection type of
given characteristics
 SYNTAX:

channel ChannelName
//...
endchannel
 Optional attributes:

◦ Error
◦ Delay
◦ datarate
Channel Definition Example

channel LeasedLine
delay 0.0018 // sec
error 1e-8
datarate 128000 // bit/sec
endchannel
Simple Module

 Simple modules are the basic building blocks


for other (compound) modules.
 Simple module types are identified by names.
 By convention, module names begin with

upper-case letters.
 A simple module is defined by declaring its

parameters and gates.


Simple Module
 SYNTAX
simple SimpleModuleName
parameters:
//...
gates:
//...
endsimple
Gates
 Gates are the connection points of modules.

 Messages are sent through output gates and


received through input gates.

 Gates are identified by their names.

 Gate vectors are supported: a gate vector


contains a number of single gates.
Gates
simple Example1
parameters: //...
gates:
in input;
out output;
endsimple
simple Example2
parameters: //...
gates:
in input[];
out output[];
endsimple
Compound Module Definitions

 Compound modules are modules composed


of one or more submodules.

 Like simple modules, compound modules can


also have gates and parameters, and they can
be used wherever simple modules can be
used.
Compound Module
 SYNTAX:
module CompoundModule
parameters:
//...
gates:
//...
submodules:
//...
connections:
//...
endmodule
Submodules
 Submodules are instances of a module type,
either simple or compound – there is no
distinction.

 The module type must be known to the NED


compiler, that is, it must have appeared
earlier in the same NED file or have been
imported from another NED file.
Submodules
 SYNTAX:
module CompoundModule
//...
submodules:
submodule1: ModuleType1
parameters:
//...
gatesizes:
//...
submodule2: ModuleType2
parameters:
//...
gatesizes:
//...
endmodule
Module Vector
 It is possible to create an array of submodules (a
module vector).
 Done with an expression between brackets right behind
the module type name.
 EXAMPLE:
submodules:
submod1: Node1[3]
//...
submod2: Node2[size]
//...
submod3: Node3[2*size+1]
//...
‘input’ Keyword
 To get the value of a parameter from the
user, ‘input’ keyword is used.
 SYNTAX:

parameters:
numCPUs=input(10, "No of processors?");
// default value, prompt
processingTime = input(10ms);
// prompt text
cacheSize = input;
‘gatesizes’ Keyword

 The sizes of gate vectors are defined with the


gatesizes keyword.

 Gate vector sizes can be given as constants,


parameters or expressions.
‘gatesizes’ Keyword
simple Node
gates:
in: inputs[];
out: outputs[];
endsimple

module CompoundModule
parameters:
numPorts: const;
submodules:
node1: Node
gatesizes:
inputs[2], outputs[2];
node2: Node
gatesizes:
inputs[numPorts], outputs[numPorts];
//...
endmodule
Connections definition
 Connections are specified in the connections:
section of a compound module definition.
 By default, NED requires that all gates be
connected. Since this check can be inconvenient at
times, it can be turned off using the nocheck
modifier.
 EXAMPLE
connections nocheck:
node1.output --> node2.input;
node1.input <-- node2.output;
//...
Connections Definition
The gate++ notation allows you to extend a gate vector with new
gates, without having to declare the vector size in advance with
gatesizes

module SmallNet
simple Node submodules:
gates: node: Node[6];
connections:
in: in[]; node[0].out++ --> node[1].in++;
node[0].in++ <-- node[1].out++;
out: out[]; node[1].out++ -->node[2].in++;
endsimple node[1].in++ <-- node[2].out++;
node[1].out++ --> node[4].in++;
node[1].in++ <-- node[4].out++;
node[3].out++ --> node[4].in++;
node[3].in++ <-- node[4].out++;
node[4].out++ --> node[5].in++;
node[4].in++ <-- node[5].out++;
endmodule
Constants
 Numeric and string
constants
◦ Decimal or scientific
notations.
 String constants
◦ Uses double quotes.
 Time constants
◦ Seconds, milliseconds,
minutes or hours
Demo
 Create a project
 Simple module tic-toc
 Network initialisation
 Omnetpp.ini file
 Running of a project
 Add icon to tic toc and color
 Watch variable declare in class
 Self message using schedule at
 How to use parameters in modules in cc files
 Derived class
 Losing packet and resending it again
 Create a channel
 Gate vector
 statistics

You might also like