The LiteOS : Towards -like Abstractions for Networks

Qing Cao, Tarek Abdelzaher John Stankovic Department of Department of Computer Science University of Illinois at Urbana-Champaign University of Virginia {qcao2, zaher}@cs.uiuc.edu [email protected] Tian He Department of Computer Science University of Minnesota [email protected]

Abstract sensor networks circle. The purpose of LiteOS is to sig- nificantly reduce such a learning curve. This philosophy is This paper presents LiteOS, a multi-threaded operating the operating system equivalent of network directions taken system that provides Unix-like abstractions for wireless sen- by companies such as Arch Rock [1] (that superimposes a sor networks. Aiming to be an easy-to-use platform, LiteOS familiar IP space on mote platforms to reduce the learning offers a number of novel features, including: (1) a hier- curve of network programming and management). archical file system and a wireless shell for user interaction using UNIX-like commands; (2) kernel support Our key contribution is to present a familiar, Unix-like for dynamic loading and native execution of multithreaded abstraction for wireless sensor networks by leveraging the applications; and (3) online debugging, dynamic memory, likely existing knowledge that common system program- and file system assisted communication stacks. LiteOS also mers (outside the current sensor network community) al- supports updates through a separation between the ready have: Unix, threads, and . By mapping sensor net- kernel and user applications, which are bridged through a works to file directories, it allows applying user-friendly suite of system calls. Besides the features that have been im- operations, such as file directory commands, to sensor net- plemented, we also describe our perspective on LiteOS as works, therefore reducing the learning curve for operating an enabling platform. We evaluate the platform experimen- and programming sensor networks. tally by measuring the performance of common tasks, and LiteOS differs from both current sensor network oper- demonstrate its programmability through twenty-one exam- ating systems and more conventional embedded operating ple applications. systems. Compared to the former category, such as TinyOS, LiteOS provides a more familiar environment to the user. Its 1 Introduction features are either not available in existing sensor network This paper introduces LiteOS, an operating system that operating systems, such as the shell and the hierarchical file provides Unix-like abstractions to wireless sensor networks. system, or are only partially supported. Compared to the LiteOS maps a sensor network into a UNIX-like file system, latter category (conventional embedded operating systems), and supports extremely resource-constrained nodes such as such as VxWorks [29], eCos [2], embedded , and MicaZ. It supports C programming natively, and allows on- Windows CE, LiteOS has a much smaller code footprint, line debugging to locate application bugs. We believe that running on platforms such as MicaZ, with an 8MHz CPU, such an operating system could potentially expand the cir- 128K bytes of program flash, and 4K bytes of RAM. Em- cle of sensor network application developers by providing bedded operating systems, such as VxWorks, require more a familiar programming environment. While TinyOS and computation power (e.g., ARM-based or XScale-based pro- its extensions have significantly improved programmability cessors) and more RAM (at least tens of KBytes), and thus of mote-class embedded devices via a robust, modular en- cannot be easily ported to MicaZ-class hardware platforms vironment, NesC and the event-based programming model (such as MicaZ, Tmote, and Telos). introduce a learning curve for most developers outside the A possible counter-argument to our investment in a small-footprint UNIX-like operating system is that, in the aging familiar abstractions is advisable. One approach is near future, Moore’s law will make it possible for conven- to build user-friendly applications and GUIs such as Sen- tional Linux and embedded operating systems to run on sorMap [25] and MoteView [7]. In this paper, we explore motes. For example, the recent iMote2 [6] platform by a complementary solution that targets the operating system CrossBow features an XScale processor that supports em- and programming environment. bedded Linux. Sun and also demonstrated more pow- In additional to proposing several novel features, LiteOS erful sensor network hardware platforms [3, 24]. While it is also draws from previous research efforts. Its shell sub- true that more resources will be available within the current system is directly inspired by Unix, by adopting Unix-like mote form factor, Moore’s law can also be harvested by de- commands. The advantage of such command-line shells is creasing the form factor while keeping resources constant. that they are well-established mechanisms to interact with For example, the current MicaZ form factor is far from ade- complicated systems, providing powerful scripting and au- quate for wearable computing applications. Wearable body tomation support. Previous systems, such as Mantis and networks can have a significant future impact on health- , have implemented shell interfaces on resource- care, leisure, and social applications if sensor nodes could constrained motes. In contrast, LiteOS implements the shell be made small enough to be unobtrusively embedded in at- on the resource-rich PC side (basestation). This design tire and personal effects. These applications will drive the choice allows us to implement more powerful commands, need for small-footprint operating systems and because the shell is no longer constrained by as computation migrates to nodes that are smaller, cheaper, resources. and more power-efficient. This paper serves as a proof of There have also been efforts to provide file systems concept by pushing the envelope within the constraints of a for MicaZ-class sensor nodes, such as MatchBox [11] and current device; namely, the MicaZ motes. ELF [8], as well as flash-based systems, where additional We have implemented LiteOS on the MicaZ platform. flash is plugged to sensor nodes, such as Capsule [22]. To The LiteOS software is available for download at the web- implement the file system of LiteOS, we did not adopt the site http://www.liteos.net, including its manual, program- former because their interfaces do not match our goals: ming guide, application notes, and source code. Matchbox and ELF do not support hierarchical file orga- The rest of this paper is organized as follows. Section 2 nizations, and only provide basic abstractions for file oper- describes the related work. Section 3 introduces the LiteOS ations such as reading and writing. On the other hand, we operating system and describes its design and implemen- did not adopt the latter because it requires an external flash tation. Section 4 introduces its programming environment attachment. In contrast, we want users with off-the-shelf and application examples. Section 5 presents the evalua- MicaZ nodes to be able to directly use LiteOS. tion results. Section 6 outlines more features that LiteOS The third subsystem of LiteOS, its kernel, features dy- currently supports. Section 7 discusses the potential of this namic loading, a feature that is taken for granted in almost platform. Section 8 concludes this paper. every modern operating system. One approach to imple- 2 Related Work ment dynamic loading is based on virtual memory. While The rapid advances of sensor networks in the past few virtual memory support in MicaZ-class sensor networks has years created many exciting systems and applications. Op- been implemented [14, 20], we observe that such efforts erating systems such as TinyOS [16], Contiki [9], SOS [15], slow down program execution, because of the lack of hard- Mantis [5], t-Kernel [14], and Nano-RK [10] provided soft- ware support for page tables and the limited computation ware platforms. Middleware systems such as TinyDB [21] power of the CPU. While the direction of supporting dy- and EnviroTrack [4] made fast development of special- namic loading with the help of virtual memory may still be ized applications feasible. Deployed applications ranged possible, several previous efforts have tried alternative ap- from global climate monitoring to animal tracking [18], proaches to implement dynamic loading in sensor networks. promising unprecedented sampling of the physical world. The dynamic loading mechanism of LiteOS follows the Widespread adoption and commercialization of sensor net- line of several previous efforts in the literature that did not works is the next logical step. involve virtual memory such as TinyOS (using XNP), SOS, The most obvious challenge in sensor network devel- and Contiki. In XNP, a boot loader provides loading ser- opment has been to fit within extremely constrained plat- vice by reprogramming part of the flash and jumping to its form resources. Previous work, such as TinyOS, there- entry point to dispatch it. While this approach is practical, fore focused on reducing overhead and increasing robust- it cannot load more than one application, due to potential ness. Since initial users were researchers, compatibility conflicts in memory accesses. SOS, on the other hand, pro- with common embedded computing environments was not poses to use modules. Its key idea is that if modules only a major concern. Moving forward, to decrease the bar- use relative addresses rather than absolute addresses, they rier to widespread adoption and commercialization, lever- are relocatable. However, compiling such relocatable code

