Toward adaptive query processing in wireless ... - Semantic Scholar

ARTICLE IN PRESS

Signal Processing 87 (2007) 2911–2933 www.elsevier.com/locate/sigpro

Toward adaptive query processing in wireless sensor networks Angelo Braynera, Aretusa Lopesa,, Diorgens Meiraa, Ricardo Vasconcelosa, Ronaldo Menezesb a

Mestrado em Informa´tica Aplicada, Universidade de Fortaleza (UNIFOR), Brazil b Department of Computer Sciences, Florida Institute of Technology, USA

Received 1 September 2006; received in revised form 16 February 2007; accepted 15 May 2007 Available online 25 May 2007

Abstract A wireless sensor network (WSN) consists of groups of spatially distributed networked sensors used to cooperatively monitor physical environmental conditions. These sensors are usually strongly resource constrained; hence the network makes use of base stations—nodes with robust disk storage, energy and capacity of processing. In a WSN, collected data are passed from sensor to sensor until the base station is reached. A query-processing mechanism for WSNs should be able to handle common conditions such as failures, resource limitations (e.g., energy and memory), the existence of large amounts of data streams and mobility of the sensors. An efficient strategy for dealing with such conditions is to introduce adaptability when processing queries. Adaptive query engines and query operators (algorithms) can adjust their behavior in response to conditions (e.g., less energy, memory availability), which may occur when processing queries. In this paper, we propose an adaptive query processing mechanism for WSNs. In order to achieve this goal, we (i) propose a generic data model to enable logical views over data streams so that the proposed query engine can see tuples of virtual relations (rather than raw data streams) flowing through the WSN; (ii) introduce a SQL-like query language, called Sensor Network Query Language (SNQL), which enables users to express declarative queries and dynamically change parameters in queries’ clauses; and (iii) propose two adaptive query operators, called ADAGA (ADaptive AGgregation Algorithm for sensor networks) and ADAPT (ADAPTive join operator). ADAGA is responsible for processing in-network aggregation in the sensor nodes whereas ADAPT processes join operations in the base station of a WSN. Both operators are able to dynamically adjust their behavior according to memory and energy usage in sensor nodes (ADAGA) and in the base station (ADAPT). Experimental results presented in this paper prove the efficiency of the proposed query mechanism. r 2007 Elsevier B.V. All rights reserved. Keywords: Wireless sensor networks; In-network aggregation; Declarative query languages

1. Introduction

Corresponding author.

E-mail addresses: [email protected] (A. Brayner), [email protected] (A. Lopes), [email protected] (D. Meira), [email protected] (R. Vasconcelos), rmenezes@cs.fit.edu (R. Menezes).

Sensors are devices used to collect data from the environment related to the detection or measurement of physical phenomena. Sensors are limited in power, computational capacity, and memory. In general, wireless sensor networks (WSNs) consist of groups of these sensors where each group is

0165-1684/$ - see front matter r 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.sigpro.2007.05.017

ARTICLE IN PRESS 2912

A. Brayner et al. / Signal Processing 87 (2007) 2911–2933

responsible for providing information about one or more physical phenomena (e.g., group for collecting temperature data). Such groups use the WSN to disseminate the data collected from the monitored geographic regions. WSNs are mainly characterized by: (i) having a large number of sensor nodes; (ii) generally using broadcast communication; and (iii) having their location frequently changed [1]. A common organizational structure for WSNs consists of groups of sensors sending data to a base station (sink node) that has robust disk storage, no energy restrictions, and high processing capability [18]. We consider a network scenario where a base station receives data from groups of sensors scattered in the network. Sensors and base stations are organized as a typical scale-free network with a base station as the hub node of a set of sensors. In this model, each sensor has the capacity to aggregate local and incoming data (from other nodes) in such a way that data packets are passed from sensor to sensor until they reach a base station. A query-processing mechanism for WSNs should be able to adapt to conditions such as failures, resource limitations (e.g., energy, memory), the existence of large amounts of data streams, and mobility of the sensors. In order to deal with such a scenario, we introduce adaptability by making the query engine and physical query operators (algorithms that implement algebraic operators, such as join and aggregation) able to adjust their behavior in response to specific events (e.g., less energy, memory availability) common in WSNs. In this paper we first specify a generic data model for WSNs that allows a logical view over data streams handled by the system. Hence, applications can see data flowing through a WSN as tuples of (virtual) relations. Additionally, the proposed data model provides support for expressing declaratives queries based on that logical view. The definition of declarative queries based on data models frees the users from the physical details such as identifying relevant sensors for a given query or applying optimization rules to reduce the volume of transmitted packets aiming at minimizing power consumption by sensors of a WSN. Second, a SQL-like query language, denoted Sensor Network Query Language (SNQL), is described. SNQL provides the necessary support for the specification of declarative queries for WSNs. We argue that SNQL gives more flexibility to WSN applications because (i) users can control

the data volume and the precision of the results by defining parameterized features (clauses) in advance; (ii) users may change clause values on-thefly (i.e., during the query execution); (iii) continuous queries (a given query may be executed continuously in time) are supported; and (iv) it supports predefined queries (injection of the same query into the system several times—each time a new query instance is performed). Third, an adaptive query engine is proposed. As we show, the proposed query engine distributes the cost of executing a given query over the base stations and sensor nodes of a WSN. The idea is to process a query in four distinct phases: parsing, query decomposition, fragment execution, and postprocessing. The parsing, query decomposition, and post-processing phases are executed in the base station. The fragment execution phase is executed in sensor nodes (leaf or intermediate) of a WSN. Query-processing operators for WSNs should be able to handle conditions in these networks such as failures, resource limitations, the existence of large amounts of data streams, and mobility of the sensors. Adaptability has been explored by database community as an alternative to for processing queries over data streams. Adaptive query operators can adjust their behavior in response to specific events that may occur when processing a given query [2,17]. However, existing adaptive query operators present high consume rates for computational resources such as memory and energy. In this paper, we propose two adaptive query operators, which can adapt their executions according to memory or energy availability. One operator, called ADAGA (ADaptive AGgregation Algorithm for sensor networks), has the capability of processing in-network aggregation [6,8,15] in sensor nodes of a WSN. Observe that WSNs usually have a large number of sensor nodes, where each sensor node has different memory and energy availabilities. ADAGA is an adaptive strategy to dynamically adjust sensor activities (data sending and data collection), by monitoring energy consumption and memory usage, in order to maximize sensor node lifetime and also the accuracy of query results, mainly when sensor nodes experience energy or memory constraints. The goal is to make sensor nodes self-configurable devices by proactively monitoring the resource usage. The second query operator, denoted ADAPT, is a join operator, which is able to react to events that may considerably increase response time when

ARTICLE IN PRESS A. Brayner et al. / Signal Processing 87 (2007) 2911–2933

processing join operations. ADAPT has the following properties: (i) Incremental production of results as soon as the data become available. Conventional join operators produce results when at least one involved relation is completely evaluated. Joins executed over distributed data may have to wait until users begin to receive the result from the join operation. ADAPT uses a pipeline technique to incrementally provide results (to users or to another query operator) as soon as they became available. (ii) Progress of the query processing even when the delivery of data is blocked. Conventional join operators are implemented in a stop-and-go way—they have more than one phase executed sequentially (for example, the build and probe phases of hash join). Hence, delay on initial stages causes performance degradation on the execution of such operators. The idea is to overlap delays by executing other tasks when collected-data delivery is blocked; (iii) Reaction to memory-overflow events. When a memory overflow occurs, ADAPT triggers a memory-management policy consisting of flushing part of the data from main memory to disk. This paper is organized as follows. Section 2 briefly describes an abstract model of a WSN we are assuming in this paper. Section 3 presents the proposed data model and query language SNQL. Section 5 addresses the issue of performing query processing in WSNs. Section 6 presents and evaluates the ADAGA and ADAPT operators for query processing in WSNs. In Section 7, we discuss the related work. Finally, Section 7 concludes this paper. 2. Wireless sensor networks Generally speaking, sensors are battery-powered devices used in applications for monitoring specific events (e.g., an animal movement) or collect information about some environmental properties (e.g., pollution levels). They are particularly important for applications with little or no human interventions (e.g., monitoring deep oceans currents). Some premises are usually admitted for sensors [1]: (i) they have limited energy, computation, and storage capabilities; (ii) they have a simple

2913

