Sen Sip Ire

SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks

CHAPTER 1INTRODUCTION

A typical Wireless Sensor Network (WSN) consists of a large number of small-sized,

battery-powered sensor nodes that are limited in battery energy, CPU power, and communi-

cation capability. Recently, WSN has witnessed an explosive growth in both academia and

industry, attracting a great deal of research attention in the past few years. WSNs are envi-

sioned to support a variety of applications, including military surveillance, habitat monitor-

ing, and infrastructure protection, etc.

Being simple in terms of hardware, WSN applications are diverse and demanding.

The infrastructural support for such applications in the form of operating systems (OS) is be-

coming increasingly important. The basic functionalities of an OS include resource abstrac-

tions for various hardware devices, interrupt management, task scheduling, concurrency con-

trol, and networking support. Numerous applications are built on top of the OS. A sensor net-

workOS(hereafter, sensorOSfor short) bridges the gap between the hardware simplicity and

the application complexity. It plays a central role in providing a flexible

environment for building predictable and efficient services.

Over the years, we have seen various OSs emerging in the sensor network commu-

nity. While they address various challenging issues by adopting different approaches in the

design spectrum, two important issues, i.e., predictability assurance and programming flexi-

bility, are still not well addressed.

Predictability. As sensor nodes are usually deployed in inaccessible areas, operating

in an unattended manner for a long lifetime, system predictability is highly desirable. The OS

should provide mechanisms to ensure the overall system performance. First, the OS should

provide a level of separation between the OS and applications, e.g., the OS should remain re-

sponsive irrespective of the application behaviors. Second, the OS should provide a level of

separation between different tasks, e.g., a critical task should not be blocked indefinitely by

noncritical tasks or locks hold by a group of tasks.

Flexibility. Since WSN applications have diverse requirements, system flexibility to

facilitate application programming is desirable. The OS should provide many choices to meet

requirements of specific application scenarios and programmers’ preference. A hybrid model

combining both event-driven programming and multithreaded programming is highly pre-

ferred. Specific challenges should be addressed to design a hybrid system while retaining

Dept of CS&E, PESITM 1


predictability and efficiency at the same time.

Sensor nodes are usually equipped with low-power microcontrollers with stringent re-

source constraints. The OS should optimize CPU utilization and memory consumption for

high efficiency. Moreover, as sensor nodes are usually deployed in hostile environment in a

large scale, the OS should also support efficient network reprogramming to allow updating

the WSN software.



CHAPTER 2

DESIGN OF SENSPIRE OS

This section presents the design of SenSpire OS. Fig. 1 gives an overview of SenSpire

OS’s design principles.

Section 2.1 describes the two-phase interrupt servicing scheme and predictable thread

synchronization primitives for achieving system predictability. Section 2.2 details the hybrid

system design which provides a flexible model for both event-driven programming and multi-

threaded programming. Section 2.3 describes the stack sharing technique

and the modular design approach for achieving system efficiency. In addition, to facilitate

programming distributed sensor network applications, we have also designed a networking

stack and a programming language called CSpire. Section 2.4 introduces the networking ab-

straction and Section 2.5 describes the CSpire language for application programming based

on SenSpire OS.

Figure 1: A overview of SenSpire OS's Design Principle



2.1 Approaches for Predictability

Interrupt handling is very important for tiny embedded systems like sensor nodes. Ex-

isting sensor OSs usually take a single-phase interrupt servicing scheme. For example, in

TinyOS, interrupts are serviced by asynchronous code that is reachable from (i.e., called

from) one Interrupt Service Routine (ISR). While the OS kernel disables the interrupts only

for brief periods of time, it cannot prevent the applications from disabling interrupts, because

this is the only possible way of synchronization between tasks (i.e., synchronous code in

TinyOS) and interrupts (i.e., asynchronous code in TinyOS). Hence the interrupt latency can-

never be bounded without knowing application behaviors. SenSpire OS adopts a two-phase

interrupt servicing scheme, so that the worst-case interrupt latency can be guaranteed.

