μT-Kernel: A Low Power and Small Footprint RTOS for Networked Tiny Devices

Masato Kamio, Keiichi Nakamura, Shinsuke Kobayashi, Noboru Koshizuka and Ken Sakamura

The University of Tokyo, Japan {kamio, k1naka, kobayashi, koshizuka, ken}@sakamura-lab.org

Abstract This paper proposes μT-Kernel, a real-time operating system for networked tiny devices, which adopts a preemptive priority-based scheduling. It provides a sophisticated application programming interface to facilitate software development. In addition, to provide rich functionalities with a small-footprint, the kernel is reconfigurable with respect to the API. Moreover, μT-Kernel supports a power management which utilizes the periodicity of WSN applications. We conducted performance analyses of the memory footprint and energy consumption, and migrated sample applications to show the programmability of μT-Kernel. Our results show μT-Kernel is effective for developing WSN systems while realizing a kernel small enough to fit into a resource-constrained node. Key Words- Embedded Real-Time Operating System, Low Power, Small Footprint, Multitasking, Sensor Networks 1. Introduction

Wireless sensor networks (WSN) are promising technologies for monitoring physical or environmental phenomena, which are composed of numerous tiny sensor nodes that are spatially distributed and equipped with a wireless interface [1]. Sensor nodes self-organize into ad-hoc networks and collect sensing data cooperatively, enabling users to observe over a large region and for a long period of time. These characteristics ensure diverse areas of applications, such as habitat monitoring [2, 3], health care [4], home automation [5] and industrial machinery surveillance.

Unfortunately, WSN has not become popular in the industrial world yet. There are two main reasons; one is retargetability and the other is the difficulty of developing WSN applications. Many researchers are using a same hardware “Mote” [6, 7, 8] as a sensor network node. Of course, a common platform is very important for the research community because it provides a reference system for comparing results. However, the Mote is insufficient for developing a practical WSN system,

because there are many constraints required by the system, such as the size of hardware, power consumption, a wireless communication specification including radio frequency and baud rate, a type of sensors and actuators, environmental conditions such as temperature and humidity, and so on. The target hardware should be customized to meet such requirements. When customizing the target hardware, retargetability is an important issue. The ease of adding software for new sensors or actuators is required by sensor network application designers.

In addition, the difficulty of developing applications is also an important issue. Researchers suffer from difficulties in developing WSN applications or middleware because of resource and energy constrained nodes. Hence, the size of compiled codes including applications, middleware and an operating system must be small enough to fit into a memory constrained node and software needs to be energy effective to achieve longevity of sensor nodes. Moreover, there is a growing need for increasingly complex duties, such as data aggregation [9, 10] and encryption [11]. These techniques lead to communication overhead minimization and security improvement. Therefore it is required to develop software which can perform complex tasks on a resource-constrained node.

Many efforts have been made to overcome problems mentioned above. Hill et al. in [6] proposed TinyOS, a low-footprint component-based operating system, supporting modularity and concurrency using an event-driven approach. Although TinyOS is successful in fulfilling limited memory requirements, an event-driven approach induces complicated control flow because of a non-preemptive scheduler [12]. Hence, this results in degradation of usability. Some other operating systems, Contiki [16] and SOS [17], are also based on an event-driven approach. Both operating systems focus on dynamic loading and still face the same problem as TinyOS does. On the other hand, multithreaded kernel based operating systems [13, 14, 15, 18] emerged for coping with the problem. In [13] Bhatti et al. advocated advantage of a multithreaded model compared to an event-driven model and proposed the Mantis OS which supports a preemptive multithreaded model, implementing a subset of POSIX threads. Nano-RK [14]

2009 Sixth International Conference on Information Technology: New Generations

978-0-7695-3596-8/09 $25.00 © 2009 IEEE

DOI 10.1109/ITNG.2009.242

587

2009 Sixth International Conference on Information Technology: New Generations

978-0-7695-3596-8/09 $25.00 © 2009 IEEE

