«Carles Gómez Josep Paradells José E. Caballero Edita: Fundación Vodafone España Autores: Carles Gómez Montenegro* Universitat Politècnica de ...»
• In the former case, the device communicates its decision to its router by transmitting the disassociation notification command. The router will then transmit an update-device command to the trust centre, which will erase the device from its list of devices in the network. Fig. 9.10 shows the described message exchanges.
• In the latter case, the trust center transmits a remove-device to the router, which in turn transmits a disassociation notification to the device so that it abandons the network. Fig. 9.11 shows the described message exchanges.
9.4. Security services of other solutions Although ZigBee defines a complete security architecture that adds the security functionality that is not defined in IEEE 802.15.4, the same has yet to be developed for 6LoWPAN. Nevertheless, the need for it has already been identified . With regard to BT-LE, the link layer provides encryption and authentication by using AES-128 and CCM .
Other solutions, such as Z-Wave, INSTEON or Wavenis offer encryption services. In particular, the 200 and 300 series Z-Wave chips do not offer security mechanisms, but the 400 series Z-Wave chip supports 128-bit key AES encryption. INSTEON supports various encryption techniques, but recommends the use of simple rolling codes, as used in garage door openers. Wavenis supports encryption algorithms such as Triple Data Encryption Standard (3DES) and 128-bit key AES.
 IEEE 802.15.4, “Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)”, May 2003.
 V. Rijmen, J. Daemen, “The Block Cipher Rijndael”, Smart Card Research and Applications, LNCS 1820, pp. 288-296, Springer-Verlag, 2000.
 M. Bellare, J. Kilian, P. Rogaway, “The Security of the Cipher Block Chaining Message Authentication Code”, Journal of Computer and System Sciences, 61(3) pp. 362-399, December 2000.
 D. Whiting, R. Housley, N. Ferguson. “Counter with cbc-mac (ccm)”, RFC 3610, September 2003.
 “ZigBee Specification”, r17 version, January 2008.
Chapter 9. Security
 IEEE Computer Society, "IEEE Std. 802.15.4-2006", September 2006.
 C. Bormann, D. Sturek, Z. Shelby, “6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols”, Internet Draft, (Work in progress) July 2009.
 “Specification of the Bluetooth System”, Covered core package version:
