SCALABLE QUERY PROCESSING IN SERVICE ORIENTED SENSOR NETWORKS

1. SCALABLE QUERY PROCESSING IN SERVICE ORIENTED SENSOR NETWORKS Raja Bose Advisor: Dr. Abdelsalam (Sumi) Helal Mobile and Pervasive Computing Laboratory Department of Computer and Information Science and Engineering Monday, November 24, 2008

2. Overview • What is a Service Oriented Sensor Network? • Objectives • Introduction to Sensable • Sensor-Aware Query Processing • Virtual Sensors Framework • Phenomena Detection and Tracking • Conclusions • Patents & Publications

3. What is a Service Oriented Sensor Network? • Service Oriented Sensor Network (SOSN) brings the concept of Service Oriented Architecture (SOA) into sensor networks. • Each sensor represented as a software service which abstracts away its low-level operational details. • Sensor services can be dynamically discovered and composed into applications. • SOSNs emerged due to the fact that Wireless Sensor Networks (WSNs) lacked sufficient programmability to develop sophisticated smart space applications. • The Atlas Platform developed at the University of Florida was the world’s first service-oriented sensor platform.

4. Objectives • Bring query processing in service-oriented sensor networks into the realm of immediate utility. • Leverage SOAto provide energy-efficient query processing. • Leverage SOA to provide enhanced information processing capabilities to the smart space.

5. Introduction to Sensable • Sensors and Actuators as Services • Plug-and-Play – Devices appear as Services on Power-Up • Abstracts away Low-Level Device and Network Heterogeneity • Provides Basic Sensor Querying and Actuation • Utilizes Knowledge associated with Sensor Services to Minimize Total Energy Consumption • Enhancing Sensing Capability of Smart Space • Dynamic Creation and Lifecycle Management of Virtual Sensors • Localized, In-Network Detection & Tracking of Phenomena Clouds Sensable is a Scalable Query Processing middleware built on the Atlas Platform

6. Overall Architecture

7. Sensor-Aware Query Processing

8. Sensor-Aware Query Processing • In WSN research, traditional assumption is that networking is the major source of energy drain in query processing. • Advent of low-power yet high speed communication like ZigBee can render the above assumption invalid. • Use sensor operation knowledge associated with sensor service to optimize query execution.

9. When does Sensing Cost outweigh Networking Cost? • Faster the network, lower the transmission time. • Sensing depends on low-level primitive electrical devices which have physical limitations which can prohibit speedier operation. *MICA2 Mote from CrossBow: Atmega128 MCU and CC1000 Radio@38.4Kbps. RCB from Atmel: Atmega1281 MCU with ZigBee stack and AT86RF230 802.15.4 Radio@250Kbps.

10. Sensing Strategies - Push Query: (s1) AND (s2) AND (s3 OR s4) • Conventional approach to query execution. • All sensors sampled in parallel. • Readings propagated up and clauses evaluated. service layer Push Strategy base station (s1) AND (s2) AND (s3 OR s4) (s1) AND (s2) (s3 OR s4) (s1) (s2) (s3) (s4) s1 s2 s3 s4 physical sensors

11. Sensing Strategies – Selective Pull Query: (s1) AND (s2) AND (s3 OR s4) • Sensors sampled selectively in serial order. • Avoids sampling sensors unless strictly necessary. • Order of sampling determined based on sensors’ sensing cost, selectivity and cost of transferring control of evaluation to this sensor by reducing to a Traveling Salesman Problem. service layer Selective Pull Strategy base station (s1) AND (s2) AND (s3 OR s4) (s3 OR s4) (s1) AND (s2) (s1) (s2) (s3) (s4) s1 s2 s3 s4 physical sensors

12. Push vs. Selective Pull push Energy Consumption hybrid push-pull selective pull low high selective pull Latency of Response hybrid push-pull push low high

13. Sensing Strategies – Hybrid Push-Pull Query: (s1) AND (s2) AND (s3 OR s4) • A combination of push and selective pull strategies. • Provides a compromise between energy and latency. • As number of push operations increase, energy cost increases and latency decreases. • As number of pull operations increase, energy cost decreases and latency increases. service layer Selective Pull Strategy base station (s1) AND (s2) AND (s3 OR s4) (s3 OR s4) (s1) AND (s2) (s1) (s2) (s3) (s4) s1 s2 s3 s4 physical sensors Push Selective Pull