DOI 10.1109/ITNG.2009.242

587

also provides multithreaded kernel and supports real-time tasksets that have deadlines associated with their data delivery. In terms of adopting a multithreaded kernel and supporting power management both operating systems are closely related to our work. But such current WSN platforms do not provide sufficient functionalities suitable for achieving retargetability and supporting inter-task communication and real-time processing easily and effectively. These functions are useful in developing complex WSN systems.

In this paper, we propose μT-Kernel operating system, a real-time operating system for networked tiny devices, which is derived from T-Kernel [22]. μT-Kernel has four main features. First, μT-Kernel has a retargetable framework. μT-Kernel provides the framework of interrupt handling and device driver. It is easy to add new devices such as sensors and actuators, hence, designers are able to customize software for customized target hardware. Second, μT-Kernel provides a sophisticated programming interface, for facilitating software development including basic real-time kernel functions. For example, all system calls which may change a state of a task to a wait state have a time-out limit parameter in order to make it easy to write time-sensitive applications, and it provides several kinds of inter-task synchronization and communication functions, which allows these functions to be selected according to the needs. Third, a kernel is reconfigurable with respect to the API. This eliminates unused functions, variables and members of structures from compiled codes in order to provide rich functionalities with a small-footprint. Fourth, μT-Kernel supports a power management which leverages the periodicity of WSN applications. Programmers can create power-aware applications without writing energy management codes implicitly.

The rest of this paper is organized as follows. Section 2 describes μT-Kernel and its design. Section 3 analyzes the performance of μT-Kernel, followed by a discussion of the programmability. Finally, the paper is summarized and concluded in Section 4. 2. The μT-Kernel operating system 2.1. Design principles

To achieve retargetability and facilitate software development, we summarize design principles of a wireless sensor network operating system.

• Adaptability to hardware and application. One of the characteristics of WSN is application-specificity, that is, WSN works for specificity purposes by sensing and transmitting cooperatively. Many application-specific protocols have been proposed for such occasions. In the

same way, other software components and hardware will be also an application-specific in real deployment. To meet such requirements, an operating system should be customizable according to an application.

• Availability of a full range of functions. Most of operating systems for WSN limit the number of available functions in order to make kernel size small. A small set of functions leads to inefficiency in developing applications, especially when building a complex system.

• Longevity of the battery. Sensor nodes are usually powered by a battery. It is difficult to recharge or replace batteries after deployment because of the huge number of nodes. Moreover, many WSN applications require long term operation. Thus it is important to conserve energy as much as possible. Since it is difficult for user applications to control hardware correctly because of lack of system-wide information, power management is needed to be supported by an operating system.

• Usability. It is challenging to realize an operating system which runs on scarce memory. To meet this requirement some operating systems introduce special abstractions. But such abstractions sometimes induce poor usability, and result in a steep learning curve. So operating systems should fulfill requirements without degrading usability.

2.2. Multitasking operating system

There are two main abstractions for a WSN operating system; event-driven and multitasking. As described in section 1, several previous works adopted an event-driven paradigm [6, 16, 17]. Since event-driven systems have only one stack, they can achieve a low-cost task switch which does not need context saving and restoring. This characteristic is particularly suitable for extremely resource constrained systems. Because an event-driven approach does not permit preemptive task scheduling, a task must not interfere with other task processes. Hence an event-driven approach leads to complicated control flow with split-phase operations, making a steep learning curve.

On the other hand, a multitasking approach allows developers to program tasks without considering other task processes. This permits long-term tasks instead of breaking a function into several fractions, and is useful for building complex systems. A multitasking increases task switching time and memory usage for task context information compared to the event-driven approach. In cases that a targeted hardware is extremely resource constrained, for example, the one equipped with 8 KB ROM and 500 bytes RAM that TinyOS targeted at first [6], overheads of the multitasking approach cause

588588

