Georg-August-Universitt a Gttingen o Institute of Computer Science

ISSN No.

1611-1044 IFI-TB-2010-04

Technical Report

Simulation Environments for Wireless Sensor Networks

Ansgar Kellner, Kerstin Behrends, Dieter Hogrefe

Technical Reports of the Institute of Computer Science at the Georg-August-Universitt Gttingen a o June 2010

Georg-August-Universitt Gttingen a o Institute of Computer Science Goldschmidtstr. 7 37077 Gttingen o Germany Phone: +49 (551) 39 - 172000 Fax: +49 (551) 39 - 14403 E-Mail: oce@cs.uni-goettingen.de WWW: www.i.informatik.uni-goettingen.de

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

Simulation Environments for Wireless Sensor Networks

Ansgar Kellner, Kerstin Behrends, Dieter Hogrefe

AbstractRecently, the advances in micro-technology and highly integrated electronics speeded up the rising technology of Wireless Sensor Networks (WSNs). In WSNs distributed autonomous, self-conguring devices, so called sensor nodes, cooperate to form a wireless network for monitoring environmental conditions such as temperature, motion etc. Originally starting from military researches, their application area also evolved into civil areas such as the monitoring of factories or emergency scenarios. The research area of WSNs is still under development so that continuously new protocols and components have to be tested, which causes tremendous costs in terms of money, but also developing and deployment costs. An alternative to the development on real sensor nodes, is the use of simulation environments, as widely practised in other networking domains. However, WSNs have special characteristics that have to be considered and that also have to be made available for simulation environments. Therefore, this technical report discusses a selection of current simulation environments that can be used to simulate WSNs, covering existing simulation environments that were extended to support WSNs, but also new simulation environments that were developed from the scratch for WSNs. Index TermsWireless Sensor Networks; Simulation Environments; WSNs; Network Simulator; Simulation Tools

instead of implementing everything on real hardware sensor nodes. The rest of the technical report is structured as follows: In the second section, the detailed reasons for using simulation environments in the context of WSNs will be discussed. Afterwards, current simulation environments, which can be used for WSNs, are investigated. Finally, conclusions about the considered simulation environments will be drawn and an overview table will be presented that contains the main features of the simulation environments.

II. M OTIVATION Due to the continuously changing research area of WSNs, new ideas in hard or software design as well as modications in existing parts have to be extensively veried regarding their correctness, impact and aptitude for daily use in different WSN application scenarios. In general, it is not feasible to test each new implementation, modication or change in conguration on real hardware because of the tremendous effort of time and costs. For that reason, as in other networks areas widely practised, simulation environments are used to test certain scenarios in advance. This approach provides additionally debugging, monitoring and controlling features, which can help to observe certain interactions of nodes that would be impossible in a live-system. However, in contrast to wired and common wireless networks, WSNs have certain requirements, which have to be considered for the choice of a simulator. One crucial requirement is scalability because it is assumed that WSNs consists of hundreds up to thousands of nodes. Nonetheless, the simulator should provide correct and accurate results so that conclusion can be drawn how the entire system could react in the real world. For accuracy reasons, ideally a battery and a power model should be provided by the simulation environment as well as realistic propagation modelling and physical environment modelling. Furthermore, the architecture of the simulator should be exible so that single components, such as certain protocol layers, can be easily exchanged without big effort. At the moment, various simulation environments exists that can be used for WSNs. However, the simulation environments differ signicantly in their structure and the provided features such as models and protocols. For that reason, in the following an overview of currently existing simulation environments that provides support for WSNs will given.

I. I NTRODUCTION With the arise of wireless technology in the last few years, existing, previously wired, applications became wireless, while at the same time completely new application areas emerged. One of the main research areas that emerged in the context of wireless technology was ad hoc networks, i.e. cooperating, self-conguring network nodes capable of connecting to each other on a peer-to-peer basis on demand without an xed infrastructure using the wireless medium. With the advances in micro and highly integrated electronics as well as with the improvement of energy accumulators, a new generation of devices, so called sensor nodes, was developed, which can be seen as special subset of ad hoc networks. The main application area of sensor nodes is to perform sensing tasks in a distributed manner, while consuming as little energy as possible. The focus of these wireless sensor networks (WSNs) is to cooperatively reach the common goal of collecting, aggregating and forwarding sensed data from a certain region via multiple hops to a certain point in the network where the data can be analysed and evaluated. However, due to the continuous technological progress, new techniques, algorithms and protocols needs to be developed and tested in various WSN application scenarios to examine their usefulness, correctness and effectiveness. One option for testing is to use simulation environments to ease this process,

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

III. S IMULATION E NVIRONMENTS FOR WSN S In this section, a selection of existing simulation environments for WSNs is discussed. Basically, the investigated simulation environments can be divided into two major types: adaptive development and new development. The adaptive development covers simulation environments that already existed before the idea of WSNs emerged. These simulation environments were then extended to support wireless functionality and were then adapted for the use with WSNs. In contrast, new developments cover new simulators, which were created solely for simulating WSNs, considering sensor specic characteristics from the beginning. Both types have advantages and disadvantages, but basically it can be stated that while the evolutionary adaptation has some advantages in reusing well-tested ideas and source code as well as the bigger user and developer basis, the new developments have their advantages in focusing on the special characteristics and the functioning of sensor nodes.

Fig. 1.

QualNet Architect: Design Mode [5]

A. GloMoSim/ QualNet GloMoSim [1][3] is a scalable simulation environment for wireless and wired network systems, which uses the parallel discrete-event simulation capability provided by Parsec [4], a c-based simulation language for sequential and parallel execution of discrete-event simulation models. Both, GloMoSim as well as Parsec, were developed by the Parallel Computing Lab. at UCLA. GloMoSim can be run on Windows as well as Unix derivates. GloMoSim follows the idea of the OSI reference model by using a layered approach. For the communication between the different simulation layers a standard API is used so that new models and layers can be rapidly exchanged and integrated. Furthermore, a JAVA GUI is provided for the creation and conguration of scenarios as well as the playback of simulations and the ascertain of results. GloMoSim offers basic functionality to simulate wireless networks, even for ad hoc networks (e.g. AODV, DSR). However, the current version of GloMoSim does not offer any sensor network specic features in the default package so that without any further efforts no WSNs can be simulated meaningfully. In 2000 QualNet [6], [7], a commercial derivate of GloMoSim, was created and with GloMoSim 2.0, the last version of GloMoSim, was released under an academic licence. From this point in time, no further improvements to GloMoSim were made, whereas the development of QualNet expedited. In October 2009 the current version 5.0 of QualNet was released including enhancements such as a new sensor network library for ZigBee, new network security library, parallel updates, new models (e.g. battery and energy), updates to current models as well as performance improvements. Furthermore, a new QT based GUI was added providing a scenario designer, a visualiser to view network scenarios (2D and 3D), a packet tracer for debugging, an analyser for statistics and a le editor to edit the scenarios directly.

