In-Network Processing Comparison

In Sections 6.3.1 and 6.3.2, we outlined two ways that in-network processing can be implemented utilizing the WSNFS framework, namely on-demand and continuous data aggregation. In the following, we will compare these processes with some of the traditional approaches typically applied to data aggregation in WSN systems. By considering how data aggregation problems are addressed with traditional systems, it should become apparent how helpful the WSNFS framework is for implementing in-network processing applications within the WSN environment.

In Section 6.3.1, we presented two methods in which the WSNFS framework may be used to implement an on-demand process that aggregates sensor data. In the first simple example, we discussed a centralized approach in which we leveraged the data publishing aspects of WSNFS to allow any node in the network to access data from other parts of the network. In the second example, we discussed how to utilize network topology information in combination with the data sharing aspects

of WSNFS to implement a distributed algorithm for data aggregation. In this discussion, we will address both approaches from a traditional perspective.

In traditional systems, the centralized on-demand algorithm for data aggregation must be done without any direct knowledge of network topology. In these systems, any sensor node that initiates the data aggregation has little, if any, information about the size of the surrounding network, and as such the initiating node’s only option is to broadcast a request for the needed sensor data to the network at large. This in itself would not be a problem except that now the initiating node does not know how many replies it might receive in response to its request. This causes several issues ranging from general network congestion to algorithm termination determinism problems. On the other hand, as we saw in Section 6.3.1, this type of algorithm is trivial on a system supported by WSNFS, because the initiating node can directly view network topology and the available remote data. The WSNFS node can then either broadcast a request or sequentially request data from each of the nodes on an individual basis as needed. Additionally, in a system supported by WSNFS, any node attempting to calculate an aggregate value can utilize the network topology available to directly establish a limit to the scope of the operation, keeping communications and time required to a minimum.

In general, the distributed aggregation algorithm presented for WSNFS in Section 6.3.1 would not be possible using traditional methods, primarily because it relies on each node having information about the network topology. As such, traditional systems generally take a different approach to distributed data aggregation problems. Effectively, a system without WSNFS must resort to some kind of message passing

algorithm that does not need global network coordination. Examples of this are found in statistical aggregation methods (e.g., [48]) in which nodes systematically share data with 1-hop neighbors only and continually calculate marginal probabilities to estimate the true aggregate value of a variable. This type of aggregation requires continuous communication to allow the probabilistic values to converge and may not be considered very flexible as a general purpose aggregation method. On the positive side, this type of aggregation does not require any global network coordination. Aside from the statistical methods, on-demand distributed aggregation problems may also be addressed with in-network query-based algorithms (a survey of which is presented in [14]). As discussed in Section 1.2.2, in-network query provides a reasonable method for distributed aggregation. However, as we outlined in Section 6.1, in-network query systems lack the flexibility needed for a general purpose in-network processing solution. To illustrate this point, implementation of an in-network query system is possible using the WSNFS framework, but the converse is not the case.

For continuous aggregation algorithms, as discussed in Section 6.3.2 with WSNFS, the traditional approaches tend to utilize either a statistical method or some form of a directed diffusion algorithm. Directed diffusion was first introduced in [50], however many variations exist based on this approach. In general, directed diffusion-based algorithms require each sensor node to keep track of which 1-hop neighbor forwarded a request for data. Upon receiving a request (referred to as an interest), each node assigns an attribute (metadata) to any locally acquired data that matches the request and sends its response on a path determined by a communications gradient. In directed diffusion, requests are broadcast through the network, and each receiving

node begins acquiring data to service the request. The diffusion aspect of the algorithm has to do with a virtual gradient established based on the network path taken by the request. This gradient determines the direction of data flow through the network. As such, there is generally no global information on the network available to sensor nodes, and thus, each node simply forwards collected data to the 1-hop neighbor from which it received the original request (according to the established gradient). Aggregation in directed diffusion algorithms is only possible by having each node cache data with a matching attribute as it is passed along through the network. Each node continually calculates the aggregate based on its locally cached data. These types of systems require near constant (though somewhat optimized) flooding of sensor data throughout the network to find an aggregate value. Flooding of data for aggregation in directed diffusion is a direct result of the fact that nodes in the network are not aware of where a data request originated. Effectively, this means each node must always assume the request originated from the neighbor that relayed the original request. As we saw from Section 6.3.2, WSNFS significantly simplifies applications that require continuous aggregation by comparison.

Overall, we see that the WSNFS framework provides services that greatly enhance in-network processing applications programming. This is accomplished by providing topology and data-sharing capabilities throughout the network. A comparison to existing approaches shows that WSNFS capabilities significantly simplify in-network processing by providing mechanisms to distribute both computation and data effec- tively and efficiently.