Dynamic Sensor Networks

1. Impact GPS leveraged for geo-referenced identity, and low power communications synchronization. Up to 100x communications power reduction. Standard APIs implemented as Java class libraries and browser-based user interfaces provide code mobility, code reuse, and platform independence. High-level spatial and context “anycast” addressing enables dynamic specialization for augmented awareness and collaborative consensus applications. New Ideas Power-aware link and routing protocols. Exploit fine-grained power control of radios for energy efficient connectivity. Maximize sensor network’s operational lifetime through energy-aware routing. GPS-aware link protocols. GPS-synchronized ultra-low-power communication. Spatial addressing and connectivity. High-level addressing, unicast, multicast, anycast, and gathercast communication based on spatial referencing of the nodes. Mobile code and web technology. Embedded Java APIs for code portability and browser-based topographical map interface for visualizing dynamic data from sensor net. SmartSensorNode SmartSensorNode SmartSensorNode Dynamic Sensor Networks Event Target COTSPDA Target Milestones Sensor Control API Specification FY00 Q1 Topographical Map Interface Definition FY00 Q1 Network Services API Specification FY00 Q2 GPS-Aware Link Protocol Experiment FY01 Q4 Network Services PDA/Laptop Experiment FY01 Q4 Integrated Sensor-Kit Experiment FY02 Q4 Brian Schott PI, Bob Parker (USC/ISI), Mani Srivastava (UCLA) Co-PI, Mark Jones (Virginia Tech) Co-PI

2. Virginia Tech Tasks in DSN (1) • GUI front-end for sensor networks • Users can enter queries in a map-based format • Queries results are displayed and tracked over time within the same format • Status of sensor network can be examined • coverage, battery life, communication information, etc. • Will integrate with the sensor.com node system in SenseIT via the U-Maryland query interface API • Will integrate the GUI with the Rockwell nodes under DSN • Will run on a handheld WinCE device and have portable to other platforms by using Java (pJava)

3. Virginia Tech Tasks in DSN (2) • Queries in the proposed sensor networks in SenseIT are expressed as “Tell me if you see event(s) A in the Z-meter circle around point X,Y” • Proposed routing protocols can get this query to the correct region of interest • Routing protocols alone cannot decide which sensor nodes within the area of interest should be tasked • Efficiency dictates that the minimal subset of sensors in the region should be tasked to reduce the resources required as well as to maximize the number of potential tasks • We are looking at strategies based on independent sets for addressing this issue

4. One aspect of the DSN project is the design and implementation of a map-based GUI front-end for the sensor network This GUI front-end should support multiple query languages formulated under SenseIT multiple sensor platforms developed under SenseIT multiple local applications that perform specialized processing on sensor results (e.g., may want to do image processing on an image taken off the sensor net) execution on a variety of operating systems and platforms including PDAs, laptops, PCs, and workstations Approach to GUI Front-End

5. Map-Based GUI Design • The GUI accepts user queries and presents results in a map-based context • multiple layers • satellite imagery • topographical maps • buildings, etc. • Formulates queries in the query language(s) expected by the query manager • Allows multiple local plug-in applications to send queries and use XML to display results on the GUI

6. Expected User Queries • “Are there any X’s in area Y right now?” (One-time) • X could be a single thing (a T-72), a collection (tracked vehicles), or simply anything anomalous (GUI will allow for combinations) • The GUI doesn’t know what an X is, but it does know how to express that in the query language and which local application to interface with for X’s; if X was poison gas, then the correct local application would be told and it would give the GUI the correct display (different than we’d expect for T-72 query) • The GUI will let the user specify the area Y on the map/photo using a pen or mouse or Y could be “where I am now” • “Let me know if/when you see any X’s in Y?” (Persistent) • X is the same as above, Y could be “where I am” but moving • The GUI does know that the query is persistent, but it is the job of the query manager to handle this persistence; need to eventually work out how to express the change in Y to the query manager

