This page describes the demo scenario.
The demo mission is an Urban Warfare mission, specifically "securing a building". A platoon of soldiers observes a building that is a known location of insurgent activity, and report all activity to Battalion HQ. Based on observed activity, Battalion HQ determines that two important insurgent leaders are in the building. At that point, Battalion HQ orders the platoon to secure the building and capture its occupants.
This scenario has three advantages: (1) it is of broader military interest than our intelligence team of last year; (2) we can use all of our existing software and database information (e.g., the terrorists from last year are inside the building); and (3) it involves two different military entities -- the platoon and Battalion HQ -- which allows us to demonstrate each technology component where it makes sense, rather than trying to use all the technology components in a single entity's task.
In particular, we expect that the platoon will mainly demonstrate the networking components, as they send back reports about their position, the building, and the insurgents, and as they make simple queries about the building and insurgents that they are observing. These simple queries will be made against the black-gray-white and SALUTE databases.
On the other hand, Battalion HQ will mainly demonstrate the information-retrieval components, as the HQ analysts make complex queries to determine whether the insurgent leaders are actually in the building. These queries will involve the text databases, the construction tool MACE, and so on. However, we will also demonstrate the networking components with Battalion HQ, specifically we will shut down HQ, move it to a new location, and turn all the computers back on, to demonstrate that network connectivity among the HQ machines is restored "instantaneously" due to Aprl's ability to discover the network topology.
The agent infrastructure will play an important role in both the HQ and platoon components.
We will perform the "outside" portions of the demo (i.e., the platoon and Battalion HQ when it is moving) at Dartmouth, and make appropriate video and computer recordings for playback in Washington. We will perform the "inside" portions of the demo (i.e., Battalion HQ except when it moves) in Washington. We may feed some portion of the recorded platoon data stream into Battalion HQ during the Washington demo. Note that we will record the inside part of the demo at Dartmouth also as a backup.
In contrast to last year, we will instrument all of the demo software to collect a range of statistics about demo performance (e.g., bandwidth usage, agent throughput per machine, query completion times, etc.)
The figure below illustrates the demo scenario.
The demo mission is an Urban Warfare mission. Specifically, a platoon is sent into an urban environment to (1) observe a building that is a known location for insurgent activity, (2) wait until important insurgents are inside, and (3) then seize the building and its occupants. This mission involves three military entities.
Individual warfighter. Each warfighter has a wireless computing device and makes reports about what is happening in the field (via SALUTE). The reports go through the platoon leader for approval and forwarding to Battalion HQ. The warfighters are on foot.
Platoon leader. The platoon leader has the same wireless computing device as the warfighters. The platoon leader receives and forwards SALUTE reports from the warfighters, generates additional SALUTE reports for their own observations, and queries local and remote databases (e.g., BGW) for mission-relevant information. The platoon leader does planning and coordination for the local team. The platoon leader is most likely on foot, but might have a vehicle. In any case, there is some vehicle that serves as a gateway between the platoon and Battalion HQ (e.g., the vehicle would have the same wireless computing device as the soldiers plus a satellite uplink to the rest of the military network, and would forward data traffic in either direction as needed).
Battalion HQ. Battalion HQ has some number of analysts (in particular, the S2-intelligence office and the S3-operations office) who draft the original mission plan, get the battalion commander's approval, issue the orders to the platoon, and update the plan based on what happens on the ground. The analysts review the SALUTE reports coming back from the field and examine a wide range of other data sources (BGW, newsfeed, etc.) during the planning and re-planning phases. Battalion HQ is a tent encampment, but can move. A real Battalion HQ often moves frequently.
The mission begins when the platoon receives orders from Battalion HQ to observe and secure the building. The mission then can be divided into four phases.
Phase one: Going to the building. The platoon moves toward the target building and provides updates along the way. The current locations of the platoon members are reported automatically to Battalion HQ. Other information, such as vehicle activity, is entered and reported manually. In both cases, the reports are sent back as SALUTE records. (Non-position) observations from individual soldiers are sent first to the platoon leader, who reviews them and forwards some of them to Battalion HQ.
During this phase, a small group of soldiers needs to temporarily move out of (wireless transmission) range of the other soldiers. RPI's network-sensing software detects that the soldiers are moving out of range, and notifies the messaging system so that any pending observations can be transferred off of the soldier's machines. RPI's software also notifies the soldiers of the impending network disconnection. While the soldiers are out of range, they continue to enter observations. The active-messaging system queues these observations at the disconnection boundary, and transmits them to Battalion HQ as soon as the soldiers move back into range and the disconnection goes away.
(Note that RPI's current software detects when a machine is losing all of its network connections. Depending on the state of RPI's software near the end of the summer, we will demonstrate the active-messaging system by having the small group of soldiers break away from the main group as described above, and then demonstrate RPI's network-sensing software by having a single soldier break away from the small group.)
To further demonstrate network disconnections, the soldiers might take different routes to the target building. The feasibility of doing this will depend on which building we use at Dartmouth, and whether we can maintain at least partial contact with a gateway machine during the journey to that building.
Diagram: How the soldiers might move to create the necessary network disconnections
This phase of the demo primarily demonstrates (1) Harvard's Aprl routing algorithm, which maintains network connectivity among the moving soldiers, (2) RPI's network-sensing algorithms, which detect the impending disconnection, and (3) the simple active-network software, which allows the observations (wrapped inside mobile agents) to queue themselves up at the network-disconnection boundary.
Phase two: Observation. The soldiers observe the activity in and near the building, and send back appropriate SALUTE reports. In particular, a person enters the building. The soldiers send a description of the person (as SALUTE reports) to Battalion HQ. Battalion HQ searches the BGW and SALUTE databases to determine if any of the descriptions match known insurgent leaders (e.g., an insurgent leader might have some noticeable physical attribute such as a scar). Battalion HQ sends photographs of any insurgent leaders that match the description to the soldiers. The soldiers confirm whether the person they saw is in fact one of the insurgent leaders in the pictures.
In the demo, the person turns out to be an insurgent leader. Thus Battalion HQ knows that one of the important insurgent leaders is now in the building.
During this phase, the platoon leader will also make some simple queries against the SALUTE and BGW databases. For example, after the mission changes from observing to securing the building, are there other platoons close enough to help secure the building? Where are the closest medical teams? Have other bad guys been sighted at other locations within the city?
Phase I (Going to the building) and Phase II (Observation) will overlap. In particular, the small group that breaks away from the main group will be the group that sees the first bad guy enter the building, and they will see the first bad guy while they are disconnected from the network. This will demonstrate how critical it is to queue up messages (observations) at the disconnection boundary, and then transmit them them the rest of the way as soon as the disconnection goes away.
This phase of the demo primarily demonstrates Dartmouth's mobile-agent system D'Agents, which is used to implement all of the database interfaces and application-specific queries.
Phase three: Information gathering (persistent and complex queries). The analysts in Battalion HQ will have established persistent queries against several of the text databases. These persistent queries search for any new information relevant to the insurgent group (and the building itself). At some point, a new phone-call transcript in the Intelligence Summary database matches the persistent query (e.g., it originates from or goes to the building in question, or the building's geographic area in the case of a cell phone, and appears to mention insurgent activity.) The analysts then do additional queries against the other databases to see if the phone call was made by one of the insurgent leaders. For example, the analyst might search both the news and BGW databases to see if any of the names mentioned in the phone call are aliases for insurgent leaders or otherwise associated with the insurgency leadership. At this point,
In the demo, the phone call does originate from a (different) insurgent leader inside the same building, so Battalion HQ now knows that two insurgent leaders are in the building. At this point, Battalion HQ orders the platoon to secure the building and capture its occupants.
This phase of the demo involves more complex queries than the previous phase, and primarily demonstrates (1) clustering algorithms for graphically organizing query results, (2) MACE, which is a visual construction environment that a non-programmer can use to construct complex query agents, (3) Serval, which is an agent-based retrieval engine for text documents, and (4) cluster-based persistent queries.
Phase four: Battalion HQ moves. Once the platoon has captured the building (not explicitly shown in the demo), the Battalion HQ relocates for the sake of some future mission. The HQ shuts down its computers, moves to the new location, and restarts all the computers. The internal HQ network re-establishes itself "instantly" after the machines power up, due to Aprl's ability to dynamically discover and set up network routes.
This phase again demonstrates Harvard's Aprl routing algorithm.
The platoon will be involved in several tasks:
Automatically send GPS positions to the other platoon members and to Battalion HQ. These position reports will not be stored in the SALUTE database.
Send SALUTE reports to the platoon leader and to Battalion HQ. Later we might send the reports only to the platoon leader, and have the platoon leader filter the reports and forward only some reports to Battalion HQ. Later we might also give the platoon leader a local copy of the SALUTE database (or a subset of the SALUTE database).
There are several kinds of SALUTE reports that will be sent during the demo:
Person with a certain description (i.e., the first insurgent leader) enters the building
Other people (entering, leaving, on the roof, at a window, etc.)
Vehicles (arriving, leaving, parked, driving past, etc.)
Lights in the building (going on, going off)
Notes:
The last three types of SALUTE reports lead up to the first (e.g., car arrives with four occupants, three passengers get out, one of the passengers is the insurgent leader, etc.)
Many SALUTE reports will be pre-canned, i.e., the text will be written ahead of time and the demo participant will simply select desired report from a list of available reports. This will make the demo easier for the participants and will eliminate one source of mistakes.
Platoon leader makes queries against remote SALUTE and BGW databases, e.g., "Show me the location of the three closest medical teams.", "Show me the location of nearby platoons that can help secure the building.", and "Have other bad guys been sighted at other locations within the city?"
Battalion HQ sends confirmation request with one or more photographs. For now, send to the soldier who made the initial observation of the person in question. Later, send to the platoon leader, who forwards it to the soldier at the appropriate time (i.e., at a time when it will not distract the soldier from more critical tasks).
Move in a way that creates network disconnections, since we need to demonstrate the active-messaging and network-sensing systems. See the disconnection diagram for a preliminary plan.
Databases. The analysts at Battalion HQ make queries against five military databases during the course of the mission.
| Database | Type | Query system |
| News | Text | Serval (replacement for last year's Smart) |
| Background | Text | Serval (replacement for last year's Smart) |
| Intelligence Summaries | Text | Serval (replacement for last year's Smart) |
| BGW | Relational | mySql (same as last year) |
| SALUTE | Relational | mySql (same as last year) |
We will install replicated copies of each database, at the different universities involved in the ActComm project, and on laptops that we bring to Washington. In most ways, these replicated copies are only a building block for future work, since we will probably not have time to integrate Hiro's planning algorithms (which allow an agent to plan its migration path when there are multiple copies of needed services). This year an agent will just pick randomly among the available copies, and (possibly) fall back to a secondary copy if the primary copy is down. In the demo, we will intentionally break the Internet connection to bring down the primary copy.
BGW database. The BGW database will contain entries for six types of people.
Insurgent Leader 1 (observed entering the building)
Insurgent Leader 2 (makes telephone call)
n people who resemble Insurgent Leader 1 (these can overlap with the three groups below)
other bad guys in the same group
other bad guys in un-related groups
people who are not bad guys
We must generate the BGW entries for the first four categories manually, since we have to ensure that physical descriptions are similar when needed, that the leaders are associates of the group members, and so on. We can generate the BGW entries for the last two categories automatically.
Intelligence Summaries. The Intelligence Summary database will contain just phone transcripts (since presumably entries will be tagged by type so we could immediately filter the summaries to get just phone calls anyway). Each phone transcript has several parts:
Time of call
Phone number (source, target)
Address (source, target) if landline
Region (source, target) if cell phone
Text transcript of the phone call
We must manually generate the phone transcript for the call made by the second insurgent leader, as well as transcripts for calls that are similar to that transcript. We can automatically generate other transcripts.
One way to automatically generate phone transcripts is to obtain sources
such as
Movie scripts Transcripts of presidential phone calls Transcripts of presidential news conferences
divide each source into multiple fragments, and pretend that each fragment is
a phone call between two people.
Note that the military does not actually store phone transcripts in an Intelligence Summary database, but the real database is classified, so we will just use our own name and format for the database (i.e., the Phone Transcript Database or PhoTran).
SALUTE database. We need a few pre-generated SALUTE reports for the platoon leader's queries (e.g., locations of medical units), but nearly all of the SALUTE reports are generated during the demo itself.
News database. We will get new news articles for this year's demo, but we will keep all of last year's articles (Lockerbie and Dartmouth articles) so that we have more distinct articles to search. We will sanitize the Lockerbie articles so that they do not include the names of the real Lockerbie terrorists and victims (and do not mention Lockerbie by name).
For the new news articles, we will get a set of news articles relating to Kosovo and Yugoslovia, and sanitize them so that they refer to Hanover and Norwich. Kosovo and Yugoslovia are a military situation in which soldiers might need to secure a building in an area that is largely secure otherwise. One possible source for this news article is the AP newswire (http://www.apalert.com).
More specifically, we now plan to include the following articles in the database:
Background database. The background database will contain sanitized encyclopedia articles about Kosovo, Albania, Macedonia, etc., as well as unsanitized articles about other parts of the world. We will also keep all of last year's articles (Libya, etc., IRA, PLO, etc., Dartmouth history).
Persistent queries. The persistent queries will be entered at the beginning of the mission, not in response to any mission event. The queries could involve:
Descriptions of the insurgent leaders
Building name, address, range of telephone numbers, etc.
Keyword descriptions of insurgent activities of interest
The persistent queries will involve four of the databases:
SALUTE
Intelligence Summaries
News
Background
Any new SALUTE report, Intelligence Summary, news article or background article that matches the persistent queries will be forwarded to Battalion HQ for review.
For the purposes of the demo, many documents from all four databases will match the persistent queries, but only one will be important to the mission, namely an Intelligence Summary that contains a transcript of an intercepted phone call. The transcript, possibly after performing additional queries to learn about the names and activities mentioned during the phone call, will indicate that the second insurgent leader is in the building (the first insurgent leader was observed entering by the platoon).
Thus the one critical persistent query is the one that looks for phone transcripts that mention insurgent activity. The agent that handles this persistent query might perform multiple steps:
New transcript arrives at the IntSum database.
Agents checks if it originates from or goes to the insurgent building (i.e., correct address or cell-phone region, correct time, etc).
If so, agent extracts names from phone call, and sees if any of those names are (aliases for) the insurgent leader or his associates. The agent will extract aliases and associates from the BGW database before it starts waiting for new phone transcripts.
If so, agent optionally checks transcript text for mention of insurgent activity.
Agent sends relevant transcripts to Battalion HQ.
The other persistent queries, particularly against the News and Background databases, will be used to demonstrate the clustering algorithms.
Question: In a real military operation, would the HQ analysts use a persistent query, or would they just tell the IntSum analysts to notify them of any "interesting" phone calls? Our view (confirmed by discussion with Jody) is that phone-call transcripts are entered into the IntSum database much faster than the IntSum analysts can review them, so the HQ analysts would ask the IntSum analysts to keep their eyes open, but would also establish the persistent query. In this way, the HQ analysts would maximize their chances of getting timely notification of the phone call.
Confirming that a soldier actually saw the first insurgent leader. There are two ways for a Battalion HQ analyst to confirm that a SALUTE report form the field refers to one of the insurgent leaders, (1) run a series of queries by hand, or (2) launch an agent that will automate the same queries. In both cases the series of queries will be something like
HQ has a SALUTE record that contains a person's description.
Queries BGW with that description and gets back more than one possibility
Queries BGW to get the known associates of each of the candidates
Queries the News database for names, aliases, associates, organization, etc.
Ditto for IntSum and Background.
Ends up with a few prime candidates.
Sends photographs of prime candidates to the soldiers for confirmation.
Battalion HQ makes some queries to "plan" the mission. Some of the these queries are persistent. For example, HQ will make a persistent query against the News database, so that the analysts will see all new News articles that might be relevant to the mission at hand (such as a report of an accident or killing elsewhere in the country that changes mission priorities). The stream of new articles coming back from the News databases will be inserted into an existing clustering.
Battalion HQ establishes the persistent query against the Phone Transcript database.
Platoon moves toward building. Different platoon members will possibly take different routes to the target building (to further demonstrate how we handle network disconnections).
Platoon experiences network disconnection as small group moves off, and big group reshuffles to restore connectivity. Everyone continues to enter observations as this happens.
Soldier sees first insurgent leader enter the building (without knowing that it is in fact the leader). Sends a SALUTE report containing the leader's description to Battalion HQ.
Battalion HQ does some number of queries to determine that the observed person is probably the insurgent leader.
Battalion HQ sends photograph of leader to the observing soldier.
Soldier responds that he did see the person in the photograph.
Battalion HQ now knows that the first insurgent leader is in the building.
Intercepted phone call matches persistent query and is forwarded to battalion HQ.
HQ reviews the call transcript, possibly doing additional queries on the names and activities mentioned in the transcript.
Phone call turns out to have been made by the second insurgent leader from inside the building.
Battalion HQ now knows that the second insurgent leader is in the building.
Battalion HQ sends the GO signal to the platoon leader.
Platoon leader sends the GO signal to the platoon members.
Platoon secures the building and captures its occupants.