Study On Operating Systems In Sensor Networks Computer Science Essay


Operating system for the Wireless Sensor networks is considered to be less complex than the general purpose operating systems. The wireless sensor networks OS resembles the embedded systems. The main reason behind this is that they are developed with a particular application and need for low cost and low power leads to the use of low-power microcontrollers .Different operating systems used in sensor networks includes TinyOS, LiteOS, Contiki, SOS, Pushpin, MantisOS .TinyOS is the first operating system designed for wireless sensor networks. It is based on event driven programming model. LiteOS is a newly developed OS ,which provides UNIX like abstractions and support for c programming language. Contiki uses a simpler programming style in C ,it provides advances such as 6LoWPAN and proto-threads.SOS is a dynamic OS that takes a dynamic point on the design spectrum. Mantis provides a multithreaded cross-platform embedded OS for wireless sensor networks.Pushpin OS supports mobile computational processes. This paper deals with the comparison on various operating systems used in wireless sensor networks.

Keywords: Wireless sensor networks, Embedded system, Multithreading, Cross-platform, Event-driven.

Lady using a tablet
Lady using a tablet


Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

I. Introduction

This paper compares various operating systems used in wireless sensor networks. Different operating systems used are TinyOS, MantisOS, Contiki, SOS, LiteOS, Pushpin etc. TinyOS is a flexible, application specific operating system for sensor networks. TinyOS is the core component of intelligence systems.It is the first OS designed for wireless networks. It is built from a set of reusable components assembled into an application specific system .TinyOS is based on an event-driven programming model instead of multithreading. TinyOS programs are composed of event handlers and tasks with run to completion semantics .When an external event occurs, such as when an incoming data packet or a sensor reading, IT signals the appropriate event handler to handle the event occurred. It is a programming framework for embedded systems and set of components that enable building an application-specific OS into each application. TinyOS is implemented in NesC language[1] .

Mantis provides a new multithreaded cross-platform for wireless sensor networks. Mantis is a lightweight and energy efficient multithreaded OS.It is designed to support cross-platform support across PC's, PDAs , as well as diverse micro sensor hardware platforms. Mantis is implemented using C programming language.

Contiki is a lightweight OS which supports dynamic loading and replacement of individual programs and services.IT is built around an event-driven kernel but it provides preemptive multithreading which is applied to individual processes as an application library that runs on the top of the event-driven kernel. The kernel is event-driven but it also supports preemptive multithreading on a per-process basis. Contiki is implemented in the C language. It is designed for memory constrained systems.

SOS is developed as a new operating system for mote-class sensor nodes[2] .It consists of dynamically loaded modules and a common kernel, which implements messaging, dynamic memory, and module loading and unloading , among other services.Like TinyOS SOS has no memory protection .It uses dynamic memory in kernel and in application modules. It provides significant energy savings over TinyOS.

LiteOS is a multi-threaded operating system that provides unix-like abstractions for wireless sensor networks.Various features of LiteOS includes (i) hierarchical file system and a wireless shell interface for user interaction using UNIX-like commands(ii)kernel support for dynamic loading and execution of multithreaded applications(iii)online debugging ,dynamic memory, and file system assisted communication stacks. Updation of software is done through a separation between the kernel and user applications, bridged through system calls[6].


TinyOS: It is based on component based programming model. It is a graph of components, each component represents independent computational entity called interfaces. There are three computational abstractions for the components which includes: commands, events, and tasks. Commands and tasks are used for inter-component communication, and tasks are used to express intra-component concurrency. Wiring specifications are used by each application for connecting components. It defines the set of components that can be used by an application. This model is referred to as component model. The component has two classes of interfaces: Provides and Uses. These interfaces defines how the component directly interacts with other components. Interfaces defines the services and it is specified by an interface type. Figure shows the TimerM component, part of TinyOStimer service, which provides the StdControl and Timer interfaces and uses a clock interface.

Lady using a tablet
Lady using a tablet


Writing Services

Lady Using Tablet

Always on Time

Marked to Standard

Order Now

