Projects:DFuse

From Epl

Vision

Simple in-network data aggregation (or fusion) techniques for sensor networks have been the focus of several recent research efforts, but they are insufficient to support advanced fusion applications. We extend these techniques to future sensor networks and ask two related questions:

1. What is the appropriate set of data fusion techniques?
2. How do we dynamically assign aggregation roles to the nodes of a sensor network?

We have developed an architectural framework, DFuse, for answering these two questions. It consists of a data fusion API and a distributed algorithm for energy-aware role assignment. The fusion API enables an application to be specified as a coarse-grained dataflow graph, and eases application development and deployment. The role assignment algorithm maps the graph onto the network, and optimally adapts the mapping at run-time using role migration. Work on DFuse is ongoing.

Architecture Overview

Sample application

Consider a simplified sensor network based surveillance application that provides filtered and collaged images efficiently to a security guard. Let the directed graph in the image below be an example deployment of this application across nodes that can perform computation and relay services in addition to connecting a physical sensor to the network. Three cameras feed video into the network, which performs in-network computation to provide the security guard with the required information.

Figure 1:Sample DFuse-based application: Distributed, in-network video surveillance

The security guard's PDA might be able to perform all of the computations, but performing them in a distributed fashion in the sensor network enables power saving, critical for application longevity. Furthermore, migrating computation (and associated communication loads) within the sensor network dynamically while the application is running can further increase application longevity.

Fusion Channels

Figure 2:Fusion Channel

DFuse provides a Fusion Channel abstraction which encapsulates a general "fusion function" (filter, collage, ...), providing data buffering and synchronization facilities. Instances of these fusion channels can be migrated across nodes in a sensor network at runtime.

Cost Functions

Figure 3:Fusion Channel Cost Function

DFuse's Placement Module employs application-specified cost functions to drive the dynamic migration of fusion channels in the network. MT1 is one such function meant to minimize communication (and hence radio power drain). With fusion channel f mapped to n2, aggregate source-sink bandwidth is 9kbps. As f appears to currently be performing data contraction, migrating it to n1 (closer to the sources) should lower this communication cost to 6 kbps. Anticipated migration overhead is ignored here, but is used in DFuse deployments.

Determination of when to migrate a particular fusion channel is a local decision, evaluated periodically by nodes hosting fusion channels. Currently, only immediate neighbor nodes are queried to see if their cost for hosting the fusion channel would be lower, but we are exploring local-minima escape mechanisms such as including 2- or 3-hop neighbors in a more expensive, but less frequent decision.

Putting it all together

Figure 4:Fusion Channel Architecture

Given an application task-graph, application-specific fusion functions and cost functions, the DFuse middleware deploys the application on a target sensor network. Each node in the network provides monitoring information to DFuse's placement module (remaining battery; and network, CPU, memory usage). Following an initial "naive" deployment, the mapping of the task graph to the nodes in the network is dynamically adjusted by the placement module's cost-function evaluation in response to application and resource behavior.

Current Work

Figure 5:iPAQ Farm

We have published experiments on an iPAQ farm show that the fusion API has low-overhead, and the role assignment algorithm with role migration significantly increases the network lifetime compared to any static assignment. We are continuing research by:

• exploring additional mapping heuristics
• exploring placement and device synergies (CPU clock, voltage scaling)
• performing simulation-based performance and scalability studies
• collecting CPU and memory usage in addition to communication for cost function inputs
• integrating support for application developers: tools for describing DFuse inputs and for runtime debugging
• using analytical models for discovering performance bounds
• developing mechanisms to efficiently support multiple concurrent applications
• developing more efficient sensor network stacks suitable for DFuse
• exploring stack and heuristic support for mobility efficiency
• and using driving applications on real deployments.

Publications and Collaborators

About DFuse Publications Collaborators

Projects SenorLab