Initial application (Revision 1: July 8, 1998)

This page briefly describes our initial application. This initial application will be demonstrated in Fall, 1998.

Contents

• Application goals
• Application scenario
• Application demo
• Application components
  • Hypothesis tracker
  • Observation delivery
  • Queries
  • GPS
  • Other components

Application goals

The goal of the initial application is to demonstrate three of the key technologies from the proposal.

• The network-routing algorithms, which allow two wireless machines to communicate with each other even if (1) they are not in direct transmission range (intermediate wireless machines are used as routers) or (2) they are moving (routing tables are continuously updated to reflect current machine locations).

• The mobile-agent infrastructure, which allows the rapid development of robust and efficient network applications.

• The information-clustering algorithms, which automatically discover and create graphical representations of the relationships among text documents (e.g., one document discusses the same subject as a second document).

Application scenario

The application provides operational support to military counter-intelligence teams. First we provide some basic background on military counter-intelligence, and then we describe the application itself.

In general, counter-intelligence teams attempt to discover any hidden enemy activity (i.e., guerrillas or terrorists) in an area that is under the control of friendly forces. For example, suppose the enemy is driven out of a small city but leaves behind guerrillas to hamper friendly forces. Counter-intelligence teams would attempt to identify and seize the guerrillas and their weapons. Alternatively, suppose that the first democratic elections in fifty years are about to be held in a Central American country. Supporters of the old dictatorship have hired a terrorist group to disrupt the election, and the interim government has invited in the U.S. military to ensure a peaceful election. Counter-intelligence teams would attempt to identify and arrest the terrorists.

We will use the election scenario for our demo. As a more specific example of the election scenario, suppose that Natasha, a known terrorist who works for the MMBG (Many May Bad Guys) organization, was spotted entering the country and has been traced to the country's largest city. She is expected to meet with supporters of the old regime and other members of her own group in order to plan one or more bombing attacks on election sites. The counter-intelligence mission is to set up surveillance on Natasha, identify her associates (most importantly the unknown Boris, the ringleader of the old-regime supports), and then make the necessary searches, arrests and weapons seizures as election day approaches. In addition to the specific task of surveiling Natasha and her associates, the counter-intelligence teams would also set up checkpoints and observation posts throughout the city, and conduct interviews with local citizens and arrested terrorists to obtain additional information.

We assume that (1) each counter-intelligence team member has a wireless computer, (2) each team member is assigned to a field-deployed command center such as a observation post (or simply a jeep if a team has been sent in to make an arrest), and (3) all teams report to a single headquarters that is coordinating all counter-intelligence activity in the city. One of the main tasks of the field-deployed command center is to provide a network connection between the team members and headquarters.

Our application provides a subset of the support that these counter-intelligence teams need. Specifically, the application has three main tasks:

• Maintain network connectivity among team members (and between team members and headquarters) even if team members are moving rapidly or are spread out across a wide area (such that network packets must be routed through the computers of multiple team members before they can reach the final destination). The wireless-routing algorithms will be used to maintain this network connectivity.

• Allow team members to send observations of suspicious activity to a central tracker and SALUTE relational database. The tracker, which is oriented towards vehicles, mathematically determines which vehicle observations are most likely the same vehicle.

• Allow team members to make queries against the tracker, the SALUTE database, a black-gray-white database that contains suspected and known terrorists, old-regime supporters and new-regime supporters, and one or more document collections that contain text documents relevant to the current situation and environment (such as news feeds and descriptions of the local culture). The interview teams in particular will make queries against these databases as new information comes to light during an interview; the results will be used to redirect that interview or subsequent interviews. If time allows, the black-gray-white database will include photographs. Then the counter-intelligence teams could take pictures in the field and send them to the database. Also, if time allows, we will replicate each database across multiple machines. Then the application could use RPI's network sensing techniques and Dartmouth's planning algorithms to decide which machines can answer the query the quickest. The information-clustering algorithms will be used to present the query results.

Application demo

We will divide the demo into three distinct phases:

Phase one	:	A team with laptops and Harvard's long-range wireless hardware sets itself up at observations posts across campus and makes observations of "suspicious" moving vehicles; these observations will be sent to the tracker and the SALUTE database. The "suspicious" moving vehicles will be two or more cars that have been marked in some way and are being driven around Hanover (which is the town in which Dartmouth is located). The cars will carry GPS units (and laptops of their own) so that their exact position can be compared with the tracker's results. This phase of the demo demonstrates the static adaptivity of the network-routing algorithms; network connectivity is automatically established among all the laptops. This phase also demonstrates the tracker, which is interesting even though it is not part of the proposal.
Phase two	:	A team with laptops and Dartmouth's short-range wireless hardware is sent to arrest (or follow) a subject. This phase of the demo demonstrates the dynamic adaptivity of the network-routing algorithms; network connectivity is maintained even though the laptops are moving continuously.
Phase three	:	An interview team makes queries against the tracker and the available databases. We plan to have four databases: SALUTE, white-gray-black, and two collections of text documents, specifically news feeds and cultural information. Not all of the databases will be located at Thayer. At least one will be in the computer science department, and at least one will be at Harvard. This phase of the demo demonstrates the information-clustering software, and more than the other phases, the underlying mobile-agent infrastructure.

