introduction to omnet++ -...

Network Traffic

Engineering:

Laboratory

a.y. 2016/2017

Introduction to OMNeT++

Ion TurcanuE-mail: [email protected]

Room 106, DIET

Department of Information

Engineering, Electronics and

Telecommunications (DIET)

mailto:[email protected]

Lab Overview

• Introduction to OMNeT++

• TicToc Tutorial

• M/M/1 queue simulation with OMNeT++

• Result analysis and evaluation with R

• Exam: full simulation experiment

Lab Overview

Outline

• Introduction

• OMNeT++ in a nutshell

– Discrete Event Simulation

– Simple and compound modules

– Messages, gates, links

– Building and running a simulation

• NEtwork Description Language (NED)

• Message definition

• Configuration file

• Programming modules in OMNeT++

• Results recording


Introduction

• What is OMNeT++?

– Objective Modular Network Testbed in C++ an

object-oriented modular discrete event network simulation

framework

• Where it can be used?

– modeling of wired and wireless communication networks

– protocol modeling

– modeling of queueing networks

– …

– modeling and simulation of any system where the discrete

event approach is suitable

• Is it a network simulator then?

– No. But it provides infrastructure and tools to write

‘network’ simulations


What does OMNeT++ provide?

• C++ class library

– Event-driven simulation kernel

– Utility classes: implementations of common functionality for network

simulations

• Random number generation

• Statistics collection

• Math functions, etc

• Infrastructure to assemble simulations

– Network Description (NED) language

– INI files

• User interfaces (environments) for simulations

– Tkenv

– Cmdenv

• Eclipse-based simulation IDE for designing, running and

evaluating simulations

• Extension interfaces for real-time simulation, emulation, parallel

distributed simulation, database connectivity, etc.


Discrete Event Simulation

• Discrete Event System – a system where state changes (events)

happen at discrete instances in time, and events take zero time to

happen.

• Systems that can be viewed as discrete event systems can be

modeled using Discrete Event Simulation (DES).


initialize -- this includes building the model and

inserting initial events to FES

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)

}

finish simulation (write statistical results, etc.)

• Future Event Set (FES)

• Event execution order in

OMNeT++:

1. Earlier arrival time

2. Higher scheduling priority

3. Scheduled/sent earlier

DES Loop

Example: packet transmission


Alice

Bob

e1

e2

e3

e4

• e1 – Alice starts transmitting the packet

• e2 – Bob starts receiving the packet

• e3 – Alice finishes transmitting the packet

• e4 – Bob finishes receiving the packet

e1

e2

e3

e4

…

head

Event Queue

OMNeT++ Simulation Model

• A simulation model consists of modules, which are

grouped/connected together

– Modules that are grouped together are themselves modules

– Hierarchical, modular, object-oriented modeling approach

• In OMNeT++, a simulation model is also called a

network

– A network is itself a module


Source: https://omnetpp.org/doc/omnetpp/manual/#sec:overview:modeling-concepts

Gates

Example: module hierarchy


Network

Node 1 … Node n

Application Network NIC

MAC PHY

DeciderAnalogModel

Module Types

• Simple Modules

– Base building blocks

– Declared using the NED language

– Contain the algorithms of the model implemented in C++

– Simple Modules grouped together form Compund Modules

• Compound Modules

– Describe the structure of the simulation model

– Module at top of hierarchy system module

– Modules below submodules (compound or simple

modules)

– Modules at bottom of hierarchy simple modules

– Hierarchy depth is unlimited


Messages, Gates, Links

• Messages

– Modules communicate by exchanging messages

– Can contain arbitrarily complex data structures (e.g., frames or

packets in a computer network, timers, etc)

– Messages can arrive from another module or from the same module

(self-messages are used to implement timers)

– Simple modules can send messages either directly to their destination

or along a predefined path, through gates and connections

• Gates

– Input and output interfaces of modules

– Messages are sent out through output gates

– Messages arrive through input gates

• Connections (Links)

– Two gates can be directly linked via connection


Building and running a simulation program


• To implement a simulation

model, the user must provide:

– The .ned files which describe

the modules

– The .msg files which describe

the messages

– The .h and .cc files which

implement the simple modules

behaviour

– The .ini file which contains

the simulation parameters

C++ sources

Compiling and linking

*_m.cc/h files

MSG files

opp_msgc

NED files

Running

omnetpp.ini

Simulation kernel anduser interface libraries

Simulation program

Result files

NEtwork Description Language (NED)

• Used to describe the structure of a simulation model.

• Features:

– Hierarchical: any complex module can be broken down into smaller

modules

– Component-Based: simple and compount modules are inherently

reusable

– Interfaces: placeholders for concrete module or channel types which are

determined at network setup time by a parameter

– Inheritance: modules and channels can be subclassed

– Packages: a Java-like package structure to reduce the risk of name

clashes between different models

– Inner types: channel types and module types used locally by a compound

