OPERATING SYSTEMS FOR

WIRELESS SENSOR NETWORKS: AN OVERVIEW

Daniele De Caneva, Pier Luca Montessoro and Davide Pierattoni

DIEGM – University of Udine, Italy
{daniele.decaneva; montessoro; pierattoni}@uniud.it

ABSTRACT

The technological trend in the recent years has led to the emergence of complete
systems on a single chip with integrated low power communication and transducer
capabilities. This has opened the way for wireless sensor networks: a paradigm of
hundreds or even thousands of tiny, smart sensors with transducer and
communication capabilities. Manage such a complex network that has to work
unattended for months or years, being aware of the limited power resouces of
battery-supplied nodes is a challenging task. Attending that task requires an
adequate software platform, in other words an operating system specifically suited
for wireless sensor networks. This paper presents a brief overview of the most
known operating systems, highlighting the key challenges that have driven their
design.

Keywords: wireless sensor networks, operating systems.

1 INTRODUCTION the most known operating systems designed for

Thanks to the well known “Moore’s Law”
integrated circuits are becoming smaller, cheaper
and less power consuming. This trend has led to the
emergence of complete systems on a chip with
integrated low power communication and
transducer capabilities. The consequence is the
opening of the ubiquitous computing era, in which
electronic systems will be all around us, providing
all kind of information services to users in a
distributed, omnipresent but nearly invisible fashion.
One of the most important applications that new
technologies are enabling is the paradigm of
Wireless Sensor Networks (WSNs), where
hundreds or even thousands of tiny sensors with
communication capabilities will organize
themselves to collect important environmental data
or monitor areas for security purposes.
The hardware for WSNs is ready and many
applications have become a reality, nevertheless the
missing of a commonly accepted system
architecture and methodology constitute a curb to
the expansion and the improvement of such
technologies. Aware of that, many research groups
in the world have proposed their own system
architecture. The key point in all these proposals is
the capability of the software to manage a
considerable number of sensors. In particular, there
is a tradeoff between the responsiveness of the
system and the extremely scarce resources of the
nodes in terms of power supply, memory and
computational capabilities.
In this article will be presented an overview of
WSNs. Without proposing direct comparisons, we
describe the key features of these architectures, the
challenges that led their development, with the aim
of helping the reader to choose among these
systems the one that best suites his/her purposes.
2 OVERVIEW
2.1 TinyOS
TinyOS [1] is virtually the state-of-the-art of
sensor operating systems. Berkeley University
researchers based their work aiming to face two
issues: the first was to manage the concurrency
intensive nature of nodes which need to keep in
movement different flows of data simultaneously,
while the second was to develop a system with
efficient modularity but believing that hardware and
software components must snap together with little
processing and storage overhead. The purpose of
the researchers was also to develop a system that
would easily scale with the current technology
trends, supporting smaller devices as well as the
crossover of software components into hardware.
Considering power as the most precious
resource and trying to achieve high levels of
concurrency, the system was designed following an
event-based approach, which avoids reserving a
stack space for each execution context. This design
guideline was drawn from a parallelism with high
performance computing, where event-based
programming is the key to achieve high
performance in concurrency intensive applications.

Ubiquitous Computing and Communication Journal 1

