Simulation using OMNet++

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

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

Connection points of module

Input, output, inout

A module can have multiple gates(gate vector), size need not specified

@loose, @directIn, ‘allowunconnected’ keyword

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");} <--> ...

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

COMPUTER NETWORK SIMULATION USING OMNET++prr.hec.gov.pk/jspui/bitstream/123456789/48/1... · QualNet, GloMoSiM, JiST/SWANS, DIVERT, NCTUns, etc.) [1] [2] based on sequential/parallel

AVENS–ANovelFlyingAdHocNetworkSimulatorwithAutomaticCode ... ... aerial network simulation framework, ... lator and OMNeT++ Discrete Event Simulator. In a

Performance Evaluation of Opportunistic Routing Protocols: A Framework-based Approach using OMNeT++

A Comparative Study of AODV, DSR, and DYMO routing protocols using OMNeT

OMNET++ AND MIXIM FRAMEWORK - create-net.org · OMNET++ AND MIXIM FRAMEWORK ... Partial list of OMNeT++-based network simulators and simulation frameworks: ... import "ethernet";

Introduction to OMNeT++ - uniroma1.itnetlab.uniroma1.it/netgroup/sites/default/files/intro_omnet++.pdf · • In OMNeT++, a simulation model is also called a ... – A network is

OMNeT++ User Guide · Chapter 1. Introduction The OMNeT++ simulation IDE is based on the Eclipse platform and extends it with new editors, views, wizards, and other functionality.

OMNeT++ - gipuzkoa · Introduction OMNeT++ is an object-oriented modular discrete event system simulation framework. It has a generic architecture, so it can be used in various problem

Simulation of Ad Hoc Routing Protocols using OMNeT++ of Ad Hoc Routing Protocols using OMNeT++ A Case Study for the DYMO Protocol ... In the context of the INET Framework and the mobility

SIMULATION OF ELECTRICAL GRID WITH OMNET++ OPEN …

Introduction to simulation with omNeT ++

Data Center Modeling and Simulation Using OMNeT++

Trace-driven Co-simulation of High-Performance … · Trace-driven Co-simulation of High-Performance Computing Systems using OMNeT++ Cyriel Minkenberg IBM Zurich Research Laboratory

KNX IP Simulation - TU Wien IP Simulation (Revised).pdf · OMNeT++. A discrete event simulation environment ... Source(s)) Sink. Routing_Busy ... KNX IP Simulation ...

Energy Consumption Investigations in WSN using OMNeT++

Tic-Toc Tutorial...Tic-Toc Tutorial Contents TicToc Tutorial for OMNeT++ This short tutorial to OMNeT++ guides you through an example of modeling and simulation, showing you along

Simulation of Ad Hoc Routing Protocols using OMNeT · 2020. 1. 13. · based network simulator such as the well known ns-2. OMNeT++ already provides the framework for comprehensive

04 Introduction to Network Simulation Tools · PDF fileIntroduction to Network Simulators ... • OMNeT++ is an open-source, ... 4.5 Network Simulation Tools

Simulation of Ad Hoc Routing Protocols using OMNeT of Ad Hoc Routing Protocols using OMNeT++ ... OMNeT++ already provides the framework for comprehensive simulation setups. In the

A Simulation Framework for V2V Wireless Systems · A Simulation Framework for V2V Wireless Systems ... V2V System Simulation Framework OMNeT++ ... A Simulation Framework for V2V Wireless