Initial application

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

Contents

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

Application scenario

There are two kinds of mobile battlefield users - soldiers and commanders. Each user has a laptop computer that can communicate with other nearby computers through a wireless network. In addition, there are some number of base stations that allow the computers to communicate with the central, wired network. The users and computers are moving and only some of the computers will be in range of a base station at any given time. Thus some computers will need to route their transmitted packets through other mobile computers, which in turn will deliver the packets to a base station.

Each user has two main tasks: (1) deliver observations about the current battlefield conditions to a central tracking station (e.g., an enemy tank one mile north of my position is moving west) and (2) query the central tracking station (and other databases) for information about the current battlefield conditions. The two kinds of users will perform different kinds of queries. The soldiers are interested in the current location of friendly and enemy units, the local geography, and critical, immediately relevant orders. Most of a soldier's queries will be standing queries, i.e., the relevant information will be automatically delivered to the soldier's computer as the soldier moves through the battlefield. Commanders are interested in a wider variety of information and will perform additional queries against available textual information (such as equipment technical specifications, memos, reports, suggested procedures, and so on).

Application demo

Application components

The application, shown in the figure below, has 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 ...). 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 battlefield 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 field units 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 will use the network-sensing techniques from Dartmouth, the network-monitoring and prediction techniques from RPI, and most importantly, the wireless packet-routing techniques 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). Field units (as well as command units) can make queries against the hypothesis tracker and various textual databases. In the most general case, the field unit will send an agent to the hypothesis tracker to identify which objects are near the field unit's current position (or headed towards the field unit, or headed towards the field unit with a certain expected interception time, or ...). Then the agent will move on to the textual databases to find technical specifications, memos and reports that are related to the objects identified in the previous step. For example, if a tank is heading towards the field unit, the agent might retrieve a text document that describes the tank's capabilities. Once the agent has its results, it returns to the field unit and presents the results to the user.

  As noted above, we distinguish between two types of field units, soldiers and commanders. Soldiers will be interested primarily in the location information from the tracker, and most of their queries will be standing queries.

  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.

  Some queries will involve only the textual databases since the user might simply need additional information about a known object.

  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 unclear whether there will be time to integrate this mobile-agent system with D'Agents before fall; it will be integrated in time for the next prototype, however.

Application figure