Sep 29, 2005 1

Design of a Wireless Sensor Network Platformfor Detecting Rare, Random, and Ephemeral Events

Prabal Dutta

with Mike Grimmer (Crossbow), Anish Arora, Steven Bibyk (Ohio State)

and David Culler (U.C. Berkeley)

Sep 29, 2005 2

Origins : “A Line in the Sand”

Put tripwires anywhere – in deserts, or other areas where physical terrain does not constrain troop or vehicle movement – to detect, classify, and track intruders

Sep 29, 2005 3

Evolution : Extreme Scale (“ExScal”) Scenarios

• Border Control– Detect border crossing

– Classify target types and counts

• Convoy Protection– Detect roadside movement

– Classify behavior as anomalous

– Track dismount movements off-road

• Pipeline Protection– Detect trespassing

– Classify target types and counts

– Track movement in restricted area

ExScal Focus Areas: Applications, Lifetime, and Scale

Sep 29, 2005 4

Common Themes

• Protect long, linear structures• Event detection and classification

– Passage of civilians, soldiers, vehicles– Parameter changes in ambient signals– Spectra ranging from 1Hz to 5kHz

• Rare– Nominally 10 events/day– Implies most of the time spent monitoring noise

• Random– Poisson arrivals– Implies “continuous” sensing needed since event arrivals are

unpredictable• Ephemeral

– Duration 1 to 10 seconds– Implies continuous sensing or short sleep times– Robust detection and classification requires high sampling rate

Sep 29, 2005 5

The Central Question

How does one engineer a wireless sensor network platform to reliably detect and classify, and quickly report, rare, random, and ephemeral events in a large-scale, long-lived, and wirelessly-retaskable manner?

Sep 29, 2005 6

Our Answer

• The eXtreme Scale Mote– Platform

• ATmega128L MCU (Mica2)• Chipcon CC1000 radio

– Sensors• Quad passive infrared (PIR)• Microphone• Magnetometer• Temperature• Photocell

– Wakeup• PIR• Microphone

– Grenade Timer• Recovery

– Integrated Design

• XSM Users– OSU, Berkeley, MIT, UIUC,

UVa, Vanderbilit– MITRE/NGC/Kestrel/SRI– Others (now sold by Xbow)

Why this mix? Easy classification:– Noise = PIR MAG MIC– Civilian = PIR MAG MIC– Soldier = PIR MAG MIC– Vehicle = PIR MAG MIC

Sep 29, 2005 7

The Central Question : Quality vs. Lifetime

How does one engineer a wireless sensor network platform to reliably detect and classify, and quickly report, rare, random, and ephemeral events in a large-scale, long-lived, and wirelessly-retaskable manner?

Sep 29, 2005 8

Quality vs. Lifetime : A Potential Energy Budget Crisis

• Quality– High detection rate

– Low false alarm rate

– Low reporting latency

• Lifetime– 1,000 hours

– Continuous operation

• Limited energy– Two ‘AA’ batteries

– < 6WHr capacity

– Average power < 6mW

• A potential budget crisis– Processor

• 400% (24mW)

– Radio• 400% (24mW on RX)• 800% (48mW on TX)• 6.8% (411W on LPL)

– Passive Infrared• 15% (880W)

– Acoustic• 29% (1.73mW)

– Magnetic• 323% (19.4mW)

• Always-on requires ~1200% of budget

Sep 29, 2005 9

Quality vs. Lifetime : Duty-Cycling

Processor and radio• Has received much attention in the literature• Processor: duty-cycling possible across the board

• Radio: LPL with TDC = 1.07 draws 7% of power budget

– Radio needed to forward event detections and meet latency

Sep 29, 2005 10

Quality vs. Lifetime : Sensor Operation

Low(<< Pbudget)

Medium(< Pbudget)

High( Pbudget)

Short(<< Tevent)

Duty-cycle

or

Always-on

Duty-cycle Duty-cycle

Medium(< Tevent)

Duty-cycle

or

Always-on

? ?

Long( Tevent) Always-on ? Unsuitable

Power Consumption(with respect to budget)

Sta

rtu

p L

aten

cy(w

ith

res

pec

t to

eve

nt

du

rati

on

)

Sep 29, 2005 11

Quality vs. Lifetime : Sensor Selection

Key Goals: low power density, simple discrimination, high SNR

2,200 x difference!

Power density may be a more important metric than current consumption

Sep 29, 2005 12

Quality vs. Lifetime : Passive Infrared Sensor

• Quad PIR sensors– Power consumption: low– Startup latency: long– Operating mode: always-on– Sensor role: wakeup sensor

Sep 29, 2005 13

Quality vs. Lifetime : Acoustic Sensor

