Towards System Architecture for Tiny Networked Devices

David Culler

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

U.C. Berkeley

Wireless hoo-hah

5/30/2000

5/30/2000 wireless hoo hah 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

5/30/2000 wireless hoo hah 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

5/30/2000 wireless hoo hah 4

‘Mote’ Initial Platform

5/30/2000 wireless hoo hah 5

TOS Tiny OS

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

• Component:– Frame

– 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

5/30/2000 wireless hoo hah 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)();

5/30/2000 wireless hoo hah 7

Composition

RFM

Radio byte

Radio Packet

UART

Serial Packet

i2c

Temp

photo

Active Messages

clocksbit

byte

packet

mapper router sensor applnappln

HW

SW

5/30/2000 wireless hoo hah 8

Dynamics of Events and Threads

• Message Send Transition

Timing diagram of event propagation

5/30/2000 wireless hoo hah 9

Empirical Breakdown of Effort

• can take apart time, power, space, …

• 50 cycles threads ovhd, 10 cycle event ovhd

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

5/30/2000 wireless hoo hah 10

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

5/30/2000 wireless hoo hah 11

Programming CAD

• Can assemble overall system using WV structural VHDL

• Scripts convert to all the make magic

5/30/2000 wireless hoo hah 12

Projects this Term

• Device Proxy Architecture– mobile-IP RDP variant

• Integration with infrastructure – JINI and Ninja

• Multithreaded vs federated archtiecture

• 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

5/30/2000 wireless hoo hah 13

Looking forward

• Mote “designed for experimentation” this summer

• Lots of projects now “small matter of programming”

• Good basis for incorporating more exciting HW architectures