WSNOPSYS article 159 final 159

Description

UBICC, the Ubiquitous Computing and Communication Journal [ISSN 1992-8424], is an international scientific and educational organization dedicated to advancing the arts, sciences, and applications of information technology. With a world-wide membership, UBICC is a leading resource for computing professionals and students working in the various fields of Information Technology, and for interpreting the impact of information technology on society.

Shared by: tabindah

Tags

UbiCC, Journal

Stats

views:: 14
posted:: 6/17/2010
language:: Italian
pages:: 6

Public Domain

Document Sample

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

Ubiquitous Computing and Communication Journal 1
In TinyOS neither blocking nor polling operation is 2.2 MANTIS
permitted and the CPU doesn’t waste time in
actively looking for interesting events; on the The MultimodAl system for NeTworks of In-
contrary, unused CPU cycles are spent in a sleep situ wireless Sensors [3] was developed focusing on
state. two design key: the need for a small learning curve
System configuration can be summarized in a for users and the need for flexibility. The first
tiny scheduler and a set of components. The objective led to fundamental choices in the
scheduler is a simple FIFO utilizing a bounded size architecture of the system and the programming
scheduling data structure for efficiency, nonetheless language used for its implementation. In fact, to
a more sophisticated scheduling policy could be lower the entry barrier the researchers decided to
implemented. When the task queue is empty, the adopt a largely diffuse design methodology, that is,
CPU is forced to the sleep state waiting for an the classical structure of a multithreaded operating
hardware event to trigger the scheduling of the system. For this reason MANTIS includes features
event-associated tasks. Tasks in the TinyOS like multithreading, preemptive scheduling with
architecture are atomic and run to completion time slices, I/O synchronization via mutual
although they can be preempted by events. This exclusion, and standard network stack and device
semantics of tasks allows the allocation of a single drivers. The second choice is associated with the
stack, which is an important feature in memory purpose of flattening the learning curve for users
constrained systems. and determinates the use of standard C as
Three types of components were thought to developing language for the kernel and the API.
constitute the TinyOS architecture. The first type of The choice of C language additionally entails the
components are the “hardware abstraction” which cross-platform support and the reuse of a vast
map physical hardware like I/O devices into legacy code base.
component models. The second type of components MANTIS kernel resembles UNIX-style
is called “synthetic hardware” and simulates the schedulers providing services for a subset of
behavior of advanced hardware; often synthetic POSIX threads along with priority based scheduling.
hardware sits on top of the hardware abstraction The thread table is allocated statically, so it can be
components. The last type of components are the adjusted only at compile time. The scheduler
“high level software” components, which perform receives notes to trigger context switches from an
control, routing and all data transformations such as hardware timer interrupt. This interrupt is the only
data aggregation and manipulation. This kind of kind of hardware interrupt handled by the kernel: in
abstraction of hardware and software in the fact all the others interrupts are sent directly to
component model is intended to ease the device drivers. Context switches are triggered not
exploitation of tradeoffs between the scale of only by timer events but also by system calls or
integration, the power requirements and the cost of semaphore operations. Besides drivers and user
the system. Every component owns a fixed-size threads, MANTIS has a special idle, low-priority
frame that is statically allocated: this allows to thread created by the kernel at startup. This thread
know exactly the memory requirements of a could be used to implement power-aware
component at compile time and prevents the scheduling: thanks to its position, it can detect
overhead associated with dynamic allocation. patterns of CPU utilization and adjust kernel
TinyOS was originally developed in C, giving parameters to conserve energy.
the system the capability of targeting multiple CPU MANTIS researchers thought that wireless
architectures. However, the system was afterwards networking management was a critical matter, so
re-implemented in nesC: this is a programming they developed the layered network stack as a set of
language specific for networked embedded systems, user level threads. In other words, they
whose key focus is holistic approach in design. implemented different layers in different threads
It’s remarkable that for TinyOS a byte-code advocating that this choice promotes flexibility to
interpreter has been developed that makes the the detriment of performance. This flexible
system accessible to non-expert programmers and structure is useful in particular for dynamic
enables quick and efficient programming of a reprogramming, because it enables application
whole WSN. This interpreter, called Maté, depicts developers to reprogram network functionalities
the program’s code as made of capsules. Thanks to such as routing by simply starting, stopping and
the beaconless, ad-hoc routing protocol deleting user-level threads.
implemented in Maté, when a sensor node receives Drawing from the experience in WSNs, the
a newer version of a capsule, it will install it. developers of MANTIS gave their system a set of
Through a hop-by-hop code injection, Maté can sophisticated features like dynamic reprogramming
update the code of the entire network. of sensors nodes via wireless communication,
remote debugging and multimodal prototyping.
MANTIS prototyping environment provides a
framework for testing devices and applications

