Smart Dust and TinyOS: Hardware and Software for Network

advertisement

CS294-1 Deeply Embedded Networks

Emerging Standards and Course

Perspective

David Culler

University of California, Berkeley

12/2/03

New Class of Computing

Mainframe

Minicomputer

Workstation

PC

Laptop

PDA year

12/2/03

Number Crunching

Data Storage productivity interactive streaming information to/from physical world

Example uses

Env. Monitoring, Conservation biology, ...

Precision agriculture, land conservation, ... built environment comfort & efficiency ... alarms, security, surveillance, treaty verification ...

Civil Engineering: structures response

condition-based maintenance disaster management urban terrain mapping & monitoring

Interactive Environments

context aware computing, non-verbal communication handicap assistance

»

»

home/elder care asset tracking

Integrated robotics

12/2/03

CENS.ucla.edu

Typical Characteristics

# nodes >> # people sensor/actuator data stream unattended inaccessible prolonged deployment energy constrained operate in aggregate in-network processing is necessary what they do changes over time

=> must be self-organized, self-maintaining and programmed in situ to operate at very low duty cycle

12/2/03

The System Challenge

Monitoring & Managing Spaces and Things applications data mgmt service network system architecture

MEMS sensing

Comm.

Proc

Store technology uRobots actuate

Power

12/2/03

Miniature, low-power connections to the physical world

A Systems View

Desire for decomposition

Modularity, Optimization, Predictability

Interactions Across Layers / Components

Constraints

Information availability

Control

Performance Characteristics

12/2/03

Where Have We Been?

12/2/03

Application-Driven Network Architecture

Emergence of Wireless Sensor/Effector Nodes

Operating Systems for DENs

Low-power MAC, discovery, topology formation

Tools for analysis

Broadcast / Data dissemination

Design Lessons (Lew Girod, Dave Hughes)

Aggregation and in-network processing (Sam)

Multihop Routing for Data Collection (Alec)

Time Synchronization

Ad Hoc Routing

Cluster Formation

Where We’ve been (cont)

Directed Diffusion

Localization

Collaborative Signal Processing (Feng Zhao)

Tracking

Multi-resolution Storage

Distributed Control

Coverage

Security

Privacy

Emerging Standards

12/2/03

Impact of radio design?

Bluetooth ?

IEEE 802.15.4 ?

Bluetooth and Sensor Networks: A Reality Check

Designed as cable replacement

Connection oriented, frequency hopping

Narrow interface

TDM - master/slave(7) piconet

ScatterNet ???

12/2/03

Fresh Look at BlueTooth

Fixed MAC

Similar event-driven

Discovery and connection mgmt below HCI

Master: inquiry

Slave: inquiry scan

Pre-established connection above

Build self-assembly out of connection ???

Timing and pwr mgmt invisible to appln

App adapts to radio, not reverse

Very small stack

10% of Bluetooth

3 KB for UART HCI

MAC in HW

12/2/03

Events and Buffering

Retain buffer swap

Start/End ptr across layers to allow encapsulation

12/2/03

Multihop Topology Formation

Two radios per node

Master (connects to children)

Slave (connects to parent)

Grow Tree as very slow flood

Turn on slave and look for master

If success, turn on M and allow children

Backtrack on fail

Try alternating parent

3 connect-fail on node with 7 children

»

Disconnect child

»

On disconnect, disconnect all children

Convergence???

Maintenance over time?

How well connected can network be?

S

M

M

S

M

S

M

S

12/2/03

In-Network Processing

Query Graph subset of radio graph

Devices can negotiate “sniff mode”

App has no control over timing

App adapts to TDM

Pipelines query processing across epochs

Cannot go into deep sleep

No rate adaptation to contention

No snooping

12/2/03

Throughput & Power

Small fraction of peak

5x ChipCon & RFM

Similar uJ/bit

High Power

30 mW radio on

39 mW inquirable

89 mW waiting for conn

136 mW maintain conn

200 mW @ 6 KB/s

Sniff save 5 mW

12/2/03

Energy Usage

Radio off => rediscover

10-30 sec to discover

12/2/03

Mica

Worst case

Closing Observations

Scatter nets still not supported

Certification

Applns denied relevant information

Connection maintenance expensive

Sniff not much value

Perhaps this all changes with “single chip” version

MCU shared with application

12/2/03

What about 802.15.4?

Sensor nets at least a secondary goal

Game controllers primary

Direct Sequence Spread Spectrum

instead of freq. Hop (O-QPSK)

Phy & MAC separate from network (Zigbee)

Simple, controllable MAC

Attention to low duty-cycle devices

0-104 byte packets

12/2/03

Lessons about Methodology

Emerging area, so not just X improvement over established basis

Reaching beyond current technology

Define method of evaluation along with new idea

Still, some classic pitfalls to avoid

12/2/03

1. Compare to a Weak Strawman

My fancy routing protocol is 40% better than all nodes flooding

(when there is only one or two “communications” going on at a time).

My fancy scheduling algorithm uses half the energy of naively burning full time

(when there may be simple ways of reducing energy cost of most prevalent state).

This piece of steel is a million times stronger than that wet noodle .

Weak strawthings are for negative results

This piece of lasagna is ONLY 40 stronger than that wet noodle

If it is all you’ve got, estimate optimal so you can see the spread

12/2/03

12/2/03

2. Change many parameters at once and claim the one that you have been talking about accounts for the improvement

My adaptive clustering protocol

(which happens to also compress n values to 1 at each hop) is 40% better than tree-based routing

(of all the data).

Patterson refers to this as the Computer Science Method

3. Design for a different load point and compare where yours is intended

My new protocol (designed for short messages) is 40% better then theirs (designed for long messages) on short messages.

My scheduling algorithm (designed for high contention) is

40% better than theirs (designed for moderate contention) on …

Also good to never show simple options that perform almost as well as your really complex thing, because that just confuses the reader.

12/2/03

4. Do very narrow empirical assessment and extrapolate through simulation, neglecting the impact of more general setting

Measure range error for particular pair of nodes in direct alignment and use for many pairs of nodes in arbitrary orientation

12/2/03

Small Technology, Broad Agenda

Social factors

security, privacy, information sharing

Applications

long lived, self-maintaining, dense instrumentation of previously unobservable phenomena

interacting with a computational environment

Programming the Ensemble

describe global behavior, synthesis local rules that have correct, predictable global behavior

Distributed services

localization, time synchronization, resilient aggregation

Networking

self-organizing multihop, resilient, energy efficient routing

despite limited storage and tremendous noise

Operating system

extensive resource-constrained concurrency, modularity framework for defining boundaries

Architecture

rich interfaces and simple primitives allowing cross-layer optimization

Components

low-power processor, ADC, radio, communication, encryption, sensors, batteries

12/2/03

Larger Questions

What is the energy required to maintain a distributed data structure (e.g, routing tree, connectivity graph) to a certain level of precision?

What are sufficient conditions on local rules to assure globally predictable behavior?

What are the scalability limits and how are they influenced by hierarchy, connectivity, storage?

12/2/03

Thanks

Projects Friday Dec 5, 2 pm, 6th floor Soda

12/2/03

Download