Impact

1
Dynamic Sensor Networks

• New Ideas
• Power-aware link and routing protocols. Exploit
  fine-grained power control of radios for energy
  efficient connectivity. Maximize sensor
  networks 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.

Event
Target
COTSPDA
Target

• 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.

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
Approach to GUI Front-End

• 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

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 Xs 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 doesnt 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
  Xs if X was poison gas, then the correct local
  application would be told and it would give the
  GUI the correct display (different than wed
  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 Xs 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 isnt 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 dont
  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 dont
  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