architecture consisting of a sensing unit, a processing unit, a transceiver unit, and a power unit; (iii) they collect only one or very few types of data; (iv) they are prone to failures, but these failures should not strongly affect application results; and (v) they usually broadcast data by means of radio transmissions. It is important to note that the sensor node lifetime is extremely dependent on the available energy in its battery. There are three domains to be considered in energy consumption [1]: (i) sensing activity (data collection from the environment), which is the primary goal of a sensor; (ii) communication (sending and receiving packets), which is essential to form a WSN; and (iii) data processing, which consists in some operations applied over data by smart sensors [4,6]. Even though all these activities consume energy, communication is responsible for the bulk of the power consumption thus being the main point of attention in algorithms designed for sensors—save energy by reducing the communication activity [6], which consequently increases the WSN lifetime. A common architecture proposed for WSNs is based on the distribution of sensor nodes in a geographical area in such a way that sensors send collected data to a base station (a hub) by using multi-hop routing protocols. Usually, these approaches organize sensors in routing trees [5,7,8]. In this paper we assume a scale-free network topology, in which sensors are categorized by their sensing activities (e.g., temperature collection). A set of sensors with the same sensing activity forms a sensor group. It is important to note that sensor nodes that have N different sensing activities will be categorized in N different sensor groups. For simplicity and without losing generality, we consider a WSN consisting of just one base station and several sensor nodes. The generalization of this architecture would be to link base stations by transmission media in order to guarantee network scalability. Nevertheless, there is a base station, in which a query is injected into the system and to where results are generated. A simplified scale-free network is organized as described in Fig. 1. 3. Expressing declarative queries in WSN applications In order to illustrate the use of the data model and SNQL, let us consider the following running example. An application consisting of an environmental



Fig. 1. A scale-free wireless sensor network. The three types of nodes: Base station: It is a robust node (in Level 0) that organizes the network topology, distributes queries to sensors, receives data sent by sensors, and returns results to users. Intermediate nodes: They are distributed in a geographical area in intermediate levels of the network (e.g., Level 1). These nodes collect data from the environment, receive data packets from other nodes (parent nodes), process in-network aggregation and send data to closer nodes, which are their parents. Several intermediate levels may exist in a scale-free network. Leaf nodes: These sensors are situated in the outmost levels of the network (from the base station). They collect data from the environment, process innetwork aggregation, and send data packets to their parents.

biocomplexity mapping relates data about temperature, pressure, and humidity coming from sensors that are spatially distributed in an environment. The application has the goal of obtaining the so-called Heat Index or THIndex. The Heat Index is a relation between temperature and humidity which has the purpose of studying health risks caused by such combination, since the higher the value for THIndex, the higher the risk of heat stroke. For example, if the temperature sensors register a temperature higher than 20 C and, at the same time, a high value of humidity, the Heat Index will be higher than the air temperature itself—in this case, higher than 20 C. We assume that all sensors in the network have similar (initial) capacity of processing, memory, and battery power; and that all nodes are already organized in a scale-free network.

this, applications can see data flowing through a WSN as tuples of (virtual) relations. The data model abstracts the user from physical details such as identifying relevant sensors for a given query (i.e., querying data from an specific geographical region) [9], identifying data to be processed in sensor nodes or in the base station, and applying optimization rules to reduce the volume of transmitted packets, which minimizes the traffic in the network, and consequently power consumption. Each sensor group is represented by a specific relation (SensorGroup1, SensorGroup2,y, SensorGroupN) and has attributes related to the monitored phenomenon. A sensor can monitor more than one phenomenon (e.g., temperature and pressure). Consequently, a sensor may belong to different sensor groups. This data model captures the information about geographical areas by means of the SensorRegion relation (see Fig. 2), which contains an attribute (regionId) as an identifier for the delimited geographical area where a set of sensors collects data. This attribute is common to all relations, thus it allows information generated by different sensor groups be related through geographical areas (regions), where each region may have sensors belonging to different groups (see Fig. 2). Fig. 3 shows an instantiation of the proposed data model for the running example. It is important to note that temperature, humidity, and pressure are in fact virtual tables seen over data stream flowing through the WSN. Observe that each relation has information related to the physical phenomenon represented, e.g., temperature has information about the geographical area where the data were

3.1. Data model The effectiveness of the data model is illustrated by applying it to the aforementioned running example. As already said, the key goal of using the proposed data model is to allow a logical view over data-streams dealt by the system. By doing

Fig. 2. Generic data model for WSN applications.


Fig. 3. Instantiation of the generic data model for the running example.

collected (regionId), the measured temperature value (collectedValue), the number of collections performed (sampleAmount), and the considered scale (scale, which identifies if the measurement is made in Celsius or Fahrenheit degrees, for example). The SensorRegion relation has attributes to represent the properties of each region (see Fig. 3). 3.2. SNQL SNQL includes five features for expressing and processing queries in WSNs. First, users can express declarative (ad-hoc) queries. Second, users can control the data volume and the precision of the results by previously defining parameterized features. Third, it supports continuous queries [4,14]; that is, the results are continuously collected, updated, and sent back to the users. Fourth, users are able to deal with the notion of a predefined query, which means that the same query is continuously re-injected into the system in predefined periods. Finally, SNQL defines statements to adjust clause values of submitted queries, previously injected into the system, on-the-fly. Sensors and the base station use the Time Window and Data Window clauses in order to know when they should stop a query execution. The predefined value Continuous in the Time Window clause specifies a continuous query. In this case the query is executed for an indefinite period of time and results are continuously updated. The Sense Interval clause specifies the interval between consecutive data collections. High values

2915

for that interval means that less data will be collected and consequently results will be less precise. On the other hand, low values for Sense Interval produce more precise results since a larger sample will be collected, but this scenario also means more data processing and more data being stored in memory. The Send Interval clause value should also be carefully defined, since it impacts memory usage. If its value is high, more data should be stored in sensor nodes, which increases the chance of memory overflows. But low values may produce larger amounts of small packets, increasing data traffic and also making sensors waste more energy. In summary, the values for the Sense Interval and Send Interval clauses directly influence network performance and sensors’ lifetime (see Table 1). The Schedule clause works by allowing users to specify a number of times and the periodicity in which a query should be injected into the system. For instance, 2 ‘10-oct-05 14:00:00’, ‘15-oct-2005 14:00:00’, means that the query will be executed two times in the specified date and time, which results in two query instances. The predefined value Continuous forces the query to be executed an indefinite number of times. In this case, at the end of each query instance execution, all materialized data in the base station is discarded and new data materialization starts. Fig. 4 shows the following query in SNQL: Find what is the maximum temperature value and the correspondent minimum humidity value in the following delimited geographical region: 3 430 0800 S238 310 5100 W and 3 430 1600 S238 310 1400 W. Focus temperature values greater than 20 C and humidity values smaller than 0.7. The query should be injected into the system twice (in 10-oct-05 at 14:00:00 and in 15-oct-05 at 14:00:00), each time it might stay executing for 3600 s. Data should be collected each 10 s and sent to the base station each 120 s. SNQL also defines statements to adjust (on-thefly) the following clause values: Time Window, Data Window, Sense Interval, Send Interval, and Schedule. Thus, SNQL makes possible to inject a query fragment into the system (WSN) that informs a new value for any of those clauses. It is possible to inject a message into the system that informs the clause to be changed and the value it has to be changed to (e.g., new Sense Interval 60). The Time Window and Data Window clause values can be changed at any time before the query execution ends. The Schedule clause value can be changed


2916 Table 1 SNQL clauses Clausesa

Specification

Select fhexprig

hexpri: It specifies a subset of the attributes in the original relations From fhsensor groupig hsensor groupi: It specifies the considered sensor group [Where fhpredig] hpredi: It specifies a set of predicates which filters processed tuples [Group by fhexprgroupig hexprgroupi: It specifies a subset of [Having fhpredhavingig]] attributes in which aggregate functions are based. hpredhavingi: It specifies predicates, based on aggregate functions, to filter aggregated results Time Window htwsecondsij htwsecondsi: It defines the time Continuous interval in which a query is valid to the system (e.g., 3600 s). ‘Continuous’ means that the query validity time is infinite. [Data Window hdwnumrowsi: It specifies an exact hdwnumrowsi] amount of data to be collected SendInterval hsndsecondsi hsndsecondsi: It specifies the interval between two consecutive sending of packets (e.g., 120 s) Sense Interval hsnssecondsi hsnssecondsi: It specifies the interval between two consecutive data collection (e.g., 10 s) [Schedule hnumexecutionsi hnumexecutionsi: It defines the ½fdatetimegj Continuous] number of times a query is injected into the system. If this number is greater than 1, a set of date and time values must be informed to determine when executions should occur (e.g., 2 ‘10-oct-05 14:00:00’, ‘15-oct-2005 14:00:00’). Continuous means that the query has to be injected into the system an infinite number of times. Each time a different query instance is considered. a