Thread synchronization is an important issue in preemptive systems. The design and

implementation of synchronization primitives, however, are overlooked in existing sensor

OSs, such as Contiki OS, Mantis OS. Without a careful design, the synchronization of threads

can lead to an indefinite period of priority inversion, during which a high priority thread waits

indefinitely for the completion of low priority threads. In order to address

this issue, SenSpire OS adopts the priority ceiling protocol to avoid unpredictable priority in-

version and the formation of deadlocks.

2.1.1 Two-Phase Interrupt Servicing

We split interrupt servicing in SenSpire OS into two phases, i.e., the top half and the bottom

half. The top half executes at interrupt time and is meant to be short enough to complete all

necessary actions at the time of the interrupt.



Figure 2: The sensetask application in tiny OS versus Senspire OS

It perfoms sensitive and critical tasks with all interrupts disabled. In contrast, the bot-

tom half can be deferred to a more suitable point in time to complete servicing of a prior in-

terrupt. It allows top halves to preempt its execution by enabling

interrupts.

Fig. 2 shows the code snippets for the SenseTask application for both TinyOS-1.x and

SenSpire OS (hereafter, we will use T1 to refer to TinyOS-1.x and T2 to refer to TinyOS-2.x

when different TinyOS versions matter).

The code for SenSpire OS is written in CSpire, which will be introduced in Section

2.5. In CSpire, the bh keyword is used to indicate a bottom half while thetaskkeyword is used

to indicate a run-to-completion task (a run-to-completion task cannot block or self-suspend,

e.g., TinyOS tasks are run-tocompletion). In the code for T1, the atomic keyword is used to

protect the shared data by disabling global interrupts. Hence, within the atomic section, the

OS is not responsive toany other interrupts. In contrast, in the code for SenSpire OS, the

ADC completion event is notified in the context of a bottom half, and the critical primitive is

used to protect the shared data. The critical primitive differs from the atomic primitive in that

it only defers the execution of bottom halves. Hence top halves can still be serviced immedi-

ately once interrupts trigger. Note that the critical primitive is used to protect shared data be-

tween tasks and bottom halves. To protect shared data between bottom halves and top halves,

we should use the atomic keyword (which disables all interrupts) instead. In this case, top

halves cannot interrupt the execution of bottom halves. Interrupt latency depends on the



length of time top halves execute and the rate of interrupts. In TinyOS, the interrupt latency

also depends on the atomic section length because the atomic keyword disables all interrupts

from execution. As the atomic keyword is exposed to application programmers, the applica-

tion code does affect the interrupt latency. On the other hand, in SenSpire OS, the critical

keyword disables bottom halves (but not top halves) and top halves can always be serviced ir-

respective of the critical section size. Hence, SenSpire OS achieves a more predictable inter-

rupt latency.

2.1.2 Predictive Thread Synchronization

A number of recent sensor OS’s support preemptive threading to ensure predictable

system performance. Synchronization primitives are important to serialize the access to

shared resources. The design and implementation of existing synchronization mechanisms are

overlooked in prior preemptive threaded sensor OSs. In fact, a direct application of traditional

synchronization primitives can lead to an indefinite period of priority inversion and a low

level of schedulability.

We consider a similar example in (shown in Fig. 3). T1, T2, and T3 are three threads

arranged in descending order of priority with T1 having the highest priority. T1 and T3 share

a data structure protected by a mutex. At time t1, T3 starts execution. At time t2, T3 locks the

mutex and executes its critical section. During the execution of T3’s critical section, T1 pre-

empts T3 at time t3. At time t4, T1 attempts to use the shared data. However, it blocks on the

mutex hold by T3. At the same time, T2 starts execution till time t5.



Figure 3: Example of unpredictable periods of priority inversion

In this example, we would expect that T1, being the highest priority thread, will be

blocked no longer than the time for T3 to complete its execution in the critical section, i.e.,

(t6 - t5). However, the duration of blocking is, in fact, (t6 - t5) + (t5 - t4), which is unpre-