Ubiquitous Computing and Communication Journal 2
across heterogeneous platforms. It extends beyond linking. Dynamic linking is based on synchronous
simulation permitting the coexistence of both events: a library function is invoked by issuing an
virtual and physical nodes in the same network. event generated by the caller program. The event
This feature is derived directly by the system code broadcasts the request to all the libraries and a
architecture, which can run without modifications rendezvous protocol is used to find out the library
on virtual nodes within an x86 architecture. that implements the required function. When the
Dynamic reprogramming in MANTIS is correct library has completed the call, the control
implemented as a system call library, which is built returns back to the calling process. Since dynamic
into the kernel. There are different granularities of linking bases its functioning on synchronous events,
reprogramming: entire kernel reflashing, it is essential that context switching overhead is as
reprogramming of a single thread, changing of small as possible, in order to have a good system
variables within the thread. Along with dynamic performance. Contiki developers have granted this
reprogramming, an important feature has been also by implementing processes as event handlers,
developed: the Remote Shell and Command Server which run without separate protection domains.
which allows the user “logging in” into a node and The flexible mechanism of dynamic linking
taking control of it. The server is implemented as an allowed Contiki researchers to implement
application thread and gives the user the ability to multithreading as a library optionally linked with
alter node’s configuration, run or kill programs, programs. Another important component based on a
inspect and modify the inner state of the node. shared library is the communication stack.
Implementing the communication stack as a library
allows its dynamic replacement and, more precisely,
2.3 Contiki if the stack is split into different libraries it
becomes easy to replace a communication layer on
Contiki is an operating system based on a the run.
lightweight event-driven kernel. It was developed
drawing from previous operating systems’ works
with the goal of adding features like run-time 2.4 PicOS
loading and linking of libraries, programs and
device drivers, as well as support for preemptive PicOS is an operating system written in C and
multithreading. specifically aimed for microcontrollers with limited
Event-based systems have shown good RAM on chip. In the attempt to ease the
performance for many kind of WSN’s applications; implementation of applications with constrained
however, purely event-based systems have the resource hardware platforms, PicOS creators leaned
penalty of being unable to respond to external towards a programming environment, which is a
events during long-lasting computations. A partial collection of functions for organizing multiple
solution to this problem is adding multithreading activities of “reactive” applications. This
support to the system, but this would cause environment is capable to provide services like a
additional overhead. To address these problems flavor of multitasking and tools for inter-process
Contiki researchers have done the compromise of communication.
developing an event-driven kernel and Each process is thought as a FSM that changes
implementing preemptive multithreading features its state according to the events. This approach is
as a library, which is optionally linked with very effective for reactive applications, whose
programs that explicitly require it. primary role is to respond to events rather than
Contiki operating system can be divided in three processing data or crunching numbers. The CPU
main components: an event driven kernel that multiplexing happens only at state boundaries: in
provides basic CPU multiplexing and has no other words FSM states can be viewed as
platform-specific code, a program loader and checkpoints, at which PicOS processes can be
finally a set of libraries that provide higher level preempted. Owing the fact that processes are
functionalities. preemptible at clearly defined points, potentially
From a structural point of view, a system problematic operations on counters and flags are
running Contiki can be partitioned in two parts: a always atomic. On the other hand, such non-
core and a set of loadable programs. The core is preemptible character of PicOS processes makes
compiled into a single binary image and is this system not well suitable for real time
unmodifiable after nodes’ deployment. The applications. In PicOS active processes that need to
programs are loaded into the system by the program wait for some events may release the CPU by
loader, which may obtain the binaries either from issuing a “wait request”, which defines the
the communication stack (and thus from the conditions necessary to their recovery. This way the
network) or from the system’s EEPROM memory. CPU resources could be destined to other processes.
Shared libraries like user programs may be The PicOS system is also equipped with several
replaced in deployed systems by using the dynamic advanced features, like a memory allocator capable

