Introduction to TinyOS

Networking Open Experimental Platform Small microcontroller 8 kB code 512 B data Simple, low-power radio 10 kbps ASK EEPROM (32 KB) Simple sensors WeC 99 “Smart Rock” Mica 1/02 NEST open exp. Platform 128 kB code, 4 kB data 40kbps OOK/ASK radio 512 kB Flash Rene 11/00 Designed for experimentation -sensor boards -power boards TinyOS Services Dot 9/01 Demonstrate scale Spec 6/03 “Mote on a chip” Telos 4/04 Robust Low Power 250kbps Easy to use Mica2 12/ kbps radio FSK Commercial Off The Shelf Components (COTS)

Reminder watt = voltage * amphere –Unit of power joule = watt * second –Unit of energy

Faster, Smaller, Numerous Moore’s Law –“Stuff” (transistors, etc) doubling every 1-2 years Bell’s Law –New computing class every 10 years year log (people per computer) Streaming Data to/from the Physical World Source: HotChips 2004

Mote Evolution Source: HotChips 2004

Design Principles Key to Low Duty Cycle Operation: –Sleep – majority of the time –Wakeup – quickly start processing –Active – minimize work & return to sleep Source: HotChips 2004

Sleep Majority of time, node is asleep –>99% Minimize sleep current through –Isolating and shutting down individual circuits –Using low power hardware Need RAM retention Run auxiliary hardware components from low speed oscillators (typically 32kHz) –Perform ADC conversions, DMA transfers, and bus operations while microcontroller core is stopped Source: HotChips 2004

Overhead of switching from Sleep to Active Mode Wakeup Microcontroller Radio (FSK) 10ns – 4ms typical 1– 10 ms typical 2.5 ms 292 ns Source: HotChips 2004

Active Microcontroller –Fast processing, low active power –Avoid external oscillators Radio –High data rate, low power tradeoffs –Narrowband radios Low power, lower data rate, simple channel encoding, faster startup –Wideband radios More robust to noise, higher power, high data rates External Flash (stable storage) –Data logging, network code reprogramming, aggregation –High power consumption –Long writes Radio vs. Flash –250kbps radio sending 1 byte Energy : 1.5  J Duration : 32  s –Atmel flash writing 1 byte Energy : 3  J Duration : 78  s Source: HotChips 2004

Mica2 (AVR) –0.2 ms wakeup –30  W sleep –33 mW active –19 kbps 2/3 of AA capacity –2.5V min Power Calculation Comparison Design for low power MicaZ (AVR) –0.2 ms wakeup –30  W sleep –33 mW active –250 kbps –2.5V min 2/3 of AA capacity Telos (TI MSP) –0.006 ms wakeup –2  W sleep –3 mW active –250 kbps –1.8V min 8/8 of AA capacity Report data once every 3 minutes with two AA batteries (<1% duty cycle) 328 days945 days453 days

Software challenges Power efficiency Small memory footprint Application specific Modularity Concurrency-intensive operations –Multiple, high-rate data flows (radio, sensor, actuator) Real-time –Real-time query and feedback control of physical world –Little memory for buffering: Data must be processed on the fly –TinyOS: No buffering in radio hw: deadline miss  data loss –TinyOS provides NO real-time guarantees! –EDF (Earliest Deadline First) scheduling supported in TinyOS 2.x Perfect???

“General-Purpose” OS? MANY functionalities & programming APIs Protection between “untrusted” applications and kernel –Overhead for crossing kernel/user boundary & interrupt handling Multi-threaded architecture –Large number of threads  large memory –Context switch overhead I/O model –Blocking I/O: waste memory on blocked threads –Polling: waste CPU cycles and power Need a new OS architecture!

TinyOS Overview Application = scheduler + graph of components –Compiled into one executable Event-driven architecture Single shared stack No kernel/user space differentiation Communication ActuatingSensing Communication Application (User Components) Main (includes Scheduler) Hardware Abstractions