2 Table 1. Shell Commands Command List File Commands ls, cd, cp, rm, mkdir, touch, pwd, du, chmod Commands ps, kill, exec debug, list, print, set Debugging Commands breakpoint, continue, snapshot, restore Environment Commands history, who, man, echo Device Commands ./DEVICENAME

Once mounted, a LiteOS node looks like a file directory from the base station. A sensor network, therefore, maps into a higher level directory composed of node-mapped di- rectories. The shell, called LiteShell, supports UNIX com- mands, such as copy (cp), executed on such directories. The Figure 1. LiteOS Operating System Architec- external presentation of LiteShell is versatile. While our ture current version resembles closely a UNIX terminal in ap- pearance, it can be wrapped in a (GUI), appearing as a “sensor network drive” under Win- has size limitations: the for the AVRplatform (Mi- dows or Linux. caZ) only supports such binaries up to 4K bytes. Contiki The basic (stripped-down) version of LiteOS is geared takes yet another approach, where it parses ELF files to for trusted environments. This choice of default helps re- patch all unsolved symbolic links, and performs binary re- duce system overhead when the trust assumptions are satis- location with the help of a symbol table in its kernel. The fied. In more general scenarios, where security concerns are approach in LiteOS does not handle ELF files directly, in- relevant, an authentication mechanism is needed between stead, it uses modified HEX files, which are smaller in size, the base station and mounted motes. Low-cost authentica- to store relocation information. tion mechanisms for sensor networks have been discussed 3 The LiteOS Operating System in prior literature and are thus not a focus of this paper [26]. In this section, we present the LiteOS operating system. 3.2 LiteShell Subsystem We first present an overview and its design choices, then we describe its three subsystems. The LiteShell subsystem provides Unix-like command- line interface to sensor nodes. This shell runs on the base 3.1 Architectural Overview station PC side. Therefore, it is a front-end that interacts Figure 1 shows the overall architecture of the LiteOS op- with the user. The motes do not maintain command-specific erating system, partitioned into three subsystems: LiteShell, state, and only respond to translated messages (represented LiteFS, and the kernel. Implemented on the base station PC by compressed tokens) from the shell, which are sufficiently side, the LiteShell subsystem interacts with sensor nodes simple to parse. Such an asymmetric design choice not only only when a user is present. Therefore, LiteShell and LiteFS significantly reduces the code footprint of the LiteOS kernel are connected with a dashed line in this figure. that runs on motes, but also allows us to easily extend the LiteOS provides a wireless node mounting mechanism shell with more complicated commands, such as authenti- (to use a UNIX term) through a file system called LiteFS. cation and security. Much like connecting a USB drive, a LiteOS node mounts Currently, we have implemented the commands listed in itself wirelessly to the root filesystem of a nearby base Table 3. They fall into five categories: file commands, pro- station. Moreover, analogously to connecting a USB de- cess commands, debugging commands, environment com- vice (which implies that the device has to be less than a mands, and device commands. USB-cable-length away), our wireless mount currently sup- 3.2.1 File Operation Commands ports devices within wireless range. The mount mechanism comes handy, for example, in the lab, when a developer File commands generally maintain their Unix meanings. might want to interact temporarily with a set of nodes on For example, the ls command lists directory contents. It a table-top before deployment. While not part of the cur- supports a -l option to display detailed file information, such rent version, it is not conceptually difficult to extend this as type, size, and protection. To reduce system overhead, mechanism to a “remote mount service” to allow a network LiteOS does not provide any time synchronization service, mount. Ideally, a network mount would allow mounting a which is not needed by every application. Hence, there is device as long as a network path existed either via the In- no time information listed. As an example, a ls -l command ternet or via multi-hop wireless communication through the may return the following: sensor network. $ls-l

