A variety of WSN simulators exist, many with different features. This section covers a number of the simulators considered for the simulations performed in this work.
2.5.1
TOSSIM
TinyOS is a flexible, embedded, component-based operating system and platform for low-power wireless devices, such as those used in wireless sensor networks [84]. The design motivations of the TinyOS are to deal with: (i) limited resources, (ii) reactive concurrency, (iii) flexibility and (iv) low power. These features are
supported because the OS is written in a C dialect called nesC [49] optimised for the memory limits of sensor networks. TinyOS supports an event-driven concurrency model based on split-phase interfaces, asynchronous events, and deferred computation called tasks.
Codes written for TinyOS can be run in the TOSSIM simulator and also on a variety of hardware. TOSSIM is a discrete event simulator capable of accurately modelling sensor nodes and the modes of communications between them. TOSSIM provides two noise traces to model the environment: (i) The
meyer-heavy noise sample collected from the Meyer library from Stanford and (ii)
the casino-lab noise sample collected from Colorado schools of mines. The main
difference is that meyer-heavy trace creates a very noisy environment whereas casino-lab trace generates a more quiet environment [83]. Instead of compiling a TinyOS application for a node, users can compile it into the TOSSIM framework, which runs on a laptop. Thus, this allows users to debug, test and analyse algorithms in a controlled and repeatable environment. However, TOSSIM has several disadvantages: (i) TOSSIM only supports codes written for TinyOS, and (ii) Only one hardware platform (MICAz) is supported.
2.5.2
COOJA
COOJA is a novel simulator for the Contiki operating system [39] that enables cross-level simulation: simultaneous simulation at many levels of the system. COOJA combines low-level simulation of sensor node hardware and simulation of high-level behaviour in a single simulation. COOJA is flexible and exten- sible in that all levels of the system can be changed or replaced: sensor node platforms, operating system software, radio transceivers, and radio transmission models [112].
The simulator is implemented in Java, making the simulator easy to extend for users, but allows sensor node software to be written in C by using the Java native interface. Furthermore, the sensor node software can be run either as compiled native code for the platform on which the simulator is run, or in a sensor node emulator that emulates an actual sensor node at the hardware level. It supports the MSP430 and ATmega CPUs in the form of support for the TelosB (Sky) and MICAz motes.
Whilst COOJA has proved to be very useful there are some issues with it that do not seem to have been resolved. There are issues with the compiler
for the TelosB motes22 (MSP-GCC 4.6.3) where instructions are generated for
the MSP430X CPU instead of the MSP430 CPU present. This is the default compiler provided by TinyOS and also the Debian operating system. Updating to a more recent version of the compiler introduced its own set of issues, so code needs to be written to avoid the generating MSP430X instructions.
2.5.3
RIOT
RIOT is a small operating system for networked, memory-constrained systems with a focus on low-power wireless Internet of Things (IoT) devices [11]. RIOT is based on a microkernel architecture inherited from FireKernel [143]. In contrast to other operating systems with similarly low memory usage (e.g., TinyOS
2https://github.com/contiki-os/mspsim/blob/47ae45/se/sics/mspsim/core/
or Contiki), RIOT allows application programming with the programming languages C++ and provides multiple network stacks such as IPv6, 6LoWPAN and transmission control protocol (TCP). Advantages of the RIOT architecture thus include: (i) high reliability and (ii) a developer-friendly API.
However, RIOT has no provided simulator. This means that cycle accurate simulators like COOJA would need to be used to simulate code. This comes with the same downsides as using Contiki with COOJA, the main one being the low scalability and low simulation speed.
2.5.4
FlockLab
FlockLab is a wireless sensor network testbed developed and run by the Com- puter Engineering and Networks Laboratory at the Swiss Federal Institute of Technology Zurich in Switzerland [91]. FlockLab combines the capability of a logic analyser, power analyser, serial data logger, and programmable power supply with network synchronisation and deep local storage adjacent to each targetdistributed across the entire testbed.
FlockLab consists of several distributed target-observer pairs and a set of
servers. Observersare powerful platforms that can host up to four devices under
test, the targets, connected through relatively simple interface boards. They
connect to several backendserversresponsible for coordinating their distributed
and synchronised operation, for processing and storing collected results, and interacting with FlockLab users. FlockLab users can program the nodes using different OS such as TinyOS and Contiki. However, FlockLab does not have enough nodes, so many SLP-routing protocols requiring hundreds of nodes cannot be tested on it. Besides, queued jobs in FlockLab cannot exceed 1 hour of queued testbed time.