TinyOS: An Operating System for Sensor Networks

Jason Hill, Robert Szewczyk, Alec Woo, Philip Levis, Sam Madden, Cameron Whitehouse,
Joseph Polastre, David Gay, Cory Sharp, Matt Welsh,
Eric Brewer and David Culler

Abstract through actuators, performing local data processing, trans-

We present TinyOS, a flexible, application-specific operating sys- mitting data, routing data for others, and participating in
tem for sensor networks. Sensor networks consist of (potentially) various distributed processing tasks, such as statistical ag-
thousands of tiny, low-power nodes, each of which execute con- gregation or feature recognition. Many of these events,
current, reactive programs that must operate with severe memory such as radio management, require real-time responses.
and power constraints. The sensor network challenges of limited This requires an approach to concurrency management that
resources, event-centric concurrent applications, and low-power reduces potential bugs while respecting resource and tim-
operation drive the design of TinyOS. Our solution combines flex- ing constraints.
ible, fine-grain components with an execution model that supports 3) Flexibility: The variation in hardware and applications
complex yet safe concurrent operations. TinyOS meets these chal- and the rate of innovation require a flexible OS that is both
lenges well and has become the platform of choice for sensor net- application-specific to reduce space and power, and inde-
work research; it is in use by over a hundred groups worldwide, pendent of the boundary between hardware and software.
and supports a broad range of applications and research topics. In addition, the OS should support fine-grain modularity
We provide a qualitative and quantitative evaluation of the system, and interpositioning to simplify reuse and innovation.
showing that it supports complex, concurrent programs with very 4) Low Power: Demands of size and cost, as well as un-
low memory requirements (many applications fit within 16KB of tethered operation make low-power operation a key goal
memory, and the core OS is 400 bytes) and efficient, low-power of mote design. Battery density doubles roughly every 50
operation. We present our experiences with TinyOS as a platform years, which makes power an ongoing challenge. Although
for sensor network innovation and applications. energy harvesting offers many promising solutions, at the
very small scale of motes we can harvest only microwatts
1 Introduction of power. This is insufficient for continuous operation of
Advances in networking and integration have enabled even the most energy-efficient designs. Given the broad
small, flexible, low-cost nodes that interact with their en- range of applications for sensor networks, TinyOS must not
vironment and with each other through sensors, actuators only address extremely low-power operation, but also pro-
and communication. Single-chip systems are now emerg- vide a great deal of flexibility in power-management and
ing that integrate a low-power CPU and memory, radio duty-cycle strategies.
or optical communication [75], and MEMS-based on-chip In our approach to these requirements we focus on two
sensors. The low cost of these systems enables embedded broad principles:
networks of thousands of nodes [18] for applications rang-
ing from environmental and habitat monitoring [11, 51], Event Centric: Like the applications, the solution must be
seismic analysis of structures [10], and object localization event centric. The normal operation is the reactive ex-
and tracking [68]. ecution of concurrent events.
Sensor networks are a very active research space, with
ongoing work on networking [22, 38, 83], application sup- Platform for Innovation: The space of networked sensors
port [25, 27, 49], radio management [8, 84], and secu- is novel and complex: we therefore focus on flexibility
rity [9, 45, 61, 81], as a partial list. A primary goal of and enabling innovation, rather then the “right” OS
TinyOS is to enable and accelerate this innovation. from the beginning.
Four broad requirements motivate the design of TinyOS:
TinyOS is a tiny (fewer than 400 bytes), flexible oper-
1) Limited resources: Motes have very limited physical ating system built from a set of reusable components that
resources, due to the goals of small size, low cost, and low are assembled into an application-specific system. TinyOS
power consumption. Current motes consist of about a 1- supports an event-driven concurrency model based on split-
MIPS processor and tens of kilobytes of storage. We do phase interfaces, asynchronous events, and deferred com-
not expect new technology to remove these limitations: the putation called tasks. TinyOS is implemented in the nesC
benefits of Moore’s Law will be applied to reduce size and language [24], which supports the TinyOS component and
cost, rather than increase capability. Although our current concurrency model as well as extensive cross-component
motes are measured in square centimeters, a version is in optimizations and compile-time race detection. TinyOS
fabrication that measures less than 5 mm2 . has enabled both innovation in sensor network systems and
2) Reactive Concurrency: In a typical sensor network a wide variety of applications. TinyOS has been under
application, a node is responsible for sampling aspects of development for several years and is currently in its third
its environment through sensors, perhaps manipulating it generation involving several iterations of hardware, radio
 Interface Description
stacks, and programming tools. Over one hundred groups ADC Sensor hardware interface
worldwide use it, including several companies within their Clock Hardware clock
products. EEPROMRead/Write EEPROM read and write
This paper details the design and motivation of TinyOS, HardwareId Hardware ID access
I2C Interface to I2C bus
including its novel approaches to components and concur- Leds Red/yellow/green LEDs
rency, a qualitative and quantitative evaluation of the oper- MAC Radio MAC layer
ating system, and the presentation of our experience with Mic Microphone interface
Pot Hardware potentiometer for transmit power
it as a platform for innovation and real applications. This Random Random number generator
paper makes the following contributions. First, we present ReceiveMsg Receive Active Message
the design and programming model of TinyOS, including SendMsg Send Active Message
StdControl Init, start, and stop components
support for concurrency and flexible composition. Second, Time Get current time
we evaluate TinyOS in terms of its performance, small size, TinySec Lightweight encryption/decryption
lightweight concurrency, flexibility, and support for low WatchDog Watchdog timer control
power operation. Third, we discuss our experience with Figure 1: Core interfaces provided by TinyOS.
TinyOS, illustrating its design through three applications:
environmental monitoring, object tracking, and a declara-
tive query processor. Our previous work on TinyOS dis- mediately while deferring extensive computation to tasks.
cussed an early system architecture [30] and language de- While tasks may perform significant computation, their ba-
sign issues [24], but did not present the operating system sic execution model is run-to-completion, rather than to run
design in detail, provide an in-depth evaluation, or discuss indefinitely; this allows tasks to be much lighter-weight
our extensive experience with the system over the last sev- than threads. Tasks represent internal concurrency within
eral years. a component and may only access state within that com-
Section 2 presents an overview of TinyOS, including ponent. The standard TinyOS task scheduler uses a non-
the component and execution models, and the support for preemptive, FIFO scheduling policy; Section 2.3 presents
concurrency. Section 3 shows how the design meets our the TinyOS execution model in detail.
four requirements. Sections 4 and 5 cover some of the en- TinyOS abstracts all hardware resources as compo-
abled innovations and applications, while Section 6 covers nents. For example, calling the getData() command
related work. Section 7 presents our conclusions. on a sensor component will cause it to later signal a
dataReady() event when the hardware interrupt fires.
2 TinyOS While many components are entirely software-based, the
TinyOS has a component-based programming model, cod- combination of split-phase operations and tasks makes this
ified by the nesC language [24], a dialect of C. TinyOS distinction transparent to the programmer. For example,
is not an OS in the traditional sense; it is a programming consider a component that encrypts a buffer of data. In a
framework for embedded systems and set of components hardware implementation, the command would instruct the
that enable building an application-specific OS into each encryption hardware to perform the operation, while a soft-
application. A typical application is about 15K in size, of ware implementation would post a task to encrypt the data
which the base OS is about 400 bytes; the largest applica- on the CPU. In both cases an event signals that the encryp-
tion, a database-like query system, is about 64K bytes. tion operation is complete.
The current version of TinyOS provides a large num-
2.1 Overview ber of components to application developers, including ab-
A TinyOS program is a graph of components, each of stractions for sensors, single-hop networking, ad-hoc rout-
which is an independent computational entity that exposes ing, power management, timers, and non-volatile storage.
one or more interfaces. Components have three computa- A developer composes an application by writing compo-
tional abstractions: commands, events, and tasks. Com- nents and wiring them to TinyOS components that provide
mands and events are mechanisms for inter-component implementations of the required services. Section 2.2 de-
communication, while tasks are used to express intra- scribes how developers write components and wire them
component concurrency. in nesC. Figure 1 lists a number of core interfaces that are
A command is typically a request to a component to available to application developers. Many different compo-
perform some service, such as initiating a sensor read- nents may implement a given interface.
ing, while an event signals the completion of that service.
Events may also be signaled asynchronously, for example, 2.2 Component Model
due to hardware interrupts or message arrival. From a tra- TinyOS’s programming model, provided by the nesC lan-
ditional OS perspective, commands are analogous to down- guage, centers around the notion of components that en-
calls and events to upcalls. Commands and events cannot capsulate a specific set of services, specified by interfaces.
block: rather, a request for service is split phase in that the TinyOS itself simply consists of a set of reusable system
request for service (the command) and the completion sig- components along with a task scheduler. An application
nal (the corresponding event) are decoupled. The command connects components using a wiring specification that is
returns immediately and the event signals completion at a independent of component implementations. This wiring
later time. specification defines the complete set of components that
Rather than performing a computation immediately, the application uses.
commands and event handlers may post a task, a function The compiler eliminates the penalty of small, fine-
executed by the TinyOS scheduler at a later time. This al- grained components by whole-program (application plus
lows commands and events to be responsive, returning im- operating system) analysis and inlining. Unused compo-
 module TimerM {
provides { Timer
StdControl configuration TimerC {
interface StdControl;
interface Timer[uint8_t id]; provides {
StdControl Timer } interface StdControl;
uses interface Clock; StdControl Timer interface Timer[uint8_t id];
TimerM } }
implementation { TimerM }
HWClock
... a dialect of C ... Clock
implementation {
} components TimerM, HWClock;

Figure 2: Specification and graphical depiction of the StdControl = TimerM.StdControl;

TimerM component. Provided interfaces are shown above the Timer = TimerM.Timer;
Clock
TimerM component and used interfaces are below. Downward TimerM.Clk -> HWClock.Clock;
arrows depict commands and upward arrows depict events. HWClock
}
TimerC
interface StdControl {
command result_t init(); Figure 4: TinyOS’s Timer Service: the TimerC configura-
command result_t start();
command result_t stop();
tion.
}

