Distributed Sensing in AINS Mani Srivastava mbsucla edu

Distributed Sensing in AINS Mani Srivastava mbs@ucla. edu 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 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? – Sensor. Ware: Agent-based middleware for autonomous missionspecific operation – SOS, DASVM: dynamic software reconfiguration How to self-configure sensor networks after ad hoc deployment? – Ah. Los: 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 – Helio. Mote: 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 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 (Tiny. OS) Modular Binary (SOS) Lightweight Scripts (Virtual Machine) Flexibility Differential Binary Patching

11 Recent Research Directions and Accomplishments • New research – Detailed SOS vs. Tiny. OS, 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 s. Qual. Net – 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 Mobi. Sys 2005

12 Performance Characterization: SOS vs. Tiny. OS (fixed image), Mate (virtual machine) Data Transfer Delay Tiny. OS SOS Maté 4. 58% 4. 64% 5. 13% 29. 92 29. 94 30. 02 Method Energy Cost Entire binary upgrade (Tiny. OS) 784. 14 m. J High Modular binary upgrade (SOS) 12. 25 m. J Moderate Virtual Machine scripts (Maté) 0. 34 m. J Low Active Time (%)� Average Power(m. W) Packet Delivery Ratio

13 Hierarchy of Reconfiguration Mechanisms Script New Script, Small, Interpreted Dynamic and application-specific boundary Dynamic Module Virtual Machine Interpreter Dynamic Module Dynamic Application Specific 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: Helio. Mote Sensor Platform and Learning-based Harvesting-aware N/W Operation • • Energy storage: Ni. MH battery Management: Autonomous, Analog Solar panel: Autonomous, near maximal power point operation System support: Harvesting aware operation – Hardware and Tiny. OS driver/API for collecting charge accumulation, temperature, run-time and voltage data Learn Local Energy Characteristics Learn Consumption Statistics Predict Future Energy Opportunity Distributed Decision for Scheduling Routing MAC Duty. Cycling

18 Helio. Mote Lifetime Analysis (based on NASA’s insolation data for December in LA) Duty cycle Power (m. W) 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 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 3 X higher in Summer (7. 25 k. WH/m 2)

19 Recent Accomplishments • • Helio. Mote v 2 platform – Improved efficiency and noise, bug fixes – More robust packaging Performance measurement and analysis – Detailed Helio. Mote 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 Helio. Mote v 3 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 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 Radio Tx Rare EVENT

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 • • 4 B for perfect sync 250 B for 11. 5% 1212 B for 2. 2% 1 B for every 416 us • Reducing time uncertainty – Stable, high quality clock source • Size, power, cost issues • Even NIST’s chip-scale atomic clock is 75 m. W – Time synchronization • Require additional message exchange to periodically resync • This overhead can negate energy benefits of uncertainty reduction 2. 22% duty cycle 1212 B Preamble Length – Worst case is asynchronous – E. g. BMAC with 29 B payload 11. 5% duty cycle 250 B 4 B 0 0. 1 s 0. 5 s 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. 5 s 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 100 ms to maximum of 2 minutes FTSP 30 s, 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 (TA , TB) Window (W) Current state of art Error Prediction Sampler 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 18 s 2µs/s 45 s 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 30 s Asynchronous BMAC uses 94 B preamble UBMAC (BMAC+RATS) set to use 6 B and RATS tries to keep error bound within 2 B = 832 us 24 hour experiment – BMAC: 2800 packets with 94 B preamble – UBMAC: 2800 packets with 6 B preamble + 28 RATS packets – Total energy improvement at Tx: 3 X – Similar gains at Rx, as it too is on for shorted duration RATS is equivalent to having a “stable” clock source of < 300 n. W

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. 5 s per hop == 1% duty cycle), energy gains of UBMAC can be up to 60 x 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 Send at T 1 A Recv at T 4 A Recv at T 2 B Send at T 3 B 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 T 1 A Snoop Recv at T 2 Jam the signal B Replay it later PULSE DELAY FACTOR 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 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 (T 1) (T 2) B : A, B, NA, sync 2. B (T 3) (T 4) A : B, A, T 2, T 3, MAC{KAB}[B, A, NA, T 2, T 3], ack 3. A calculates propagation delay d=(T 2 -T 1)+(T 4 -T 3)/2 If d≤d* then ={(T 2 -T 1)-(T 4 -T 3)}/2, else abort

44 Is is feasible? How accurately can we estimate d*? Empirical evaluation over 5 mote pairs. Maximum total delay (μs) Minimum total delay (μs) Average total delay (μs) (davg) Standard deviation ( ) 768 755 762 2. 82 With 99. 97% confidence delay will be in [762 – 3*2. 82 μs, 762 + 3*2. 82 μs] 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!