problems. But currently popular hardware has more rich functionalities, for example the Mica2 mote has 128 KB ROM and 4 KB RAM, and the Telos mote has 48 KB ROM and 10 KB RAM. Hence such overheads do not always cause serious problems. Rather, it is important for platforms to be able to build WSN system without programming difficulties in order to deploy in the real world. Therefore, μT-Kernel adopts preemptive priority-based scheduling to support real-time processing. 2.3. Application programming interface

Most of operating systems for WSN provide the minimum set of functions which can control a sensor node with a small-sized kernel. But limited functions sometimes introduce inefficiency for developing applications because of inadequacy. To avoid this problem, on the other hand, μT-Kernel provides a full range of functions, including task management, inter-task communication and synchronization, memory management, interrupt management, time management and device management. These functions help developers utilize functions selectively according to application.

First, μT-Kernel provides an API for achieving synchronization and communication such as a mailbox which passes messages in system memory and message buffers which pass variable-size messages by copying buffers. These are used for synchronous or asynchronous communication and helpful in developing a complex system with concurrent execution of multiple tasks. Furthermore, μT-Kernel addresses problems caused by multitasking. For example, priority inversion may happen in priority-based scheduling, which causes the execution of a high priority task to be blocked until a low priority task has released a resource. This caused a troubles experienced by “Mars Pathfinder” in 1997. Mutex provided by μT-Kernel supports both a priority inheritance protocol and a priority ceiling protocol to avoid priority inversion. μT-Kernel also provides semaphores, event flags, rendezvous, memory pools and time management functions. Event flags use bit patterns indicating the existence of corresponding events for synchronization. Rendezvous allows tasks to communicate in a client server model with request and reply messages. Memory pools allocate memory and block execution of a requested task when there is no sufficient memory. Moreover, all blocking API calls can be specified with a time-out value for canceling the request. Therefore, developers selectively exploit these functions according to application.

Second, supporting device driver management and interrupt management is useful for retargeting. For example, interrupts from sensors are very important to catch an external event, but writing an interrupt handler requires pre-processing and post-processing such as

saving and restoring registers, switching stacks, counting interrupt nests and so on. In addition, these processes are mostly written in assembler language. Thus it is cumbersome to add a new interrupt handler. So it is necessary to support to prevent developers from writing such pre-processing and post-processing and enables developers to add a new interrupt handler by just writing a handler body in the C language. When adding a new interrupt handler, for example, the first thing programmers have to do is to write a handler as follows.

void accel_inthdr( UINT dintno ) { accel_clear_int(); tk_wup_tsk( tskid ); /* Wakeup a task */ }

Then the handler is registered at the corresponding interrupt vector by specifying the interrupt vector number.

T_DINT dint; dint.intatr = TA_HLNG;

/* this means a handler is written in C*/ dint.inthdr = accel_inthdr; tk_def_int( &dint, 17 );

/* ‘17’ is an interrupt vector number */

The procedure shown above needs information of interrupt vector numbers only, hence developers can reuse most of interrupt handlers for a device when using the same device on a different board. Likewise, device driver management is helpful to reuse software components. 2.4. Reconfigurable kernel

As mentioned above it is important to provide an application interface which enables developers to utilize the interface selectively depending on application requirements. But if all functions are linked as one kernel image, it would pose an oversized kernel. So it is necessary to reduce the kernel size. Hence μT-Kernel is designed to be reconfigurable with respect to the API, eliminating unnecessary functions, variables and members of structure from the kernel image. To achieve this, μT-Kernel applies two approaches: one is to eliminate unused functions and variables; the other is to purge non-referred function or variable declarations.

First, we explain elimination of unused functions and variables. When compiling kernel sources, a linker tries to link object files together. But it typically links the whole object file to a single kernel image even if the linker finds one referred symbol in an object file. Consequently, an object file comprised of several functions and variables leads to generate a kernel image which includes unnecessary codes to run. To avoid this, source files of μT-Kernel is written to be dividable. First, we write relevant functions and variables in the same

