omnet and mixim framework n.
Skip this Video
Loading SlideShow in 5 Seconds..
OMNeT ++ and MiXiM Framework PowerPoint Presentation
Download Presentation
OMNeT ++ and MiXiM Framework

Loading in 2 Seconds...

play fullscreen
1 / 63

OMNeT ++ and MiXiM Framework - PowerPoint PPT Presentation

  • Uploaded on

OMNeT ++ and MiXiM Framework. Introduction. What is OMNeT++?. OMNeT ++ is a component-based, modular and open-architecture discrete event network simulator. OMNeT ++ represents a framework approach

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'OMNeT ++ and MiXiM Framework' - issac

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what is omnet
What is OMNeT++?
  • OMNeT++ is a component-based, modular and open-architecture discrete event network simulator.
  • OMNeT++ represents a framework approach
    • Instead of containing explicit and hardwired support for computer networks or other areas, it provides an infrastructure for writing such simulations
    • Specific application areas are catered by various simulation models and frameworks, most of them open source.
    • These models are developed completely independently of OMNeT++, and follow their own release cycles.
omnet frameworks
OMNET++ Frameworks
  • Partial list of OMNeT++-based network simulators and simulation frameworks:
    • Mobility Framework -- for mobile and wireless simulations
    • INET Framework -- for wired and wireless TCP/IP based simulations
    • Castalia -- for wireless sensor networks
    • MiXiM-- for mobile and wireless simulations
  • More specialized, OMNeT++-based simulators:
    • OverSim -- for overlay and peer-to-peer networks (INET-based)
    • NesCT -- for TinyOS simulations
    • Consensus Positif and MAC Simulator -- for sensor networks
    • SimSANs -- for storage area networks
    • CDNSim -- for content distribution networks
    • ACID SimTools -- for simulation of concurrency control, atomic commit processing and recovery protocols
    • X-Simulator -- for testing synchronization protocols
    • FIELDBUS -- for simulation of control networks (fieldbuses)
    • PAWiS -- Power Aware Wireless Sensor Networks Simulation Framework
what is mixim
What is MiXiM?
  • MiXiM project
    • MiXiM (mixed simulator) is a simulation framework for wireless and mobile networks using the OMNeT++ simulation engine
  • MiXiM is a merger of several OMNeT++ frameworks written to support mobile and wireless simulations
  • The predecessors of MiXiM are:
    • ChSim by Universitaet Paderborn
    • Mac Simulator by TechnischeUniversiteit Delft
    • Mobility Framework by TechnischeUniversitaet Berlin, Telecommunication Networks Group
    • Positif Framework by TechnischeUniversiteit Delft
important issues in a discrete event simulation environment
Important issues in a discrete event simulation environment
  • Pseudorandom generators
  • Flexibility
  • Programming model
  • Model management
  • Support for hierarchical models
  • Debugging, tracing, and experiment specifications
  • Documentation
  • Large scale simulation
  • Parallel simulation
  • Core framework for discrete event simulation.
    • Different add-ons for specific purposes.
  • Fully implemented in C++.
  • Functionality added by deriving classes following specified rules.
omnet programming model
OMNET++ Programming model
  • Simulated objects are represented by modules
    • Modules can be simple or composed (depth of module nesting is not limited)
    • Modules communicate by messages (sent directly or via gates)
    • One module description consists of:
      • Interface description (.NED file)
      • Behavior description (C++ class)
  • Modules, gates and links can be created:
    • Statically - at the beginning of the simulation (NED file)
    • Dynamically – during the simulation
hierarchical models
Hierarchical models
  • Network interface card, a compound module consisting of a simple module MAC and a compound module Phy
model management
Model management
  • Clear separation among simulation kernel and developed models.
  • Easiness of packaging developed modules for reuse.
  • No need for patching the simulation kernel to install a model.

Build models and combine like LEGO blocks