The symbol fg denotes a set, ½ denotes optional clauses, hi denotes an expression, xjy denotes that x or y can be used.

after the end of the current query instance execution. The Sense Interval and Send Interval clause values can just consider new values after the current interval finishes. It is important to note that values for the Sense Interval and Send Interval clauses can be dynamically adjusted by ADAGA (see Section 5.1). 4. Processing queries over WSNs According to the proposed query engine, a query is processed by four distinct phases: parsing, query decomposition, fragment execution and post-processing. Fig. 5 depicts an abstract model of the proposed query engine for processing queries in WSNs. When a user injects a query (Q) into the system (Fig. 5), the query is parsed and decomposed into fragments (sub-queries q1 and q2 in Fig. 5) according to the decomposition criterion. Subqueries are then sent to sensors through the WSN in order to execute the fragments. When a sensor (e.g., A) receives a packet from the same sensor group (fact represented by + in Fig. 5), the data in this packet are filtered and aggregated with locally collected data, but if a packet belongs to another sensor group ð#Þ, it is just forwarded to the parent nodes. Finally, a final processing is performed in the base station and results are produced to users. 4.1. Parsing When a user injects a query Q, the parsing component (running at the base station) parses Q in order to verify if the submitted query represents a valid expression for SNQL and the defined global data schema. Recall that we propose a generic data model (Section 3.2) for allowing a relational view over data streams flowing in the WSN. Thus, the query engine ‘‘sees’’ data streams as sequence of

SELECT r.regionID AS GeographicalRegion, MAX(t.collectedValue), MIN(h.collectedValue) FROM Humidity h, Temperature t, SensorRegion r WHERE r.regionID=t.regionID AND r.regionID=h.regionID AND r.initialLatitude>034308 AND r.finalLatitude< 034316 AND r.initialLongitude>383151 AND r.finalLatitude20 AND h.collectedValue < 0.7 GROUP BY r.position TIME WINDOW 3600 SEND INTERVAL 120 SENSE INTERVAL 10 SCHEDULE 2 ‘01-jan-06 14:00:00’, ‘15-jan-06 14:00:00’ Fig. 4. SNQL query.


2917

Fig. 5. Approach for query processing over WSNs.

tuples (ordered by time) belonging to relations, where each relation represents in fact a set of sensors having the same sensing activity (sensor group). Furthermore, the parsing component has the functionality of generating a query execution plan (QEP). The generated QEP is represented by an operator graph, whose nodes represent algebraic operators of relational algebra (such as join, selection, projection, and aggregations) or sensor groups represented in the global schemas by the notion of relations. The edges represent the data flow between nodes. The nodes may have attributes which can be used by other components of the query engine, such as data locality (sensors belonging to the same sensor group may be spread over different geographical regions) and selectivity factor. Fig. 6 depicts the QEP plan for the query in Fig. 4. Observe that the QEP (produced by the parsing phase) has operations over global relations (data streams produced by different sensor groups). Clearly, the next step is to decompose that QEP to be executed in several different nodes of the WSN. 4.2. Query decomposition After the execution of the parsing phase, the query engine starts the execution of the query

decomposing component in the base station (see Fig. 6). The key functionality of this component is to decompose the QEP (produced in the parsing phase into sub-graphs). Each sub-graph corresponds to a query fragment (or sub-query) of the inject query Q. The decomposition criteria are based on the sensor group and locality. Thus, there might be fragments that should be executed by specific sensor groups (temperature or humidity, for example) or fragments which should be executed by sensors (of a sensor group) located in specific geographical regions (see the query depicted in Fig. 4). Fig. 7 illustrates the QEP for the query in Fig. 4 after the decomposition phase. In order to optimize query execution, reduction techniques are applied to the fragments before disseminating the query to the sensors. We have defined reduction techniques for projection, aggregation, selection, and join operations (of relational algebra). For each projection or aggregation operation in the original query Q (submitted by the user), the following rule is applied: (R1) projection or aggregation operations should be distributed over the fragments according to the attributes defined (by means of the global schema) for each sensor group (which corresponds to a relation). In the case of a selection operation,



Fig. 6. Parsing phase.

Fig. 7. Decomposition phase.

we have defined the following rule: (R2) if the selection condition refers to attributes of only one sensor group SG, the operation should be

executed by the fragment corresponding to SG. In the case of a join operation involving two different sensor groups, the following rule has to


