Towards System Architecture for Tiny Networked Devices Jason Hill jhill jhill/tos U.C. Berkeley.

Towards System Architecture for Tiny Networked Devices

Jason Hill

http://www.cs.berkeley.edu/~jhill

http://www.cs.berkeley.edu/~jhill/tos

U.C. Berkeley

6/20/2000

6/20/2000 Endeavor Retreat 2

An End-to-end Perspective

• Desktops– max out at few 100M– in your face– connected to the infrastructure

• Ubiquitous Devices– billions– sensors / actuators– PDAs / smartphones / PCs– heterogeneous

Service Path

• Scalable Infrastructure– highly available– persistent state (safe)– databases, agents– service programming environment

6/20/2000 Endeavor Retreat 3

Key Characteristics of TNDs

• Small physical size and low power consumption

• Concurrency-intensive operation– flow-thru, not wait-command-respond

• Limited Physical Parallelism and Controller Hierarchy– primitive direct-to-device interface

• Diversity in Design and Usage– application specific, not general purpose

– huge device variation

=> efficient modularity

=> migration across HW/SW boundary

• Robust Operation– numerous, unattended, critical

=> narrow interfaces

6/20/2000 Endeavor Retreat 4

‘Mote’ Initial Platform

• 4Mhz, 8bit MCU512 bytes RAM, 8K ROM

• 900Mhz Radio10-30 ft. range

• Temperature Sensor• Light Sensor• LED outputs• Serial Port

6/20/2000 Endeavor Retreat 5

Tiny OS

• Scheduler and Graph of Components– constrained two-level scheduling model: threads + events

• Component:– Frame (storage)– Threads (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

6/20/2000 Endeavor Retreat 6

TOS Component

Messaging Component

init

Po

we

r(m

od

e)

TX

_p

ack

et(

bu

f)

TX

_p

ack

et

_d

on

e

(su

cce

ss)

RX

_p

ack

et_

do

ne

(b

uff

er)

Internal State

init

po

we

r(m

od

e)

sen

d_

msg

(ad

dr,

typ

e,

da

ta)

msg

_re

c(ty

pe

, d

ata

)

msg

_se

nd

_d

on

e

(su

cce

ss)

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)();

6/20/2000 Endeavor Retreat 7

Composition

RFM

Radio byte

Radio Packet

UART

Serial Packet

i2c

Temp

photo

Active Messages

clocksbit

byte

packet

Route map router sensor applnapplication

HW

SW

6/20/2000 Endeavor Retreat 8

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

6/20/2000 Endeavor Retreat 9

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.

6/20/2000 Endeavor Retreat 10

Dynamics of Events and Threads

• Message Send Transition

Timing diagram of event propagation

6/20/2000 Endeavor Retreat 11

Empirical Breakdown of Effort

• can take apart time, power, space, …• 50 cycle thread overhead, 10 cycle event overhead

ComponentsPacket reception work breakdown

Percent CPU Utilization Energy (nj/Bit)

AM 0.05% 0.20% 0.33

Packet 1.12% 0.51% 7.58

Ratio handler 26.87% 12.16% 182.38

Radio decode thread 5.48% 2.48% 37.2

RFM 66.48% 30.08% 451.17

Radio Reception - - 1350Idle - 54.75% -Total 100.00% 100.00% 2028.66

6/20/2000 Endeavor Retreat 12

Storage Breakdown (C Code)

0

500

1000

1500

2000

2500

3000

3500

4000

Multihop Router

AM light

AM Temp

AM

Packet

Radio Byte

RFM

Photo

Temp

UART Packet

UART

i2c

Init

TinyOS Scheduler

C Runtime

3450 B code 226 B data

6/20/2000 Endeavor Retreat 13

Projects this Term

• Device Proxy Architecture– mobile-IP RDP variant

• Integration with infrastructure – JINI and Ninja

• Multithreaded vs. federated architecture

• Pluggable adaptive MAC layer– often periodic, moment of crisis

– sleep cycling

• Ad Hoc routing component

• Connectivity-based location detection

• smart badge + sensor in smart space

6/20/2000 Endeavor Retreat 14

Multi-Hop Routing Demo

• Sensors automatically detect routing topology

• Base station broadcasts out routing information

• Individuals listen for an propagate route update– N messages sent

• Generational scheme to prevent cycles in routing table

Base

6/20/2000 Endeavor Retreat 15

Multi-Hop Routing Demo (cont.)

• Sensor information propagated up routing tree

• Statistics kept as to number of readings received and number of packets forwarded for each node

• Sensors transmit data when “significant” events occur or when time limit is exceeded

• Must be continuously listening for packets to be forwarded

6/20/2000 Endeavor Retreat 16

Second generation hardware design is under way• Mote “designed for experimentation”

• Additional Sensors– 2 Axis Accelerometer and 2 Axis Magnetometers

» Allows dead reckoning in 2-D plane

– Humidity, Temperature, and Pressure sensor

– Transmission strength sensor and control

• Expansion capabilities through external BUS– The hardware sandwich

• Ability to directly plug into logic analyzer for debugging purposes

6/20/2000 Endeavor Retreat 17

Current and Future Work

• Quantify error characteristics of RFM Radio– Allows selection of coding techniques that optimize

throughput and reliability

• Aggressive inlining to minimize overhead of modules

• Document and release code for others to use

• Determine limitations of TinyOS

• Incorporate more exciting HW architectures

• Integrate with Ninja active proxies and Base services