Fig. 2.

OPNET [11]

B. OPNET Modeler Wireless Suite OPNET Modeler Wireless Suite (Version 16.0, released December 2009) [8][10] is a commercial modelling and simulation tool for various types of wireless networks. It is developed by developed by OPNET Technologies, Inc. and based on the well-known product OPNET Modeler. The simulation environment uses a fast discrete event simulation engine operating with a 32-bit/ 64-bit fully parallel simulation kernel, which is available for Windows and Linux. The OPNET Modeler provides an object-oriented modelling approach and a hierarchical modelling environment. As a foundation a three-tiered hierarchy is used covering the three domains: network, node and process. The network domain consists of nodes, links and subnets. A node represents a network device and groups of devices, i.e. servers, workstations etc. and WLAN nodes, IP clouds etc. Links represent point-to-point and bus-links between the nodes. The node domain covers the building of blocks, also referred to as modules, including processors, queues and transceivers as well as the specication of interfaces between the modules. The

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

process domain consists of state transition diagrams, clocks of C-code, OPNET Kernel Procedures (KPs) as well as state and temporary variables. An advantage of OPNET Modeler is that all these domains can be accessed using graphical editors that are integrated in a common GUI, which also provides debugging and analysis features. As a result, basic network simulations can be simply created without special programming knowledge. However, the internal process of nodes and protocols have to be dened as C++ classes. The Wireless Suite already includes hundreds of wired/ wireless protocol and vendor device models with source code. Although there are no special routing protocols for wireless sensor network available, at least different propagation and modulation techniques as well as a ZigBee (802.15.4) MAC layer are provided. Additional modules have to be customised or developed from the scratch. The simulations of wireless networks can be run as discrete event, hybrid or analytical, encompassing terrain, mobility and path-loss models. Due to the open interface external object les, libraries as well as other simulators can be integrated to the OPNET Modeler. Optional a System-in-the-Loop is available to interface simulations with live systems. Furthermore, the OPNET Modeler Wireless Suite provides grid computing support so that simulations can be executed in a distributed manner. C. TOSSIM TOSSIM (TinyOS mote simulator) [12][15] is a discreteevent simulator for TinyOS sensor networks that is part of the ofcial TinyOS package. TOSSIM takes advantage of the component based architecture of TinyOS by integrating it transparently by providing a new hardware resource abstraction layer that simulates the TinyOS network stack at the bit level for normal PCs. Due to this approach low-level protocols up to top-level applications can be simulated with TOSSIM. To compile TinyOS code no additional modications have to be made to the source code, instead just another make target has do be dened, i.e. instead of compiling the TinyOS source code for a sensor node, it can be simply compiled for a normal PC using the TOSSIM framework. Because the applications compiled for TOSSIM can be run natively on a PC, the traditional debuggers and development tools can be used as for normal applications. As a result, developers cannot only test their algorithms, but also their specic implementations. After successful testing the implementation can be deployed directly to a real TinyOS-based sensor node without any modications. TOSSIM has an external communication system so that transmitted packets can be monitored and even new packets can be injected to network. Furthermore, the conguration of the debug options is ne grained providing the desired debug output at runtime. TOSSIM offers three network connectivity models: simple connectivity, static connectivity and space connectivity. While using simple connectivity all sensor nodes are in one cell, with static connectivity the network graph is created once at start up and then never changes again. In space connectivity the sensor nodes move randomly in a squared area and their transmission range can be changed.

Fig. 3.

Visualisation of a TOSSIM simulation with TinyViz [16]

The running simulations can be visualised and controlled by the Java-based GUI TinyViz. The user interface offers, on the one hand, passive observing mechanisms, for instance, the inspection of debug messages or radio ranges, and, on the other hand, mechanisms to interact actively with the network, for example by injecting packets to the network. The utilised plugin architecture enables the user to develop new visualizations and controlling interfaces for TinyViz. D. OMNeT++ OMNeT++ [17][20] is an object-oriented discrete network simulation framework. The architecture is rather generic so that various problem domains can be simulated such as protocol modelling, validation of hardware architectures and modelling of wired and wireless communication networks. OMNeT++ is not a simulator, but it rather provides a framework and tools to write simulations. It is highly portable so that it can be run on the most common operating systems such as Windows, Linux and Mac OSX. The current version 4.0 of OMNeT++ was released in March 2009. It is free for academic and non-prot use for commercial purposes OMNEST, a commercially supported version, can be licensed by Simulcraft Inc. One of the fundamentals of the OMNeT++ framework is the component-based architecture for the simulation models: A model can be combined in various ways from reusable components, so called modules. The modules can be connected using gateways and multiple modules can be combined to form a compound module the nesting depth is unlimited. The communication between modules is done via message passing, where each message can carry arbitrary data structures. The messages can be passed either using pre-dened paths via gateways or directly to the destination. Each module can have parameters to customise the module behaviour and/ or customise the topology of the model. The modules at the lowest level of the hierarchy, also referred to as simple modules, are programmed in C++ and make use of the simulation library. The larger components are assembled using the high-level language NED. A simulation with OMNeT++ can be run utilising various interfaces: from simple command-line interfaces, which suits ideally for batch execution, to sophisticated graphical animated user interfaces, which can be used for debugging

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

Fig. 4.

OMNeT++ 4.0 IDE [21]