interface Timer {
command result_t start(char type, uint32_t interval);
mands and events. A module declares private state vari-
command result_t stop(); ables and data buffers, which only it can reference. Config-
event result_t fired(); urations are used to wire other components together, con-
}
necting interfaces used by components to interfaces pro-
interface Clock { vided by others. Figure 4 illustrates the TinyOS timer ser-
command result_t setRate(char interval, char scale); vice, which is a configuration (TimerC) that wires the timer
event result_t fire(); module (TimerM) to the hardware clock component (HW-
}
Clock). Configurations allow multiple components to be
interface SendMsg { aggregated together into a single “supercomponent” that
command result_t send(uint16_t address, exposes a single set of interfaces. For example, the TinyOS
uint8_t length,
TOS_MsgPtr msg); networking stack is a configuration wiring together 21 sep-
event result_t sendDone(TOS_MsgPtr msg, arate modules and 10 sub-configurations.
result_t success); Each component has its own interface namespace,
}
which it uses to refer to the commands and events that
Figure 3: Sample TinyOS interface types. it uses. When wiring interfaces together, a configuration
makes the connection between the local name of an inter-
face used by one component to the local name of the inter-
nents and functionality are not included in the application face provided by another. That is, a component invokes an
binary. Inlining occurs across component boundaries and interface without referring explicitly to its implementation.
improves both size and efficiency; Section 3.1 evaluates This makes it easy to perform interpositioning by introduc-
these optimizations. ing a new component in the component graph that uses and
A component has two classes of interfaces: those it pro- provides the same interface.
vides and those it uses. These interfaces define how the Interfaces can be wired multiple times; for example, in
component directly interacts with other components. An Figure 5 the StdControl interface of Main is wired to
interface generally models some service (e.g., sending a Photo, TimerC, and Multihop. This fan-out is transpar-
message) and is specified by an interface type. Figure 2 ent to the caller. nesC allows fan-out as long as the return
shows a simplified form of the TimerM component, part type has a function for combining the results of all the calls.
of the TinyOS timer service, that provides the StdCon- For example, for result t, this is a logical-AND; a fan-
trol and Timer interfaces and uses a Clock interface (all out returns failure if any subcall fails.
shown in Figure 3). A component can provide or use the A component can provide a parameterized interface that
same interface type several times as long as it gives each exports many instances of the same interface, parameter-
instance a separate name. ized by some identifier (typically a small integer). For ex-
Interfaces are bidirectional and contain both commands ample, the the Timer interface in Figure 2 is parameterized
and events. A command is a function that is implemented with an 8-bit id, which is passed to the commands and
by the providers of an interface, an event is a function that events of that interface as an extra parameter. In this case,
is implemented by its users. For instance, the Timer inter- the parameterized interface allows the single Timer com-
face (Figure 3) defines start and stop commands and a ponent to implement multiple separate timer interfaces, one
fired event. Although the interaction between the timer for each client component. A client of a parameterized in-
and its client could have been provided via two separate in- terface must specify the ID as a constant in the wiring con-
terfaces (one for its commands and another for its events), figuration; to avoid conflicts in ID selection, nesC provides
grouping them in the same interface makes the specifica- a special unique keyword that selects a unique identifier
tion much clearer and helps prevent bugs when wiring com- for each client.
ponents together. Every TinyOS application is described by a top-level
nesC has two types of components: modules and config- configuration that wires together the components used. An
urations. Modules provide code and are written in a dialect example is shown graphically in Figure 5: SurgeC is a sim-
of C with extensions for calling and implementing com- ple application that periodically (TimerC) acquires light
 SurgeC reachable from tasks.
StdControl Asynchronous Code (AC): code that is reach-
SurgeM
Main able from at least one interrupt handler.
StdControl ADC Timer SendMsg Leds

The traditional OS approach toward AC is to minimize

it and prevent user-level code from being AC. This would
be too restrictive for TinyOS. Component writers need to
StdControl ADC StdControl Timer StdControl SendMsg Leds interact with a wide range of real-time hardware, which is
Photo TimerC Multihop LedsC not possible in general with the approach of queuing work
for later. For example, in the networking stack there are
Figure 5: The top-level configuration for the Surge applica- components that interface with the radio at the bit level, the
tion.
byte level, and via hardware signal-strength indicators. A
primary goal is to allow developers to build responsive con-
sensor readings (Photo) and sends them back to a base sta- current data structures that can safely share data between
tion using multi-hop routing (Multihop). AC and SC; components often have a mix of SC and AC
nesC imposes some limitations on C to improve code ef- code.
ficiency and robustness. First, the language prohibits func- Although non-preemption eliminates races among tasks,
tion pointers, allowing the compiler to know the precise there are still potential races between SC and AC, as well
call graph of a program. This enables cross-component as between AC and AC. In general, any update to shared
optimizations for entire call paths, which can remove the state that is reachable from AC is a potential data race. To
overhead of cross-module calls as well as inline code for reinstate atomicity in such cases, the programmer has two
small components into its callers. Section 3.1 evaluates options: convert all of the conflicting code to tasks (SC
these optimizations on boundary crossing overheads. Sec- only), or use atomic sections to update the shared state. An
ond, the language does not support dynamic memory al- atomic section is a small code sequence that nesC ensures
location; components statically declare all of a program’s will run atomically. The current implementation turns off
state, which prevents memory fragmentation as well as run- interrupts during the atomic section and ensures that it has
time allocation failures. The restriction sounds more oner- no loops. Section 3.2 covers an example use of an atomic
ous than it is in practice; the component abstraction elim- section to remove a data race. The basic invariant nesC
inates many of the needs for dynamic allocation. In the must enforce is as follows:
few rare instances that it is truly needed (e.g., TinyDB, dis-
cussed in Section 5.3), a memory pool component can be Race-Free Invariant: Any update to shared state
shared by a set of cooperating components. is either SC-only or occurs in an atomic section.

