A Remote Interface for Live Interaction with OMNeT++ Simulations

A Remote Interface for Live Interaction with OMNeT++ Simulations

Maximilian Köstler1 and Florian Kauer2 Institute of Telematics, Hamburg University of Technology
Am Schwarzenberg-Campus 3, 21073 Hamburg, Germany
1maximilian.koestler@tuhh.de, 2florian.kauer@tuhh.de

Discrete event simulators, such as OMNeT++, provide fast and convenient methods for the assessment of algorithms and protocols, especially in the context of wired and wireless networks. Usually, simulation parameters such as topology and traffic patterns are predefined to observe the behaviour reproducibly. However, for learning about the dynamic behaviour of a system, a live interaction that allows changing parameters on the fly is very helpful. This is especially interesting for providing interactive demonstrations at conferences and fairs.

In this paper, we present a remote interface to OMNeT++ simulations that can be used to control the simulations while visualising real-time data merged from multiple OMNeT++ instances. We explain the software architecture behind our framework and how it can be used to build demonstrations on the foundation of OMNeT++.

I Introduction

OMNeT++ [1] offers a variety of powerful visualisation tools that can also be used to display information at simulation time. However, many features that would be useful for live demonstrations with OMNeT++ are not available. This includes a convenient and clean interface to manipulate simulation parameters on the fly as well the possibility to merge multiple data sets from different simulations. The Institute of Telematics has developed a framework to close this gap and uses it to demonstrate the performance of data link layer protocols.

This paper presents this framework as well as the requirements and architecture behind it. The current implementation allows remote interaction with OMNeT++ simulations and the presentation of data suitable for demonstrations. It allows for interactive sessions where visitors with little knowledge of the system can modify the simulation and experience the results without an artificial delay. Furthermore, it allows creating simplistic applications with a clean interface designed especially for demonstrations. In contrast to pure OMNeT++ applications, distractions, such as unwanted menus, are removed.

Ii State of the Art

This section describes the available features in OMNeT++ for demonstrations and live interaction scenarios. This information is used to derive the need for an additional framework to close the gap between OMNeT++ and our requirements.

Ii-a Data Presentation

Tools for visualising running simulations and their results have been improved over the past OMNeT++ releases. Since version 5.0, 3D visualisation is supported which can be used to display useful information for different scenarios. A feature with a longer history is the graphical view for collected statistics at run-time. While these tools are useful for purposes of debugging and development, it is difficult to use them to present data to other researchers in a demonstration setting. The different graphical views of one simulation do not form a concise user interface that focuses on the important parts while not causing a distraction. Also, it is hardly possible to merge data from different simulations into a single view. While OMNeT++ does support parallel simulation distributed across multiple devices, a feature that is missing is the possibility to simulate on powerful computers while presenting data live on lightweight clients such as tablet computers. A different aspect of performance is related to the data collection at run-time. For live evaluations, OMNeT++ requires results to be stored in vectors, but during long-running demonstrations, these data structures may become too large to handle efficiently.

Ii-B Live Interaction

In most scenarios for OMNeT++ simulations, parameters are provided before simulation start and do not change during execution. In the Tkenv or Qtenv user interface it is, however, possible to drill down to any module and change its parameters at run-time. Using this method requires the affected modules to be designed with this in mind. While OMNeT++ notifies modules when one of their parameters is changed, the module itself has to perform the necessary adoptions under any circumstance. Additionally, OMNeT++ does not offer the possibility to conveniently design a custom GUI to modify the simulation parameters. This is unsuitable for an interactive demo where an uninformed visitor should be able to modify the simulation in predefined degrees of freedom.

Iii Requirements for the Framework

For us, the need for a good demonstration platform arose when we wanted to demonstrate the performance of a data link layer protocol [2]. Since our first approaches where hindered by the weaknesses of OMNeT++ as described in the previous section, we decided to collect the requirements for a good simulation control platform for OMNeT++ based projects. A part of these functional and non-functional requirements for the framework can be derived from a set of use cases which are shown in Fig. 1.

Fig. 1: Main use cases for the demonstration framework

One main goal was the decoupling of visualisation and control from the simulation itself into different applications. Furthermore, it should be possible to separate the execution context of both of these applications so that it is possible to run the simulation on a dedicated machine and visualise it elsewhere. Communication between the OMNeT++ simulation and the front end should be performed using a portable protocol that allows authors to extend the system. This could be used to add new modules that provide or process data and commands such as dedicated hardware platforms or mobile applications. The framework should promote ease of use for both author and visitor of an interactive demonstration. To achieve this, it should be possible to create a simplistic user interface for the visitor while offering a high degree of customisation for the author. All parts of the combined application should be lightweight and efficient to permit long-running and feature-rich demonstrations.

Iv Architecture

The software used for a particular demonstration setup can be partitioned into a front end and a back end with a middleware in between. The front end itself can be composed of one or multiple separate interfaces. In a simple scenario, each interface is a web application displayed in a browser, and each web application itself consists of multiple widgets. Finally, each widgets encapsulates a single feature such as displaying a value, a chart, or a button to send a message.