or demonstration purposes. In the current version an Eclipsebased comprehensive simulation IDE has been introduced to replace the previous standalone GUI programs gned, scalars and plove. OMNeT++ also supports the execution of parallel distributed simulations by providing several communication mechanisms between partitions. To run a parallel distributed simulation no special modications to the models are necessary only the conguration has to be modied correspondingly. There are a couple of simulation frameworks that enable OMNeT++ to be used for wireless sensor networks. The most common of these frameworks are discussed in the following subsections. Mobility Framework: The Mobility Framework [22][24], developed in the Telecommunication Networks Group (TKN) at the Technical University of Berlin, provides only basic support for mobile and wireless networks. It includes some basic layers such as MAC layers (Aloha, CSMA) and network layers (ooding) as well as some basic mobility functionality and some basic application layer. However, except from this, the Mobility Framework does not offer any sensor network specic functionality. Besides, the Mobility Framework is not actively maintained anymore because the code was integrated into the MiXiM project that should be used instead in the future. MiXiM: MiXiM [25], [26] is a merger of several OMNeT++ frameworks to support mobile and wireless simulations. It uses the mobility support, the connection management, and the general structure from the Mobility Framework (MF); the radio propagation models from the CHannel SIMulator (ChSim); and the protocol library from the MAC simulator, the Positif frame- work [27], and the Mobility Framework. At the moment, there is no ofcial release of MiXiM, though the current developing status can be downloaded and used. However, MiXiM is currently under heavy development so that only a subset of the envisioned features is implemented until now. Currently, there are implementations of CSMA and a 802.11 MAC Layer available as well as about ten mobility modules. The implementation of routing protocols has begun so that rst alpha implementations of basic sink routing and

queued routing are available in the developer tree. Castalia: Castalia [28], [29] is a simulator for WSNs (WSN), body area networks (BAN) and generally networks of low-power embedded devices that is based on OMNeT++. It is developed at the National ICT Australia since 2006 and made public as open source under the Academic Public License in 2007. Currently, Castalia is available in version 2.3b (released November 2009). Castalia provides and advanced channel model based on empirically measured data, an advanced radio model based on real radios for low-power communication as well as extended sensing modelling provisions. Furthermore, specic characteristics such as the clock drift of nodes and CPU power consumptions are considered. Until now only TMAC, bypass MAC and a tunable MAC module are provided. The routing support is rather basic so that there are only implementations of some basic approaches such as bypass routing, multipath rings routing and simple tree routing. INET Framework: The INET Framework [30], [31] is a framework for OMNeT++ that contains various implementations of common protocols, such as IPv4, IPv6, TCP, UDP etc., as well as several application models. The INET Framework is not specialised on mobile and wireless networks, but has some support for it. The mobility and wireless functionality were derived from the Mobility Framework. Recently, there have been contributions to support ad hoc routing protocols such as DYMO, DSR and AODV, but currently there is not special WSN support. NesCT: NesCT [32] is not a real framework, but rather a translator from the programming language NesC to C++ classes for OMNet++. The idea of NesCT is that code can be directly written in NesC using TinyOS components for actual hardware, but at the same time all the features of OMNeT++ and the Mobile Framework (MF) can be used for a simulation of the code. The combination of NesCT, OMNeT++ and MF allows to make use of already existing protocols such as the accurate physical layer of MF that uses 802.11 as radio and which can be tuned by parameters such as transmission range, speed, delay etc. E. NS-2 NS (the Network Simulator) [33], [34] is an object-oriented discrete event simulator targeting at networking research. At the beginning, NS was focused on wireless networks, but over time there was also wireless support included. The development of NS started already in 1989 as a variant of the REAL network simulator. From 1995 on, NS gained support from DARPA (VINT). Currently the development is continued in collaboration with different researchers and institutes including DARPA (SAMAN), NSF (CONSER) and ICIR. Further contributions for wireless support were made by Sun Microsystems and the UCB Daedelus and Carnegie Mellon Monarch projects. In June 2009 the current version NS-2.34 was released. Due to its current major version number NS is also often referred to as NS-2.1 NS-2 is written in C++ and OTcl, an object-oriented version of Tcl. The main idea of NS-2 is based on the separation
1 The

development of NS-3 started in 2006, but is still under development.

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

radio), lightweight protocol stacks for wireless micro-sensors, scenario generation and hybrid simulation. A special feature of SensorSim is the hybrid simulation mode that enables the integration of real application support, i.e. the same applications that run on real nodes can also run on simulated nodes without any modications. Besides, real nodes and simulated nodes can interact with each other. However, due to the inability of the authors to provide support for the public release, SensorSim was withdrawn so that there is currently no public version available. F. Avrora Avrora [41][43] is a set of simulation and analysis tools for programs written for AVR micro-controllers. It has support for different sensor platforms, such as Mica2 and MicaZ, allowing wireless network simulation, dynamic instrumentation and static analysis. Since 2004, Avrora is developed in a research project of the UCLA compiler group. Currently Avrora is available in version Beta 1.7.106 from August 2008. The special characteristic of Avrora is that it operates on the instruction-level, i.e. actual microcontroller programs can be run in the simulator, instead of just simulating software models. This approach provides an accurate simulation of devices and radio communication so that, for example, the energy usage can be predicted according to the number of clock-cycles needed for the used instructions. Avrora is implemented in Java which offers great exibility and portability because the simulation of machine code is operating system independent. Avrora runs one thread per node. The synchronisation between the threads is only done when necessary, i.e. only to ensure the global timing and the order of radio communication. For the efcient execution of programs an event queue is utilised, which provides a cycle accurate execution of the device and a guaranteed communication behaviour. Avrora scales up to networks of 10.000 nodes and performs 20 times faster than previous simulators with the emulating approach and the same accuracy. Moreover, Avrora contains further tools such as proling utilities, an energy analysis tool, a stack checker, a control ow graph tool etc. However, Avrora lacks an integrated graphical user interface so that everything has to be done manual on the command line. G. J-Sim J-Sim [44][46] is a component-based compositional simulation environment based on the autonomous component architecture (ACA). The basic entities of ACA are components, which communicated with each other by sending and receiving data using their ports. The components behaviour is specied at design time in contracts their actual binding will linked at system integration time. The loosely-coupled component architecture of J-Sim enables the user to design, implement and test single components individually. New components can be easily added or exchanged for existing ones. On top of ACA a generalised packet switched network model, the so called Internetworking Simulation Platform (INET), is developed that

