Intro omnetpp-if13-published
1 like1,372 views
The document discusses network modeling and simulation using OMNeT++. It explains the concepts of network simulation and emulation, advantages and disadvantages, the basics of simulating nodes and connections, and provides exercises for creating models in a smart home scenario. Additionally, it details the implementation of a simple model in OMNeT++ and includes coding examples for message handling.
Intro omnetpp-if13-published
- 1. Network Modeling and Simulation with OMNeT++ Dr. Anna Förster anna.foerster@ieee.org Informa4ca Feminale, Bremen August 2013
- 2. Copyright Dr. Anna Förster 2013 What is simulation? 3 Image sources: Wikipedia
- 3. Network Simulation • 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. Copyright Dr. Anna Förster 2013 • What is network simula4on? 4
- 4. 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 • • • • Copyright Dr. Anna Förster 2013 Simulation -‐ Advantages 5
- 5. • 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! Copyright Dr. Anna Förster 2013 Simulation -‐ Disadvantages 6
- 6. Simulation Basics • • • • • Time Network par4cipants or nodes Con4nuous processes at the nodes Connec4ons between nodes and their proper4es Informa4on exchange between nodes Copyright Dr. Anna Förster 2013 • The following basics need to be simulated: 7
- 7. Simulating Time • Real-‐4me simula4on • Discrete Event based simula4on • Events of a system are ordered in a simulated 4me and processed in order. (Markov chain) Copyright Dr. Anna Förster 2013 • Real 4me is used to simulate events and the development of a system. Oaen combined with emula4on, real world hardware, etc. 8
- 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 • 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! Copyright Dr. Anna Förster 2013 4me 9
- 9. 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! • • • • Copyright Dr. Anna Förster 2013 Time properties in event based simulation 10
- 10. 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 Copyright Dr. Anna Förster 2013 Simulating network nodes 11
- 11. • 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. Copyright Dr. Anna Förster 2013 Simulating continuous processes at the node 12
- 12. • 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 Node 1 Node 2 Copyright Dr. Anna Förster 2013 Connections between nodes 13
- 13. Connections between nodes • 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 Copyright Dr. Anna Förster 2013 • Proper4es of links: 14 Node 1 Node 2
- 14. Information exchange between nodes • Various types of informa4on or things can be exchanged: Copyright Dr. Anna Förster 2013 • Organic viruses or generally sicknesses • Digital media like SMS, mail, videos, etc. 15
- 15. 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. Copyright Dr. Anna Förster 2013 How to model a network 16
- 16. How to model realistically • Stay real! • Do not model behavior, which is impossible in the real world: • 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. Copyright Dr. Anna Förster 2013 • Receiving data faster than sending • Smart-‐phones able to see and process organic viruses • … 17
- 17. Design Exercise (1) • Design a model for the following scenario: • 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. Copyright Dr. Anna Förster 2013 • 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: 18
- 18. Design Exercise (2) • 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) Copyright Dr. Anna Förster 2013 • Design the model, given that: 19
- 19. Design Exercise (3) – Solution • End user device with level of trust (rights) • Central smart home device • Home device with internal status (simply a list of possible text values) Copyright Dr. Anna Förster 2013 • Three types of nodes with proper4es: 20
- 20. Working with OMNeT++ Source: omnetpp.org 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. } 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. } 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. Copyright Dr. Anna Förster 2013 } 21
- 21. Copyright Dr. Anna Förster 2013 OMNeT++ IDE 22
- 22. 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; ! } ! Copyright Dr. Anna Förster 2013 Tic-‐Toc Step-‐by-‐Step Tutorial 23
- 23. Defini3on of a simple module, with simple Txc1 { ! only 2 gates, named IN and OUT !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; ! } ! Copyright Dr. Anna Förster 2013 Tic-‐Toc Step-‐by-‐Step Tutorial 24
- 24. simple Txc1 { ! !gates: ! ! !input in; ! Defini3on of a network, consis3ng of two sub-‐modules, both of type Txc1 ! !output out; ! and with connec3ons between their } ! gates network Tictoc1 { ! !submodules: ! ! !tic: Txc1; ! ! !toc: Txc1; ! !connections: ! ! !tic.out --> { delay = 100ms; } --> toc.in;! ! !tic.in <-- { delay = 100ms; } <-toc.out; ! } ! Copyright Dr. Anna Förster 2013 Tic-‐Toc Step-‐by-‐Step Tutorial 25
- 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); ! }; ! Copyright Dr. Anna Förster 2013 Implementa3on of the Txc1 module – header file 26
- 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"); } ! Copyright Dr. Anna Förster 2013 Implementa3on of the Txc1 module – source file 27
- 27. NED Network source (C++) Module Module Module Module omnetpp.ini Module Copyright Dr. Anna Förster 2013 Simple Module 28 executable
- 28. Creating Messages • Duplicating a message before sending to several gates or any other copy:! cMessage *msg1 = msg->dup();! ! Copyright Dr. Anna Förster 2013 • Creating a new message:! ! cMessage *msg = new cMessage(“message_name”);! msg->setKind(MY_MESSAGE_TYPE);! ! 29
- 29. Sending Messages • Send a message to an out/inout gate: • send(msg, “gateOut”); • scheduleAt(200.6f, msg); • Cancel again a previously scheduled message: • cancelEvent(msg); Copyright Dr. Anna Förster 2013 • Send a self message: 30
- 30. Receiving messages • All messages are received in handleMessage() • Asking for the incoming gate: • Asking for the kind (type): • if (msg-‐>getKind() == MY_MESSAGE_TYPE) • Asking whether it was a self message: • if (msg-‐>isSelfMessage()) Copyright Dr. Anna Förster 2013 • bool arrivedAtGateName = msg-‐>arrivedOn(“gate_name”, index) 31
- 31. Asking for parameters • Parameter defined in NED: “int interval” • Asking for the value of it in the implementa4on: • More secure: • int value = hasPar(“interval”) ? par(“interval”) : 10; Copyright Dr. Anna Förster 2013 • int value = par(“interval”); 32
- 32. • 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 Copyright Dr. Anna Förster 2013 Further useful things 33
- 33. • 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; Copyright Dr. Anna Förster 2013 Further useful things 34
- 34. Exercises • Exercise 1: create your own copy of the 4c-‐toc tutorial, called *your-‐name*TicToc. Change the names of the modules: • 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. Copyright Dr. Anna Förster 2013 • txc1 -‐> tac • Tictoc1 -‐> Tictac 35
- 35. • 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. Copyright Dr. Anna Förster 2013 Exercises 36