2.3 Execution Model and Concurrency The nesC compiler enforces this invariant at compile time,
preventing nearly all data races. It is possible to introduce
The event-centric domain of sensor networks requires fine- a race condition that the compiler cannot detect, but it must
grain concurrency; events can arrive at any time and must span multiple atomic sections or tasks and use storage in
interact cleanly with the ongoing computation. This is a intermediate variables.
classic systems problem that has two broad approaches: 1) The practical impact of data race prevention is sub-
atomically enqueueing work on arrival to run later, as in stantial. First, it eliminates a class of very painful non-
Click [41] and most message-passing systems, and 2) ex- deterministic bugs. Second, it means that composition can
ecuting a handler immediately in the style of active mes- essentially ignore concurrency. It does not matter which
sages [74]. Because some of these events are time criti- components generate concurrency or how they are wired
cal, such as start-symbol detection, we chose the latter ap- together: the compiler will catch any sharing violations at
proach. nesC can detect data races statically, which elimi- compile time. Strong compile-time analysis enables a wide
nates a large class of complex bugs. variety of concurrent data structures and synchronization
The core of the execution model consists of run-to- primitives. We have several variations of concurrent queues
completion tasks that represent the ongoing computation, and state machines. In turn, this makes it easy to handle
and interrupt handlers that are signaled asynchronously by time-critical actions directly in an event handler, even when
hardware. Tasks are an explicit entity in the language; they update shared state. For example, radio events are al-
a program submits a task to the scheduler for execution ways dealt with in the interrupt handler until a whole packet
with the post operator. The scheduler can execute tasks has arrived, at which point the handler posts a task. Sec-
in any order, but must obey the run-to-completion rule. tion 3.2 contains an evaluation of the concurrency checking
The standard TinyOS scheduler follows a FIFO policy, and its ability to catch data races.
but we have implemented other policies including earliest-
deadline first. 2.4 Active Messages
Because tasks are not preempted and run to completion,
they are atomic with respect to each other. However, tasks A critical aspect of TinyOS’s design is its networking archi-
are not atomic with respect to interrupt handlers or to com- tecture, which we detail here. The core TinyOS communi-
mands and events they invoke. To facilitate the detection cation abstraction is based on Active Messages (AM) [74],
of race conditions, we distinguish synchronous and asyn- which are small (36-byte) packets associated with a 1-byte
chronous code: handler ID. Upon reception of an Active Message, a node
dispatches the message (using an event) to one or more han-
Synchronous Code (SC): code that is only dlers that are registered to receive messages of that type.
Handler registration is accomplished using static wiring Application Size Structure
and a parameterized interface, as described above. Optimized Unoptimized Reduction Tasks Events Modules
AM provides an unreliable, single-hop datagram proto- Blink 683 1791 61% 0 2 8
col, and provides a unified communication interface to both Blink LEDs
the radio and the built-in serial port (for wired nodes such GenericBase 4278 6208 31% 3 21 19
Radio-to-UART packet router
as basestations). Higher-level protocols providing multi-
CntToLeds 6121 9449 35% 1 7 13
hop communication, larger ADUs, or other features are
Display counter on LEDs
readily built on top of the AM interface. Variants of the ba-
CntToRfm 9859 13969 29% 4 31 27
sic AM stack exist that incorporate lightweight, link-level
Send counter as radio packet
security (see Section 4.1). AM’s event-driven nature and
Habitat monitoring 11415 19181 40% 9 38 32
tight coupling of computation and communication make Periodic environmental sampling
the abstraction well suited to the sensor network domain. Surge 14794 20645 22% 9 40 34
Ad-hoc multihop routing demo
2.5 Implementation Status Maté 23741 25907 8% 15 51 39
TinyOS supports a wide range of hardware platforms and Small virtual machine
has been used on several generations of sensor motes. Sup- Object tracking 23525 37195 36% 15 39 32
Track object in sensor field
ported processors include the Atmel AT90L-series, Atmel
TinyDB 63726 71269 10% 18 193 91
ATmega-series, and Texas Instruments MSP-series proces-
SQL-like query interface
sors. TinyOS includes hardware support for the RFM
TR1000 and Chipcon CC1000 radios, as well as as well Figure 6: Size and structure of selected TinyOS applications.
as several custom radio chipsets. TinyOS applications may
be compiled to run on any of these platforms without mod-
ification. Work is underway (by others) to port TinyOS
Absolute Size: A TinyOS program’s component graph de-
to ARM, Intel 8051 and Hitachi processors and to support
fines which components it needs to work. Because compo-
Bluetooth radios.
nents are resolved at compile time, compiling an applica-
TinyOS supports an extensive development environ- tion builds an application-specific version of TinyOS: the
ment that incorporates visualization, debugging, and sup- resulting image contains exactly the required OS services.
port tools as well as a fine-grained simulation environment.
Desktops, laptops, and palmtops can serve as proxies be- As shown in Figure 6, TinyOS and its applications are
tween sensor networks and wired networks, allowing inte- small. The base TinyOS operating system is less than
gration with server side tools implemented in Java, C, or 400 bytes and associated C runtime primitives (including
MATLAB, as well as interfaces to database engines such floating-point libraries) fit in just over 1KB. Blink repre-
as PostgreSQL. nesC includes a tool that generates code to sents the footprint for a minimal application using the base
marshal between Active Message packet formats and Java OS and a primitive hardware timer. CntToLeds incorpo-
classes. rates a more sophisticated timer service which requires ad-
ditional memory. GenericBase captures the footprint of
TinyOS includes TOSSIM, a high-fidelity mote simula- the radio stack while CntToRfm incorporates both the ra-
tor that compiles directly from TinyOS nesC code, scaling dio stack and the generic timer, which is the case for many
to thousands of simulated nodes. TOSSIM gives the pro- real applications. Most applications fit in less than 16KB,
grammer an omniscient view of the network and greater while the largest TinyOS application, TinyDB, fits in about
debugging capabilities. Server-side applications can con- 64KB.
nect to a TOSSIM proxy just as if it were a real sensor
network, easing the transition between the simulation en- Footprint Optimization: TinyOS goes beyond standard
vironment and actual deployments. TinyOS also provides techniques to reduce code size (e.g., stripping the symbol
JTAG support integrated with gdb for debugging applica- table). It uses whole-program compilation to prune dead
tions directly on the mote. code, and cross-component optimizations remove redun-
dant operations and module-crossing overhead. Figure 6
shows the reduction in size achieved by these optimizations
3 Meeting the Four Key Requirements on a range of applications. Size improvements range from
In this section, we show how the design of TinyOS, particu- 8% for Maté, to 40% for habitat monitoring, to over 60%
larly its component model and execution model, addresses for simple applications.
our four key requirements: limited resources, reactive con- Component Overhead: To be efficient, TinyOS must min-
currency, flexibility and low power. This section quantifies imize the overhead for module crossings. Since there are
basic aspects of resource usage and performance, including no virtual functions or address-space crossings, the basic
storage usage, execution overhead, observed concurrency, boundary crossing is at most a regular procedure call. On
and effectiveness of whole-system optimization. Atmel-based platforms, this costs about eight clock cycles.
Using whole-program analysis, nesC removes many of
3.1 Limited Resources these boundary crossings and optimizes entire call paths by
We look at three metrics to evaluate whether TinyOS ap- applying extensive cross-component optimizations, includ-
plications are lightweight in space and time: (1) the foot- ing constant propagation and common subexpression elim-
print of real applications should be small, (2) the compiler ination. For example, nesC can typically inline an entire
should reduce code size through optimization, and (3) the component into its caller.
overhead for fine-grain modules should be low. In the TinyOS timer component, triggering a timer event
 Cycles Optimized Unoptimized Reduction Component Type Data-race variables
Work 371 520 29% RandomLFSR System 1
Boundary crossing 109 258 57% UARTM System 1
Non-interrupt 8 194 95% AMStandard System 2
Interrupt 101 64 -36% AMPromiscious System 2
Total 480 778 38% BAPBaseM Application 2
ChirpM Application 2
Figure 7: Optimization effects on clock event handling. This MicaHighSpeedRadioM System 2
figure shows the breakdown, in CPU cycles, for both work TestTimerM Application 2
and boundary crossing for clock event handling, which requires ChannelMonC System 3
7 module crossings. Optimization reduces the overall cycle count NoCrcPacket System 3
by 38%. OscilloscopeM Application 3
QueuedSend System 3
SurgeM Application 3
SenseLightToLogM Application 3
crosses seven component boundaries. Figure 7 shows cy- TestTemp Application 3
MultihopM System 10
cle counts for this event chain with and without cross- eepromM System 17
component optimizations. The optimization saves not only TinyAlloc System 18
57% of the boundary overhead, but also 29% of the work, IdentC Application 23
Total 103
for a total savings of 38%. The increase in the crossing
overhead for the interrupt occurs because the inlining re- Figure 8: Component locations of race condition variables.
quires the handler to save more registers; however, the total
time spent in the handler goes down. The only remaining /* Contains a race: */ /* Fixed version: */
if (state == IDLE) { uint8_t oldState;
boundary crossing is the one for posting the task at the end state = SENDING; atomic {
of the handler. count++; oldState = state;
Anecdotally, the code produced via whole-program op- // send a packet if (state == IDLE) {
} state = SENDING;
timization is smaller and faster than not only unoptimized }
code, but also the original hand-written C code that pre- }
dates the nesC language. if (oldState == IDLE) {
count++;
// send a packet
3.2 Reactive Concurrency }

We evaluate TinyOS’s support for concurrency by looking Figure 9: Fixing a race condition in a state transition.
at four metrics: (1) the concurrency exhibited by applica-
tions, (2) our support for race detection at compile time, (3)
context switching times, and (4) the handling of concurrent Of these, 53 were false positives (discussed below) and
events with real-time constraints. 103 were genuine data races, a frequency of about six per
thousand code statements. We fixed each of these bugs by
Exhibited Concurrency: TinyOS’s component model
moving code into tasks or by using atomic statements. We
makes it simple to express the complex concurrent actions
then tested each application and verified that the presence
in sensor network applications. The sample applications in
of atomic sections did not interfere with correct operation.
Figure 6 have an average of 8 tasks and 47 events, each of
Figure 8 shows the locations of data races in the TinyOS
which represents a potentially concurrent activity. More-
tree. Half of the races existed in system-level components
over, these applications exhibit an average of 43% of the
used by many applications, while the other half were ap-
code (measured in bytes) reachable from an interrupt con-
plication specific. MultihopM, eepromM, and TinyAlloc
text.
had a disproportionate number of races due to the amount
As an example of a high-concurrency application, we of internal state they maintain through complex concurrent
consider TinyDB, covered in Section 5.3, an in-network operations. IdentC tracks node interactions, records them
query processing engine that allows users to pose queries in flash, and periodically sends them to the basestation; it
that collect, combine and filter data from a network of sen- has complex concurrency, lots of state, and was written be-
sors. TinyDB supports multiple concurrent queries, each of fore most of the concurrency issues were well understood.
which collects data from sensors, applies some number of The nesC version is race free.
transformations, and sends it up a multihop routing tree to The finite-state-machine style of decomposition in
a basestation where the user receives results. The 18 tasks TinyOS led to the most common form of bug, a non-atomic
and 193 events within TinyDB perform several concurrent state transition. State transitions are typically implemented
operations, such as maintenance of the routing tables, mul- using a read-modify-write of the state variable, which must
tihop routing, time synchronization, sensor recalibration, in be atomic. A canonical example of this race is shown in
addition to the core functionality of sampling and process- Figure 9, along with the fix.
ing sensor data. The original versions of the communication, TinyAl-
Race Detection: The nesC compiler reports errors if loc and EEPROM components contained large numbers of
shared variables may be involved in a data race. To evaluate variable accesses in asynchronous code. Rather than using
race detection, we examine the reported errors for accuracy. large atomic sections, which might decrease overall respon-
Initially, TinyOS included neither an explicit atomic siveness, we promoted many of the offending functions to
statement nor the analysis to detect potential race condi- synchronous code by posting a few additional tasks.
tions; both TinyOS and its applications had many data False positives fell into three major categories: state-
races. Once race detection was implemented, we applied based guards, buffer swaps, and causal relationships. The
detection to every application in the TinyOS source tree, first class, state-based guards, occurred when access to a
finding 156 variables that potentially had a race condition. module variable is serialized at run time by a state vari-
able. The above state transition example illustrates this; in Component Code Size Data Size
this function, the variable count is safe due to the moni- (Sizes in bytes) inlined noninlined
tor created by state. Buffer swaps are a controlled kind AM 456 654 9
of sharing in which ownership is passed between producer Core Active Messages layer
and consumer; it is merely by this convention that there are MicaHighSpeedRadioM 1162 1250 61
Radio hardware interface
no races, so it is in fact useful that nesC requires the pro-
NoCRCPacket 370 484 50
grammer to check them. The third class of false positives
Packet framing without CRC
occurs when an event conflicts with the code that caused it
CrcFilter – 34 0
to execute, but because the two never overlap in time there
CRC filtering
is no race. However, if there are other causes for the event,
ChannelMonC 454 486 9
then there is a race, so these are also worth explicitly check-
Start symbol detection
ing. In all cases, the norace type qualifier can be used to RadioTimingC 42 56 0
remove the warnings. Timing for start symbol detection
Context Switches: In TinyOS, context switch overhead PotM 50 82 1
corresponds to both the cost of task scheduling and in- Transmit power control
terrupt handler overhead. These costs are shown in Fig- SecDedEncoding 662 684 3
ure 10 based on hand counts and empirical measurements. Error correction/detection coding
The interrupt overhead consists of both switching overhead SpiByteFifoC 344 438 2
and function overhead of the handler, which varies with the Low-level byte interface
number of saved registers. HPLPotC – 66 0
Hardware potentiometer interface
Overhead Time (clock cycles) Figure 11: Breakdown of code and data size by component in
Interrupt Switching 8 the TinyOS radio stack. A ‘–’ in the inlined column indicates
Interrupt Handler Cost 26-74 that the corresponding component was entirely inlined. Dead
Task Switching 108
code elimination has been applied in both cases.
Figure 10: TinyOS scheduling overhead.

