Simulation using OMNet++

Simulation using
OMNeT++

Jeromy Fu

Presentation_ID © 2008 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1

Agenda
 Why simulation
 OMNeT++ core components
 Write your own simulation program

Source: Placeholder for Notes is 14 points

Why simulation?
 Mathematical model, sometime difficult
 Impractical experiment ， PlanetLab helps
 Provide reproducible results
 Complementary methods, mathematical model validated
by simulation, simulation validate by experiments.


Simulator
 Usability
clean API, script language support, documentation
 Scalability
multi-thread ,distributed simulation
 Statistics
 underlying network simulation
network protocol, cross-traffic, link latency, topology


What is OMNeT++
 It’s not a simulator of anything concrete, but an object-
oriented modular discrete event network simulation
framework.
 Provides infrastructure and tools for writing simulators.
 Has a component architecture, can be used in various
problem domains.
 Support TK/TCL GUI and Cmd GUI.
 Support parallel distributed simulation.
 Portable(Linux, Mac OS, Windows etc).
 Well documented.


Omnest – commercial product
 http://www.omnest.com/references.php
 http://www.omnest.com/webdemo/ide/demo.html


OMNet++ vs Omnest


DES(Discrete Event Simulation)
initialize -- this includes building the model and inserting
initial events to FES(Future Event Set)

while ( FES not empty and simulation not yet complete)
{
retrieve first event from FES
t := timestamp of this event
process event
(processing may insert new events in FES or delete
existing ones)
}



OMNeT++ core components
 Simple module
 Compound module
 Gate
 Channel


Module
 Modules that contain sub-modules 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.
 Model structure is described in OMNeT++’s NED
language.


Messages, Gates, Links and Channels
 Modules communicate by exchanging messages.
 Simple modules can send messages either directly to
their destination or along a pre deﬁned path, through
gates and connections.
 Gates are the input and output interfaces of modules;
 Messages are sent out through output gates and arrive
through input gates. Typically travel through a series of
connections, starting and arriving in simple modules.
 Connections support the following parameters: data
rate, propagation delay, bit error rate and packet error
rate, and may be disabled.

Simulation class library
 Module, gate, parameter, channel
 Message, packet
 Container classes(e.g. queue, array)
 Data collection classes
 Statistic and distribution estimation class
 Transient detection and result accuracy detection
classes
 Reflection support for C++
 User Interface( GUI can even change the variable on-
the-fly, cmd UI support batch execution)

Simulator relating files
 NED language topology description(s)(.ned files) that
describe the module structure with parameters, gates,
etc.
 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.


Simulation process
 Read all NED files, dynamically building up the network.
 Read configuration file which contains values for model
parameters.
 Simulation runs until a pre-defined condition or user stop
it through GUI.
 Logs, vector file and scalar files can be recorded.
 A variety of tools are provided for post-analyze and
post-process.


Distribution directory


NED(Network Description)
 Hierarchical
 Component-based(support component libraries)
 Interfaces(concrete module or channel type can be
specified by parameters)(single, multiple inheritance?)
 Inheritance
 Packages
 Inner types
 Metadata annotations


Simple module
 Defined with ‘simple’ keyword
 Have optional parameters and gates sections
 Operation of the module is expressed in C++ Class,
which default have the same name with the module
name.
 @class, @namespace
 Can be extended


Simple module
simple Queue
{
parameters:
int capacity;
@class (mylib:Queue);
@display("i=block/queue");
gates:
input in;
outpu out;
}


Simple module
Simple BoundedQueue extends Queue
{
capacity = 10;
}

Simple PriorityQueue extends Queue //correct solution
{
@class(PriorityQueue);
}


Compound module
 Defined with ‘module’ keyword
 Group other modules into a large unit
 May have gates and params, but no behavior
associated
 Have ‘submodules’ section, ‘connections’ section is
optional
 Can defined inner module or channel types in ‘types’
section.
 Can be extended


Compound module
module WirelessHostBase
{
gates:
input radioIn;
submodules:
tcp: TCP;
ip: IP;
wlan: Ieee80211;
Connections:
tcp.ipOut --> ip.tcpIn;
tcp.ipIn <-- ip.tcpOut;
ip.nicOut++ --> wlan.ipIn;
ip.nicIn++ <-- wlan.ipOut;
wlan.radioIn <-- radioIn;
}

Compound module
module WirelessUser extends WirelessHostBase
{
submodules:
webAgent: WebAgent;
Connections:
webAgent.tcpOut --> tcp.appIn++;
webAgent.tcpIn <-- tcp.appOut++;
}


Compound module
module DesktopUser extends WirelessUser
{
gates:
inout ethg;
submodules:
eth: EthernetNic;
connections:
ip.nicOut++ --> eth.ipIn;
ip.nicIn++ <-- eth.ipOut;
eth.phy <--> ethg;
}


Channels
 Channels encapsulate parameters and behavior
associated with connections
 Have C++ classes behind them, so @class and
@namespace etc works the same with simple module
 Can define channel Class, however, the defaults are
enough(IdealChannel, DelayChannel, DatarateChannel)
 Can also be extended


Channels
channel C extends ned.DatarateChannel
{
datarate = 100Mbps;
delay = 100us;
ber = 1e-10;
}

channel DatarateChannel2 extends ned.DatarateChannel
{
double distance @unit(m);
delay = this.distance / 200000km * 1s;
}


Parameters
 Parameters are variables that belong to a module
 Parameters can be used in building the topology
(number of nodes, etc), and to supply input to C++ code
that implements simple modules and channels
 Can be specified in NED files or in configuration(‘ini’),
which one choose?
 support string, numeric or boolean values, or can
contain XML data trees
 Can use expression, can set default, sizeof operator,