7. Issues Resolved Since 10-99 PI Meeting • Browsers: The current set of browsers available for PDAs make a browser-based solution unattractive. We are using a pure Java solution • JVM: Sun has released a version of their JVM for the WinCE platform (pJava) • pJava has a much smaller footprint than Java2 • we are currently running on laptops • we are porting our Java2 implementation to pJava to run on a handheld PDA • BBN Openmap: • We think BBN Openmap provides Java routines that are going to help us read in a variety of data formats • The entire Openmap itself isn’t suitable for a PDA application

8. Issues Resolved Since 10-99 PI Meeting • Source of Map Information: The GUI allows multiple map/photo formats and contexts • satellite imagery, topographical maps, city maps, etc. • we are using ArcView (GIS) to get data • we are also taking with BBN on data sources for Aug demo • GPS/Radio Interface: The PDA/laptop version of the front-end should have an interface to a GPS/radio unit • we have directly interfaced to a sensor.com database node • we have interfaced to the Rockwell emulator and will take the next step soon • Query Language: Need to get specifications on the query language(s) to allow formulation of queries by the GUI

9. Status of GUI • The GUI is implemented in Java2 • accepts user queries • displays query responses • connects to a sensor.com gateway node • connects to the Rockwell gateway node protocol • will demo with sensor.com nodes today • Porting to pJava • Integrating with GIS & OpenMap • Building Sensor Network Management interface for GUI • Need to get final API specs from U-Maryland and then integrate

10. VT Sensor Assignment Algorithms • As noted, we want to efficiently task the sensors in a region to avoid wasting power • turn off sensors and sensor preprocessing • avoid reporting redundant results • avoid processing of acquired sensor data • Routing only gets the query to the region, it does not directly task the sensors • We want to avoid any type of centralized sensor tasking system • avoid any assignment techniques that run at the user/gateway level • avoid storing any (semi)permanent state of the sensor network • avoid complex negotiations or artificial assignment of regions • allow for sensors to leave and join the network on-the-fly

11. Independent Set Algorithms • Each sensor node has different coverage areas for each of its sensors (e.g., infrared differs from acoustic in range) • If ten sensors overlap, then it may be desirable to only activate a subset of them • An independent set is a set of nodes that don’t overlap • we have distributed algorithms that are guaranteed to quickly generate such a subset • We are investigating the use of this algorithm in two stages • Electing Local Application Query Servers in neighborhood • Purely distributed algorithms for each query

12. Local Application Query Servers • Local application query servers are elected within a network • these query servers are chosen using the I.S. algorithms to provide the necessary coverage for each application (acoustic, seismic, etc) • note that the query servers themselves don’t necessary have to cover the area completely, but they must be in contact with nodes that can cover the area (they maintain the status of local nodes) • these servers task the sensor nodes in their area of responsibility • Queries are routed to these local application query servers • routing by geographic address and application type • queries may be accompanied by mobile code • The local application query servers must be monitored locally to ensure they are still present • limited mobility

13. Purely Distributed Algorithm • All the sensors listening in the area specified by a query are eligible to service that query • required if we have rapidly moving sensors and/or high sensor loss rates • Queries are routed to areas without knowing which sensors will answer (queries may contain mobile code) • The sensor nodes in the area negotiate using independent set algorithms (nearest-neighbor communications) to determine who will cover the area • log(N) rounds of very short messages • set of nodes selected based on power status, query load, etc. • This selection is very fast, no state of neighbors is maintained, and is a pure distributed algorithm

14. Coverage Areas in a Sensor Network

15. Selected Subset

16. Status of Sensor Assignment Algorithms • We have implemented several versions of these independent set algorithms in other contexts • We are currently building the capability to explore the implementation of these algorithms through a combination of simulated and physical sensor nodes • We will implement the local application query servers as part of the DSN effort in the coming months • using the independent set algorithms as the election method • Following the evaluation of that effort, we will pursue the purely distributed algorithms for mobile sensor networks • The goal is to evaluate this methodology for integration into the overall SenseIT effort