Real-time Constraints: The real-time requirements in the Fine-grained Components: TinyOS allows applications
sensor network domain are quite different from those tradi- to be constructed from a large number of very fine-grained
tionally addressed in multimedia and control applications. components. This approach is facilitated by cross-module
Rather than sophisticated scheduling to shed load when inlining, which avoids runtime overhead for component
many tasks are ongoing, sensor nodes exhibit bursts of ac- composition. The TinyOS codebase consists of 401 com-
tivity and then go idle for lengthy intervals. Rather than de- ponents, of which 235 are modules and 166 are configu-
livering a constant bit rate to each of many flows, we must rations. The 42 applications in the tree use an average of
meet hard deadlines in servicing the radio channel while 74 components (modules and configurations) each. Mod-
processing sensor data and routing traffic. Our initial plat- ules are typically small, ranging from between 7 and 1898
forms required that we modulate the radio channel bit-by- lines of code (with an average of 134, median of 81).
bit in software. This required tight timing on the transmitter Figure 11 shows a per-component breakdown of the data
to generate a clean waveform and on the receiver to sample and code space used by each of the components in the
each bit properly. More recent platforms provide greater TinyOS radio stack, both with and without inlining applied.
hardware support for spooling bits, but start-symbol detec- The figure shows the relatively small size of each of the
tion requires precise timing and encoding, decoding, and components, as well as the large number of components in-
error-checking must keep pace with the data rate. Our ap- volved in radio communication. Each of these components
proach of allowing sophisticated handlers has proven suffi- can be selectively replaced, or new components interposed
cient for meeting these requirements; typically the handler within the stack, to implement new functionality.
performs the time-critical work and posts a task for any re-
maining work. With a very simple scheduler, allowing the Concurrent Components: As discussed in the previous
handler to execute snippets of processing up the chain of section, any component can be the source of concurrency.
components allows applications to schedule around a set Bidirectional interfaces and explicit support for events en-
of deadlines directly, rather than trying to coerce a prior- able any component to generate events autonomously. In
ity scheme to produce the correct ordering. More critical addition, the static race detection provided by nesC re-
is the need to manage the contention between the sequence moves the need to worry about concurrency bugs dur-
of events associated with communication (the handler) and ing composition. Out of our current set of 235 modules,
the sampling interval of the application (the tasks). Ap- 18 (7.6%) contain at least one interrupt handler and are
plying whole-system analysis to verify that all such jitter thereby sources of concurrency.
bounds are met is an area for future work. Hardware/Software Transparency: The TinyOS compo-
nent model makes shifting the hardware/software boundary
3.3 Flexibility easy; components can generate events, which may be soft-
To evaluate the goal of flexibility, we primarily refer to ware upcalls or hardware interrupts. This feature is used
anecdotal evidence. In addition to the quantitative goal in several ways in the TinyOS codebase. Several hardware
of fine-grain components, we look at the qualitative goals interfaces (such as analog-to-digital conversion) are imple-
of supporting concurrent components, hardware/software mented using software wrappers that abstract the complex-
transparency, and interposition. ity of initializing and collecting data from a given sensor
hardware component. In other cases, software components mand causes a component to attempt to minimize its power
(such as radio start-symbol detection) have been supplanted consumption, for example, by powering down hardware or
with specialized hardware modules. For example, each of disabling periodic tasks. The component saves its state in
the radios we support has a different hardware/software RAM or in nonvolatile memory for later resumption using
boundary, but the same component structure. the start command. It also informs the CPU about the
Interposition: One aspect of flexibility is the ability to in- change in the resources it uses; the system then uses this
terpose components between other components. Whenever information to decide whether deep power saving modes
a component provides and uses the same interface type, it should be used. This strategy works well: with all com-
can be inserted or removed transparently. ponents stopped, the base system without the sensor board
One example of this is seen in work at UVA [26], which consumes less than 15 µA, which is comparable to self dis-
interposes a component in the network stack at a fairly low charge rate of AA alkaline batteries. The node lifetime de-
level. Unknown to the applications, this component buffers pends primarily on the duty cycle and the application re-
the payload of each message and aggregates messages to quirements; a pair of AA batteries can power a constantly
the same destination into a single packet. On the receive active node for up to 15 days or a permanently idle node for
side, the same component decomposes such packets and up to 5 years (battery shelf life). By exposing the start/stop
passes them up to the recipients individually. Although interface at many levels, we enable a range of power man-
remaining completely transparent to the application, this agement schemes to be implemented, for example, using
scheme can actually decrease network latency by increas- power scheduling to disable the radio stack when no com-
ing overall bandwidth. munication is expected, or powering down sensors when
A similar type of interpositioning can be seen in the ob- not in use.
ject tracking application described in Section 5.2. The rout- Hardware/Software Transparency: The ability to re-
ing stack allows the interpositioning of components that en- place software components with efficient hardware imple-
able, for example, reliable transmission or duplicate mes- mentations has been exploited to yield significant improve-
sage filtering. Similarly, the sensor stacks allow the inter- ments in energy consumption in our platform. Recent
positioning of components that implement weighted-time work [36] has demonstrated a single-chip mote that inte-
averaging or threshold detection. grates the microcontroller, memory, radio transceiver, and
radio acceleration logic into a 5 mm2 silicon die. The
3.4 Low Power standard software radio stack consumes 3.6 mA (involving
The application-specific nature of TinyOS ensures that about 2 million CPU instructions per second); The hard-
no unnecessary functions consume energy, which is the ware implementation of these software components con-
most precious resource on the node. However, this as- sumes less than 100 µA and allows for much more efficient
pect alone does not ensure low power operation. We exam- use of microcontroller sleep modes while providing a 25-
ine three aspects of TinyOS low power operation support: fold improvement in communication bit rate.
application-transparent CPU power management, power
management interfaces, and efficiency gains arising from 4 Enabled Innovations
hardware/software transparency. A primary goal for TinyOS is to enable innovative solu-
CPU power usage: The use of split-phase operations tions to the systems challenges presented by networks of
and an event-driven execution model reduces power usage resource constrained devices that interact with a chang-
by avoiding spinlocks and heavyweight concurrency (e.g., ing physical world. The evaluation against this goal is in-
threads). To minimize CPU usage, the TinyOS scheduler herently qualitative. We describe three subsystems where
puts the processor into a low-power sleep mode whenever novel approaches have been adopted that can be directly
the task queue is empty. This decision can be made very related to the features of TinyOS. In particular, TinyOS
quickly, thanks to run-to-completion semantics of tasks, makes several kinds of innovations simpler that appear in
which maximizes the time spent in the sleep mode. For these examples: 1) cross-layer optimization and integrated-
example, when listening for incoming packets, the CPU layer processing (ILP), 2) duty-cycle management for low
handles 20000 interrupts per second. On the current sen- power, and 3) a wide-range of implementation via fine-
sor hardware, the CPU consumes 4.6 mA when active and grain modularity.
2.4 mA when idle, and the radio uses 3.9 mA when re-
ceiving. System measurements show the power consump- 4.1 Radio Stack
tion during both listening and receiving to be 7.5 mA. The A mote’s network device is often a simple, low-power radio
scheduler, which needs to examine the task queue after ev- transceiver that has little or no data buffering and exposes
ery event, still manages to operate in idle mode 44% of the primitive control and raw bit interfaces. This requires han-
time. dling many aspects of the radio in software, such as control-
Power-Management Interfaces: The scheduler alone ling the radio state, coding, modulating the channel, fram-
cannot achieve the power levels required for long-term ap- ing, input sampling, media access control, and checksum
plications; the application needs to convey its runtime re- processing. Various kinds of hardware acceleration may be
quirements to the system. TinyOS address this requirement provided for each of the elements, depending on the spe-
through a programming convention which allows subsys- cific platform. In addition, received signal strength can be
tems to be put in a low power idle state. Components ex- obtained by sampling the baseband energy level at partic-
pose a StdControl interface, which includes commands ular times. The ability to access these various aspects of
for initializing, starting, and stopping a component and the the radio creates opportunities for unusual cross-layer opti-
subcomponents it depends upon. Calling the stop com- mization.
Integrated-Layer Processing: TinyOS enables ILP Hardware/Software Transparency: The existence of a
through its combination of fine-grain modularity, whole- variety of radio architectures poses a challenge for system
program optimization, and application-specific handlers. designers due to the wide variation in hardware/software
One example is the support for link-layer acknowledg- boundaries. There are at least three radio platforms that
ments (acks), which can only be generated after the check- are supported in the TinyOS distribution: the 10kbps first-
sum has been computed. TinyOS allows the radio stack generation RFM, the 40kbps hardware-accelerated RFM,
to be augmented with addition error checking by simply and the recent 40kbps Chipcon. In addition, UART and
interposing the checksum component between the compo- I2C stacks are supported. The hardware-accelerated RFM
nent providing byte-by-byte radio spooling and the packet platform exemplifies how a direct replacement of bit level
processing component. It is also important to be able to processing with hardware achieves higher communication
provide link-level acknowledgments so that higher levels bandwidth [29]. In the extreme cases, the entire radio
can estimate loss rates or implement retransmission, how- stack has been built in pure hardware in spec (mote-on-
ever, these acks should be very efficient. The event protocol a-chip) [36], as well as in pure software in TOSSIM [44].
within the stack that was developed to avoid buffering at We have also transparently used hardware acceleration for
each level allows the checksum computation to interleave encryption. Stack elements using a component remain un-
with the byte-level spooling. Thus, the ack can be gener- changed, whether the component is a thin abstraction of a
ated immediately after receiving the last byte thus the un- hardware element or a software implementation.
derlying radio component can send the ack synchronously,
i.e. reversing the channel direction without re-arbitration or
reacquisition. Note that holding the channel is a real-time
operation that is enabled by the use of sophisticated han- 4.2 Time Synchronization and Ranging
dlers that traverse multiple layers and components without
data races. This collection of optimizations greatly reduce Time and location are both critical in sensor networks due
both latency and power, and in turn allows shorter timeouts to the embodied nature of sensor nodes; each node has
at the sender. Clean modularity is preserved in the code a real, physical relationship with the outside world. One
since these time-critical paths span multiple components. challenge of network time synchronization is to eliminate
sources of jitter such as media access delay introduced by
ILP and flexible modularity have been used in a simi-
the radio stack. Traditional layering often hides the de-
lar manner to provide flexible security for confidentiality
tails at the physical layer. Timing protocols often per-
and authentication [2]. Although link-level security is im-
form round-trip time estimation to account for these errors.
portant, it can degrade both power and latency. The abil-
TinyOS allows a component to be interposed deep within
ity to overlap computation via ILP helps with the latency,
the radio stack to signal an event precisely when the first
while interposition makes it easy add security transparently
bit of data is transmitted; this eliminates media access de-
as needed. This work also showed that the mechanisms for
lay from calculations. Similarly, receivers can take a times-
avoiding copying or gather/scatter within the stack could
tamp when they hear the first data bit; comparing these fine-
be used to substantially modify packet headers and trailers
grain timestamps can reduce time synchronization error to
without changing other components in the stack.
less than a bit time (<25µs). Although reference broad-
A TinyOS radio stack from Ye et al. [83, 84] is an ex- cast synchronization (RBS) [16] achieves synchronization
ample that demonstrates ILP by combining 802.11-style accurate to within 4µs without interposition by comparing
media access with transmission scheduling. This allows time stamps of receivers, it does so at the cost of many
a low-duty cycle (similar to TDMA) with flexible channel packet transmissions and sophisticated analysis.
sharing.
The ability to interact with the network stack at this low
Power Management: Listening on the radio is costly even
level also enabled precise time of flight (TOF) measure-
when not receiving anything, so minimizing duty cycle
ments for ranging in an ad-hoc localization system built on
is important. Traditional solutions utilize some form of
TinyOS [76]. A transmitter sends an acoustic pulse with a
TDMA to turn off the radio for long periods until a recep-
radio message. TinyOS’s low context switching overhead
tion is likely. TinyOS allows a novel alternative by sup-
enables receivers to check for the acoustic pulse and the ra-
porting fast fine-grain power management. By integrating
dio message concurrently. Taking the difference between
fast power management with precise timing, we were able
the timestamps of the two signals produces an acoustic
to periodically sample the radio for very short intervals at
TOF measurement. TinyOS can accurately measure both
the physical layer, looking for a preamble. This yields the
arrival times directly in their event handlers, since the han-
illusion of an always-on radio at a 10% duty cycle while lis-
dlers execute immediately; a solution based on queuing the
tening, while avoiding a priori partitioning of the channel
work for later would forfeit precise timing, which is also
bandwidth. Coarse-grain duty cycling can still be imple-
true for the time-syncrhonization example above.
mented at higher levels, if needed.
TinyOS has also enabled an efficient solution to the epi- The newest version of the ranging application uses a
demic wakeup problem. Since functionality can be placed co-processor to control the acoustic transducer and per-
at different levels within the radio stack, TinyOS can detect form costly localization calculation. Controlling the acous-
that a wakeup is likely by sampling the energy on the chan- tic transducer requires real time interactions between the
nel, rather than bring up the ability to actually receive pack- two processors which is enabled by TinyOS’s low over-
ets. This low-level wake-up only requires 0.00125% duty head event handling. To exploit parallelism between the
cycle [29], a 400-fold improvement over a typical packet- two processors, computation and communication must be
level protocol. A similar approach has been used to derive overlapped; the split-phased nature of TinyOS’s AM model
network neighborhood and proximity information [73]. makes this trivial.
4.3 Routing
The rigid, non-application specific communication stack
found in industrial standards such as IEEE 802.11 [1] or
Bluetooth [7] often limit the design space for routing proto-
cols. TinyOS’s component model and ease of interposition
yield a very flexible communication stack. This opens up
a platform for implementing many different routing pro-
tocols such as broadcast based routing [23], probabilistic
routing, multipath routing [37], geographical routing, reli-
ability based routing [80, 82], TDMA based routing [14],
and directed diffusion [34].
The large number of routing protocols suggests that sen-
sor network applications may need to use a diverse set
within one communication stack. TinyOS’s parameterized
interfaces and extensible component model enable a coher-
ent routing framework where an application can route by Figure 12: System architecture for habitat monitoring.
network address, geographic location, flooding, or along
some application specific gradients [69].
networks might better be served by a lean bytecode inter-
4.4 Dynamic Composition and Virtual Ma- preter that sits on top of a TinyOS substrate.
chines
In our experience, most sensor network applications uti-
5 Applications
lize a common set of services, combined in different ways. In this section, we describe three applications that have
A system that allows these compositions to be concisely been built using the TinyOS platform: an environmen-
described could provide much of the flexibility of full tal monitoring system, a declarative query processor, and
reprogramming at a tremendous decrease in communica- magnetometer-based object tracking. Each of these appli-
tion costs. Maté, a tiny bytecode interpreter that runs on cations represents a distinct set of design goals and exhibits
TinyOS [43], meets this need. It is a single nesC module different aspects of the TinyOS design.
that sits on top of several system components, including
sensors, the network stack, and non-volatile storage. 5.1 Habitat Monitoring
Maté presents a virtual stack architecture to the pro- Sensor networks enable data collection at a scale and res-
grammer. Instructions include sensing and radio communi- olution that was previously unattainable, opening up many
cation, as well as arithmetic and stack manipulation. Maté new areas of study for scientists. These applications pose
has a set of user-definable instructions. These allow devel- many challenges, including low-power operation and ro-
opers to use the VM as a framework for writing new VM bustness, due to remote placement and extended operation.
variants, extending the set of TinyOS services that can be One such application is a habitat monitoring system on
dynamically composed. The virtual architecture hides the Great Duck Island, off the coast of Maine. Researchers
split-phased operations of TinyOS behind synchronous in- deployed a 35-node network on the island to monitor the
structions, simplifying the programming interface. This re- presence of Leach’s Storm Petrels in their underground bur-
quires the VM to maintain a virtual execution context as rows [51]. The network was designed to run unattended for
a continuation across split-phase operations. The stack- at least one field season (7–9 months). Nodes, placed in
based architecture makes virtual context switches trivial, burrows, monitored light, temperature, relative humidity,
and as contexts are only 78 bytes (statically allocated in a pressure, and passive infrared; the network relayed read-
component), they consume few system resources. Contexts ings back to a base station with an Internet connection via
run in response to system events, such as timers or packet satellite, to be uploaded to a database. Figure 12 illustrates
reception. the tiered system architecture for this application.
Programs virally propagate through a network; once A simple TinyOS program ran on the motes. It peri-
a user introduces a single mote running a new program, odically (every 68 s) sampled sensors and relayed data to
the network rapidly and autonomously reprograms itself. the base-station. To achieve long network lifetimes, nodes
Maté programs are extremely concise (orders of magnitude used the power management facilities of TinyOS aggres-
shorter than their binary equivalents), conserving commu- sively, consuming only 35 µA in low power state, com-
nication energy. TinyOS’ event-driven execution provides pared to 18–20 mA when active. Nodes sampled sensors
a clear set of program-triggering events, and the nesC’s in- concurrently (using a split-phase data acquisition opera-
terfaces allow users to easily change subsystems (such as tion), rather than serially, resulting in further power reduc-
ad-hoc routing). Maté extends TinyOS by providing an in- tion. During the 4 months of deployment, the network col-
expensive mechanism to dynamically compose programs. lected over 1.2 million sensor readings.
nesC’s static nature allows it to produce highly optimized A specialized gateway node, built using a mote con-
and efficient codes; Maté demonstrates that run-time flexi- nected to a high-gain antenna, relayed data from the net-
bility can be re-introduced quite easily with low overhead. work to a wired base station. The gateway application
By eschewing aside the traditional user/kernel boundary, was very small (3090 bytes) and extraordinarily robust: it
TinyOS allowed other possibilities to emerge. Maté sug- ran continuously, without failing, for the entire 4 months
gests that the run-time/compile-time boundary in sensor of deployment. The gateway required just 2 Watt-hours
 Event−triggered Activity in Z−Racer
