A Dynamic Operating System for Sensor NodesChih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler and Mani Srivastava

University of California, Los Angeles{simonhan, roy, kohler}@cs.ucla.edu, {ram, mbs}@ucla.edu

ABSTRACT

Sensor network nodes exhibit characteristics of both em-bedded systems and general-purpose systems. They mustuse little energy and be robust to environmental condi-tions, while also providing common services that makeit easy to write applications. In TinyOS, the current stateof the art in sensor node operating systems, reusablecomponents implement common services, but each noderuns a single statically-linked system image, making ithard to run multiple applications or incrementally up-date applications. We present SOS, a new operating sys-tem for mote-class sensor nodes that takes a more dy-namic point on the design spectrum. SOS consists of dy-namically-loaded modules and a common kernel, whichimplements messaging, dynamic memory, and moduleloading and unloading, among other services. Modulesare not processes: they are scheduled cooperatively andthere is no memory protection. Nevertheless, the systemprotects against common module bugs using techniquessuch as typed entry points, watchdog timers, and primi-tive resource garbage collection. Individual modules canbe added and removed with minimal system interruption.We describe SOS’s design and implementation, discusstradeoffs, and compare it with TinyOS and with the Matevirtual machine. Our evaluation shows that despite thedynamic nature of SOS and its higher-level kernel inter-face, its long term total usage nearly identical to that ofsystems such as Mate and TinyOS.

1 INTRODUCTION

Wireless sensor nodes—networked systems containingsmall, often battery-powered embedded computers—candensely sample phenomena that were previously diffi-cult or costly to observe. Sensor nodes can be locatedfar from networked infrastructure and easy human ac-cessibility, anywhere from the forest canopy [13] to thebacks of zebras [12]. Due to the difficulty and expenseof maintaining such distant nodes, wireless sensor net-works are expected to be both autonomous and long-lived, surviving environmental hardships while conserv-ing energy as much as possible. Sensor network applica-tions will change in the field as well; data returned fromthe network can influence followup experiment design,and long-lived networks will necessarily be retasked dur-ing their lifetimes.

All of this argues for a general-purpose sensor network

operating system that cleanly supports dynamic applica-tion changes. But sensor nodes are embedded systems aswell as general-purpose systems, introducing a tensionbetween resource and energy constraints and the layersof indirection required to support true general-purposeoperating systems. TinyOS [15], the state-of-the-art sen-sor operating system, tends to prioritize embedded sys-tem constraints over general-purpose OS functionality.TinyOS consists of a rich collection of software com-ponents written in the NesC language [8], ranging fromlow-level parts of the network stack to application-levelrouting logic. Components are not divided into “kernel”and “user” modes, and there is no memory protection,although some interrupt concurrency bugs are caught bythe NesC compiler. A TinyOS system image is staticallylinked at compile time, facilitating resource usage anal-ysis and code optimization such as inlining. However,code updates become more expensive, since a whole sys-tem image must be distributed [10].

This paper shows that sensor network operating sys-tems can achieve dynamic and general-purpose OS se-mantics without significant energy or performance sacri-fices. Our operating system, SOS, consists of a commonkernel and dynamic application modules, which can beloaded or unloaded at run time. Modules send messagesand communicate with the kernel via a system jump ta-ble, but can also register function entry points for othermodules to call. SOS, like TinyOS, has no memory pro-tection, but the system nevertheless protects against com-mon bugs. For example, function entry points are markedwith types using compressed strings; this lets the systemdetect typing errors that might otherwise crash the sys-tem, such as when a module expecting a new version ofan interface is loaded on a node that only provides theold. SOS uses dynamic memory both in the kernel and inapplication modules, easing programing complexity andincreasing temporal memory reuse. Priority schedulingis used to move processing out of interrupt context andprovide improved performance for time-critical tasks.

We evaluate SOS using both microbenchmarks and theapplication-level Surge benchmark, a well-known multi-hop data acquisition program. Comparisons of Surgeversions running on SOS, TinyOS, and Mate Bombillavirtual machine [14] show comparable CPU utilizationand radio usage; SOS’s functionality comes with onlya minor energy cost compared to TinyOS. Evaluationof code distribution mechanisms in the same three sys-

Copyright held by the author 163

tems shows that SOS provides significant energy savingsover TinyOS, and more expressivity than Mate Bombilla.However, analytical comparisons of the total energy con-sumed by the three systems over an extended period oftime reveals that general operating costs dwarf the abovedifferences, resulting in nearly identical total energy con-sumption on the three systems.

The rest of the paper is structured as follows. Section 2describes other systems that have influenced the SOS de-sign. A detailed look at the SOS architecture is presentedin Section 3, including key differences between SOS andTinyOS. A brief walk through of an SOS application ispresented in Section 4. An in-depth evaluation of SOS,including comparisons to TinyOS and Mate Bombilla, ispresented in Section 5. Section 6 closes with ending re-marks and directions for future work.

2 RELATED WORK

SOS uses ideas from a spectrum of systems research inboth general purpose operating system methods and em-bedded systems techniques.

2.1 Traditional Operating SystemsSOS provides basic hardware abstractions in a core ker-nel, upon which modules are loaded to provide bothhigher level functionality. This is similar to microkernelabstractions explored by the Mach [19] operating sys-tem and the Exokernel [6]. Mach modularizes low layerkernel services to allow easy customization of the sys-tem. The Exokernel uses a minimal hardware abstractionlayer upon which custom user level operating environ-ments can be created. SOS also uses a small kernel thatprovides interfaces to the underlying hardware at a levellower than Mach and higher than the Exeokernel.

SOS’s typed communication protocols were inspiredpartially by SPIN [2], which makes kernel extensionssafe through the use of type safe languages.

2.2 Sensor Network Operating SystemsTinyOS [9] is the de facto standard operating systemfor sensor nodes. TinyOS is written using the NesC lan-guage [8] and provides an event driven operating envi-ronment. It uses a component model for designing sen-sor network applications. At compile time, a componentbinding configuration is parsed, elements are staticallybound and then compiled to make a binary image thatis programmed into the flash memory on a sensor node.TinyOS’s static binding facilitates compile time checks.Like TinyOS, SOS is event driven and uses a componentmodel, but SOS components can be installed and modi-fied after a system has been deployed.

Our experiences working with TinyOS helped to mo-tivate the development and design decisions of SOS.

As described in section 5.1, approximately 21% of theMica2 specific driver code and 36% of the AVR specificcode included in the current SOS distribution is porteddirectly from TinyOS.

The need for flexible systems has inspired virtual ma-chines (VM), mobile agents, and interpreters, for sensornodes. One such system is Mate [14]. Mate implementsa simple VM architecture that allows developers to buildcustom VMs on top of TinyOS and is distributed withBombilla, which demonstrates a VM implementation ofthe Surge protocol. Sensorware [3] and Agilla [7] are de-signed to enable mobile agent abstractions in sensor net-works. Unfortunately, these approaches can have signif-icant computational overhead, and the retasking of thenetwork is limited by the expressibility of the underly-ing VM or agent system. SOS occupies a middle groundwith more flexibility and less CPU overhead than VMs,but also higher mote reprogramming cost.

MANTIS [1] implements a lightweight subset of thePOSIX threads API targeted to run on embedded sen-sor nodes. By adopting an event driven architecture, SOSis able to support a comparable amount of concurrencywithout the context switching overhead of MANTIS.

