Accurate power-aware simulation of wireless sensor networks considering real-life application code

Abstract

In this paper, we present a methodology to establish an accurate and power-aware simulation of wireless sensor networks. As the design of software applications running on resource-constrained sensor nodes mainly influences both timing and power consumption in the network, it is crucial to include these components in the simulation. Besides considering the software aspect in the network, it is also important to obtain a detailed and accurate power consumption profile of every hardware module present in the network. Our methodology extends the PAWiS framework, which builds upon the well known discrete event network simulator OMNeT++. The framework was extended to include natively executing real-life application code written in the C language. Using a time-annotation process brings the timing aspect of application code execution into the simulation, and therefore increases simulation accuracy. Moreover, the presented partitioning of the application code into software layers provides easy porting of the simulated code to real sensor nodes. This concept does not impose any restrictions with respect to the target platform used or the OS running on it. To demonstrate the functionality of this approach, the methodology was applied to a real-world networking test scenario, and the achieved simulation results were compared to real-world measurements. The performance of the simulation environment was evaluated and is presented.

Full text

Accurate Power-Aware Simulation of Wireless Sensor
Networks Considering Real-Life Application Code
Georg Möstl
moestl@riic.at
Richard Hagelauer
hagel@riic.at
Research Institute for Integrated Circuits
Johannes Kepler University
Linz, Austria
Andreas Springer
a.springer@nthfs.jku.at
Gerhard Müller
g.mueller@nthfs.jku.at
Institute for Communications and RF-Systems
Johannes Kepler University
Linz, Austria
ABSTRACT
In this paper, we present a methodology to establish an accu-
rate and power-aware simulation of wireless sensor networks.
As the design of software applications running on resource-
constrained sensor nodes mainly influences both timing and
power consumption in the network, it is crucial to include
these components in the simulation. Besides considering the
software aspect in the network, it is also important to obtain
a detailed and accurate power consumption profile of every
hardware module present in the network.
Our methodology extends the PAWiS framework, which
builds upon the well known discrete event network simu-
lator OMNeT++. The framework was extended to include
natively executing real-life application code written in the C
language. Using a time-annotation process brings the tim-
ing aspect of application code execution into the simulation,
and therefore increases simulation accuracy. Moreover, the
presented partitioning of the application code into software
layers provides easy porting of the simulated code to real
sensor nodes. This concept does not impose any restrictions
with respect to the target platform used or the OS running
on it.
To demonstrate the functionality of this approach, the
methodology was applied to a real-world networking test
scenario, and the achieved simulation results were compared
to real-world measurements. The performance of the simu-
lation environment was evaluated and is presented.
Categories and Subject Descriptors
C.2.1 [Computer-Communication Networks]: Network
Architecture and Design—Wireless communication; I.6.3 [Si-
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MSWiM’2010 October 17–21, 2010, Bodrum, Turkey.
Copyright 2010 ACM 978-1-4503-0274-6/10/10 ...$10.00.
mulation and Modeling]: Applications; I.6.8 [Simulation
and Modeling]: Types of Simulation—Discrete event
General Terms
Design, Verification
Keywords
Hardware/software/network co-simulation, power-aware si-
mulation, real-life code execution
1. INTRODUCTION
A network consisting of several resource-constrained sens-
ing devices, i.e. sensor nodes, that monitor any kind of
environmental condition (temperature, sound, acceleration,
etc.) and communicate by means of wireless transmission is
typically called a wireless sensor network (WSN). In the past
few years, the relevance of WSNs has increased, as they have
been employed in a growing range of application domains,
such as building automation, car-interior devices, car-to-car
communication, container monitoring and tracking, health-
related deployments, environmental monitoring, and indus-
try and military applications.
The development and evaluation of WSNs is a difficult
task due to the distributed nature and sheer number of
nodes (hundreds or thousands) contained in a single net-
work. Moreover, the nodes not only have limited processing
resources but also have stringent energy consumption re-
quirements. Since nodes must achieve lifetimes of several
years supplied by single batteries, obtaining a detailed pro-
file of the energy consumption of single modules within the
nodes is crucial for designers to tune and optimize these
blocks. These constraints make it unfeasible to model the
network analytically. Another important principle for eval-
uating WSNs is the use of physical testbeds. Although
testbeds are the most accurate method for developing and
evaluating sensor networks, they suffer from significant lim-
itations in terms of scalability (temporal and spatial dimen-
sions), diversity of operational scenarios, repeatability, cost
and effort. It is costly and troublesome to establish a net-
work consisting of hundreds of nodes, which influences di-
rectly the scale of the network used. Moreover, investigating