589589

source file as programmers often do. Then, special comments are put in the front and back of each function or variable. In the case of semaphore.c which contains definitions of functions and variables associated with semaphore, special macros beginning with USE_FUNC_ are put as the following pseudo source code.

#ifdef USE_FUNC_SEMCB_TABLE EXPORT SEMCB knl_semcb_table[]; EXPORT QUEUE knl_free_semcb; #endif /* USE_FUNC_SEMCB_TABLE */

#ifdef USE_FUNC_SEMAPHORE_INITIALIZE ID knl_semaphore_initialize( void ) { ... } #endif /* USE_FUNC_SEMAPHORE_INITIALIZE */

Next, source files are passed to a script that breaks files into smaller files per function or variable according to special comments before the compilation as depicted in figure 1. Finally many small object files are created, which correspond to each function and variable. A kernel image composed of these small object files include only binary codes to execute an application. In the above example, supporting information for debugging does not need for a program to run, thus object files which contain debugging functions are not linked. As a result, a kernel image without unnecessary code is obtained.

Next, we present how to purge non-referred functions or variable declarations. Although the method described above prevents from linking unnecessary functions and variables in many cases, it does not work perfectly. For example, an operating system initializes control blocks for unnecessary kernel objects, unless there is information of the number of kernel objects used in applications. Due to this behavior, functions and variables which are not

referred from user programs can be linked. In μT-Kernel the maximum number of each kernel object is defined statically in a configuration header file. These values are used to make a decision of which kernel objects are needed. For example, if the maximum number of mutex is set to zero, then all declarations of functions, variables and structure members related to mutex can be purged from kernel sources. In addition, this eliminates program code related to unused objects such as object initialization code. This is implemented by using the C preprocessor.

In this way, μT-Kernel provides rich functionalities while fitting within memory-constrained tiny devices. Section 3.2 discusses effectiveness of a reconfigurable kernel. 2.5. Power management

Power management is inevitable to accomplish long-term monitoring. As mentioned in [19], there are various techniques to reduce energy consumption from circuit design to application-level power management. μT-Kernel adopts a cross-layer approach exploiting the periodicity of WSN application.

Periodicity is one of the main characteristics of WSN applications, that is, nodes are activated and inactivated repeatedly in a certain cycle. For example, many proposed media access control protocols including contention-based [20, 21] as well as TDMA-based are periodic to realize low-power wireless communications. This makes a great impact on total energy consumption, because radio dissipates energy more than other hardware components. However, it is difficult to determine such cycles for application programmers because they have to know the cycles of all applications and middleware expected to run concurrently. On the other hand, operating system can know the numbers of tasks in the runnable state and when the next task should be scheduled. Therefore, μT-Kernel incorporates power management system into the kernel.

The procedure of power management system is as follows. First, presence of any runnable tasks is determined just by checking a ready queue in which current runnable tasks are sorted in the order of priority. In the case of figure 2(a) task A, B and C are in the ready queue and the task A is running. Next, if there is no runnable task, the time when the earliest task should be woken up by the task scheduler can be acquired from a timer event queue in which waiting tasks are sorted in the order of expiration time. μT-Kernel then sets the timer and changes the state of the node into sleep mode. In the case of figure 2(b) the timer is set to be the expiration time of the task D. Finally, the node is woken up when the timer is expired, and the scheduled task runs. This procedure is executed without special codes in the application sources. So there is no need of any

Figure 1. Procedure of eliminating unused functions and variables

590590

modification for user programs. Thus, supporting power management by operating system, our approach reduces burden of programming energy-aware applications. 3. Evaluation 3.1. Implementation

