Reducing Simulation Runtime in Wireless Sensor Networks: A Simulation Framework to Reduce WSN Simulation Runtime by Using Multiple Simultaneous Instances

Introduction

A Wireless Sensor Network (WSN) consists of a large number of sensor nodes communicating with each other, where each node has limited energy and processing resources. Usually, these nodes generate and transport sensed data towards a gateway node, which, in turn, connects these networks to the Internet, as shown in Figure 1.

Figure 1.

Typical WSN

The WSNs can be deployed in real scenarios using hardware products such as the Z1 (“Z1 mote,” n.d.), the SeedEye (“SeedEye,” n.d.), the MICAz (“MICAz,” n.d.), or the Tmote Sky (“Tmote Sky Project,” n.d.). In terms of software, specifically regarding the Operative System (OS), multiple options are available, examples being the Tiny OS (“TinyOS,” n.d.), the RIOT OS (“RIOT Operative System,” n.d.), and the Contiki (“Contiki OS,” n.d.).

To design and test WSN, namely in scenarios using Contiki, the developers may rely on a development environment named InstantContiki which consists of an Ubuntu Linux in a VMware virtual machine with a set of developer tools. Up to date, the latest version of Contiki is 2.7 and it includes the Cooja simulator (Osterlind, Dunkels, Eriksson, Finne, & Voigt, 2006).

The Cooja simulator is a WSN simulator that uses the full Contiki’s source code in a set of emulated hardware nodes. While other simulators, such as NS-2 (“NS-2,” n.d.) or NS-3 (“NS-3,” n.d.), assume that motes are simplified versions of the real hardware, the usage of full Contiki’s source code and real hardware emulation allows Cooja to obtain close-to-real results and enables the fast deployment of the simulated experiments directly onto the real motes. However, it also increases simulation complexity and simulation runtime. The extension of simulation runtimes can be more expressive when developers need to run multiple simulations in order to obtain statistically sound simulation results, either to test different random topologies or test the same scenario with random seeds. Such rounds of repeated simulations in Monte Carlo experiments can sum up to several hours or even days of simulation runtime.

At the same time, while running simulations, Cooja runs as single-threaded and this means that it uses a single process and a single core at each instant of time. Thus, if Cooja simulator runs within a machine where a multi-core processor is available, these cores will be underused. While there may not be a direct correspondence between the number of cores assigned to the InstantContiki virtual machine, and the number of cores on the real host machine, the underutilization of virtual processing resources leads to the underuse of real processing resources.

The current chapter proposes a simulation framework that automates Cooja simulations and allows Cooja to run multiple simultaneous instances in order to take advantage of multiple virtual cores. The results show that by running multiple simultaneous instances, this simulation framework reduces simulations runtime while requiring a higher CPU load and a higher usage of RAM.

Background

Other research efforts have been applied in order to reduce simulation times either by sampling simulation, by dynamically changing simulation detail, or by using multi-threaded workloads in order to take advantage of multi-core processors. In sampling simulations, developers reduce the simulation runtimes by simulating just a small percentage of the overall tested applications, though trying to cover its most relevant portions and obtain close to real results. Using dynamic simulation detail, the developers use different details while the simulation is running, highlighting specific stages of simulations that will be executed with detail (extending simulation runtime) and using other stages executed with low detail (reducing simulation runtime). This technique reduces simulations runtime when compared to constant high detail simulations execution technique.