6

of energy per day and was recharged with a 36 in2 solar 1) Z−Racer drives
panel [63]. In comparison, an early prototype version 5of (5,1) (5,2) (5,3) (5,4) (5,5)
the gateway, an embedded Linux system, required over 60
Watt-hours of energy per day from a 924 in2 solar panel. 2) Broadcast detections
The Linux system failed every 2 to 4 days, while the gate-
4 (4,1) (4,2) (4,3) (4,4) (4,5)
way mote was still operating two months after researchers
lost access to the island for the winter.

5.2 Object Tracking 3 (3,1) (3,2) (3,3) (3,4) (3,5)

3) Send position to
The TinyOS object-tracking application (OTA) uses a sen- camera
sor network to detect, localize and track an object mov-
(2,1) (2,2) (2,3) (2,4) (2,5)
ing through a sensor field; in the prototype, the object 2is
a remote-controlled car. The object’s movement through
the field determines the actions and communication of the
motes. Each mote periodically samples its magnetometer; 1 (1,1) (1,2) (1,3) (1,4) (1,5)
if the reading has changed significantly since the last sam- Figure 13: Event-triggered activity in the object tracking ap-
ple, it broadcasts the reading to its neighbors. The node plication. (1) The vehicle being tracked drives around position
with the largest reading change estimates the position 0of (4,4) (dashed-line); (2) Six nodes broadcast readings (lightened
0 1 (3) Node 2(4,4) declares
3 itself the4leader, aggregates
5 6
the target by computing the centroid of its neighbors’ read- nodes); the
ings. Using geographic routing [38], the network routes readings, and routes them to the base station (dark arrows).
the estimated position to the base-station, which controls a
camera to point at the target. The operation of the tracking
application is shown in Figure 13.
OTA consists of several distributed services, such as the query:
routing, data sharing, time synchronization, localization, SELECT AVG(light)
FROM sensors
power management, and sensor filtering. Twelve different WHERE temp > 100o F
research groups are collaborating on both the architecture SAMPLE PERIOD 10s
and individual subsystem implementation. TinyOS execu-
tion model enables running these services concurrently on tells the network to provide the average light value
limited hardware resources. The component model allows over all the nodes with temperature greater than 100o
for easy replacement and comparative analysis of individ- F once every 10 seconds. TinyDB uses in-network
ual services. Currently, the reference implementation con- aggregation [42, 49] to greatly reduce network bandwidth
sists of 54 components. General purpose services, such as requirements; this requires that nodes coordinate to
time synchronization or localization, have many competing produce the results.
implementations, enabled by different features of TinyOS.
Replacement of low-level components used for sensing al- TinyDB relies heavily on TinyOS’component-oriented
lowed OTA to be adapted to track using light values instead design, concurrency primitives, and ability to perform
of magnetic fields. cross-layer optimizations. TinyDB consists of components
that perform query flooding, local data collection, forma-
Several research groups have successfully implemented
tion of routing trees, aggregation of query data, and a cat-
application specific services within this framework. Hui
alog of available sensor devices and attributes (such as lo-
et al. developed a sentry-based approach [31] that ad-
cation) at each node. It uses the routing, data collection,
dresses power management within an object tracking net-
and power management interfaces of TinyOS, and inter-
work. Their algorithm chooses a connected subset of sentry
operates with a variety of implementations of these ser-
motes, which allows for degraded sensing; the non-sentry
vices.
units are placed in a low power state. This service makes
extensive use of the TinyOS power management interfaces, TinyOS’s task model meshes well with the concurrency
and is shown to reduce energy consumption by 30% with requirements of TinyDB, which supports multiple simulta-
minimal degradation of tracking accuracy. neous queries by scheduling a timer for each query which
fires when the next set of results for that query are due.
5.3 TinyDB Each timer event posts a task to collect and deliver results
Many sensor network users prefer to interact with a net- for the corresponding query. The non-preemptive nature
work through a high-level, declarative interface rather of tasks and the support for safe concurrent handlers avoid
than by low-level programming of individual nodes. data races despite extensive information sharing.
TinyDB [50], a declarative query processor built on One example benefit of cross-layer optimization in
TinyOS, supports this view, and is our largest and most TinyDB is message snooping, which is important for de-
complex application to date. It poses significant challenges termining the state of neighboring nodes in the network.
for concurrency control and limited resources. Snooping is used to enable query propagation: new nodes
In TinyDB, queries (expressed in an SQL-like syntax) joining the network learn of ongoing queries by snooping
propagate through the network and perform local data col- for results broadcast by neighbors. This technique also en-
lection and in-network aggregation. Queries specify only ables message suppression; a node can avoid sending its
what data the user is interested in and the data collection local reading if it is superseded by a message from another
rate; the user does not specify any details of query propa- node, as in the case of a query requesting the maximum
gation, data collection, or message routing. For example, sensor value in the network.
6 Related Work not address the specific needs of low-power, low-resource
Sensor networks have been the basis for work on ad hoc embedded systems. The units [19] component model, sup-
networking [34, 37, 38, 47], data aggregation [33, 49], dis- ported by the Knit [67] language in OSKit [20], is similar
tributed algorithms [25, 46, 59], and primitives such as lo- to that in nesC. In Knit, components provide and use inter-
calization [8, 76, 77], and time synchronization [16, 62]. In faces, and new components can be assembled out of exist-
addition to our mote platform, a number of low-power sen- ing ones. Unlike nesC, however, Knit lacks bidirectional
sor systems have been proposed and developed [3, 4, 12, interfaces and static analyses such as data race detection.
39, 55, 56, 64], though few of these systems have addressed Several embedded systems have taken a component-
flexible operating systems design. Several projects use oriented approach for application-specific configurabil-
more traditional embedded systems (such as PDAs [16]) ity [21]. Many of these systems use heavyweight compo-
or customized hardware [64]. sition mechanisms, such as COM or CORBA, and several
A wide range of operating systems have been devel- support runtime component instantiation or interposition-
oped for embedded systems. These range from relatively ing. PURE [6], eCos [66], and icWORKSHOP [35] more
large, general-purpose systems to more compact real-time closely match TinyOS’s goal of lightweight, static compo-
executives. In [30] we discuss range of these embedded sition. These systems consist of a set of components that
and real-time systems in detail. These systems are gener- are wired together (either manually or using a composition
ally not suitable for extremely resource-constrained sensor tool) to form an application. Components vary in size from
nodes, which mandate very compact, specialized OS de- fine-grained, specialized objects (as in icWORKSHOP) to
signs. Here, we focus our attention on a number of emerg- larger classes and packages (PURE and eCos). VEST [70]
ing systems that more closely match the resource budget is a proposed toolkit for building component-based embed-
and execution model of sensor networks. ded systems that performs extensive static analyses of the
system, such as schedulability, resource dependencies, and
Traditional embedded operating systems are typically
interface type-checking.
large (requiring hundreds of KB or more of memory),
general-purpose systems consisting of a binary kernel with
a rich set of programming interfaces. Examples include 7 Discussion, Future Work, and Conclusion
WinCE [52], QNX [28], PalmOS [60], pSOSystem [79], Sensor networks present a novel set of systems challenges,
Neutrino [65], OS-9 [54], LynxOS [48], Symbian [71], and due to their need to react to the physical environment, to
uClinux [72]. Such OSes target systems with greater CPU let nodes asynchronously communicate within austere re-
and memory resources than sensor network nodes, and gen- source constraints, and to operate under a very tight energy
erally support features such as full multitasking, memory budget. Moreover, the hardware architectures in this new
protection, TCP/IP networking, and POSIX-standard APIs area are changing rapidly. When we began designing an
that are undesirable (both in terms of overhead and gener- operating system for sensor nets we believed that the lay-
ality) for sensor network nodes. ers and boundaries that have solidified over the years from
There is also a family of smaller real-time executives, mainframes to laptops were unlikely to be ideal. Thus, we
such as CREEM [40], OSEKWorks [78], and Ariel [53], focused on building a framework for experimenting with
that are closer in size to TinyOS. These systems support a a variety of system designs so that the proper boundaries
very restrictive programming model which is tailored for could emerge with time. The key elements being a rich
specialized application domains such as consumer devices component approach with bidirectional interfaces and en-
and automotive control. capsulated tasks, pervasive use of event-based concurrency,
Several other small kernels have been developed that and whole-system analysis and optimization. It has been
share some features in common with TinyOS. These sys- surprising just how varied those innovations are.
tems do not support the degree of modularity or flexibil- Reflecting on the experience to date, the TinyOS’ com-
ity in TinyOS’s design, nor have they been used for as ponent approach has worked well. Components see a great
wide a range of applications. EMERALDS [85] is a real- deal of re-use and are generally defined with narrow yet
time microkernel, requiring about 13KB of code, that sup- powerful interfaces. nesC’s optimizations allow develop-
ports multitasking using a hybrid EDF and rate-monotonic ers to use many fine-grained components with little penalty.
scheduler. Much of this work is concerned with reducing This has facilitated experimentation, even with core sub-
overheads for semaphores and IPC. AvrX [5] is a small systems, such as the networking stack. Some developers
kernel for the AVR processor, written in assembly, that experience initial frustration with the overhead of building
provides multitasking, semaphores, and message queues in components with a closed namespace, rather than just call-
around 1.5 KB of memory. Nut/OS [15] and NESOS [58] ing library routines, but this is compensated by the ease
are small kernels that provide non-preemptive multitask- of interpositioning, which allows them to introduce simple
ing, similar in vein to the TinyOS task model, but use some- extensions with minimal overhead.
what more expensive mechanisms for interprocess commu- The resource-constrained event-driven concurrency
nication than TinyOS’s lean cross-module calls. The BTN- model has been remarkably expressive and remains almost
ode OS [39] consists mainly of library routines to interface unchanged from the first version of the OS. We chose the
to hardware and a Bluetooth communication stack, but sup- task/event distinction because of its simplicity and mod-
ports an event-driven programming model akin to TinyOS. est storage demands, fully expecting that something more
Modules can post a single-byte event to a dispatcher, which sophisticated might be needed in the future. Instead, it
fires the (single) handler registered for that event type. has been able to express the degree of concurrency re-
A number of operating systems have explored the use of quired for a wide range of applications. However, the me-
component architectures. Click [41], Scout [57], and the x- chanics of the approach have evolved considerably. Ear-
kernel [32] are classic examples of modular systems, but do lier versions of TinyOS made no distinction between asyn-
chronous and synchronous code and provided inadequate References
support for eliminating race conditions, many of which [1] ANSI/IEEE Std 802.11 1999 Edition.
were exceedingly difficult to find experimentally. At one [2] TinySec: Link Layer Security for Tiny Devices. http://www.cs.
point, we tried introducing a hard boundary to AC, so all berkeley.edu/˜nks/tinysec/.
“user” processing would be in tasks. This made it impossi- [3] G. Asada, M. Dong, T. Lin, F. Newberg, G. Pottie, W. Kaiser, and H. Marcy.
ble to meet the real-time requirements of the network stack, Wireless integrated network sensors: Low power systems on a chip. 1998.
and the ability to perform a carefully designed bit of pro- [4] B. Atwood, B. Warneke, and K. S. Pister. Preliminary circuits for smart dust.
cessing within the handler was sorely missed. The frame- In Proceedings of the 2000 Southwest Symposium on Mixed-Signal Design,
San Diego, California, February 27-29 2000.
work for innovation concept led us to better support for
building (via atomic sections) the low-level concurrent data [5] L. Barello. Avrx real time kernel. http://www.barello.net/avrx/.
structures that cleanly integrate information from the asyn- [6] D. Beuche, A. Guerrouat, H. Papajewski, W. Schröder-Preikschat,
O. Spinczyk, and U. Spinczyk. The PURE family of object-oriented oper-
chronous external world up into local processing. This par- ating systems for deeply embedded systems. In Proceedings of the 2nd IEEE
ticularly true for low-level real-time operations that cannot International Symposium on Object-Oriented Real-Time Distributed Comput-
be achieved without sophisticated handlers. ing, 1999.
[7] Bluetooth SIG, Inc. http://www.bluetooth.org.
TinyOS differs strongly from most event-driven embed- [8] N. Bulusu, V. Bychkovskiy, D. Estrin, and J. Heidemann. Scalable, ad hoc
ded systems in that concurrency is structured into modular deployable, rf-based localization. In Proceedings of the Grace Hopper Con-
components, instead of a monolithic dispatch constructed ference on Celebration of Women in Computing, Vancouver, Canada, October
with global understanding of the application. Not only has 2002.
this eased the conceptual burden of managing the concur- [9] D. W. Carman, P. S. Kruus, and B. J. Matt. Constraints and approaches for dis-
tributed sensor network security. NAI Labs Technical Report #00-010, Septem-
rency, it has led to important software protocols between ber 2000.
components, such as split-phase data acquisition, data- [10] Center for Information Technology Research in the Interest of Society. Smart
pumps found between components in the network stack, buildings admit their faults. http://www.citris.berkeley.edu/
and a power-management idiom that allows hardware ele- applications/disaster_response/smartbuil%dings.html,
ments to be powered-down quickly and easily. In a number 2002.
of cases, attention to these protocols provided the benefits [11] A. Cerpa, J. Elson, D. Estrin, L. Girod, M. Hamilton, and J. Zhao. Habitat
monitoring: Application driver for wireless communications technology. In
of integrated-layer processing while preserving clean mod- Proceedings of the Workshop on Data Communications in Latin America and
ularity. the Caribbean, Apr. 2001.
[12] L. P. Clare, G. Pottie, and J. R. Agre. Self-organizing distributed mi-
TinyOS is by no means a finished system; it contin- crosensor networks. In SPIE 13th Annual International Symposium on
ues to evolve and grow. The use of language tools for Aerospace/Defense Sensing, Simulation, and Controls (AeroSense), Unat-
whole-system optimization is very promising and should tended Ground Sensor Technologies and Applications Conference, Apr. 1999.
be taken further. Currently, components follow implicit [13] R. Deline and M. Fahndrich. Enforcing High-level Protocols in Low-Level
software protocols; making these protocols explicit entities Software. In Proceedings of the ACM SIGPLAN ’01 Conference on Program-
ming Language Design and Implementation, June 2001.
would allow the compiler to verify that components are be-
[14] L. Doherty, B. Hohlt, E. Brewer, and K. Pister. SLACKER. http://
ing properly used. Examples of these protocols include the www-bsac.eecs.berkeley.edu/projects/ivy/.
buffer-swapping semantics of the networking stack and the
[15] egnite Software GmbH. Nut/OS. http://www.ethernut.de/en/
state sequencing in the control protocols. Parallels exist be- software.html.
tween our needs and work such as Vault [13] and MC [17]. [16] J. Elson, L. Girod, and D. Estrin. Fine-grained network time synchronization
using reference broadcasts. In Fifth Symposium on Operating Systems Design
Richer means of expressing composition are desirable. and Implementation (OSDI 2002), Boston, MA, USA., dec 2002.
For instance, while developing a routing architecture, we [17] D. Engler, B. Chelf, A. Chou, and S. Hallem. Checking system rules using sys-
found that layers in the stack required significant self- tem specific, programmer-written compiler extensions. In Proceedings of the
consistency and redundancy in their specifications. A sim- Fourth Symposium on Operating Systems Design and Implementation., Oct.
2000.
ple example is the definition of header fields when multiple
layers of encapsulation are provided in the network stack. [18] D. Estrin et al. Embedded, Everywhere: A Research Agenda for Networked
Systems of Embedded Computers. National Acedemy Press, Washington, DC,
We have explored template wiring, which defines a skele- USA, 2001.
ton structure, behaviors of composition, and naming con- [19] M. Flatt and M. Felleisen. Units: Cool modules for HOT languages. In Pro-
ventions into which stackable components can be inserted. ceedings of the ACM SIGPLAN ’98 Conference on Programming Language
A template wiring produces a set of modules and config- Design and Implementation, pages 236–248, 1998.
urations that meet the specification; it merges component [20] B. Ford, G. Back, G. Benson, J. Lepreau, A. Lin, and O. Shivers. The flux OS-
composition and creation into a single step. We expect to Kit: A substrate for kernel and language research. In Symposium on Operating
Systems Principles, pages 38–51, 1997.
incorporate these higher-level models of composition into
nesC and TinyOS as they become more clear and well de- [21] L. F. Friedrich, J. Stankovic, M. Humphrey, M. Marley, and J. J.W. Haskins.
A survey of configurable component-based operating systems for embedded
fined. applications. IEEE Micro, May 2001.
[22] D. Ganesan. TinyDiffusion Application Programmer’s Interface API 0.1.
We continue to actively develop and deploy sensor net- http://www.isi.edu/scadds/papers/tinydiffusion-v0.
work applications; many of our design decisions have been 1.pdf.
based on our and other users’ experiences with these sys- [23] D. Ganesan, B. Krishnamachari, A. Woo, D. Culler, D. Estrin, and S. Wicker.
tems in the field. Sensor networks are still a new domain, An empirical study of epidemic algorithms in large scale multihop wireless
filled with unknowns and uncertainties. TinyOS provides networks. citeseer.nj.nec.com/ganesan02empirical.html,
2002. Submitted for publication, February 2002.
an efficient, flexible platform for developing sensor net-
work algorithms, systems, and full applications. It has en- [24] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The
nesC language: A holistic approach to networked embedded systems. In Pro-
abled innovation and experimentation on a wide range of ceedings of Programming Language Design and Implementation (PLDI), June
scale. 2003.
[25] I. Gupta and K. Birman. Holistic operations in large-scale sensor network [48] LynuxWorks. LynxOS 4.0 Real-Time Operating System. http://www.
systems: A probabilistic peer-to-peer approach. In Proceedings of Interna- lynuxworks.com/.
tional Workshop on Future Directions in Distributed Computing (FuDiCo),
[49] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. TAG: A Tiny
June 2002.
AGgregation Service for Ad-Hoc Sensor Networks. In OSDI, 2002.
[26] T. Ha, B. Blum, J. Stankovic, and T. Abdelzaher. AIDA: Application Indepen- [50] S. Madden, W. Hong, J. Hellerstein, and M. Franklin. TinyDB web page.
dant Data Aggregation in Wireless Sensor Networks. Submitted to Special http://telegraph.cs.berkeley.edu/tinydb.
Issue of ACM TECS, January 2003.
[51] A. Mainwaring, J. Polastre, R. Szewczyk, D. Culler, and J. Anderson. Wireless
[27] J. S. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan, D. Estrin, and sensor networks for habitat monitoring. In ACM International Workshop on
D. Ganesan. Building efficient wireless sensor networks with low-level nam- Wireless Sensor Networks and Applications (WSNA’02), Atlanta, GA, USA,
ing. In Proceedings of the 18th ACM Symposium on Operating Systems Prin- Sept. 2002.
ciples, Banff, Canada, October 2001.
[52] Microsoft Corporation. Microsoft Windows CE. http://www.
[28] D. Hildebrand. An Architectural Overview of QNX. http://www.qnx. microsoft.com/windowsce/embedded/.
com/literature/whitepapers/archoverview.html.
[53] Microware. Microware Ariel Technical Overview. http://www.
[29] J. Hill and D. E. Culler. Mica: a wireless platform for deeply embedded net- microware.com/ProductsServices/Technologies/ariel_
works. IEEE Micro, 22(6):12–24, nov/dec 2002. technology_bri%ef.html.
[30] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler, and K. S. J. Pister. [54] Microware. Microware OS-9. http://www.microware.com/
System architecture directions for networked sensors. In Architectural Support ProductsServices/Technologies/os-91.html.
for Programming Languages and Operating Systems, pages 93–104, Boston,
[55] Millenial Net. http://www.millennial.net/.
MA, USA, Nov. 2000.
[56] R. Min, M. Bhardwaj, S.-H. Cho, N. Ickes, E. Shih, A. Sinha, A. Wang, and
[31] J. Hui, Z. Ren, and B. H. Krogh. Sentry-based power management in wireless
A. Chandrakasan. Energy-centric enabling technologies for wireless sensor
sensor networks. In Proceedings of Second International Workshop on Infor-
networks. 9(4), August 2002.
mation Processing in Sensor Networks (IPSN ’03), Palo Alto, CA, USA, Apr.
2003. [57] D. Mosberger and L. Peterson. Making paths explicit in the Scout operating
system. In Proceedings of the USENIX Symposium on Operating Systems De-
[32] N. C. Hutchinson and L. L. Peterson. The x-kernel: An architecture for im- sign and Implementation 1996, October 1996.
plementing network protocols. IEEE Transactions on Software Engineering,
17(1):64–76, 1991. [58] Nilsen Elektronikk AS. Nilsen Elektronikk Finite State Machine Operating
System. http://www.ethernut.de/en/software.html.
[33] C. Intanagonwiwat, D. Estrin, R. Govindan, and J. Heidemann. Impact of net-
work density on data aggregation in wireless sensor networks. In Proceedings [59] R. Nowak and U. Mitra. Boundary estimation in sensor networks: Theory
of the International Conference on Distributed Computing Systems (ICDCS), and methods. In Proceedings of 2nd International Workshop on Information
July 2002. Processing in Sensor Networks, Palo Alto, CA, April 2003.