module can be defined within the compound module

– Metadata annotations: extra information for various tools; not used by

the simulation kernel directly (e.g., icon, measurement unit, etc)


NED: network example


network FifoNet

{

submodules:

gen: Source {

parameters:

@display("p=89,100");

}

fifo: Fifo {

parameters:

@display("p=209,100");

}

sink: Sink {

parameters:

@display("p=329,100");

}

connections:

gen.out --> fifo.in;

fifo.out --> sink.in;

}

Compound modules can

be directly instantiated

as networks

Display string;

@something are called

properties – are used to

annotate objects with

metadata

NED: simple module example


simple Fifo

{

parameters:

volatile double serviceTime @unit(s);

@display("i=block/queue;q=queue");

gates:

input in;

output out;

}

volatile (non-const): C++

code is supposed to read it

on every use, not only

during initilization phase

Physical units:

(i) automatic conversion;

(ii) unit checking (cannot

convert mW to s)

Default icon

NED: channel example


network FifoNet

{

types:

channel C extends BasicChannel {

delay = 0.1ms

datarate = 1Gbps;

}

submodules:

gen: Source {…}

fifo: Fifo {…}

sink: Sink {…}

connections:

gen.out --> C --> fifo.in;

fifo.out --> C --> sink.in;

}

Bidirectional connections:

a <--> b

Is equivalent to:

a.out --> b.in

a.in <-- b.out

Message definition

• Messages are represented with the following classes:

– cPacket: used for network packets (frames, datagrams, transport

packets, etc.) in a communication network

– cMessage: used for everything else

• Example:


packet MyPacket

{

int srcAddress;

int destAddress;

int remainingHops = 32;

};

MyPacket.msg

MyPacket_m.cc

MyPacket_m.h

class MyPacket : public cPacket {

...

virtual int getSrcAddress() const;

virtual void setSrcAddress(int srcAddress);

...

};

Configuration file (.ini)

• Configuration and input data for the simulation are in a configuration file usually called omnetpp.ini


[General]

network = FifoNet

sim-time-limit = 100h

#debug-on-errors = true

#record-eventlog = true

[Config Fifo1]

description = "low job arrival rate"

**.gen.sendIaTime = exponential(0.2s)

**.gen.msgLength = 100b

**.fifo.bitsPerSec = 1000bps

[Config Fifo2]

extends = Fifo1

description = "high job arrival rate"

**.gen.sendIaTime = exponential(0.01s)

**.gen.msgLength = ${msgLength=5,10,20}b

repeat = 5

Configuration file grouped into

sections ([General], [Fifo1], [Fifo2])

Iterations (by default, they

correspond to measurements)

Repeat count (with different

seeds)

A configuration can extend

another, and override settings in

its base (inheritance chain defines

lookup order)

No extends means «extends =

General»

Programming modules behavior

• Simple modules and channels can be programmed by redefining

certain member functions, and providing your own code in them.

• Basic member functions:

– initialize()- perform all initialization tasks, read module parameters,

initialize class variables, allocate dynamic data structures with new, allocate

and initialize self-messages (timers) if needed.

– finish() – record statistics; do not delete anything or cancel timers all

cleanup must be done in the destructor.

– destructor – delete everything which was allocated by new.

– handleMessage() – it is invoked with the message as parameter

whenever the module receives a message; is expected to process the

message, and then return.

– send() – send messages to other modules

– scheduleAt() – schedule an event (send a message to itself)

– cancelEvent() – delete an event scheduled with scheduleAt()


Example: Hello Module


// file: HelloModule.cc

#include <omnetpp.h>

using namespace omnetpp;

class HelloModule : public cSimpleModule

{

protected:

virtual void initialize();

virtual void handleMessage(cMessage *msg);

};

// register module class with OMNeT++

Define_Module(HelloModule);

void HelloModule::initialize()

{

EV << "Hello World!\n";

}

void HelloModule::handleMessage(cMessage *msg)

{

delete msg; // just discard everything we receive

}

Example: Packet Generator


class Generator : public cSimpleModule

{

public:

Generator() : cSimpleModule() {}

protected:

virtual void initialize();

virtual void handleMessage(cMessage *msg);

};

Define_Module(Generator);

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);

}

Recording simulation results

• OMNeT++ provides built-in support for recording simulation results,

via output vectors and output scalars.

• Output Vectors – are time series data, recorded from simple modules

or channels.

• Output Scalars – are summary results, computed during the

simulation and written out when the simulation completes.

• Results may be collected and recorded in two ways:

1. Based on the signal mechanism, using declared statistics

2. Directly from C++ code, using the simulation library


What’s next?

• OMNeT++ manual is your best friend

https://omnetpp.org/doc/omnetpp/manual/

• TicToc Tutorial

https://omnetpp.org/doc/omnetpp/tictoc-tutorial/


introduction to omnet++ -...

Documents