• Single microphone– Power consumption: medium (high with FFT)– Startup latency: short (but noise estimation is long)– Operating mode: duty-cycled “snippets” or triggered

Sep 29, 2005 14

Quality vs. Lifetime : Magnetic Sensor

• Magnetometer– Power consumption: high– Startup latency: medium (LPF)– Operating mode: triggered

Sep 29, 2005 15

Quality vs. Lifetime : Passive Vigilance

• Trigger network includes hardware wakeup, passive infrared, microphone, magnetic, fusion, and radio, arranged hierarchically

• Nodes: sensing, computing, and communicating processes

• Edges: < E, PFA> < E, PFA>

FalseAlarmRate

EnergyUsage

HighLow

LowHigh

Energy-Quality Hierarchy

Multi-modal, reasonably low-power sensors that areDuty-cycled, whenever possible, and arranged in anEnergy-Quality hierarchy with low (E, Q) sensorsTriggering higher (E, Q) sensors, and so on…

Sep 29, 2005 16

Quality vs. Lifetime : Energy Consumption

• How to Estimate Energy Consumption?– Power = idle power + energy/event x events/time– Estimate event rate probabilistically: p(tx) =

from ROC curve and decision threshold for H0 & H1

• How to Optimize Energy-Quality?– Let x* = (x1*, x2*,..., xn*) be the n decision boundaries

between H0 & H1. for n processes. Then, given a set of ROC curves, optimizing for energy-quality is a matter of minimizing the function f(x*) = E[power(x*)] subject to the power, probability of detection, and probability of false alarm constraints of the system.

Sep 29, 2005 17

The Central Question : Engineering Considerations

How does one engineer a wireless sensor network platform to reliably detect and classify, and quickly report, rare, random, and ephemeral events in a large-scale, long-lived, and wirelessly-retaskable manner?

Sep 29, 2005 18

Engineering Considerations: Wireless Retasking

• Wireless multi-hop programming is extremely useful, especially for research

• But what happens if the program image is bad?

No protection for most MCUs!

• Manually reprogramming 10,000 nodes is impossible!

• Current approaches provide robust dissemination but no mechanism for recovering from Byzantine programs

Sep 29, 2005 19

Engineering Considerations: Wireless Retasking

• No hardware protection• Basic idea presented by

Stajano and Anderson• Once started

– You can’t turn it off

– You can only speed it up

• Our implementation:

Sep 29, 2005 20

Engineering Considerations: Logistics

• Large scale = 10,000 nodes!• Ensure fast and efficient human-in-the-loop ops

– Highly-integrated node• Easy handling (and lower cost)

– Visual orientation cues• Fast orientation

– One-touch operation• Fast activation

– One-listen verification• Fast verification

• Some observations– One-glance verification

• Distracting, inconsistent, time-consuming

– Telescoping antenna• “Accidental handle”

Sep 29, 2005 21

Engineering Considerations: Packaging

Sep 29, 2005 22

Evaluation

• Over 10,000 XSM nodes shipped• 983 node deployment at Florida AFB• Nodes

– Survived the elements– Successfully reprogrammed wirelessly– Reset every day by the grenade timer– Put into low-power listen at night for operational reasons

• Passive vigilance was not used

• PIR false alarm rate higher than expected– 1 FA/10 minutes/node– Poor discrimination between person and shrubs

Sep 29, 2005 23

Conclusions

• Passive vigilance architecture– Energy-quality tradeoff – Beyond simple duty-cycling– Extend lifetime significantly (72x compared to always-on)– Optimize energy, quality, or latency

• Scaling Considerations– Wirelessly-retaskable – Highly-integrated system– One-touch– One-listen

• DARPA classified the project effective 1/31/05• Crossbow commercialized XSM (MSP410) on 3/8/05

Sep 29, 2005 24

Future Work

• “Perpetual” Deployment– Evaluate year-long deployment

– 1,000 node sensor network

– Areas surrounding Berkeley

• Trio Mote– Telos platform

– XSM sensor suite

– Grenade timer system

– Prometheus power system

Sep 29, 2005 25

Closing Thoughts

Data Collection

Phenomena Omni-chronic

Signal Reconstruction

Reconstruction Fidelity

Data-centric

Data-driven Messaging

Periodic Sampling

High-latency Acceptable

Periodic Traffic

Store & Forward Messaging

Aggregation

Absolute Global Time

Event Detection

Rare, Random, Ephemeral

Signal Detection

Detection and False Alarm Rates

Meta-data Centric (e.g. statistics)

Decision-driven Messaging

Continuous “Passive Vigilance”

Low-latency Required

Bursty Traffic

Real-time Messaging

Fusion, Classification

Relative Local Time

vs.

Sep 29, 2005 26

Discussion