Main /

Discussion of the various mobile/ad-hoc frameworks for OMNeT++

By today there's a puzzling abundance of various mobile, ad-hoc and sensor simulation frameworks based on OMNeT++. How do they differ? How to choose from them? Is some sort of convergence meaningful, desirable, or is it to be expected?

See also WsnAlgorithms for a recapitulative table of all open source WSN algorithm implementations in the various frameworks.

On this page we'd like to collect experience to help researchers decide which simulation framework to use for a particular project, and for framework developers to determine in which directions to steer the development.

If you'd like to contribute installation instructions, bugs, tips and tricks, etc, please consider doing so in the KnowledgeBase. (You can also add pages there, for models that do not have one yet.)

MiXiM

MiXiM is an OMNeT++ modeling framework created for mobile and fixed wireless networks (wireless sensor networks, body area networks, ad-hoc networks, vehicular networks, etc.). It offers detailed models of radio wave propagation, interference estimation, radio transceiver power consumption and wireless MAC protocols (e.g. Zigbee).

MiXiM is currently the recommended framework for detailed wireless simulations. The MiXiM web site contains manual, tutorials, etc.

Mobility Framework

Used to be the reference platform for doing mobile/ad-hoc simulations with OMNeT++. (INET's mobile/ad-hoc support is based on code ported from MF-1.0a5, and is largely compatible with it.) MF is not actively developed any more, the developers have moved on to create MiXiM.

MF embraces the framework approach, and emphasizes decoupled, pluggable components even in the physical layer (whereas other models often mix the MAC and physical layer aspects into a single module). Remarkably, communication (i.e. signals) between protocol layers inside a node is organized via the Blackboard (in INET, NotificationBoard), which decouples producers and consumers of such signals.

MF includes a 802.11 model (ad-hoc mode only), but currently, alas, no routing protocol (just flooding.)

Idea: Tutorial similar to OMNeT++ would be appreciated.

INET Framework

INET's mobile/ad-hoc support is based on code ported from the MF-1.0a5 release. Mobility, physical and MAC layer have been ported to INET, and significantly improved.

  • INET currently contains 9 mobility models, which include the scriptable TurtleMobility, and ANSimMobility and BonnMotionMobility which utilize scenarios generated by the tools ANSim and BonnMotion -- work is underway to integrate (some of) these into MF as well.
  • INET's ChannelControl uses sendDirect() instead of dynamically created connections. It is also underway to port this to MF as an optional feature. (Is this right Andreas? --Andras)

MF vs INET: MF authors and Andras have agreed that it makes sense to maintain mobile/ad-hoc support in both INET and MF. MF can be used to simulate all sorts of experimental and research-type networks, while INET will focus on simulating more concrete and more established technologies. It's foreseen that we'll do further code synchronizations whenever MF or INET gets significantly improved.

Q: If I want to contribute some mobility models (such as Random Direction and my proposal), which mobility framework should I modify? INET or MF?

AODV Framework

Contains a (simplified? accurate?) AODV protocol implementation. (Uses cPars; it would be nice to update the code to make use of subclassing (.msg files)). There are several mobility models (random walk, restricted random walk, random direction, random waypoint, pursuit model, normal Markovian mobility model), not compatible with MF/INET mobility models.

Q: Any advice on how to decide between the AODV Framework and other frameworks for a project? --Andras

Q: Experiences?

NesCT

NesCT allows running TinyOS programs in OMNeT++ by translating the code into C++ with OMNeT++ calls.

NesCT focuses on parsing nesc source code and creating OMNeT++ compatible components. Therefore, it may be accepted as a plugin for existing frameworks. There is work going on to integrate NesCT generated components to MF and MACSimulator.

TinyOS components are linked to each other at compile time and actual code that is executed in the simulator is a monolithic C code. On the other hand, NesCT translates each component of TinyOS to an OMNeT++ module. All calls between components are modeled using Remote Procedure Calls (RPC).

Different sensor network applications may be run within the same simulation environment. An example application may be to run TOSBase + sensor application or CntToRfm + RfmToLeds application.

NesCT modules are generated dynamically and there is heavy use of activity and cPar.

Existing NesCT translation is done until the MAC layer. Therefore, it assumes that it is going to borrow this functionality from one of the existing frameworks. There is no power consumption model and mobility support as well.

Good news: As of 17-11-05, integration of NesCT to MF has been completed. You can download MF integrated examples from NesCT home page. --Omer Sinan Kaya

Q: Experiences of NesCT vs TosSim? See NesCT

MACSimulator

Simulation model of various different energy-efficient MAC protocols for Wireless Sensor Networks. Currently includes models for T-MAC, S-MAC, L-MAC and a simple CSMA-based MAC. It includes a series of simple application protocols as well, but can be extended for more detailed models. At the moment, it does not support mobility or routing protocols, but extensions in these areas are intended for future work.

Q: Any advice on how to decide between MACSimulator and other frameworks for a project? --Andras

A: Don't use MacSimulator, it's obsoleted by MiXiM Otto

SENSIM

Concentrates on sensor networks. For example, it contains a battery model which MF or INET does currently not. Contains 802.11 and directed diffusion model.

There is a 14-page manual and some Doxygen documentation on-line. It would be nice to generate neddoc as well (like for INET), and turn on source browser in Doxygen.

Q: Any advice on how to decide between SENSIM and other frameworks for a project? --Andras

EWsnSim

Mobility is implemented (Random Way Point algorithm by default). Each node is responsible for defining its own trajectory and announcing it to the simulator.

Nodes exchange messages using wireless communication. A message will be heard by all the neighbours situated within the transmission range (the modules within transmission range are connected automatically to each-other).

The user can specify if unidirectional or bidirectional links have to be used. Each node can specify and update its transmission range independently.

Some basic energy management is also included.

The nodes have different kinds of failing probabilities (individual failures, failures that affect regions of the map, etc.) Maps for area failures can be specified and used. Other maps can easily used for obstacles, fading, etc. In order to perform all of this features we have chosen to use.

Q: Any advice on how to decide between EWsnSim and other frameworks for a project? --Andras

Edit - History - Print - Recent Changes - Search
Page last modified on August 14, 2010, at 03:13 PM