The back end of the demonstration is formed by OMNeT++ simulations. Here, in contrast to normal simulations, some modules were modified to allow the exchange of messages with the clients. An example of such a module is a special result recorder that collects and publishes a set of statistics. The complete demonstration architecture is depicted in Fig. 2.

Fig. 2: The architecture with clients connected to a set of simulations. Lines represent connections via the middleware either for RPCs or publish-subscribe.

Iv-a Middleware

The OMNeT++ simulation and the remote front end exchange commands and data via the Web Application Messaging Protocol (WAMP) [3]. WAMP provides Remote Procedure Calls (RPCs) and publish-subscribe event notifications via WebSockets. While WAMP can be used with either JavaScript Object Notation (JSON) or MessagePack for object serialisation and deserialisation, we have decided to use JSON for the presented framework. Through its nature as a string-oriented message format, JSON is not as efficient as the binary MessagePack regarding the size of the serialised data. However, JSON has the advantage of direct support in JavaScript and a human-readable format, which is very useful for the front end development.

Our framework uses RPCs to send control signals from the web front end to the connected OMNeT++ simulations and a publish-subscribe mechanism to direct results back to the GUI. An example of such a control signal would be a reset command that orders one or multiple simulations to restart from the beginning. Results reported via publish-subscribe could be the number of messages lost during the last second or the power consumption per device over a certain period.

Iv-B Back End

The back end part of the framework is developed entirely in C++ and integrates into the simulation as OMNeT++ modules. To achieve portability, a custom and lightweight implementation of the WAMP protocol is linked into the simulation binary. At the time of development, existing WAMP implementations required a large number of dependencies to be compiled which should be avoided in this case. In the current architecture, every module can be modified to offer RPCs or publishing services by itself. While it is possible to develop generic remote interfaces to OMNeT++ parameters and statistics, this is not required by the architecture so modules can provide RPCs for custom functionality. This flexibility allows the application of this framework to projects of varying complexity and size. To avoid disk space management issues on the simulation side, the back end is only responsible for storing or aggregating a set of statistics until it is published and pushed towards the client. That also means that as long as no front end is connected, no data has to be stored. If the demonstration should show data that covers a time frame of more than a few seconds, the front end is responsible for keeping the required data during the period of use. The simulations in the back end should be able to run for long periods of time without requiring resets or explicit clean-up operations. A relaunch of a front end application is uncritical for the simulation itself because apart from displaying a history, the front end does not have to keep track of a certain state. For simulations, this is different, since some demonstrations might require large amounts of computation time to reach the desired state. Also, long term observation can be an explicit goal of the demonstration.

Iv-C Front End

The client-side software in mind during the development of this framework is a web application built on the widespread technologies of the Hypertext Markup Language (HTML), JavaScript (JS) and Cascading Style Sheets (CSS). Through the open-source WAMP implementation Autobahn|JS [4], interaction with the middleware is possible in few lines of code. The combination HTML, JavaScript and CSS is widely used and therefore the barrier to use and extend our framework is kept low. Also, this choice of technology offers the possibility to separate GUI design and application code, and it is supported by a variety of debugging tools. To create a clean interface to one or more OMNeT++ simulations in the back end, the client view is composed of multiple widgets, each with a well-defined responsibility. After the widgets have been developed, the client view is simply composed by instantiating them. If unlocked, widgets can be shown or hidden at run-time and rearranged manually or through switching presets.

The widgets themselves can use Autobahn|JS to communicate with the back end while using JavaScript libraries such as jQuery [5] or Chart.js [6] to display statistics or to interact with the user. Every widget can subscribe to a different publisher if required and the same holds true for the remote procedure calls. A single control element can also call multiple RPCs from different simulations upon a single user interaction. This allows controlling multiple simulations synchronously while combining and comparing their results in a single view. Again, it is possible to develop a generic command multiplexer that relays RPCs towards the corresponding back end, or every widget can take care for that itself. This architecture makes the front end flexible and extensible, and it can thereby be easily adapted for very different scenarios.

V Implemented Features

With the presented framework, we developed a demonstration of the open source project openDSME [2] [7]. This demo was first presented at the NetSys 2017 [8]. The implementation allows demo visitors to compare the packet delivery ratio and power consumption between two OMNeT++ simulations. One simulation uses basic IEEE 802.15.4 [9] as the data link layer protocol, and the other uses IEEE 802.14.5 DSME. The interface can be used to change the amount of generated traffic as well as the topology by modifying the position of the nodes on the fly. In addition to the current and past values for the packet delivery ratio and the power consumption, the reason for lost transmissions and their location are visualised. A section of the demo interface is shown in Fig. 3.