[34] C. Intanagonwiwat, R. Govindan, and D. Estrin. Directed diffusion: a scal- [60] Palm, Inc. PalmOS Software 3.5 Overview. http://www.palm.com/
able and robust communication paradigm for sensor networks. In Proceedings devzone/docs/palmos35.html.
of the International Conference on Mobile Computing and Networking, Aug. [61] A. Perrig, R. Szewczyk, V. Wen, D. Culler, and J. D. Tygar. Spins: Security
2000. protocols for sensor networks. Wireless Networks, 8(5):521–534, sep 2002.
[35] Integrated Chipware, Inc. Integrated Chipware icWORKSHOP. http:// Previous version of this paper appeared as PSWCT2001.
www.chipware.com/. [62] S. Ping. Something about time syncronization. XXX Lets get this written up
as an Intel tech report.
[36] Jason Hill. Integrated µ-wireless communication platform. http:
//webs.cs.berkeley.edu/retreat-1-03/slides/Mote_ [63] J. Polastre. Design and implementation of wireless sensor networks for habitat
Chip_Jhill_Nest_jan2003.pdf. monitoring. Master’s thesis, University of California at Berkeley, 2003.
[37] C. Karlof, Y. Li, and J. Polastre. ARRIVE: Algorithm for Robust Routing in [64] N. B. Priyantha, A. Miu, H. Balakrishnan, and S. Teller. The Cricket Com-
Volatile Environments. Technical Report UCB//CSD-03-1233, University of pass for context-aware mobile applications. In Proceedings of the 7th ACM
California at Berkeley, Berkeley, CA, Mar. 2003. MOBICOM, Rome, Italy, July 2001.
[38] B. Karp and H. T. Kung. GPSR: greedy perimeter stateless routing for wireless [65] QNX Software Systems Ltd. QNX Neutrino Realtime OS . http://www.
networks. In International Conference on Mobile Computing and Networking qnx.com/products/os/neutrino.html.
(MobiCom 2000), pages 243–254, Boston, MA, USA, 2000. [66] Red Hat, Inc. eCos v2.0 Embedded Operating System. http://sources.
[39] O. Kasten and J. Beutel. BTnode rev2.2. http://www.inf.ethz.ch/ redhat.com/ecos.
vs/res/proj/smart-its/btnode.html. [67] A. Reid, M. Flatt, L. Stoller, J. Lepreau, and E. Eide. Knit: Component com-
[40] B. Kauler. CREEM Concurrent Realitme Embedded Executive for Microcon- position for systems software. In Proc. of the 4th Operating Systems Design
trollers. http://www.goofee.com/creem.htm. and Implementation (OSDI), pages 347–360, 2000.
[68] C. Sharp. Something about the mag tracking demo. XXX Lets get this written
[41] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek. The Click
up as an Intel tech report.
modular router. ACM Transactions on Computer Systems, 18(3):263–297, Au-
gust 2000. [69] C. Sharp et al. NEST Challenge Architecture. http://www.ai.mit.
edu/people/sombrero/nestwiki/index/.
[42] B. Krishanamachari, D. Estrin, and S. Wicker. The impact of data aggregation
in wireless sensor networks. In International Workshop of Distributed Event [70] J. A. Stankovic, H. Wang, M. Humphrey, R. Zhu, R. Poornalingam, and C. Lu.
Based Systems (DEBS), Vienna, Austria, Dec. 2002. VEST: Virginia Embedded Systems Toolkit. In IEEE/IEE Real-Time Embed-
ded Systems Workshop, London, December 2001.
[43] P. Levis and D. Culler. Maté: A tiny virtual machine for sensor networks. In In-
ternational Conference on Architectural Support for Programming Languages [71] Symbian. Symbian OS - the mobile operating system. http://www.
and Operating Systems, San Jose, CA, USA, Oct. 2002. symbian.com/.
[44] P. Levis, N. Lee, A. Woo, S. Madden, and D. Culler. Tossim: Simulating large [72] uClinux Development Team. uClinux, The Linux/Microcontroller Project.
wireless sensor networks of tinyos motes. Technical Report UCB/CSD-TBD, http://www.uclinux.org/.
U.C. Berkeley Computer Science Division, March 2003. [73] University of California at Berkeley. 800-node self-organized wireless sensor
[45] D. Liu and P. Ning. Distribution of key chain commitments for broadcast network. http://today.cs.berkeley.edu/800demo/, Aug. 2001.
authentication in distributed sensor networks. In 10th Annual Network and [74] T. von Eicken, D. E. Culler, S. C. Goldstein, and K. E. Schauser. Active mes-
Distributed System Security Symposium, San Diego, CA, USA, Feb 2003. sages: a mechanism for integrating communication and computation. In Pro-
[46] J. Liu, P. Cheung, L. Guibas, and F. Zhao. A dual-space approach to tracking ceedings of the 19th Annual International Symposium on Computer Architec-
and sensor management in wireless sensor networks. In Proceedings of First ture, pages 256–266, May 1992.
ACM International Workshop on Wireless Sensor Networks and Applications, [75] B. Warneke, M. Last, B. Leibowitz, and K. S. J. Pister. Smart dust: Com-
September 2002. municating with a cubic-millimeter computer. IEEE Computer, 32(1):43–51,
January 2001.
[47] C. Lu, B. M. Blum, T. F. Abdelzaher, J. A. Stankovic, and T. He. RAP: A real-
time communication architecture for large-scale wireless sensor networks. In [76] K. Whitehouse. The design of calamari: an ad-hoc localization system for
Proceedings of IEEE RTAS 2002, San Jose, CA, September 2002. sensor networks. Master’s thesis, University of California at Berkeley, 2002.
[77] K. Whitehouse and D. Culler. Calibration as parameter estimation in sensor
networks. In ACM International Workshop on Wireless Sensor Networks and
Applications (WSNA’02), Atlanta, GA, USA, Sept. 2002.
[78] Wind River Systems, Inc. OSEKWorks 4.0. http://www.windriver.
com/products/osekworks/osekworks.pdf.
[79] Wind River Systems, Inc. pSOSystem Datasheet. http://www.
windriver.com/products/html/psosystem_ds.html.
[80] A. Woo and D. Culler. Evaluation of Efficient Link Reliability Estimators for
Low-Power Wireless Networks. Technical report, UC Berkeley, 2002.
[81] A. D. Wood and J. A. Stankovic. Denial of service in sensor networks. IEEE
Computer, 35(10):54–62, Oct. 2002.
[82] M. D. Yarvis, W. S. Conner, L. Krishnamurthy, A. Mainwaring, J. Chhabra,
and B. Elliott. Real-World Experiences with an Interactive Ad Hoc Sen-
sor Network. In International Conference on Parallel Processing Workshops,
2002.
[83] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient mac protocol for
wireless sensor networks. In Proceedings of IEEE Infocom 2002, New York,
NY, USA., June 2002.
[84] W. Ye, J. Heidemann, and D. Estrin. A flexible and reliable radio communica-
tion stack on motes. Technical Report ISI-TR-565, USC/ISI, Aug. 2002.
[85] K. M. Zuberi, P. Pillai, and K. G. Shin. EMERALDS: a small-memory real-
time microkernel. In Symposium on Operating Systems Principles, pages 277–
299, 1999.