1. The Design of an Acquisitional Query Processor For Sensor Networks Samuel Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong Presentation by Xin Liu

2. Outline Introduction Acquisitional Query Language Query Optimization Query Dissemination and Routing Query Execution Summary Discuss

3. Introduction A sensor node is a battery-powered, wireless computer, which power is extremely low. So reducing power consumption is important. ACQP (ACquisitional Query Processor): use acquisitional techniques to reduce power consumption compared to traditional passive systems.

4. Introduction (cont.) What is meant by acquisitional techniques? Where, when, and how often to acquire data. Four related questions: When should samples be taken? What sensors have relevant data? In what order should samples be taken? Is it worth to process and relay a sample?

5. Introduction (cont.) TinyDB (ACQP engine) is a distributed query processor which runs on each of the nodes in a sensor network. TinyDB runs on the Berkeley Mica mote platform, on top of the TinyOS operating systems.

6. Acquisitional Query Language Data Model Entire sensor network viewed as one single, infinitely-long logical table: sensors Columns consist of all the attributes defined in the network. Rows are individual sensor data. Queries as a Stream Sensors table is an unbounded, continuous data stream. Operations such as sort and symmetric join are not allowed. SQL-like queries in the form of SELECT-FROM-WHERE SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s

7. Acquisitional Query Language Event-Based Queries Instead of continuous polling for data, query runs only when interesting events happens. Example: ON EVENT bird-detector(loc) SELECT AVG(light), AVG(temp), event.loc FROM sensors AS s WHERE dist(s.loc, event.loc) < 10m SAMPLE INTERVAL 2s FOR 30s

8. Acquisitional Query Language Lifetime-Based Queries Example: Nodes perform cost-based lifetime estimate to determine data rate. Nodes must transmit at the root ’ s rate or at an integral divisor of it. SELECT nodeid, accel FROM sensors LIFETIME 30 days

9. Query Optimization Query optimization is power-based, the goal is to yield lowest overall power consumption. Queries are optimized by base station before dissemination. Power consumption dominated by: sampling transmitting

10. Query Optimization Metadata Management Each node contains metadata about its attributes. Nodes periodically send metadata to root. Information about cost, time to fetch, and range is used in query optimization.

11. Query Optimization Ordering of Sampling and Pridicates Consider the query: 1s Three options: sample accel and mag, then process select sample mag, filter, then sample accel sample accel, filter, then sample mag First option is always more expensive. If S mag is more selective than S accel, then second is cheaper. If S accel is highly selective, the third can be cheaper. SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s

12. Query Optimization Event Query Batching Consider the following query: Maybe multiple instances of query run at the same time. Thus, the independent sampling and delivering results will consume significant energy. What can we do with this? ON EVENT e(nodeid) SELECT a 1 FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k

13. Query Optimization Event Query Batching Solution: convert external events into a stream of events, and rewrite the query as a sliding window join between events and sensors. When an event arrives, add it to the buffer of events. When a sensor tuple s arrives, events older than k seconds are dropped from the buffer and s is joined with the remaining events. SELECT s.a1 FROM sensors AS s, events AS e WHERE s.nodeid = e.nodeid AND e.type = e AND s.time – e.time e.time SAMPLE INTERVAL d FOR k ON EVENT e(nodeid) SELECT a 1 FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k

14. Dissemination and Routing Intuition: if a node knows that none of its children will satisfy the selection predicate, say because they have constant attribute values outside the predicate ’ s range, it need not forward the query down. What can we do? SELECT light FROM sensors WHERE loc.x > 3 AND loc.x < 7

15. Dissemination and Routing Semantic Routing Tree Semantic Routing Tree Each node stores a interval representing the range of A values beneath each of its children. (A is a constant attribute) When a query q with a predicate over A arrives at node n, n checks if any child ’ s value of A overlaps with the range of A in q. If so, forwards the query and prepares to receive results. Otherwise, the query is not forward.

16. Dissemination and Routing Semantic Routing Tree The gray nodes participate in the query, while white nodes doesn’t.

17. Dissemination and Routing Semantic Routing Tree Building Semantic Routing Tree Flooding SRT building request. This request includes the name of the attribute A over which the tree should be built. Each node forwards the request to the children. The leaf node selects a parent, and reports the value of A to its parent. When a node heard from all of its children, it choose a parent and sends a selection message indicating the range of values of A which it and its descendents cover. The parent records this interval with child node id and proceeds to choose its own parent in the same manner, until root. SRT are limited to constant attributes, but maintenance is required.

18. Query Execution Prioritizing Data Delivery The radio queue of sensor node could be overflow, how to deal with this? Approach: prioritize data that need to be sent. Three simple prioritization schemes: Naive – no tuple is considered more valuable, just FIFO Winavg – average two results at head of queue when queue fills. Delta – each tuple is assigned a score relative to its difference form the most recent value successfully transmitted, delivery the tuple with the highest score first, discard the lowest when queue fills.

19. Query Execution Prioritization Comparison Sample rate was K times faster than delivery rate. In this example, K = 4

20. Query Execution Adapting Rates Adaption based on Network contention TinyDB monitors channel contention and adaptively reduces the number of packets transmitted as contention rises. Adaption based on Power consumption Goal: adapting tuple delivery rate to meet specific lifetime requirements. Approach: Compare current voltage to predicted voltage Re-estimate power consumption characteristics of device Re-run lifetime calculation to determine rates

21. Summary Discuss important aspects of an acquisitional query language, introducing event and lifetime clauses. Query optimization Ordering the sampling operators Event query batching Use semantic routing tree to disseminate query. Query execution Prioritizing data according to quality Techniques to adapt the transmission and sampling rate

22. Discuss Main Contribution: TinyDB and other early work are an important first step to investigate some Database research issues in Sensor Network. Provide simple extensions to SQL for controlling data acquisition. Proposed a series of acquisitional techniques which provide significant reductions in power consumption. Related Work: TAG (Tiny AGgregation Service) – UC Berkeley Cougar Sensor Database Project – Cornell Directed Diffusion – UCLA and ISI

23. Discuss (cont.) Future Work: Ordering exemplary aggregate in query optimization Better re-optimization of sample rate based upon acquired data More sophisticated prioritization schemes Mechanisms allowing users to express their prioritization preferences

24. References TinyDB http://telegraph.cs.berkeley.edu/tinydb/ Query processing challenges in sensor networks http://telegraph.cs.berkeley.edu/tinydb/tinydb_tutorial.ppt Query Processing For Streaming Sensor Data, Samuel R. Madden, Ph.D Quilifying Exam Proposal, May 2002 Fjording the Stream: An Architecture for Queries over Streaming Sensor Data, Samuel R. Madden, Michael J. Franklin, ICDE 2002 TAG: a Tiny Aggregation Service for Ad-Hoc Senser Network, Samuel R. Madden, Michael J. Franklin, etc., OSDI, Dec. 2002 Telegraph Research Project http://telegraph.cs.berkeley.edu/ Cougar http://www.cs.cornell.edu/database/cougar/

25. Appendix A stable release of TinyDB is included with the TinyOS 1.1 release. TinyDB provides a PC interface written in Java.

26. Appendix in the UC Berkeley Botanical Garden, 50 "micromote" sensors are dangled like earrings from the branches of 3 redwood trees to monitor their growth.

27. The Design of an Acquisitional Query Processor For Sensor Networks Thanks! Thanks!