Query/Tasking at Virginia Tech within the DSN Project

1
Query/Tasking at Virginia Tech within the DSN
Project

• Mark Jones
• ECE
• Virginia Tech
• DSN (USC-ISI, UCLA, Virginia Tech)

2
Overview of Query/Tasking Effort _at_VT

• Putting queries and query results in context
• How to make queries within a geographical context
  (not a query language issue)
• How to display query results in a meaningful
  context
• Interested in both the soldier-in-the-field and
  analyst perspective
• Can we provide meaningful, detailed geographic
  data to augment sensor coverage models?
• Power-efficient tasking of sensor nodes
• Once a query arrives in the specified area, how
  do we decide which subset of eligible nodes
  should handle the query?
• There may be many possible subsets of nodes that
  can handle the query
• Developing and experimenting with algorithms to
  balance task load, battery status, and coverage
  area
• These two tasks are linked by their need for
  accurate geographical information for the sensor
  network

3
The Context of Queries

• We envision that the soldier in the field will
  make queries and view their results using a
  map-based display
• Handheld PDA-like devices
• Heads-up displays
• The map-based display must provide enough
  visual/geographic context for the soldier to
• Make meaningful queries
• Be able to make sense of query results that are
  returned by the sensor network
• The map-based display must also be able to show
  the soldier the quality/quantity of sensor net
  coverage
• We believe that the remote user case is simpler

4
The Map-Based Display

• To provide meaningful context in many terrains,
  the map-based display must be show 3D renderings
  of the sensor network area
• Initial 3D images will be static, pre-rendered
  images that provide information on terrain and
  large objects (buildings)
• Next stage will be to provide wireframe views of
  buildings (such data exists for at least one
  military urban test site) the wireframe views
  will change at the user command (e.g.
  walkthroughs)
• Further stages allow for 3D images rendered
  on-the-fly and for viewing of query results in a
  heads-up-display
• 2D images will, of course, be available
• The usefulness of these 3D displays will depend
  on the availability of accurate, detailed
  geographic information for the sensor network area

5
The Map-Based Display System

• Problem the map-based display requires accurate
  geographical information, yet most handheld
  device do not have the storage capacity to hold
  the data nor the processing power to render 3D
  images
• We will break the system into three parts
• Display-oriented component (similar to the
  current user GUI) which is appropriate the
  portable device
• Cache/communication system which holds the most
  recent data for the users locality
• Map server which can be queried for more
  geographic information
• Capable of provide 2D/3D renderings
• Capable of supplying reduced/full models for
  handheld rendering
• This design allows us to strike an appropriate
  balance between portable node capacity and
  communication speeds as well as provide a fully
  functioning system for the remote user

6
The Map Server

• The map server can be any one of a number of
  programs
• BBNs OpenMap has been used for the initial stages
• We are using the work of another group at VT to
  provide us with a high-performance, open source
  system for the modeling and rendering of high
  detail geographic information with immersive
  environments in mind
• The VT IGIS system is composed of three
  components
• The model layer can read in and store
  SDTS-formatted DEMs, DLGs, and DOQs as well as
  other formats
• The rendering layer provides for 2D 3D
  renderings of model data
• The application layer is used to build an
  application using the model/rendering layer
• We are working with the IGIS group to adapt it to
  the needs of SenseIT
• Providing for export of renderings
• Integration of new data formats
• Adaption (if possible) of rendering code to
  handheld device

7
Example of RenderingGrand Canyon
8
Status of Map-Based Display

• Current standalone display has been implemented
  in Java
• Most of the GUI has been ported to a reduced
  subset of Java (pJava) appropriate for a handheld
  device
• Integrated with current version of SenseIT
  software for the August demo
• Expect to import 2D renderings from the IGIS
  system soon with 3D renderings to follow early
  this summer
• Export of model data to follow

9
VT Sensor Tasking Algorithms

• Problem Need to efficiently task the sensors in
  a region to avoid wasting power
  processing/sensing capability
• Task only a subset of the sensors in a query
  region
• Allow sensors/preprocessor/processor to be turned
  off when possible to save battery power
• Use processing/sensing resources on only those
  nodes required to allow for more queries to be
  serviced
• Routing gets the query to the region, it does not
  necessarily directly task the sensor nodes
• The local, distributed tasking algorithms should
• avoid complex negotiations or artificial
  assignment of regions
• allow for sensor nodes to leave and join the
  network on-the-fly
• Focus on provably good tunable methods to
  allow for the desired level of redundancy/accuracy

10
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 sensor node coverage areas overlap, then
  it may be desirable to only activate a subset of
  those sensor nodes
• An independent set is a set of nodes that dont
  overlap (in some specified sense)
• 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
  neighborhoods
• Purely distributed algorithms for each query

11
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
  necessarily 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
• DSN Project queries are routed to these local
  application query servers
• routing by geographic address and application
  type
• No change to routing protocols needed, rather the
  AQSs are the nodes that accept the queries
• queries may be accompanied by mobile code
• The local application query servers must be
  monitored locally to ensure they are still
  functional
• limited mobility

12
Independent Set Computation

• The selection of a maximal independent set (MIS)
  provides for a node set that is at most one hop
  from all other nodes
• The distributed algorithm selects a set of nodes
  to belong to the MIS based on a combination of
  random numbers and a function of battery status,
  task load, etc.
• Communication required by the algorithm is
  one-hop only
• Scalable Requires O(log(n)/loglog(n))
  messages/steps
• Tolerates dropped messages w/o deadlock

13
Simulation Results

• Simplistic OpNet simulation
• assign all algorithm vs.
• MIS-based assign subset algorithm
• 100 nodes randomly distributed in a square region
  with an overabundance of nodes
• Not surprisingly, the average battery power and
  the number of dead nodes are much better for
  the MIS-based algorithm
• Need to move to more realistic simulation and
  more complex MIS-based algorithm

14
More Advanced Scenarios

• Moving sensor nodes
• Sensors attached to vehicles/aircraft in the
  field
• How to use these to augment ongoing queries?
• Steerable sensor nodes
• Unmanned aircraft/vehicles
• How should these be steered to best effect?
• Deployable, stationary sensor nodes
• Can ask for more sensor nodes to be deployed to
  fill-in weak areas dictated by the coverage
  model in combination with user queries?
• An AQS (or set of nodes) could request insertion
  automatically

15
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)/loglog(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
• Algorithms simple enough to run in the
  pre-processor

16
Status of Sensor Assignment Algorithms

• We have implemented scalable versions of these
  independent set algorithms in other contexts
• We have a basic version implemented in an OpNet
  simulation and need to transition to ns
• We will implement the local application query
  servers as part of the DSN effort in the coming
  months
• Following the evaluation of that effort, we will
  pursue the non-AQS based distributed algorithms
• The goal is to evaluate this methodology for
  future integration into the overall SenseIT effort