april 27, 20051 design of a wireless sensor network platform for detecting rare, random, and...
Post on 21-Dec-2015
222 views
TRANSCRIPT
April 27, 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)
April 27, 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
April 27, 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
April 27, 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
April 27, 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?
April 27, 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– UIUC– University of Virginia– MITRE/NGC/others
Why this mix? Easy classification:– Noise = PIR MAG MIC– Civilian = PIR MAG MIC– Soldier = PIR MAG MIC– Vehicle = PIR MAG MIC
April 27, 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?
April 27, 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
April 27, 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
April 27, 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
)
April 27, 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
April 27, 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
April 27, 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
April 27, 2005 14
Quality vs. Lifetime : Magnetic Sensor
• Magnetometer– Power consumption: high– Startup latency: medium (LPF)– Operating mode: triggered
April 27, 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…
April 27, 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.
April 27, 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?
April 27, 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
April 27, 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:
April 27, 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”
April 27, 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
April 27, 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
April 27, 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
April 27, 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.
April 27, 2005 27
Deconstructing Startup Latency
• Low bandwidth sensors– Humidity– Temperature
• Large time-constant analog filtering circuits– PIR band pass filter– Magnetometer anti-aliasing low pass filter
• Analog filtering is easy on the energy budget• If analog filtering (e.g. anti-aliasing) required
– Either• Decouple sensing and signal condition• Duty-cycle sensor, T/H sensor output, analog always-on
– Or• Use sensing hierarchy with low-quality, low-power sensors
triggering high-quality, high-power sensors
April 27, 2005 28
Common Themes
• Event detection– Passage of civilians, soldiers, vehicles– Parameter changes in ambient signals– Spectra ranging from 1Hz to 5kHz
• Large scale– Long, linear structures– Requires 1,000s of nodes for coverage
• Long lifetime– Network must last for a long period of time
April 27, 2005 29
Quality vs. Lifetime : Passive Vigilance
• 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…
April 27, 2005 30
Quality vs. Lifetime : Duty-Cycling
Sensors• Acoustics: duty-cycling possible for “periodic snippets”
• Magnetic: duty-cycling impossible (Poweravg, fs and Tstartup conflict)
• Infrared: duty-cycling impossible (Tstartup too big, but not needed)
April 27, 2005 32
Quality vs. Lifetime : Passive Vigilance
• Multi-modal, low-power sensors that are
• Duty-cycled, where possible, and arranged in an
• Energy-Quality hierarchy with low (E, Q) sensors
• Triggering higher (E, Q) sensors, and so on…
• 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
April 27, 2005 33
Requirements (of the hardware platform)
• Functional– Detection, Classification (and Tracking) of:
Civilians, Soldiers and Vehicles
• Reliability– Recoverable: Even from a Byzantine program image
• Performance– Intrusion Rate: 10 intrusions per day– Lifetime: 1000 hrs of continuous operation (> 30 days)– Latency: 10 – 30 seconds– Coverage: 10km^2 (could not meet given constraints)
• Supportability– Adaptive: Dynamic reconfiguration of thresholds, etc.
April 27, 2005 35
Genesis: The Case for a New Platform
• Cost– Eliminate expensive parts from BOM– Eliminate unnecessary parts from BOM– Optimize for large quantity manufacturing and use
Network Scale by 100x (10,000 nodes)– Reliability: How to deal with 10K nodes with bad image
Detection range by 6x (10m)– New sensors to satisfy range/density/cost tradeoff
Lifetime 8x (720hrs 1000hrs)– Magnetometer: Tstartup = 40ms, Pss = 18mW– UWB Radar: Tstartup = 30s, Pss = 45mW– Optimistic lifetime: 6000mWh / 63mW < 100 hrs– Must lower power
• Radio– Fix anisotropic radiation and impedance mismatch
April 27, 2005 36
Hardware Evolution
Telos =Low-power CPU +802.15.4 Radio +Easy to useSleep-Wakeup-Active
MICAzMICA2 - CC1000 +802.15.4 RadioSleep-Wakeup-Active
XSMMICA2 + Improved RF +Low-power sensing + RecoverabilityPassive Vigilance-Wakeup-Active
XSM2XSM + Improvements +Bug Fixes
April 27, 2005 37
Sensor Suite
• Passive infrared– Long range (15m)
– Low power (10s of micro Watts)
– Wide FOV (360 degrees with 4 sensors)
– Gain: 80dB
– Wakeup
• Microphone– LPF: fc = 100Hz – 10kHz
– HPF: fc = 20Hz – 4.7kHz
– Gain: 40dB – 80dB (100-8300)
– Wakeup
• Magnetometer– High power, long startup latency
– Gain: 86dB (20,000)