Fig. 5.

Visualisation of a ns-2 simulation with NAM [35]

of control and data: While OTcl is used for the control, i.e. the scripting of the model topology and its parameters, C++ is used for the data, i.e. the programming of each object in the simulation topology. The separation of these two areas is achieved by the following approach: Each network component object is written and compiled in C++. For each of these C++-objects a corresponding OTcl-object is created by OTcl linkage. As a result, the C++ objects can be controlled by OTcl. The standard operating procedure for creating a simulation with NS-2 is as follows: First, a OTcl script is written that describes the network topology, its parameters as well as the network trafc. After that the OTcl script will be run by the OTcl interpreter that utilises the NS Simulator Library. The NS Simulation Library provides access to different simulation parts including the Event Scheduler Objects, the Network Component Objects and the Network Setup Helping Modules. In the third step, the simulation will be run, and the results will be stored in so called trace les. Finally, these les can be analysed by scripts or even animated by the graphical Network Animator (NAM). Due to this approach, a change in topology does not result in recompiling the entire simulation. The source code, licensed under GPL2, is freely available so that NS is very extensible and thus widely used in academia. A huge amount of contributed protocol source codes can be found on the website http://nsnam.isi.edu/nsnam/index.php/ Contributed Code. among them there are also some for WSNs interesting wireless protocols such as different variations of 802.11, 802.16, IR-UWB, BlueTooth and 802.15.4. Despite the great number of contributing researchers the support for wireless sensor network specic protocols is rather low. As special wireless sensor network framework the Mannasim Framework [36] should be highlighted that provides sensor network specic protocols such as LEACH and Directed Diffusion. Also the extension NS2-MIUN [37] provides some wireless sensor network specic contributions with the focus on intrusion detection. SensorSim: SensorSim [38][40] is a simulation framework for modelling sensor networks that built up on NS-2. It provides additional features for modelling sensor networks such as sensor channel models, power models (battery and

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

denes the generic structure of a node and the generic network components, which can be used as base classes to implement protocols across various layers. The combination of J-Sim as Java implementation and the component-based architecture makes J-Sim a platformindependent, extensible and reusable simulation environment. Moreover, J-Sim provides a scripting interface that enables the use of script languages such as Perl, Tcl and Python. In the current release, version 1.3, Jacl, the Java implementation of a Tcl interpreter, is completely integrated into J-Sim. J-Sim provides a dual-language environment similar to NS-2. The basic classes are written in Java, while their linkage is glued together using a scripting language such as Tcl/Java. In comparison to NS-2, the classes/methods/elds do not have to be exported to be accessible by Tcl. A framework for sensor networks simulation is included, which has been built upon ACA, INET and the Wireless Protocol Stack. In the framework the following components are specied: sensor and sink nodes; sensor channels and wireless communication channels; and physical media covering seismic channels, mobility models and power models. Applicationspecic models can be dened by sub-classing the specied classes of the WSN simulation framework and adapting them to the desired behaviour. At the moment, 802.11 is used as MAC Layer and AODV is provided as routing protocol. H. ATEMU ATEMU [47], [48] is one of the rst instruction-level software emulators for AVR based systems. Additionally peripheral devices of the MICA2 sensor node platform such as radio is supported. Although at the moment only the MICA2 hardware is supported, ATEMU can be easily extended to support other sensor node platforms. ATEMU is developed at Maryland University and currently available in version 0.4, which was already released in March 2004. The ATEMU consists of two components: the ATEMU emulator core and the XATDB graphical debugger. The ATEMU emulator core can simulate an arbitrary amount of sensor nodes and can model the interaction between them such as the radio communications. Because of the emulation of the AVR instruction set and the partial support for all MICA2 board components, the simulation results are close to the real-life operation of a wireless sensor network. The only difference to reality is that the medium air is at the moment only modelled as d2 propagation the authors claim to improve this in future releases. Because of the binary compatibility with the MICA2 platform, TinyOS-based software can be directly used for the simulation. Furthermore, each node can run different application code. As a result, the execution of binaries can be accurately modelled on the AVR processor emulation engine without loosing much details due to the abstraction. This enables the user to perform comparisons of different sensor networking protocols on the same platform and obtaining relatively realistic results. The other component of the ATEMU package is XATDB, a graphical gdb-like fronted to the ATEMU emulator core. XATDB provides a system for debugging and monitoring the execution of code

including the set of watchpoints and breakpoints as well as the execution in single steps of the assembly or nesC code. The powerful debugging interface can be used for multiple nodes in a sensor network at the same time. Although ATEMU is the most accurate instruction-level emulator for wireless sensor network research, it lacks from simulation speed, being 30 times slower than TOSSIM, for example. I. EmStar EmStar [49][51] is an environment for WSNs built from Linux-class devices, so called microservers. In comparison to motes, microservers are much less constrained in computational power and data storage size so that they can handle more complex tasks such as image and audio processing. EmStar consists of simulation and emulation tools, which utilise a modular, but not strictly layered, architecture. The current version 2.5 of EmStar was released in October 2005. The EmStar is utilising a modular approach based on a multiprocess service architecture, i.e. it is built as a collection of separate processes, also referred to as modules, providing services. The use of the more powerful microservers enables EmStar to support multiple independent applications concurrently. The idea of implementing each service as separate process enables, on the one hand, greater freedom for the implementation and, on the other hand, it provides fault isolation between services. Because each module focuses on a well scoped task, the initial implementation of each service can be simplied and later be extended and rened for more complex tasks. The communication between the modules is done through well dened interfaces. Moreover, the modular approach provides the opportunity to compose services as needed for certain implementations individually. Similar to TinyOS, EmStar uses an event-driven software structure, i.e. it reacts to asynchronous notications. The notication is passed up from the lowest to the top level layer. At each level domain-specic ltering can be applied. EmStar provides different simulation modes: a pure simulation mode, an emulation mode, a real mode and a hybrid mode. In the pure simulation mode the microserver and mote code is run in the EmStar environment and all nodes communicate through a simulated RF channel. In contrast, in the emulation mode the microserver and mote code is run in the EmStar environment, but the nodes communicate using a real RF channel. In the real mode, the microserver code runs in the EmStar environment, while the mote code runs natively on real motes. The communication between the emulated microservers and the mote is done via a real RF channel. The hybrid mode supports a mixture of real and emulated modes, in which some nodes are emulated, while others run natively. All nodes communicate through a real RF channel. The EmStar source code and conguration les are identical for all these modes so that they can be easily exchanged. The EmStar release includes multiple tools to support the deployment, the simulation, the emulation, and the visualisation of real and simulated WSNs. The main tools are: EmSim/EmCee, EmProxy/EmView, EmRun and SCALE. EmSim

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