Depending on hardware availability and other logistics, we might have teams at one or more of the other institutions, such as RPI, Harvard or Illinois.

The audience will be in a Thayer class room where we will show (1) a map that has the locations and tracks of all team members and observed vehicles, (2) the GUI that the team members have on their laptop screens (e.g., one or more team members will be physically in the classroom but virtually out on campus), and (3) other displays that relate to the specific subsystems (such as a throughput and latency graph for the wireless routing software).

Application components

The application, shown in the figure below, can be divided into four main components.

• Hypothesis tracker (component 2). The hypothesis tracker is an existing system that will serve as a sample data repository for the demo application. The hypothesis tracker accepts observations from field units; these observations contain a vehicle description, location, heading and speed (e.g, a large truck heading west at approximately 50 miles per hour at GPS position ...). These observations are structured as SALUTE records and are fed into both the tracker and a SALUTE relational database. The hypothesis tracker uses several statistical techniques to make an "educated guess" as to which observations correspond to the same vehicle. Observations corresponding to the same vehicle make up a track. The tracks are stored in a database and used to answer queries about the current tactical situation.

  In the initial version of the demo, the hypothesis tracker will run at some fixed, central location. In later version, the hypothesis tracker itself will be able to move to the most advantageous network location.

  The hypothesis tracker is not one of the key technologies that are being developed as part of the MURI. It is simply a useful "glue" component for the rest of the application.

• Observation delivery (component 1). Observations must be delivered from mobile team members to the hypothesis tracker. Since field units will typically have an unreliable wireless link into the network, multiple copies of the same observation must be sent along multiple network paths to ensure timely delivery. Different replication strategies will be used for different network environments and for different priority messages. To allow rapid introduction of new strategies into the system, observation delivery will be performed by mobile agents, i.e., each observation is carried by a mobile agent that can decide ``on-the-fly'' which network path to follow and when and where to replicate itself.

  The main difficulty here is that the current D'Agents system is based around high-level languages such as Tcl and Java, which are too slow to allow the most efficient low-level routing. However, these languages are sufficient for prototype applications.

  This component relies on the mobile-agent infrastructure and, most importantly, the wireless packet-routing software from Harvard and Dartmouth. In addition, Illinois has developed several flow-control algorithms, as well as an algorithm for dynamically changing the transmission power of each wireless node (to minimize interference while still ensuring connectively). However, we will probably run out of time before we can integrate the Illinois algorithms into the initial prototype; instead these algorithms will be used in the next prototype.

• Queries (component 3). Team members can make queries against the hypothesis tracker and the various databases. In the most general case, a team member will send an agent to the hypothesis tracker to identify which objects are near her current position (or headed towards her, or headed towards her with a certain expected interception time, or ...). Then the agent will move on to the databases to find any information relating to those objects. Once the agent has its results, it returns to the team member's laptop and presents its results.

  In a more specific case, interview teams will be making queries against just the databases as new information comes to light during the interviews.

  As part of the result presentation, the text documents are automatically clustered into related groups so that the user can browse the documents easily. The tracks themselves will be displayed on a map so that the user can visualize the current positions of the objects of interest.

  Finally, the same routing techniques that were used for observation delivery will be used here to ensure timely delivery of the query and the query results.

  The advantage of mobile agents in the query component is twofold: (1) the agent can continue its task even if the field unit disconnects from the network, and (2) the agent minimizes the amount of intermediate results that are transferred across the typically low-bandwidth network that connects the field unit to the central network.

• GPS units (component 4). All field units are equipped with GPS units. The field unit's current position, taken from the GPS unit, will be automatically included in the observations and in the queries.
• Other components (not shown).

  P.R. Kumar at the University of Illinois is developing a simulation testbed for ad-hoc networks, and Gul Agha at the University of Illinois has developed a Java-based mobile-agent system that uses the actor model. This mobile-agent system includes several abstractions (such as synchronization, itineraries, resource-management constructs and various communication mechanisms) that will be useful to a mobile-agent programmer. It is unlikely that this mobile-agent system can be integrated with D'Agents before fall.

  In addition, Dartmouth and RPI have developed several network-sensing and planing algorithms that an agent can use to decide which copy of a database to visit, which database to visit first, and so on. If time allows, these algorithms will be included in a limited way in the query part of the demo.

Application figure