A System Architecture for Tiny Networked Devices Jason Hill U.C. Berkeley 9/22/2000

Goals: To develop an ultra low power networked sensor platform, including hardware and software, that enables low-cost deployment of sensor networks. To be a system level bridge that combines advances in low power RF technology with MEMS transducer technology.

Key Characteristics of TNDs Small physical size and low power consumption => Limited Physical Parallelism and Controller Hierarchy => primitive direct-to-device interface Concurrency-intensive operation flow-thru, not wait-command-respond => must handle multiple inputs and outputs simultaneously Diverse in Design and Usage application specific, not general purpose huge device variation => efficient modularity => migration across HW/SW boundary Largely Unattended & Numerous => robust operation => narrow interfaces

‘Mote’–The Hardware 4Mhz, 8bit MCU (ATMEL) 512 bytes RAM, 8K ROM 900Mhz Radio (RF Monolithics) ft. range Temperature Sensor Light Sensor LED outputs Serial Port COTS Dust weC Mote

Second Generation ‘Mote’ Two Board Sandwich Main CPU board with Radio Communication Secondary Sensor Board Allows for expansion and customization Current sensors include: Acceleration, Magnetic Field, Temperature, Pressure, Humidity, Light, and RF Signal Strength. Can control RF transmission strength & Sense Reception Strength

Tiny OS – The Software Provides a component based model abstracting hardware specifics from application programmer. Capable of maintaining high levels of concurrency. Allows multiple applications to be “running.” Services Provided Include: RF messaging protocols. Periodic Timer Events. Asynchronous access to UART data transfers. Mechanism for Static, Persistent Storage. Can “Swap Out” system components to get necessary functionality. Complete applications fit in 4KB of ROM and 256B RAM.

Tiny OS Internals Scheduler and Graph of Components constrained two-level scheduling model: tasks + events Component: Frame (storage) Tasks (concurrency) Commands, and Handlers (events) Constrained Storage Model frame per component, shared stack, no heap Very lean multithreading Layering components issue commands to lower-level components event signal high-level events, or call lower-level commands Guarantees no cycles in call chain

TOS Component Messaging Component init Power(mode) TX_packet(buf) TX_packet _done (success) RX_packet_ done (buffer) Internal State init power(mode) send_msg(ad dr, type, data) msg_rec(type, data) msg_send_ done (success) send_msg_thread /* Messaging Component Declaration */ //ACCEPTS: char TOS_COMMAND(AM_SEND_MSG)(char addr,char type, char* data); void TOS_COMMAND(AM_POWER)(char mode); char TOS_COMMAND(AM_INIT)(); //SIGNALS: char AM_MSG_REC(char type, char* data); char AM_MSG_SEND_DONE(char success); //HANDLES: char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet); //USES: char TOS_COMMAND(AM_SUB_TX_PACKET)(char* data); void TOS_COMMAND(AM_SUB_POWER)(char mode); char TOS_COMMAND(AM_SUB_INIT)(); CommandsEvents

Composition to Complete Application RFM Radio byte Radio Packet UART Serial Packet i2c Temp photo Active Messages clocks bit byte packet Route map routersensor appln application HW SW

Programming with CAD Can assemble overall system using structural VHDL Scripts pre-process VHDL at compile time Allows for compile time resolution of event handlers Eliminates need for registration mechanisms and dynamic dispatch Automatically allows events to be handled by multiple components. (TX_Done) Significantly more flexibility than library based component models

Event Based Programming Model System composed of state machines Each State Machine is a TinyOS “component” Command and event handlers transition a component from one state to another Quick, low overhead, non-blocking state transmissions Allows many independent components to share a single execution context Emerging as design paradigm for large scale systems “Tasks” are used to perform computational work Run to completion, Atomic with respect to each other

Dynamics of Events and Threads Message Send Transition Timing diagram of event propagation

Empirical Breakdown of Effort can take apart time, power, space, … 50 cycle thread overhead, 10 cycle event overhead Components Packet reception work breakdown Percent CPU UtilizationEnergy (nj/Bit) AM 0.05%0.20%0.33 Packet 1.12%0.51%7.58 Ratio handler 26.87%12.16% Radio decode thread 5.48%2.48%37.2 RFM 66.48%30.08% Radio Reception Idle-54.75%- Total %

Migration of the Hardware Software Boundary TinyOS component model propagates hardware abstractions into software. Allows for a migrations of software components into hardware: Example: Bit level radio procession component could be implemented as specialized FIFO with complex pattern matching.

Storage Breakdown (C Code) 3450 B code 226 B data

Multi-Hop Routing Demo Sensors automatically assemble and determine routing topology Parallel Breadth First Search Shortest path to all nodes remembered Base station broadcasts out routing information Individuals listen for and propagate route update N messages sent Generational scheme to prevent cycles in routing table Base

Demo (cont.) Sensor information propagated up routing tree Statistics kept for number of readings received and number of packets forwarded by each node Sensors transmit data when “significant” events occur or when time limit is exceeded Must be continuously listening for packets to be forwarded – impacts power considerations

Future Goals: Short Term Deploy sensor net for week long trials Target Civil Engineering’s and The Center For the Built Environment’s needs for a real world deployment. Determine algorithms for aggregation and analysis of data inside the network. Support applications where data is “picked up” by roaming data collection nodes. Long Term Deploy networks of 1000s of nodes Year long, unattended deployments