A Remote Interface for Live Interaction with OMNeT++ Simulations
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++.
OMNeT++  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 . 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.
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.
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.
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
V Implemented Features
With the presented framework, we developed a demonstration of the open source project openDSME  . This demo was first presented at the NetSys 2017 . 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  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.
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
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.
-  András Varga, “The OMNeT++ Discrete Event Simulation System,” in Proceedings of the European Simulation Multiconference (ESM’2001), 2001.
-  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.
-  WAMP - The Web Application Messaging Protocol The Web Application Messaging Protocol. [Online]. Available: http://wamp-proto.org/
-  Autobahn|JS - WAMP for Browsers and NodeJS. [Online]. Available: https://github.com/crossbario/autobahn-js
-  jQuery. [Online]. Available: https://jquery.com/
-  Institute of Telematics, TUHH, openDSME. [Online]. Available: http://opendsme.org/
-  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.
-  Low-Rate Wireless Personal Area Networks (WPANs), IEEE Standard 802.15.4, 2015.