In TinyOS neither blocking nor polling operation is
permitted and the CPU doesn’t waste time in
actively looking for interesting events; on the
contrary, unused CPU cycles are spent in a sleep
state.
System configuration can be summarized in a
tiny scheduler and a set of components. The
scheduler is a simple FIFO utilizing a bounded size
scheduling data structure for efficiency, nonetheless
a more sophisticated scheduling policy could be
implemented. When the task queue is empty, the
CPU is forced to the sleep state waiting for an
hardware event to trigger the scheduling of the
event-associated tasks. Tasks in the TinyOS
architecture are atomic and run to completion
although they can be preempted by events. This
semantics of tasks allows the allocation of a single
stack, which is an important feature in memory
constrained systems.
Three types of components were thought to
constitute the TinyOS architecture. The first type of
components are the “hardware abstraction” which
map physical hardware like I/O devices into
component models. The second type of components
is called “synthetic hardware” and simulates the
behavior of advanced hardware; often synthetic
hardware sits on top of the hardware abstraction
components. The last type of components are the
“high level software” components, which perform
control, routing and all data transformations such as
data aggregation and manipulation. This kind of
abstraction of hardware and software in the
component model is intended to ease the
exploitation of tradeoffs between the scale of
integration, the power requirements and the cost of
the system. Every component owns a fixed-size
frame that is statically allocated: this allows to
know exactly the memory requirements of a
component at compile time and prevents the
overhead associated with dynamic allocation.
TinyOS was originally developed in C, giving
the system the capability of targeting multiple CPU
architectures. However, the system was afterwards
re-implemented in nesC: this is a programming
language specific for networked embedded systems,
whose key focus is holistic approach in design.
It’s remarkable that for TinyOS a byte-code
interpreter has been developed that makes the
system accessible to non-expert programmers and
enables quick and efficient programming of a
whole WSN. This interpreter, called Maté, depicts
the program’s code as made of capsules. Thanks to
the beaconless, ad-hoc routing protocol
implemented in Maté, when a sensor node receives
a newer version of a capsule, it will install it.
Through a hop-by-hop code injection, Maté can
update the code of the entire network.
Ubiquitous Computing and Communication Journal
2.2 MANTIS
The MultimodAl system for NeTworks of In-
situ wireless Sensors [3] was developed focusing on
two design key: the need for a small learning curve
for users and the need for flexibility. The first
objective led to fundamental choices in the
architecture of the system and the programming
language used for its implementation. In fact, to
lower the entry barrier the researchers decided to
adopt a largely diffuse design methodology, that is,
the classical structure of a multithreaded operating
system. For this reason MANTIS includes features
like multithreading, preemptive scheduling with
time slices, I/O synchronization via mutual
exclusion, and standard network stack and device
drivers. The second choice is associated with the
purpose of flattening the learning curve for users
and determinates the use of standard C as
developing language for the kernel and the API.
The choice of C language additionally entails the
cross-platform support and the reuse of a vast
legacy code base.
MANTIS kernel resembles UNIX-style
schedulers providing services for a subset of
POSIX threads along with priority based scheduling.
The thread table is allocated statically, so it can be
adjusted only at compile time. The scheduler
receives notes to trigger context switches from an
hardware timer interrupt. This interrupt is the only
kind of hardware interrupt handled by the kernel: in
fact all the others interrupts are sent directly to
device drivers. Context switches are triggered not
only by timer events but also by system calls or
semaphore operations. Besides drivers and user
threads, MANTIS has a special idle, low-priority
thread created by the kernel at startup. This thread
could be used to implement power-aware
scheduling: thanks to its position, it can detect
patterns of CPU utilization and adjust kernel
parameters to conserve energy.
MANTIS researchers thought that wireless
networking management was a critical matter, so
they developed the layered network stack as a set of
user level threads. In other words, they
implemented different layers in different threads
advocating that this choice promotes flexibility to
the detriment of performance. This flexible
structure is useful in particular for dynamic
reprogramming, because it enables application
developers to reprogram network functionalities
such as routing by simply starting, stopping and
deleting user-level threads.
Drawing from the experience in WSNs, the
developers of MANTIS gave their system a set of
sophisticated features like dynamic reprogramming
of sensors nodes via wireless communication,
remote debugging and multimodal prototyping.
MANTIS prototyping environment provides a
framework for testing devices and applications
2
across heterogeneous platforms. It extends beyond
simulation permitting the coexistence of both
virtual and physical nodes in the same network.
This feature is derived directly by the system code
architecture, which can run without modifications
on virtual nodes within an x86 architecture.
Dynamic reprogramming in MANTIS is
implemented as a system call library, which is built
into the kernel. There are different granularities of
reprogramming: entire kernel reflashing,
reprogramming of a single thread, changing of
variables within the thread. Along with dynamic
reprogramming, an important feature has been also
developed: the Remote Shell and Command Server
which allows the user “logging in” into a node and
taking control of it. The server is implemented as an
application thread and gives the user the ability to
alter node’s configuration, run or kill programs,
inspect and modify the inner state of the node.
2.3 Contiki
Contiki is an operating system based on a
lightweight event-driven kernel. It was developed
drawing from previous operating systems’ works
with the goal of adding features like run-time
loading and linking of libraries, programs and
device drivers, as well as support for preemptive
multithreading.
Event-based systems have shown good
performance for many kind of WSN’s applications;
however, purely event-based systems have the
penalty of being unable to respond to external
events during long-lasting computations. A partial
solution to this problem is adding multithreading
support to the system, but this would cause
additional overhead. To address these problems
Contiki researchers have done the compromise of
developing an event-driven kernel and
implementing preemptive multithreading features
as a library, which is optionally linked with
programs that explicitly require it.
Contiki operating system can be divided in three
main components: an event driven kernel that
provides basic CPU multiplexing and has no
platform-specific code, a program loader and
finally a set of libraries that provide higher level
functionalities.
From a structural point of view, a system
running Contiki can be partitioned in two parts: a
core and a set of loadable programs. The core is
compiled into a single binary image and is
unmodifiable after nodes’ deployment. The
programs are loaded into the system by the program
loader, which may obtain the binaries either from
the communication stack (and thus from the
network) or from the system’s EEPROM memory.
Shared libraries like user programs may be
replaced in deployed systems by using the dynamic
Ubiquitous Computing and Communication Journal
linking. Dynamic linking is based on synchronous
events: a library function is invoked by issuing an
event generated by the caller program. The event
broadcasts the request to all the libraries and a
rendezvous protocol is used to find out the library
that implements the required function. When the
correct library has completed the call, the control
returns back to the calling process. Since dynamic
linking bases its functioning on synchronous events,
it is essential that context switching overhead is as
small as possible, in order to have a good system
performance. Contiki developers have granted this
by implementing processes as event handlers,
which run without separate protection domains.
The flexible mechanism of dynamic linking
allowed Contiki researchers to implement
multithreading as a library optionally linked with
programs. Another important component based on a
shared library is the communication stack.
Implementing the communication stack as a library
allows its dynamic replacement and, more precisely,
if the stack is split into different libraries it
becomes easy to replace a communication layer on
the run.
2.4 PicOS
PicOS is an operating system written in C and
specifically aimed for microcontrollers with limited
RAM on chip. In the attempt to ease the
implementation of applications with constrained
resource hardware platforms, PicOS creators leaned
towards a programming environment, which is a
collection of functions for organizing multiple
activities of “reactive” applications. This
environment is capable to provide services like a
flavor of multitasking and tools for inter-process
communication.
Each process is thought as a FSM that changes
its state according to the events. This approach is
very effective for reactive applications, whose
primary role is to respond to events rather than
processing data or crunching numbers. The CPU
multiplexing happens only at state boundaries: in
other words FSM states can be viewed as
checkpoints, at which PicOS processes can be
preempted. Owing the fact that processes are
preemptible at clearly defined points, potentially
problematic operations on counters and flags are
always atomic. On the other hand, such non-
preemptible character of PicOS processes makes
this system not well suitable for real time
applications. In PicOS active processes that need to
wait for some events may release the CPU by
issuing a “wait request”, which defines the
conditions necessary to their recovery. This way the
CPU resources could be destined to other processes.
The PicOS system is also equipped with several
advanced features, like a memory allocator capable
3
of organizing the heap area into a number of
different disjoint pools, and a set of configurable
device drivers including serial ports, LCD displays
and Ethernet interfaces.
2.5 MagnetOS
Applications often need to adapt not only to
external changes but also to the internal changes
initiated by the applications themselves. An
example may come from a battlefront application
that may modify its behavior switching from the
defensive to the offensive mode: this application
could change its communication pattern and
reorganize the deployed components. Focusing on
this point, researchers at the Cornell University
argued that network-wide energy management is
best provided by a distributed, power-aware
operating system. Those researchers developed
MagnetOS aiming to the following four goals. The
first was the adaptability to resources and network
changes. The second was to follow efficient
policies in terms of power consumption. The third
goal was giving the OS general-purpose
characteristics, allowing it to execute applications
over networks of nodes with heterogeneous
capabilities and handling different hardware and
software choices. The fourth goal was providing the
system with facilities for deploying, managing and
modifying executing applications.
The result was a system providing a SSI,
namely a Single System Image. In this abstraction,
the entire network is presented to applications as a
single unified Java virtual machine. The system,
which follows the Distributed Virtual Machine
paradigm, may be partitioned in a static and in a
dynamic component. The static component rewrites
regular Java applications into objects that can be
distributed across the network. The dynamic
component provides on each node services for
application monitoring and for object creation,
invocation and migration. In order to achieve good
performance an auxiliary interface is provided by
the MagnetOS runtime that overrides the automatic
object placement decisions and allows
programmers to explicitly direct object placement.
MagnetOS uses two online power-aware
algorithms to reduce application energy
consumption and to increase system survival by
moving application components within the entire
network. In practice, these protocols try to move he
communication endpoints in order to conserve
energy. The first of them, called NetPull, works at
the physical layer whereas the second one, called
NetCenter, works at the network layer.
2.6 EYES
This operating system was developed within the
Ubiquitous Computing and Communication Journal
EYES European project and tries to address the
problems of scarce resources in terms of both the
memory and power supply and the need for
distribution and reconfiguration capabilities.
The researchers found solution to these
problems developing a event-driven system. In fact,
EYES OS is structured in modules that are executed
as responses to external events, leaving the system
in a power saving mode when there is no external
event to serve. Every module can ask for several
tasks to be performed; each task in turn defines a
certain block of code that runs to completion. In
this paradigm, no blocking operation is permitted
and no polling operation should be instantiated: the
programmer instead will use interrupts to wake up
the system when the needed input becomes
available.
The system provides a scheduler which can be
implemented as a simple FIFO or a more
sophisticated algorithm. The interrupts are also seen
as tasks scheduled and ready to be executed.
In the EYES architecture there are two system
layers of abstraction. The first layer is the “Sensor
and Networking Layer”, which provides an API for
the sensor nodes and the network protocols. The
second layer is the “Distributed Services Layer”,
which exposes an API for mobile sensor
applications support. In particular, two services
belong to this layer: the “Lookup Service” and the
“Information Service”. The first supports mobility,
instantiation and reconfiguration, while the latter
deals with aspects of collecting data. On top of
cited layers stand the user applications.
The EYES OS provides a four-step procedure
for code distribution, designed to update the code
into nodes, including the operating system. This
procedure is resilient to packet losses during the
update, using as few communication and local
resources as possible and halting the node
operations only for a short period.
3 CONCLUSIONS
The operating systems here described present
different approaches to the common problems of
WSNs. It is not in the aim of this article to express
opinions about the presented systems; nevertheless,
some general guidelines could be drawn from the
work experience made by all the esteemed
researchers.
We present now some guidelines for the
development of the next generation of WSN
operating systems, that should help both researchers
and users.
The constrained nature of resources in
embedded systems is definitely evident, so a
small, efficient code is a primary goal, as well
as power-aware policies are an obligatory
4
 Table 1: summary of WSN OS features.

