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

Prabal Dutta

Sep 29, 2005

with Mike Grimmer (Crossbow), Anish Arora, Steven Bibyk (Ohio State) and David Culler (U.C. Berkeley)

1

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 2

Evolution : Extreme Scale (“ExScal”) Scenarios ExScal Focus Areas: Applications, Lifetime, and Scale

• 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

Sep 29, 2005 3

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 4

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 5

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)

Sep 29, 2005

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

6

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 7

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% (411  W on LPL) – Passive Infrared • 15% (880  W) – Acoustic • 29% (1.73mW) – Magnetic • 323% (19.4mW) • Always-on requires ~1200% of budget

Sep 29, 2005 8

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

T DC

= 1.07 draws  7% of power budget – Radio needed to forward event detections and meet latency

Sep 29, 2005 9

Quality vs. Lifetime : Sensor Operation

Short (<< T event ) Medium (< T event ) (  Long T event )

Sep 29, 2005 Power Consumption (with respect to budget)

Low (<< P budget ) Medium (< P budget ) High (  P budget ) Duty-cycle or Always-on Duty-cycle or Always-on Duty-cycle Duty-cycle ?

?

Always-on ?

Unsuitable

10

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 11

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 12

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 13

Quality vs. Lifetime : Magnetic Sensor

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

Sep 29, 2005 14

Quality vs. Lifetime : Passive Vigilance Energy-Quality Hierarchy

• • • Low High False Alarm Rate Energy Usage Multi-modal, reasonably low power sensors that are Duty-cycled, whenever possible, and arranged in an Energy-Quality hierarchy with low (E, Q) sensors Triggering higher (E, Q) sensors, and so on… High Low Trigger network includes hardware wakeup, passive infrared, microphone, magnetic, fusion, and radio, arranged hierarchically Nodes: sensing, computing, and communicating processes Edges: <  E,  P FA >  <  E,  P FA >

Sep 29, 2005 15

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

H 0

• How to Optimize Energy-Quality?

&

H 1

– Let

x

* = (

x

1 *,

x

2 *,...,

x n

*) between

H 0

&

H 1

. for

n

ROC curves, optimizing for energy-quality is a matter of minimizing the function

f

be the (

x

*) =

n E

alarm constraints of the system.

[ decision boundaries processes. Then, given a set of

power

(

x

*)] subject to the power, probability of detection, and probability of false

Sep 29, 2005 16

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 17

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 18

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 19

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 20

Engineering Considerations: Packaging Sep 29, 2005 21

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 22

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 23

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 24

Closing Thoughts

Data Collection vs.

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

Sep 29, 2005 25

Discussion Sep 29, 2005 26