can run many virtual nodes in parallel in a simulation environment that models radio and sensor channels. EmCee runs the EmSim core, but provides an interface to real low-power radios instead of modelled channel. EmView is a graphical visualiser for EmStar based systems, which is able to display the real-time state of running emulations. EmView provides a plug-in system so that it can be extended by new plug-ins for further applications and services. EmProxy is a server that runs on a node or as part of a simulation to handle requests from EmView. Based on these requests EmProxy monitors the nodes status and report the results back to EmView. EmRun starts, stops and manages running EmStar services. Based on the given conguration le, which species the dependencies of the various services in terms of their connections, EmRun can start the system in the dependency order, while maximising parallelism. Each child process is monitored via control channel so that unresponsive services can be detected and restarted. Furthermore, per-process logging to memory-ring buffers can be activated for different debug levels. SCALE is a tool that gives a general assessment of connectivity across the network by tracking connectivity between nodes to give a measure of link quality. SCALE can be integrated in EmView. For interaction EmStar uses the Linux /dev le system. This feature is provided by the kernel module FUSD, based on devfs, that enables a user-space process to expose device le interfaces by proxy through the kernel. Both, text and binary information, are stored in the same le. The text mode enables interaction from the shell or scripts, while the binary mode enables programmatic access to data, e.g. via C-structures. EmStar provides various services that are used and combined to provide network functionality for wireless embedded systems. This includes link drivers for the lowest-layer interfaces to network resources, pass-through modules that implement various types of lter and passive processing, and routing modules such as Flooding, DSR, Sink, StateSync and Centroute. J. SENS SENS [52], [53] is an application-oriented simulator for WSNs. It has a modular, layered architecture so that components for applications, network communication and the physical environment can be easily interchanged and extended. Due to different component implementations, which varies in the degree of realism, application-specic environments can be created and simulated. SENS is platform independent so that new emerging sensor platforms can be added to the simulator. The last released version of SENS was published in January 2005. In SENS multiple sensor nodes are interacting with an environment component. Each node consists of three components: an application component, a network component and a physical component. Because each component runs separately, several components can be run concurrently. The application component simulates the software on a single network node. To send or receive packets, the application component communicates with the network component and to read sensor values or control actuators with the physical

component. Each individual application component is based on a C++ base class that provides a common interface. Furthermore, a compatibility layer is provided that enables direct portability between the simulator and real sensor nodes so that the simulator code can be used also for TinyOS. The network component simulates the packet sending and receiving functionality. Each network component class is derived from a common networking class, specifying the networking interface. The network component is, on the one hand, connected to a single application component and, on the other hand, to the network components of its neighbouring nodes. The messages that are exchanged between the nodes are based on a xed format. Currently, there are different implementations that provide various characteristics such as SimpleNetwork, ProbLossyNetwork (drop of packets based on error probabilities) and CollisionLossyNetwork (packet collisions). The physical component models sensors, actuators and power as well as interacts with the environment component. Through the environment component the neighbouring nodes can be obtained including the signal strength etc. The environment component provides a model of the real environment with which the nodes sensors and radios can interact. Basically, the environment is modelled as 2-dimensional grid of interchangeable squared tiles. Each tile can simulate different styles of environments such as grass, concrete side-walks and walls. Due to the chosen approach, SENS enables application portability because the same source code can be run with in a simulation or deployed on actual sensor nodes. K. SENSE SENSE (Sensor Network Simulator and Emulator) [54], [55] is a simulator for WSNs that is based on a novel component-oriented simulation methodology, which promotes extensibility and reusability. At the same time, the simulation efciency and the scalability was considered. Currently, SENSE is available in version 3.1 released in November 2008. SENSE is based on COST, a general purpose discrete event simulator using CompC++, a component-oriented extension to C++. COST was inuenced by the ideas of componentbased software architecture and component-based simulation. A component-port model was introduced that enabled the composition of components to form complex software systems. Each component can communicate with other components through in-ports or out-ports. An in-port implements a functionality, whereas an out-port provides an abstraction layer of a function pointer, i.e. denes the functionality expected by others. To apply the component-port model to simulations, the simulation component classication was introduced, which extends the component-port model to the simulation domain. Based on the way how simulated time is handled, the following classes were created: time-independent (Type I), time-aware (Type II) and autonomous classes (Type III). The components are generally written as C++-templateclass so that each component is capable of handling different types of data. The removal of module interdependency enables also the reuse of existing components, i.e. a component that was written for one application can be later used for other

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