We have implemented μT-Kernel on an active RFID tag developed by the Yokosuka Telecom Research Park Ubiquitous Networking Laboratory illustrated in figure 3. It operates on the Renesas H8S/2212 low power 16-bit microcontroller which runs at 6.144 MHz with an internal 32-bit architecture consisting of 128 KB of program memory and 12 KB of data memory, and utilizes the Chipcon CC1020 radio interface for wireless communication. It also includes acceleration, illuminance, humidity and temperature sensors. It is noteworthy that it has an external real-time clock (RTC) which is used for waking up CPU from a sleep mode by using interrupts. This reduces energy consumption significantly as described in section 3.3.

In the following evaluation, we used several simple applications from TinyOS source code tree as benchmark programs. 3.2. Memory usage

We examined memory usage under three different configurations: normal, light and heavy. In the normal configuration the number of kernel objects is set to the exact number each application requires, and unused functions, variables and members of structure are eliminated from the compiled kernel image as explained

in section 2.4. In addition to the setting of the normal configuration, the light configuration applied further optimization such as decreasing the number of available priorities, suppressing kernel messages, and disabling dynamic memory allocation and interrupt management. Conversely, the heavy configuration is not applied unused code elimination by splitting source files into function-by-function files. Note that the heavy configuration does not include all functions μT-Kernel provides, since the linker does not link object files which are never referenced, for example a kernel image of the Blink application does not contain functions such as inter-task communication and synchronization, memory management and interrupt management. In this evaluation, we used the Blink application which turns on and off LEDs periodically, and the GlowLeds application which brighten and darken LEDs gradually. Both applications are migrated from the TinyOS source code tree.

The ROM sizes of the Blink application in heavy, normal and light configurations are about 14.7 KB, 9.1 KB, and 3.9 KB respectively as shown in table 1. In this result, the sizes of stack allocated for each task are excluded. Comparison between normal and heavy shows a difference between the sizes of kernel images built with or without elimination of unused code. For both applications, about 38% of ROM usage in the heavy configuration is reduced in the normal configuration. This means that it is effective to link object files which only contain each function or variable instead of object files which contain several relevant functions and variables. In addition, the light configuration achieved a much smaller kernel just by setting macros for each optimization in configuration header files.

Compared with the normal configuration of Blink and GlowLeds, the ROM usage of GlowLeds is 2,496 bytes larger than that of Blink. This overhead results from functions each application used. Blink only wakes up a task periodically and turns on and off LEDs. On the other

Figure 3. Block diagram of an active RFID tag

Figure 2. A ready queue and waiting queues

(a) Task A, B and C are runnable, and task D is waiting.

(b) There is no runnable task.

591591

hand, GlowLeds brightens and darkens by pulse-width modulation (PWM) using cyclic handlers which generate timer interrupts periodically and comprises of two tasks. The increase of ROM usage consumed by the application and the kernel is 712 bytes and 1,443 byte respectively. Especially, 672 bytes of ROM used by the kernel is corresponding to cyclic handlers. The remaining overheads are due to 32-bits integer library which is needed for cyclic handlers. Thus the kernel is reconfigured according to application requirements.

Although unused code elimination works well, even the light configuration consumes more memory compared with other multitasking operating systems. Particularly, task control blocks dominate the RAM usage except for temporal stack, as shown in table 2 which lists all statically allocated variables used by Blink in the light configuration. On the other hand, the size of a task control block of Mantis and Nano-RK consume 10 bytes and 50 bytes respectively. First, this difference arises from the size of pointers. If the size of pointer type in H8S/2212 were not 32 bits but 16 bits, the size of a task control block would be 50 bytes. This is the same as that of Nano-RK. Second, functions provided by μT-Kernel and Mantis are different. The Mantis task control block contains minimal information such as a stack pointer, stack size and priority. In addition to this information, the μT-Kernel task control block maintains variables for wait information, timer event and so on. This additional information is, for example, used for realizing time-out functions for all blocking API calls which allow developers to specify time for canceling the wait. Moreover, such a cost is acceptable for nodes with 12 KB RAM. Thus, μT-Kernel can provide a full range of functions while realizing a kernel small enough to fit within a sensor node.

3.3. Energy consumption