3 Name Type Size Protection 3.2.3 Debugging Commands usrfile file 100 rwxrwxrwx usrdir dir --- rwxrwx--- We now describe the debugging commands. Eight com- mands are provided, including those for setting up the de- In this example, there are two files in the current direc- bugging environment (debug), watching and setting vari- tory (a directory is also a file): usrfile and usrdir. LiteOS ables (list, print,andset), adding/removing breakpoints enforces a simple multilevel access control scheme. All (breakpoint and continue), and application checkpoints 0 2 2 users are classified into three levels, from to ,and is (snapshot and restore). Note that all debugging commands the highest level. Each level is represented by three bits, keep information on the front-end, i.e., the PC side. In stored on sensor nodes. For instance, the usrdir directory fact, there is no debugging state stored on the mote, which 1 2 can be read or written by users with levels and . means that there is no limit on the maximum number of Once sensor nodes are mounted, a user uses the above variables (or the size of variables) can be watched, or how commands to navigate the different directories (nodes) as if many breakpoints can be added. We now briefly explain they are local. Some common tasks can be greatly simpli- these commands. Detailed documentation of these com- fied. For example, by using the cp command, a user can mands can be found in the LiteOS manual. either copy a file from the base to a node to achieve wire- The user first invokes the debug command to initiate less download, or from a node to the base to retrieve data the environment. This command takes the source code di- results. The remaining file operation commands are intu- rectory of the application as its parameter. For example, itive. Since LiteFS supports a hierarchical file system, it if supplied with the kernel source code location, it allows provides mkdir, rm and cd commands. debugging the kernel itself. Once invoked, this command 3.2.2 Process Operation Commands parses the source code as well as the generated assembly to gather necessary information, such as memory locations LiteOS has a multithreaded kernel to run applications as of variables. Such information is then used by other de- threads concurrently. LiteShell provides three commands bugging commands for diagnosis purposes. For instance, to control behavior: ps, exec,andkill. We illustrate it is used by the command list to display the current vari- these commands through an application called Blink, which ables and their sizes, commands print and set to watch blinks LEDs periodically. Suppose that this application has and change variable values, and commands breakpoint and been compiled into a binary file called Blink.lhex1,andis continue to add and remove breakpoints. Once a breakpoint located under the C drive of the user’s . To install it is added, the command ps tells whether a thread has reached on a node named node101 (that maps to a directory with the the breakpoint. same name) in a sensor network named sn01, the user may We now explain the commands snapshot and restore. use the following commands: Snapshot allows adding a checkpoint to an active thread, $ pwd by exporting all its memory information, including variable Current directory is /sn01/node101/apps $ cp /c/Blink.lhex Blink.lhex values, stack, and the program counter, to an external file. Copy complete Restore, on the other hand, allows importing such mem- $ exec Blink.lhex File Blink.lhex successfully started ory information from a previously generated file, essentially $ps restoring a thread to a previous state. Combined use of these Name State Blink Sleep two commands allows replaying part of an application by rewinding it, and is particularly useful for locating unex- As illustrated in this example, we first copy an applica- pected bugs. tion, Blink.lhex, into the /apps directory, so that it is stored in the LiteFS file system. We then use the exec command to 3.2.4 Environment Commands start this application. The implementation of exec is as fol- The next four commands support environment manage- lows. The processor architecture of Atmega128 follows the ment: history for displaying previously used commands, Harvard architecture, which provides a separate program who for showing the current user, man for command ref- space (flash) from its data space (RAM). Only instructions erences, and echo for displaying strings. The meanings of that have been programmed into the program space can be these commands are similar to their Unix counterparts. executed. Hence, LiteOS reprograms part of the flashtorun the application. 3.2.5 Device Commands Once the Blink application is started, the user may view The LiteOS shell provides an easy way to interact with the its thread information using the ps command. Finally, the . Every time the file system is initialized, a directory kill command is used to terminate threads. dev is created, which contains files that map to actual device 1LiteOS uses a revised version of the Intel hex format, called lhex, to drivers. On MicaZ, the dev directory contains the following store binary applications. lhex stands for LiteOS Hex. files:

4 Table2.LiteFSAPIList API Usage API Interface Open file FILE* fopen(const char *pathname, const char *mode); Close file int fclose(FILE *fp); Seek file int fseek (FILE *fp, int offset, int position); Test file/directory int fexist(char *pathname); Create directory file int fcreatedir(char *pathname); Delete file/directory int fdelete(char *pathname); Figure 2. LiteShell Implementation Read from file int fread(FILE *fp, void *buffer, int nBytes); Write to file int fwrite(FILE *fp, void *buffer, int nBytes); Move file/directory int fmove(char *source, char *target); Copy file/directory int fcopy(char *source, char *target); $ls Format file system void formatSystem(); led, light, temp, magnet, accel, Change current directory void fchangedir(char *path); Get current directory void fcurrentdir(char *buffer, int size); In this directory, led refers to the LED device. There are Check EEPROM Usage int fcheckEEPROM(); Check Flash Usage int fcheckFlash(); four sensors, light, temperature, magnetic, and accelerator, Search by name void fsearch(char *addrlist, int *size, char *string); respectively. There is also the radio device, which sends and Get file/directory info void finfonode(char *buffer, int addr); receives packets. An example of reading 100 data samples from the light sensor at a frequency of 50 milliseconds is RAM EEPROM Flash written as follows, where the first parameter is the frequency 256 storage blocks 65 control blocks and the second parameter is the number of readings. File Handle F 2K ( x 8 ) D ./light 50 100 F 2K EEPROM 3.2.6 Implementation of LiteShell Bit Vector Root D Figure 2 illustrates the implementation of LiteShell. Its F 2K Flash D command processor interprets user commands into internal Bit Vector F 2K forms, communicates with the sensor network, and replies to the user. To reduce overhead, sensor nodes are stateless. All state information regarding user operations, such as the Figure 3. LiteFS Architecture current working directory, is maintained by the shell, while the sensor nodes only respond to interpreted commands us- ing an ACK-based reliable communication protocol. and the allocation information of EEPROM and the data As an additional note, not every command can always be flashinthefirst module, uses EEPROM to keep hierarchical successfully completed. For example, when the user installs directory information in the second, and uses the data flash an application, if the remaining program flash and RAM of to store files in the third. Just like Unix, files in LiteFS rep- a node are not sufficient for a binary to be loaded, the node resent different entities, such as data, application binaries, responds with an error message. and device drivers. A variety of device driver files, includ- 3.3 LiteFS Subsystem ing radio, sensor, and LED, are supported. Their read/write operations are mapped to real hardware operations. For ex- We now describe the LiteFS subsystem. The interfaces ample, writing a message to the radio file (either through the of LiteFS provide support for both file and directory opera- shell by a user or through a by an application) tions.The APIs of LiteFS are listed in Table 2. maps to broadcasting this message. While most of these APIs resemble those declared in In RAM, our current version of LiteOS supports eight “stdio.h” in C, some of them are customized for sensor net- file handles (this number is adjustable according to applica- works. For instance, two functions, fcheckEEPROM and tion needs), where each handle occupies eight bytes. Hence, fcheckFlash, are unique in that they return the available at most eight files can be opened simultaneously. LiteFS space on EEPROM and the data flash, respectively. An- uses two bit vectors to keep track of EEPROM/flash alloca- other feature of LiteFS is that it supports simple search- tion, one with 8 bytes for EEPROM, the other with 32 bytes by-filename using the fsearch API, where all files whose for the serial flash. A total of 104 bytes of RAM are used to names match a query string are returned. These APIs can support these bit vectors. be exploited in two ways; either by using shell commands In EEPROM, each file is represented as a 32-byte con- interactively, or by using application development libraries. trol block. LiteFS currently uses 2080 bytes of the 4096 bytes available in EEPROM to store hierarchical directo- 3.3.1 Implementation of LiteFS ries, while the remaining EEPROM is available for other Figure 3 shows the architecture of LiteFS, which is parti- needs. These 2080 bytes are partitioned into 65 blocks. The tioned into three modules. It uses RAM to keep opened files first block is the root block, which is initialized every time

