Towards A Holistic Approach for System Design in Sensor Networks

1. Towards A Holistic Approach for System Design in Sensor Networks Chair: Prof. Nael Abu-Ghazaleh Committee Members: Prof. Kenneth Chiu Dr. Tony Fountain Prof. Wendi Heinzelman Prof. Kyoung-Don Kang Prof. Michael Lewis Sameer Tilak

2. Outline • WSN Applications and Challenges • Summary of Contributions • Holistic Principle • WSN critical Subsystems and Services • Holistic Framework Architecture • Abstractions and Virtualization • Conclusion and Future Work

3. Enablers – Micro-sensors • Small (coin->matchbox->PDA range) • Limited resources • Battery operated • Embedded processor (8-bit to PDA-class processor) • Memory: Kbytes—Mbytes range • Radio: (Kbps – Mbps; often small range) • Storage (none to a few Mbits)

4. Sensor Network Applications Disaster Response Embed numerous distributed devices to monitor and interact with physical world: hospitals, homes, vehicles, and “the environment” Network these devices so that they can coordinate to perform higher-level tasks. Requires robust distributed systemsof hundreds or thousands of devices.

5. Sensor Node Specific Challenges • Low Battery power • Low bandwidth • Error-prone air medium • Low computing power and memory • Heterogeneous software and Hardware architectures

6. Sensor Network Challenges • Large-scale fine-grained heterogeneous sensing • 100s to 1000s of nodes providing high resolution • Spaced a few feet to 10s of meters apart • Collaborative • Each sensor has a limited view • Spatially • In terms of sensed data type • Distributed • Communication is expensive • Localized decisions and data fusion necessary

7. Summary of Contributions • WSN critical subsystems and services • Information dissemination • Storage Management • Localization • Holistic Framework • Abstraction and virtualization

8. Holistic Principle • Data centric, resource constrained operation • effective operation requires careful balancing of application level utility and cost  (Principle 1)  •  Communication is expensive • Localized interactions -- produce local estimates of utility and cost (Principle 2) • Local estimates of application level utility and cost can significantly differ from actual value observed globally • Information available globally that significantly impacts local estimates are called context • Identify and track context when it is worth it to do so (Principle 3)

9. WSN Critical Subsystems/Services Non-Uniform Information Dissemination ICNP 2003, NCA 2004, NCA 2005, TR

10. Non-Uniform Information Dissemination Loss in precision as a function of distance is acceptable

11. Intuition • Forward packets less aggressively the further away you are from the event • deterministically: e.g., forward every nth packet, n increase with distance • probabilistically: e.g., forward packets with a probability thatdrops with distance from event • Here, the context is spatial and can be efficiently tracked by tracking the distance from the source on the event packet • Significant energy saving results, while keeping information accurate close to the event source

12. Randomized Protocols Biased protocol: • Packet forwarding decisions are based on a coin toss and relative distance from source. • Forwarding probability is higher for physically closer sources. (Context) • Simple, low overhead and very scalable

13. Weighted Energy-Error Study

14. High-level concluding remarks • Energy-efficient light-weight protocols that capitalize on non-uniform information granularity • Context embedded in the form of TTL (distance from an event source).

15. WSN Critical Subsystems/Services Storage Management IJAHUC 2005, Wiley Book chapter 2005, TR

16. Intuition • Exploit spatio-temporal redundancy • Coordinate for redundancy control • Context is Spatial

17. Candidate Protocols • Local Storage • Local-Buffer • Clustering • CBCS: Aggregate and Store and Cluster Head • Context: • CLS: Coordinate and store locally • CCS: Combined CBCS + CLS

18. Clustering Round 1 (time = 0) Round 2 (time = 20) • Only CH stores data • Rotate CH • Distributed storage, medium fault-tolerance • Spatial aggregation possible Round 1 (time = 40)

19. CCS Samples CH has more global view than individual sensor CH Feedback Data Round 1 (time = 0) Feedback provides context for data utility Round 1 (time = 40)

20. Storage and Energy Study

21. High-level concluding remarks • Collaborative protocols are scalable, light-weight, does load balancing and increase storage lifetime • Context provided in terms of feedback for redundancy control • Context in space

22. WSN Critical Subsystems/Services Localization IEEE IWSEEASN 2005