14. Results and Analysis Energy Consumption of Query Plans

15. Results and Analysis Latency of Query Plans

16. Results and Analysis Effect of Sensor Selectivity on Energy Consumption

17. Energy Consumption of All Plans Energy Consumption (mJ)

18. Results and Analysis Effect of Sensor Selectivity on Latency

19. Results and Analysis Effect of Query Size on Energy Consumption

20. Results and Analysis Effect of Query Size on Latency

21. Virtual Sensors Framework

22. Virtual Sensors Framework • Contemporary query processing systems for sensor networks deal with primitive data sourced directly from physical sensors. • Virtual sensor data is a function of multiple physical sensory inputs due to: • Spatial scope of data • Abstract data type • Virtual Sensors are software sensors whose output is a function of multiple inputs. • Virtual Sensors Framework enables the discovery, creation and lifecycle management of virtual sensors using SOA. • Allows applications to access and use virtual sensors as if they are physical sensors.

23. Classification of Virtual Sensors Wellness of Resident Derived Wellness Virtual Sensor • Basic Virtual Sensor • Composed of multiple sensors of same output type over a large space. • Output of Virtual Sensor is of same data type as that of component sensors. • Derived Virtual Sensor • Composed of multiple sensors with heterogeneous output types. • Output of Virtual Sensor is of a more abstract data type than component sensors. Temperature of Bedroom Basic Temperature Virtual Sensor

24. Framework Architecture framework controller management layer knowledge base derived virtual sensor services sensor layer basic virtual sensor services physical sensor services

25. Enhancing Sentience of the Smart Space virtual temperature sensor (basic) service composition service composition virtual ambience sensor (derived) service composition virtual humidity sensor (basic) service composition

26. Service Composition Graph Temperature • Used for creation of virtual sensors (forward look up) • Used for detecting new sensing capabilities of space (reverse look up). Ambience Virtual Ambience Sensor (derived) Virtual Temperature Sensor (basic) Physical Temperature Sensor Virtual Humidity Sensor (basic) Physical Humidity Sensor Humidity

27. Virtual Sensors in the GTSH Effect of adding Temperature Sensors Effect of adding Humidity Sensors Gator Tech Smart House

28. Creation and Operation of Virtual Sensors Step I – Centralized Creation inside the Service Layer User Application select ‘ambience’ from location = ‘bedroom’ Framework Controller Knowledge Base Ambience Sensor Service (Derived VS) Temperature Sensor Service (Basic VS) Humidity Sensor Service (Basic VS)

29. Creation and Operation of Virtual Sensors Step II – Distributed Operation inside the Node Layer Service Framework Ambience Sensor Service (Derived VS) Temperature Sensor Service (Basic VS) Humidity Sensor Service (Basic VS) root of evaluation tree for virtual ambience sensor root of aggregation tree for virtual temperature sensor root of aggregation tree for virtual humidity sensor Node Layer Sensor Layer physical temperature sensors physical humidity sensors

30. Monitoring Data Quality • Each Virtual Sensor has a built-in mechanism for monitoring quality of data originating from it. • Each reading is associated with a Virtual Sensor Quality Indicator (VSQI) value between 0 and 1. • VSQI of a Virtual Sensor decreases when one of its component sensors fails. • Approximation algorithm applied to maximize VSQI in face of sensor failure, by attempting to approximate readings of dead sensors using other live sensors. VSQIBVS = VSQIBVS є [0, 1] VSQIDVS = ∏ VSQIBVSi x ∏ VSQIDVSjVSQIDVS є [0, 1] 1≤ i ≤ n 1≤ j ≤ m

31. Results and Analysis Effect of Sensor Failure on Virtual Sensor Quality and Relative Error

32. Results and Analysis Effect of Sensor Failure Pattern on Virtual Sensor Quality

33. Results and Analysis Effect of Increase in Participating Sensors on Energy Consumption of Virtual Sensor

34. Results and Analysis Effect of Increase in Participating Sensors on Latency

35. Phenomena Detection and Tracking

