A Survey of Wireless Sensor Network Data Collection Schemes

1. A Survey of Wireless Sensor Network Data Collection Schemes by Brett Wilson

2. The Problem • How do you reliably and efficiently collect specific sensor data from a Wireless Sensor Network (WSN)? • Limited processing and storage at each node • Inherently “lossy” network links • Extreme power consumption constraints

3. Three Approaches • TinyDiffusion • UCLA • In use collecting environmental data at James Reserve • API provided with which developers can build applications • TinyDB • UC Berkeley • Complete, ready to use “out of the box” • Major goal is to abstract away all the technicalities • User submits simple “SQL-like” queries • Cougar • Cornell • Research project formulating concepts and testing ideas • Working system not yet built – only tested in simulations

4. Architecture Overview • TinyDiffusion • Data requests/responses consist of sets of attributes of the form key, op, value (photo GT 123) • Nodes express interest in data through “subscriptions” • Flood interest msgs throughout network • All nodes save information about received interests in a cache • Nodes express availability of data by “publishing” attributes • e.g. Photo IS 125 • When an interest msg is received, a node attempts to match it to its published attributes • If data that meets the subscription is found, a response msg is sent back along the path from which the interest was received • Uses interest cache for routing • Filters can intercept data msgs and perform aggregation • No underlying network layer (it IS the network)

5. Architecture Overview • TinyDB • User queries network using connected PC • Requests are made using SQL-like declarative language (what I want, not how to get it) • SELECT roomno, AVG(light), AVG(volume) FROM sensors GROUP BY roomno HAVING AVG(light) < l AND AVG(volume) < v EPOCH DURATION 5min • Query Optimizer processes request and generates optimal data retrieval plan • Uses known capabilities of nodes and network topology • Optimizes communications and in-network computation • Query Plan distributed to only those nodes identified in the optimization • Uses underlying network layer to form “network tree” • Network layer required to provide specific interface to TinyDB

6. Architecture Overview • Cougar • Research into using declarative languages to extract data from sensor networks • No working application yet developed • Some ideas have been tested using simulation • TinyDB implements many of the concepts being explored in the Cougar project • Many opportunities for further research • Query processing/optimization • Metadata management • Integrating use of filters • Distributed triggers

7. Advantages/Disadvantages • TinyDiffusion • Highly efficient, small memory footprint • Only API provided, no “out of box” functionality • Significant development effort required to assemble an application • TinyDB • Ready to use in standard mica mote networks • User enters simple SQL-like queries into base station PC • High degree of optimization possible • Requires modification of underlying network layer or development of a “wrapper” around layer to provide required functionality • Cougar • Exploratory research into declarative language data extraction