dictable because the execution time of T2 (= t5 - t4) and any other pending intermediate

threads can be sufficiently long’

SenSpire OS hence adopts the priority ceiling protocol to address this issue. It works as

follows:

In SenSpire OS, each thread has a static priority and a dynamic priority.

Each shared resource has a static priority ceiling, which equals to the highest static

priority of the thread that uses it. Thanks to the CSpire language, we are able to obtain

the priority ceiling by program code analysis.

The dynamic priority of a thread equals the maximum of its static priority and priority

ceiling of the shared resource it currently uses.

A ready thread can preempt the current thread only when its static priority is higher

than the dynamic priority of the current thread.

It is formally proved in that the priority ceiling protocol reduces the worst-case blocking

time to at most the duration of execution of a single critical section of a lower priority thread.

In addition, it prevents the formation of deadlocks. In the example shown in Fig. 3, if the pri-

ority ceiling protocol is used, at time t4, T3 will continue because it has a higher dynamic pri-

ority than T2’s static priority.



2.2 Approaches for Flexibility

The debate between threads and events is a very old one. Event-driven systems have

the benefits of high system responsiveness, high performance, and low resource consumption.

On the other hand, multithreaded systems have the benefits of expressiveness and ease of use,

e.g., application programmers can reason about the series of actions taken by a thread in the

familiar way, leading to a natural programming style in which the control flow for a single

thread is apparent.

As a hybrid model combines both event-driven programming and multithreaded pro-

gramming, we therefore favor it to meet diverse application requirements. With a hybrid

model, it means that the application programmer could design parts of the application using

threads, where threads are the appropriate abstraction, and parts of the system using events,

where they are more suitable. It is flexible and gives the best of two worlds: the expressive-

ness of threads and customizability of events. While there exist a number of prior works on

the design of hybrid models, SenSpire OS’s integral design goals distinguish its hybrid sys-

tem design from existing works. The hybrid model of SenSpire OS has the following fea-

tures.

Flexibility and customizability. Existing hybrid approaches, based on legacy code-

base, make tight coupling of two subsystems, e.g., event-biased approaches require the exis-

tence of the event-driven subsystem while threadbiased approaches require the existence of

multithreaded

subsystem. By natively supporting hybrid scheduling in the kernel scheduler, SenSpire OS al-

lows decoupling of two subsystems, hence is more flexible in expressing and

customizing different scheduling policies.

Predictability and real-time performance. Existing approaches such as Protothreads,

TinyThreads, do not support priority preemption. Other approaches, such as TinyMOS, only

provide a limited number of priorities (e.g., limited to five in TinyMOS). SenSpire OS ad-

vances prior work by supporting programmer-assigned priority-based preemption, thus na-

tively supporting longrunning computations without degrading system performance.

Moreover, SenSpire OS supports event preemption, which is important to achieve pre-

dictability in the eventdriven subsystem. In addition, SenSpire OS employs the

priority ceiling protocol to achieve predictable thread synchronization (Section 2.1).



Memory efficiency. Existing hybrid systems, such as TOSThreads, TinyMOS, based

on legacy codebase, preclude aggressive resource optimizations in the implementation. In

contrast, by natively supporting hybrid scheduling in the kernel scheduler, SenSpire OS is

able to exploit stack sharing in order to reduce the stack memory consumption.

2.2.1 Hybrid System

Fig. 4 gives an overview of SenSpire OS’s hybrid system. In SenSpire OS, we clas-

sify tasks in two forms: event handler task (event for short) and thread task (thread for short).

Events are handled by the event-driven subsystem and threads are handled by the multi-

threaded subsystem.

Figure 4:SenSpire OS's Hybrid system

Events are scheduled by Event Schedulers (ESs) which in turn are scheduled by the

Kernel Scheduler (KS). SenSpire OS’s event-driven subsystem is different from TinyOS, in

that we can support multiple preemption levels by the use of multiple ESs. Events in different

ESs can preempt one another. In contrast, the TinyOS core has only one preemption level