36. Phenomena Detection and Tracking • Contemporary query processing systems only process data types which have precise definitions. • How to detect events which cannot be precisely described? • How to detect such events in face of uncertainty and noise? • Phenomena clouds are defined as a manifestation of a number of simultaneous events reaching “critical mass” and spanning a contiguous space. • The shape, size and direction of movement of phenomena clouds either cannot be predicted accurately.

37. Detection and Tracking of Phenomena Clouds • Contemporary systems such as Nile-PDT use a streaming approach where processing is done in a central query processor. • We utilize in-network, localized algorithms where detection and tracking processes are executed on sensor nodes clustered in the region where phenomena clouds are present at any given time. • A phenomenon cloud P is expressed as a 5-tuple: P = <a, b, pT, m, n>; where: [a, b] defines the range of magnitude of the phenomenon, pTdefines threshold probability, m defines sliding window size, n defines minimum quorum.

38. Classification of Roles assigned to Sensors • Tracking • Candidate • Potential Candidate • Idle

39. Role Transition Rules Neighboring Sensor • R1: Candidate → Tracking: If a sensor satisfies the Phenomenon-Condition then it transitions into the tracking category. • R2: Potential Candidate → Candidate: A potential candidate sensor will transition to a candidate sensor if any of its neighbors transitions into a tracking sensor. • R3: Idle → Potential Candidate: An idle sensor transitions into a potential candidate if any of its neighbors becomes a candidate sensor. • R4: Tracking → Candidate: A tracking sensor will transition down to the candidate category; if it is unable to satisfy the Phenomenon-Condition. • R5: Candidate → Potential Candidate: A candidate sensor will transition to a potential candidate sensor if none of its neighbors are tracking sensors. • R6: Potential Candidate → Idle: A potential candidate transitions into an idle sensor if all its neighbors are either potential candidates or idle, that is none of its neighbors are in the candidate category.

40. Steps in the Detection & Tracking Process Initial Selection & Monitoring Growth of Phenomenon Cloud Initial Occurrence Shrinking of Phenomenon Cloud Candidate Tracking Idle Sensor Potential Candidate

41. A Practical Application of Phenomena Detection and Tracking in the GTSH Effect of a Footstep on the Smart Floor Gator Tech Smart House Smart Floor

42. Results and AnalysisDetection Performance Effect of varying quorum ‘n’ on detection performance

43. Results and AnalysisDetection Performance Effect of varying threshold probability ‘pT’ on detection performance

44. Results and AnalysisDetection Performance Effect of varying sliding window size ‘m’ on detection performance

45. Results and AnalysisResource Consumption Effect of increasing sensor network size on number of updates

46. Results and AnalysisResource Consumption Effect of increasing sensor network size on number of active sensors

47. Results and AnalysisResource Consumption Effect of increasing sensor network size on node energy consumption

48. Conclusions • Described a query processing system for service-oriented sensor networks which utilizes SOA to provide energy-efficient querying and expanded information processing capabilities. • Described real-life applications of the system and provided performance analysis which supports the practical viability of this dissertation.

49. Patent • “Modular Platform Enabling Heterogeneous Devices, Sensors and Actuators to Integrate Automatically Into Heterogeneous Networks”, published October 2007 (USPTO Publication # 20070236346).

50. Publications • R. Bose, H. Yang, A. Helal, J. Xia, C. Chang, Fault-resilient Pervasive Service Composition, Advanced Intelligent Environments, H. Hagras, Editor, Springer Verlag. To appear, 2009. • A. Helal, R. Bose, C. Chen, H. Yang, The Internal Workings of the Gator Tech Smart House - Middleware and Programming Models, Smart Houses: Advanced Technology for Living Independently, Springer Verlag, To appear, 2009. • A. Helal, J. King, R. Bose, H. El-Zabadani, Y. Kaddourah, Assistive Environments for Successful Aging, Advanced Intelligent Environments, H. Hagras, Editor, Springer Verlag. To appear, 2009. • R. Bose, A. Helal, Distributed Mechanisms for Enabling Virtual Sensors in Service Oriented Intelligent Environments, Proceedings of 4th IET International Conference on Intelligent Environments (IE '08), Seattle, July 2008.