Execution Model: Execution model consists of run-to-completion tasks that represents ongoing computation, and interrupt handlers. Program submits a task to the scheduler for execution with post operator. Standard TinyOS uses FIFO policy. Active Messages- TinyOS communications are based on Active messages, which are small packets associated with a 1-byte handler ID[1].

StdControl Timer



Fig1. Graphical Representation of TimerM component

Mantis OS: Mantis OS architecture is a classical layered multithreaded design.API separates the application threads from the underlying OS. It enables cross-platform support. MOS consists of a lightweight and energy-efficient scheduler, user-level network stack and device drivers.




Command server

Network stack


Kernel/scheduler COMM DEV


Fig.2 MANTIS OS architecture

API: Mantis has a set of System APIs that supports I/O and System interaction.

APIs can be categorized into:


On board sensors

Visual Feedback


Kernel and Scheduler: MOS kernel is similar to UNIX -style schedulers. They provides various services which includes subset of POSIX threads, scheduling method used is priority based thread scheduling using round robin semantics. They also supports binary semaphores and counting semaphores. Global data structure used in MOS kernel is a thread table having only one entry per thread. Thread table entry is 10 bytes and it contains a current stack pointer, stack boundary in formation, pointer to thread's starting function, thread's priority, and next thread pointer for use in linked list. Kernel also maintains ready-list and tail pointers for each priority level. Semaphores used in MOS are 5 bytes[3].

Network stack and Comm layer: Network stack is designed for the efficient use of limited memory, flexibility and convenience. The stack is implemented as one or more user-level threads. Stack also supports routing, transport layer and application layer. MAC protocol is supported by the communication layer "comm." Comm layer provides a unified interface for communication device drivers. It also manages packet buffering and synchronization functions.

Device drivers: Logical/physical partitioning is done through device drivers.A single static table is used to store function pointers for the implementation of devices . Devices are specified by their index into the table .

Contiki: Contiki operating system consists of kernel, libraries, program loader, and a set of processes. System is partitioned into two parts: the core and the loaded programs. Core consists of contiki kernel and the program loader consists of commonly used parts of the language .It also supports libraries and a communication stack with device drivers for communication hardware.Kernel consists of a lightweight event scheduler that dispatches events to running processes and periodically calls processes polling handlers. Kernel supports two kinds of events :asynchronous and synchronous events. Asynchronous events are similar to deferred procedure call .Synchronous events are similar to asynchronous events but they immediately causes the target process to be scheduled. Contiki kernel also supports polling mechanism. In contrast to Mantis OS contiki uses an event based scheduler without preemption thereby avoiding allocation of multiple stacks and locking mechanism.


Loaded program

Communication service

Language run-time

Program loader


Loaded program

Communication service


Fig 3. Partitioning into code and loaded programs

SOS: SOS provides basic hardware abstractions in a core kernel. Like TinyOS, SOS is also event driven and uses the component model, but SOS can be installed and modified even after the deployment of the system.SOS reduced the overhead of context switching faced by MANTIS by event driven architecture. Features of SOS includes dynamically linked modules, flexible priority scheduling, and dynamic memory subsystem.

Modules in SOS are independent binaries that implements a specific task or function similar to TinyOS. Message handling functions are handled and implemented using a module specific handler function. Module interaction is implemented via messages, as direct calls to functions registered by a module and system calls into the SOS kernel. SOS uses cooperative scheduling to share processor between multiple lines of execution by queuing messages.SOS uses a priority queue for scheduling.

LiteOS: LiteOS is partitioned into three subsystems : LiteShell, LiteFS, and the kernel.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

LiteOS interacts with the sensor nodes using LiteShell subsystem only when the user is present.

Kernel design: TinyOS and SOS are based on events, Mantis is based on threads and contiki supports both events and threads.

The kernel of LiteOS is based on threads, but it also allows applications to handle events using callback functions. Priority-based scheduling and round-robin scheduling are implemented in kernel[6].


Different hardware and software are used for the implementation of each operating system in sensor networks .This section deals with the implementation overview and programming model associated with each operating system.

Implementation of TinyOS