TinyOS Mantis
Objectives Manage concurrent data flows Small learning curve
Scale easily with technology
Modularity
Structure Event-based approach Multithreaded OS,
Tiny scheduler and a set of components UNIX-style scheduler
No blocking or polling Statically-allocated thread table
Developed in nesC Developed in C
Special A byte code interpreter for non-expert Specific idle task that adjusts kernel
features programmers parameters to conserve energy
Remote debugging and reprogramming

Contiki PicOS
Objectives Preemptive multithreading support Aimed for microcontrollers with tiny RAM
Runtime loading and linking of libraries
Structure Lightweight event-driven kernel Each process thought as a FSM
Multithreading features as an optionally Multiplexing at state boundaries
linked library Written in C
Special Capable of changing communication layer on Memory allocator
features the run A set of configurable device drivers

MagnetOS EYES
Objectives Adaptability to resource and network changes Address problems of scarce memory and
Manage nodes with heterogeneous power supply
capabilities
Structure Single System Image, the entire network is a Event driven OS
unified Java virtual machine Structured in modules executed as responses
to external events
Each task runs to completion
Special Two on-line special algorithms to reduce Two layers of abstraction with specific API
features energy consumption for applications and physical support
Four-step procedure to update the code

Table 2: the seven expected features of the next generation WSN operating systems.