within the task context. Some critical system events (e.g., packet reception) are executed in

the task context, sharing the same context as other noncritical tasks (e.g., compression).

Therefore, a critical task can be interfered by the execution of other noncritical tasks ahead of

it. The multithreaded subsystem consists of multiple threads which are directly scheduled by

our KS along with ESs. It is different from Mantis OS, in that we do not employ time-sliced

scheduling, instead, preemption occurs when a high priority thread (or ES) is ready or when

the currently running thread calls a blocking I/O or gives up its CPU cycles voluntarily by



calling sleep( ) or yield( ). Hence the number of context switches can be reduced. In SenSpire

OS, the event-driven subsystem takes a higher priority than the multithreaded subsystem be-

cause it is more suitable for time-sensitive operations.

We have introduced the design of SenSpire OS’s thread synchronization primitives in

Section 2.1.2. In the following section, we will describe SenSpire OS’s novel differentiated

kernel scheduling scheme which implements the hybrid model while reduces memory con-

sumption by stack sharing at the same time.

2.2.2 Differentiated Kernel Scheduling

SenSpire OS’s KS differentiates three execution contexts, i.e., ES, the primary thread

(i.e., the system startup context, denoted as T0), and nonprimary threads (denoted as T1...n).

As each ES represents a nonblocking context, they can share a common stack with one of the

blocking context. In SenSpire OS, all ESs share a common stack with the primary thread.

SenSpire OS’s stack sharing technique is inspired by TinyOS fibers [25], in which a system

stack is shared between events and one thread. SenSpire OS extends it by supporting preemp-

tive events and multiple threads. We will further discuss the issue of stack sharing in Section

2.3.1.

Context switches between ESs or between ES and the primary thread do not involve

stack switching. Stack switching is only required when switching between threads or between

ES and nonprimary threads. Note that we still need to switch the register files. Table 1 shows

the actions taken by the KS.



Table 1: Differentiated Kernel Scheduling

Note that, events, being run-to-completion, are not allowed to block. This means that events

cannot block on synchronization primitives such as mutexes. In order to achieve synchroniza-

tion between events of different priorities, or events and threads, we need to manually check

for the resource availability in the event, and need to repost the event if the resource is un-

available at the current time.

The KS employs preemptive scheduling in accordance with the priorities of ESs and

threads. The priorities of ESs must be different while the priorities of threads can be the

same. Within the same priority, the KS schedules threads in an FIFO manner. Each ES uses a

nonpreemptive scheduling scheme. Within each ES, events share a common execution

context and are scheduled by a certain nonpreemptive policy (e.g., FIFO, or nonpreemptive

priority based). Hence, to execute an event, two levels of scheduling are involved: first, the

KS schedules the corresponding ES (which the event is assigned to), then the ES schedules

the event to run.

The scheduling system can be viewed as a hierarchy of execution contexts . As shown

in Figure 5, the Kernel Scheduler schedules two ESs and two threads in a prioritypreemption

manner. The ES-NPPS has the highest priority. Thus any event assigned to it can preempt

other tasks. The scheduling policy is Non-Preemptive Priority Scheduling (NPPS). The ES-

FIFO has an intermediate priority. Any event assigned to it can preempt threads, but not

events assigned to ES-NPPS. It schedules events assigned to it in an FIFO manner. Two

threads have the same lowest priority and can be preempted by any events in the system.

They are scheduled by our KS in an FIFO manner.



2.2.3 Comparison with Prior Work

Fig. 6 compares SenSpire OS’s hybrid model with prior works in the sensor network commu-

nity. In this figure, x-axis represents the thread phase while the y-axis represents the event

phase. Early OSs, such as TinyOS (also SOS, Contiki OS core), only support nonpreemptive

events. Protothreads , built on Contiki OS, supports thread-like programming. However, it

does not maintain thread-independent data, and does not allow preemption. TinyOS fibers,

built on TinyOS, only supports one thread

Figure 5: An Example for Scheduling hierarchy

Figure 6: Comparision of existing hybrid systems