be applied: (R3) the operation should be executed at the base station. After the initial query is decomposed into fragments, all fragments are disseminated to sensors. Each fragment is encapsulated in a packet in whose header there is the necessary information about the decomposition criterion (sensor group or locality). Thus, each sensor can evaluate received packets in order to accept and process sub-queries addressed to it according to the decomposition criterion. Considering that the submitted query uses the Time Window clause to specify its execution time, after the fragment dissemination, a timer is initialized to determine when data packet reception should be interrupted. Each sensor also initializes a local timer and starts query processing after receiving a fragment (sub-query). 4.3. Fragment processing The execution of this phase is distributed over several sensors (see Fig. 5) which may be leaf and/or intermediate nodes of the abstract model for a WSN depicted in Fig. 2. In-network aggregation operations are executed in intermediate nodes by means of the algorithm, denoted ADAGA, described in Section 5.1. It is important to note that ADAGA provides the necessary support for in-network aggregation. Thus, when a sensor (say for humidity) implementing ADAGA receives a packet from the same sensor group, the data in this packet are filtered (select operation) and aggregated with locally collected data, but if a packet belongs to another sensor group, it is just forwarded to other sensors. For example, consider the sensors A and C in Fig. 5 belong to the same sensor group, but sensor B belongs to another sensor group. When A receives a packet from C, the data in this packet are filtered (flow represented by # in Fig. 5) and aggregated with locally collected data, but it receives a packet from B to another sensor group (flow represented by ‘‘), it is just forwarded to the parent nodes. 4.4. Post-processing This phase is executed at the base station and has two basic functionalities: (i) to execute join (by using the ADAPT algorithm described in Section 5.2) and group by operations, and (ii) to provide the query result to the users.

2919

5. Adaptive query operators 5.1. ADAGA– ADaptive AGgregation algorithm ADAGA was designed for processing in-network aggregation in sensor nodes. Furthermore, this algorithm explores techniques in order to adapt its behavior according to memory and energy usage (very limited resources in sensor nodes). The goal is to achieve better approximate results in resource constraint situations. ADAGA presents the following features: (i) in-network aggregation; (ii) monitoring energy consumption and memory usage; (iii) better result approximation, and (iii) fault tolerance. 5.1.1. Algorithm ADAGA is executed in five sequential stages. Sensors, such as Mica Motes [6], are not able to perform parallel operations; others, such as mAMPS, can receive and send data simultaneously, but other operations also cannot be executed in parallel [10]. The proposed algorithm uses three logical data structures (lists) to temporarily store data: a receiving area, which stores received packets; a processing area, where data to be aggregated is stored; and a sending area, where packets to be sent to other nodes are stored. ADAGA also admits packet replication by adopting a routing strategy which progressively eliminates replicated packets, as they are passed though the network, in order to produce better approximate results (see Section 5.1.3). The routing strategy is presented in Section 5.3. The five stages of ADAGA are as follows (see Fig. 8): Stage 1: The key goal of the first stage is to control the other four stages of the execution. Basically, it has a sequence of nested loops, where the first one (line 1) is performed i times, where i is the number of query executions (defined in the Schedule clause); the second loop (line 3) specifies that each query has to be executed while the Time Window clause value is not reached; the third loop (line 6) specifies that the Send Interval clause value should not overtake the Time Window clause value. Stage 2: This stage is responsible for processing data temporarily stored in the processing area. In other words, it performs in-networking aggregation which consists of filtering data, according to query predicates, and aggregating similar data (packets generated by nodes from the same sensor group).


2920

Stage 1: Adaga (Sensor s, Query q) 1: For i = 1 to number of query executions do 2: initialize timerTimeWindow; 3: While timerTimeWindow < q.TimeWindow do 4: initialize timerSendInterval; 5: s.SenseInterval ← q.SenseInterval 6: While timerSendInterval < q. SendInterval do 7: initialize timerSenseInterval; 8: If timerSenseInterval < q. SenseInterval then 9: d ← collectDataFromTheEnvironment(); 10: processingArea ← d; 11: End if; 12: processData(); 13: End while 14: receivePackets (Sensor s); 15: sendPackets (Sensor s); 16: End for Stage 2: ProcessData() 1: 2: 3: 4: 5:

p1 ← get a packet from the processing area; p2 ← get a packet from the processing area; filter data in p1 and p2, according to predicates in the query; p3 ← agg(p1,p2); //apply aggregate function specified in the query //and generate p3 which substitutes p1 and p2;

Stage 3: MonitorResource(Sensor s, Query q) 1: 2: 3: 4: 5: 6: 7:

x1 ← s.getAvailableEnergy(); x2 ← s.getAvailableMemory(); a ← q.SendInterval; t ← q.TimeWindow; b ← q.SenseInterval; a´ ← s.SendInterval ← adaptSendIntervals ( x1, a , t ); s.SenseInterval ← adaptSenseInterval ( x2, b, a´ );

Stage 4: ReceivePackets (Sensor s, Query q) 1: For each packet in the receivingArea do 2: MonitorResource(s,q); 3: p ← get a packet from the receivingArea; 4: If p.sensorGroup = s.sensorGroup then ο 5: //p.amountOfCopies=n . of copies in the p header 6: If p.amountOfCopies = 1 then 7: processingArea ← p 8: End if 9: Else 10: sendingArea ← p; 11: End if 12: End for

Stage 5: SendPackets(Sensor s) 1: For each packet in the sendingArea do 2: p ← get a packet from the sendingArea; 3: c ← p.amountOfCopies; // registered in the p header 4: l ← get the number of local copies of p; 5: discard l - 1 copies of p; 6: n ← c - l; 7: register n in p header as the new number of p copies; 8: If n > 1 then 9: s´ ← parent of s, chosen randomly; 10: send p to s´; 11: Else 12: send p to all parents of s; 13: End if 14: discard p from the sendingArea; 15: End for

Fig. 8. ADAGA algorithm.

Stage 3: It is the responsibility of this stage the monitoring of energy and memory usage. This stage adjusts data collection according to resource availability (energy and memory) in order to produce results consistent with real results (when no resource constraint is faced). Section 5.1.2 describes the procedures adaptSendIntervalðx1; a; tÞ (line 6) and adaptSenseIntervalðx2; b; a0 Þ (line 7) in more detail. Stage 4: This stage deals with packets stored in the receiving area (line 3). If a packet and a sensor node, which received it, have the same sensor group (line 4), the packet is stored in the processing area in order to be aggregated with locally collected data (line 7), otherwise, the packet is stored in the sending area (line 10). Stage 5: It is responsible for sending packets to parent nodes. For each packet p stored in the sending area (line 1), this stage verifies the number of copies of p (c in line 3) in the packet header; and the number of local copies of p (l in line 4). The result value for n ¼ c l is obtained in line 6. Thus if n41 (line 8), the packet is sent to a randomly chosen parent (line 10), just as it happens in the

Gossiping approach [16]. Otherwise, it is sent to all parents (line 12). When each send interval is reached, data sensing is interrupted, the data stored in memory are packed and sent to parent nodes together with packets received from other sensor nodes. Data sensing resumes at the end of Stage 5. SNQL supports the following aggregate functions: Count, Sum, Max, Min, Average, and Median. Gray et al. [3] classify those aggregate functions in the following categories: (i) Distributive (Max, Min, Count, and Sum), (ii) Algebraic (Average) and Holistic (Median). In Distributive aggregates, the size of each partial result, obtained by applying an aggregate function in sensor nodes, is the same as the size of the final result calculated in the base station. For instance, when calculating the function Max, the size of any partial result is 1, which corresponds to the same size of the final result. For the Algebraic aggregate Average, the partial results obtained in each sensor node corresponds to the distributive functions Sum and Count, applied to the collected data. In this case, the final result for Average is produced in the base station. In Holistic


aggregates, all the data must be brought together to be aggregated by the base station, since no useful partial aggregation can be produced in sensor nodes. ADAGA implements all the aggregate functions belonging to the three aforementioned categories by applying the function aggðp1; p2Þ, specified in line 4 of Stage 2 (see Fig. 8). In order to show how ADAGA aggregates data with respect to different aggregate functions, let us look at the following scenario. Consider two sensor nodes, say A and B, belonging to the sensor group Temperature. Whenever nodes A or B receive a packet produced (and sent) by a node belonging to the sensor group Temperature, they open the packet and aggregate data transported by the packet with locally collected data, according to the aggregate function (specified in the query). Thereafter, they send the packets to the base station. Suppose that A and B produce packets pA and pB , respectively. Table 2 illustrates aggregated data by different aggregate functions in ADAGA. Observe that the size of a packet depends on the aggregate function specified in the query. For example, after the sensor node A has collected the values 20 220 221 (A might have received them from other temperature sensors or might have sensed them locally), the packet pA contains just the value for Sum (i.e., 61) and the value for Count (i.e., 3), if Average were the aggregate function specified in the query injected into the WSN. On the other hand, if Median were the specified function, the packet pA should contain the set f20 ; 20 ; 21 g of temperature values. 5.1.2. Monitoring sensor resources ADAGA acts in a proactive way, since it monitors energy and memory usage in order to dynamically adjust sensor activities to these resources availability (energy and memory). To achieve that goal, ADAGA works with two strategies: (i) adjusting the Send Interval clause, in case of energy constraints; and (ii) adjusting the Sense Interval clause, in case of

2921

memory constraints. These two strategies are implemented by applying the functions f ðvÞ and hðmÞ, which correspond to the adaptSendIntervalðx1; a; tÞ and the adaptSenseIntervalðx2; b; a0 Þ procedures (see Section 5.1), defined as follows. The first strategy uses a function f ðvÞ which adjusts the Send Interval clause value (d) according to energy availability (v). Since almost 50% of power consumption in a sensor node occurs due to communication activities (sending and receiving data) [6], energy is a critical resource to sensors. For that reason, ADAGA may delay the sending of packets in order to save energy and increase sensor lifetime. In other words, ADAGA chooses to increment the value of Send Interval in order to reduce the frequency of packets transmission. This when applied to the entire network yields a smooth degradation of the network capabilities. Fig. 9 shows how the value for the Send Interval clause is incremented according with energy availability, v. The function f ðvÞ varies from the minimum, which correspond to the value, d, defined in the Send Interval clause, to the maximum, which is the value for the Time Window clause, t. Note that if the available energy is close to 100%, f ðvÞ returns the value d. However, as the energy is consumed, f ðvÞ is progressively increased. Thus, packet sending is postponed of d100=ve units of time, where d100=ve 2 N and 1pd100=vept=d. Finally, if energy availability is close to 0%, f ðvÞ assumes the value t, which means that the sensor node is not able to work (because no energy is available). Observe that f ðvÞ should not be continuous, since sensor nodes are supposed to send and receive packets in predefined periods of time (periods known by all sensor nodes in the network). The value 100 in d100=ve defines how gradual is the adjustment—this value was chosen empirically. However, it can be changed to better fit the characteristics of different networks (e.g., battery max level of capacity).

Table 2 Partial results obtained by applying different aggregate functions Node

A B Base station a

Collected data

20 220 221 21 221 222 pA and pB a

Aggregate function Min

Max

Count

Sum

Average

Median

20 21 20

21 22 22

3 3 6

61 64 125

61;3 64;3 125=6 ¼ 20:83

20 220 221 21 221 222 21

pA is the packet produced by node A and pB is the packet produced by node B.



Fig. 9. Function for adapting the send interval clause to energy usage.

Fig. 10. Function for adapting the sense interval to memory usage.

The second strategy consists of adjusting the Sense Interval clause value, g, according to memory availability, m. The goal is to dynamically decrease sensing activity as memory availability decreases, which reduces in turn the sample size (number of collections made from the environment). Accordingly, less data should be stored in memory to be aggregated and to be sent to the base station. Furthermore, power consumption associated to sensing and data processing activities is also decreased. ADAGA adjusts the value for the sense interval according with the function hðmÞ. The function hðmÞ varies from the minimum, which correspond to value of the Sense Interval clause, g, to the maximum, the value of the Send Interval clause (obtained by applying the f ðvÞ function); both clauses defined in the query. Fig. 10 shows three possible curves for the function hðmÞ, each of which having a different

value for a which defines the curved line tendency. For a ¼ 0:4, Sense Interval adjustments occur too soon (when 90% of memory is available), which may change more quickly the value defined by the user for the Sense Interval clause. On the other hand, for a ¼ 1:2, Sense Interval adjustments occur too late (just when one has about 30% of available memory), which may represent a significant amount of memory usage. We consider an intermediate value, a ¼ 0:6, in our experiments. In this case the function hðmÞ stays relatively constant between 50% and 100% of memory availability and thus the sensor node has hðmÞ equal or close to g. However, as memory usage increases (memory available decreases), the value for hðmÞ also increases. If the available memory reaches 0%, the sense interval value assumes the value obtained in f ðvÞ, which means that no collection will be made until the next send interval is reached. It is


important to note that after each sending of packets, hðmÞ assumes the value g again. It should be noted that given we wanted the behavior described in Fig. 10, we decided to find a function to yield the desired results. This fitting was done empirically and the result of the fitting process is the function hðmÞ. In general, approaches for in-network aggregation in WSN applications work in a reactive fashion. Those approaches interrupt the sensing activity when memory overflows or the battery power exhausts. The goal of using the functions f ðvÞ and hðmÞ is to make sensor nodes self-configurable devices by proactively monitoring the resource usage and adjusting sensor node activities. Indeed, the Sense Interval and Send Interval value adjustments made by ADAGA have priority over the values defined by users (in a SNQL query).

5.1.3. In-network aggregation with packet replication In a WSN, leaf nodes collect and pack data to be sent to other nodes. Intermediate nodes collect data (by sensing) and receive packets from other sensors. Since there would probably be more packaged data in intermediate nodes, failures in these nodes are more critical. In order to reduce the impact of packet losses in case of node failure, alternative packet routes should exist, which means that a sensor should send a packet to several sensors close to it. In other words, replication is necessary. Nevertheless, replication should be limited in order to avoid the implosion deficiency faced by flooding protocols [5]. Implosion consists of sending the same packet to several nodes, which also send this packet to several other nodes. Packet replication may become an even more difficult problem to solve when in-network aggregation is considered, since

2923

data packets should be aggregated progressively in each node they passed through. In Fig. 11, we have a scenario where a set of temperature sensors, represented by nodes A, B, C, and D, are distributed across three levels of a scalefree network. Suppose that each sensor node performs 10 collections (detections) from the environment before sending packets to its parents. Each packet is composed by an ID and a set of tuples of the form: detected (temperature) value and the number of detections. Now, suppose that the node A replicates a packet pA by sending it to both B and C. In turn, B aggregates its local collected data (i.e., 20 10, which means the value 20 has been detected 10 times) with data enclosed in pA (which has been sent by A), generating a new packet pB . C aggregates its local collected data ð21 10Þ with data coming from A, generating a new packet pC . D aggregates its local collected data ð20 10Þ with data coming from B and C, but it is not able to detect data replication because the initial identification of the packet generated in A was lost. Finally, the base station produces the final result, which does not reflect the correct result (see Fig. 11). In order to avoid such a problem, ADAGA admits packet replication but not as it happens in flooding strategy. For that reason, we have developed an alternative packet-replication strategy in order to run ADAGA. When a packet P finds the first node ðNÞ that has more than one parent, a copy of P is generated to each parent of N. After that, when one of the copies of P finds a node N 0 , which also has more that one parent, just one of those parents is randomly chosen to receive P. Therefore, after the first packet replication, no other copy for P is generated any more. In order to make that control, when a packet is generated, the number of replicas (copies) generated, c, is stored in its header.

Fig. 11. Data replication happens when a node has more that one parent.



There are two possibilities when a node N, which has more than one parent, receives a packet P: (i) if c ¼ 1, P is replicated for each of the N’s parent; (ii) on the other hand, if c41, P is sent to just one of the N’s parents (which is randomly chosen). Therefore, after the first packet replication, the number of copies for a given packet P is not increased any more. When a node N receives m copies of the same packet P, the copy of P ðPk Þ which has the smallest value for c is kept, the other m 1 copies are discarded, and c is updated, i.e., c is set to c ¼ c ðm 1Þ. The new value for c is then stored in the header of Pk . Observe that, when the value c ¼ 1, the data in the packet (detected value and the number of detections) can be aggregated because there is no risk of generating duplicate in final result. Hence, packet copies are progressively discarded as they are passed through the network and data in given packet are aggregated when there are no replicas for the packet ðc ¼ 1Þ. In order to illustrate how ADAGA processes innetwork aggregation, consider the same example depicted in Fig. 11. Observe in Fig. 12 how data are progressively aggregated until they reach the base station (delays are disregarded). In Fig. 12, the header of a packet contains the number of packet copies (c). Suppose that node A collects data and generates the packet pA which is sent to its parent nodes B and C. Since the packet pA has 2 copies (i.e., c41), its data are not aggregated with data collected in nodes B and C. Since the node D receives 2 copies of pA , D discards one of them and set c ¼ 1, according to the routing strategy described above. Thereafter, D aggregates data in the packet pA with the locally collected data. Finally, the result packet pD is generated by D and sent to the base station.

Clearly, some packets received by the base station may still have copies left in the network. Similar to what happens in sensors, packet content cannot be processed until all their replicas are discarded. However, if a packet P in the base station has lost copies, its content would never be aggregated because the c would never be 1. There are two alternatives to overcome that problem. The first consists of using timeouts to indicate when a packet can be opened by the base station, even if c41. The second is to wait until the query validity time (Time Window clause) is reached, since data will not be received any more, the packet can be opened because its copies will not be accepted if they arrive later. However if the query is defined as a continuous query, the second alternative cannot be applied because the query validity time is infinite— packets with lost copies in the network would never have their data aggregated in the base station. 5.1.4. Evaluation We evaluated ADAGA by processing a query which consists of sending distinct detected temperature values, and the number of detections for each value. The base station is supposed to receive data sent by sensors and calculate an Average operation. Statistics are used to draw inferences about a population from a sample. We consider as complete population all values that should be obtained if we had continuous sensing activity. Observe that when a sensing interval is informed in a query, it defines the size of a sample for a complete population. Thus, when the sensing interval is increased, a smaller sample is obtained and less precise results are produced. In order to reduce the distance between approximated results (obtained because of the resource constraints) and correct results, it is

Fig. 12. In-network aggregation with the ADAGA algorithm.


possible to guess about the values of detections that were not performed (because of larger sensing intervals) by appropriately analyzing data already collected. A simple approximation could be made by computing the number of detections (estimated number of collections) that would be made if the sensing interval were not adjusted. The next step would be to add the result of this operation to the number of detections of the last collected value. Another way would be to compute a new estimated value of detection based on the average of the last two collected values from the environment, which would be associated to the estimated number of collections. Our experiment was executed on a sensor network simulator, developed in C þ þ, and executed in a Pentium IV machine. This simulator allows the configuration of memory and energy availability. Thus, it is possible to simulate how the ADAGA algorithm would respond in resource constraint situations. In Figs. 13 and 14, we consider a SNQL query Q with the following clause values: Time Window ¼ 600 s, Send Interval ¼ 600 s, and Sense Interval ¼ 1 s. Q is executed in order to collect temperature measurements from the environment. We also consider a uniform distribution of temperature values between 10 C and 30 C. Fig. 13 shows how results (for distinct values and amount of collections of each distinct value) assume different approximations of the correct result (when no energy or memory constraint is faced), based on

Fig. 13. Results obtained by applying the average operation.

2925

Fig. 14. Amount of detections for each value computed by the average operation.

three approaches: (i) proactive, explored in ADAGA by monitoring energy and memory availability, in order to adjust sensor activities; (ii) reactive, which consists of processing in-network aggregation without monitoring resource usage; and (iii) conventional for WSN applications, which consists of just collecting and sending data to other nodes, without in-network aggregation. Note that in 600 s, 600 collections would have been made, if memory constraints were disregarded producing the result for the average operation of 19:91 C. By using in-network aggregation, a maximum of 1680 bytes would be necessary to store distinct detected values and the number of detections of each distinct value. In Fig. 13, we observe that ADAGA produces better estimations of the correct results, considering different levels of memory constraints, than approximations produced by a reactive approach or when in-network aggregation is not applied. Fig. 14 shows a comparative graph of the amount of collections made. In this case, the proactive approach and the reactive approach have almost the same number of collections, since both perform in-network aggregation. On the other hand, when in-network aggregation is not applied, the number of collections drastically decreases since memory is quickly used up. Fig. 15 compares energy consumption using the proactive (ADAGA), reactive, and without in-network aggregation approaches. Energy consumption model is based on a transmission cost of



Fig. 15. Power consumption for processing average of temperature values.

75 nJ/bit, reception cost of 50 nJ/bit, detection and processing costs of 125 nJ/bit. Observe that energy consumption increases with memory consumption since more data are sent to other nodes and thus more power consumption is required. However, the proactive approach achieves a better optimized energy usage when compared to other approaches. When memory availability is enough to compute the query result, all three strategies reach the same power consumption amount. 5.2. ADAPT As already mentioned, ADAPT is a join operator, which is able to react to events which may considerably increase response time when processing join operations in base stations. ADAPT ensures the following properties: (i) incremental production of results as soon as data become available; (ii) progress of the query processing even when the delivery of data is blocked, and (iii) reaction to memory-overflow events. When memory overflow occurs ADAPT triggers a memory-management policy which consists of flushing part of the data from main memory to disk. 5.2.1. Algorithm ADAPT is executed in three phases, each of which running in a different thread. The first phase is responsible for executing the join in a pipelining fashion. Thus, the first phase ensures incremental result production as soon as tuples are delivered. Furthermore, the first phase has the capability of reacting to memory overflow events (when the ADAPT is being executed). When tuple delivery is

blocked, the second phase is triggered. The idea is to overlap delays by executing other tasks. The third phase is executed to ensure correctness in the results produced by ADAPT. It is important to observe that the first and second phases do not need to be executed sequentially. That means, after the execution of the second phase, the operator can return to execute the first phase again. Next, those phases are described in detail. First phase: The key goal of the first phase is to join the largest amount of memory-resident tuples, using the available memory. This phase starts to run as soon as tuples begin to arrive and continues executing as long as tuples of at least one of the tables are arriving. When all tuples of both tables involved in the join operation have arrived, the first phase stops its execution (and the third phase is started). If the arrival of tuples from both tables is interrupted (blocked), the execution of the first phase is suspended (and the second phase is started), since there are no new tuples to be processed. When new tuples restart to arrive, the execution of the first phase is resumed. For that reason, the ADAPT is a non-blocking join operator. When the first phase starts to run, two hash tables are created (one for each table of the join operation). Thereafter, the hash tables can be populated (as soon as tuples from the tables involved in the join operation arrive) by applying a hash function h over the join attributes. Each hash table is composed by buckets. For example, in Fig. 16, there are two hash tables H A and H B . Each hash table has two buckets: M A1 and M A2 (belonging to H A Þ, and M B1 and M B2 (belonging to H B Þ. The buckets have the same memory size. Two buckets of different hash tables are said to be correspondent if they have the same address in the hash tables. In other words, when the hash function is applied to the join attributes of the tuples of two

Fig. 16. Execution state before flushing buckets to disk.


correspondent buckets (for example, M A1 and M B1 Þ, we get the same result (address). Correspondent buckets form pairs. For instance, in Fig. 16 is depicted the pair PAB1 , which is composed by the buckets M A1 and M B1 , and the pair PAB2 , which is composed by the buckets M A2 and M B2 . Tuples allocated in a given bucket are uniquely identified in that bucket by an identifier, denoted BTID (Bucket Tuple IDentifier). A BTID is a sequential number incremented whenever a new tuple comes to the bucket. It is important to observe that the last (the greatest) BTID in a given bucket represents the number of tuples in that bucket. As already mentioned, as long as tuples arrive to be processed by ADAPT, they are first allocated to a bucket according to the result of the hash function applied over the join attribute (build step). After a tuple t has been allocated to a given bucket, it is compared with tuples of the corresponding bucket of the other table involved in the join operation (probe step). Therefore, the execution of the build and probe steps is pipelined in ADAPT. In other words, build and probe can be executed in parallel. Therefore, ADAPT supports intra-operator pipelining. To illustrate how the first phase of ADAPT works, consider a join operation between two

2927

groups of sensors A and B. Recall that the proposed data model (Section 3.1) allows the query engine to see data flowing through a WSN as tuples of (virtual) relations. When the ADAPT operator starts to receive tuples, it initializes two hash tables, denoted H A and H B (see Fig. 16). Suppose that tA1 is the first to come to C 1 and it is allocated in the bucket M A1 . A BTID should be added to the tuple tA1 . Since tA1 is the first tuple in M A1 , the BTID for tA1 should be 1. Thereafter other tuples from relations A (tA2 , tA3 , tA4 , tA5 ) and B (tB1 , tB2 , tB3 ) arrive and are processed by ADAPT in the same way that tuple tA1 was. Fig. 16 depicts the execution state after ADAPT has processed tuples tA1 , tA2 , tA3 , tA4 , tA5 , tB1 , tB2 , and tB3 . During the execution of the first phase, there are two scenarios in which an overflow may occur. First, since each bucket has a limited size, a bucket overflow may occur. In that case, there is not enough space to allocate tuples in a given memoryresident bucket M, although it is possible to allocate tuples in another bucket M 0 , where M 0 aM. Second, since mobile hosts may have limited main memory, memory overflow may occur. In such a scenario, there is no available memory to room tuples in any bucket. In order to overcome the memory-overflow problem, ADAPT implements

Fig. 17. Execution state after flushing M A1 to disk and receiving the tuple tA6 .



a memory-management described in the following. Consider the scenario illustrated in Fig. 17. When an arriving tuple tA6 should be allocated to a given bucket M A1 and an overflow occurs, the contents of M A1 is flushed to a disk area, denoted disk bucket DA1 (see Fig. 17). Thereafter, M A1 can receive new tuples again. It is important to note that whenever a memory-resident bucket M A1 is flushed to disk, its content is in fact appended to the disk bucket DA1 (disk bucket associated to the memory-resident bucket M A1 Þ. Another important feature of the memory-management policy implemented by ADAPT to cope with memory overflow is the following: whenever an overflow occurs, buckets, which have been already flushed to disk and which have tuples in memory, will be chosen as victim (bucket to be flushed to disk). The idea is to choose buckets (victims) which already have a portion of their contents in disk in order to keep other buckets entirely memory resident. By doing this, ADAPT avoids to flush to disk several different buckets, reducing, thus, disk access when executing its second and third phases. As already seen, ADAPT implements a memorymanagement policy for reacting to memory-overflow events. However, memory overflow represents in fact an undesirable side-effect of the execution of ADAPT. In order to minimize the frequency of memory overflow, the ADAPT implements the following strategy. Before allocating a tuple tA of a relation A (involved in the join operation) in a given bucket M Ai , the ADAPT operator verifies if all tuples of the other relation, say B, have already been received (by ADAPT) and there was no memory overflow for the bucket M Bi (i.e., the contents of has never been flushed to disk). In that case, after comparing the new tuple tA of M Ai with the tuples of M Bi , tA can be discharged (i.e., it is not allocated anymore in M Ai Þ, since all tuples from B which would be allocated in M Bi are memoryresident. Second phase: This phase starts its execution whenever the arrival of tuples of both tables is interrupted (blocked). In that case, the operator chooses a disk-resident bucket and uses it to probe the memory-resident tuples of the corresponding bucket from the other relation. The tuples which satisfy the join condition are included to the result. After processing all tuples of the disk-resident bucket, the ADAPT verifies if the tuple delivery from the relations involved in the join operation is still blocked. In the case of the delivery is still

blocked, another bucket in disk is processed, otherwise the ADAPT switches its execution to the first phase. Third phase: The third phase is activated when all tuples of both relations (operands of the join operation) have already been received. The execution of this phase avoids incomplete results. Incomplete results may occur due to the following two reasons. The first phase fails to compute tuples which were not memory-resident at the same time. In other words, the first phase is not able to join tuples belonging to corresponding buckets when at least one of them has already been flushed to disk. On the other hand, the second phase fails to join disk-resident tuples with tuples which have not yet arrived to the corresponding bucket in memory. The third phase of the ADAPT has the functionality of joining disk-resident tuples which were not yet compared. Such tuples can be identified by means of the mechanism described in Section 3.2. Thereafter, the following steps are executed: Step 1. For each disk-resident bucket DAi of relation A For each tuple t in DAi Compare t with all tuples of the correspondent buckets M Bi and DBi of relation B; Apply a hash function f, f ah, over the join attribute a of t; Allocate t in a hash table T HA , where T HA ¼ f ðaÞ; Step 2. For each disk-resident bucket DBi of relation B For each tuple t in DBi Compare t with all tuples of the correspondent buckets M Ai and DAi of relation A; Apply a hash function f, f ah, over the join attribute a of t; Allocate t in a hash table T HB , where T HB ¼ f ðaÞ; Step 3. Execute a hybrid hash join using T HA and T HB ; 5.2.2. Avoiding duplicates It is important observe that during the execution of the ADAPT operator, the following phenomena may occur. First, as already mentioned when tuples of a memory-resident bucket M are flushed to disk they will not be compared anymore with tuples of the corresponding bucket M 0 which come to M 0


after the flushing operation of M. In order to illustrate such a phenomenon, consider that tuples of M A1 (as in Fig. 16) are flushed to disk. In that case, tuples, which are arriving (after the flush operation on tuples of M A1 ) to the bucket M B1 , are not compared anymore with the tuples of M A1 which were flushed to disk. Such a phenomenon may provoke incomplete results and it is avoided (in ADAPT) by executing the second and third phases. However, a second phenomenon may occur when executing the second and third phases of ADAPT. The execution of those phases may produce duplicates, since they perform overlapping work. In order to illustrate such a phenomenon, consider that tuples of M A1 and M B1 (depicted in Fig. 16) had been joined in the first phase and after that M A1 are flushed to disk as shown in Fig. 17. An execution of the second phase of ADAPT evolving DA1 and M B1 would produce spurious duplicate (tA1 would be compared with tB2 again producing A as a result once more). In order to avoid the aforementioned phenomenon, the ADAPT operator implements a mechanism to identify which tuples of both relations (operands of a join operation) were actually compared. The key idea of that mechanism is the following. Whenever a bucket M A1 is flushed to disk, a control table is generated for the pair of buckets PAB1 composed by M A1 and its correspondent bucket M B1 . The number of lines and columns of a control table is defined by the number of tuples already

2929

received for that pair of correspondent buckets (Fig. 18). In other words, the number of lines is defined by the number of tuples belonging to one table involved in the join operation allocated for a given bucket M A1 and the number of columns represents the number of tuples belonging to the other table allocated to M B1 (the correspondent bucket of M A1 Þ. The content of a control table’s cell may be 0 or 1, which indicates whether the tuples were compared (1) or not (0). In fact, the control table is a bit table. To show how the mechanism for avoiding duplicates in ADAPT operates, consider the scenario illustrated in Fig. 17. Suppose that the allocation of a tuple tA6 in M A1 provokes memory overflow. Thus, ADAPT flushes the bucket M A1 to disk and frees the area of M A1 . A control table C for the pair PAB1 should be created as shown in Fig. 18. For the sake of clarity, let us assume that the number of lines of control tables corresponds to the amount of tuples belonging to relation A allocated to M A1 and the number of columns corresponds to the number of tuples of relation B allocated to M B1 . In fact, the ADAPT operator defines dynamically which relation corresponds to the lines and which one corresponds to columns of the control table. Hence, the control table has 4 lines and 2 columns. Observe that one can define the number of lines and columns by using the last BTID of each bucket (in that case, M A1 and M B1 Þ. Fig. 18 illustrates the execution state of ADAPT after M A1 has been flushed to disk

Fig. 18. Execution state after flushing M A1 to disk and receiving the incoming tuple tA6 , which is represented in the control table C.



Fig. 19. Properties that can be explored in a control table.

and the control table for the pair PAB1 . Observe that the cells have assumed value 1 for all tuples of M A1 flushed to disk (Fig. 18), since they were compared with the tuples of M B1 . In Fig. 18, A1 (control table) represents the set of tuples belonging to M A1 (memory-resident) and DA1 (disk-resident). In turn, B1 (control table) represents the set of tuples belonging to M B1 and DB1 . After the control table for a given pair of buckets P has been created, that table has to be resized whenever a new tuple arrives and has to be allocated in one of the buckets of the pair P. During the execution of the second phase, the control table should be used to avoid duplicate tuples in the join result. This is because disk-resident tuples may have been compared with memoryresident tuples belonging to the other input of the join operation. The mechanism to avoid duplicates works as follows. Before reading disk-resident tuples, the operator reads the control table and identifies the BTIDs of the tuple which were not processed yet. Recall that the cells in the control table of those tuples are set to 0. With such information, the operator reads the tuples which were not yet processed of the disk-resident bucket and uses them to probe the memory-resident tuples of the corresponding bucket. The third phase is performed by reading all control tables in order to identify disk-resident buckets which were not compared with their correspondent buckets yet. It is important to note that the ADAPT explores some properties of the control table for optimizing its use. In order to illustrate how such properties are explored, consider the control table depicted in Fig. 19.

Suppose that the control table C depicted in Fig. 19 had been generated when one of the memory-resident buckets of the pair PAB1 (see Fig. 18) was flushed to disk. BTIDs of tuples from table A are used as indexes to access each line in the control table; in the same way, BTIDs for tuples from table B are used as indexes to access the columns in the control table. Observe that the cardinality of A1 and B1 (denoted a and b in Fig. 6, respectively) are known, since we have the greatest values for BTIDs of tuples in A1 and B1. Recall that A1 represents the set of tuples belonging to M A1 and DA1 , B1, in turn, represents the set of tuples belonging to M B1 and DB1 . Thus the following properties of the control table are explored: (i) If ki ¼ b, the tuple in A1 which has BTID equals to i was already compared with all tuples from B1; (ii) If l j ¼ a, the tuple in B1 which has BTID equals to j was already compared with all tuples from A1, and; (iii) If r ¼ s, where s ¼ a b, all tuples from A1 were already compared with all tuples from B1. This property avoids unnecessary carrying of buckets from disk to memory. Analyzing the control table in Fig. 19, one can observe that tuples in A1 with BTID equal to 1, 2, and 3 have already been compared with all tuples from B1, since k1 ¼ k2 ¼ k3 ¼ b ¼ 3 (property (i)). In the same way, tuples from B1 whose BTID is 1 have already been compared with all tuples in A1, since l 1 ¼ a ¼ 4 (property (ii)). Although property (iii) is not observed in the scenario depicted in Fig. 19, it is in fact the most important one to be evaluated, since it can avoid unnecessary disk access. Thus, if in the scenario shown in Fig. 19 the value for r were equal to s (i.e., 12), this would


mean that all tuples from A1 and B1 would have already been compared. In that case it would not be necessary to read disk-resident tuples for A1 and B1. Observe that most part of the work performed in the ADAPT’s second and third phases is overlapping work (since they compare the same set of tuples more than once), the gains of not reading tuples from disk when not necessary represents an important feature supported by ADAPT. 5.2.3. Cost estimation In order to estimate the cost of executing the ADAPT operator, consider the scenario described in Section 2. Thus, we have a join operation between the unsorted tables A and B (stored in the mobile databases DB2 and DB3 which reside in mobile hosts C 2 and C 3 , respectively). For the sake of simplicity, let us consider that the tables A and B have the same cardinality c, the same tuple size and there is an even distribution of tuples between the two hash tables. The available main memory area in C 1 for executing the ADAPT has the capacity of storing s tuples. We consider disk-access cost. Without lost of generality, the measure for estimating that cost is the number of tuple transfers to/from disk, instead of block transfer. The cost for ADAPT can be estimated, according the following conditions: 1. sX2c: In this case, there is no overflow. Thus, no tuple is flushed to disk and the third phase is not triggered, which gives a cost of 2c (for reading tables A and B); 2. s=2ocps: In this case, there is an overflow of c tuples, since we have assumed an even distribution of tuples across the hash tables. The cost is given by 2c þ ðc=2 þ c=2Þ þ ðc=2 þ c=2Þ, i.e., 4c. Note that, one term ðc=2 þ c=2Þ represents the cost of flushing tuples to disk and the other represents the cost of reading the tuples from disk for executing the third phase. 3. soc: In this situation, we have an overflow of ð2c sÞ tuples, i.e., an overflow of ðc s=2Þ tuples for each table. Thus, the estimated cost is 2c þ ð2c sÞ þ ð2c sÞ, giving the final cost of 2ð3c sÞ. 5.2.4. Experimental results In order to investigate performance issues with respect to properties of the ADAPT operator, we have performed experiments. In the experiments a query Q is submitted to a mobile computer C 1 , where

2931

Q represents a join operation between two unsorted tables A and B, which are stored in two different instances of SQL Server database, each of which residing in a different mobile computer, C 2 and C 3 , respectively. The tuples of those relations should be delivered to mobile host C 1 where the join operation has to be executed. Both relations (A and B) have the same cardinality (50 103 tuples of 115 bytes). In one experiment, we have investigated the behavior of the ADAPT considering memory restriction (which induces memory overflows) and the occurrence of interruptions of data delivery to the operator (which induces the execution of the second phase). We have simulated a data delivery interruption of 5 s for each table for every 5000 tuples (of that table). Fig. 20 shows the performance in an environment with 4 MB of available memory, regarding the execution or not of the second phase. For that reason, we have first switched off the second phase. Thereafter, we have switched on the second phase. Observe that the ADAPT operator has an aggressive strategy to produce results as soon as possible when the second phase is executed. In other experiment, we have investigated the performance of the ADAPT by simulating a bursty data arrival. We have simulated interruptions of 5 and 10 s for each table for every 1000 and 5000 tuples which arrive to the operator. For example, the data delivery from table A is blocked for 5 and 10 s whenever 1000 tuples of A have arrived to the ADAPT. For this experiment, the second phase is triggered whenever the arrival of tuples of both tables is interrupted (blocked). Fig. 21 shows the result of that experiment. Observe that ADAPT is scalable w.r.t. the frequency and duration of

Fig. 20. Performance with main memory of 4 MB.


2932

Fig. 21. Performance with bursty data delivery.

interruptions of data delivery. Looking closely to Fig. 21, one can observe that one has almost the same curve for each simulation, since they are just shifted by a factor corresponding to the frequency and duration of interruptions. In other words, there is no exponential growth when more interruptions (bursty data arrival) are introduced which represents a desirable behavior for an adaptive join operator.

considers energy and memory availability as criteria to adjust sensor activity and increase the fidelity of query results. Some studies have proposed extensions to the conventional SQL as an approach to work with declarative queries in WSN applications. The TinyDB Project at Berkeley proposed an acquisitional query language [6], which has some simple extensions to SQL for controlling data acquisition. Madden et. al show how acquisitional issues influence query optimization, dissemination, and execution [6]. Other query languages also offer support to sensor networks, such as CQL [4] which was designed to process continuous queries, and SQTL [11] which was proposed in the context of the SINA Project in order to delegate tasks to sensor nodes. These query languages do not allow specifying data sending interval, which is an important parameter to our resource-aware approach. Thus, we developed a simplified query language named SNQL, which has the necessary parameters to allow sensor nodes to become self-configurable devices.

6. Related work 7. Conclusion There is a growing interest in query processing for WSNs. Some research has explored in-network aggregation as an alternative to achieve energy efficiency when propagating data from sensors to sink nodes [6,7,9,12]. In-network aggregation approaches are mainly differentiated by their network protocols for routing data. Directed diffusion is proposed in [13] as a data-centric communication where a sink node broadcasts an interest that describes the desired data to its neighbors. As interests are passed throughout the network, gradients are formed indicating the direction in which collected data will flow back. Each node maintains a small cache of recently received data items in order to avoid duplicates. In [12] a greedy incremental tree (GIT) is proposed, in which a shortest path is established for only the first source to the sink node and the others are incrementally connected at the closest point on the existing tree. TAG [7] works with a routing tree rooted at a base station and does not accept duplicate packets in the network. All these approaches have energy-saving as their main goal, but memory constraints are not considered. Even using in-network aggregation, the volume of data collected, the query complexity, or the low memory availability of a particular sensor node may increase chances of memory overflows. In this paper, we have presented an approach, which

In this paper we described some important issues related to sensor networks and resource-aware techniques. We have proposed an approach for adjusting sensor activities according to energy consumption and memory usage, in order to maximize sensor lifetime (by saving energy) and also the accuracy of query results, mainly considering situations in which sensors experience resource constraints (energy and memory). Moreover, we presented a simplified query language for sensor networks, called SNQL, which is especially designed to inform some initial parameters (e.g., data sensing and data sending intervals) to be used by sensor nodes. Those parameters are progressively adjusted in order to give sensors self-configurable capability. Finally, we presented the algorithm ADAGA, which implements the proposed adaptive approach and also processes in-network aggregation. An important issue for WSNs is the possibility to adapt sensor node behavior to their resource availability. Since WSN applications are naturally data-driven, data processing is a critical task for sensor nodes, which strongly influences resource consumption of sensor nodes (e.g., by using in-network aggregation). Thus, we believe that adaptive strategies applied to sensor data processing can significantly increase WSN lifetimes.


References [1] I. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cyirci, Wireless sensor networks: a survey, Comput. Networks 38 (4) (March 2002) 393–422. [2] L. Golab, M.T. O¨zsu, Issues in data stream management, ACM SIGMOD 32 (2) (June 2003). [3] J. Gray, A. Bosworth, A. Layman, H. Pirahesh, Data cube: a relational aggregation operator generalizing group-by, cross-tab, and sub-total, Data Mining and Knowledge Discover 1(1) (May 1997) 29–53. [4] A. Arasu, S. Babu, J. Widom, The CQL continuous query language: semantic foundations and query execution, Technical Report, Stanford University, October 2003. [5] W. Heinzelman, J. Kulik, H. Balakrishnan, Adaptive protocols for information dissemination in wireless sensor networks, in: ACM/IEEE MOBICOM, August 1999. [6] S.R. Madden, M.J. Franklin, J.M. Hellerstein, TinyDB: an acquisitional query processing system for sensor networks, ACM Trans. Database Syst. 30 (1) (March 2005) 122–173. [7] S.R. Madden, M.J. Franklin, J.M. Hellerstein, W. Hong, TAG: a tiny aggregation service for ad-hoc sensor networks, OSDI, December 2002. [8] I. Solis, K. Obraczka, In-network aggregation trade-offs for data collection in wireless in sensor networks, INRG Technical Report 102, August 2003. [9] Y. Yao, J. Gehrke, Query processing for sensor networks, in: Proceedings of the CIDR conference, 2003. [10] S. Cho, E. Shih, N. Ickes, R. Min, et al., Physical layer driven protocol and algorithm design for energy-efficient

[11]

[12]

[13]

[14] [15]

[16]

[17]

[18]

2933

wireless sensor networks, in: ACM/IEEE MOBICOM, Italy, July 2001, pp. 272–287. C. Srisathapornphat, C. Jaikaeo, C. Shen, Sensor information networking architecture and applications, IEEE Personal Commun. 8 (4) (August 2001) 52–59. C. Intanagonwiwat, D. Estrn, R. Govindan, J. Heidemann, Impact of network density on data aggregation in wireless sensor networks, in: International conference on distributed computing systems (ICDCS), July 2002, p. 457 C. Intanagonwiwat, R. Govindan, D. Estrin, Directed diffusion: a scalable and robust communication paradigm for sensor networks, in: Proceedings of the Mobi-Com, ACM, August 2000. S. Babu, J. Widom, Continuous queries over data streams, SIGMOD Rec. 30 (3) (September 2001). J. Considine, F. Li, G. Kollios, J. Byers, Approximate aggregation techniques for sensor databases, in: Proceedings of ICDE, April 2004. S. Hedetnieme, S. Hedetnieme, A. Liestman, A survey of gossiping and broadcasting in communication networks, Networks 18 (1988) 319–349. J.M. Hellerstein, M.J. Franklin, S. Chandrasekaran, A. Deshpande, K. Hildrum, S. Madden, V. Raman, M.A. Shah, Adaptive query processing: technology in evolution. IEEE Data Engineering Bulletin 23(2) (June 2000) 7–18. M. Tubaishat, J. Yin, B. Panja, S. Madria, A secure hierarchical model for sensor network, ACM SIGMOD 33 (1) (March 2004) 10–20.

Toward adaptive query processing in wireless ... - Semantic Scholar

Toward adaptive query processing in wireless ... - Semantic Scholar

Suggest Documents

Adaptive Query Processing - Tableau Research

Dynamic Query Processing in DIOM - Semantic Scholar

Adaptive Query Processing in Mobile Environment - CiteSeerX

Advanced Spatiotemporal Query Processing - Semantic Scholar

Cache-Oblivious Query Processing - Semantic Scholar

Maximum Lifetime Continuous Query Processing ... - Semantic Scholar

Evaluating Adaptive Query Processing Techniques for ... - CiteSeerX

Using State Modules for Adaptive Query Processing

Toward a miniature wireless integrated ... - Semantic Scholar

Toward Adaptive Conversational Interfaces ... - Semantic Scholar

TOWARD AN ADAPTIVE DATA DISTRIBUTION ... - Semantic Scholar

Parallel OLAP query processing in database ... - Semantic Scholar

Parallel Query Processing in Shared Disk ... - Semantic Scholar

Building DD to Support Query Processing in ... - Semantic Scholar

Advanced Query Processing in Object Bases ... - Semantic Scholar

Multi-scale query processing in vehicular networks - Semantic Scholar

Query privacy in wireless sensor networks - Semantic Scholar

Query-Based Data Collection in Wireless Sensor ... - Semantic Scholar

Query Processing in an Information Mediator 1 ... - Semantic Scholar

Query Optimization and Processing in Federated ... - Semantic Scholar

Relational Query Processing in a P2P Network - Semantic Scholar

Efficient Time Triggered Query Processing in ... - Semantic Scholar

The NAPA Adaptive Processing Architecture - Semantic Scholar

Adaptive Wireless Services for Augmented ... - Semantic Scholar