Power-aware policies

Self organization

Easy interface to expose data

Simple way to program, update and debug
network applications
Power-aware communication protocols

Portability
Easy programming language for non-tech
users

Ubiquitous Computing and Communication Journal 5

condition to exploit the efficiency in WSN
applications.
To ensure a proper functioning of a network,
which is constituted by unattended nodes that
could have been deployed in a harsh
environment, the operating system must provide
a mechanism for self-organization and
reorganization in case of node failures.
A WSN, especially if composed of a huge
number of nodes, must behave as a distributed
system, exposing an interface where data and
processes are accessible and manageable like it
happens with databases.
A large number of nodes carries also the need
for an easy, yet power efficient way to program
the network, which should be also usable after
the deployment and without affecting normal
functioning. Such a programming (and re-
programming) procedure must be robust to
interference and to all other causes of
transmission failures during the dissemination
of code chunks. While the entire re-
programming of the core of the system may not
be necessary, the applications must be patched,
updated or even totally changed if the main
purpose of the WSN is changed. This leads to
the preference, if possible, of different levels of
re-programming granularity.
The operating system must treat wireless
communication interfaces as special resources,
providing a set of different power aware
communication protocols. The system has to
choose the proper protocol, according to the
current environment state and application needs.
The operating system should be portable to
different platforms: this is necessary both for the
possible presence of nodes with different tasks
and for the opportunity of a post-deployment of
newer sensors, which could be placed in order
to reintegrate the network node set.
The operating system should provide a
platform for fast prototyping, testing and
debugging application programs. In this context
it is remarkable to note that, if the WSN
paradigm will spread in a kaleidoscopic set of
applications, touching many aspects of our life,
Ubiquitous Computing and Communication Journal
then program developers will not be just
communication and computer engineers. It
appears clear that, in order to support non-
technical developers, a really simple API or
even an application-typology programming
language must be provided, alongside with the
“normal” and more efficient API. Making WSN
easy to use will make them more attractive and
step up their diffusion.
4 REFERENCES
[1] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D.
Culler, K. Pister: System Architecture
Directions for Networked Sensors, ASPLOS.
(2000).
[2] K. Sohraby, D. Minoli, T. Znati: Wireless
Sensor Networks: technology, Protocols and
Applications, John Wiley & Sons Inc. (2007).
[3] H. Abrach, S. Bhatti, J. Carlson, H. Dai J. Rose,
A. sheth, B. Sheth, B. Shucker, J. Deng, R. Han:
MANTIS: System Support for MultimodAl
NeTworks of In-situ Sensors, Proceedings of the
2nd ACM International Conference on Wireless
Sensor Networks and Applications. (2003).
[4] A. Dunkels, B. Grönvall, T. Voigt, J. Alonso:
The Design for a Lightweight Portable
Operating System for Tiny Networked Sensor
Devices, SICS Technical Report (2004).
[5] E. Akhmetshina, P. Gburzynski, F. Vizecoumar:
PicOS: A Tiny Operation System for Extremely
Small Embedded Platforms, Proceedings of the
Conference on Embedded System and
Applications ESA’02 (2002).
[6] R. Barr, J. Bicket, D. S. Dantas, B. Du, T.W.D.
Kim, B. Zhou, E. Sirer: On the need for system-
level support for ad hoc and sensor networks,
SIGOPS Oper. Syst. Rev. (2002).
[7] S. Dulman, P. Havinga: Operating System
Fundamentals for the EYES Distributed Sensor
Network, Proceedings of Progress’02 (2002).
2