TinyThreads, also built on TinyOS, implements a cooperative thread mechanism. In

the cooperative thread model, a thread must explicitly yield the CPU to other runnable



threads. The problem with cooperative threads is the correctness of the system depends on

application code voluntarily yielding the CPU at specific intervals. If a thread does not relin-

quish the CPU for a long time, then other threads may be unable to make progress. The same

issue exists for event-driven systems. Therefore, TinyOS Preemptive Level Scheduler (PL)

supports preemptive events based on TinyOS, but it does not support thread-like program-

ming. The Contiki preemptive library, and TOSThreads, support true preemptive multithread-

ing on event-driven kernels; TinyMOS supports events in a multithreaded kernel (Mantis

OS). SenSpire OS advances these three works in three aspects. First, SenSpire OS supports

preemption in both event-driven subsystem and multithreaded subsystem. Event preemption

is important for ensuring system predictability in the event-driven subsystem. Second, Sen-

Spire OS supports customizing different scheduling policies with the help of the CSpire lan-

guage compiler (which will be further discussed in Section 4.5). Third, by directly supporting

hybrid scheduling in the kernel scheduler, SenSpire OS is able to employ stack sharing for

optimizing resource utilization (see Section 2.3.1).

2.3 Approaches for Efficiency

The design and implementation of a sensor OS should meet the resource constraints

of sensor nodes. In most components of SenSpire OS, we adopt cost-effective design ap-

proaches (as opposed to approaches for traditional OSs). In particular, we employ stack shar-

ing to reduce stack memory consumption in our scheduler design. In addition, the modular

extension of SenSpire OS enables energy-efficient network reprogramming. We will intro-

duce the stack sharing technique and the modular design approach in the following two sec-

tions, respectively.

2.3.1 Stack Sharing

The shared stack model not only can be applied to nonpreemptive systems, but also

preemptive systems where tasks have run-to-completion semantics and do not suspend them-

selves.

In order to see why stack sharing can be applied to our hybrid system, we analyze the

following conditions. First, all ESs can share a common stack because their execution is non-

interleaved, i.e., if ESj begins execution between the start and finish of ESi (to make it possi-

ble, ESj must have a higher priority), then ESi is not allowed to resume execution until ESj



has finished. Second, all ESs can share a common stack with one of the threads (primary

thread). This is because each ES’s execution cannot be preempted by threads (as ES’s priority

is higher than threads), and, once some ES preempts the execution of the primary thread, it

must run to completion before the primary thread can be resumed.

In order to see the benefits our differentiated kernel scheduling (Section 2.2.2), we an-

alyze the stack consumption of the scheduling hierarchy shown in Fig. 5 for prior

approaches (without stack sharing) and SenSpire OS’s approach (with stack sharing). With-

out stack sharing, this scheduling hierarchy will occupy the following four stacks.

1. Stack for ES-NPPS; all tasks within ES-NPPS are nonpreemptive, hence share this

common stack.

2. Stack for ES-FIFO; all tasks within ES-FIFO are nonpreemptive, hence share this

common stack.

3. Stack for thread1 (the primary thread).

4. Stack for thread2.

This is a relative costly scheme for implementing the hybrid model on resource con-

strained sensor nodes. In SenSpire OS, a common system stack is shared among ESs and the

primary thread. Considering an additional stack for thread2, the system consumes two stacks,

reducing two stacks compared to prior approaches.

2.3.2 Modular Design

Recently, SenSpireOSsupports dynamic loadable modules to enable

energy-efficient network reprogramming. Early OSs, such as TinyOS, re-

quire full image replacement to reprogram a network of sensors. This in-

curs a large amount of transmission overhead during code dissemination,

which significantly impacts energy efficiency and the lifetime of a sensor

network. A few differential-based approaches are designed for TinyOS.

The problem

therein is that they require the program layout to be exactly the same on all sensor nodes. If

sensor nodes are running different versions of their software, differential-based approaches

do not scale. SenSpire OS supports loadable modules. It uses an optimized module file for-