4.0, December 2009
10. Operating systems As it has been mentioned in Chapter 5, a sensor node includes a processor that executes tasks which require access to hardware elements such as memory, input/output and communications. The operating system (OS) is another task that allows coordinating the use of resources and offers an interface with the hardware to make it independent from the applications that the sensor node executes.
10.1. Basic features
The basic functions the OS is responsible for are the following: processor management, device management, execution time scheduling and concurrency management. In addition, the capability of code download, as well as offering an interface for application access to hardware elements are desirable features for an OS. In particular, an OS for sensor nodes should also account with energy management functionality in order to minimize energy consumption.
An OS is a program of vital importance in any processor because it makes easy to develop applications, but it must not degrade the features that the processor should offer. In environments where there are plenty of resources, this requirement is not important. However, as sensor nodes are limited devices in memory and processing capabilities, this requirement is fundamental .
Because WSNs are a distributed scenario, the OS may offer additional capabilities related to distributed application execution. This aspect is generally sol
ved with the usage of a concept known as ‘middleware’, which is software that may be placed in the elements of the network. Some middleware are a task executed by the nodes and some OSs include this functionality.
There exists a large range of OSs for sensor nodes. Some of them are adaptations of existing solutions for limited platforms, while others have been developed for sensor nodes. OSs can be classified in terms of basic features such as the architecture, the reprogramming facilities, the execution model and the scheduling.
The architecture of an OS refers to the organization of the OS and the applications that are executed. There exists a type of architecture called monolithic architecture, whereby the OS and the applications are integrated in the same program. Other types of OS architectures are the modular architecture and the virtual machine-based architecture. In the latter, the OS includes application components which allow making compact applications and hiding the network.
The execution model of an operating system indicates in which way the applications are executed. The most common execution model is based on events, but there exists another model that is based on threads. In the former, applications generate events which are dealt with sequentially. There exist other options, such as an execution model based on a state machine.
Reprogramming refers to the possibility of modifying the software which is executed in the OS. This feature has special interest in WSNs as access to the nodes may be limited in some environments.
With regard to scheduling, the processor is shared by the different tasks.
The most common scheduling approaches in WSNs are periodical/nonperiodical one and critical/non-critical one. For instance, a temperature measurement corresponds to a periodical event, while the generation of an alarm is non-periodical.
10.2. Existing operating systems for wireless sensor nodes There exists a great amount of OSs in the literature . The most accepted ones are TinyOS and Contiki, all of them being open-source OSs.
10.2.1. TinyOS TinyOS  is a popular free source code multi-platform OS for constrained devices, which is used in several hardware platforms from Crossbow (e.g. MICA, TelosB, Cricket or Shimmer). TinyOS was created by researchers from the University of Berkeley in the frame of the SmartDust project. It has no kernel to interface with the hardware. It is based in three functional abstractions, which are, in a decreasing order of priority: events, commands and tasks. TinyOS supports only five priority levels, which is a reduced value in comparison with those supported by other OSs. It restricts the maximum number of tasks to 255. Only one simultaneously active task is allowed and it can only be preempted by events or commands. TinyOS is written in nesC, a dialect of the C language and the behaviour of an application can be simulated using TOSSIM and PowerTOSSIM. TinyOS has embedded communication facilities such as the concept of active message. The message has a handler address that is used on the arrival of the message to call the handler. In addition, TinyOS has functionalities to support multi-hop communication, instead of single-hop communication, which is the default one in most OSs. TinyOS has a small footprint of 178 bytes of memory. As of the writing, the last version of TinyOS is 2.1.0.
FreeRTOS  is a free real-time multiplatform OS. It supports tasks and co-routines. Communication and synchronization among tasks or between tasks and interruptions is performed by queues and semaphores.
Development tools are available for several processor platforms, including Cortex-M3, ARM7, MSP430, H8/S, AMD, AVR, x86 and 8051. It neither poses constraints on the maximum number of tasks which can be created nor limits the number of priority levels which can be used. The same priority level can be assigned to different tasks.
10.2.3. RETOS RETOS  is a free source code multiplatform OS developed by the Mobile Embedded System research group of Yonsei University. It supports
threads which communicate between them using mutex and monitor functionality. As FreeRTOS, it does not restrict the number of tasks which can be created. It allows up to ten priority levels. The same priority level can be assigned to different tasks.
10.2.3. uC/OS II uC/OS II  is a multiplatform OS developed by Micrium. This is a preemptive real time multitasking OS intended for embedded systems. This OS can manage up to 255 tasks and specifies up to 64 priority levels, where 56 of them can be used by applications. The same priority can be specified to different tasks. Synchronization and communication among tasks or between tasks and interruptions is based on queues, mailboxes and semaphores.
It is not freely available and requires licensing from Micrium Inc, but it is free for educational purposes. It has ports for most of the popular processors and boards available in the market.
10.2.4. AMBIENT RT
AMBIENT RT  is an OS developed by Ambient Systems which allows managing up to 72 tasks (each one of them requires ten additional bytes of RAM). It does not limit the number of priorities to be used and it allows assigning the same priority to different tasks. Synchronization and communication among tasks or between tasks and interruptions is based on a data centric architecture and automatic mutual exclusion techniques, thus avoiding the use of semaphores or monitors. A limited version of this OS is available for free. One of the main disadvantages of this operating system is its complexity.
Nano-Qplus  is a sensor network multithreaded operating system developed by Korea’s Electronics and Telecommunications Research Institute (ETRI). The architecture of Nano-Qplus follows a layered modular design which consists of dynamically-loaded modules in the following three
Chapter 10. Operating systems
parts: Hardware, Nano OS and Application. Nano-Qplus assumes an ATMEL Atmega128 MCU and a CC2420 RF module. The Nano OS part has a role as kernel scheduler and network protocol stack. Nano-Qplus uses the notion of task and provides a variety of schedulers including FIFO scheduler, preemptive Round Robin scheduler, etc.
MantisOS is an open source, light –weighted and energy– efficient, multithreaded OS . The name of the OS comes from MultimodAl NeTworks of In-situ micro Sensor (MANTIS). The OS is preemptive and multi-threading with a power efficient scheduler that sleeps the microcontroller. It has a network protocol stack and supports remote management with dynamic reprogramming and remote login. The OS is written in C language and presents a small footprint requiring less than 500 bytes.
The Sensor Operating System (SOS)  is optimized towards reconfigurability. It can add, modify, and delete software modules at runtime. This allows incrementally updating a node once it is deployed and remove unused modules. It uses a kernel to access system resources such as timers, memory, sensors and actuators. It provides a mechanism for communication between modules based on the usage of messages. The OS is written in C language. As of the writing, the development of SOS has been discontinued.
Contiki  is an open-source, highly portable, multi-tasking operating system for constrained embedded systems. Contiki offers most of the standard features of an OS such as threads, timers, random number generations, file system and command line shell. Contiki consists of an event-driven kernel. Programs are dynamically loaded and unloaded on top of this kernel.
Contiki processes use lightweight protothreads, which offer a linear, thread
like programming on top of the event-driven kernel. Contiki also supports per-process optional preemptive multithreading and inter-process communication using message passing through events. Contiki uses C as a programming language and the behaviour can be simulated using COOJA (Contiki OS Java Simulator). Contiki incorporated an IP stack (the uIP stack, developed to be used in resource constrained platforms). Contiki runs on a variety of platforms including TelosB, with AVR MCU and MSP430 MCU among others.
10.2.9. Microsoft.NET Micro
The Microsoft.NET Micro  is a solution from Microsoft for embedded platforms which are too resource-constrained to run other solutions from the same company. It offers the advantages of.NET programming for this type of platforms. It has a small footprint (about 300 kB) considering the type of solution. It supports full Visual Studio Integration, with live debugging of code running in the objective device. This OS requires a significant amount of resources, such as for example ARM7 or ARM9 CPUs, but it does not offer real time support. The IMote 2.0 node uses this OS.
 Adi Mallikarjuna V. Reddy, A.V.U. Phani Kumar, D. Janakiram, G. Ashok Kumar, “Wireless sensor network operating systems: a survey”, International Journal of Sensor Networks, Vol. 5, No. 4, pp. 236-255,  A.K. Dwivedi, M.K. Tiwari, O.P. Vyas, “Operating systems for tiny networked sensors: a survey”, Internatonal Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009.
 TinyOS website, http://www.tinyos.net  FreeRTOS website, http://www.freertos.org,  RETOS website, http://www.retos.yonsei.ac.kr/index.html
Chapter 10. Operating systems
 uC/OS II website.
http://www.micrium.com/products/rtos/kernel/rtos.html  AMBIENT RT website.
http://smart-surroundings.com/ambient/technology-rtos.htm  S. Park et al. “A Nano Operating System for Wireless Sensor Networks”, ICACT 2006, February 2006.
 S. Battti et al. “MANTIS OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms”, Mobile Networks and Applications, Springer, Vol. 10, No. 4, pp. 536-579, August 2005  SOS website.