5 Program Space LiteOS Kernel Process 1 Process 2 Allocation Memory Map Memory Map Memory Map 3.4.2 Dynamic Loading in LiteOS Program Memory Data Memory Data Memory Data Memory $0000 $0000-$001F Interrupt Vectors 32 Registers 32 Registers 32 Registers $0020-$005F LiteOS provides two approaches for dynamic loading of 64 I/O Registers 64 I/O Registers 64 I/O Registers $0060-$00FF 160 Ext I/O Reg. 160 Ext I/O Reg. 160 Ext I/O Reg. user applications. These approaches allow multiple threads $0100 LiteOS Kernel Memory Sections for LiteOS Kernel to be concurrently executed without memory access con- (.data .bss .noinit) flicts. Figure 4 illustrates such an example, where six Memory Sections for Process 1 (.data .bss .noinit) threads (besides the kernel) are executed. Note that the

Process 1 Binary Stack space for Thread 1A memory sections of different threads do not overlap, and Stack space for Thread 1B threads are executed natively. Process 2 Binary Stack space for Process 1 In the first loading approach, we assume that the source Memory Sections for Process 2 (.data .bss .noinit) code is available. Every time the user needs to load the Stack space for Thread 2A binary to a different location, the source code is re-compiled Stack space for Thread 2B with different memory settings. This approach introduces Stack space for Process 2 no extra overhead, and generates smaller binary images. In the second approach, we do not assume the source Self-programming support located in Stack space for Stack space for Stack space for the boot-loader LiteOS Kernel LiteOS Kernel LiteOS Kernel code is available for the user. This approach remotely (part of LiteOS $10FF (4K bytes) kernel) $FFFF echoes the differential patching idea [17, 28] in application (64K words) distributions over networks. Different from that idea, how- Figure 4. LiteOS Memory Organization ever, we directly encode relocation information into appli- cation binaries, by fitting differential patches with mathe- matical models, and distributing these models together with the file system is formatted. The other 64 blocks are either binary images. With such models, the kernel is able to directory blocks (specified with D) or file blocks (specified rewrite part of the binary images for relocation. with F) according to application needs. Just like Unix, files Our development of mathematical models for differen- represent data, binary applications, and device drivers. tial patches is driven by practical observations, and is cus- We follow three design choices in LiteFS. First, the max- tomized for our GCC-based toolchain. We start presenting imal length of a file name is 12 bytes. Therefore, the Eight its details by observations of binary instructions. When the Dot Three naming system is supported. Second, a file con- kernel loads a binary to different memory locations, the po- trol block addresses at most ten logical flash pages. Each tential factors that affect the image can be written as a vec- page holds 2K bytes of data (or 8 physical flash pages). If a tor (S, M, T), where S is the start address of the binary exe- file occupies more than 20K bytes, LiteFS allocates another cutable in the program flash, M the start address of allocated control block for this file, and stores the address of the new memory, and T the stack top. Observe that the difference block in the old one. Third, all control blocks reside in EEP- between T and M is the actual memory space allocated for ROM rather than in RAM. this executable, whose minimum requirement can be stat- ically decided using a technique called stack analysis (as 3.4 LiteOS Kernel Subsystem long as the application has no recursive functions). Several such tools are available [23, 27]. Therefore, we assume that 3.4.1 Kernel Overview the stack top has been statically decided. Threads are the most commonly used concurrency mech- Because (S, M, T) is volatile, we have to find a way to anism in modern general purpose operating systems. In encode its impact. Experimentally, we observe that as the sensor networks, there are design tradeoffs between us- vector changes, it only affects the immediate operands of a ing threads and events. Both approaches have been im- few instructions. More specifically, of the 114 instructions plemented in previous research efforts. TinyOS [16] provided by the Atmega128 processor (on MicaZ), under and SOS [15] are based on events, Mantis [5] and our customized GCC compiling environment, only the fol- TinyThreads [23] choose threads, and Contiki [9] provides lowing six instructions are affected: LDI, LDS, STS, JMP, support for both. CALL, CPI. The detailed meanings of these instructions The kernel subsystem of LiteOS takes the thread ap- can be found in the datasheet of Atmega128. We call them proach, but it also allows user applications to handle events differential instructions. using callback functions for efficiency. We implement both We use an example to illustrate the major steps of our priority-based and round-robin scheduling in the address translation procedure. In this example, we sample kernel. We also support dynamic loading and un-loading of the light sensor for 100 times, at a frequency of once per user applications, as well as a suite of system calls for the second, and write readings into a local file in LiteFS. Using separation between kernel and applications. We now de- the GCC compiler, this application compiles to 358 instruc- scribe these topics in more detail. tions consuming 790 bytes of binary. We compiled it with