applications. For the scalability parallelisation is provided. However, this is not mandatory and the parallel simulation engine can only execute components of parallelisation compatible components otherwise the normal sequential engine can be used. In the component repository of SENSE there are already different components available from the application to the physical layer including IEEE 802.11, AODV, DSR, SSR, SHR as well as Battery Models and a Power Model. At the moment, there does not seem to be any further tools included in SENSE so that, for example, a visualisation tool to analyse the network behaviour graphically is missing. L. Shawn Shawn [56][58] is customisable sensor network simulator based on an algorithmic approach. The primary design goals of Shawn are: simulate the effect caused by a phenomenon, scalability and support for extremely large networks and free choice of the implementation model. Instead of simulating the effects of a phenomenon, Shawn simulates only the caused effects, i.e. for example, for the MAC layer effects, such as packet lost, corruption and delay, are simulated. Due to the effectiveness of this approach this leads to a performance gain. However, a disadvantage of this approach is that not the same level of details as in other simulations can be reached, though a well chosen model can produce the same impacts on the application layer as detailed physical models. To support a large amount of sensor nodes at the same time, the structure of low-level parameters is simplied so that timeconsuming computations can be replaced by fast substitutions, if the investigated behaviour is not affected. Therefore, Shawn has to be adjusted to the problem by selecting only crucial parameters for the current scenario. Shawn supports a multiple-development cycle in which developers can follow different implementation steps: starting from an initial idea and the problem analysis, a rst centralised implementation can be created, then a simplied decentralised protocol can be developed and nally, a fully distributed protocol. All steps are optional, but the gradually process should help the developers to get from the initial idea to a fully distributed protocol. The architecture of Shawn can be divided into three main parts: the models, the sequencer and the simulation environment. Models are the interfaces that are used by Shawn to control the simulation without knowing the exact implementation. Each implementation of a model species the actual behaviour. In the repository of Shawn there are several model implementation available, which can be combined into a simulation setup. There are three models that form the basis of Shaw: the communication model, the edge model and the transmission model. The communication model species whether two nodes can communicate with each other or not. Shawn already includes some of these models such as Unit Disk Graph (UDG), Quasi-Unit Disk Graph (Q-UDG) and Radio Irregularity Model (RIM). The edge model provides a representation of a network as graph in which each vertex

is representing a sensor node and each edge is representing a communication link. To create the graph and keep it current, the edge model queries permanently the communication model. At the moment there are several edge models provided by Shawn such as a lazy edge model, a grid edge model, a list edge model etc. The transmission model deals with the behaviour of the transmission channel in terms of its transient characteristics. This transmission characteristic is determined for each message individually, i.e. the message can be delayed, dropped or altered. Currently there are several implementations for the transmission model provided such as Pure CSMA & CSMA/CA, (Slotted) Aloha, Random Drop etc. Additionally to the three core models, there are several other models provided by Shawn for random variables, distance estimation and mobility. The sequencer is the control centre of the simulation. It creates the environment for the nodes, initiates the model implementations based on the conguration and controls the entire simulation. The sequencer includes the simulation tasks, the simulation controller and the event scheduler. The simulation environment provides a sort of virtual world in which the different parts of the simulation are located. The simulated nodes are located in a single world instance and the nodes themselves are containers for processors. The application logic is implemented as instances of processors. As a result, the application is decoupled from the node so that multiple applications can be executed in a single simulation run. To visualise the simulation scenarios the additional tool Viz is provided, which allows to create a graphical output of a simulation. This can be single images as well sequences of images to create an animation. There is no stable release of Shawn, but the current state of the project can be downloaded via SVN from an open repository (see https://shawn.svn.sourceforge.net/svnroot/shawn). IV. C ONCLUSION The development of new protocols for WSNs is expensive in terms of the required time for development, deployment and testing. A good alternative to reduce this effort is to use simulation environments, as widely practised in other networking domains. However, to simulate WSNs their special requirements and characteristics, such as the demand for high scalability and accuracy, have to be considered and available for the simulation environments that should be used. This technical report gave an insight into a selection of current simulation environments that are capable of simulating WSNs. This included, on the one hand, simulation tools that were extended for WSNs and, on the other hand, simulation tools that were explicitly created for the use with WSNs. Furthermore, the presented tools differed regarding the used approach in terms of simulation, emulation or hybrid. An overview of the investigated simulation environments for WSNs is shown in table I. Although there are several simulators, even beyond the presented selection of simulators, there is no one size ts all tool that can solve all problems for all sorts of scenarios: For different simulation environments there are different layer,

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

Simulation Environment GloMoSim/ QualNet

Version 2.0 (Dec 2000)/ 5.0 (Nov 2009)

License free for academic research/ commercial commercial

OPNET Modeler Wireless Suite TOSSIM (part of TinyOS) OMNeT++

16.0 2009) 2.1.1 2010)

