A Dynamic Operating System for Sensor Nodes Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, Mani, Srivastava, MobiSys ‘05 Oct., 2009 발표자 : 김영선, 윤상열

Introduction Sensor Operating System is needed for Wireless Sensor Network –General-purpose System Characteristic Easy to Write Applications –Embedded System Characteristic Little Energy Robust to Environmental Conditions –Sensor nodes located Far from Networked Infrastructure Internet System Technology2

Motivation code updates become more expensive, since a whole system image must be distributed More efficient energy Less latency Internet System Technology3

Solution Approach Operating System for Sensor Node –Event Driven –Component Model Possible Exceptionally to be Modified after Deploying it to a System –Flexible System such as VM Computational Overhead → Less CPU Overhead but Higher Mote Reprogramming Cost Internet System Technology4

Solution Approach Micro kernel –Mach, Exokernel  SOS uses a small kernel : Lower than Mach and higher than the Exokernel TinyOS –Event driven –Static-linked system  SOS is event driven and uses a component model, but SOS components can be installed and modified after a system has been deployed. Internet System Technology5

Solution Approach : structure of SOS Module –position independent binaries driver, protocol, application component –Message handling Parameter : message + module state Internet System Technology6

Solution Approach : structure of SOS Message handling –init / final message –init message handler module initialize initial periodic timer, function registration, function subscription –final message handler free node resources such as timer, memory, registered functions –module specific messages handling of timer trigger sensor reading incoming data messages from other modules or nodes Internet System Technology7

Solution Approach : structure of SOS Function Control Block (FCB) –key information about the registered function –indexed by the tuple { module ID, function ID } –valid flag, subscriber reference count, prototype information prototype : { return type, pointer, ?, parameter n } –SOS kernel can easily replace a function by changing the function pointer in the FCB ※ module access kernel functions using a jump table Internet System Technology8

Solution Approach : structure of SOS Module insertion –distribution protocol listening for advertisements of new modules –check... already installed? free program memory? Module removal –initiated by the kernel dispatching a final message final opportunity to gracefully release –garbage collection memory, timers, sensor drivers, and other resources Internet System Technology9

Solution Approach : structure of SOS Potential Failure Modes –deliver a scheduled message to a module that does not exist on the node drop the message and free memory –delivering a message to a handler that is unable to handle the message solved by the individual modules drop the message, return an error code, and instruct the kernel to collect memory Internet System Technology10

Solution Approach : structure of SOS Message Scheduling –priority queues –Memory Layout of An SOS Message Queue Internet System Technology11

Solution Approach : structure of SOS Dynamic Memory –simple best fit fixed-block memory allocation smallest block size –message headers... larger block –applications need to move large continuous blocks of memory –allocates using linked list of free blocks Internet System Technology12

Advantage Small code size Very focused on less energy consumption to support powerful update mechanism Internet System Technology13

Discussion (1/3) Authors conclusively mentioned event-driven is more applicable than multi-thread. Only compared with event-driven based operating systems. >> The performance of event-driven could be affected by lengthy computation or latency. >> ‘Contiki’ uses a hybrid model to combine the benefits of both event-driven systems and preemptable threads. Internet System Technology14 [IEEE LCN'04] Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors

Discussion (2/3) The total energy usage in SOS is nearly identical to that in TinyOS and Mat´e, despite different update costs and CPU active times. Dynamic memory and dynamic module management should have overhead. >> It can be possible to consume higher total energy if modules update less than expected. Internet System Technology15

Discussion (3/3) There is no objective evaluation for stability of dynamic memory. >> Dynamic memory is rarely used for sensor node because of limitation of memory and the possibility of memory crash. Internet System Technology16