6 Section Address = 0x500 = 0x504 = 0x600 always generate training binary images, serving as verifica- _do_copy ① 19098 ldi r17, 0x05 ldi r17, 0x05 ldi r17, 0x06 _data ② 1909a ldi r26, 0x00 ldi r26, 0x04 ldi r26, 0x00 tions of the mathematical models. ③ 1909c ldi r27, 0x05 ldi r27, 0x05 ldi r27, 0x06 ④ 190ac cpi r26, 0x0C cpi r26, 0x10 cpi r26, 0x0C ⑤ 190ae cpc r27, r17 cpc r27, r17 cpc r27, r17 3.4.3 System Calls and Software Compatibility _do_clear ⑥ 190b2 ldi r17, 0x05 ldi r17, 0x05 ldi r17, 0x06 _bss ⑦ 190b4 ldi r26, 0x0C ldi r26, 0x10 ldi r26, 0x0C To distribute applications using the LiteOS HEX format, ⑧ 190b6 ldi r27, 0x05 ldi r27, 0x05 ldi r27, 0x06 one important problem is software compatibility. To re- ⑨ 190bc cpi r26, 0x14 cpi r26, 0x18 cpi r26, 0x14 ⑩ 190be cpc r27, r17 cpc r27, r17 cpc r27, r17 duce redundancy, LiteOS provides system resources, such main ⑪ 190d2 ldi r22, 0x00 ldi r22, 0x04 ldi r22, 0x00 as LiteFS, drivers, and thread services for user applications. ⑫ 190d4 ldi r23, 0x05 ldi r23, 0x05 ldi r23, 0x06 ⑬ 190d6 ldi r24, 0x02 ldi r24, 0x06 ldi r24, 0x02 If the LiteOS kernel is modified, the addresses of its internal ⑭ 190d8 ldi r25, 0x05 ldi r25, 0x05 ldi r25, 0x06 data structures will change. If not handled carefully, such an updated kernel will no longer support binaries compiled Figure 5. Binary Image Difference Example for older versions of LiteOS. While this problem can be de- tected easily (through version numbers), we are interested in how to avoid such incompatibilities. three M settings, 0x500, 0x504,and0x600, and compared We introduce lightweight system calls to address com- the compiled code in the assembly level. We found a total of patibility. Our implementation is based on revised call- 12 different instructions out of these 358 instructions. Se- gates, a special type of function pointers. These callgates mantically, they are grouped into three difference clusters, are the only access points through which user applications shown in Figure 5. access system resources. Therefore, they implement a strict We list a total of 14 instructions, including two instruc- separation between the kernel and user applications. As tions (5 and 10 ) that are not differential, but are useful long as the system calls remain supported by future versions for our following explanations. Before illustrating what we of LiteOS, user binaries do not need to be recompiled. can do, we start with what we cannot do. Generally, it is At the system kernel side, each system call gate takes almost impossible to leverage the semantic relationships to 4 bytes, with 1024 bytes of program space allocated for construct models. For example, in Figure 5, instructions 1 at most 256 system calls. Compared to directly invoking to 5 are part of the initialization of the data segment before kernel functions, each system call adds 5 instructions (10 the main program runs. The same is true for instructions 6 CPU cycles), a sufficiently low overhead to be supported on to 10 , which serve the function of clearing the bss section MicaZ. At the user side, interactions with system calls are (for storing global variables). Such kind of implicit rela- provided as libraries. The details of call gates are therefore tionships only emerge by application specific analysis, but hidden from user applications. are beyond the capability of our mathematical models. In our design, we take an application independent ap- 4 The Programming Environment proach to model the impact of (S, M, T). We analyze the In this section, we briefly describe the programming en- differences between compiled images under different mem- vironment of LiteOS. This section is organized as follows. ory settings, generate linear models to fit such differences, We first present a concrete programming example, then we and test the models with training data. For differential describe the programming model details. instructions, their values under different (S, M, T) vectors 4.1 The “Hello, World” Example demonstrate a set of linear displacements. This follows di- rectly from the format of machine code for various address- As a concrete example of how to program in LiteOS, we ing modes. In the previous example, except non-differential use the classical “Hello, World” example. The source code instructions 5 and 10 , f can be written as follows: of this application is shown as follows. Lines starting with #include are not listed. V =((aM + b) >> L) << R (1) int main() In this equation, the values of a, b, L and R are to be { while (1) { solved, >> is the right-shifting operation, and << is the radioSend_string("Hello, world!\n"); opposite. After solving these variables for the previous ex- greenToggle(); sleepThread(100); ample, the f function of 1 is determined as M >> 8 } (a =1, b =0, L =8,andR =0). return 0; } While our discussions so far are only about M,thesame approach applies to S and T.Thefinal form of f is typi- 4.2 Programming Model cally a superposition of different linear equations for S, M, and T,andissufficiently simple to be encoded into binary We use programming model to refer to a developer’s images. To ensure that our approach works correctly, we view of a programming environment. In TinyOS/NesC [12,

7 13], the view is that an application is driven by events, not a problem because it wastes a few hundred CPU cycles, which can optionally post long-running tasks to a FIFO less than 0.1ms. For computationally intensive applications, scheduler. A complicated program typically needs state ma- however, user applications want to reduce overhead. LiteOS chines, because TinyOS does not directly support execution provides another primitive for this purpose: callback func- contexts. For instance, in writing reliable communication tions. stacks, the developer sometimes wants to do the following: A callback function registers to an event, which could after sending a packet, a node waits for a period Ttimeout range from radio events to detections of targets, and is in- (after which the previous packet is considered lost), or stops voked when such an event occurs. For instance, the function waiting if an acknowledgement is received. In the program- registerRadioEvent tells that a message has been received. ming model of TinyOS, such a task is decomposed into two Its prototype is defined as follows: events: a timeout event, and a radio receive event. Because void registerRadioEvent(uint8_t port, uint8_t *msg, the order of these two events is not predictable, a devel- uint8_t length, void (*callback)(void)); oper introduces two states in the state machine, and han- This interface requires the user thread to provide a buffer dles their possible transitions. If the number of states grows space for receiving incoming messages. After the kernel large, handling state transitions usually becomes compli- copies the message to this buffer, it invokes the callback cated. Such difficulties motivated several research efforts to function. Based on this mechanism, the previous reliable simplify application development, such as protothreads [9] communication example can be implemented as follows: and the OSM model [19]. Part I: Application In contrast to the event based programming model adopted by TinyOS, LiteOS uses threads to maintain ex- 1 bool wakeup = FALSE; ecution contexts. For example, in the previous “Hello, 2 uint8_t currentThread; 3 currentThread = getCurrentThreadIndex(); World” example, every time the function radioSend string 4 registerRadioEvent(MYPORT, msg, length, packetReceived); is called, the thread is suspended until the radio operation 5 sleepThread(T_timeout); 6 unregisterRadioEvent(MYPORT); finishes. Threads, however, do not completely eliminate the 7 if (wakeup == TRUE) {...} use of events for efficiency reasons. Observe that there are 8 else {...} two types of events: internally generated events, and ex- Part II: Callback function ternally generated events. For instance, a sendDone event 9 void packetReceived() always follows a packet sending operation, and is there- 10 { fore internally generated. A radio receive event, however, 11 _atomic_start(); 12 wakeup = TRUE; is triggered by external events, and may not be predictable. 13 wakeupThread(currentThread); LiteOS treats these two types of events separately. Gener- 14 _atomic_end(); 15 } ally, internally generated events are implicitly handled by using threads, where events like sendDone are no longer We briefly explain this example. First, the thread listens visible. It is the externally generated events that deserves on MYPORT, and allocates a buffer for receiving incoming special attention. packets (line 4). This thread then sleeps (line 5). When it We illustrate how externally generated events are han- wakes up, it checks if it has been woken by the callback dled using the radio receive event as an example. LiteOS function (line 7), or by a timeout event (line 8). The thread provides two solutions to handle this event. The first is to then handles these two cases separately. create a new thread using the createThread system call, A potential risk of this model is race conditions, which which blocks until the message arrives2. Consider a reli- only exist between variables in user applications, because able communication example. Suppose that the application the variables in the kernel are not directly accessible. thread creates a child thread to listen to possible acknowl- Hence, a must ensure that every variable that edgements. If such a message is received before T timeout, is accessed asynchronously by multiple threads is protected the child thread wakes up its parent thread using the wake- by atomic operations. Otherwise, if a thread that is modify- upThread method. Otherwise, if its parent thread wakes up ing this variable gets preempted, and another thread modi- without receiving an acknowledgement, this child thread is fies this variable again, race conditions occur. One improve- terminated by its parent thread using the terminateThread ment is to automatically detect potential race conditions in method. the compiler, as the NesC compiler does. While this thread-based approach is usually sufficient for 5 Evaluation handling externally generated events, it introduces the over- head of creating and terminating threads. This is typically 5.1 LiteShell Performance Evaluation