‘index’ of the current module, refer to already defined
parameters, ‘volatile’
 @unit property

Gates
 Connection points of module
 Input, output, inout
 A module can have multiple gates(gate vector), size
need not specified
 @loose, @directIn, ‘allowunconnected’ keyword


Gates
simple Classifier{
parameters:
int numCategories;
gates:
input in[];
output out[numCategories];
}

simple GridNode
{
gates:
inout neighbour[4]@loose;
}

Submodules
 A compound module can have multiple submodules
(module vector), size SHOULD be specified.
 In submodule body, we can assign parameters, set the
size of gate vector, add/modify properties.
 Add new parameters and gates is not permitted.


Submodules
module Node
{
gates:
inout port[];
submodules:
routing: Routing {
parameters: // this keyword is optional
routingTable = "routingtable.txt";
gates:
in[sizeof(port)]; // set gate vector size
out[sizeof(port)];
}
queue[sizeof(port)]: Queue {
@display("t=queue id $id"); //modify display string
id = 1000 + index; //different "id" parameter for each element
}
connetions:
...
}

Connections
 Used for connecting gates
 Can not span across hierarchy levels
 ‘-->’,’<--’,’<-->’
 ‘gatename++’ notation


Connections
... <--> {delay=10ms;} <--> ...
... <--> {delay=10ms; ber=1e-8;} <--> ...
... <--> C <--> ...
... <--> BBone{cost=100; length=52km; ber=1e-8;} <--> ...
... <--> {@display("ls=red");} <--> ...
... <--> BBone{@display("ls=green,2");} <--> ...


Chain
module Chain{
parameters:
int count;
submodules:
node[count]: Node{
gates:
inout port[2];
}
connections allowunconneted:
for i = 0..count-2{
node[i].port[1] <--> node[i+1].port[0];
}
}

BinaryTree
simple BinaryTreeNode {
gates:
inout left;
inout right;
inout parent;
}

module BinaryTree {
parameters:
int height;
submodules:
node[2^height-1]: BinaryTreeNode;
connections allowunconnected:
for i=0..2^(height-1)-2 {
node[i].left <--> node[2*i+1].parent;
node[i].right <--> node[2*i+2].parent;
}
}

RandomGraph
module RandomGraph{
parameters:
int count;
double connectedness; //0.0<x<1.0
submodules:
node[count]: Node {
gates:
in[count];
out[count];
}
connections allowunconneted:
for i=0..count-1, for j=0..count-1{
node[i].out[j] --> node[j].in[i]
if i!=j && uniform(0,1)<connectedness;
}
}

Submodules type as a parameter
 A submodule type may be speciﬁed with a module
parameter of the type string, or in general, with any
string-typed expression.
 The syntax uses the ‘like’ keyword.

network Net6
{
parameters:
string nodeType;
submodules:
node[6]: <nodeType> like INode{
address = index;
}
connections:
...
}

Submodules type as a parameter
moduleinterface INode
{
parameters:
int address;
gates:
inout port[];
}

module SensorNode like INode
{
parameters:
int address;
...
gates:
inout port[];
...
}


Class Hierarchy


Simulation in pseudo code
perform simulation run;

build network
(i.e. the system module and its submodules recursively)

insert starter messages for all submodules using activity()

do callInitialize() on system module

enter event loop // (described earlier)

if (event loop terminated normally) // i.e. no errors
do callFinish() on system module

clean up


Simulation in pseudo code
callInitialize()
{
call to user-defined initialize() function
if( module is compound )
for (each submodule)
do callInitialize() on submodule
}

callFinish()
{
if( module is compound )
for (each submodule)
do callFinish() on submodule
call to user-defined finish() function
}


Event loop in more detail
while ( FES not empty and simulation not yet complete )
{
retreive first event from FES
t := timestamp of this event
m := module containing this event
if ( m works with handleMessage() )
m->handleMessage(event)
else // m works with activity()
transferTo(m)
}


activity() vs handleMessage()
 activity(), implemented using fiber in win32, coding more
or less like multi-thread, simple, but consume more
memory usage(stack), bad coding style. Not
recommendate.

 handleMessage(), messaged-based, event-driver.


Message processing in handleMessage()
 Send()
 ScheduleAt()
 CancelEvent()
 DO NOT use receive() and wait(), they’re used in
activity()


Simple Module example
class Generator : public cSimpleModule
{
public:
Generator(): cSimpleModule() {}
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
}

Define_Module(Generator);


Simple Module example
void Generator::initialize()
{
// schedule first sending
scheduleAt(simTime(), new cMessage);
}

void Generator::handleMessage(cMessage* msg)
{
// generate & send packet
cMessage * pkt = new cMessage;
send(pkt, "out");
// schedule next call
scheduleAt(simTime() + exponential(1.0), msg);
}

Message definition
 setter and getter
 reflection provided for messages(just like java)
 Compiled into .h and .cc files
 Can be used to define message and packets


Steps for application
1. Create a working directory called tictoc.
2. Describe your example network by creating a topology
file(*.ned).
3. We now need to implement the functionality of the simple
module(*.cc).
4. We now create the Makefile which will help us to compile and
link our program to create the executable tictoc:
$ opp_makemake
5. Compile and link our very first simulation by making command:
$ make
6.you have to create one. omnetpp.ini tells the simulation program
which network you want to simulate
7. Once you complete the above steps, you launch the simulation.

Building and running simulation


Tic-toc example: tictoc1.ned


Tic-toc example: txc1.cc


One-hop simulation


Q and A


Simulation using OMNet++

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Simulation using OMNet++

Similar to Simulation using OMNet++ (20)

Recently uploaded

Recently uploaded (20)

Simulation using OMNet++