ller@cs.berkeley.edu
dgay@intel-research.net
Abstract
Energy management is a critical concern in wireless sensornets. De-
spite its importance, sensor network operating systems today pro-
vide minimal energy management support, requiring applications to
explicitly manage system power states. To address this problem,
we present ICEM, a device driver architecture that enables simple,
energy efcient wireless sensornet applications. The key insight
behind ICEM is that the most valuable information an application
can give the OS for energy management is its concurrency. Us-
ing ICEM, a low-rate sensing application requires only a single line
of energy management code and has an efciency within 1.6% of
a hand-tuned implementation. ICEMs effectiveness questions the
assumption that sensornet applications must be responsible for all
power management and sensornets cannot have a standardized OS
with a simple API.
Categories and Subject Descriptors
D.4.7 [Operating Systems]: Organization and Design; D.2.11
[Software Engineering]: Software Architectures
General Terms
Design, Management
Keywords
Concurrency, Energy, Device Driver Architecture, TinyOS
1.
INTRODUCTION
Energy efciency is a critical concern in mobile and battery pow-
ered systems. Reducing energy consumption improves system life-
time. An OS can improve energy efciency by putting peripherals
into low power modes and dropping the processor to a sleep state
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 prot or commercial advantage and that copies
bear this notice and the full citation on the rst page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specic
permission and/or a fee.
SOSP07,
October 1417, 2007, Stevenson, Washington, USA.
Copyright 2007 ACM 978-1-59593-591-5/07/0010 ...$5.00.
when idle. The challenge lies is deciding when and how to do so: to
manage energy well, an OS must infer future application behavior.
Prior work has shown us two things are generally true when an OS
optimizes for energy: simple models are rarely effective and a bit of
application knowledge can go a long way. For dynamic CPU volt-
age scaling, Vertigo [6] showed that having a process tell the OS its
workload class greatly outperforms simple hardware heuristics and
xed-interval averaging [11], and GRACE-OS demonstrated that re-
ceiving explicit real-time deadlines from applications allows an OS
to reduce energy further [41]. For disk spindown, Coop-I/O explored
how application-specied timeouts on disk operations allow the OS
to batch requests, outperforming even an oracle spindown policy for
standard le interfaces [39].
Despite all of these advances, most modern operating systems still
use very simplistic energy management policies. The problem is
that, beneath all of their advanced libraries, applications still use
APIs which were designed before energy constraints were a ma-
jor concern. At rst glance, wireless sensor networks (sensornets)
seem to be a domain of computer systems that would avoid these pit-
falls. Intended to last for months or years on small batteries, sensor-
nets have harsh energy requirements, making energy management a
critical component of almost every application. As sensornets have
limited resources and very different use cases than traditional time-
sharing systems, they tend to run small, customizable operating sys-
tems with exible abstraction boundaries.
In practice today, however, sensornet operating systems, like their
embedded siblings, provide minimal energy management support.
They leave all complexity to the application. Embedded OSes such
as eCos [29] and VxWorks [40], for example, have interfaces for
processor power control but peripheral device control is left to the
application.
Sensornet OSes such as TinyOS [16], Contiki [5],
MOS [1], and SOS [12] have power control interfaces which an
application must explicitly invoke in order to change power states.
Pushing all this logic into the application means that the OS does
not prevent energy saving strategies, but this exibility comes at the
cost of application code complexity. For example, the core code for
the TinyOS Great Duck Island deployment [33] the rst success-
ful long-term deployment of the OS is 500 lines lled with special
cases such as if forwarding a packet, defer powering down. In con-
trast, if this application were to be implemented using the features
provided by ICEM, it would be fewer than 50 lines.
In this paper, we present ICEM (Integrated Concurrency and En-
ergy Management), a sensornet device driver architecture that allows
1 a sensornet OS to automatically minimize energy consumption with-
out requiring additional explicit information from an application.
The key insight behind ICEM is that the most important informa-
tion a sensornet application can provide is the potential concurrency
of its I/O. As most sensornet OSes are completely event-driven, an
application simply needs to make a set of asynchronous system calls
and let the OS schedule the underlying operations.
The research challenge in ICEM lies in the fact that some op-
erations must occur serially. While application-level requests can
use a single API call, peripherals often have complex call/return se-
quences, some of which have tight timing constraints. This requires
integrating traditional blocking synchronization primitives into an
execution model that is completely non-blocking.
ICEM solves
this problem by carefully exposing low-level concurrency to drivers
through power locks, a novel non-blocking lock mechanism that in-
tegrates concurrency, energy, and hardware conguration manage-
ment. For example, when a client acquires a drivers power lock,
ICEM has powered and correctly congured the hardware for that
client. When a power lock falls idle, ICEM powers down the under-
lying hardware. Power locks transform locks, a traditionally passive
data structure, into an active energy management participant.
We have designed and implemented ICEM as a key part of the
second generation of the TinyOS operating system, TinyOS 2.0 (T2).
It has been used to replace many of the ad-hoc policies and interfaces
found in TinyOS 1.0 with three basic system abstractions and a small
library of power lock components. We evaluate ICEM using a rep-
resentative low duty cycle application that logs sensors every ve
minutes and sends data to a base station every twelve hours. Using
ICEM, the application has a single line of power management code:
it sets the radio duty cycle when it boots. ICEM achieves 98.4
99.9% of the energy efciency of a hand-tuned implementation that
schedules I/O at the application level.
The rest of this paper is structured as follows. In Section 2, we
introduce a sample application that we use as an example throughout
the rest of the paper and provide background information on wire-
less sensor energy proles and operating systems. In Section 3, we
introduce how ICEM divides device drivers into three concurrency
classes and give their dening characteristics. In Section 4, we de-
scribe how drivers manage their concurrency and energy, describe
power locks, and provide details of the supporting power manage-
ment library. In Section 5 we evaluate ICEM using power traces of
our sample application, runtime instrumentation of library calls, and
a survey of where and and how often the different driver classes ap-
pear. We compare our approach to prior work and existing sensornet
OSes in Section 6, provide insight into future developments in Sec-
tion 7, and conclude in Section 8. Appendix A contains pointers to
the TinyOS 2.0 ICEM source code.
2.
BACKGROUND
This section provides background on the challenges and details
of managing energy on a wireless sensor. We start with a descrip-
tion of the sample application used as a running example through-
out the rest of the paper. We describe the split-phase program-
ming and concurrency model common to most sensornet OSes. We
overview ultra-low power hardware characteristics and how they af-
fect both driver implementations and sensornet energy management
as a whole. From this information we observe that application con-
currency gives a sensornet OS the ability to schedule operations in
an energy efcient manner.
2.1
Application
Throughout this paper, we ground our goals and evaluation
through a representative application of long lived, unattended wire-
Every 5 minutes:
Every 12 hours:
Write prior samples
For all new log entries:
Sample photo active
Send current sample
Sample total solar
Read next sample
Sample temperature
Sample humidity
Figure 1: Application pseudocode. Every operation is non-blocking.
Rather than try to coordinate sample completion, the loop writes the
previous results to ash. Similarly, while it sends one set of samples
it reads the next set from ash.
less sensors. Every ve minutes, the application samples four sen-
sors and logs the readings in ash with a sequence number. Each
log record is ten bytes. Every twelve hours, the application retrieves
new readings from ash and sends them to a gateway. The appli-
cation logs values to ash to provide data reliability in case of tem-
porary or long-term disconnection, a common problem in long-term
deployments [35]. Sampling and sending are completely decoupled:
the two parts have a producer/consumer relationship on the log.
Data latencies of a day are acceptable for many low-rate envi-
ronmental monitoring applications [33, 35]. If needed, the applica-
ti