Attributes of Queries

Queries form an essential part of any deployed WSN as they are wholly responsible for extracting all the data that is requested by the end-user. Queries may be actively injected into the network once the network has been deployed or they may be predefined within every node prior to deployment.

There are a number of attributes that are usually specified in a query and these attributes help decide how and which data needs to be collected. The manner in which the specified query attributes are processed can have a significant impact on the overall network lifetime.

Any query must have three user-defined attributes specified within it: (i) duration, (ii) scope, and (iii) result. Figure . gives an overview of the various attributes. We now describe every attribute in greater detail.

. Duration: This attribute indicates for how long a particular query needs to return results to the user. Typically, there are two possible options. Either the user requires a snap-shot of the sensor readings in the network at a particular specified time instance or the user needs data to stream in from the sensors periodically for an extended duration. Queries running for an extended duration are referred to as long-running queries. Note that the duration refers to the time period after data collection begins. Thus for event-based queries which request for data only when a particular event occurs, the “duration” attribute refers to the time after the event has occurred.

. Scope: A user may not always require data to be collected from all the sensors in the network at all times. Instead, one may limit the scope of the query by specifying certain spatial, temporal, or sensor-based constraints. Queries with such constraints are known as range queries. For example, readings may be requested only if the sensor readings go

Richard Zurawski/Networked Embedded Systems K_C Finals Page  -- #

Architectures for Wireless Sensor Networks 4-19

TABLE.ASummaryofDistributedDataExtractionTechniquesforWSNs Characteristics EssentialConceptualFeaturesPlatform NameoftheProject/In-NetworkAcquisitionalQueryCross-LayerData-CentricQuery/ MechanismAuthorProcessingProcessingOptimizationDataDisseminationSimulationMote-ClassPDA-ClassPC-Class Directeddiffusion[]Usesfilters××Publish/subscribeapplica- tionprogramminginter- face(API)basedonnamed data

✓✓ Suppressionof duplicatemessagesGradientsusedtoroutedata fromsourcetosink Cougar[]Aggregationatcluster leaders×××✓ Packetmerging TinyDB[]Evaluationof operatorssuchas MIN,MAX,COUNT, AVERAGE,etc.

Centralizedquery optimizationbasedon collectedmetadata Communication schedulingprimarily forupstream dataflow Semanticrouting✓✓ Prioritygiventocheapest sensorwhenevaluating multiplepredicates

Nodesabletodecideon schedulethemselves usinghopcount Designedforrangequeries Multi-queryoptimization: Groupingofmultiple identicalevents

Minimizesburden onMACMaintenancealgorithm maybetoocostlyif measuredattribute changestoorapidly Schemeunusablefor multipleconcurrent querieswithdifferent epochrequirements Bonfilsetal.[]Decentralizedquery operatorplacement×××✓ (continued)

Richard Zurawski/Networked Embedded Systems K_C Finals Page  -- #

4-20 Networked Embedded Systems

TABLE.(continued) Characteristics EssentialConceptualFeaturesPlatform NameoftheProject/In-NetworkAcquisitionalQueryCross-LayerData-CentricQuery/ MechanismAuthorProcessingProcessingOptimizationDataDisseminationSimulationMote-ClassPDA-ClassPC-Class TiNA[]Exploitstemporal correlations×××✓ Readingstransmitted onlywhenuser- specifiedthreshold isexceeded Deligiannakis etal.[]Transmitsapproxi- matedreadings generatedusing basesignals

×××✓✓ WaveScheduling××Nodesscheduledto minimizeMAC collisions

×✓ Savesenergy,but increaseslatency Comanetal.[]×××Queriesforwarded basedonspatial andtemporalranges

✓ REED[]Joinsbetweenstatic, externaltables,and sensornodes

×××✓✓ BBQ[]×Minimizesamplingby predictingsensor readingsusingcentralized statisticalmodels

××✓ Identifytemporaland spatialcorrelations Ken[]Nodeskeeplocal modelsynchronized withcentralmodel

×××✓ Abletodetectoutliers

