intro omnetpp-if13-published
DESCRIPTION
Lecture and Tutorial on Simulation and Modelling Networks in general and with OMNeT++ in particular. Given at the Informatica Feminale summer school in Bremen, Germany, August 2013.TRANSCRIPT
Network Modeling and Simulation with OMNeT++ Dr. Anna Förster [email protected] Informa4ca Feminale, Bremen August 2013
What is simulation?
Image sources: Wikipedia
Copyrig
ht Dr. An
na Förster 2013
3
Network Simulation • What is network simula4on? • A program models the behavior of a network by calcula4ng the interac4on between the individual en44es (nodes) either with the help of mathema4cal formulas or by capturing and playing back real world observa4ons.
• What is network emula4on? • When simula4on is combined with real-‐4me applica4ons.
Copyrig
ht Dr. An
na Förster 2013
4
Simulation -‐ Advantages • Hardware-‐independent studies • Environment-‐independent studies • Low-‐cost • Fast evalua4on of many different scenarios and parameter seQngs
• Repeatability of experiments • Visibility of experiments (debugging) • Step-‐wise adding of complexity possible
Copyrig
ht Dr. An
na Förster 2013
5
Simulation -‐ Disadvantages • Simula4on can only mimic reality, can never reach its complexity
• Targeted environment might not be covered in simula4on models (and comes usually at a surprise!)
• Real hardware with its proper4es (interrupts, failures, baYery failures, …) is not captured
• Slight differences in simula4on seQngs result in completely different behavior – error-‐prone process!
Copyrig
ht Dr. An
na Förster 2013
6
Simulation Basics • The following basics need to be simulated: • Time • Network par4cipants or nodes • Con4nuous processes at the nodes • Connec4ons between nodes and their proper4es • Informa4on exchange between nodes
Copyrig
ht Dr. An
na Förster 2013
7
Simulating Time • Real-‐4me simula4on • Real 4me is used to simulate events and the development of a system. Oaen combined with emula4on, real world hardware, etc.
• Discrete Event based simula4on • Events of a system are ordered in a simulated 4me and processed in order. (Markov chain)
Copyrig
ht Dr. An
na Förster 2013
8
Simulating Time -‐ Example • A single node with a life4me of 1 year • Every 10 minutes, the node sends out a message (blinking?)
Start of life4me Regular blinking
4me
• Real 4me simula4on: – Time factor 1:1, length of simula4on 1 year, blinking every 10 minutes, most of the 4me the simula4on is inac4ve (wai4ng)
– Time factor 1:525600, length of simula4on 1 hour, blinking every approx. 1 msec.
• Event based simula4on: – No 4me factors, only events are processed. Blinking constantly!
Copyrig
ht Dr. An
na Förster 2013
9
Time properties in event based simulation
• Simula4on 4me is not real 4me! • Events get ordered in a queue by their 4me • The processing of one event takes zero simula4on 4me • One event gets completely processed, before another can start
• No going back in simula4on 4me! • Each event can schedule another events, but only in the future!
Copyrig
ht Dr. An
na Förster 2013
10
Simulating network nodes What is a network node? • A single, independent unit in an environment: a body, a building, an organism, a device, etc.
• The node acts independently of all other nodes in the network • The node has the ability to communicate with other nodes • Typically represented by a box
Node 1 Node 2 Copyrig
ht Dr. An
na Förster 2013
11
Simulating continuous processes at the node
• Con4nuous processes: aging, baYery levels, etc. • We need to discre4ze the process: • Define a variable to represent the current level: age, baYery level, etc.
• Define a metric: years or seconds, percent or mA • Define a 4me step to change the variable: 1 year, 10 seconds, 1 msec.
• How precise should we go? • It depends on the processes using the variable. • For example, if we send a message every 10 minutes and we need to check the baYery level before doing it, a minute-‐precise 4me step is enough.
• On the other side, the :me step precision depends on the variable precision.
• For example, if the baYery level has only a 0 and 1 precision, higher 4me precision is advisable.
Copyrig
ht Dr. An
na Förster 2013
12
Connections between nodes • In order to exchange something, we first need a connec4on or a channel.
• Example from our world: voice and ears, pictures and eyes, things and hands.
• In simula4on, a channel is a way to exchange something between two nodes (of course, only virtual things)
• Connec4ons are typically represented by an arrow and have some proper4es
Copyrig
ht Dr. An
na Förster 2013
13 Node 1 Node 2
Connections between nodes • Proper4es of links: • Direc:on: the direc4on, in which things can flow. Could be unidirec4onal or bidirec4onal
• Latency: 4me needed for the exchanged thing to pass from one node to the other via this channel.
• Capacity: how many things at once can pass through the channel. • Addi4onally, we need a way to send things from the nodes to that channel. We usually call this gates. Real-‐world analogy is the mouth – it is our gate from our brain to the voice channel.
• Gates have also some proper4es: • One gate is connected to exactly one channel (link) • A gate can be either unidirec4onal or bidirec4onal
Copyrig
ht Dr. An
na Förster 2013
14 Node 1 Node 2
Information exchange between nodes
• Various types of informa4on or things can be exchanged: • Organic viruses or generally sicknesses • Digital media like SMS, mail, videos, etc.
Copyrig
ht Dr. An
na Förster 2013
15
How to model a network It is an intui4ve process, not a science! 1. Iden4fy your nodes – organisms, people, devices, buildings, etc.
Don’t forget: they are independent of each other! • Good example: all your nodes are people. Or: some of your nodes are smart-‐phones, others are laptops.
• Bad example: some of your nodes are people, others are laptops. Or: some are buildings, others are smart-‐phones
2. Iden4fy the communica4on channels and iden4fy their proper4es (direc4on, latency and capacity)
3. Connect any two nodes which are able to communicate to each other with an individual connec4on. This might take a lot of gates and connec4ons!
4. Make sure that both nodes, who are able to communicate to each other, can process the same type of informa4on. For example, you cannot send a voice mail to a building or a human virus to a smart-‐phone.
Copyrig
ht Dr. An
na Förster 2013
16
How to model realistically • Stay real! • Do not model behavior, which is impossible in the real world: • Receiving data faster than sending • Smart-‐phones able to see and process organic viruses • …
• Keep the same level of detail everywhere: • Do not mix smart-‐phones and low-‐level hardware, such as a CPU.
• At the same 4me, abstract as much from the real world as possible! • Example: you want to model a network of people, communica4ng via
devices. What you are interested in, is the spread of informa4on between people. Solu4on: model only the people, do not care of the means of communica4on. Assume the communica4on link is simple and can pass any informa4on between the people.
• Example: same as above, but you are interested in understanding what kind of baYeries you need to provide to the people for their devices. Solu4on: you need to go deeper in detail and simulate abstract devices with proper4es such as how much energy they need to exchange a piece of informa4on.
Copyrig
ht Dr. An
na Förster 2013
17
Design Exercise (1) • Design a model for the following scenario: • A family owns a so called “smart home”, reachable via a central device over internet. The family members have different rights and can reach various devices in the house: • The mother and the father can give commands to the general hea4ng system, to the window opening/closing system, to the kitchen devices and to the TV. They can also send a message through the system to all other members, which will be displayed on the screen in the entrance and can add/delete items to the joint shopping list.
• The older children (e.g. aged 12-‐14) can give commands to the TV, can send messages, only add items to the shopping list and can see the current status of all other devices
• The younger children can only see the current status of all devices, can send messages and add items to the shopping list, which are however marked for approval by the parents.
Copyrig
ht Dr. An
na Förster 2013
18
Design Exercise (2) • Design the model, given that: • You are interested in the general correctness of the system and the existence of all needed links
• You need to be able to inject different (also faulty!) commands from the different family members
• You need to be able to observe the current status of each device (incl. the message screen and the shopping list)
Copyrig
ht Dr. An
na Förster 2013
19
Design Exercise (3) – Solution • Three types of nodes with proper4es: • End user device with level of trust (rights) • Central smart home device • Home device with internal status (simply a list of possible text values)
Copyrig
ht Dr. An
na Förster 2013
20
Working with OMNeT++
Copyrig
ht Dr. An
na Förster 2013
21
} Define the model structure in the NED language. You can edit NED in a text editor or in the graphical editor of the Eclipse-‐based OMNeT++ Simula4on IDE.
} An OMNeT++ model is build from components (modules) which communicate by exchanging messages. Modules can be nested, that is, several modules can be grouped together to form a compound module. When crea4ng the model, you need to map your system into a hierarchy of communica4ng modules.
} The ac4ve components of the model (simple modules) have to be programmed in C++, using the simula4on kernel and class library.
} Provide a suitable omnetpp.ini to hold OMNeT++ configura4on and parameters to your model. A config file can describe several simula4on runs with different parameters.
} Build the simula4on program and run it. You'll link the code with the OMNeT++ simula4on kernel and one of the user interfaces OMNeT++ provides. There are command line (batch) and interac4ve, graphical user interfaces.
} Simula4on results are wriYen into output vector and output scalar files. You can use the Analysis Tool in the Simula4on IDE to visualize them. Result files are text-‐based, so you can also process them with R, Matlab or other tools.
Source: omnetpp.org
OMNeT++ IDE
Copyrig
ht Dr. An
na Förster 2013
22
Tic-‐Toc Step-‐by-‐Step Tutorial simple Txc1 { !
!gates: !! !input in; !! !output out; !
} !network Tictoc1 { !
!submodules: !! !tic: Txc1; !! !toc: Txc1; !!connections: !! !tic.out --> { delay = 100ms; } --> toc.in;!! !tic.in <-- { delay = 100ms; } <--
toc.out; !} !
Copyrig
ht Dr. An
na Förster 2013
23
Tic-‐Toc Step-‐by-‐Step Tutorial simple Txc1 { !
!gates: !! !input in; !! !output out; !
} !network Tictoc1 { !
!submodules: !! !tic: Txc1; !! !toc: Txc1; !!connections: !! !tic.out --> { delay = 100ms; } --> toc.in;!! !tic.in <-- { delay = 100ms; } <--
toc.out; !} !
Defini3on of a simple module, with only 2 gates, named IN and OUT
Copyrig
ht Dr. An
na Förster 2013
24
Tic-‐Toc Step-‐by-‐Step Tutorial simple Txc1 { !
!gates: !! !input in; !! !output out; !
} !network Tictoc1 { !
!submodules: !! !tic: Txc1; !! !toc: Txc1; !!connections: !! !tic.out --> { delay = 100ms; } --> toc.in;!! !tic.in <-- { delay = 100ms; } <--
toc.out; !} !
Defini3on of a network, consis3ng of two sub-‐modules, both of type Txc1 and with connec3ons between their gates
Copyrig
ht Dr. An
na Förster 2013
25
Tic-‐Toc Step-‐by-‐Step Tutorial
#include <string.h> !#include <omnetpp.h> !class Txc1 : public cSimpleModule { !
!protected: !!// The following redefined virtual function holds
the algorithm. !! !virtual void initialize(); !! !virtual void handleMessage(cMessage *msg); !
}; !
Implementa3on of the Txc1 module – header file
Copyrig
ht Dr. An
na Förster 2013
26
Tic-‐Toc Step-‐by-‐Step Tutorial
// The module class needs to be registered with OMNeT++ !Define_Module(Txc1); !void Txc1::initialize() { !
// Initialize is called at the beginning of the simulation. !// To bootstrap the tic-toc-tic-toc process, one of the modules needs !// to send the first message. Let this be `tic'. !// Am I Tic or Toc? !
! !if (strcmp("tic", getName()) == 0) { !! !// create and send first message on gate "out". "tictocMsg" is an !
! !// arbitrary string which will be the name of the message object. !! !cMessage *msg = new cMessage("tictocMsg"); !! !send(msg, "out"); } } !
void Txc1::handleMessage(cMessage *msg) { !// The handleMessage() method is called whenever a message arrives !// at the module. Here, we just send it to the other module, through !
// gate `out'. Because both `tic' and `toc' does the same, the message !// will bounce between the two. !
! !send(msg, "out"); } !
Implementa3on of the Txc1 module – source file
Copyrig
ht Dr. An
na Förster 2013
27
Simple Module
NED source (C++)
Module
Module Module
Network
Module Module
omnetpp.ini
executable
Copyrig
ht Dr. An
na Förster 2013
28
Creating Messages • Creating a new message:!!cMessage *msg = new cMessage(“message_name”);!msg->setKind(MY_MESSAGE_TYPE);!
• Duplicating a message before sending to several gates or any other copy:!cMessage *msg1 = msg->dup();!!
!
Copyrig
ht Dr. An
na Förster 2013
29
Sending Messages • Send a message to an out/inout gate: • send(msg, “gateOut”);
• Send a self message: • scheduleAt(200.6f, msg);
• Cancel again a previously scheduled message: • cancelEvent(msg);
Copyrig
ht Dr. An
na Förster 2013
30
Receiving messages • All messages are received in handleMessage() • Asking for the incoming gate: • bool arrivedAtGateName = msg-‐>arrivedOn(“gate_name”, index)
• Asking for the kind (type): • if (msg-‐>getKind() == MY_MESSAGE_TYPE)
• Asking whether it was a self message: • if (msg-‐>isSelfMessage())
Copyrig
ht Dr. An
na Förster 2013
31
Asking for parameters • Parameter defined in NED: “int interval” • Asking for the value of it in the implementa4on: • int value = par(“interval”);
• More secure: • int value = hasPar(“interval”) ? par(“interval”) : 10;
Copyrig
ht Dr. An
na Förster 2013
32
Further useful things • endSimula3on() – ends the simula4on immediately, e.g. in case of a fatal error.
• recordScalar("Data",data) – records a data item into an external file, for future processing/representa4on
• bubble(”ERROR! HELP!”) – presents a graphical bubble in the simula4on with the given text
• display strings – each module has a display string, consis4ng of argument tuples, which can be changed also at run-‐4me – see the documenta4on of display strings
Copyrig
ht Dr. An
na Förster 2013
33
Further useful things • double simTime() – returns the current simula4on 4me. • ev – outputs debugging informa4on into the event screen. Example of usage:
ev << getName() << “:” << “I just received a packet with ID “ << id << endl;
Copyrig
ht Dr. An
na Förster 2013
34
Exercises • Exercise 1: create your own copy of the 4c-‐toc tutorial, called *your-‐name*TicToc. Change the names of the modules: • txc1 -‐> tac • Tictoc1 -‐> Tictac
• Exercise 2: create a new parameter called period, and include it into the module tac. Read the value of the parameter in tac.ini4alize and display it with ev.
Copyrig
ht Dr. An
na Förster 2013
35
Exercises • Exercise 3: Now change the way how tac works. Instead of crea4ng a message in the beginning of the simula4on and leQng it bounce between the nodes, create one message every period (the parameter from Ex.2) at 4c and delete it at toc.
Copyrig
ht Dr. An
na Förster 2013
36