WSN Simulation Template for OMNeT++ Stefan Dulman s.o.dulman@utwente.nl

Presentation Overview OMNeT++ Introduction Sensor Network Template Implementation Example Discussion and future work

OMNeT++ Introduction

OMNeT++ Features Simulator designed for fixed, wired, distributed systems (such as: computer networks, multiprocessor systems…) Discrete time simulator It is compatible with: DOS, UNIX, WINDOWS (uses C++ and Tcl/Tk) Several graphical interfaces allows easy debugging and variables inspection Offers support for parallel execution

OMNeT++ Features (2) 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

OMNeT++ Features (3) 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

OMNeT++ Features (4) What is missing or not working as wanted: Mobile entities and wireless communication between them are not included Static data types not allowed For storing data needed by all the modules a central manager has to be created Communication with this entity goes by messages (slow!) Using pointers to it is not always good idea (parallel execution) Execution goes very slow with the increase of the number of messages and when using parameters Very slow 2D graphical interface made in Tk

Sensor Network Template

Template Description What is it: A fully working project consisting of a network of mobile nodes that can communicate by wireless means. The user has only to implement the wanted algorithm, with no concern on how these issues are handled. All the parameters of the network can be changed without any need of rewriting any code Offers (a lot of) easy to use macros for accessing the main functionalities

Template Description (2) Characteristics: Implements mobility (Random Way Point alg.) Wireless communication Simulated by dynamically connecting modules within transmission range Unidirectional links Signal strength can be varied from within the nodes Energy management is also included Nodes have failing probabilities Map for area failures can be specified and used Other maps can easily used for obstacles, fading, etc. (implementation is similar)

Network Architecture Central Manager Sensor nodes Used as a central database Its main function: stores the connectivity map and updates it upon request It takes care of reading additional configuration files and sending the information It is hidden from the display, communication with it is done only with sendDirect() function Sensor nodes

Sensor Node Architecture Layer 0 Sensor Energy manager Blackboard Application Custom network layers

Mobility Issues Approaches to describe mobility Each node reports its position after a certain interval. Simulation precision depends on this interval. The smallest the interval the longest the simulation time Each node reports the equation of the curve of its movement Manager computes the interaction moments and schedules gates connect/disconnect at those moments Faster execution (almost 4 times in our simulations) More precise simulation Graphical display no longer linked to the simulator precision Random Way Point model as default

Energy Management Implemented using the blackboard Consumed energy and of the current energy Data can be accessed from anywhere within a sensor node Estimation of the lifetime of the node (can be improved by using any desired estimation function) Warnings can be issued when no energy is left (special behaviours can be implemented in the energy manager; e.g. stop certain components when energy goes beyond a treshhold)

Reliability Issues Two kinds of failures implemented Node failure probability Can be specified for each node separately Available to all the layers inside a node Can be set to change over the time Area failure probability The failure zones are specified as rectangles inside a configuration file Data is available to all the layers It can be given any interpretation needed. Easy to extend to a set of maps

Other features RWP algorithm is fully configurable by constants for speed and sleep time Discrete simulator problem: update messages from the manager/layer0 for the topology update arrive in the same time with messages from the application. Solution: usage of a constant defining the maximum time resolution used by the application Infrastructure update messages are scheduled before information messages Layer0 can check if the user has used time values that need a higher precision than allowed

Other Features (2) Support for beacons is added (needed by the localization algorithms) A certain number of nodes have fixed positions Any node can find out if it is a beacon or not Each node can be displayed in several ways (useful for debugging and presentations: to highlight the discovered paths, the clusters, etc.) 3 distinct graphical signs and 10 colors for each one Can be modified from anywhere inside the node Modifications are displayed immediately Simulation precision is no longer related to display update User can specify the display rate

Work in progress Signal sources: Support for fixed and mobile beacons Support for areas of interest Fixing minor bugs and optimizing the code Rather use new derived classes than parameters Finding the best places to place the functionality (manager or layer0) Trying to create a library of modules WANTED: 3D graphical display !!!

Work in Progress (2) Tcl/Tk script for: Easy configuration of the network Designing the maps, node initial positions, initial values, etc. Generation of project files

Implementation example

Example (1) Application example: Step 1 One node periodically broadcasts distinct messages (each 5 sec) Each other node re-broadcasts a received messages if this one is newer than the last heard one (after 1 second) In case of message collision, the incoming messages are discarded Step 1 Adding the interface description for the custom layers

Example (2) Step 2 Step 3 Step 4 Step 5 Creating the new module C++ class (using Tcl script) Step 3 Writing the code for the message collision Step 4 Writing the application code Step 5 Verification by simulation

Address where to download the template: Email address: Discussions Address where to download the template: http://wwwhome.cs.utwente.nl/~dulman/tools.htm Email address: s.o.dulman@utwente.nl