1. An Integration Framework for Sensor Networks and Data Stream Management Systems

2. Outline Introduction Architecture Query Optimization Demonstration Highlights Conclusion

3. Introduction (1/3) Query optimization can reduce sensornet power consumption and increase the primary sensor performance. To further improve both the power efficiency and utility of sensor network query-processing systems(SNQPs) by their integration with one of several streaming database systems, such as STREAM, TelegraphCQ, or Aurora, commonly referred to as data stream management systems (DSMSs).

4. Introduction (2/3) By integrating the two query processing systems, the optimization goals of the sensor network (primarily power) and server network (primarily latency and quality) can be unified into one quality of service metric. Demonstrates an integrated query processing environment where users can seamlessly query both a data stream management system and a sensor network with one query expression.

5. Introduction(3/3) This integration offers three major benefits: The ability to combine stored or streaming data from the DSMS with data from the sensornet. A single, integrated interface for interacting with both the streaming database and the sensor network. The ability to optimize between the database system and the sensor network. - to push certain filters and aggregates into the sensor network if user queries are interested in only particular subsets or coarse summaries of readings.

6. Architecture(1/6) allows the sensor network to communicate its processing capabilities and constraints, along with descriptions of the data it can produce to the DSMS. provides a way to resolve contrasting optimization goals of sensor networks and DSMSs. It is sufficiently general so that future efforts to integrate other forms of data sources with DSMSs can be worked into the same architecture.

7. Architecture(2/6) The fundamental idea behind the integration architecture is to place a proxy intermediary at each interface between sensor networks and instances of the DSMS. Proxy : make the sensor network appear to the DSMS instance as if it were another instance running on a different site. The DSMS can then move operators and stored relations across the server/sensor boundary with the same ease as if it were moving across server/server boundaries.

8. Architecture(3/6)

9. Architecture(4/6) The proxy has three primary functions. These functions are performed by the proxy for all connected sensor networks. it gathers statistics about constraints of connected subnetworks so that it can reject proposals from the DSMS to move operators or stored relations into the network (or change the parameters of operators already in the sensor network) if it accepts an operator on behalf of the sensor network, it selects the appropriate implementation of the operator. it works with the DSMS to optimize the query

10. Architecture(5/6) The proxy interacts with its sensornets using a wrapper for each network. The wrapper : Provide a standardized API to integrate the connected sensornets into the optimizationprocess. includes a set of meta data which describes the related sensornet. All additional data sources to the DSMS are connected through it.

11. Architecture(6/6)

12. Query Optimization(1/3) Query optimization across a DSMS-sensor network integration faces three primary challenges. The processing capabilities of the sensor network is much smaller than the capabilities of the DSMS and thus only a subset of potential query plans In contrast to a DSMS, in a sensor network the same operator will be run on multiple nodes

13. Query Optimization(2/3) A DSMS and a sensor network have different and potentially conflicting goals. Solve: by aggregating sensor network constraints into one lifetime metric and supplement DSMS QoS with an additional dimension to optimize. The lifetime of a query is equal to the minimum of the lifetimes of all data sources of this query. (Lifetime can be thought of as a fixed amount of service the DSMS has bought from the sensor network.) When the service runs out, no data will be produced for the query.

14. Query Optimization(3/3) The more work the query requires of a sensor network, the faster the fixed amount of service is used. This allows the DSMS to choose in which direction of the power/latency/quality trade-off to optimize using application QoS functions.

15. Demonstration Highlights This demonstration shows a simulated factory environment with temperature sensitive construction phases. A continuous query is desired that joins aggregate temperature readings from sensors located at various positions in the factory with a time-indexed relation that encodes the desired temperature range.

16. Demonstration Highlights

18. Conclusion Integration of these systems to create a unified query plan that will execute across DSMS/sensor boundaries is not a trivial task because of the different architectures and assumptions of these systems. Demonstrate a successfully integrated sensor network and DSMS where user queries can be run and optimized across these heterogeneous query processing components.

19. A Distributed System for Answering Range Queries on Sensor Network Data

20. Outline Introduction Data Representation Range Query Distributed Framework Query Plan Future Work

21. Introduction (1/2) A distributed architecture for storing sensor network data and supporting fast approximate (aggregate) query answering Data are stored in a compressed form Provides approximate query answers Accuracy of answering becomes less relevant when data becomes older

22. Introduction (2/2) Each node can stored a (compressed) snapshot of data represented into other nodes, which is update periodically The possibility of storing the same information into different nodes of the system improves the efficiency in the query answering Queries can be evaluated by partitioning them into sub-queries and by submitting each sub- query to a different node

23. Data Representation (1/3)

24. Data Representation (2/3) An order set of n sources producing n independent streams of data Data stream sequence

25. Data Representation (3/3) Raw data Raw data Raw data Raw data Comp. data Comp. data Comp. data

26. Range Query (1/2) A range query is a pair Assumption that the sensors in the network can be organized according to a linear ordering The mapping should be closeness-preserving If a meaningful linear ordering of sensors cannot be found, the model can be extended to a three- dimensional setting

27. Range Query (2/2) Querying compressed data stream Give a sum range query Q The answer can be obtained by where and intersects Q

28. Distributed Framework (1/2)

29. Distributed Framework (2/2) Updating compressed data The snapshot agent accesses the snapshot catalog to check which pairs have a snapshot contract snapshot contract Frequency of updates Compression ratio …

30. Query Plan (1/2)

31. Query Plan (2/2) Bounds the number of SSD to be accessed Avoids overloading server Avoids accessing SSD whose Usage percentage too large Avoid congestion occurs, where either too Many servers are involver or some server are overloaded

32. Conclusion Provides flexible answers by issuing queries and guarantees the desired of the client fast accuracy

33. Future Work The system is under construction Defining ad-hoc techniques to solve optimization problem

34. Compare InterfaceDatabaseData TypeOptimizationContinuo us Query Integration Framework proxyDSMSstreamBased on sensor(life time) Support Distributed Framework Data dispatcher DBMSArray and compressed data Based on system Not support