mat, SELF, for dissemination. The SELF loader within the OS is responsible for loading and

executing a new module. Compared to existing modular OSs, such as SOS and Contiki OS,

SenSpire OS’s modular design has two major advantages.



First, compared to Contiki’s CELF, SELF is even smaller. CELF only redefines long

data types to short ones (e.g., from 32 bits to 16 bits, or 16 bits to 8 bits), hence still leads to a

large amount of metadata overhead. SenSpire OS optimizes the module file format much fur-

ther. For example, with the chained reference technique, it reduces the number of relocation

entries to the number of unique references, instead of the total number of references; with a

system call jump table, it is able to prelink system calls to fixed addresses in the jump table

slots. This prelinking technique significantly reduces the overhead of kernel symbols and

their string representations.

Second, compared to SOS’s MELF, SELF is more flexible. MELF, being small in

size, has several limitations. First, it uses Position Independent Code (PIC). Not all CPU ar-

chitectures support PIC and even when supported, programs compiled to PIC typically are

subject to size restrictions, e.g., 4 KB for the AVR microcontroller. SenSpire OS does not

have this limitation by using relocatable code. Second, SOS module does not allow to define

global variables because data relocation is not performed. SenSpire OS does not have this

limitation.

2.4 Networking Abstraction

We have designed and implemented a three-layer networking stack to facilitate pro-

gramming distributed sensor applications based on SenSpire OS. Different layers abstract

different functionalities by different classes of WSN developers.

1) The radio layer provided by device driver developers. It implements device specific

MAC protocols.

2) The unified resource layer provided by OS kernel developers. It virtualizes the radio

hardware, scheduling concurrent requests. On top of it, different applications can use

the hardware radio without interfering each other.

3) The sensornet layer provided by network service developers. It implements neighbor-

hood management and link estimations, which can be shared among different upper-

layer networking routing protocols.



2.5 Programming Language

We have developed a programming language, CSpire, for application programming

based on SenSpire OS. CSpire partially supports object-oriented programming while tightly

integrates with the OS kernel for compile-time verifications, optimizations, and customiza-

tions. We summarize CSpire’s features as follows:

Encapsulation. CSpire forces the application code be encapsulated in classes.

Function polymorphism. CSpire allows a common name to be shared among multiple

functions as long as their signatures are different. Note that CSpire does not allow dy-

namic polymorphism as it will incur a large runtime overhead.

Object manipulation. CSpire supports invoking methods of an object. However,

CSpire does not manage object lifetime.

Support for the hybrid model. CSpire supports the keywords of task, thread, bh, etc.,

to simply programming on top of SenSpire OS’s hybrid model.

Annotations. CSpire supports specifying annotations to objects, e.g.,

task[period=1000] denotes a periodic task with a one second period.

Compile-time verification. CSpire verifies whether the application code conforms to

the requirements of SenSpire OS. For example, blocking is not allowed in events (or

bottom halves).

Compile-time optimization and customization. CSpire is able to analyze application

resource requirements and customize the OS kernel. Currently, CSpire supports for

customization of the scheduling hierarchy, e.g., the multithreaded system can be ex-

cluded if the application never uses. CSpire also supports stack size estimation by dif-

ferentiating different execution contexts and analyzing at the assembly level.



CHAPTER 3

IMPLEMENTATION

We have implemented SenSpire OS on three commonly deployed sensor node plat-

forms—Mica2, MicaZ, and TelosB.

Figure 7: SenSpire OS design overview

The SenSpire OS kernel is written in C. As shown in Fig. 7, The SenSpire OS mainly

consists of the following components:

Hardware drivers. They are further classified into onchip device drivers (such as hard-

ware timers, UART, and ADC) and off-chip device drivers (such as MTS300/

MTS310 sensorboards, Chipcon CC1000/ CC2420 radios). We port parts of this code

from SOS and Mantis OS.

Interrupt system. It contains the two-phase interrupt handling code.

Task scheduling system. It implements the differentiated kernel scheduling algorithm

and a set of synchronization primitives.