23. Mobile Sensor Localization • Localization: Determine physical coordinates of a given sensor • Existing research considers static sensor nets. • Mobile sensors • Energy versus accuracy trade-offs • Protocols • SFR (Static Fixed Rate) • DVM (Dynamic Velocity Monotonic) • MADRD (Mobility Aware Dead Reckoning Driven)

24. Existing Research on Localization • Assumes Static Sensor Network • Focus on How to Carry Localization and not When • Range/Direction Based • Calculate distance from anchors and triangulate • Received Signal Strength (e.g. RADAR) • Time of Arrival (e.g. GPS) • Time Difference of Arrival (Cricket, Bat) • ProximityBased • Centroid • ATIP • DV HOPS • MDS

25. Motivation What about Mobile Sensor Networks ? Interesting Energy-Accuracy trade off !

26. Problem Definition

27. SFR • Localize every t seconds • Very simple to implement • Once Localize tag data with those coordinates till next localization • Energy expenditure independent of Mobility • Performance varies with Mobility • Existing Projects such as Zebranet use this approach (3 minutes).

28. DVM • Adaptive Protocol • Sensor Adapts its localization frequency to Mobility • Goal maintain error under application-specific tolerance • Compute current velocity and use it to decide next localization period • Once Localize tag data with those coordinates till next localization • Upper and Lower query threshold • Energy expenditure varies with Mobility • Performance almost invariant of Mobility

29. MADRD • Predictive Protocol • Estimate mobility pattern and use it to predict future localization • Localization triggered when actual mobility and predicted mobility differs by application-specific tolerance • Tag data with predicted coordinates (differs from SFR and DVM) • Changes in mobility model affect the performance • Upper and Lower query threshold • Energy expenditure varies with Mobility • Performance almost invariant of Mobility

30. MADRD State Diagram

31. High-level Summary of Analysis • Error in non-predictive protocols increase with any mobility that moves the node away from its last localization point • Error in Predictive protocols increase only when the predictive • Model is inaccurate • Model estimation in incorrect • Model changes (pause, direction change)

33. Medium Speed (4-5 m/s)

34. Error versus Pause time

35. Summary • Studied energy versus accuracy tradeoff in localization for mobile sensors • DVM and MARD are completely distributed scalable protocols • DVM and MADRD outperform SFR • Context Temporal

36. Application Context Data Samples Local utility estimate Resource Management • Non-Local resources • Data utility • (Principle 3) Storage Energy BW Local Resources HOLISTIC APPROACH Principle 1 Operation Management Principle 2 Initial Idea

37. Context • Localized decisions leads to scalability • Local estimate of utility of data can differ from global measurement • Absence of relevant global knowledge: Context • Feedback can be used to improve accuracy of local estimate

38. Patterns & Types Context • Patterns • Context in time • Context in space • Application-specific (domain knowledge) • Resource related (src-dest path) • Types • Utility context • Cost context

39. Research Challenges • Data Utility Assessment • Resource Cost Assignment • Utility-Cost Normalization • Tracking, Building, and Maintaining Context • Middleware

40. Holistic Framework Architecture Point in design space

41. Holistic Framework Components • Benefit Estimator • Cost Calculator • Planner

42. Benefit Estimator • Data Significance • Data scope in Time, Space • App-specific (observer interest) • Data Quality • Data Freshness, accuracy, resolution, • App-specific measures • Output Benefit Vector (BV) • MAUT

43. Cost Calculator • Sensing, Transmission, Storage, Computational, Reception. • Output Cost Vector (CV): Vector of pre-determined transformations • MAUT

44. Planner • Rule based engine. • Input BV, CV • Incorporates application state • Objective: Maximize Benefit/Cost ratio

45. Instance of a Planner Algorithm IF (Utility == HIGH) { IF(STATE== NEED_LOCALIZATION) LOCALIZE AND THEN TRANSMIT } If (Utility == MEDIUM) Transmit If (Utility == MEDIUM) Low drop.

46. Component Placement Trade-offs • Middleware versus Application • Benefit Estimator? • Application-specific knowledge • Cost Calculator? • App/infrastructure communication • Resource cost in middleware • Planner? • Single versus multiple apps

47. Abstraction EESR 2005

48. Related Work • Database Abstraction • Programming abstractions e.g. Nesc • TinyOS • Plan-9, Inferno

49. File System Abstraction • Treat entire sensor network as a distributed file system • Application-specific namespaces • Well understood interface • Heterogeneity • Applications get fine grained control over resources

50. Application-specific Namespaces Making Abstractions efficient Default resource namespace