2.3 Dynamic CodeTraditional solutions to reprogrammable systems targetresource rich devices. Loadable modules in Linux sharemany properties with SOS, but benefit from running onsystems that can support complex symbol linking at runtime. Impala [17] approaches the devices SOS targetsby implementing dynamic insertion of code on devicessimilar to PDAs. At any given time, Impala middlewarechooses a single application to run based on the state ofapplication specific and global node state, allowing Im-pala to execute an application that is the best fit to currentconditions. In contrast to this, SOS both expects and sup-ports multiple modules executing and interacting on topof the SOS kernel at the same time. An operating sys-tem for 8-bit devices developed at the same time as SOSand supporting modular dynamic code updates is Con-tiki [5]. Contiki uses runtime relocation to to update bi-naries loaded onto a node, as opposed to the completelyposition independent code used by SOS. This results adifferent low layer design choices in Contiki and SOS.

XNP [4] is a mechanism that enables over the air re-programming of the sensor nodes running TinyOS. WithXNP a new image for the node is stored into an exter-nal flash memory, then read into program memory, andfinally the node is rebooted. SOS module updates cannotreplace the SOS kernel, but improve on XNP’s energyusage by using modular updates rather than full binarysystem images, not forcing a node to reboot after up-dates, and installing updates directly into program mem-ory without expensive external flash access.

164

Low overhead solutions using differential patching areproposed in [20] and [11]. In these schemes a binary dif-ferential update between the original system image andthe new image is created. A simple language is used toencode this update in a compressed form that is then dis-tributed through the network and used to construct a newsystem image on deployed nodes. This technique can beused at the component level in SOS and, since changesto the SOS kernel or modules will be more localized thanin tightly coupled systems, result in smaller differentials.

MOAP [22] and Deluge [10] are two protocols thathove been used to distribute new system images to allnodes in a sensor network. SOS currently includes apublish-subscribe scheme that is similar to MOAP fordistributing modules within a deployed sensor network.Depending on the user’s needs SOS can use MOAP, Del-uge, or any other code distribution protocol. SOS is notlimited to running the same set of modules or same basekernel on all nodes in a network, and will benefit fromdifferent types of distribution protocols including thosesupporting point-to-point or point-to-region transfer ofdata.

3 SYSTEM ARCHITECTURE

In addition to the traditional techniques used in embed-ded system design, the SOS kernel features dynamicallylinked modules, flexible priority scheduling, and a sim-ple dynamic memory subsystem. These kernel serviceshelp support changes after deployment, and provide ahigher level API freeing programmers from managingunderlying services or reimplementing popular abstrac-tions. Most sensor network application and protocol de-velopment occurs in modules that sit above the kernel.The minimal meaningful sensor network application us-ing SOS consists of a simple sensing module and routingprotocol module on top of the kernel.

Table 1 presents memory footprints of the core SOSkernel, TinyOS with Deluge, and Mate Bombilla virtualmachine. All three of these configurations include a baseoperating environment with the ability to distribute andupdate the programs running on sensor nodes. SOS na-tively supports simple module distribution and the abilityto add and remove modules at run time. TinyOS is ableto distribute system images and reflash nodes using Del-uge. The Mate Bombilla VM natively supports the trans-fer and execution of new programs using the Trickle [16]protocol. SOS is able to provide common kernel servicesto external modules in a footprint comparable to TinyOSrunning Deluge and a space smaller than the Mate Bom-billa VM. Note that RAM usage in SOS is broken intotwo parts: RAM used by the core kernel and RAM re-served for the dynamic memory subsystem.

The following discussion takes a closer look at thekey architectural decisions in SOS and examines them

Platform ROM RAMSOS Core 20464 B 1163 B(Dynamic Memory Pool) - 1536 BTinyOS with Deluge 21132 B 597 BBombilla Virtual Machine 39746 B 3196 B

Table 1—Memory footprint for base operating system with ability todistribute and update node programs compiled for the Mica2 Motes.

Figure 1—Module Interactions

in light of the commonly used TinyOS.

3.1 ModulesModules are position independent binaries that imple-ment a specific task or function, comparable in function-ality to TinyOS components. Most development occursat the module layer, including development of drivers,protocols, and application components. Modification tothe SOS kernel is only required when low layer hardwareor resource management capabilities must be changed.An application in SOS is composed of one or more in-teracting modules. Self contained position independentmodules use clean messaging and function interfacesto maintain modularity through development and intodeployment. The primary challenge in developing SOSwas maintaining modularity and safety without incurringhigh overhead due to the loose coupling of modules. Anadditional challenge that emerged during development,described in more detail in section 3.1.4, was maintain-ing consistency in a dynamically changing system.

3.1.1 Module Structure

SOS maintains a modular structure after distribution byimplementing modules with well defined and generalizedpoints of entry and exit. Flow of execution enters a mod-ule from one of two entry mechanisms: messages deliv-ered from the scheduler and calls to functions registeredby the module for external use. This is illustrated in fig-ure 1.

Message handling in modules is implemented using amodule specific handler function. The handler function

165

Communication Method Clock CyclesPost Message Referencing Internal Data 271Post Message Referencing External Buffer 252Dispatch Message from Scheduler 310Call to Function Registered by a Module 21Call Using System Jump Table 12Direct Function Call 4

Table 2—Cycles needed for different types of communication to andfrom modules in SOS when running on an Atmel AVR microcontroller.The delay for direct function calls within the kernel is listed as a base-line reference.

takes as parameters the message being delivered and thestate of the module. All module message handlers shouldimplement handler functions for the init and final mes-sages produced by the kernel during module insertionand removal, respectively. The init message handler setsthe module’s initial state including initial periodic timers,function registration, and function subscription. The finalmessage handler releases all node resources includingtimers, memory, and registered functions. Module mes-sage handlers also process module specific messages in-cluding handling of timer triggers, sensor readings, andincoming data messages from other modules or nodes.Messages in SOS are asynchronous and behave some-what like TinyOS tasks; the main SOS scheduling looptakes a message from a priority queue and delivers themessage to the message handler of the destination mod-ule. Inter-module direct function calls are used for mod-ule specific operations that need to run synchronously.These direct function calls are made possible through afunction registration and subscription scheme describedin section 3.1.2. Module state is stored in a block of RAMexternal to the module. Modules are relocatable in mem-ory since: program state is managed by the SOS kernel,the location of inter-module functions is exposed througha registration process, and the message handler functionfor any module is always located an a consistent offset inthe binary.

3.1.2 Module Interaction

Interactions with modules occur via messages, directcalls to functions registered by a module, and ker * sys-tem calls into the SOS kernel. The overhead for each ofthese types of interactions is presented in table 2. Mes-saging, detailed in section 3.2, provides asynchronouscommunication to a module and enables scheduling bybreaking up chains of execution into scheduled subparts.Messaging is flexible, but slow, so SOS provides directcalls to functions registered by modules, which bypassthe scheduler to provide low latency communication tomodules.

Function registration and subscription is the mecha-nism that SOS uses to provide direct inter-module com-munication and upcalls from the kernel to modules.

Function Registration Action Clock CyclesRegister a Function 267Deregister a Function 230Get a Function Handle 124Call to Function Registered by a Module 21

Table 4—Cycles needed for the function registration mechanism inSOS when running on an Atmel AVR microcontroller.

Figure 2—Jump Table Layout and Linking in SOS.

When explicitly registering functions with the SOS ker-nel, a module informs the kernel where in its binary im-age the function is implemented. The registration is donethrough a system call ker register fn described in table 3with overheads detailed in table 4. A function controlblock (FCB) used to store key information about the reg-istered function is created by the SOS kernel and indexedby the tuple {module ID, function ID}.

The FCB includes a valid flag, a subscriber referencecount, and prototype information. The stored prototypeinformation encodes both basic type information and wh-ether a parameter contains dynamic memory that needsto undergo a change of ownership. For example, the pro-totype {’c’, ’x’, ’v’, ’1’} indicates a function that re-turns a signed character (’c’) and requires one parame-ter (’1’). That parameter is a pointer to dynamically al-located memory (’x’). When a registered function is re-moved, this prototype information is used by kernel stubfunctions described in section 3.1.4.