2LiteOS classifies radio messages using ports, where the kernel deliv- We now evaluate the performance of LiteShell, focusing ers messages to threads listening on matching ports. on response time. In the following experiments, we classify

8 16000 Copy Command Latency (Node to Base station) Table 3. Shell Commands Classification 14000 Command List Copy Command Latency (Base station Local Commands pwd, echo, who, man, history 12000 to Node) Copy Command Latency (Node to cp, rm, mkdir, touch 10000 Network Commands Node through Base station)

du, ps, kill, exec, ls Latency (ms)

d 8000 500 Average Response Time 6000 450 4000 400

350 Comman Copy 2000 300 0 256 512 1K 2K 4K 8K 250 File Size (bytes) 200 150 100 Figure 7. Average Copy Time using LiteShell

50 35000 8000 Average Response Time (ms) Time Response Average Read Throughput/Sequential Write Throughput/Sequential 0 30000 Read Throughput/Random 7000 Write Throughput/Random

ls/4 ls/8 rm mkdir touch du exec ps kill 25000 6000

5000 Command Name 20000 4000 15000 3000 10000

Figure 6. Average Command Response Time Throughput (bytes/second)

Throughput (bytes/second) 2000

5000 of LiteShell 1000

0 0 1248163264128 1248163264128 Block Size (Bytes) Block Size (Bytes) (a) Read Throughput of LiteFS (b) Write Throughput of LiteFS representative shell commands into two categories: those executed locally, and those communicating with nodes, as Figure 8. LiteFS Throughput listed in Table 3. We observe that local commands are typically finished dle of a file with the help of the fseek API. Therefore, we within one millisecond. Therefore, it is the second category performed both sequential and random reads and writes. of commands that affects users’ experience. We measured We observe a reading throughput up to 30 KBytes/s, the average response time of these commands by using a much higher than the writing throughput. Another obser- script to execute each command 100 times, and recorded vation is that when the block size is small, the random writ- the average response time of each command. The results ing throughput degrades exponentially. The reason is that it are shown in Figure 6. is very likely for a page-erase operation to occur for every As measured in this experiment, the average response writing operation, because the file pointer has been modi- time of these commands is typically less than half a second. fied to a random position. This is a form of thrashing, where While we can further optimize their performance by fine- the cache of the serial flash (264-byte SRAM) experiences tuning the communication protocol, the current response excessive misses. Because of this phenomenon, the random time is already quite acceptable. For example, our inter- throughput of LiteFS is lower, compared to throughput re- active performance is generally better than common experi- sults reported in the ELF file system [8], which followed a ences in Web browsing. different setting to test random throughput, where the file One special command that deserves further experiments pointer was modified only once and no thrashing occurred. is the cp command, whose response time depends on the size of the file to be transferred over the air. We experi- 5.3 Comparison of Programming Envi- mented with different file sizes, and list the results in Fig- ronments ure 7. As illustrated in this figure, the transfer rate is accept- able for common uses. We have implemented a suite of libraries for user pro- gramming in LiteOS. To evaluate its performance, we select 5.2 LiteFS Performance 21 benchmark applications shown in Figure 9. To compare LiteOS and TinyOS, our choices of benchmarks are limited To evaluate the performance of LiteFS, we focus on its to those available in standard TinyOS distributions (version throughput. The experiment results are shown in Figure 8. 1.1.x). All LiteOS applications are compiled into the modi- In this experiment, we wrote a simple application that re- fied HEX format (lhex format). We do not choose the ELF peatedly called the fread and fwrite APIs, and measured format because it has a much larger size (usually 5-10 times the time to complete I/O operations. By default, we used larger) compared to the HEX format. one file with 128K bytes, and experimented with different We used three metrics in the following experiments: read/write block sizes. LiteFS allows modifying the mid- code length as measured in lines of code after removing

9 Application Functionality 3 Number of Threads (LiteOS) Simple applications Blink, BlinkTask, CntToLeds, CntToLedsAndRfm, 2 (demonstrations of CntToRfm, CountRadio , GlowLeds, GlowRadio, simple APIs, total: 11) ReverseUSART, RfmToLeds, SenseToLeds 1

Pong Two nodes exchange messages Number of Threads Sense Sense the environment and report 0 SenseTask Sense the environment and report, using tasks GenericBase Base station to receive messages Number of Threads Oscilloscope Display data on PC a) Number of Threads for LiteOS Applications OscilloscopeRF Display data on PC, through the radio 300 SenseLightToLog Read sensors and store the value in flash Source code LOC (LiteOS) 250 Source code LOC (TinyOS) SenseToRfm Read sensors and report through the radio SimpleCmd Basic command interpretation 200

Surge Basic multi-hop program 150

100

Figure 9. Benchmark Applications SourceCode Linesof Code 50