(Dec

(Apr

BSD

4.0 (March 2009)

Academic Public License GPL

NS-2

2.34 2009)

(Jun

Avrora

Beta 1.7.106 (Aug 2008)

BSD

J-Sim

1.3 + patch4 (Jul 2006)

BSD-like

ATEMU

0.4 (2004)

BSD

EmStar

2.5 2005)

(Oct

unknown

SENS

jan31-2005b (Jan 2005) 3.1 2008) (Nov

unknown

SENSE

BSD-like

Shawn

Continuous SVN development (May 2010)

BSD

Programming WSN support Language C and Parsec GloMoSim: basic mobility and radio propagation models; 802.11; QualNet: additionally battery and energy model; ZigBee GloMoSim seems to be outdated; QualNet seems to be more up-to-date, but commercial conguration Different propagation models; 802.11, ZigBee; some by GUI; MANET protocols, but no special WSN support internals C++ powerful tool with a nice GUI, but expensive nesC All TinyOS-based WSN protocols can be simulated with TOSSIM without modications good approach especially if implementation should also be used with TinyOS-based nodes basic modules Several frameworks that add WSN functionality to C++; larger OMNet++ such as MiXiM, Castalia, etc. active structures project with a huge user base; Eclipse-based IDE for NED development C++; congu- Huge amount of protocols available contributed by ration OTcl NS-2 users complex conguration; unclear situation due to large number of different user contributed implementations AVR micro- Particularly for programs written for AVR microcontroller controller with support for support for Mica2 and Mibinaries caZ very special application area; project seems to be still active - still changes in CVS Java; Includes sensor network package containing models conguration such as propagation, battery, radio model and senTcl/Java sor protocol stack including AODV and 802.11 project seems to be abandoned AVR micro- Complete emulation of the AVR instruction set with controller partial Mica2 support; TinyOS based code can be binaries run very special application area; slow simulation speed; project seems to be abandoned C Provides network functionality for wireless embedded systems; EmTOS can be used to run TinyOS applications as EmStar module project seems be abandoned (download links broken) C++ Provides very basic network and physical layer support. Source can be compiled for TinyOS. project does not seem to be developed any further C++ Includes battery and power models, MAC layers (802.11) as well as network protocols (AODV, DSR, SSR, SHR) does not seem to be developed any further C++ Algorithmic approach that concentrates on lower layers, no special WSN protocols very active project - lot of recent changes in SVN

TABLE I OVERVIEW OF S IMULATION E NVIRONMENTS FOR WSN S

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

10

components or protocols implemented so that it is difcult to compare them. Besides, it is obvious that each protocol implementation differs so that even if two simulators have the same protocol, it is likely that there functionality is not be exactly the same. Depending on the application area it should be considered whether new implemented protocols should only be run in a simulator or if the protocols should also be later deployed on real sensor nodes. In the latter case it is recommended to use one of the emulator approaches, which make it possible to use the same source code for the simulator as well as the hardware platform. Because of the obvious differences of simulation environments, a clear recommendation cannot be given. This technical report should be rather seen as starting point to investigate in simulation environments that are a possibility for planned WSN scenarios in the future. V. F UTURE W ORK Until now the results about the studied simulation environments are mainly based on papers, manuals, documentation and partly source code review. For that reason, the provided results are rather theoretical and might be different to practical experience. Therefore, to support these theoretical results about the simulation environments, different scenarios in each simulation environment could be simulated and then the results could be explored with respect to several criteria such as accurateness, performance, memory usage etc. In a next step, the simulated results could be also compared to the real-world experimental test-bed at the sensor lab of the Telematics Group. These results will help to nd out which of the simulation results are the one closest to reality. R EFERENCES
[1] Parallel Computing Laboratory at UCLA. (2010, May) GloMoSim. [Online]. Available: http://pcl.cs.ucla.edu/projects/glomosim/ [2] L. Bajaj, M. Takai, R. Ahuja, K. Tang, R. Bagrodia, and M. Gerla, GloMoSim: A scalable network simulation environment, UCLA Computer Science Department Technical Report, vol. 990027, p. 213, 1999. [3] J. Nuevo, A Comprehensible GloMoSim Tutorial. Quebec, Canada, March 2004, 2006. [4] Parallel Computing Laboratory at UCLA. (2010, May) Parsec. [Online]. Available: http://pcl.cs.ucla.edu/projects/parsec/ [5] Scalable Network Technologies. (2010, May) QualNet Architect: Design Mode (picture). [Online]. Available: http://www.scalable-networks.com/ wp-content/uploads/2009/10/design-mode.jpg [6] . (2010, May) QualNet. [Online]. Available: http://www. scalable-networks.com/products/qualnet/ [7] S. Technologies, Qualnet v. 3.9. 5 users guide, 2006. [8] OPNET Technologies, Inc. (2010, May) OPNET. [Online]. Available: http://www.opnet.com/ [9] H. Jiang, P. Wang, and H. Liu, Research on OPNET simulation model in wireless sensor networks, Jisuanji Gongcheng/ Computer Engineering, vol. 33, no. 4, 2007. [10] P. Jurk and A. Koub a, The IEEE 802.15. 4 OPNET Simulation c a Model: Reference Guide v2. 0, 2007. [11] OPNET Technologies, Inc. (2010, May) OPNET (picture). [Online]. Available: http://www.opnet.com/support/des model library/ images/MANET scrnsht.jpg [12] Computer Science Division at UC Berkeley. (2010, May) TOSSIM. [Online]. Available: http://www.cs.berkeley.edu/pal/research/tossim. html [13] P. Levis, N. Lee, M. Welsh, and D. Culler, TOSSIM: Accurate and scalable simulation of entire TinyOS applications, in Proceedings of the 1st international conference on Embedded networked sensor systems. ACM New York, NY, USA, 2003, pp. 126137.

[14] P. Levis and N. Lee, Tossim: A simulator for tinyos networks, UC Berkeley, September, 2003. [15] S. Notani, Performance Simulation of Multihop Routing Algorithms for Ad-Hoc Wireless Sensor Networks Using TOSSIM, in Advanced Communication Technology, 2008. ICACT 2008. 10th International Conference on, vol. 1, 2008. [16] Computer Science Division at UC Berkeley. (2010, May) Visualisation of a TOSSIM simulation with TinyViz (picture). [Online]. Available: http://www.tinyos.net/tinyos-1.x/doc/tutorial/imgs/ tinyviz-screenshot1.gif [17] OMNeT++ Community. (2010, May) OMNeT++. [Online]. Available: http://www.omnetpp.org/ [18] A. Varga et al., The OMNeT++ discrete event simulation system, in Proceedings of the European Simulation Multiconference (ESM2001), 2001, pp. 319324. [19] A. Varga, OMNeT++ Discrete event simulation system. User Manual, Technical University of Budapest, Dept. of Telecommunications, 2006. [20] A. Varga and R. Hornig, An overview of the OMNeT++ simulation environment, in Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops table of contents. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering) ICST, Brussels, Belgium, Belgium, 2008. [21] OMNeT++ Community. (2010, May) OMNeT++ 4.0 IDE (picture). [Online]. Available: http://omnetpp.org/doc/omnetpp40/ide-overview/ pictures/img1.png [22] Mobility Framework for OMNeT++ Community. (2010, May) Mobility Framework for OMNeT++. [Online]. Available: http: //mobility-fw.sourceforge.net [23] W. Drytkiewicz, S. Sroka, V. Handziski, A. Koepke, and H. Karl, A mobility framework for omnet++, in 3rd International OMNeT++ Workshop, 2003. [24] M. L bbers, D. Willkomm, A. K pke, and H. Karl, Framework for o o Simulation of Mobility in OMNeT++(Mobility Framework), 2004. [25] MiXiM developers. (2010, May) MiXiM project. [Online]. Available: http://mixim.sourceforge.net/ [26] A. K pke, M. Swigulski, K. Wessel, D. Willkomm, P. Haneveld, o T. Parker, O. Visser, H. Lichte, and S. Valentin, Simulating wireless and mobile networks in OMNeT++ the MiXiM vision, in Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops table of contents. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering) ICST, Brussels, Belgium, Belgium, 2008. [27] University of Twente and TU Delft. (2010, May) Positif, MAC Simulator and T-MAC. [Online]. Available: http://www.consensus. tudelft.nl/software.html [28] National ICT Australia. (2010, May) Castalia. [Online]. Available: http://castalia.npc.nicta.com.au/ [29] A. Boulis, Castalia: revealing pitfalls in designing distributed algorithms in WSN, in Proceedings of the 5th international conference on Embedded networked sensor systems. ACM New York, NY, USA, 2007, pp. 407408. [30] OMNeT++ Community. (2010, May) INET framework for the OMNeT++. [Online]. Available: http://inet.omnetpp.org/ [31] A. Ariza-Quintana, E. Casilari, and A. Cabrera, Implementation of MANET routing protocols on OMNeT++, in Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems & workshops table of contents. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering) ICST, Brussels, Belgium, Belgium, 2008. [32] OMNeT++ Community. (2010, May) NesCT for the OMNeT++. [Online]. Available: http://nesct.sourceforge.net/ [33] NS-2 developers. (2010, May) The Network Simulator ns-2. [Online]. Available: http://www.isi.edu/nsnam/ns/ [34] I. Downard and N. R. L. W. DC, Simulating sensor networks in ns-2, 2004. [35] NS-2 developers. (2010, May) Visualisation of a ns-2 simulation with NAM (picture). [Online]. Available: http://www.isi.edu/nsnam/ nam/nambig.gif [36] Departamento de Ci ncia da Computacao, Universidade Federal de e Minas Gerais. (2010, May) Mannasim Framework for ns-2. [Online]. Available: http://www.mannasim.dcc.ufmg.br/ [37] Computer Science, Mid Sweden University , Sweden. (2010, May) NS2-MIUN. [Online]. Available: http://apachepersonal.miun.se/ qinwan/resources.htm

TECHNICAL REPORT, IFI-TB-2010-04, JUNE 2010

11

[38] Networked and Embedded Systems Laboratory (NESL) at the University of California at Los Angeles (UCLA). (2010, May) SensorSim framework. [Online]. Available: http://nesl.ee.ucla.edu/ projects/sensorsim/ [39] S. Park, A. Savvides, and M. Srivastava, SensorSim: a simulation framework for sensor networks, in Proceedings of the 3rd ACM international workshop on Modeling, analysis and simulation of wireless and mobile systems. ACM New York, NY, USA, 2000, pp. 104111. [40] , Sensor Sim: A Simulation Framework for Networks Sensors, Electrical Engineering Department, University of California, Los Angeles, Retrieved October, vol. 16, 2006. [41] UCLA Compilers Group). (2010, May) Avrora. [Online]. Available: http://compilers.cs.ucla.edu/avrora/ [42] B. Titzer, Avrora: The AVR simulation and analysis framework, Masters thesis, University of California, Los Angeles, 2004. [43] B. Titzer, D. Lee, and J. Palsberg, Avrora: Scalable sensor network simulation with precise timing, in Proceedings of the 4th international symposium on Information processing in sensor networks. IEEE Press Piscataway, NJ, USA, 2005. [44] Department of Computer Science at University of Illinois at Urbana-Champaign). (2010, May) J-Sim. [Online]. Available: http: //sites.google.com/site/jsimofcial [45] A. Sobeih, W. Chen, J. Hou, L. Kung, N. Li, H. Lim, H. Tyan, and H. Zhang, J-sim: A simulation environment for wireless sensor networks, in Proceedings of the 38th annual Symposium on Simulation. IEEE Computer Society Washington, DC, USA, 2005, pp. 175187. [46] J. Hou, L. Kung, N. Li, H. Zhang, W. Chen, H. Tyan, and H. Lim, J-Sim: A Simulation and emulation environment for wireless sensor networks, IEEE Wireless Communications Magazine, vol. 13, no. 4, pp. 104119, 2006. [47] Center for Satellite and Hybrid Communication Networks (CSHCN) at University of Maryland. (2010, May) Atemu. [Online]. Available: http://www.cshcn.umd.edu/research/atemu/ [48] J. Polley, D. Blazakis, J. McGee, D. Rusk, and J. Baras, Atemu: A ne-grained sensor network simulator, in Sensor and Ad Hoc Communications and Networks, 2004. IEEE SECON 2004. 2004 First Annual IEEE Communications Society Conference on, 2004, pp. 145 152. [49] Laboratory for Embedded Collaborative Systems (LECS) at UCLA. (2010, May) EmStar. [Online]. Available: http://www.lecs.cs.ucla.edu/ emstar/ [50] J. Elson, S. Bien, N. Busek, V. Bychkovskiy, A. Cerpa, D. Ganesan, L. Girod, B. Greenstein, T. Schoellhammer, T. Stathopoulos et al., Emstar: An environment for developing wireless embedded systems software, Center for Embedded Networked Sensing (CENS) Technical Report, vol. 9, 2003. [51] L. Girod, N. Ramanathan, J. Elson, T. Stathopoulos, M. Lukac, and D. Estrin, Emstar: A Software Environment for Developing and Deploying Heterogeneous Sensor Actuator Networks, Center for Embedded Network Sensing, p. 101, 2007. [52] Open Systems Laboratory at University of Illinois at UrbanaChampaign. (2010, May) SENS. [Online]. Available: http://osl.cs.uiuc. edu/sens/ [53] S. Sundresh, W. Kim, and G. Agha, SENS: A sensor, environment and network simulator, in Proceedings of the 37th annual symposium on Simulation. IEEE Computer Society Washington, DC, USA, 2004. [54] Computer Science Department at Rensselaer Polytechnic Institute (RPI). (2010, May) SENSE. [Online]. Available: http://www.ita.cs.rpi. edu/sense/ [55] G. Chen, J. Branch, M. Pug, L. Zhu, and B. Szymanski, Sense: A sensor network simulator, Advances in Pervasive Computing and Networking, pp. 249267, 2004. [56] SwarmNet project. (2010, May) Shawn. [Online]. Available: http: //shawn.sourceforge.net/ [57] A. Kroeller, D. Psterer, C. Buschmann, S. Fekete, and S. Fischer, Shawn: A new approach to simulating wireless sensor networks, Arxiv preprint cs/0502003, 2005. [58] S. Fekete, A. Kroller, S. Fischer, and D. Psterer, Shawn: The fast, highly customizable sensor network simulator, in Networked Sensing Systems, 2007. INSS07. Fourth International Conference on, 2007, pp. 299299.