The call ker get handle described in table 3 is used tosubscribe to a function. The module ID and function IDare used as a tuple to locate the FCB of interest, and typeinformation is checked to provide an additional level ofsafety. If the lookup succeeds, the kernel returns a pointerto the function pointer of the subscribed function. Thesubscriber should always access the subscribed functionby dereferencing this pointer. This extra level of indirec-tion allows the SOS kernel to easily replace the imple-mentation of a function with a newer version by chang-ing the function pointer in the FCB, without needing toupdate subscriber modules.

166

Prototype Descriptionint8 t ker register fn(sos pid t pid, uint8 t fid, Register function ’func’ with type ’prototype’ as beingchar *prototype, fn ptr t func) supplied by ’pid’ and having function ID ’fid’.fn ptr t* ker get handle(sos pid t req pid, Subscribe to the function ’fid’ provided byuint8 t req fid, char *prototype) module ’pid’ that has type ’prototype’.

Table 3—Function Registration and Subscription API

Modules access kernel functions using a jump table.This helps modules remain loosely coupled to the kernel,rather than dependent on specific SOS kernel versions.Figure 2 shows how the jump table is setup in memoryand accessed by a module. This technique also allows thekernel to be upgraded without requiring SOS modules tobe recompiled, assuming the structure of the jump tableremains unchanged, and allows the same module to runin a deployment of heterogeneous SOS kernels.

3.1.3 Module Insertion and Removal

Loading modules on running nodes is made possibleby the module structure described above and a minimalamount of metadata carried in the the binary image of amodule.

Module insertion is initiated by a distribution protocollistening for advertisements of new modules in the net-work. When the distribution protocol hears an advertise-ment for a module, it checks if the module is an updatedversion of a module already installed on the node, or ifthe node is interested in the module and has free programmemory for the module. If either of the above two con-ditions are true, the distribution protocol begins to down-load the module and immediately examines the metadatain the header of the packet. The metadata contains theunique identity for the module, the size of the memoryrequired to store the local state of the module, and ver-sion information used to differentiate a new module ver-sion. Module insertion is immediately aborted should theSOS kernel find that it is unable to allocate memory forthe local state of the module.

A linker script is used to place the handler functionfor a module at a known offset in the binary during com-pilation, allowing easy linking during module insertion.During module insertion a kernel data structure indexedby the unique module ID included in the metadata is cre-ated and used to store the absolute address of the han-dler, a pointer to the dynamic memory holding the mod-ule state, and the identity of the module. Finally the SOSkernel invokes the handler of the module by schedulingan init message for the module.

The distribution protocol used to advertise and propa-gate module images through the network is independentof the SOS kernel. SOS currently uses a publish sub-scribe protocol similar to MOAP.

Module removal is initiated by the kernel dispatchinga final message. This message provides a module a final

opportunity to gracefully release any resources it is hold-ing and inform dependent modules of its removal. Afterthe final message the kernel performs garbage collectionby releasing dynamically allocated memory, timers, sen-sor drivers, and other resources owned by the module.As described in section 3.1.4, FCBs are used to maintainsystem integrity after module removal.

3.1.4 Potential Failure Modes

The ability to add, modify, and remove modules froma running sensor node introduces a number of potentialfailure modes not seen in static systems. It is importantto provide a system that is robust to these potential fail-ures. While still an area of active work, SOS does pro-vide some mechanisms to minimize the impact of poten-tial failure modes that can result from dynamic systemchanges. These mechanisms set a global error variable tohelp inform modules when errors occur, allowing a mod-ule to handle the error as it sees fit.

Two potential modes of failure are attempting to de-liver a scheduled message to a module that does not existon the node, and delivering a message to a handler that isunable to handle the message. In the first case, SOS sim-ply drops the message addressed to a nonexistent mod-ule and frees dynamically allocated memory that wouldnormally undergo ownership transfer. The latter case issolved by the individual modules, which can choose cus-tom policies for what to do with messages that they areunable to handle. Most modules simply drop these mes-sages, return an error code, and instruct the kernel to col-lect dynamically allocated memory in the message thatwould have undergone a change of ownership.

More interesting failure modes emerge as a result ofintermodule dependencies resulting from direct func-tion calls between modules, including: no correct im-plementation of a function exists, an implementation ofa function is removed, an implementation of a functionchanges, or multiple implementations of a single func-tion exist.

A module’s subscription request is successful if thereexists a FCB that is tagged as valid and has the samemodule ID, function ID and prototype as that in the sub-scription. Otherwise the subscription request fails andthe module is free to handle this dependency failure asit wishes. Actions currently taken by various SOS mod-ules include aborting module insertion, scheduling a laterattempt to subscribe to the function, and continuing to

167

execute with reduced functionality.A subscription to a function can become invalid should

the provider module be removed. When the supplier ofa function is removed from the system, SOS checks ifany other modules have registered to use the function.If the registration count is zero then the FCB is sim-ply removed from the system. If the registration countis greater than zero, a control flag for the FCB is markedas being invalid to prevent new modules from subscrib-ing and the implementation of the function is redirectedto a system stub function. The system stub function per-forms expected memory deallocations as encoded in thefunction prototype and sets a global error variable thatthe subscriber can use to further understand the problem.

Problems can arise after a module has subscribed toa function if the implementation of the function changesdue to updates to the provider module. Similar to whena module is removed, functions provided by a moduleare marked invalid during an update. When the updatedmodule finishes installing, it registers new versions of theprovided functions. SOS assumes that a function regis-tration with the same supplier module ID, function ID,and prototype of an already existent FCB is an updateto the function implementation, so the existent FCB isupdated and the control flag is returned to being valid.This automatically redirects subscribers to the new im-plementation of the function. Changes to the prototypeof a provided function are detected when the new imple-mentation of the function is registered by the supplyingmodule. This results in the old FCB remaining invalidwith old subscribers redirected to a system stub and anew FCB with the same supplier module ID and func-tion ID but different prototype information being created.New subscribers with the new prototype information arelinked to the new FCB, while any attempts to subscribeto the function with the old prototype fail.

It is important to note that when SOS prevents an er-ror in the situations described above, it typically returnsan error to the calling module. The programmer of themodule is responsible for catching these errors and han-dling them as they see fit. Providing less intrusive protec-tion mechanisms is a fascinating and challenging prob-lem that continues to be worked on as SOS matures.

3.2 Message SchedulingSOS uses cooperative scheduling to share the processorbetween multiple lines of execution by queuing messagesfor later execution.

TinyOS uses a streamlined scheduling loop to popfunction pointers off of a FIFO message queue. This cre-ates a system with a very lean scheduling loop. SOS in-stead implements priority queues, which can provide re-sponsive servicing of interrupts without operating in aninterrupt context and more general support for passing

parameters to components. To avoid tightly integratedmodules that carefully manage shared buffers, a resultof the inability to pass parameters through the messag-ing mechanism, messaging in SOS is designed to handlethe passing of parameters. To mitigate memory leaks andsimplify accounting, SOS provides a mechanism for re-questing changes in data ownership when dynamicallyallocated memory is passed between modules. These de-sign goals result in SOS choosing a more expressivescheduling mechanism at the cost of a more expensivescheduling loop. The API for messaging is SOS is shownin figure 5.

Figure 3—Memory Layout of An SOS Message Queue

Figure 3 provides an overview of how message head-ers are structured and queued. Message headers within aqueue of a given priority form a simple linked list. Theinformation included in message headers includes com-plete source and destination information, allowing SOSto directly insert incoming network messages into themessaging queue. Messages carry a pointer to a data pay-load used to transfer simple parameters and more com-plex data between modules. The SOS header providesan optimized solution to this common case of passing afew bytes of data between modules by including a smallbuffer in the message header that the data payload can beredirected to, without having to allocate a separate pieceof memory (similar to the mbuf design). SOS messageheaders also include a series of flags to describe the prior-ity of the message, identify incoming and outgoing radiomessages, and describe how the SOS kernel should man-age dynamic memory. These flags allow easy implemen-tation of memory ownership transfer for a buffer movingthrough a stack of components, and freeing of memoryon completion of a scheduled message.