0 all comments and blank lines, compiled number of bytes, where we use default settings for both LiteOS and TinyOS, Application Name and static RAM consumption of user applications3.We b) Source Code Length Comparison didn’t include the LiteOS kernel in the comparison because 1800 Compiled Code Size (LiteOS) 1600 Compiled Code Size (TinyOS) the functionalities it provides, such as its support for the 1400 shell and file system, are not available in the TinyOS ver- 1200 1000 sion of benchmark applications. To make fair comparisons, 800 we only included user side applications, where TinyOS sys- 600 tem modules are not included for the analysis (we used the (bytes) Size Code Compiled 400 200 module memory usage script in the contrib directory of 0 TinyOS to extract such modules). When writing benchmark applications under LiteOS, Application Name we implemented exactly the same functionalities as their c) Compiled Code Size Comparison 200 Static Memory Consumption (LiteOS) TinyOS counterparts that were measured. One excep- 180 Static Memory Consumption (TinyOS) tion is the Surge application, where we only implemented 160 140 the multi-hop spanning tree and data retrieval, while the 120 message queuing and command broadcast functionality in 100 80 the TinyOS version of Surge have not been implemented. 60 40 Memory Consumption (bytes) Therefore, we compared the LiteOS version to a partial 20 Surge application in TinyOS for fair comparison. Figure 10 0 shows the comparison results. Figure 10(a) shows the num- ber of threads for each LiteOS application, while TinyOS Application Name applications are all single-threaded. Given that LiteOS re- d) Static Memory Consumption Comparison moves event handlers, wiring, and interfaces, it is not sur- prising that, as shown in 10(b), the source code sizes of Figure 10. Benchmark Evaluation LiteOS applications are typically smaller than their TinyOS counterparts. While such a reduction may not necessarily Figure 10(d) shows the static memory usage comparison. mean that programming in LiteOS is easier, it is at least Observe that several applications consume more memory in promising for reducing the development cost of sensor net- LiteOS than in TinyOS, because their LiteOS versions are work applications. multithreaded. In fact, there is a strong correlation between Figure 10(c) shows the compiled code size (consump- the number of threads and the consumed RAM, by com- tion of program flash) comparison. Observe that while the paring figures (a) and (d), because extra threads consume LiteOS images include system calls, their code sizes are additional RAM for their own stacks. While it is possible comparable to TinyOS, indicating that the LiteOS program- to reduce the number of threads for some applications us- ming model does not introduce too much overhead. ing callback functions, we choose not to optimize this way 3We don’t compare stack usage because the stack consumption of because we want to show that, based on the benchmarks, TinyOS is attributed to both system services and user applications. It is the worst case RAM consumption of multithreaded applica- hard to measure stack consumption for user applications alone in TinyOS tions is still acceptable: even the GenericBase application applications. with three threads consumes fewer than 200 bytes of RAM.

10 6 Other Features of LiteOS its invocation history of the kernel system calls, and the dy- namics of its behavior across nodes. In this section, we describe three additional features f the LiteOS platform. Detailed documentation of these features Briefly speaking, the event logging service of LiteOS is is available at www..net. implemented as follows. We keep an internal buffer (its size decided by the user) to record the most recent application 6.1 File Assisted Communication Stacks events. We only log one application at a time. Therefore, The design of flexible and powerful communication we only need one byte for most events, up to 256 different stacks has been a critical challenge to sensor network ap- types, including all the system calls, certain kernel events plications. In LiteOS, we treat communication stacks, such such as context switches and driver invocations, and ap- as routing and MAC protocols, as threads. Hence, differ- plication specific events inserted by the user. Every time ent communication protocols can be exchanged easily, and an event triggers, a corresponding byte is written into the dynamically loaded just like any user application. buffer. When the buffer is full, we write its content into a To use a protocol, an application organizes the header of file stored in the external flash. Such recorded traces are packets in such a way that the communication protocol can obtained after experiments and are translated into a recog- correctly parse it. Packets are then sent to the port which nizable sequence of events. Therefore, the sensor node is the protocol is listening on. For example, a flooding proto- no longer a black box. Instead, we now have valuable in- col uses a different listening port compared to a multi-hop sight on why an application fails, and what we should do to routing protocol. In the following example, our multi-hop correct unexpected software glitches. routing protocol listens on port 10, and the application sends a packet of 16 bytes through this protocol using the follow- 7 Perspective ing code sample:

//10 is the port number, 0 means local node protocol In retrospect, several design choices become evident af- //16 is the message length, and msg is the message pointer radioSend(10, 0, 16, msg); ter finishing a prototype version of LiteOS. One advantage of LiteOS is that it supports interactive use. We believe an Our implementation of this multi-hop protocol (geo- interactive system (e.g., one that offers an interactive shell graphic forwarding) maintains a neighbor table of 12 en- to users and ) leads to improved productivity tries, and contains around 300 lines of code. Its binary im- at development time. Our experiences using LiteOS con- age consumes 1436 bytes of program flash, and 260 bytes firm this thesis. How will LiteOS affect the way we interact of RAM, including stack. Its overhead is so low that it can with sensor networks? With a graphical shell, it can serve co-exist with other protocols, such as flooding. The source as a sensor network drive that can be mounted to a PC and code of this protocol is available in LiteOS 0.3. controlled over Web browsers. Sensor networks can then become just another common peripheral. 6.2 Dynamic Memory Apart from promoting interactive use, there is a concep- LiteOS supports dynamic memory at the kernel level. tual question on the need for LiteOS. In sensor networks, The dynamic memory is provided as library APIs (malloc a few other operating systems have already been imple- function and free function) to user applications through sys- mented. Why do we need yet another one? To better un- tem calls. The dynamic memory grows in the opposite di- derstand the differences and similarities between LiteOS rection from the LiteOS stack, and resides completely in the and other operating systems, we compare some of them in unused memory between the end of the kernel variables, and Figure 11 for reference. The design of LiteOS is partially the start of user application memory blocks. Therefore, the inspired by Unix, as the title suggests. We believe that it size of dynamic memory can be adjusted after deployment is precisely its affinity to UNIX that could make LiteOS according to user applications’ needs. easier to be adopted by mainstream system programmers. 6.3 Event Logging One goal of LiteOS is to hopefully offer an easy transition path for those beginning sensor networks programmers who Visibility is a key challenge for wireless sensor net- are experienced in conventional systems programming, but work applications. Deployed on the extremely resource- not proficient with event-based programming, wiring, and constrained mote platform, such applications may fail un- state-machine abstractions of program execution. LiteOS expectedly, or exhibit behavior different from their intended and the previous sensor network operating systems, such as goals. To help understand why such problems occur, we de- TinyOS, therefore, fill complementary needs. We hope that sign and implement an event trace logger in LiteOS, which this diversity brings us one step closer to making sensor net- allows us to partially reconstruct application behavior after work programming attainable to system programmers with- execution, such as which path it took for an IF statement, out steep learning curves.

11 LiteOS TinyOS Mantis Contiki SOS