Traditional OS Architectures Problems Large memory & storage requirement Unnecessary and overkill functionality Address space isolation, complex I/O subsystem, UI Relative high system overhead, e.g, context switch Require complex and power consuming hardware support VMI/O Scheduler Application 1 Application 2 Monolithic kernel HW NFSI/O Scheduler Application 1 Micro-kernel HW IPC VM

Desirable OS architecture Extremely small footprint Extremely low system overhead Extremely low power consumption

NO Kernel Direct hardware manipulation NO Process management Only one process on the fly NO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile time NO Software signal or exception Function call Goal: to strip down memory size and system overhead. TinyOS Architecture Overview I/O COMM. ……. Scheduler TinyOS Application Component Application Component Application Component

TinyOS Architecture Overview Characteristics of TinyOS –No UI, power constrained –Application specific HW and SW –Multiple flows, concurrent bursts –Extremely passive vigilance (power saving ) –Tightly coupled with the application Mote Hardware ActuatingSensing Simplified TinyOS Architecture Active Message Communication Application (User Components) Main (includes Scheduler)

TinyOS component model Component has: –Frame: storage –Tasks: computation –Interface Command Event Frame: static storage model - compile time memory allocation (efficiency) Command and events are function calls (efficiency) Messaging Component Internal State Internal Tasks CommandsEvents

An Example Application RFM Radio byte (MAC) Radio Packet i2c Temp photo Messaging Layer clocks bit byte packet Routing Layer sensing application application HW SW ADC messaging routing

TinyOS Two-level Scheduling Tasks do computations –Non-preemptive FIFO scheduling –Bounded number of pending tasks Events handle concurrent dataflows –Interrupts trigger lowest level events –Events preempt tasks, tasks do not –Events can signal events, call commands, or post tasks Hardware Interrupts events commands FIFO Tasks POST Preempt Time commands

Two-Level Scheduling Event and Task –Tasks cannot preempt other tasks –Single shared stack Used by both interrupts and function calls –Simple FIFO scheduler –Events can preempt a task –Events can preempt each other –When idle, scheduler shuts down the node except for clock

Event implementation Event is independent of FIFO scheduler. Lowest level events are supported directly by Hardware interrupt Software events propagate from lower level to upper level through function call

How to handle multiple data flows? Data are handled by –A sequence of non-blocking event/command (function calls) through the component graph –Post tasks for computations that are not “emergent” Preempting tasks to handle new data

How should network msg be handled? Socket/TCP/IP? –Too much memory for buffering and threads Data are buffered until application threads read it Application threads blocked until data is available –Transmit too many bits (sequence #, ack, re- transmission) –Tied with multi-threaded architecture TinyOS solution: Active Messages

Active Message Every message contains the name of an event handler Sender –Declare buffer storage in a frame –Name a handler –Request Transmission –Done - completion signal Receiver –The corresponding event handler invoked No blocked or waiting threads on the receiver Behaves like any other events Single buffering

Analysis and Evaluation Space, Power and Time

Code and Data Size Breakdown Scheduler: 178 Bytes code Totals: 3450 Bytes code 226 Bytes data

Time Breakdown

Total propagation delay: 40 us (80 instructions)

Power Breakdown…

Evaluation of TinyOS Small memory footprint  –Non-preemptable FIFO task scheduling Power efficient  –Put microcontroller and radio to sleep Efficient modularity  –Function call (event, command) interface between components Concurrency-intensive operations  –Event-driven architecture –Efficient interrupts/events handling (function calls, no user/kernel boundary) Real-time  –Non-preemptable FIFO task scheduling –No real-time guarantees or overload protection

What should be added to TinyOS? Priority- & deadline-driven scheduling? –RM? EDF? –Appropriate for data-centric applications? –How to deal with multiple resources, e.g., CPU & wireless bandwidth? Extend RM or EDF? End-to-end timing guarantees? Reliable synchronization mechanism? Internet or large scale service infrastructure? –Interoperability? –Protocols? TCP/IP, UDP, RTP? …