SOS uses the high priority queue for time critical mes-sages from ADC interrupts and a limited subset of timersneeded by delay intolerant tasks. Priority queues have al-lowed SOS to minimize processing in interrupt contextsby writing interrupt handlers that quickly construct andschedule a high priority message and then drop out of theinterrupt context. This reduces potential concurrency er-rors that can result from running in an interrupt context.Examples of such an errors include corruption of sharedbuffers that may be in use outside of the interrupt con-text, and stale interrupts resulting from operating with

168

Prototype Descriptionint8 t post short(sos pid t did, sos pid t sid, Place a message on the queue to call function ‘type’ inuint8 t type, uint8 t byte, uint16 t word, uint8 t flag) module ‘did’ with data ‘byte’ and ‘word’.int8 t post long(sos pid t did, sos pid t sid, Place a message on the queue to call function ‘type’uint8 t type, uint8 t len, void *data, uint8 t flag) in module ‘did’ with *data pointing to the data.

Table 5—Messaging API

Prototype Description Cyclesvoid *ker malloc(uint16 t Allocate memory 69size, sos pid t id)void ker free(void* ptr) Free memory 85int8 t ker change own(void Change ownership 43*ptr, sos pid t id)sos pid t Validate memory 1175ker check memory() (after a crash)

Table 6—Cycles needed for dynamic memory tasks in SOS when run-ning on an Atmel AVR microcontroller.

interrupts disabled.

3.3 Dynamic MemoryDue to reliability concerns and resource constraints, em-bedded operating systems for sensor nodes do not alwayssupport dynamic memory. Unfortunately, static memoryallocation results in fixed length queues sized for worstcase scenarios and complex program semantics for com-mon tasks, such as passing a data buffer down a protocolstack. Dynamic memory in SOS addresses these prob-lems. It also eliminates the need to resolve during mod-ule insertion what would otherwise be static referencesto module state.

SOS uses dynamic memory with a collection of book-keeping annotations to provide a solution that is efficientand easy to debug. Dynamic memory in SOS uses simplebest fit fixed-block memory allocation with three baseblock sizes. Most SOS memory allocations, includingmessage headers, fit into the smallest block size. Largerblock sizes are available for the few applications thatneed to move large continuous blocks of memory, suchas module insertion. A linked list of free blocks for eachblock size provides constant time memory allocation anddeallocation, reducing the overhead of using dynamicmemory. Failed memory allocation returns a null pointer.

Queues and data structures in SOS dynamically growand shrink at run time. The dynamic use and release ofmemory in SOS creates a system with effective temporalmemory reuse and an ability to dynamically tune mem-ory usage to specific environments and conditions. Selfimposed hard memory usage limits prevent programingerrors that could otherwise result in a module allocatingall of the dynamic memory on a node.

Common memory functions and their clock cycleoverheads are presented in table 6. All allocated mem-ory is owned by some module on the node. This valueis set during allocation and used by SOS to implement

basic garbage collection and watch for suspect memoryusage. Modules can transfer memory ownership to reflectdata movement. Dynamic memory blocks are annotatedwith a small amount of data that is used to detect basicsequential memory overruns. These features are used forpost-crash memory analysis1 to identify suspect memoryowners, such as a module owning a great deal of sys-tem memory or overflowed memory blocks. SOS alsosupports the use of a hardware watchdog timer used toforce a soft boot of an unresponsive node and triggeringthe same post-crash memory analysis. Finally, memoryblock annotations enable garbage collection on moduleunload.

3.4 Miscellaneous

The SOS kernel includes a sensor API that helps to man-age the interaction between sensor drivers and the mod-ules that use them. This leads to more efficient usageof a node’s ADC and sensing resources. Other standardsystem resources include timer multiplexing, UART li-braries, and hardware management of the I2C bus.

The loosely coupled design used in SOS has resultedin a platform that is very portable. SOS currently has sup-port for the Mica2 and MicaZ motes from Crossbow, andthe XYZ Node from Yale. The most difficult portion ofa port tends to be the techniques for writing to programmemory while the SOS core is executing.

Limitations on module development result from theloose coupling of modules. An example of this is a 4KBsize limitation for AVR module binaries, since relativejumps used in position independent code on the AVR ar-chitecture can only jump up to 4KB. Moreover, modulescannot refer to any global variables of the SOS kernel,as their locations of may not be available at compilationtime.

4 PROGRAMMING SOS APPLICATIONS

Figure 4 contains a source code listing of the Sam-ple Send module of the Surge application2. The programuses a single switch structure to implement the messagehandler for the Sample Send module. Using the standardC programing language reduces the learning curve ofSOS while taking advantage of the many compilers, de-velopment environments, debuggers, and other tools de-signed for C. C also provides efficient execution neededto operate on resource limited 8-bit microcontrollers.

169