Module manager. It extends SenSpire OS for handling modules. It is responsible for

module placement, loading, and execution.

Network protocols. They include the sensornet layer and illustrative network routing

protocols such as the tree routing protocol.

Programming environment. Applications based on SenSpireOSare written in

CSpire,weexpose SenSpire OS kernel services to application programmers via the

CSpire native classes which are thin wrappers around their C implementations. We

implement the CSpire compiler with JavaCC. It compiles user applications together

with SenSpire OS native classes into C. Then it invokes the corresponding C cross-

compiler (e.g., avr-gcc or msp-gcc) to compile the converted C code into the binary

code.

The kernel scheduler is the core of SenSpire OS. The SenSpire OS kernel scheduler main-

tains a priority queue. As shown in Fig. 8, the kernel scheduler fetches the highest priority

task from the queue. If there is no task in the queue, the kernel scheduler puts the CPU into

the sleep state to

Figure 8:Pseudocode for kernel scheduler

save energy. Otherwise the kernel scheduler switches the register files. After that, the kernel

scheduler switches the stack only when necessary (according to Table 1).



CHAPTER 4

RELATED WORK

TinyOS, developed at UC Berkeley, is perhaps the earliest sensor OS in the literature. To en-

able a flexible architecture and a low resource consumption, TinyOS programming is based

on components which are wired together to create a single application image at design-time.

Component interactions happen at two directions, i.e., one component can use commands

provided by another component; also, one component can signal events to another compo-

nent. The execution model of TinyOS consists of interrupts and tasks. Interrupts execute at a

higher priority and can preempt the execution of tasks. Tasks execute at a lower priority and

are scheduled in a FIFO manner. Tasks in TinyOS are written in a run-to-completion manner,

and they cannot be preempted or self-suspended. For this reason, I/Os are done in splitphases,

i.e., a request is issued before a signal invokes the

start of the next task.

Contiki, developed at Swedish Institute of Computer Science, is a sensor OS that sup-

ports dynamically loadable modules. Contiki supports multithreading via libraries to address

the programming inconvenience of event-based programming (e.g., in TinyOS). Contiki also

supports a lightweight threading mechanism, i.e., protothreads .

SOS, developed at the University of California, Los Angeles, also supports dynami-

cally loadable modules. It adopts a module-based architecture which allows dynamically

loading and unloading modules. The SOS execution model is only slightly more complex

than TinyOS: SOS message handlers (similar to TinyOS tasks) are dispatched according to

three different priorities, but preemption is not allowed between two message handlers.

Mantis OS, developed at Colorado University, implements a traditional preemptive

time-sliced multithreading on sensor nodes. The Mantis kernel supports synchronous I/Os (as

opposed to split-phase I/Os), and a set of concurrency control primitives, e.g., binary sema-

phores (mutex) and counting semaphores.

Nano-RK, developed at Carnegie Mellon University, implements a reservation-based

real-time OS for WSNs. Nano-RK supports fixed-priority preemptive multitasking for guar-

anteeing that task deadlines are met. It also supports CPU and network bandwidth reserva-



tions, i.e., tasks can specify their resource demands and the OS provides timely, guaranteed

and controlled access to CPU cycles and network packets.

RETOS, developed at Yonsei University, Korea, is designed to improve several as-

pects of prior work. It improves system resilience by supporting dual mode operation (i.e.,

kernel mode and user mode) as well as application code checking at design-time and runtime.

It optimizes multithreading implementation and provides support for POSIX 1003.1b real-

time scheduling. It also supports loadable modules and provides multihop networking ser-

vices.

LiteOS, developed at the University of Illinois at Urbana Champaign, is designed to pro-

vide a traditional Unix-like environments for programming WSN applications. It includes:

1) A built-in hierarchical file system and a wireless shell for user interaction using Unix-

like commands.

1) Kernel support for dynamic loading native execution of multithreaded applications.

2) An object oriented programming language (LiteC++) that uses a subset of C++ as its

syntax with class library support.