the behaviour of the network for long periods of time is im-
practical, as execution in testbeds cannot run faster than
real time. Some short tests may also take too long to allow
several repetitions, therefore making comparative analysis
difficult. Compared to simulations, physical testbeds are
constrained in terms of their input conditions. Considera-
tions such as these necessitate the use of simulation which
can overcome these limitations in the development and eval-
uation process of WSNs.
PAWiS [26] is a simulation framework supporting the de-
sign and evaluation of WSNs. The framework builds upon
the well known discrete event network simulator OMNeT++
[24] and makes it possible to capture node externals (net-
work, environment) and internals (modules). The main fea-
tures of the framework are:
•Power consumption capturing of software and hard-
ware modules of the node and hence support for their
power-optimization. Within a node, a hierarchy of
power consumers and suppliers with different electri-
cal characteristics (i.e. a simple electrical network) can
be established. In addition to pre-defined electrical be-
haviour (constant, resistive or linear), modules can also
have user-defined characteristics implemented in cus-
tom power reporters. As the current consumption of
the consumers influences the supply voltage and vice
versa, an iterative calculation approach with a user-
specified number of iterations is implemented.
•A clear separation between software and hardware tasks
which directly supports the hardware/software parti-
tioning of the system.
•Cross-level simulation, i.e. the modelling of nodes at
various abstraction levels. Therefore, the framework
can be used both at an early design stage (evalua-
tion of algorithms using abstract models) and at a late
design stage (validation of applications using detailed
models). Furthermore, the node models at different
abstraction levels can be used in one simulation.
•Mobility is supported by assigning a three-dimensional
position to every node in the network. Position and
other configuration parameters can be changed dynam-
ically during simulation using the embedded scripting
language LUA.
•RF communication considers interferers, noise and at-
tenuation due to distance and is independent of topol-
ogy or modulation format. With this approach, any
routing protocol and any type of modulation can be
modelled. Moreover, data transmission can be de-
scribed from the packet-level down to the bit-level.
•A notion of time, concurrency, structuring/modularity
and the specification of wait conditions (event/time)
are the fundamental concepts of hardware modelling
and are provided by PAWiS. Further, the framework
offers an abstract CPU model with support for inter-
rupts, which enables the development of applications
targeting microcontrollers.
Although PAWiS allows modelling a WSN at the network
and system level, it lacks the integration of real-life appli-
cation code into the simulation. From our point of view,
it is crucial that the simulation considers the timing and
power consumption issues of the application that will be
running on the nodes. In the following sections, a method-
ology is presented which eliminates this drawback and makes
possible a power-aware simulation of WSNs including time-
annotated real-life application code. This application code
can be ported easily to real sensor nodes.
The remainder of this paper is organised as follows: Sec-
tion 2 gives a comprehensive overview of related work done
so far. Our concept is introduced in section 3, application of
the concept and example simulation results are presented in
section 4. Section 5 comprises the conclusion of this paper
and future work.
2. RELATED WORK
Many tools are available that deal with the simulation of
networks and especially with the simulation of WSNs. A
comprehensive overview can be found in [6] and [4]. Since
determining the power consumption of nodes is one of the
crucial tasks when simulating and developing WSNs, only
those simulation environments are considered which offer
this power awareness.
Landsiedel et al. developed AEON [13], which builds upon
Avrora [23]. While Avrora offers cycle-accurate instruction-
level simulation of wireless sensor networks consisting of
AVR-based nodes, it does not have any power profiling mech-
anism. AEON integrates an energy model (i.e. pre-measured
current draws of each state of sensor node components) into
Avrora and extends the implementation of each emulated
hardware component by monitoring its power usage. With
a cycle-accurate simulation of real-life code, the setup is 50 %
slower compared to an operating-system-level emulation us-
ing TOSSIM [14]. In contrast, our approach is based on the
fastest possible way of simulating real-life code - native ex-
ecution. Further we use MSP430-based sensor nodes, which
are not supported by AEON.
PowerTOSSIM [21] is an extension of the TOSSIM simu-
lator and enables estimation of the energy consumption of
Mica2 network sensor nodes. TOSSIM is located at the op-
erating system abstraction level using TinyOS [15] and is
therefore highly scalable. This benefit comes at the price
of being bound to a specific platform, operating system and
language (i.e. NesC). The level of hardware abstraction cho-
sen to model device components in TOSSIM can result in in-
accurate energy consumption predictions by PowerTOSSIM.
In [8], Eriksson et al. presented a simulation-based tool
for power estimation at the network level. The system con-
sists of the COOJA [18] Java-based sensor network simula-
tor, the MSPSim [7] instruction level emulator of MSP430-
based sensor network nodes and a power profiler integrated
into the Contiki [5] operating system for tiny networked sen-
sors. The Contiki power profiler is based on a linear energy
model which uses pre-measured current consumption values
and the on/off times of the node components to estimate the
energy consumption. In addition to the fact that all appli-
cations must be based on the Contiki operating system, this
approach has a second serious drawback: the modelling of
external components, such as a transceiver module, as hav-
ing only two states (i.e. on and off). In our approach, every
hardware component can be modelled at an unconstrained
level of detail using several or no intermediate states.
Castalia [1] is an extension of OMNeT++ [24] that offers
energy-aware simulation using a simple resource manager
module [2]. Every module within the node can report its

