Simulation using OMNet++

© 2008 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1

Simulation using OMNeT++

Jeromy Fu


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

Usabilityclean API, script language support, documentation

Scalabilitymulti-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 defined 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 modulemodule 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.


Submodulesmodule 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 specified 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++

Technology

Transcript of Simulation using OMNet++