1. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ Lecture on Sensor Networks Historical Development time Copyright (c) 2005 Dr. Thomas Haenselmann (University of Mannheim, Germany). Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included on the last pages entitled "GNU Free Documentation License".

2. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ Problem of severe data aggregation towards the sink Each node samples its own data. It sends these data with all samples gathered from the children to the parent node in the tree. On the way up all data accumulates more and more. In the worst case the bandwidth near the sink node is not enough to transport all the information. Missing bandwidth can be compensated for up to a certain degree by buffering data. This shifts some communication effort into time slots with lower activity. However, both memory and bandwidth are limited and data may be lost. To mitigate the problem data should be lost in a controlled manner by means of aggregation. Aggregation 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 3 3 3 3 4 5 1 6 6 9 4 18 28 sink

3. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ Tiny Aggregation Service TAG „TAG: A Tiny Aggregation Service for Ad-Hoc Sensor Networks“ by S. Madden, M. J. Franklin, J. M. Hellerstein We assume that the sensor network only has a single access point to a wide area network. In the following approach a tree will be built. The root of the tree will be the node with access to the WAN. All nodes send on a broadcast medium and address one another by Ids (0=broadcast to everyone). (1)The root node declares itself as such and broadcasts a triple (tree level, ID, parent) (2)All nodes in the range store the received root ID as parent node and set their own ID to the parent ID+1. (3)All child nodes start a random timer. The most impatient node defines itself implicitly as intermediate node and broadcasts its own triple like the root node did. Possible improvement: Nodes with the same level may choose the candidate with the best connectivity as inner tree node. (4)All children in the same range continue according to (2). Broadcast messages are ignored by all nodes which have chosen their parent already. Note: The initialization phase of the tree is very similar to the initialization phase in AMRIS. Aggregation

4. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ Tiny Aggregation Service TAG Example of a TAG-like tree in a sensor network Aggregation (0/1/-) root (Level/ID/Parent) (1/2/1) (1/3/1) (1/4/1) (2/11/4) (2/4/4) (2/9/4) (2/5/2) (2/7/3) (2/8/4) (3/17/9) (4/22/17) (3/16/8) (3/15/8) (3/14/7) (4/20/14) (3/13/6) (3/12/6) (5/25/21) (5/26/21) (5/27/22) (5/28/22) (4/23/17) (4/24/17) (3/18/9) (3/19/9) (2/6/2) (4/21/15)

5. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Query model Requests to the network are syntactically based on SQL and origin from the root node. The root then propagates the query further to its children and so on... SELECT [ALL,DISTINCT, UNIQUE] {const, attr, fkt(expr), arithm. expression} FROM sensors WHERE {selPreds} GROUP BY {attrs} HAVING {havingPreds} EPOCH DURATION i SELECT is used to aggregate attributes (columns) or merely to display specific attributes (possibly after some kind of arithmetic transform). The aggregation only takes place with regard to the attributes that show up in GROUP BY. Besides attributes, constants and functions can as well be used in the select clause. SELECT price*100/116, price*16/116 lists prices and 16% tax separately SELECT TODAY, price lists today's price together with the date SELECT BestNr, count(*), sum(price) aggregates goods with the same product number but preserves the amount Aggregation

6. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Query model FROM is a constant expression in the case of TAG in which only the network can be addressed by “sensors”. No other table is known. As a consequence no join is possible. WHERE filters sensor nodes before being aggregated. A single sensor (resp. its data) can be considered as a single row of the table. Allowed are all kinds of relational operators (light > 500 lux), BETWEEN (light BETWEEN 100 AND 500), IN (NO_NEIGHBORS IN (2,3,4)), ISNULL or IS NULL, LIKE (e.g. SerialNo LIKE „12%“). The WHERE-clause has no function in the context of a join. It is only used as a simple filter. GROUP BY groups data from nodes according to the attributes specified. All attributes which determine the grouping also have to be selected (otherwise a group could not be identified anymore). Vice versa all attributes being selected but not aggregated have to appear in the GROUP BY clause. Only aggregated attributes must not be used for grouping. SELECT OrderNo, count(*), sum(price) FROM order GROUP BY OrderNo Aggregation

7. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Query model HAVING filters a whole group which was created with GROUP BY. This is not to be confused with the WHERE clause in which single tuples or sensors are filtered. Finally, EPOCH DURATION is the only non-SQL clause which defines the time span which must suffice for the children to deliver their (aggregated) results. The time span must be large enough to a) receive the request b) make local measurements c) to aggregate from children below in the tree d) send the aggregated result back to the parent This means that a node receiving a request subtracts the time it needs itself and provides the rest for its own children. Data that does not return in time from the children will simply be ignored by the parent node (the aggregated data has be forwarded to the parent before anyway. Other than ordinary SQL-requests the TAG query model delivers results every time span defined in EPOCH DURATION in the fashion of a constant data stream. This is one of the reasons why the authors of TAG do not care for packet loss. Aggregation

8. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Query model Example: Sensors are distributed in a building over a large number of rooms in different stories. A single room will usually contain several sensors. Sensors know to following data: a) room b) story c) loudness The request should return the occupied rooms in the 6 th story. A room is considered to be occupied if the average loudness is greater than a predefined threshold. The request should be repeated every 30 seconds. SELECT AVG(loudness),room FROM sensors WHERE story=6 GROUP BY room HAVING AVG(loudness) > threshold EPOCH DURATION 30s Aggregation

9. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Elements of the aggregation Aggregations consist of three components: Merging function The merging function merges to vector valued partial results to f(, )a single one. Initializer iThe initializer is the anchor for the cascading aggregation at the end of a recursive request. It tells a leaf node what to deliver if no children are available (note that the merging function can not be used by a leaf node). The initializer is often trivial (but not always). Evaluator eThe evaluator computes the answer based on the final result delivered by the root node. Often, the result is the answer itself, but not always. The aggregation only takes place at the inner nodes of the tree. The initialization only takes place at the leaves and the evaluation only at the root node. Aggregation

10. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Elements of the aggregation The average of a scalar measurement merging function: f(, ) = <value1+value2, count1+count2> initializer: evaluator: result = value/count The maximum of a scalar measurements merging function: f(value1, value2) = max{value1,value2} initializer: evaluator: result = value Number of sensors merging function: f(, ) = value1 + value2 initializer:1 evaluator: result = value Aggregation

11. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Structure of the aggregation function Examples: Histogram of a measured value merging function: f(, ) = initializer: [value] += 1 (increment the vector at index “value” by one. “value” is a measured sample.) evaluator: result = Compared to the previous aggregation function a value only influences a histogram in the form of an index. Often, the value will be quantized before being used. The index defines which bin of the histogram will be incremented by one. In the end the histogram serves to display the distribution of values (e.g. a temperature histogram could display the amount of days with a particular temperature. Each integer temperature is a unique bin). Care has to be taken with regard to the granularity of the measured value. A 16-bit value would result in a histogram with 65,536 bins. In this case sending the measurements themselves would probably be less demanding. Aggregation

12. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Classification of aggregation functions Occurrences of the partial state (see following side) distributed:Every sub-group of sensors delivers its own result which can be interpreted by itself (in a meaningful way). algebraic:The result of an aggregation of a sub-group (sub-tree) can not be interpreted by itself. A meaningful result can only be obtained after applying the evaluation function. holistic:The size of the aggregation of a sub-group is proportional to the amount of data contained in the group. An interpretation only makes sense at the end of the query. unique:As in the case of “holistic”, but only pairwise different values are of interest. context-The size of the data depends on the content of the data but not sensitive:necessarily on the amount. Aggregation

13. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Classification of aggregation functions The aggregation functions will now be classified according to four dimensions: The partial state allows for five occurrences. In the context of sensor networks this kind of classification is of major importance because it determines the amount of effort necessary for the transmission. Aggregation

14. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: The aggregation process The aggregation process consists of two phases, namely the distribution and the collection phase. Distribution phase: The request is distributed to all nodes in the network or at least to those which can answer it (we may also deal with heterogeneous networks with nodes that have different abilities). However, nodes which can not answer particular requests may still have to aggregate the result of their children. The only thing that changes in a request which is handed down to the tree is the EPOCH DURATION time. It is decreased by the amount of time a node needs itself. The rest is available for its children and their children and so on. A node will answer its parent's request no sooner than necessary, even if the children's results have already arrived and all local processing has been done. This proceeding enables that parent node to sleep as long as possible because a precipitated packet can not occur. Aggregation

15. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ Aggregation TAG: Topology maintenance After the initialization of the tree changes can occur in the network, e.g. nodes may drop out, some could move and others could be newly deployed. Every node keeps a list of neighbors in its range including the nodes' IDs and a quality metrics for the communication with that particular node. Topology changes are handled in two ways: (1)A node keeps an eye on the delivery rate of its parent. This can easily be achieved by means of sequence numbers in the packets which are incremented continuously by the parent. A gap is a hint for a missing packet. The delivery rates of the parents are also eavesdropped. In case of decreasing transmission quality the parent is replaced by a better candidate. (2)A node has not received any messages from its parent node for a longer time (longer as compared to the EPOCH DURATION time). So the node sets its own level to infinity and seeks for another parent node. This means that a parent with higher level than the previous one could be chosen. The new level will be the parent level+1. Note that the node must forward this information to its children as well. These have to find a new parent just as if the former parent node would have dropped out. Note: Every node sends a single request for every EPOCH, so duplicates can not emerge, even if parents are changed within the process.

16. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: The aggregation process Collection phase: A node should be able to sleep most of the time. Only the clock has to keep running to wake up a node in time. As stated above a node can be sure not to receive any results from the children earlier than expected. The time preceding this transmission can be overslept. The children's data are received, aggregated, some local measurements are included and the result is sent to the parent node – if it is already the right time. A node may have to wake up slightly earlier than negotiated with the children in order to account for imprecise clocks. Aggregation Level 1 Level 2 Level 3 Level 4 Level 5 root Measurement and processing network idle Ready to receive Active transmission Sensor node idle (rest) Collection phase after distribution

17. Tiny Aggregation ©Thomas Haenselmann – Department of Computer Science IV – University of Mannheim^ TAG: Example for aggregation Aggregation Temp.: 10 Light: 5 6 Temp.: 10 Light: 15 5 Temp.: 30 Light: 25 4 Temp.: 20 Light: 50 3 Temp.: 10 Light: 15 2 Temp.: 20 Light: 10 1 6 Group AVG 10 10 (6,5) 5 4 3 2 1 Group AVG 10 10 (6,5) 30 25 (4) Group AVG 10 20 50 30 25 Group AVG 10 35/3 (6,5,2) 20 30 (3,1) 30 25 (4) Request: select temp, AVG(light) from sensors group by temp