Richard Zurawski/Networked Embedded Systems K_C Finals Page  -- #

Architectures for Wireless Sensor Networks 4-21

TD-DES[]××Eventschedulerdynamically allocatesandmultiplexes upstreamanddownstream timeslotsforeachevent type

×✓ Rootworksoutschedule DTA[]××DTAdefinesrulescontrolling orderofdatatransmission×✓✓ Rootworksoutschedule AI-LMAC[]××AdaptsoperationofMAC basedonrequirementsof application Directsqueriesonlyto relevantpartsofthe network

✓ Distributedbandwidth allocationbasedon expectedtrafficfor aparticularquery

Queriesdirectedbased onattributename andvalue MACoperateswithlow dutycycleininactive areasofnetwork GHT[]×××Hashesattributename intogeographic coordinates

✓✓ Nodesmustbelocation aware Usesperimeterrefresh protocoltoimprove robustness Usesstructuredreplication toeliminatebottlenecks duringoccurrenceof multipleidenticalevents (continued)

Richard Zurawski/Networked Embedded Systems K_C Finals Page  -- #

4-22 Networked Embedded Systems

TABLE.(continued) Characteristics EssentialConceptualFeaturesPlatform NameoftheProject/In-NetworkAcquisitionalQueryCross-LayerData-CentricQuery/ MechanismAuthorProcessingProcessingOptimizationDataDisseminationSimulationMote-ClassPDA-ClassPC-Class DIFS[]×××Supportsrangequeries✓ Hashesattributename andvalueinto geographiccoordinates Nodesmustbelocation aware Doesnotdealadequately withnodefailuresand packetlosses DIM[]×××Supportsrangequeries✓✓ Hasheseventtoazone Nodesmustbelocation aware Reassignszoneswhen nodesenterorleave ACKschemeimproves robustness DOSA[]Aggregatesdataby takingadvantageof correlationsof sensorreadingsof adjacentsensor nodes

××Publish/subscribeAPI basedonnameddata✓✓ Gradientsusedtoroute datafromsourcetosink

Richard Zurawski/Networked Embedded Systems K_C Finals Page  -- #

Architectures for Wireless Sensor Networks 4-23

Query attributes

Scope

Duration Result

Snapshot Long-running Range All Raw Aggregated

FIGURE . Attributes specified within a query.

above a certain threshold, or if a sensor is located in a specific area or at a particular time of the day. These constraints may also be specified in various combinations. Note that

“scope” may not necessarily be a static parameter such as location or sensor type. It could be a dynamic parameter as well such as temperature. For example, if we consider a static network in an outdoor environment, a query that requires temperature readings from a particular region will always result in readings coming from the same part of the network regardless of the time of the day. However, if a user requires humidity readings only if the temperature goes above a particular threshold, the query might result in different sets of sensors returning readings depending on the time of the day. Event-based queries make use of the “scope” parameter as they make use of the temporal constraint, i.e., instead of returning data all the time, data is sent to the user only when a particular event occurs.

Conversely, a user may require all the readings from the network.

. Result: The “result” attribute refers to the format of the data that is requested by the user.

The data can either be in “raw” format—in which case the user requires every reading sampled by the sensors chosen by the “scope” attribute, or the user may require aggregated data, e.g., the average of all the chosen sensors.

Table . gives an overview of how the some of the significant projects/papers in the field of dis-tributed data extraction address the three attributes described above. Note that the table illustrates which attributes the particular method is specifically designed for. For example, we have stated in the table that TinyDB supports snap-shot queries. However, in reality, TinyDB can also accept long-running queries. But the optimizations built into TinyDB are specifically geared toward snap-shot

TABLE . A Summary of How Query Attributes Are Managed by Different Projects

Duration Scope Result

Name of the Project/Mechanism/Author Snapshot Long-Running Range All Raw Aggregated

Directed diffusion [] ✓ ✓ ✓

Richard Zurawski/Networked Embedded Systems K_C Finals Page  -- #

4-24 Networked Embedded Systems

queries. We advise the reader to refer to this table while reading Section .. which provides details of the various projects/papers.