Ubiquitous Computing and Communication Journal 3
of organizing the heap area into a number of EYES European project and tries to address the
different disjoint pools, and a set of configurable problems of scarce resources in terms of both the
device drivers including serial ports, LCD displays memory and power supply and the need for
and Ethernet interfaces. distribution and reconfiguration capabilities.
The researchers found solution to these
problems developing a event-driven system. In fact,
2.5 MagnetOS EYES OS is structured in modules that are executed
as responses to external events, leaving the system
Applications often need to adapt not only to in a power saving mode when there is no external
external changes but also to the internal changes event to serve. Every module can ask for several
initiated by the applications themselves. An tasks to be performed; each task in turn defines a
example may come from a battlefront application certain block of code that runs to completion. In
that may modify its behavior switching from the this paradigm, no blocking operation is permitted
defensive to the offensive mode: this application and no polling operation should be instantiated: the
could change its communication pattern and programmer instead will use interrupts to wake up
reorganize the deployed components. Focusing on the system when the needed input becomes
this point, researchers at the Cornell University available.
argued that network-wide energy management is The system provides a scheduler which can be
best provided by a distributed, power-aware implemented as a simple FIFO or a more
operating system. Those researchers developed sophisticated algorithm. The interrupts are also seen
MagnetOS aiming to the following four goals. The as tasks scheduled and ready to be executed.
first was the adaptability to resources and network In the EYES architecture there are two system
changes. The second was to follow efficient layers of abstraction. The first layer is the “Sensor
policies in terms of power consumption. The third and Networking Layer”, which provides an API for
goal was giving the OS general-purpose the sensor nodes and the network protocols. The
characteristics, allowing it to execute applications second layer is the “Distributed Services Layer”,
over networks of nodes with heterogeneous which exposes an API for mobile sensor
capabilities and handling different hardware and applications support. In particular, two services
software choices. The fourth goal was providing the belong to this layer: the “Lookup Service” and the
system with facilities for deploying, managing and “Information Service”. The first supports mobility,
modifying executing applications. instantiation and reconfiguration, while the latter
The result was a system providing a SSI, deals with aspects of collecting data. On top of
namely a Single System Image. In this abstraction, cited layers stand the user applications.
the entire network is presented to applications as a The EYES OS provides a four-step procedure
single unified Java virtual machine. The system, for code distribution, designed to update the code
which follows the Distributed Virtual Machine into nodes, including the operating system. This
paradigm, may be partitioned in a static and in a procedure is resilient to packet losses during the
dynamic component. The static component rewrites update, using as few communication and local
regular Java applications into objects that can be resources as possible and halting the node
distributed across the network. The dynamic operations only for a short period.
component provides on each node services for
application monitoring and for object creation,
invocation and migration. In order to achieve good 3 CONCLUSIONS
performance an auxiliary interface is provided by
the MagnetOS runtime that overrides the automatic The operating systems here described present
object placement decisions and allows different approaches to the common problems of
programmers to explicitly direct object placement. WSNs. It is not in the aim of this article to express
MagnetOS uses two online power-aware opinions about the presented systems; nevertheless,
algorithms to reduce application energy some general guidelines could be drawn from the
consumption and to increase system survival by work experience made by all the esteemed
moving application components within the entire researchers.
network. In practice, these protocols try to move he We present now some guidelines for the
communication endpoints in order to conserve development of the next generation of WSN
energy. The first of them, called NetPull, works at operating systems, that should help both researchers
the physical layer whereas the second one, called and users.
NetCenter, works at the network layer.
The constrained nature of resources in
2.6 EYES embedded systems is definitely evident, so a
small, efficient code is a primary goal, as well
This operating system was developed within the as power-aware policies are an obligatory

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

Shared by: UbiCC Journal

UbiCC Journal

Research

Ubiquitous Computin...

UbiCC Journal

ubicc.org

About

UBICC, the Ubiquitous Computing and Communication Journal [ISSN 1992-8424], is an international scientific and educational organization dedicated to advancing the arts, sciences, and applications of information technology. With a (More...)world-wide membership, UBICC is a leading resource for computing professionals and students working in the various fields of Information Technology, and for interpreting the impact of information technology on society.

Related docs