actual energy consumption to the resource manager, which
subsequently subtracts linearly the consumed energy from
the battery. The purpose of Castalia is in the early-phase
algorithm and protocol design phase. This is reflected by the
abstract and highly tuneable modules (e.g. MAC), which
enable high scalability and simulation performance with the
drawbacks of lacking (i) timing accuracy of interrupt prop-
erties and (ii) the inclusion of real-life application code.
Nguyen et al. [17] presented a SystemC-based cycle-
accurate simulator for wireless body area networks (BSN).
The simulator contains a model of the MSP430 microcon-
troller architecture and executes application code written in
NesC and compiled with TinyOS. A power monitor module
is added to monitor and accumulate the energy consumed
by each component in the BSN node. A serious drawback,
besides the fact that one is bound to NesC and a special op-
erating system, is the absence of any channel model in the
simulator.
SensorSim [19] is a simulator for sensor networks and
builds upon a NS-2 [16] 802.11 network model. Although
the authors added a power, battery and CPU model the high
level of abstraction results in inaccurate and coarse-grained
approximations. Another drawback is that the developers
have withdrawn the public release of the SensorSim suite
of tools because of the ”unfinished nature of the software”
(http://nesl.ee.ucla.edu/projects/sensorsim/).
Varshney et al. developed sQualNet [25], a simulation and
emulation environment for WSNs building upon the com-
mercial network simulator QualNet [22]. In this environ-
ment, a kind of co-simulation of the discrete event network
simulator (DENS) and the emulated sensor node using an
operating system (OS) is established. Although the prin-
ciple is not limited to a special OS, it is a tricky task to
implement a well maintained interface between the DENS
and the OS (as shown for the SOS [10]), which directly in-
fluences simulation performance.
In [9], Fummi et al. presented an energy-aware hardware/
software/network simulation setup targeting the AquisGrain-
2 node. TinyOS-based application code is executed on an
instruction set simulator (µCSim), while hardware and net-
work components are modelled in SystemC and executed
by the SystemC simulation kernel. The transceiver is ab-
stracted to a finite state machine model of the IEEE 802.15.4
MAC protocol with specified energy consumption for each
state.
Our approach differs from the aforementioned simulation
environments in several ways. Firstly, we use native exe-
cution of real-life application code in the simulation. This
approach in combination with a homogeneous simulator pro-
vides the fastest possible simulation principle. Secondly, ar-
bitrary application code can be simulated, i.e. there is no
need to use an underlying operating system on the target
platform. Thirdly, building upon the sophisticated energy
model of PAWiS (see section 1), it is possible to obtain a
power consumption profile of every hardware and software
module in the network. Fourthly, including time-annotated
real-life code in the simulation yields an accurate timing
and power evaluation of the system. Finally, the presented
methodology allows modelling the network at different ab-
straction levels and running cross-level models of the nodes
in one simulation.
Application
HAL ... Hardware Abstraction Layer
HAL_CC2500
HAL_CC2420
HAL_CC1100
HAL_DIGIO
HAL_TIMER
HAL_AD
HAL_SPIHAL_RS232
HAL_MCU
HAL_BOARD
HIL ... Hardware Interface Layer
HIL_RS232
HIL_ERROR
HIL_BUFFER HIL_UTILS HIL_RF
hardware
dependent
hardware
independent
Figure 1: Software architecture
3. METHODOLOGY
The methodology developed targets mainly the software
side of simulation, as the modelling principles of hardware
components are already provided by the PAWiS framework.
Portability of source code, execution time of application
code and the linkage between native and simulation envi-
ronments are the main issues addressed by the established
methodology.
3.1 Software architecture
Code portability is a key issue in the development of ap-
plications, particularly when the targeted platform is a mi-
crocontroller. This is due to the huge variety of micro-
controllers, which differ not only between vendors but also
within the product families of individual vendors.
In our case, in addition to the different microcontroller
architectures, there is another target platform - the simu-
lation. Seamless porting of the application between these
platforms can only be achieved by a software architecture
which splits the code into a hardware/platform-dependent
and hardware/platform-independent part. As shown in Fig-
ure 1, this is accomplished by using different software layers.
The hardware abstraction layer (HAL) comprises the
platform-dependent code for various hardware modules. For
example, the initialisation of a serial peripheral interface
(SPI) module varies between different microcontrollers and
is therefore encapsulated in the HAL SPI block, which is
part of the HAL. The implementation of such a block is
split into an interface declaration and a behaviour defini-
tion using the concept of header and source files offered
by the C language. As a result, switching to another plat-
form is as simple as exchanging the behaviour (i.e. the C
source file) of the HAL SPI block, while the interface to
the upper layers and to other HAL modules remains un-
changed. Currently, HAL implementations are available for
MSP430FG4618, MSP430F2274 and the PIC18x microcon-
troller families.
The hardware interface layer (HIL) supports hardware in-
dependency at a higher abstraction level and therefore pro-
vides higher reusability. An integral part of the HIL is an

error detection mechanism that gives feedback to the appli-
cation. In summary, the HAL implements functions which
are supported directly by the hardware, while the HIL uses
them to serve as a module handler for the application.
On top of the HAL and HIL is the application, which can
be an arbitrary software component ranging from a rather
simple send/receive application utilizing low-level HAL func-
tionality to an operating system with an integrated network
stack.
The advantage of this layered structure is that a platform
change requires only exchanging the HAL, while the HIL
and application remain untouched.
3.2 Creating shared libraries
The structured application code (application, HAL and
HIL) is used to build shared libraries, which are then linked
with the shared libraries of the simulator to form the simu-
lation executable. This approach keeps the build environ-
ments for the real-life application and the simulator appro-
priately separated. Compile- and link-time settings as well
as external dependencies of the application can be retained.
Moreover, the simulator build process can be carried out
with different compiler and linker settings.
Every node in the network utilizes one shared library for
the application code running on it. Therefore, it is possible
to define different preprocessor constants for different ap-
plications, which enables powerful conditional compilation.
For example, if Node1 uses a CC2500 module and the corre-
sponding API for running an application, but Node2 needs
a CC2420 API, all one has to do is to include the switch
“-DCC2500”or“-DCC2420”in the compilation scripts. These
scripts are generated automatically from a list of prepro-
cessor constants and a list of source files specified in a text
file. As stated above, HAL files targeting the microcontroller
must not be used in simulations, i.e. they are excluded from
the build step by not listing them in the text files. Instead,
HAL source files corresponding to the simulation are speci-
fied in the text files.
To avoid name clashes between the linked application li-
braries, every library has its own namespace. Namespaces
are created automatically during the compilation step, using
macros and preprocessor constants defined in scripts.
3.3 Annotating the application code
Distinguishing between wall-clock time and simulation time,
native execution of application code takes zero simulation
time. To run a timing-accurate simulation, synchronisa-
tion between natively executed code and network simulation
is necessary. This is achieved by the global function re-
quireCpu() provided by the Glue Logic module. Calling this
function suspends native execution of tasks and gives con-
trol to the simulation kernel by using PAWiS functionality.
When the specified simulation time period has expired, the
suspended task is reactivated.
Although it is possible to annotate the application source
code at a very fine-grained single statement level, the advan-
tage of the annotation approach lies in summarizing state-
ments into blocks which are then annotated. This gives
block-level annotation and avoids an unnecessary increase
in the amount of events dispatched to the simulation ker-
nel by the annotation process. Furthermore, the annotation
is made before the simulation is executed. Therefore, the
Glue Logic
µC App
DigIO
SPI
TIMER[1]
TIMER[2]
RFMOD
CPU SUPPLY
simulation environmentnative environment
Node
Figure 2: Node structure
time taken to annotate the application code with calls to
requireCpu() does not affect simulation performance.
Besides the time values, which are related to a norm CPU,
a profile of the code block classified into integer, float, mem-
ory and control operations can be specified. These formal
parameters can be used in requireCpu() to scale execution
time with respect to the structure of the targeted CPU. For
example, if a microcontroller has a built-in floating point
unit, the execution time of such statements decreases in com-
parison to the norm CPU.
To determine the execution time of several lines of C code,
a macro is provided. It uses “C code to assembler” and “as-
sembler to clock cycles” ratios together with the specified
clock period to compute the time parameters. As the an-
notation process is external to the simulation environment,
different and more accurate estimation techniques can be
utilized. For instance, in [3], a mathematical model for
source-code-based analysis of execution time was presented.
3.4 Glue Logic
Figure 2 shows the structure of a WSN node model with
the application, which is executed natively, on the left side
and the modelled hardware modules, which are interpreted
by the simulator, on the right side. Between these two
worlds resides the Glue Logic, which links them together.
Although these modules are described at a high level of ab-
straction using C++, they reflect reality accurately with
respect to the functional, timing and power consumption
behaviours.
Communication between Glue Logic and hardware mod-
ules is achieved by means of PAWiS functional interfaces,
which build upon the OMNeT++ message passing system.
A tighter coupling between application and Glue Logic is
achieved by function calls. The same holds true for connec-
tions to the CPU and supply module. The structure and
connections of a node are specified by network description
(NED) files as supported by OMNeT++.
Glue Logic must accomplish four main tasks. Firstly, a
database of registered interrupts and pins (in/out) is con-
tained in the module. Every hardware module registers its
symbolic names used for interrupts or pins during the ini-
tialisation step of PAWiS to the Glue Logic. The mapping
of symbolic names to names used by the application is speci-
fied in the NED file or in the initialisation file of OMNeT++.
This yields greater flexibility of the simulation setup. For
example, a transceiver model (e.g. CC2500) can be writ-

onInit() {
startTask(mainTask);
}
mainTask() {
// 1. fetch NED params
// 2. load library (dlopen)
// 3. fetch app (dlsym)
// 4. call app
}
GlueLogic LUA, NED, ".ini"
mainApp() {
...
}
Application
simple GlueLogic
parameters:
LibName : string,
AppName : string,
...
Figure 3: Start of application
ten for the symbolic name GDO2 and can be used in con-
junction with an application which expects PORT2.7 to be
used. Changing either the hardware module (e.g. GDO2 →
GDO5) or the application (e.g. Port2.7 →Port4.3) leads
only to a change in the initialisation parameters in the si-
mulation.
Secondly, Glue Logic also provides interrupt handling, since
the module serves as a wrapper for interrupt service routines
(ISR). Every interrupt is linked to this wrapper in the initial-
isation phase of the hardware modules. After an interrupt
occurs, the isrWrapperTask() method in the Glue Logic is
started, and subsequently calls the corresponding ISR of the
application code. The interrupt behaviour resembles that of
real hardware, i.e. application execution is suspended, the
ISR is executed and afterwards application execution is re-
sumed. Nested interrupts are also supported.
Thirdly, the Glue Logic of each node is responsible for
starting the application, as depicted in Figure 3 using pseudo
code. In the initialisation step, PAWiS calls the onInit()
method of every module contained in the simulation en-
vironment. In this method, a new task is started, which
subsequently fetches the name of the library containing the
application and the name of the application to execute on
this node from the NED file. These parameters can be set
directly in the NED description, in the initialisation file of
OMNeT++ or using LUA scripts. After dynamically load-
ing the library and fetching the application symbol name,
the application is started.
Finally, Glue Logic delegates calls from the application
code to the corresponding hardware modules through PAWiS
functional interfaces. An example in which the application
writes data over an SPI connection is given in Figure 4.
The application calls the corresponding API function of the
SPI HAL block. Porting of the SPI HAL block to the simu-
lation platform forwards this call to the Glue Logic module,
which invokes the functional interface of the required SPI
hardware module.
4. EXPERIMENTS AND RESULTS
To demonstrate the functionality and usefulness of the
presented methodology, we applied it to a real-world test
scenario. In the first step, the accuracy of the simulation
environment was evaluated, while in the second step the
network size was boosted to investigate the simulation per-
formance.
invoke(FI m) {
mainTask->PAWiS.invoke(m);
}
GlueLogic
mainApp() {
writeToSpi();
}
Application
writeToSpi() {
gl->invoke(writeToSpi);
}
SPI_HAL
SPI
function, delay, power
Figure 4: Delegation of application calls
The simulation setup consisted of PAWiS v2.0 and OM-
NeT++ v3.3. Simulation executables were built using the
GNU compiler collection (GCC v4.2) and GNU make v3.81.
4.1 Accuracy evaluation
The scenario used consisted of a sensor node sending data
packets regularly to a base station, which writes the RSSI
(received signal strength indicator) value of each correctly
received packet (CRC check is good) to an RS232 interface.
In practice, the base station would be connected to a PC,
which would process the RS232 bytes further. As this is
beyond the scope of the simulation, the RS232 data is logged
to a text file by the RS232 hardware module.
Both the sensor and the base station node used a CC2500
transceiver module, which was modelled in rich detail (using
fsm, fifos, registers, etc.). As in reality, this model must
be accessed through SPI commands and triggers interrupts
on the GDOx pins. This ensures easy portability of the
application code between simulation and real sensor nodes.
Using a toggling LED, the sensor node displays successfully
sent packets.
This simple scenario assembled of two nodes was chosen
because it allows real measurements of the network compo-
nents and comparison of simulated and measured data to be
made easily.
PAWiS logs the power consumption of all specified mod-
ules to a single text file in a proprietary format. Octave
(v3.0) scripts are provided which process this file and, using
Gnuplot (v4.2.2), plot the power consumption of individ-
ual modules. Special filter phrases for module names and a
time-range for plotting can be specified. Therefore, it is pos-
sible to obtain a detailed power consumption profile of every
component in the network, which subsequently enables the
developer to optimize power-inefficient blocks.
Figure 5 shows, for example, the simulated power con-
sumption of the RF module voltage regulator at the base
station in the simulation time-range between 1.078 s and
1.081 s. After a packet consisting of 2 bytes of preamble, a 4-
byte synchronisation word, 2 bytes payload and 2 bytes CRC
has been received successfully using 2-FSK modulation at a
datarate of 2.4 kBaud, the CC2500 transceiver switches from
the receive state (RX state) to the IDLE state. Thus, power
consumption drops to 4.5 mW (at 1.0792 s). To further re-
ceive packets, the application triggers an SRX strobe on the
SPI, which causes a state change from IDLE (through sev-
eral intermediate states) to RX. Consequently, power con-

5
10
15
20
25
30
35
40
1.078 1.0785 1.079 1.0795 1.08 1.0805 1.081
Power Consumption [mW]
Time [s]
Node1::supply.cc2500ldo
Figure 5: Simulated power consumption of RF mod-
ule
Figure 6: Measured current consumption of RF
module (200 µs/div; 200 mV/div)
sumption rises to approximately 43 mW. Achieving such a
detailed analysis is only possible using a sophisticated sys-
tem model of the transceiver, i.e. one that reflects every
possible state of the module. Another important point is to
have realistic current consumption values for the different
operating states of the transceiver. In our case, these values
were extracted from the CC2500 datasheet [11] for a supply
voltage of 3.0 V.
For validation purposes, real-world measurements of the
transceiver were taken, which are depicted in Figure 6. The
figure shows the measured current consumption, i.e. the
voltage drop measured across a 74.99 Ωresistor, of the RF
module voltage regulator at the base station for the above
described scenario and state changes. Given the supply volt-
age of 3.0 V and the current consumption, the power con-
sumption in different states can be calculated.
Comparing Figure 5 and Figure 6 reveals that the simu-
lation confirms the measurements not only regarding the
power consumption aspect but also concerning the timing
aspect, i.e. the sequence of state changes matches.
Besides detailed analysis of the power consumption of sin-
gle modules in the network, it is important to quickly iden-
tify the dominant power consumers. For this purpose, an-
other Octave script was developed which visualizes the en-
ergy consumption of all modules contained in a node. This
0
10
20
30
40
50
1 2 3 4 5 6
Energy Consumption [%]
Energy Consumption in [1.07s, 1.09s]
Node1::rfmod
Node1::spi
Node1::rs232
Node1::cpu
Node1::timer
Node1::led
Figure 7: Energy consumption of modules - unopti-
mized
0
10
20
30
40
50
60
70
80
90
1 2 3 4 5 6
Energy Consumption [%]
Energy Consumption in [1.07s, 1.09s]
Node1::rfmod
Node1::spi
Node1::rs232
Node1::cpu
Node1::timer
Node1::led
Figure 8: Energy consumption of modules - opti-
mized
also provides an efficient means of validating different energy
optimizing techniques.
Figure 7 visualizes the energy consumption of all consum-
ing modules contained in the base station (i.e. Node1) re-
lated to the total amount of energy consumed by the node
(in a specified time interval). The base station was equipped
with the Texas Instruments MSP430FG4618 microcontroller
[12]. As shown in the figure, the CPU of Node1 consumes
approximately 43 % of the total energy consumed in the
time-range between 1.07 s and 1.09 s.
Inspecting the application source code reveals that a busy
polling approach was implemented, which leads to this enor-
mous amount of unnecessary energy waste. A simple but
efficient solution is to set the microcontroller to a low-power
state until a new packet is received. Since the sending pe-
riod is relatively long and consequently the waiting period
of the receiver, this holds high energy saving potential. An
example in which the low-power mode LPM0 of the MSP430
architecture was utilized in the application code is shown in
Figure 8. Setting the microcontroller to sleep mode causes
the energy consumption in the specified time interval to drop
to less than 10 %.

Figure 9: Simulator performance - runtime
4.2 Performance analysis
To evaluate the performance of the extended simulation
environment, the two-node scenario was boosted to include
dozens and hundreds of nodes. For reasons of simplicity,
we used the same application as for the accuracy evalua-
tion, i.e. there is one data sink (the base station), which
receives data from a large number of data sources (the sen-
sor nodes). Whereas the base station is positioned in the
middle, the sensor nodes are distributed uniformly in a 100
x 100 m2area. This setup ensures that each node can dis-
turb the transmission of every other node in the network
and therefore yields high network traffic.
The runtime of the simulation was determined using the
Linux time command and reflects the sum of CPU-seconds
the process used directly (user mode) and the number of
CPU-seconds used by the system on behalf of the process
(kernel mode). Simulation runs were executed on an Intel
Core 2 Duo processor with 2.66 GHz and 3.2 GByte RAM.
Simulation libraries and executables were built with support
for debugging and with optimization turned off.
Figure 9 shows the number of real-time seconds it takes
per simulation-time second as a function of the number of
nodes in the sensor network. As the graph shows, the time it
takes to simulate a single second of the above described sce-
nario using the presented simulation environment increases
exponentially with respect to the network size, i.e. the num-
ber of nodes contained in the network. This is largely a
consequence of the task management and the interference
model implemented in the PAWiS framework. PAWiS uses
a global list to keep track of the pending tasks in the simu-
lation model, which has to be iterated over for each event in
the simulation. The second performance issue is related to
the fact, that transmissions can possibly interfere with each
other in the network. Therefore PAWiS has to deal with
an n-squared algorithm to keep track of transmissions and
received powers. Other WSN simulators, such as ATEMU
[20], which utilize a similar interference model also suffer
from this problem.
Importantly, the inherent exponential increase in the si-
mulation runtime is not related to our extensions to the
PAWiS framework. The number of events dispatched to
the simulation kernel increases only linearly, although the
hardware components of the system were modelled in great
Figure 10: Simulator performance - processed
events
detail, the timer module of the sensor node triggers inter-
rupts every 1 ms, and the time-annotation of the application
code introduces additional events to the simulation. This is
shown in Figure 10, where the number of events processed
by the OMNeT++ kernel is related to the number of nodes
present in the network.
5. CONCLUSIONS AND FUTURE WORK
In this paper, we have presented an approach to estab-
lishing a power-aware simulation of wireless sensor networks
with nodes running real-life applications. Using a homoge-
neous simulation environment with only one simulation en-
gine and natively executing time-annotated source code al-
lows fast simulations at a high simulation accuracy. Separat-
ing between platform-dependent and platform-independent
code as offered by the presented software architecture sup-
ports easy porting to real sensor nodes. Furthermore, the
presented methodology makes no assumptions about the un-
derlying platform or operating system and is therefore flex-
ible enough to target different architectures. The concept
was applied to a real-world networking test scenario and
simulation results and real-world measurements were pre-
sented. Evaluation results regarding the performance of
the presented simulation framework were shown and per-
formance issues were discussed.
Future work will include (i) increasing the simulation per-
formance by means of a more local task management and
(ii) improving the PAWiS channel model to solve the inher-
ent n-squared problem and to address large-scale and small-
scale fading effects. Moreover, the accuracy of the time-
annotation process will be increased using time estimations
based on compiled code. Subsequently, the simulation envi-
ronment will be used to develop energy-optimized protocols
for real-time industrial applications using WSNs.
6. ACKNOWLEDGEMENTS
This work was funded by the COMET K2 Center “Aus-
trian Center of Competence in Mechatronics (ACCM)”. The
COMET Program is funded by the Austrian Federal govern-
ment, the Federal State of Upper Austria and the Scientific
Partners of ACCM.

7. REFERENCES
[1] Castalia a simulator for wsn, April 2010.
http://castalia.npc.nicta.com.au.
[2] A. Boulis. Castalia User’s Manual, October 2009.
http://castalia.npc.nicta.com.au/documentation.php.
[3] C. Brandolese, W. Fornaciari, F. Salice, and D. Sciuto.
Source-level execution time estimation of c programs.
Hardware/Software Co-Design, International
Workshop on, 0:98, 2001.
[4] W. Du, D. Navarro, F. Mieyeville, and F. Gaffiot.
Towards a taxonomy of simulation tools for wireless
sensor networks. In Proceedings of 3rd International
ICST Conference on Simulation Tools and Techniques,
March 2010.
[5] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a
lightweight and flexible operating system for tiny
networked sensors. In Local Computer Networks, 2004.
29th Annual IEEE International Conference on, pages
455 – 462, nov. 2004.
[6] E. Egea-Lopez, J. Vales-Alonso, P. Martinez-Sala,
P. Pavon-Marino, and J. Garcia-Haro. Simulation
tools for wireless sensor networks. In Proceedings of
International Symposium on Performance Evaluation
of Computer and Telecommunication Systems USA,
July 2005.
[7] J. Eriksson, A. Dunkels, N. Finne, F. Osterlind, and
T. Voigt. Mspsim - an extensible simulator for
msp430-equipped sensor boards. In Proceedings of the
European Conference on Wireless Sensor Networks
(EWSN), Poster/Demo session, Delft, The
Netherlands, January 2007.
[8] J. Eriksson, F. ¨
Osterlind, N. Finne, A. Dunkels,
N. Tsiftes, and T. Voigt. Accurate network-scale
power profiling for sensor network simulators. In
EWSN ’09: Proceedings of the 6th European
Conference on Wireless Sensor Networks, pages
312–326, Berlin, Heidelberg, 2009. Springer-Verlag.
[9] F. Fummi, G. Perbellini, D. Quaglia, and
A. Acquaviva. Flexible energy-aware simulation of
heterogenous wireless sensor networks. In Design,
Automation Test in Europe Conference Exhibition,
2009. DATE ’09., pages 1638 –1643, april 2009.
[10] C.-C. Han, R. Kumar, R. Shea, E. Kohler, and
M. Srivastava. A dynamic operating system for sensor
nodes. In MobiSys ’05: Proceedings of the 3rd
international conference on Mobile systems,
applications, and services, pages 163–176, New York,
NY, USA, 2005. ACM.
[11] T. Instruments. CC2500 Low-Cost Low-Power 2.4
GHz RF Transceiver, swrs040b edition, September
2005. focus.ti.com/lit/ds/symlink/cc2500.pdf.
[12] T. Instruments. MSP430xG461x MIXED SIGNAL
MICROCONTROLLER, slas508g edition, April 2006.
[13] O. Landsiedel, K. Wehrle, and S. Gotz. Accurate
prediction of power consumption in sensor networks.
In Embedded Networked Sensors, 2005. EmNetS-II.
The Second IEEE Workshop on, pages 37 – 44, may
2005.
[14] P. Levis, N. Lee, M. Welsh, and D. Culler. Tossim:
accurate and scalable simulation of entire tinyos
applications. In SenSys ’03: Proceedings of the 1st
international conference on Embedded networked
sensor systems, pages 126–137, New York, NY, USA,
2003. ACM.
[15] P. Levis, S. Madden, D. Gay, J. Polastre, R. Szewczyk,
A. Woo, E. Brewer, and D. Culler. The emergence of
networking abstractions and techniques in tinyos. In
NSDI’04: Proceedings of the 1st conference on
Symposium on Networked Systems Design and
Implementation, pages 1–1, Berkeley, CA, USA, 2004.
USENIX Association.
[16] S. McCanne and S. Floyd. The network simulator -
ns-2, April 2010. http://www.isi.edu/nsnam/ns/.
[17] K. Nguyen, I. Cutcutache, S. Sinnadurai, S. Liu,
C. Basol, E. Sim, L. T. X. Phan, T. B. Tok,
L. Francis, E. H. Tay, T. Mitra, and W.-F. Wong. Fast
and accurate simulation of biomonitoring applications
on a wireless body area network. In Medical Devices
and Biosensors, 2008. ISSS-MDBS 2008. 5th
International Summer School and Symposium on,
pages 145 –148, june 2008.
[18] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and
T. Voigt. Cross-level sensor network simulation with
cooja. In Local Computer Networks, Proceedings 2006
31st IEEE Conference on, pages 641 –648, nov. 2006.
[19] S. Park, A. Savvides, and M. B. Srivastava. Sensorsim:
a simulation framework for sensor networks. In
MSWIM ’00: Proceedings of the 3rd ACM
international workshop on Modeling, analysis and
simulation of wireless and mobile systems, pages
104–111, New York, NY, USA, 2000. ACM.
[20] J. Polley, D. Blazakis, J. McGee, D. Rusk, and
J. Baras. Atemu: a fine-grained sensor network
simulator. In Sensor and Ad Hoc Communications and
Networks, 2004. IEEE SECON 2004. 2004 First
Annual IEEE Communications Society Conference on,
pages 145 – 152, oct. 2004.
[21] V. Shnayder, M. Hempstead, B.-r. Chen, G. W. Allen,
and M. Welsh. Simulating the power consumption of
large-scale sensor network applications. In SenSys ’04:
Proceedings of the 2nd international conference on
Embedded networked sensor systems, pages 188–200,
New York, NY, USA, 2004. ACM.
[22] S. N. Technologies. Qualnet, April 2010.
http://www.scalable-networks.com.
[23] B. Titzer, D. Lee, and J. Palsberg. Avrora: scalable
sensor network simulation with precise timing. In
Information Processing in Sensor Networks, 2005.
IPSN 2005. Fourth International Symposium on,
pages 477 – 482, april 2005.
[24] A. Varga. The OMNeT++ discrete event simulation
system. Proceedings of the European Simulation
Multiconference (ESM’2001), June 2001.
[25] M. Varshney, D. Xu, M. Srivastava, and R. Bagrodia.
squalnet: A scalable simulation and emulation
environment for sensor networks. In Proceedings of the
International Conference on Information Processing in
Sensor Networks, New York, NY, USA, 2007. ACM.
[26] D. Weber, J. Glaser, and S. Mahlknecht. Discrete
event simulation framework for power aware wireless
sensor networks. In Industrial Informatics, 2007 5th
IEEE International Conference on, volume 1, pages
335–340, June 2007.