debugging and tracking
Debugging and tracking
  • Support is offered for:
    • Recording data vectors and scalars in output files
    • Random numbers (also from several distributions) with different starting seeds
    • Tracing and debugging aids (displaying info about the module’s activity, snapshots, breakpoints)
  • Simulations are easy to configure using .ini file
  • Batch execution of the same simulation for different parameters is also included
  • Simulations may be run in two modes:
    • Command line: Minimum I/O, high performance.
    • Interactive GUI: Tcl/Tk windowing, allows view what’s happening and modify parameters at run-time.
simulation model building
Simulation Model building

Add behavior

for (int i=0;i<10;i++) {









Set up parameters

Model structure


build process
Build process

Network description

nedtool compiler

Simulation kernel libraries

User interface libraries

Generated C++ code

Module behavior C++ code

C++ compiler

C++ compiler


Simulation program

ned overview
NED Overview
  • The topology of a model is specified using the NED language.
  • Edit it with GNED or other text editor.
components of a ned description
Components of a NED description
  • Import directives
  • Channel definitions
  • Simple and compound module definitions
  • Network definitions
import directives
Import directives
  • import "ethernet"; // imports ethernet.ned
  • import




channel definitions
Channel definitions

channel LeasedLine

delay 0.0018 // sec

error 1e-8

datarate 128000 // bit/sec


simple module definitions
Simple module definitions

simple TrafficGen



numOfMessages : const, address : string;


in: fromPort, fromHigherLayer;

out: toPort, toHigherLayer;


Application Layer


MAC Layer

compound module definitions
Compound module definitions

module CompoundModule

parameters: //...

gates: //...

submodules: //...

connections: //...


compound module definitions submodules
Compound module definitions - submodules

module CompoundModule



submodule1: ModuleType1

parameters: //...

gatesizes: //...

submodule2: ModuleType2

parameters: //...

gatesizes: //...


assigning values to submodule parameters
Assigning values to submodule parameters

module CompoundModule


param1: numeric,

param2: numeric,

useParam1: bool;


submodule1: Node


p1 = 10,

p2 = param1+param2,

p3 = useParam1==true ? param1 : param2;




module CompoundModule

parameters: //...

gates: //...

submodules: //...


node1.output --> node2.input; node1.input <-- node2.output;



network definitions
Network definitions

network wirelessLAN: WirelessLAN parameters:

numUsers=10, httpTraffic=true, ftpTraffic=true, distanceFromHub=truncnormal(100,60);


simulation model
Simulation Model
  • // // Ethernet CSMA/CD MAC // simple EtherMAC { parameters: string address; // others omitted for brevity gates: input phyIn; // to physical layer or the network output phyOut; // to physical layer or the network input llcIn; // to EtherLLC or higher layer output llcOut; // to EtherLLC or higher layer}

Modules can be connected with each other via gatesand combined to form compound modules. Connections are created within a single level of module hierarchy: a submodule can be connected with another, or with the containing compound module. Every simulation model is an instance of a compound module type. This level (components and topology) is dealt with in NED files

simulation model1
Simulation Model
  • // // Host with an Ethernet interface // moduleEtherStation { parameters: ... gates: ... input in; // connect to switch/hub, etcoutput out;submodules: app: EtherTrafficGen; llc: EtherLLC; mac: EtherMAC; connections: app.out --> llc.hlIn; <-- llc.hlOut; llc.macIn <-- mac.llcOut; llc.macOout --> mac.llcIn; mac.phyIn <-- in; mac.phyOut --> out; }

Simple modules which, like EtherMAC, don't have further submodules and are backed up with C++ code that provides their active behavior, are declared with the simple keyword; compound modules are declared with the module keyword. To simulate an Ethernet LAN, you'd create a compound module EtherLAN and announce that it can run by itself with the network keyword:

networkEtherLAN { submodules: EtherStation;

… }

running a model
Running a model
  • #> opp_makemake --deep
    • creates a makefile with the appropriate settings
  • #> make
  • To run the executable, you need an omnetpp.ini file.
    • Without it you get the following error:
    • #> ./etherlanOMNeT++/OMNEST Discrete Event Simulation (C) 1992-2005 Andras Varga [....] <!> Error during startup: Cannot open ini file `omnetpp.ini'
running a model omnetpp ini
Running a model (omnetpp.ini)
  • [General] network = etherLAN*.numStations = 20 **.frameLength = normal(200,1400) **.station[0].numFramesToSend = 5000 **.station[1-5].numFramesToSend = 1000 **.station[*].numFramesToSend = 0

One function of the ini file is to tell which network to simulate. You can also specify in there which NED files to load dynamically, assign module parameters, specify how long the simulation should run, what seeds to use for random number generation, how much results to collect, set up several experiments with different parameter settings, etc.

why use separate ned and ini files
Why use separate NED and ini files?
  • NED files define the topology of network/modules
    • It is a part of the model description
  • Ini files define
    • Simulation parameters
    • Results to collect
    • Random seeds
  • This separation allows to change parameters without modifying the model
    • E.g. no need to recompile, experiments can be executed as a batch
output of a simulation
Output of a simulation
  • The simulation may write output vector and output scalar files
    • omnetpp.vec and
    • The capability to record simulation results has to be explicitly programmed into the simple modules
  • An output vector file contains several output vectors
    • series of pairs timestamp, value
    • They can store things like:
      • queue length over time, end-to-end delay of received packets, packet drops or channel throughput
    • You can configure output vectors from omnetpp.ini
      • you can enable or disable recording individual output vectors, or limit recording to a certain simulation time interval
    • Output vectors capture behaviour over time
  • Output scalar files contain summary statistics
    • number of packets sent, number of packet drops, average end-to-end delay of received packets, peak throughput
  • World utility module provides global parameters of the environment (size, 2D or 3D)
  • Objects are used to model the environment
    • ObjectHouse, ObjectWall
    • Objects influence radio signals and the mobility of other objects
    • ObjectManager decides which objects are interfering
  • ConnectionManager dynamically manages connections between objects
    • Signal quality based on interference
    • Signal quality based on mobility
node modules
Node Modules
  • Application, network, MAC, and physical layers
    • MAC and physical layers are grouped into a single Nic module
    • A node with multiple Nic modules can be defined
      • A laptop with bluetooth, GSM, and 802.11 radios can be modeled
node modules1
Node Modules
  • Mobility module is responsible for the movements of an object
  • Battery module used for modeling the energy reserve of nodes
    • Communication, processing, mobility related energy consumption can be modeled
  • Utility module is used for easy statistical data collection and inter-modular data passing (location, energy level etc.)
connection modeling
Connection Modeling
  • In wireless simulations the channel connecting two nodes is the air
    • A broadcast medium that can not be represented with a single connection
    • Theoretically a signal sent out by a node affects all other nodes in the simulation
      • Since the signal is attenuated by the channel, as the distance to the source is increased the interference becomes negligible
    • MiXiM sends all simultaneous signals to the connected nodes to let them decide on the final signal quality
    • Maximal interference distance decides on the connectivity
  • Definition of connection:
    • All nodes that are not connected, definitely do not interfere with each other
utility module
Utility module
  • Modules can publish observed parameters to the blackboard, a globally accessible service
    • Other modules can subscribe to these published parameters to implement different data analysis methods for gathering results
    • Dynamic parameters like location of a node or the energy levels can also be published so that other modules can change their behaviors accordingly
  • BaseNetwork.ned
    • contains the simulation network
  • BaseHost.ned
    • contains the compound module defining the hosts for the network
  • BaseNic.ned
    • contains the compound module defining the network interface card of the hosts
  • config.xml
    • contains configuration for the physical layers decider and analogue models
  • omnetpp.ini
    • contains configuration for the simulation
basenic ned

MiXiMs provides two MAC layer implementations CSMAMacLayer and Mac80211.

If you use only MiXiMs Decider and AnalogueModel implementations you can use the PhyLayer module.

basenode ned

BaseUtility is a mandatory module

BaseArp is used for address resolution

IBaseMobility is a mandatory module which defines current position and the movement pattern of the node.

IBaseApplLayer, IBaseNetwLayer and BaseNic define the network stack of this host.

IBaseApplLayer is the module for the application layer to use. You can implement you own by sub classing MiXiMs "BaseApplLayer".

INetwLayer is the module for the network layer to use. Sub-class your own network layer from MiXiMs BaseNetwLayer.

basenetwork ned

Path inside MiXiM directory

Module parameters

  • ConnectionManager
    • checks if any two hosts can hear each other
    • updates their connections accordingly.
    • If two hosts are connected, they can receivesomething from each other
  • BaseWorldUtility contains global utility methods and parameters
  • node[numNodes]: BaseNode
    • defines the hosts/nodes of our simulation.

The baseNetwork example defines a network and an application layer on top of a NIC

config xml

The AnalogueModels section defines the analogue models to use.. You can find all of the already implemented AnalogueModels under "modules/analogueModel/".

The Decider section defines the Decider to use as well as its parameters. You can find all of the already implemented Deciders under "modules/phy/".

You can set the XML file which defines the Decider and AnalogueModels of a physical layer by setting the "analogueModels" and "decider" parameter of it in omnetpp.ini

example ii
Example II
  • The MAC layer we want to implement will only implement the basic sending and receiving process
  • Since implementing a Mac layers requires a lot message handling and state changing, it needs a lot of rather boring glue code, so we will only explain the interesting parts of the code
tasks of the mac layer
Tasks of the MAC layer
  • Define start, duration, TX power mapping and bit-rate mapping of the Signal:
    • BaseMacLayer provides the convenience method “createSignal()” for simple signals
    • Takes start, duration, TX power and bit-rate as parameters
    • Returns a new Signal with a mapping representing the passed (constant) TX power and the passed (constant) bit-rate
    • To define non constant TX power and / or bit-rate over time one will have to set the Mappings of the Signal manually.
tasks of the mac layer1
Tasks of the MAC layer
  • Channel sensing:
    • “getChannelState()” - phy module method for instantaneous channel sensing.
    • Control message of kind “MacToPhyInterface::CHANNEL_SENSE_REQUEST” sent to phy module
    • Requests the phy to sense the channel over a period of time
    • Takes a timeout and a sense mode value
      • UNTIL_TIMEOUT: is used to sense for the specified amount of time.
      • UNTIL_IDLE: is used to sense until the channel is idle or until the timeout.
      • UNTIL_BUSY: is used to sense until the channel is busy or until the timeout.
    • both methods return a “ChannelState” object with an idle flag and the current RSSI value
tasks of the mac layer2
Tasks of the MAC layer
  • Switch radio:
    • “setRadioState()” - phy module method used to switch the radio.
    • Takes the state to switch to as argument
    • “Radio::TX”
    • “Radio::RX”
    • “Radio::SLEEP”
    • Returns the duration the switching will need.
    • Control message of kind “RADIO_SWITCHING_OVER” from the physical layer indicates that the switching is over.
write your own mac layer
Write your own MAC layer
  • classMyMacLayer:publicBaseMacLayer{ protected:cPacket*packetToSend;enumMacState{ RX, CS, TX }; intmacState; ChannelSenseRequest*chSense;}
  • "packetToSend" stores the packet from the upper layer we currently want to send down to the channel.
  • "macState" will store the current state our MAC layer is in
  • "chSense" hold a "UNTIL_IDLE"-channel sense request which we will use to wait for the channel to turn idle.
writing your own mac layer
Writing your own MAC layer
  • During initialization we set the initial state of our MAC layer to receiving and we initialize or "UNTIL_IDLE"-request.
  • The first parameter to the constructor is the name for our message and the second is the kind, which has to be "MacToPhyInterface::CHANNEL_SENSE_REQUEST" for every ChannelSenseRequest.
  • We further set the mode and the timeout (in seconds) of our request.
writing your own mac layer1
Writing your own MAC layer
  • This is only a part of the actual "handleUpperMsg()" method it is called on reception of a packet which should be sent down to the channel.
  • We store the packet for further processing and then we ask the phy module to do an instantaneous channel sense to see if the channel is currently idle.
    • "getChannelState()" returns a ChannelState instance which provides an "isIdle()" and "getRSSI()" method.
    • Both of the values are defined by the Decider of the phy module and especially the meaning of "isIdle()" depends on the used Decider but in most cases it should indicate that we can send something to the channel without interfering with another transmission.
  • If the channel is idle we can start the transmission process, if not we will need to start an "UNTIL_IDLE“ request to wait for it to turn back idle.
writing your own mac layer2
Writing your own MAC layer
  • We set the MAC layers state to carrier sensing and send our "UNTIL_IDLE“ request over the control channel down to the phy module.
  • The phy module will hand it to its Decider and when the Decider says that the channel is idle again or the timeout is reached it will set the "ChannelState“ member of the request and send it back up to our MAC layer.
writing your own mac layer3
Writing your own MAC layer
  • The ChannelSenseRequest we get back from the phy module will be the same which we sent down but with the result of the sensing stored in its "ChannelState" member. If the result says that the channel is back idle we can start the transmission process, which is done in "transmitpacket()":
writing your own mac layer4
Writing your own MAC layer
  • We see that we do not yet start transmitting the packet because we have to switch the radio to TX mode first. We do this by calling the phy modules "setRadioState()" method
  • The method will return the time the switching process is over. The time it takes to switch from one radio state to another can be set as parameters of the phy module.
  • As soon as the switching process is over the phy module will send us a message of kind "RADIO_SWITCHING_OVER" over the control channel. As soon as the radio is in TX mode we can start sending the packet to the channel which we do in "handleRadioSwitchedToTX()“
  • Here the packet we got from the upper layer is encapsulated into a MacPkt and then sent down to the physical layer which will send it to the channel. During encapsulation the Signal for the packet is created and attached to it
writing your own mac layer5
Writing your own MAC layer
  • The actual encapsulation is handled by BaseMacLayers "encapsMsg()" method. Our MAC layer is only responsible for creating and attaching the Signal. Since we will use a constant bit-rate and sending power for the whole transmission we can use the "createSignal()" method provided by BaseMacLayer. It takes the start and the length of the signal to create as well as its sending power and bit-rate. The method then creates a constant mapping for the power and bit-rate, stores them in a new Signal and returns it to us. If you want to use a more complex power or bitrate mapping you'll have to create the signal and the Mappings by yourself. You can take a look at the implementation of the "createSignal()" method to see how this basically works.
  • The Signal then is added to the MacPkts control info.
  • Note: Since the MAC layer has to create the Signal it has to know the whole length of the packet, including the phy header (if there is one). The phy module itself does not change the length of the packet sent to it.
writing your own mac layer6
Writing your own MAC layer
  • After the transmission of the packet is over the phy module will send us a message of kind "TX_OVER" over the control channel. When this happens our MAC layer has to switch the radio back to RX state
    • phy->setRadioState(Radio::RX);
  • Again the phy module will send us a "RADIO_SWITCHING_OVER" message as soon the switching process is over which we handle in "handleRadioSwitchedToRX()":
  • Now the whole transmission process is over and our MAC layer goes back to receiving state
links and readings
Links and readings
  • “The OMNeT++ discrete event simulation system”, Varga A. Proceedings of the European Simulation Multiconference (ESM 2001), Prague, Czech Republic, 6–9 June 2001
  • “Comparison of OMNET++ and other simulator for WSN simulation”, Xiaodong Xian; Weiren Shi; He Huang Industrial Electronics and Applications, 2008. ICIEA 2008. 3rd IEEE Conference on
  • “Simulating wireless and mobile networks in OMNeT++ the MiXiM vision”, Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems Marseille, France, 2008