Transcript ONR Minuteman Review - University of California, Los Angeles

Distributed Sensing in AINS
Mani Srivastava
[email protected]
Networked & Embedded Systems Lab
Center for Embedded Networked Sensing
University of California at Los Angeles
Based on work by: Capkun, Ganeriwal, Han, Hsu, Rengaswamy, Shea, Zahedi
Quic kTime™ and a
TIFF (Unc ompres sed) dec ompres sor
are needed t o s ee t his pict ure.
Copyright © 2005
3
Ad Hoc Deployment of Unattended
Sensors…
4
Self-Configuration …
Node Localization
Where did an event take place?
Timing synchronization
When did an event take place?
Calibration
What is the value of an event?
5
Operation: Interact with Mobile Agents in a
Mission…
6
Sustenance and Integrity: Retasking,
Recalibration, Repair…
New code
Recalibrator
7
Summary of AINS Distributed Sensing
Research
•
•
•
•
How to easily program sensor networks?
– SensorWare: Agent-based middleware for autonomous missionspecific operation
– SOS, DASVM: dynamic software reconfiguration
How to self-configure sensor networks after ad hoc deployment?
– AhLos: Ad Hoc localization framework
– TPSN, RATS: Fine-grained and rate adaptive multihop time sync
How to have sustainable sensor networks?
– Data Mule: controlled-mobility nodes and disruption tolerant networking
for energy efficient data ferrying and
– HelioMote: energy-harvesting aware sensor nodes and protocols
– U-BMAC: uncertainty-based MAC with low-power listening
How to provide high-integrity operation of sensor networks?
– PAKE: physical attribute-based keys for secure event reporting
– RFSN: reputation-based framework sensor network security
– Secure time synchronization
8
I. Dynamic Software Reconfiguration
9
Recall: SOS for Dynamic Embedded
Software Reconfiguration
•
•
Embedded OS with built-in support for remote (wired or wireless) code
configuration
– Retasking the system
– Customizing to deployment environment
– Sharing the system among concurrent users and missions
– Upgrades, bug fixes, feature additions
Approach
– Execution environment with capability to remotely insert and remove
binary modules without disruption in mote-class devices
– Efficient multihop module distribution protocol
Dynamic Modules
Dynamic Loadable
Binary Modules
Dynamic Loadable
Binary Modules
Drivers, protocols, and applications
Inexpensive to modify after deployment
Position independent
Static SOS Kernel
Hardware
Abstraction
Module
Communication
Static Kernel
Memory
Manager
Hardware abstraction and common
services
Costly to modify after deployment
Data structures to enable module loading
10
Update Cost
(Transport + Storage)
Reconfiguration Options
Entire Image
(TinyOS)
Modular Binary
(SOS)
Differential
Binary
Patching
Lightweight Scripts
(Virtual Machine)
Flexibility
11
Recent Research Directions and
Accomplishments
• New research
– Detailed SOS vs. TinyOS, Mate performance characterization
– Hierarchy of reconfiguration
• Dynamic Application-Specific Virtual Machine (DASVM)
– Safety: static checks, run-time checks, and recovery
– Support software
• Back-end application integration
• Simulation support
– Real-code simulation of SOS in sQualNet
– Detailed instruction-level simulation of SOS networks in Avrora
• Additional platforms
– Telos motes
• Deployments
– 1-week outdoor deployment in CA desert (with HMC)
• Best demonstration award at ACM/IEEE IPSN 2005
• Paper at ACM MobiSys 2005
12
Performance Characterization: SOS vs.
TinyOS (fixed image), Mate (virtual machine)
Data Transfer Delay
TinyOS
SOS
Maté
4.58%
4.64%
5.13%
29.92
29.94
30.02
Method
Energy
Cost
Entire binary upgrade (TinyOS)
784.14 mJ
High
Modular binary upgrade (SOS)
12.25 mJ
Moderate
Virtual Machine scripts (Maté)
0.34 mJ
Low
Active Time (%)
Average Power(mW)
Packet Delivery Ratio
13
Hierarchy of Reconfiguration Mechanisms
Script
Script
New Script,
Small,
Interpreted
Dynamic and
application-specific
boundary
Dynamic
Module
Virtual
Machine
Interpreter
Dynamic
Module
Dynamic
Application
Application
Application
Specific
Specific
Specific
Instruction
Instructions
Library
Instructions
Static SOS Kernel
Details and demo during afternoon lab visit!
New Binary
Module,
Moderate,
Native
New Flash
Image,
Large,
Native
14
The Emerging SOS Community
• Many groups within UCLA
•
•
•
•
Yale University
Notredame
Harvey Mudd College
NEC Labs
• And several others… (mailing list has > 50 members)
• New release with significant enhancements (with
significant inputs from Yale and Notredame
• Nascent interest from Crossbow in adopting SOS
16
II. Environmental Energy Harvesting for
Energy Neutral Distributed Sensing Systems
17
Recall: HelioMote Sensor Platform and
Learning-based Harvesting-aware N/W Operation
•
•
•
•
Energy storage: NiMH battery
Management: Autonomous, Analog
Solar panel: Autonomous, near maximal
power point operation
System support: Harvesting aware operation
– Hardware and TinyOS driver/API for
collecting charge accumulation,
temperature, run-time and voltage data
Learn Local Energy
Characteristics
Predict Future
Energy
Opportunity
Learn
Consumption
Statistics
Distributed
Decision
for
Scheduling
Routing
MAC DutyCycling
18
HelioMote Lifetime Analysis (based on
NASA’s insolation data for December in LA)
Duty
cycle
Power
(mW)
50% of Day in Shade
Surplus
Energy (%)
Discharge
Depth (%)
Lifetime
(years)
Unobstructed Node
Surplus
Energy (%)
Discharge
Depth (%)
Lifetime
(years)
1%
1.24
1.84
1.49
25 years
5.20
1.47
25 yrs
5%
4.15
0.65
2.66
23 years
4.02
2.58
23 yrs
7.5%
5.96
3.29
3.28
22 yrs
10%
7.78
2.55
3.97
21 yrs
15%
11.41
1.08
5.36
19 yrs
20%
15.05
Energy from panel insufficient to
provide perpetual operation
Energy from panel insufficient to
provide perpetual operation
Lifetime = min (time to first outage, battery degradation to 80%)
•
•
•
Even with obstructions, sustained operation at 7% duty cycle is feasible (18%
without obstructions)
Experimental numbers are much better … sustained operation at more than 40%
duty cycle in LA winter
Energy supply is 3X higher in Summer (7.25 kWH/m2)
19
Recent Accomplishments
•
•
HelioMote v2 platform
– Improved efficiency and noise, bug fixes
– More robust packaging
Performance measurement and analysis
– Detailed HelioMote platform characterization
– Lifetime analysis
– Outdoor deployments
•
•
•
•
•
•
20-node 1-week
4-node 80-days (and continuing)
External adopters
– UC Merced, EPFL, Inovonics Wireless
Low-power design contest winner at ACM ISLPED
HelioMote v3 platform in progress
– Better tracking of maximal power point (MPP)
using hybrid ultracap/battery architecture
– Versatility: handling of different solar panels,
loads, and batteries
Harvesting-aware duty cycling
– Algorithms for duty cycle adaptation, and
their integration with MAC
Depleted
More details during afternoon lab visit!
25
III. Ultra Low Power Duty Cycling with Rate
Adaptive Time Sync
26
On-Demand Wakeup
Large radio IDLE mode energy (leakage)  Shutdown
Tracker
event
Zzz
Zzz
Zzz
Multihop Tripwire
Zzz
27
Duty Cycling in Tripwire Nodes
Sensor Node
Sensor
CPU
Radio
Periodic tasks
Triggered Events
Long Lifetime
Key design principles
Sleep: majority of the time (>99%)
Wakeup: quickly start processing
Active: minimize work & return to sleep
Sensor duty
cycle period
determined by
latency and
dynamics
Sample rate
determined by
signal b/w
# of samples
determined by
sensor
characteristics
Sensor
Processor
Rare EVENT
Radio Tx
28
Asynchronous vs. Synchronous Radio Dutycycling with Low-power Listen
Packet Ready
@ Tx
Rx Ready
T
Rx
Long preamble > T
Async Tx #1
(e.g. STEM, BMAC)
Async. Tx #2
Sync. Tx
Drift
29
Key to Energy is Time
• The greater the time uncertainty
between Tx and Rx at the time of
packet transmission, the longer the
preamble
•
•
•
•
4B for perfect sync
250B for 11.5%
1212B for 2.2%
1B for every 416us
• Reducing time uncertainty
– Stable, high quality clock source
• Size, power, cost issues
• Even NIST’s chip-scale atomic clock is
75 mW
– Time synchronization
• Require additional message exchange
to periodically resync
• This overhead can negate energy
benefits of uncertainty reduction
2.22% duty cycle
1212B
Preamble Length
– Worst case is asynchronous
– E.g. BMAC with 29B payload
11.5% duty cycle
250B
4B
0
0.1s
0.5s
Time Uncertainty
30
Time Synchronization
•
Current schemes quite good for
instantaneous synchronization between
sensor nodes
– Few microseconds on motes with simple
linear regression
•
But different clock drifts cause them to go
out of sync
– Need to resync periodically
– E.g. 40 s/s, need to resync every 2.5s for
a 100 s uncertainty bound
•
This is not enough for synchronized lowpower listening MAC
– Drift variation is not constant
System
Re-synchronization
period
Shooter localization system
1 minute
James reserve
5 minute
Great Duck island
10 minutes
SMAC, MAC
Sleep time of 100ms to
maximum of 2 minutes
FTSP
30s, 5 minutes
31
•
Rate Adaptive Time Synchronization
(Reported in November)
Key ideas:
– Focus on long term time sync as opposed to instantaneous time sync
– Achieve desired level of uncertainty
– Decide maximum possible resynchronization interval
– Adapt to ambient conditions
Synchronize a pair of nodes A and B.
Sample
Repository
Model
Estimation
K
(TA , TB)
TB    k TA
Window (W)
Current state of art
k 0
Error
Prediction
k
Sampler
F
F
E p  TˆB  TB
Decide new
beaconing time of A
Error
Bound (Emax)
Sampling
period (S)
33
Performance Comparison
For an error bound of 90µs
Hardware specs
FTSP (Vanderbilt)
Drift Estimate
Periodic Resync
period
Drift Estimate
Periodic
Period
5µs/s
18s
2µs/s
45s
RATS
Resync
Average Resync
period
20 – 60 min
34
Uncertainty-driven Duty Cycling MAC
RATS + BMAC  UBMAC
• Background
– Minimum preamble length  4
– Extra bytes added for taking care of time uncertainty.
• Fixed Preamble mode
– BMAC chooses to use a preamble of x bytes irrespective of dutycycle.
– Maximum time uncertainty allowed -> (x-4)*byte time.
– RATS objective is to achieve this error bound
• Variable Preamble mode
– When transmitting packet BMAC ask RATS to estimate the time
uncertainty between the nodes.
– Based on this, the preamble size is chosen on the fly!
35
Uncertainty-driven B-MAC on
Mote Tripwires
•
•
•
•
35.5% duty cycle, application level packet every 30s
Asynchronous BMAC uses 94B preamble
UBMAC (BMAC+RATS) set to use 6B and RATS tries to keep error bound within 2B = 832us
24 hour experiment
–
–
–
–
•
BMAC: 2800 packets with 94B preamble
UBMAC: 2800 packets with 6B preamble + 28 RATS packets
Total energy improvement at Tx: 3X
Similar gains at Rx, as it too is on for shorted duration
RATS is equivalent to having a “stable” clock source of < 300 nW
37
Energy Gains at Tx
• Cut off point of relative event and
time sync frequency, beyond
which energy gains of UBMAC
over BMAC constant
• With lower duty-cycle energy
gains increases.
– UBMAC -> Functionality
remains unchanged,
– BMAC -> Need to use a longer
preamble to tackle the worstcase.
• For applications with mild latency
constraints (1.5s per hop == 1%
duty cycle), energy gains of
UBMAC can be up to 60x than
BMAC.
• Similar gains at Rx as well.
39
IV. Secure Time Synchronization
40
Securing Time Synchronization
• Time information used in many places
– Counter replay attacks
– Signal processing
– Data aggregation
– MAC layer
– Secure localization (distance bounding)
– …
• All hinge on time synchronization to be secure
• Adversary can seriously compromise the network by altering a
node’s perception of time
– E.g. node localization using time of flight
• distance = speed*time
41
Sender-Receiver Synchronization

T 2  T1  d   ;
A

Recv at T2
Send at T1
Recv at T4
A
T 4  T3 d 

B
Send at T3

B
(T 2  T 1)  (T 4  T 3)
(T 2  T 1)  (T 4  T 3)
;d 
2
2
Offset with which we correct the clock

Why can’t the attacker simply modify these packets?
We need to attach MACs but is that all…..
42
Sender-Receiver Synchronization
+ Pulse-delay Attack

Send at T1
A
Snoop


B
Replay it later
T 2  T1  d    

Recv at T2
Jam the signal
PULSE DELAY FACTOR
(T 2  T 1)  (T 4  T 3)  
(T 2  T 1)  (T 4  T 3)  
;d 
2
2
Offset is now increased by /2
– Cryptography cannot save us
• Attacker is not modifying the packet
• It is just replaying it at a later time
43
Solution
– But as a side effect

(T 2  T 1)  (T 4  T 3)  
(T 2  T 1)  (T 4  T 3)  
;d 
2
2
Calculated delay also increases by /2
Imagine that we know the upper bound on the expected
maximal delay (d*), then….
Secure Pairwise Synchronization (SPS)
1. A (T1)  (T2) B : A, B, NA, sync
2. B (T3)  (T4) A :
B, A, T2, T3, MAC{KAB}[B, A, NA,T2,T3],ack
3. A calculates propagation delay d=(T2-T1)+(T4-T3)/2
If d≤d* then ={(T2-T1)-(T4-T3)}/2, else abort
44
Is is feasible?
Delay (in microseconds)
How accurately can we estimate d*?
Empirical evaluation over 5 mote pairs.
770
765
760
755
0
100
200
300
400
500
600
700
800
900
1000
Maximum total Minimum total Average total Standard
delay (μs)
delay (μs)
delay (μs) (davg) deviation ()
Iteration
768
0.5
755
762
2.82
Probability
0.4
With 99.97% confidence delay will be in
[762 – 3*2.82 μs, 762 + 3*2.82 μs]
0.3
0.2
0.1
0
754
756
758
760
762
764
766
768
Delay (in microseconds)
Sender
software
MAC
Receiver
TX
propagation
Time stamping
RX
software
45
Performance Evaluation of SPS
• Parameter setting
– Choose maximal delay to be davg + 3  771μs
• Maximum attacker impact
– Maximum offset difference that an attacker can introduce
without getting detected.
– Equal to 6  20μs.
• Synchronization error performance
– Same as insecure TPSN  10μs.
• Overhead
– None! Delay estimation comes as an auxiliary benefit.
46
Multihop Synchronization
• Node A wants to synchronize to B which is multiple hops away.
A ----- C ----- D ------ B
• Three protocols : SOM, SDM, and STM
– Offer different points of operation in the energy-security
subspace.
• Assumptions
– No need of secure routing.
– All that is required is the existence of at least one path between
A and B.
53
Group Synchronization
• Synchronize n nodes in a cluster so that the error
between them is bounded.
• Two protocols : L-SGS and SGS
– Offer different points of operation in the energy-security
subspace.
• Assumptions
– Exploit the broadcast property of the communication
medium.
– Ti -> Send time of packet broadcasted by node i.
– Tij -> Receive time of this packet at node j.
57
Summary of Tradeoffs in Time Sync Security
59
The End!