Fig. 3: Screenshot of the live user interface with an oversaturated network. The view in the top left shows the topology; nodes can be dragged to a different position. The bottom left slider allows control over the generated traffic. The right side shows delivered and dropped packets (top) and where exactly packets have been dropped (bottom).
Fig. 4: Screenshot of a widget comparing the power consumption of two different data link layer protocols over time.
  <div id="power_chart_container"
       class="draggable ui-widget-content">
    <div class="handle">
      <h2>Total Power Consumption [mW]</h2>
  var dsme_wsuri = "ws://localhost:9002";
  var csma_wsuri = "ws://localhost:9003";
  var power_statistics
        = new PowerStatisticsModule(
            [dsme_wsuri, csma_wsuri],
            ["DSME", "CSMA"]
Fig. 5: HTML and JavaScript code required to instantiate the widget shown in Fig. 4.

To illustrate the relation between configuration effort and results, Fig. 4 and the code in Fig. 5 focus on a single widget. This widget communicates with a set of OMNeT++ simulations which each publish the total power consumed during the last simulated second. Once the widget itself has been implemented, using it in a demonstration is simple and requires little configuration. In this case, the widget only expects the ID of an HTML container for placement in the GUI, as well as the addresses and ports of the simulation hosts and the chart labels. The result is shown in Fig. 4.

V-a Available Widgets

Multiple widgets are implemented for our demonstration. The screenshot in Fig. 3 shows a condensed selection of these widgets. Currently, the following collection of widgets is available.

  • History of dropped and delivered packets (different colours for queue drop, ACK loss, etc.)

  • Location of dropped packets in the last seconds (different colours for queue drop, ACK loss, etc.)

  • Comparison of power consumption between multiple simulations over time

  • View on current topology with node drag and drop

  • Topology control widget to switch between different predefined topologies

  • Meta widget to enable or disable positioning of widgets as well as exporting and loading views

  • Reset button to reset multiple simulations at once

  • Traffic slider to control the traffic load for multiple simulations at once by adjusting the average traffic generation interval

One highlighted feature of our framework is the possibility to manipulate multiple simulations simultaneously via a single control element. This requires that all simulations offer a remote procedure with the same name and the same parameters. In our previous demonstration, the only difference between all connected simulations was the data link layer. Since all OMNeT++ instances used the same traffic generator, the only change required for remote control was to add a remote procedure to this module. The client-side JavaScript widget contains a simple slider that represents the mean delay between two packets. This widgets connects to each simulation separately and calls each RPC once the slider changes. On the simulation side, each traffic generator on every node registers a remote procedure to change module parameter that is evaluated every time the next packet generation is scheduled.

Vi Contribution and Future Work

This paper presents the implementation of a framework for remote control and visualisation of live OMNeT++ simulations. The existing possibilities and the requirements for such a system are analysed, and the architecture of our system is presented. We demonstrate the applicability with a demonstration of the openDSME data link layer implementation. The front end code111https://github.com/openDSME/opplive and the implemented OMNeT++ live modules222https://github.com/openDSME/inet-dsme/tree/opplive/src/opplive are available at GitHub. We explicitly encourage the reader to take our framework and use it for their demonstrations. Currently, and due to the limited application so far, each OMNeT++ module promotes available statistics and remote procedures by itself. A future modification could be the introduction of more generic modules that offer an interface to parameters without requiring source code additions for each one. Certainly, a more elegant integration into OMNeT++ itself is possible as well to make use of the simulators features and to separate the framework from custom application code. Also, a WAMP dealer service could be employed to further decouple the module and to advertise available simulation data to different front ends. A further application of our framework, which has not been realised yet, would be to introduce other agents and connect them to our front end and back end via the middleware for monitoring and reconfiguring simulation parameters automatically. An example of this would be an application where part of the data comes from simulation and part of it is collected from real hardware implementations, possibly using the FIT IoT-Lab.


  • [1] András Varga, “The OMNeT++ Discrete Event Simulation System,” in Proceedings of the European Simulation Multiconference (ESM’2001), 2001.
  • [2] M. Köstler, F. Kauer, T. Lübkert, and V. Turau, “Towards an Open Source Implementation of the IEEE 802.15.4 DSME Link Layer,” in Proceedings of the 15. GI/ITG KuVS Fachgespräch Sensornetze, J. Scholz and A. von Bodisco, Eds.   University of Applied Sciences Augsburg, Dept. of Computer Science, Sep. 2016, Technical Reports.
  • [3] WAMP - The Web Application Messaging Protocol The Web Application Messaging Protocol. [Online]. Available: http://wamp-proto.org/
  • [4] Autobahn|JS - WAMP for Browsers and NodeJS. [Online]. Available: https://github.com/crossbario/autobahn-js
  • [5] jQuery. [Online]. Available: https://jquery.com/
  • [6] Chart.js - Simple yet flexible JavaScript charting for designers & developers. [Online]. Available: http://www.chartjs.org/
  • [7] Institute of Telematics, TUHH, openDSME. [Online]. Available: http://opendsme.org/
  • [8] F. Kauer, M. Köstler, T. Lübkert, and V. Turau, “openDSME - A Portable Framework for Reliable Wireless Sensor and Actuator Networks,” Demonstration at the International Conference on Networked Systems, Mar. 2017.
  • [9] Low-Rate Wireless Personal Area Networks (WPANs), IEEE Standard 802.15.4, 2015.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description