01 int8_t module(void *state, Message *msg) {02 surge_state_t *s = (surge_state_t*)state;03 switch (msg->type){04 //! System Message - Initialize module05 case MSG_INIT: {06 char prototype[4] = {’C’, ’v’, ’v’, ’0’};07 ker_timer_start(SURGE_MOD_PID, SURGE_TIMER_TID,08 TIMER_REPEAT, INITIAL_TIMER_RATE);09 s->get_hdr_size = (func_u8_t*)ker_get_handle10 (TREE_ROUTING_PID, MOD_GET_HDR_SIZE,11 prototype);12 break;13 }14 //! System Message - Timer Timeout15 case MSG_TIMER_TIMEOUT: {16 MsgParam *param = (MsgParam*) (msg->data);17 if (param->byte == SURGE_TIMER_TID) {18 if (ker_sensor_get_data(SURGE_MOD_PID, PHOTO)19 != SOS_OK)20 return -EFAIL;21 }22 break;23 }24 //! System Message - Sensor Data Ready25 case MSG_DATA_READY: {26 //! Message Parameters27 MsgParam* param = (MsgParam*) (msg->data);28 uint8_t hdr_size;29 uint8_t *pkt;30 hdr_size = (*(s->get_hdr_size))();31 if (hdr_size < 0) return -EINVAL;32 pkt = (uint8_t*)ker_malloc33 (hdr_size + sizeof(SurgeMsg), SURGE_MOD_PID);34 s->smsg = (SurgeMsg*)(pkt + hdr_size);35 if (s->smsg == NULL) return -EINVAL;36 s->smsg->reading = param->word;37 post_long(TREE_ROUTING_PID, SURGE_MOD_PID,38 MSG_SEND_PACKET, length, (void*)pkt,39 SOS_MSG_DYM_MANAGED);40 break;41 }42 //! System Message - Evict Module43 case MSG_FINAL: {44 ker_timer_stop(SURGE_MOD_PID, SURGE_TIMER_TID);45 ker_release_handle(s->get_hdr_size);46 break;47 }48 default:49 return -EINVAL;40 }51 return SOS_OK;52 }

Figure 4—Surge Source Code

Line 2 shows the conversion of the generic state storedin and passed from the SOS kernel into the module’s in-ternal representation. As noted in section 3.1.1, the SOSkernel always stores a module’s state to allow modulesto be easily inserted at runtime.

An example of the init message handler appears onlines 5-13. These show the module requesting a peri-odic timer from the system and subscribing to the MOD-GET HDR SIZE function supplied by the tree routing

module. This function pointer is used on line 30 to findthe size of the header needed by the underlying routinglayer. By using this function, changes to the underlyingrouting layer that modify the header size do not break theapplication. Lines 43-47 show the final message handlerreleasing the resources it had allocated: the kernel timerand the subscribed function. If these resources had notbeen explicitly released, the garbage collector in the SOSkernel would have soon released them. Good programingstyle is observed on lines 31 and 35 where potential er-rors are caught by the module and handled.

5 EVALUATION

Our initial performance hypothesis was that SOS wouldperform at roughly the same level as TinyOS in termsof latency and energy usage, despite the greater level

of functionality SOS provides (and the overhead neces-sary to support that functionality). We also hypothesizedthat SOS module insertion would be far less expensive interms of energy than the comparable solution in TinyOSwith Deluge. This section tests these hypotheses usinga prototypical multihop tree builder and data collectorcalled Surge. A baseline evaluation of the operating sys-tems is also performed.

Benchmarking shows that application level perfor-mance of a Surge-like application on SOS is compara-ble to Surge on TinyOS and to Bombilla, an instantiationof the Mate virtual machine specifically for the Surgeapplication. Initial testing of CPU active time in base-line evaluations of SOS and TinyOS showed a significantdiscrepancy between the two systems, motivating an indepth search into the causes of overhead in SOS. Thissearch revealed simple optimizations that can be appliedto improve both systems and bring their baseline perfor-mance to almost the same level. The process of remotelyupdating an application’s functionality in SOS is moreenergy efficient than updates using Deluge in TinyOS,but less efficient than updates using Bombilla. While ourhypotheses that SOS can more efficiently install updatesthan TinyOS with Deluge proves true, further analysisshows that this difference does not significantly impactthe total energy usage over time and that the three sys-tems have nearly identical energy profiles over long timescales. From these results, we argue that SOS effectivelyprovides a flexible solution for sensor networking withenergy usage functionally equivalent to other state of theart systems.

5.1 MethodologyWe first describe the workings of the Surge application.Surge nodes periodically sample the light sensor andsend that value to the base station over multi-hop wire-less links. The route to the base station is determined bysetting up a spanning tree; every node in the tree main-tains only the address of its parent. Data generated at anode is always forwarded to the parent in the spanningtree. Surge nodes choose as their parent the neighborwith the least hop count to the base station and, in theevent of a tie, the best estimated link quality. The es-timate of the link quality is performed by periodicallybroadcasting beacon packets containing neighborhoodinformation.

The Surge application in SOS is implemented withthree modules: Sample Send, Tree Routing and Photo-Sensor. For SOS, a blank SOS kernel was deployed onall motes. The Sample Send, Tree Routing and Photo-Sensor modules were injected into the network and re-motely installed on all the nodes. For TinyOS, the nodeswere deployed with the Deluge GoldenImage. The Surgeapplication was injected into the network using the Del-

170

Type of Code PercentageKernel 0%Mica2 Specific Drivers 21%AVR Specific Drivers 36%

Table 7—Approximate number of lines of code (including comments)used from TinyOS in different parts of SOS.

uge protocol and remotely installed on all the nodes. ForMate, the Bombilla VM was installed on all the nodes.Bombilla VM implements the tree routing protocol na-tively and provides a high-level opcode, Send, for trans-ferring data from the node to the base station via a span-ning tree. Bytecode for periodically sampling and send-ing the data to the base station was injected into the net-work and installed on all relevant nodes.

In all versions of Surge, the routing protocol parame-ters were set as follows: sensor sampling happens every8 seconds, parents are selected and route updates broad-cast every 5 seconds, and link quality estimates are calcu-lated every 25 seconds. Therefore, upon bootup, a nodewill have to wait at least 25 seconds before it performsthe first link quality estimate. Since the parent is selectedbased on link quality, the expected latency for a node todiscover its first parent in the network is at least 25 sec-onds.

The experiments in section 5.2 use the setup de-scribed above to examine application level performanceof Surge. Section 5.3 examines the base SOS kernel anda simple TinyOS application to find the base CPU activetime in the two operating systems when no applicationis present. The section continues with an examination ofhow the Surge application effects CPU active time. Sec-tion 5.4 finishes with a numerical examination of the up-date overhead in SOS, TinyOS and Mate. In an attemptto isolate operating system specific overhead, the anal-ysis in section 5.4 does not use Deluge or the moduledistribution protocol currently used in SOS.

SOS reuses some of the TinyOS driver code for itsMica2 target and AVR support. Table 7 shows the ap-proximate percentage of code reused from TinyOS inSOS. For these experiments SOS uses nearly direct portsof the TinyOS CC1000 radio stack, sensor drivers, andapplications. This helps to isolate performance differ-ences to within the kernel and module framework ofSOS.

5.2 Macro BenchmarksWe first measure the time needed to form a routing treeand then measure the number of packets delivered fromeach node to the base station in a duration of 40 minutes.These tests act as a macro benchmark to help verify thatSurge is running correctly on the three test platforms.Since all three systems are executing the same applica-tion and the CPU is not being heavily loaded, we ex-

pect differences in application performance to be smallenough to be lost in the noise, as in fact they are.

For this experiment, Mica2 motes are deployed in alinear topology, regularly spaced at a distance of 4 feetfrom each other. The transmit power of the radio is setto -25dBm, the lowest possible transmit power, whichresults in a range of approximately 4 feet for our indoorlaboratory environment.

Figure 5 shows the average time it took for a node todiscover its first parent, averaged over 5 experiments. Allthree systems achieve latencies quite close to 25 seconds,the minimum latency possible given the Surge configura-tion parameters. The differences between the three sys-tems are mainly due to their different boot routines. Thesource of the jitter results from the computation of theparent being done in a context which is often interruptedby packet reception.

Figure 5 also shows the average time it takes to de-liver the first packet from a node to the base station.Since all three systems implement a queue for sendingpackets to the radio, the sources of per-hop latency arequeue service time, wireless medium access delay, andpacket transmission time. Queue service time dependsupon the amount of traffic at the node, but the only vari-ation between the three systems is due to the differencesin the protocols for code dissemination given the other-wise lightly loaded network. The medium access delaydepends on the MAC protocol, but this is nearly identi-cal in the three systems [18]. Finally, packet transmissiontime depends upon the packet size being transmitted; thisis different by a handful of bytes in the three systems,causing a propagation delay on the order of 62.4 µs perbit [21]. The latency of packet delivery at every hop isalmost identical in the three systems. The small varia-tions that can be observed are introduced mainly due tothe randomness of the channel access delay.

Finally, figure 5 shows the packet delivery ratio forthe three systems when the network was deployed for 40minutes. As expected, the application level performanceof the three systems was nearly identical. The slight dif-ferences are due to the fluctuating wireless link qualityand the different overheads introduced by the code up-date protocols.

These results verify our hypothesis that the applicationlevel performance of a typical sensor network applica-tion running at a low duty cycle in SOS is comparable toother systems such as TinyOS and Mate. The overheadsintroduced in SOS for supporting run time dynamic link-ing and message passing do not affect application perfor-mance.

5.3 CPU OverheadWe proceed by measuring CPU active time on the SOSand TinyOS operating systems without any application

171

1 2 30

5

10

15

20

25

30Tree Formation Latency

Hop Count

Late

ncy

(Sec

)

IdealTinyOSSOSMate’

(a) Surge Tree Formation Latency

1 2 30

10

20

30

40

50

60

70

80

90

100

Hop Count

Del

ay (M

illi−

seco

nds)

Surge App: Delay Measurement

TinyOSSOSMate’

(b) Surge Forwarding Delay

Hop 1 Hop 2 Hop 30

10

20

30

40

50

60

70

80

90

100Surge Packet Delivery Ratio

Trace over 40 minutes (300 Pkts per node)

Pac

ket D

eliv

ery

Per

cent

age

TinyOSSOSMate’

(c) Surge Packet Delivery Ratio

Figure 5—Macro Benchmark Comparison of Surge Application

activity to examine the base overhead in the two systems.Bombilla is not examined in these base measurementssince the virtual machine is specific to the Surge appli-cation. The evaluation is finished by examining the CPUactive time when running Surge on each of SOS, TinyOS,and Mate. In all three systems, the source code is instru-mented to raise a GPIO pin in the microcontroller whenthe CPU is performing any active operation (executing atask or interrupt). A high speed data logger is used to cap-ture the waveform generated by the GPIO pin and mea-sure the active duration. All experiments are run for 10intervals of 60 seconds using the same Mica2 motes. Weexpect both systems to have nearly identical base over-heads since the SOS kernel should be nearly as efficientas the base TinyOS kernel.

To examine the base overhead in SOS we installed ablank SOS kernel onto a single mote and measured CPUactive time to be 7.40%± 0.02%. In contrast to this, run-ning the closest TinyOS equivalent, TOSBase, resultedin a CPU active time of 4.76%±0.01%. This active timediscrepancy came as a great surprise and prompted anevaluation into the cause of overhead in SOS.

Detailed profiling using the Avrora [23] simulator re-vealed that the overhead in SOS may be related to theSPI interrupt used to monitor the radio for incomingdata. The SPI interrupt is triggered every 418µs in bothSOS and TinyOS when the radio is not in a low powermode, as is the case in the above experiments. Micro-benchmarking showed that the SPI interrupt handler inSOS and TinyOS are almost identical. However uponexit from the SPI interrupt, control is transferred to thescheduler that checks for pending tasks. On a lightlyloaded system the common case is to perform this checkand go to sleep, since the scheduling queue is usuallyempty. Further micro-benchmarking revealed that in thecommon case of empty scheduling queues, the SOSscheduling loop takes 76 cycles compared to 25 cycles inTinyOS. This additional overhead acquired every 418µs

accounts for the discrepancy in performance betweenSOS and TinyOS.

The SOS scheduling loop was then optimized to betterhandle this common case reducing the CPU active timeto 4.52% ± 0.02% and resulted in SOS outperformingTinyOS. For a fair comparison we modified the TinyOSscheduling loop and post operation 3 to use a similarscheduling mechanism, reducing the TinyOS CPU activetime to 4.20%± 0.02%. This difference is small enoughthat it can be accounted for by two additional push andpop instruction pairs in the SOS SPI handler that are in-troduced due to the slight modifications to the radio stackimplementation.

The above active times are summarized in table 8. Ofthe most interest are the last two entries, which show thatwhen both scheduling loops are optimized the base op-eration overhead of SOS and TinyOS are within a fewpercent, as expected.

Having verified that the base operating systems havevery similar overheads, we continue by examining theCPU active time when Surge is run on SOS, TinyOS andMate. Versions of both SOS and TinyOS with optimizedschedulers are used for all three tests and Mate Bom-billa runs on top of the optimized TinyOS core. Surge isloaded onto two nodes, and the active time is again mea-sured by instrumenting the code to activate a GPIO pinwhen active and monitoring this pin with a high speeddata logger. The experiment results are shown in Table 9.This comparison shows that this low duty cycle applica-tion has less effect on the base performance of SOS thanfor TinyOS. The cause of this larger increase for TinyOSis not yet fully understood. One hypothesis is that the ini-tial baseline measurement between SOS and TinyOS donot accurately reflect the same base functionality.

5.4 Code UpdatesWe now present an evaluation of the energy needed forpropagation and installation of the Surge application. We

172

OS Version Percent ActiveTime

SOS Unoptimized 7.40% ± 0.02%

TinyOS Unoptimized 4.76% ± 0.01%

SOS Optimized 4.52% ± 0.02%

TinyOS Optimized 4.20% ± 0.02%

Table 8—CPU Active Time on Base Op-erating System

OS Version Percent Active TimeSOS 4.64% ± 0.08%

OptimizedTinyOS 4.58 ± 0.02%

OptimizedMate Bom. 5.13 ± 0.02%

Table 9—CPU Active Time WithSurge

SOS Module Name Code SizeSample Send 568 bytesTree Routing 2242 bytesPhoto Sensor 372 bytesEnergy (mJ) 2312.68Latency (s) 46.6

Table 10—SOS Surge Remote Installation

begin by looking at installing Surge onto a completelyblank node over a single hop in SOS. Surge on SOS con-sists of three modules: Sample send, Tree routing, andPhoto Sensor. Table 10 shows the size of the binary mod-ules and overall energy consumption and the latency ofthe propagation and installation process. The energy con-sumption was measured by instrumenting the power sup-ply to the Mica2 to sample the current consumed by thenode.

We continue with an analytical analysis of the energycosts of performing similar code updates in our threebenchmark systems—SOS, TinyOS with Deluge [10],and Mate Bombilla VM with Trickle [16]. It is impor-tant to separate operating system-related energy and la-tency effects from those of the code distribution proto-col. Overall latency and energy consumption is mainlydue to the time and energy spent in transmitting the up-dated code and storing and writing the received code tothe program memory.

Communication energy depends upon the number ofpackets that need to be transferred in order to propagatethe program image into the network; this number, in turn,is closely tied to the dissemination protocol. However,the number of application update bytes required to betransferred to update a node depends only on the archi-tecture of the operating system. Therefore, to eliminatethe differences introduced due to the different dissemi-nation protocols used by SOS, TinyOS, and Bombilla,we consider the energy and latency of communicationand the update process to be directly proportional to thenumber of application update bytes that need to be trans-ferred and written to the program memory. The designof the actual distribution protocol used is orthogonal tothe operating system design and SOS could use any ofthe existing code propagation approaches [22, 16]; it cur-rently uses a custom publish/subscribe protocol similarto MOAP [22].

5.4.1 Updating low level functionality

To test updating low level functionality, we numericallyevaluate the overhead of installing a new magnetometersensor driver into a network of motes running the Surgeapplication. The SOS operating system requires the dis-tribution of a new magnetometer module, whose binaryis 1316 bytes. The module is written into the program

System Code Size Write Cost Write Energy(Bytes) (mJ/page) (mJ)

SOS 1316 0.31 1.86TinyOS 30988 1.34 164.02Mate VM N/A N/A N/A

Table 11—Magnetometer Driver Update

System Code Size Write Cost Write Energy(Bytes) (mJ/page) (mJ)

SOS 566 0.31 0.93TinyOS 31006 1.34 164.02Mate VM 17 0 0

Table 12—Surge Application Update

memory, one 256-byte page of the flash memory at atime. The cost of writing a page to the flash memory wasmeasured to be 0.31 mJ, and 6 pages need to be writtenso the total energy consumption of writing the magne-tometer driver module is 1.86 mJ.

TinyOS with the Deluge distribution protocol requiresthe transfer of a new Surge application image with thenew magnetometer driver. The total size of the Surgeapplication with the new magnetometer driver is 30988bytes. The new application image is first stored in ex-ternal flash memory until it is completely received. Thecost of writing and reading one page of the external flashis 1.03 mJ [21]. Thereafter, the new image is copiedfrom the external flash to the internal flash memory. Thismakes the total cost of installing a page of code into theprogram memory 1.34 mJ, and the total energy consump-tion for writing the updated Surge application 164.02 mJ.

Lastly, the Mate Bombilla VM does not support anymechanism for updating low level functionality such asthe magnetometer driver. These results are summarizedin table 11.

5.4.2 Updating application functionality

We examine updates to applications by numerically eval-uating the overhead of updating the functionality ofthe Surge application. The modified Surge applicationsamples periodically, but transmits the value to a basestation only if it exceeds a threshold. The SOS oper-ating system requires the distribution of a new Sam-ple Send module with the updated functionality. As be-fore, TinyOS/Deluge requires the transfer of a new Surgeapplication image with the modified functionality. How-ever, the Mate Bombilla VM requires just a bytecode up-

173

date. The total size of the bytecode was only 17 bytes,and since it is installed in the SRAM, it has no extra costover the running cost of the CPU. The results of an analy-sis similar to that in section 5.4.1 is presented in table 12.

SOS offers more flexibility than Mate; operations suchas driver updates not already encoded in Mate’s high-level bytecode cannot be accomplished. However, Mate’scode updates are an order of magnitude less expensivethan SOS’s. TinyOS with Deluge picks the extreme endof the flexibility/cost trade off curve by offering thegreatest update flexibility at the highest cost of code up-date. With a Deluge like mechanism, it is possible to up-grade the core kernel components, which is not possibleusing only modules in SOS; but in SOS and Mate, thestate in the node is preserved after code update while itis lost in TinyOS due to a complete reboot of the system.

The above analysis does not consider how differentialupdates described in section 2.3 could impact static anddynamic systems. There is potential for differential up-dates to significantly decrease the amount of data thatneeds to be transmitted to a node for both systems. It isalso unclear how efficiently a differential update, whichmay require reconstructing the system image in externalflash, can be implemented. Differential updates are anarea of research that both SOS and TinyOS could benefitfrom in the future.

5.4.3 Analytical analysis of update energy usage

The previous evaluation of CPU utilization and updatecosts in SOS, TinyOS, and Mate prompts asking howsignificant those factors are in the total mote energy ex-penditure over time. Application energy usage on a motecan be divided up into two primary sources: the energyused to install or update the application, and the powerused during application execution multiplied by applica-tion execution time. An interesting point of comparisonis to find the time, if any, when the total energy usageof two systems running the same application becomesequal. Starting with an update to a node, the total energyconsumption of the node is found using:

Etotal = Eupdate + Paverage × Tlive (1)

Paverage denotes the power consumption of the mote av-eraged over application execution duration and the sleepduration (due to duty cycling). Tlive is the time that thenode has been alive since it was updated. Eupdate is theenergy used to update or install the application.

The average power consumption during applicationexecution depends upon the active time of the applica-tion, duty cycle of operation, and the power consump-tion of the hardware platform in various power modes.The Mica2 power consumption in various modes was ob-tained from [21] and is summarized in table 13. We first

Mode Active (mW) Idle (mW) Sleep (mW)Mica2 Power 47.1 29.1 0.31Duty Cycle(%) TinyOS (mW) SOS (mW) Mate (mW)100 29.92 29.94 30.0210 3.271 3.272 3.2811 0.6057 0.6058 0.6067

Table 13—Average Power Consumption of Mica2 Executing Surge

compute Pawake, the average power consumption of theSurge application assuming a 100% duty cycle i.e. thesystem is operating continuously without sleep:

Pawake = Pactive ×Tactive

Tactive + Tidle+ Pidle ×

Tidle

Tactive + Tidle

Table 9 provides the ratio TactiveTactive+Tidle

, which can be usedto find Tidle

Tactive+Tidle. When the system is operated at lower

duty cycles, the average power consumption is given by:

Paverage = Pawake ×DutyCycle+Psleep× (1−DutyCycle)

Table 13 summarizes the average power consumption ofthe Surge application at various duty cycles.

Now we compute the energy used during the Surgeapplication installation, Eupdate, which is the sum of theenergy consumed in receiving the application over theradio and subsequently storing it on the platform. For theMica2 Mote, the energy to receive a byte is 0.02 mJ/byte-[21]. Using table 12 we can compute the energy requiredto update the Surge application on SOS assuming thatcommunications energy has a one to one correlation withapplication bytes transmitted:

Eupdate(SOS) = 0.02mJbyte

×566bytes+0.93mJ = 12.25mJ

Similar computations can also be performed for TinyOSand Mate using the numbers in table 12.

Using the numbers computed thus far, it is possibleto understand the total energy consumption of a system,Etotal, as a function of the elapsed time Tlive. From equa-tion 1, it can be seen that energy consumption is linearwith the slope being equal to Paverage with an initial off-set equal to Eupdate. The average power consumption foreach of the three systems examined is very similar andresults in nearly identical total energy usage over time,despite the initially significantly different update costs.For example, by solving the linear equations for the 10%duty cycle, it is easy to see that TinyOS becomes moreenergy efficient than SOS after about 9 days. Similarly,for a 10% duty cycle, SOS becomes more energy effi-cient than Mate after about 22 minutes. But looking atthe absolute difference in energy consumed after 30 daysat a 10% duty cylcle, SOS has consumes less than 2 Jmore energy than TinyOS and Mate is only about 23 Jbeyond SOS. This analysis reveals that, contrary to our

174

initial intuition, differences in both CPU utilization andupdate costs are not significant in the total energy con-sumption of the node over time.

Note that this analysis is only for a single application,Surge, running under a given set of conditions. Differ-ent applications and evolving hardware technology willchange the results of the above analysis. Applicationswith very high CPU utilization can magnify the effectsof different CPU utilization on Paverage resulting in totalenergy variances of 5% to 10% on current mote hard-ware. Similarly, improvements to duty cycling that re-duce node idle time can magnify the effects of CPU uti-lization on Paverage. Hardware innovations that reduce pe-ripheral energy usage, especially when the CPU is idle,will also lead to a noticeable discrepancy in total energyconsumption. Only as the above improvements to sys-tems are made, leading to more energy efficient execu-tion environments, will energy savings from efficient up-dates become significant.

5.5 DiscussionThis analysis examines energy usage, which provides aquantifiable comparison of these systems. This sectionalso shows that these differences are not significant whentaking into account average power consumption resultingfrom the different power modes of current mote technol-ogy. Choosing between operating systems for these sys-tems should be driven more by the features provided bythe underlying system, such as flexibility of online up-dates in SOS or full system static analysis in TinyOS,rather than total system energy consumption. As soft-ware and hardware technologies advance, the effects ofdiffering CPU utilization and update costs between sys-tems will play a more significant role in choosing a sys-tem.

The results of the experiments performed in this sec-tion validate the following claims about SOS. First, thearchitectural features presented in section 3 position SOSat a middle ground between TinyOS and Mate in termsof flexibility. Second, the application level performanceof the SOS kernel is comparable to TinyOS and Mate forcommon sensor network applications that do not stressthe CPU. Third, code updates in SOS consume less en-ergy than similar updates in TinyOS, and more energythan similar updates in Mate. Fourth, despite differentupdate costs and CPU active times, the total energy usagein SOS is nearly identical to that in TinyOS and Mate.

6 CONCLUSION

SOS is motivated by the value of maintaining mod-ularity through application development and into sys-tem deployment, and of creating higher-level kernelinterfaces that support general-purpose OS semantics.The architecture of SOS reflects these motivations. The

kernel’s message passing mechanism and support fordynamically allocated memory make it possible forindependently-created binary modules to interact. To im-prove the performance of the system and to provide asimple programming interface, SOS also lets modulesinteract through function calls. The dynamic nature ofSOS limits static safety analysis, so SOS provides mech-anisms for run-time type checking of function calls topreserve system integrity. Moreover, the SOS kernel per-forms primitive garbage collection of dynamic memoryto improve robustness. Fine grain energy usage of SOS,TinyOS and the Mate Bombilla virtual machine are de-pendent on the frequency of updates and stressing of theCPU required for a specific deployment. However, analy-sis of overall energy consumed by each of the three sys-tems at various duty cycles shows nearly identical en-ergy usage for extended deployments. Thus, to choosebetween SOS and another system, it is important for de-velopers to consider the benefits of static or dynamic de-ployments independently of energy usage.

SOS is a young project under active development andseveral research challenges remain. One critical chal-lenge confronting SOS is to develop techniques that pro-tect the system against incorrect module operation andhelp facilitate system consistency. The stub function sys-tem, typed entry points, and memory tracking protectagainst common bugs, but in the absence of any formof memory protection it remains possible for a moduleto corrupt data structures of the kernel and other mod-ules. Techniques to provide better module isolation inmemory and identify modules that damage the kernelare currently being explored. The operation of SOS isbased on the notion of co-operative scheduling, but anincorrectly composed module can utilize all of the CPU.We are exploring more effective watchdog mechanismsto diagnose this behavior and take corrective actions.Since binary modules are distributed by resource con-strained nodes over a wireless ad-hoc network, SOS mo-tivates more research in energy efficient protocols for bi-nary code dissemination. Finally, SOS stands to benefitgreatly from new techniques and optimizations that spe-cialize in improving system performance and resourceutilization for modular systems.

By combining a kernel that provides commonly usedbase services with loosely-coupled dynamic modulesthat interact to form applications, SOS provides a moregeneral purpose sensor network operating system andsupports efficient changes to the software on deployednodes.

We use the SOS operating system in our research andin the classroom, and support users at other sites. Thesystem is freely downloadable; code and documentationare available at:http://nesl.ee.ucla.edu/projects/sos/.

175

ACKNOWLEDGEMENTS

We gratefully acknowledge the anonymous reviewersand our shepherd, David Culler. Thanks goes out theXYZ developers and other users of SOS who have pro-vided feedback and help to make better system. This ma-terial is based on research funded in part by ONR throughthe AINS program and from the Center for EmbeddedNetwork Sensing.

REFERENCES[1] ABRACH, H., BHATTI, S., CARLSON, J., DAI, H., ROSE, J.,

SHETH, A., SHUCKER, B., DENG, J., AND HAN, R. Man-tis: system support for multimodal networks of in-situ sensors.In Proceedings of the 2nd ACM international conference onWireless sensor networks and applications (2003), ACM Press,pp. 50–59.

[2] BERSHAD, B. N., SAVAGE, S., PARDYAK, P., SIRER, E. G., FI-UCZYNSKI, M., BECKER, D., EGGERS, S., AND CHAMBERS,C. Extensibility, safety and performance in the SPIN operat-ing system. In 15th Symposium on Operating Systems Principles(Copper Mountain, Colorado, 1995), pp. 267–284.

[3] BOULIS, A., HAN, C.-C., AND SRIVASTAVA, M. B. Design andimplementation of a framework for efficient and programmablesensor networks. In Proceedings of the First International Con-ference on Mobile Systems, Applications, and Services (2003),ACM Press, pp. 187–200.

[4] CROSSBOW TECHNOLOGY, INC. Mote In-Network Program-ming User Reference, 2003.

[5] DUNKELS, A., GRONVALL, B., AND VOIGT, T. Contiki - alightweight and flexible operating system for tiny networked sen-sors. In Proceedings of the First IEEE Workshop on EmbeddedNetworked Sensors (2004).

[6] ENGLER, D. R., KAASHOEK, M. F., AND O’TOOLE, J. Exok-ernel: An operating system architecture for application-level re-source management. In Symposium on Operating Systems Prin-ciples (1995), pp. 251–266.

[7] FOK, C., ROMAN, G.-C., AND LU, C. Rapid development andflexible deployment of adaptive wireless sensor network appli-cations. Tech. Rep. WUCSE-04-59, Washington University, De-partment of Computer Science and Engineering, St. Louis, 2004.

[8] GAY, D., LEVIS, P., VON BEHREN, R., WELSH, M., BREWER,E., AND CULLER, D. The nesc language: A holistic approach tonetworked embedded systems. In Proceedings of ProgrammingLanguage Design and Implementation (2003).

[9] HILL, J., SZEWCZYK, R., WOO, A., HOLLAR, S., CULLER,D., AND PISTER, K. System architecture directions for net-worked sensors. In Proceedings of the ninth international con-ference on Architectural support for programming languages andoperating systems (2000), ACM Press, pp. 93–104.

[10] HUI, J. W., AND CULLER, D. The dynamic behavior of a datadissemination protocol for network programming at scale. InProceedings of the second international conference on Embed-ded networked sensor systems (2004), ACM Press.

[11] JEONG, J., AND CULLER, D. Incremental network programmingfor wireless sensors. In Proceedings of the First IEEE Communi-cations Society Conference on Sensor and Ad Hoc Communica-tions and Networks IEEE SECON (2004).

[12] JUANG, P., OKI, H., WANG, Y., MARTONOSI, M., PEH, L.-S.,AND RUBENSTEIN, D. Energy-efficient computing for wildlifetracking: Design tradeoffs and early experiences with ZebraNet.In Proc. 10th International Conference on Architectural Support

for Programming Languages and Operating Systems (ASPLOS-X) (San Jose, California, Oct. 2002).

[13] KAISER, W., POTTIE, G., SRIVASTAVA, M., SUKHATME,G. S., VILLASENOR, J., AND ESTRIN, D. Networked Infome-chanical Systems (NIMS) for ambient intelligence.

[14] LEVIS, P., AND CULLER, D. Mate: A tiny virtual machine forsensor networks. In International Conference on ArchitecturalSupport for Programming Languages and Operating Systems,San Jose, CA, USA (Oct. 2002).

[15] LEVIS, P., MADDEN, S., GAY, D., POLASTRE, J., SZEWCZYK,R., WOO, A., BREWER, E., AND CULLER, D. The emergenceof networking abstractions and techniques in tinyos. In Proceed-ings of the First Symposium on Networked Systems Design andImplementation (2004), USENIX Association, pp. 1–14.

[16] LEVIS, P., PATEL, N., CULLER, D., AND SHENKER, S. Trickle:A self-regulating algorithm for code propagation and mainte-nance in wireless sensor networks. In Proceedings of the FirstSymposium on Networked Systems Design and Implementation(2004), USENIX Association, pp. 15–28.

[17] LIU, T., AND MARTONOSI, M. Impala: a middleware system formanaging autonomic, parallel sensor systems. In Proceedings ofthe ninth ACM SIGPLAN symposium on Principles and practiceof parallel programming (2003), ACM Press, pp. 107–118.

[18] POLASTRE, J., HILL, J., AND CULLER, D. Versatile low powermedia access for wireless sensor networks. In Second ACM Con-ference on Embedded Networked Sensor Systems (2004).

[19] RASHID, R., JULIN, D., ORR, D., SANZI, R., BARON, R.,FORIN, A., GOLUB, D., AND JONES, M. B. Mach: a systemsoftware kernel. In Proceedings of the 1989 IEEE InternationalConference, COMPCON (San Francisco, CA, USA, 1989), IEEEComput. Soc. Press, pp. 176–178.

[20] REIJERS, N., AND LANGENDOEN, K. Efficient code distribu-tion in wireless sensor networks. In Proceedings of the 2nd ACMinternational conference on Wireless sensor networks and appli-cations (2003), ACM Press, pp. 60–67.

[21] SHNAYDER, V., HEMPSTEAD, M., RONG CHEN, B., ANDMATT WELSH, H. Powertossim: Efficient power simulation fortinyos applications. In Sensor Networks. In Proc. of ACM SenSys2003. (2003).

[22] STATHOPOULOS, T., HEIDEMANN, J., AND ESTRIN, D. A re-mote code update mechanism for wireless sensor networks. Tech.Rep. CENS-TR-30, University of California, Los Angeles, Cen-ter for Embedded Networked Computing, November 2003.

[23] TITZER, B. L., PALSBERG, J., AND LEE, D. K. Avrora: Scal-able sensor network simulation with precise timing. In FourthInternational Conference on Information Processing in SensorNetworks (2005).

NOTES1Soft reboot of many microcontrollers, including the Atmel AVR,

preserves on chip memory.2This source code is trimmed for clarity. Complete source code can

be downloaded separately.3Patch is being submitted to the TinyOS developers should they

wish to optimize for the case of a lightly loaded radio that is not ina low power mode.

176