Wide range of hardware platforms are used by TinyOs, different processors include the Atmel AT90L-series, Atmel ATmega-series, and Texas Instruments MSP-series processors. It supports a development environment that incorporates visualization, debugging, and support tools and simulation environment.Desktops , laptops etc. can serve as proxies between sensor networks and wired networks.They also allows integration with server side tools implemented in java, C, or MATLAB,it provides support to interfaces to database engines such as PostgreSQL. NesC provides a tool that generates code to marshal between Active Message packet formats and Java classes. A high-fedility mode simulator called TOSSIM is supported by TinyOS that compiles directly from TinyOS NesC code, scaling to thousands of simulated nodes. It also provides JTAG support integrated with gdb for debugging applications.

Implementation of Mantis OS

Mantis hardware is based on Berkeley MICA and MICA2 Mote architecture[3].It supports low power Atmel Atmega128(L) microcontroller, analog sensor and digital ports, low power chip-con CC1000 multichannel RF radio, EEPROM, power ADC sensor, and serial ports on a quad-layer PCB. It also includes several interfaces for advanced research and allows the users to extend its capability. It also support a standard sized JTAG DIP interface for expert uses that need to burn the bootloader into the Atmel's flash.

The programming model for Mantis OS is based on the standard programming language C. This enables Mantis to support Cross-platform environment and code reuse.

Code size of the kernel, scheduler, and the network stack occupies less than 500 bytes of RAM and about 14 KB of flash. This enables sufficient space for multiple application threads to execute in the ATMega128's 4 KB of RAM, as well as sufficient storage in the ATMega128's 128 KB of flash storage.

Dynamic Reprogramming is also supported by Mantis OS.It is implemented as a system call library, which is built into MOS kernel. Another method used for dynamic reprogramming are virtual machines . Special stack based instruction set is used for reprogramming sensor nodes thereby reducing the amount of data transmitted over the network.

Implementation of Contiki

In contiki, a library which is on the top of the kernel is used for implementing preemptive multithreading . Library is divided into two parts: a platform independent part that forms the interface to the kernel, and a platform specific part implementing the stack switching and preemption primitives. In contiki each thread requires a separate stack. Library provides the stack management functions.

Different multithreading library API are:


Yield from the running thread

mt_post(id, event, dataptr);

Post an event from the running thread

mt_wait(event, dataptr);

Wait for an event to be posted to the running thread


Exit the thread running

Processors supporting Contiki includes the Texas Instruments MSP430 and Atmel AVR[5].

The code size of contiki is larger than that of TinyOS, but smaller than Mantis OS. Contiki kernel is larger than TinyOS. TinyOs kernel provides FIFO event queue scheduler, the Contiki kernel supports both FIFO events and poll handlers with priorities.

D. Implementation of SOS

Programming language used in SOS is C programming language. C provides efficient execution and energy usage. SOS kernel includes a sensor drivers and modules that are using the drivers. Other resources includes timer multiplexing , UART, libraries , and hardware management of the I2C bus. SOS support Mica2 and MicaZ. Major limitation is in the development of loose coupling modules. 4KB size limitation for AVR module binaries. Modules cannot make any reference to the global variables of the SOS kernel.

E.Implementation of LiteOS

In TinyOs applications are driven by events using a FIFO scheduler. In contrast to TinyOS event based programming model, LiteOS depends on threads for execution.LiteOS applications are compiled into a modified HEX format. In LiteOS some applications consume more memory than TinyOS. LiteOS supports Dynamic memory at the kernel level , which is provided to applications as library APIs(malloc and free) through system calls.


Fig.6.Comparison of operating systems[6]


In this paper comparative study of different operating systems are presented. TinyOS, Contiki, Mantis OS, SOS,and LiteOS are the different operating systems developed for sensor networks.TinyOs is based on component based programming model. Mantis OS is a lightweight multithreaded OS .It supports C API that enables cross-platform support.It also supports multimodal prototyping, dynamic reprogramming etc. Contiki OS is designed for memory constrained systems for reducing the size of the system. It is based on event- driven kernel. It also support multithreading. SOS is a dynamically designed system which consists of dynamically linked modules and dynamic memory. LiteOS is the recently designed OS. It provides UNIX like abstractions and support for c programming language.