We evaluated the effects of the μT-Kernel power management by calculating the expected battery lifetime theoretically. The Blink application is used for the following evaluation. In the evaluation we compared the following three types of sleep modes.

• Subsleep mode: In this mode CPU and peripheral modules except for watch dog timer (WDT) and RTC are stopped.

• Watch mode: This mode stops CPU and peripheral

modules other than RTC. Oscillator is still enabled. • Standby mode: In this mode peripherals are

stopped as in watch mode, furthermore, oscillator is disabled. Hence this mode reduces power dissipation significantly.

Current consumption of Subsleep mode, Watch mode and Standby mode are 35 μA, 5 μA and 1 μA respectively. Although these low-power modes are specific for H8S/2212, other microcontrollers such as Atmega128 and MSP430 which are used for wireless sensor network platforms also provide several operating modes.

We calculated the expected battery lifetime t as

sleepactive IIQ

t)1( ρρ −+

= ,

where Q is the battery capacity, ρ is a duty cycle, Iactive is the current consumption while in an active mode and Isleep is the current consumption while in a sleep mode. For the Blink application, Iactive is dominated by current consumption of CPU core and LED, and Isleep is a summation of all the current consumption in sleep modes depicted in table 3. Duty cycle ρ depends on application requirements.

From the result shown in figure 4 there is a little difference among three modes when duty cycle is high. But the current consumption of sleep mode remarkably affects the battery lifetime below 1 % duty cycle. This characteristic is suitable for WSN, because duty cycles of typical WSN applications are ranging from 0.1% to 2% [23]. Moreover this result shows that the little difference of energy consumption in sleep mode affects total battery

Table 1. Memory usage (bytes) Configuration Application

name

heavy normal light

Blink ROM RAM

14,732 1,588

9,1001,588

3,900304

GlowLeds ROM RAM

19,016 1,748

11,5961,736

6,076460

Table 2. RAM usage breakdown of Blink in light configuration Size Variable name Remarks

12 knl_wspec_dly Wait specification for delaying task

4 knl_current_time Current time 4 knl_real_time_ofs Offset time 8 knl_timer_queue Queue for timer event

128 knl_tmp_stack Temporal stack used before creating tasks

4 knl_dispatch_disabled Task dispatch disable state 4 knl_ctxtsk Task in execution

4 knl_schedtsk Task which should be executed

24 knl_ready_queue Ready queue 84 knl_tcb_table Task control block

8 knl_free_tcb Free queue for released task control block

4 knl_taskindp Task-independent mode 4 knl_int_nest Interrupt nest count

4 knl_lowpow_discnt The number of times for disabling power-saving mode switch

8 DDR_Buffer Buffer for saving data direction registers

592592

life as well. Therefore it is effective to minimize energy consumption in sleep mode as possible even if it needs additional IC like an external RTC in the active RFID tag we used in the evaluation

3.4. Benchmark test

We have implemented a full range of functions in μT-Kernel so that users can selectively utilize functions according to application requirements. To show usability of them, we have ported 23 applications from the TinyOS source code tree (version 1.1.x). These applications are carefully written so that migrated programs implement same functions that original programs provide in order to make a fair comparison. Using these applications, we have compared lines of source code.

We counted the number of lines as follows. First, we chose files for comparison, for example, to compare the lines of source code of the CntToLeds application we selected Counter.nc, IntToLeds.nc and IntToLedsM.nc as well as CntToLeds.nc from TinyOS sources because μT-Kernel provides functions for turning on or off LEDs but does not provide functions like IntToLeds. Then we eliminated blank lines and comments from all files. After that, we reformatted source code to follow the same coding style, and counted the number of lines of each file.

The numbers of lines of 13 applications in μT-Kernel are less than that of TinyOS as shown in figure 5. But some of migrated application codes are longer than that of original TinyOS source codes. This is because there are complicated functions divided into multiple tasks. For example, GenericBase, which serves as a network bridge between a PC and a sensor network, sends out packets received from the PC via UART on the radio, and also sends out packets received from the radio on the UART. In the TinyOS source code, each UART receive function and radio receive function are treated as a unified receive function. In contrast, we created two tasks and let them manage each receive function. Although dividing a function and creating tasks increases the total length of

source code, it makes control flow easy to understand and improves extensibility.

3.5. Discussion

We can summarize the results of evaluation as follows. First, compared with TinyOS as a representative of event-driven model operating systems, the numbers of lines of 13 applications are less than that of TinyOS, and the numbers of lines of 10 applications are more than that of TinyOS. This is not a pessimistic result, because increased source code volume results from dividing complex functions caused by non-preemptive scheduling into a few tasks to make control flow simple. μT-Kernel improves readability and helps developers create complex applications at the cost of code for adding tasks. Second, compared with other multitasking operating systems, μT-Kernel has plentiful functions so that developers can selectively utilize API calls depending on application requirements. The kernel size is larger than that of Mantis and Nano-RK, however, the kernel image still fits within memory constrained sensor nodes due to the reconfigurable kernel as showed in table 1. Therefore, μT-Kernel can create applications with simple code compared with event-driven operating system and provide rich functions while realizing a small footprint

Figure 5. Comparison of the number of lines

Figure 4. Expected lifetime of Blink with 420 mAh battery

Table 3. Energy statistics of the active tag Component Active Standby

CPU CPU Core 14.6 mA 1 μARadio RX 19.9 mA ---TX (output power 1mW) 16.2 mA ---Oscillator Core 7.5 mA 0.2 μASensors Humidity/Temperature 0.55 mA 0.3 μAAccelerometer 0.36 mA Max. 1 μAIlluminance 0.62 mA 0.17 μAMiscellaneous LED 1.5 mA ---External Real Time Clock 1.5 μA 1.5 μA

593593

kernel. 4. Conclusion

In this paper, we have described μT-Kernel, a small footprint operating system for networked tiny devices, integrated with power management system for energy conservation. In designing operating system, we have argued that it is important to be retargetable for adaptation to application-specific customized hardware and software and to selectively utilize functions from a variety of functions according to application. Therefore, μT-Kernel provides plentiful API calls to meet versatile application requirements. Due to the reconfigurable kernel, overheads of providing such plentiful API calls do not incur an oversized kernel as showed in our evaluation results. In addition, power management system utilizing the periodicity of WSN applications has been found to be effective for WSN applications. Acknowledgements .

This research was partly supported by the 21st Century COE Program ‘Next Generation Ubiquitous Information Society Infrastructure.’ References [1] Akyildiz, I. F., Su, W., Sankarasubramaniam, Y. and Cayirci, E. “Wireless Sensor Networks: a Survey,” Computer Networks, 38(4), 2002, 393-422 [2] Szewczyk, R., Mainwaring, M., Polastre, J., Anderson, J. and Culler, D. “An Analysis of a Large Scale Habitat Monitoring Application,” In Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, ACM, 2004, pp. 214-226. [3] Zhang, P, Sadler, C. M., Lyon, S. A. and Martonosi, M. “Hardware Design Experiences in Zebranet,” In Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, ACM, 2004, pp. 227-238 [4] Lorincz, K., Malan, D. J., Fulford-Jones, T. R. F., Nawoj, A., Clavel, A., Shnayder, V., Mainland, G., Welsh, M. and Moulton S. “Sensor Networks for Emergency Response: Challenges and Opportunities,” Pervasive Computing, 3(4), IEEE, 2004, 16-23 [5] Srivastava, Richard Muntz, R. and Potkonjak, M. “Smart Kindergarten: Sensor-based Wireless Networks for Smart Developmental Problem-Solving Environments,” In Proceedings of the 7th Annual International Conference on Mobile Computing and Networking, ACM, 2001, pp. 132-138 [6] Hill, J., Szewczyk, R. Woo, A., Hollar, S., Culler, D. and Pister, K. “System Architecture Directions for Networked Sensors,” ACM SIGPLAN Notices, 35(11), 2000, pp. 93-104 [7] Hill, J. L. and Culler, D. E. “Mica: a Wireless Platform for Deeply Embedded Networks,” IEEE Micro, 22(6), 2002, 12-24 [8] Polastre, J., Szewczyk, R. and Culler, D. “Telos: Enabling Ultra-Low Power Wireless Research,” In Proceedings of the 4th International Symposium on Information Processing in Sensor

Networks, 2005 [9] Chitnis, L., Dobra, A. and Ranka, S. “Aggregation Methods for Large-Scale Sensor Networks,” ACM Transaction on Sensor Networks, 4(2), 2008, 1-36 [10] Nakamura, E. F., Loureiro, A. A. F. and Frery, A. C. “Information Fusion for Wireless Sensor Networks: Methods, Models, and Classifications,” ACM Computing Surveys, 39(3), 2007, Article 9/1-55 [11] Sabbah, E., Majeed, A., Kang, K.-D., Liu, K. and Abu-Ghazaleh, N. “An Application-Driven Perspective on Wireless Sensor Network Security,” In Proceedings of the 2nd ACM International Workshop on Quality of Service & Security for Wireless and Mobile Networks, ACM, 2006, pp. 1-8 [12] Levis, P., Madden, S., Gay, D., Polastre, J., Szewczyk, R., Woo, A., Brewer, E. and Culler, D. “The Emergence of Networking Abstractions and Techniques in Tinyos,” In Proceedings of the 1st Conference on Symposium on Networked Systems Design and Implementation, 2004 [13] Bhatti, S., Carlson, J., Dai, H., Deng, J., Rose, J., Sheth, A., Shucker, B., Gruenwald, C., Torgerson, A., and Han, R. “MANTIS OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms,” Mobile Networks and Applications, 10(4), 2005, 563-579 [14] Eswaran, A., Rowe, A. and Rajkumar, R. “Nano-RK: An Energy-Aware Resource-Centric RTOS for Sensor Networks,” In Proceedings of the 26th IEEE International Real-Time Systems Symposium, 2005, pp. 256-265 [15] Cao, Q., Abdelzaher, T., Stankovic, J. and He, T. “The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks,” In Proceedings of the 2008 International Conference on Information Processing in Sensor Networks, 2008, pp. 233-244 [16] Dunkels, A., Gronvall, B. and Voigt, T. “Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors,” In Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks, 2004, pp. 455-462 [17] Han, C.-C., Kumar, R., Shea, R., Eddie, K. and Srivastava, M. “A Dynamic Operating System for Sensor Nodes,” In Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services, 2005, pp. 163-176 [18] Gu, L. and Stankovic, J. A. “t-kernel: Providing Reliable OS Support to Wireless Sensor Networks,” In Proceedings of the 4th International Conference on Embedded Networked Sensor Systems, 2006, pp. 1-14 [19] Venkatachalam, V. and Franz, M. “Power Reduction Techniques for Microprocessor Systems,” ACM Computing Surveys, 37(3), 2005, 195-237 [20] Wei Ye, Heidemann, J. and Estrin, D. “Medium Access Control with Coordinated Adaptive Sleeping for Wireless Sensor Networks,” IEEE/ACM Transactions on Networking, 12(3), 2004, 493-506 [21] Polastre, J., Hill, J. and Culler, D. “Versatile Low Power Media Access for Wireless Sensor Networks,” In Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, 2004, pp. 95-10 [22] Sakamura, K. and Koshizuka, N. “T-Engine: The Open Real-Time Embedded-Systems Platform,” IEEE Micro, 22(6), 2002, 48-57 [23] Hill, J., Horton, M., Kling, R. and Krishnamurthy, L. “The Platforms Enabling Wireless Sensor Networks,” Communications of the ACM, 47(6), 2004, pp. 41-46

594594