Current license GPL BSD BSD BSD Modified BSD Website www.liteos.net www.tinyos.net mantis.cs.colorado.edu www.sics.se/contiki projects.nesl.ucla.edu/public/so s-2x/doc/ Remote scriptable Yes (on the base PC, Unix No (application specific shell No (on-the-mote shell is No (on-the-mote shell is No wireless shell commands supported) such as SimpleCmd exists) supported) supported)

Remote interface Yes No No No No for networked nodes

File system Hierarchical Unix-like Single level (ELF, Matchbox) No (will be available in 1.1) Single Level No

Thread support Yes Partial (through TinyThreads) Yes Yes (also supports ProtoThreads) No Event based Yes (through callback Yes No Yes Yes programming functions)

Remote Debugging(e.g. Yes Yes (through Clairvoyant) Partial (through NodeMD) No No watch and breakpoints)

Wireless reprogramming Yes (application level) Yes (whole system image No (will be available in 1.1) Yes Yes (module level) replacement) Dynamic memory Yes Yes (in 2.0 or through No Yes Yes TinyAlloc for 1.x)

First publication/release 2007 2000 2003 2003 2005 date

Platform support MicaZ and AVR series MCU Mica, Mica2, MicaZ, Telos, Tmote, Mica2, MicaZ, Telos Tmote, ESB, AVR series MCU, certain Mica2, MicaZ, XYZ XYZ, Iris (among others) old computers

Simulator Through AVRORA TOSSIM, PowerTossim Through AVRORA Netsim, Cooja, MSPSim Source level Simulator/ Through AVRORA

Note: [1] Only features in the current version of these operating systems as of the publication of this paper (April 2008) are compared [2] Only open-source sensor network OS projects that have websites are compared [3] All OS systems can be directly debugged using JTAG or GDB. Such comparison is not included.

Figure 11. Comparison with Other Operating Systems

8 Conclusions [10] A. Eswaran, A.Rowe, and R. Rajkumar. Nano-rk: an energy-aware resource- centric rtos for sensor networks. In IEEE RTSS, 2005. In this paper, we presented a software development plat- [11] D. Gay. Design of matchbox, the simple filing system for motes. Available at http://www.tinyos.net/tinyos-1.x/doc/matchbox-design.pdf. form called LiteOS, and conducted its performance eval- [12] D. Gay, P. Levis, and D. Culler. Software design patterns for tinyos. In Pro- uation. We also presented performance results of several ceedings of the ACM LCTES, 2005. [13] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The benchmark applications. We are hopeful that the familiar nesC Language: A Holistic Approach to Networked Embedded Systems. In abstractions exported by LiteOS will make it valuable as a Proceedings of PLDI, 2000. [14] L. Gu and J. A. Stankovic. t-kernel: Providing reliable os support to wireless new research platform, and appealing to a larger category sensor networks. In ACM SenSys, November 2006. of systems programmers. [15] C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava. A dynamic oper- ating system for sensor nodes. In Proceedings of Mobisys, 2005. [16] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System Acknowledgements architecture directions for network sensors. In Proceedings of ASPLOS-IX, 2000. [17] J. Jeong and D. Culler. Incremental network programming for wireless sensors. We gratefully acknowledge the anonymous reviewers In IEEE SECON, 2004. and our shepherd, , for their insightful com- [18] P. Juang, H. Oki, Y. Wang, M. Martonosi, L. Peh, and D. Rubenstein. Energy- Efficient Computing for Wildlife Tracking: Design Tradeoffs and Early Expe- ments. We also thank Simon Han and Richard Han for their riences with ZebraNet. In Proceedings of ASPLOS-X, October 2002. comments on the OS comparison table. We thank our col- [19] O. Kasten and K. Romer.¨ Beyond event handlers: Programming wireless sen- sors with attributed state machines. In ACM IPSN, 2005. leagues and the users of LiteOS who have provided feed- [20] A. Lachenmann, P. J. Marron, and K. Rothermel. Efficient flash-based vir- back and help to make this system possible. This paper is tual memory for sensor networks. In Technical Report 2006/07, Universitat supported in part by NSF grants, CNS 05-54759, CNS 06- Stuttgart, Faculty of Computer Science, 2006. [21] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. The Design of an 15318, CNS 06-26342, and CNS 06-26825, and a fellow- Acquisitional Query Processor for Sensor Networks. In ACM SIGMOD, 2003. ship from Vodafone Foundation. [22] G. Mathur, P. Desnoyers, D. Ganesan, and P. Shenoy. Capsule: An energy- optimized object storage system for memory-constrained sensor devices. In ACM Sensys, November 2006. References [23] W. P. McCartney and N. Sridhar. Abstractions for safe concurrent programming in networked embedded systems. In ACM Sensys, 2006. [1] Arch rock corporation. http://www.archrock.com. [24] L. Nachman, R. Kling, R. Adler, J. Huang, and V. Hummel. The intel mote [2] system. http://ecos.sourceware.org/. platform: a -based sensor network for industrial monitoring. In Pro- [3] Sun spot project. http://www.sunspotworld.com/. ceedings of IPSN, 2005. [4] T. Abdelazaher et al. Envirotrack: Towards an environmental computing [25] S. Nath, J. Liu, and F. Zhao. Challenges in building a portal for sensors world- paradigm for distributed sensor networks. In IEEE ICDCS, 2004. wide. In First Workshop on World-Sensor-Web: Centric Sensory [5] S. Bhatti et al. Mantis os: An embedded multithreaded operating system for Networks and Applications (WSW), 2006. wireless micro sensor platforms. In ACM/Kluwer Mobile Networks and Appli- [26] A. Perrig, R. Szewczyk, V. Wen, D. Culler, and D. Tygar. Spins: Security cations (MONET), Special Issue on Wireless Sensor Networks, 2005. protocols for sensor networks. In Proceedings of Mobicom, 2001. [6] CrossBow. Imote2 platform. http://www.xbow.com. [27] J. Regehr, A. Reid, and K. Webb. Eliminating stack overflow by abstract inter- [7] CrossBow. Moteview software. http://www.xbow.com. pretation. In Proceedings of EMSOFT, October 2003. [8] H. Dai, M. Neufeld, and R. Han. Elf: an efficient log-structured flash file system [28] N. Reijers and K. Langendoen. Effcient code distribution in wireless sensor net- for micro sensor nodes. In ACM SenSys, 2004. works. In In Proceedings of the 2nd ACM international conference on Wireless [9] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight and flexible sensor networks and applications, 2003. operating system for tiny networked sensors. In Proceedings of Emnets-I, 2004. [29] WindRiver. Vxworks operating system. http://www.windriver.com.

12