TAG: a Tiny AGgregation Service for Ad-Hoc Sensor Networks
url show details
You need to log in to add tags and post comments.
| papers | collections | search | login | register | forgot password? |
|
| papers | collections | search | login | register | forgot password? |
|
This paper is about TAG (Tiny AGgregation), a generic aggregation service for ad hoc networks of TinyOS motes. The authors observed that 1) the ability to extract data from ad-hoc sensor networks is the key function in most sensor applications and 2) the data usually tend to be aggregations rather than raw data under situations where communication cost outweighs processing cost. From these, they suggest a distributed low-power aggregation method as a core service of sensor networks rather than an out-of-network extension service. This network service provides a high-level programming abstraction to sensor application engineers so that they do not have to modify low level code or worry about topology, routing and loss tolerance.
An interesting idea here is they view the sensor network as a database and adopt SQL-style queries over a single table whose schema is known at the base station. The output of a TAG query is a stream of values rather than a single aggregate value. Then, they came up with several aggregate functions and classified them to state requirements, tolerance of loss, duplicate sensitivity, and monotonicity.
They evaluated performance of TAG based on simulation by mainly observing communication costs required for different aggregate functions. In general, TAG shows lower communication costs over a centralized aggregation approach where all sensor readings are sent to the base station, which then computes the aggregates. Then, they also present some optimization of the basic TAG scheme for a shared radio channel, hypothesis testing, caching, communication loss-tolerance, etc.
[Comments/Issues]
- The idea, "Sensor Network as a Database," seems to be a good abstraction for development of data-centric and energy efficient sensor applications.
- Latency consideration
Some sensor networks may require freshness of queried data to some degree. This paper doesn’t have any concern about latency. Maybe, for this kind of purpose, it would be a good option to add a real-time requirement specification to the syntax and maintain only fresh data in process of in-network aggregation.
-Programming interface: SQL-style versus C/C++
The SQL-style language is simple and easy to understand if you are familiar with SQL. But, in programmers’ perspective, high-level languages are not always favorable choice. Some people may want to customize aggregate functions for different performance goals while they cannot do with high-level language. What about having C/C++ APIs for the in-network aggregate service?
It is interesting that they provide SQL-like interfaces for sensor aggregate values, even though I'm not sure if they can be really practical in the real applications and programming environment. Also, I think there should be protocols for efficiently identifying faulty sensors in the network, for they might corrupt the aggregate values.
This is a relatively simple idea, but it is nice to see it realized.
Providing an SQL-like interface for queries doesn't seem like a major problem for me, especially since the actual aggregator functions should probably be coded up in assembly anyway, and perhaps pre-loaded on the motes (though distributing codelets might not be a bad idea either).
Also, I agree that the real-implimentation results are more impressive than the simulation results, and I would have liked to see more.
This paper takes the stance that computing aggregates is a *core service* of sensor networks. Thus, there must be adequate low-level support for such a service. In particular, they choose to provide a database like API to the network.
They show that they are more efficient than the naive method of sending raw data to the base station.
Two questions:
1) The approach of this paper is in contrast to the end-to-end arguments we've read earlier in class. One relevant question is how important, computing aggregates is, for sensor networks. If it is the case that the such queries are the most important/frequent uses of sensor nets, then considering it as a core service and optimizing might be defendable. I'm not familiar with this area, so maybe someone who is more familiar could explain the usual scenarios for sensor networks
2) Assuming that such aggregates are useful, but aren't the only requirements of the network(ie raw data is needed from time to time), the question is if in a "realistic" workload, the efficiency of specialized support for such queries outweighs the effort in creating/maintaining it.
Power is one major constraint for a sensor node, so I think major contribution of the paper is to devise mechanisms that can process sensed data, summary/aggregation in the paper, while consume little energy compare to centralized aggregation approach. However, I think instead of comparing their aggregation mechanisms with this centralized aggregation, which clearly seems inferior to their aggregation mechanisms, the authors might need to compare their method with other aggregation mechanisms proposed for wireless sensor networks.
Although the idea in this paper is quite simple, we have to be aware that a power consumption is the most critical issue for any wireless sensor network. So, most nodes in the network have to turn off its wireless component and only turns on its wireless component when it has to send or receive data. With this constrain, it becomes really challenge how to schedule all operations in the system to minimize power consumption.
Moreover, in the wireless sensor network, a model for communication is not well-understood unlike we have a client-server model in the typical network. So, many papers tried to find a suitable model for a different type of application specific traffic / data flow.
This paper is part of the research on sensor databases, so the focus is on SQL-type aggregation queries which may also include grouping (similar as GROUP BY clause). The goal is to design an aggregation framework in network which is energy-efficient. I think the idea in Sec. 6 which makes use of some nice properties of the aggregation operation and perform further optimization like snooping and hypothesis testing.
The idea in this paper is simple, to provide a query language like SQL in database. The difference is it emphasizes the energy-effective and efficient way.
Can we explore the redundancy in data to explore more, say using data mining techniques like svd(pca). There are also related work in SIGMOD.
Does the aggregation function have to be 100% accurate? I mean is it possible to use some randomized technique like Blooming Filter to reduce the operation complexity?