ICACSIS 2011 ISBN: 978-979-1421-11-9 A Comparative Study on Operating System for Wireless Sensor Networks Thang Vu Chien, Hung Nguyen Chan, and Thanh Nguyen Huu Thai Nguyen University of Information and Communication Technology Quyet Thang Commune, Thai Nguyen City, Vietnam E-mail: [email protected], [email protected], [email protected] Abstract—Wireless Sensor Networks (WSNs) them work correctly and effectively without a conflict have been the subject of intensive research over the in support of the specific applications for which they last years. WSNs consist of a large number of are designed. Each sensor node needs an OS that can sensor nodes, and are used for various applications control the hardware, provide hardware abstraction to such as building monitoring, environment control, application software, and fill in the gap between wild-life habitat monitoring, forest fire detection, applications and the underlying hardware. industry automation, military, security, and health- The basic functionalities of an OS include resource care. Operating system (OS) support for WSNs abstractions for various hardware devices, interrupt plays a central role in building scalable distributed management and task scheduling, concurrency control, applications that are efficient and reliable. Over and networking support. Based on the services the years, we have seen a variety of operating provided by the OS, application programmers can systems (OSes) emerging in the sensor network conveniently use high-level application programming community to facilitate developing WSN interfaces (APIs) independent of the underlying applications. In this paper, we present OS for WSNs. We begin by presenting the major issues for hardware. the design of OS for WSNs. Then, we examine some The traditional OS is system software that operates existing OSes for WSNs, including TinyOS, between application software and hardware and is Contiki, and LiteOS. Finally, we present a often designed for workstations and PCs with plenty of comparison of these OSes by examining some resources. This is usually not the case with sensor important OS features. We believe that our work nodes in WSNs. There are also embedded OSes such will help both OS developers and OS users. With as VxWorks [1] and WinCE [2], none of which is OS developers, they will know what has worked in specially designed for data-centric WSNs with previous OSes and what has not. With OS users, constrained resources. Sensors usually have a slow they know the features of existing sensor network processor and small memory, different from most OSes, so they can select a sensor network OS that is current systems. These parameters should be kept in the most appropriate for their application. mind in the process of OS design for WSN nodes. In this paper, we identify several major issues for the design of OS for WSNs. By examining some I. INTRODUCTION existing OSes for WSNs, we hope that our work may WSN is generally composed of a centralized allow research community to know the strengths and A station (sink) and tens, hundreds, or perhaps weaknesses of a number of different OSes. thousands of tiny sensor nodes. With the integration of The rest of this paper is organized as follows. information sensing, computation, and wireless Section II presents the major issues for the design of communication, these devices can sense the physical sensor network OS. Section III examines some phenomenon, (pre-)process the raw information, and existing OSes for WSNs, including TinyOS, Contiki, share the processed information with their neighboring and LiteOS. Section IV presents a comparison of these nodes. OSes. Finally, we conclude this paper in Section V. Typical sensor nodes are equipped with a sensor, a microprocessor or microcontroller, a memory, a radio II. OPERATING SYSTEM DESIGN ISSUES transceiver, and a battery. Therefore, these hardware Traditional OSes are system software, including components should be organized in a way that makes programs that manage computing resources, control peripheral devices, and provide software abstraction to 73 ICACSIS 2011 ISBN: 978-979-1421-11-9 the application software. Traditional OS functions are E. Application Program Interface therefore to manage processes, memory, CPU time, Sensor nodes need to provide modular and general file system, and devices. This is often implemented in APIs for their applications. The APIs should enable a modular and layered fashion, including a lower layer applications access the underlying hardware. This may of kernels and a higher layer of system libraries. allow access and control of hardware directly, to Traditional OSes are not suitable for WSNs because optimize system performance. WSNs have constrained resources and diverse data- centric applications, in addition to a variable topology. F. Code Upgrading and Reprogramming WSNs need a new type of operating system, Since the behavior of sensor nodes and their considering their special characteristics. There are algorithms may need to be adjusted either for their several issues to consider when designing sensor functionality or for energy conservation, the operating network OS. system should be able to reprogram and upgrade. A. Process Management and Scheduling G. Small Footprint The traditional OS provides process protection by The limited memory of only a few kilobytes on a allocating a separate memory space (stack) for each sensor node necessitates the OS to be designed with a process. Each process maintains data and information very small footprint. It is a fundamental characteristic in its own space. But this approach usually causes of a sensor network OS and is the primary reason why multiple data copying and context switching between so many sophisticated embedded OSes can not be processes. This is obviously not energy efficient for easily ported to sensor nodes. WSNs. Sensor network OSes should provide efficient H. Real-Time Guarantee resource management mechanisms in order to allocate As most sensor network applications such as microprocessor time and limited memory. The CPU surveillance tend to be time-sensitive in nature where time and limited memory must be scheduled and packets must be relayed and forwarded on a timely allocated for processes carefully to guarantee fairness basis, real-time guarantee is a necessary requirement (or priority if required). for such applications. B. Memory Management I. Reliability Memory is often allocated exclusively for each In most applications, sensor networks are deployed process/task in traditional OSes, which is helpful for once and intended to operate unattended for a long protection and security of the tasks. Since sensor nodes period of time. OS reliability is of great importance to have small memory, another approach, sharing, can facilitate developing complex WSN software, ensuring reduce memory requirements. the correct functioning of WSN systems. C. Kernel Model The event-driven and finite state machine (FSM) III. EXISTING OPERATING SYSTEMS FOR WIRELESS models have been used to design microkernels for SENSOR NETWORKS WSNs. The event-driven model may serve WSNs well Over the years, we have seen various OSes because they look like event-driven systems. An event emerging in the sensor network community [3]. The may comprise receiving a packet, transmitting a most prestigious works include TinyOS [4], Contiki packet, detection of an event of interest, alarms about [5], SOS [6], Mantis OS [7], Nano-RK [8], RETOS energy depletion of a sensor node, and so on. The [9] and LiteOS [10]. In this paper, we present only FSM-based model is convenient to realize TinyOS, Contiki (many interested OS users), and concurrency, reactivity, and synchronization. LiteOS (the newest sensor network OS). D. Energy Efficiency A. TinyOS Sensor nodes provide very limited battery lifetime. TinyOS [4], developed in UC Berkeley, is perhaps On the other hand, guaranteeing sensor networks to the earliest sensor network OS in the literature [11]. operate for 3 to 5 years is a very desirable objective. The design of TinyOS allows application software to Sensor network OS should support power access hardware directly when required. TinyOS is a management, which helps to extend the system lifetime tiny microthreaded OS that attempts to address two and improve its performance. For example, the issues: how to guarantee concurrent data flows among operating system may schedule the process to sleep hardware devices, and how to provide modularized when the system is idle, and to wake up with the components with little processing and storage advent of an incoming event or an interrupt from the overhead. These issues are important since TinyOS is hardware. required to manage hardware capabilities and resources effectively while supporting concurrent operation in an efficient manner. TinyOS uses an 74 ICACSIS 2011 ISBN: 978-979-1421-11-9 event-based model to support high levels of concurrent arbitrary computation in an event-based model. The application in a very small amount of memory. design of components makes it easy to connect various Compared with a stack-based threaded approach, components in the form of function calls. In order to which would require that stack space be reserved for provide a better support for the component each execution context, and because the switching rate architecture and execution model of TinyOS, the nesC of execution context is slower than in an event-based language [12] was designed for programming based on approach, TinyOS achieves higher throughput. It can TinyOS. TinyOS has a component-based programming rapidly create tasks associated with an event, with no model, codified by the nesC language. blocking or polling. When CPU is idle, the process is This WNS operating system defines three types of maintained in a sleep state to conserve energy. components: hardware abstractions, synthetic Fig. 1 illustrates the basic architecture of TinyOS. hardware, and high-level software components. TinyOS includes a tiny scheduler and a set of Hardware abstraction components are the lowest-level components. components. They are actually the mapping of physical hardware such as Input/Output (I/O) devices, a radio transceiver, and sensors.