Pixie OS, developed at Harvard University, is designed to enables resource-aware pro-

gramming. In Pixie, a sensor node has direct knowledge of available resources, such as

energy, radio bandwidth, and storage space, and can control resource consumption at a fine

granularity. The Pixie OS is based on a dataflow programming model based on the concept of

resource tickets, a core abstraction for representing resource availability and reservations. By

giving the system visibility and fine-grained control over resource management, a broad

range of policies can be implemented.

Aside from the basic system implementations mentioned above, there is a large body

of work devoted to improving OS capabilities in different dimensions, e.g., improving OS re-

liability (e.g., t-kernel, Harbor, and Neutron ), providing real-time support (e.g., FIT ), ex-

tending the programming model (e.g., protothreads , TOSThreads), and providing reprogram-

ming support (e.g., Deluge, Stream, and Elon ). For a more complete review in the areas of

sensor OS design.



CONCLUSIONS AND FUTURE WORK

In this paper, we present SenSpire OS, a predictable, flexible, and efficient operating

system for WSNs. We improve system predictability by two-phase interrupt servicing and

predictable thread synchronization; we achieve system flexibility by providing a hybrid

model for both event-driven programming and multithreaded programming; we retain system

efficiency by employing stack sharing and modular design. In addition, we have designed a

three-layer networking stack and an object-oriented programming language (CSpire) to en-

hance system usability and programming convenience. Having implemented SenSpire OS on

three most commonly used sensor node platforms, we evaluate its performance extensively.

While we have shown that SenSpire OS is promising in providing a flexible environ-

ment for building predictable and efficient sensor network applications. There is much future

work to consider. In particular, we would like to examine how SenSpire OS’s design princi-

ples will enhance the performance of large-scale complex WSN applications.



REFERENCES

1. I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless Sensor Net-

works: A Survey,” Computer Networks, vol. 38, pp. 393-422, 2002.

2. TinyOS, http://www.tinyos.net,

3. A. Dunkels, B. Gro¨ nvall, and T. Voigt, “Contiki—A Lightweight and Flexible Op-

erating System for Tiny Networked Sensors,” Proc. 29th Ann. IEEE Int’l Conf. Local

Computer Networks (LCN ’04), 2004.

4. C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava, “A Dynamic Operating

System for Sensor Nodes,” Proc. Third Int’l Conf. Mobile Systems, Applications, and

Services (MobiSys), 2005.

5. S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald,

A. Torgerson, and R. Han, “MANTIS OS: An Embedded Multithreaded Operating

System for Wireless Micro Sensor Platforms,” J. Mobile Networks and Applications,

vol. 10, pp. 563-579, 2005.

6. A. Eswaran, A. Rowe, and R. Rajkumar, “Nano-RK: An Energy- Aware Resource-

Centric RTOS for Sensor Networks,” Proc. 26th IEEE Int’l Real-Time Systems Symp.

(RTSS), 2005.

7. H. Cha, S. Choi, I. Jung, H. Kim, and H. Shin, “RETOS: Resilient, Expandable, and

Threaded Operating System for Wireless Sensor Networks,” Proc. Sixth Int’l Conf.

Information Processing in Sensor Networks (IPSN ’07), 2007.

8. Q. Cao, T.F. Adbelzaher, and J.A. Stankovic, “The LiteOS Operating System: To-

wards Unix-Like Abstractions for Wireless Sensor Networks,” Proc. Seventh Int’l

Conf. Information Processing in Sensor Networks (IPSN ’08), 2008.

9. K. Lorincz, B. rong Chen, J. Waterman, G. Werner-Allen, and M. Welsh, “Resource

Aware Programming in the Pixie OS,” Proc. Sixth ACM Conf. Embedded Network

Sensor Systems (SenSys), 2008.

10. Q. Wang, Y. Zhu, and L. Cheng, “Reprogramming Wireless Sensor Networks: Chal-

lenges and Approaches,” IEEE Network Magazine, vol. 20, no. 3, pp. 48-55, May/

June 2006.


Documents

Sen Sip Ire