52194424-omnet-

download 52194424-omnet-

of 63

  • date post

    31-Aug-2014
  • Category

    Documents

  • view

    331
  • download

    1

Embed Size (px)

Transcript of 52194424-omnet-

1

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

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

More specialized, OMNeT++-based simulators:

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 Technische Universiteit Delft Mobility Framework by Technische Universitaet Berlin, Telecommunication Networks Group Positif Framework by Technische Universiteit Delft

5

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

Flexibility6

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

Simulated objects are represented by modulesModules 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

Network interface card, a compound module consisting of a simple module MAC and a compound module Phy

Model management9

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

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 modules 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 whats happening and modify parameters at run-time.

Simulation Model building11

Add behaviorfor (int i=0;i node2.input; node1.input llc.hlIn; app.in 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)

[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?

NED files define the topology of network/modules

It is a part of the model description

Ini files defineSimulation 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

The simulation may write output vector and output scalar files

omnetpp.vec and omnetpp.sca The capability to record simulation results has to be explicitly programmed into the simple modules series of pairs timestamp, value They can store things like:

An output vector file contains several output vectors

queue length over time, end-to-end delay of received packets, packet drops or channel throughput you can enable or disable recording individual output vectors, or limit recording to a certain simulation time interval

You can configure output vectors from omnetpp.ini

Output vectors capture behaviour over time number of packets sent, number of packet drops, average end-to-end delay of received packets, peak throughput

Output scalar files contain summary statistics

MiXiM

MiXiM

World utility module provides global parameters of the environment (size, 2D or 3D) Objects are used to model the environmentObjectHouse, ObjectWall Objects influence radio signals and the mobility of other objects ObjectManager decides which objects are interfering

ConnectionManager dynamically manages connections between objectsSignal quality based on interference Signal quality based on mobility

Node Modules

Application, network, MAC, and physical layersMAC 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 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

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 All nodes that are not connected, definitely do not interfere with each other

Definition of connection:

Utility module

Modules can publish observed parameters to the blackboard, a globally accessible serviceOther 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

Example

BaseNetwork.ned

contains the simulation network contains the compound module defining the hosts for the network contains the compound module defining the network interface card of the hosts contains configuration for the physical layers decider and analogue models contains configuration for the simulation

BaseHost.ned

BaseNic.ned

config.xml

omnetpp.ini

BaseNic.nedMiXiMs provides two MAC layer implementations CSMAMacLayer and Mac80211. If you use only MiXiMs Decider and AnalogueModel implementations you can use the PhyLayer module.

BaseNode.nedBaseUtility 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.nedPath 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 receive something from each other BaseWorldUtility contains global utility methods and parameters node[numNodes]: BaseNode defines the hosts/no