Billy Foss and Robert Franceschini
Institute for Simulation and
Training
3280 Progress Drive, Orlando, FL 32826
bfoss@ist.ucf.edu
Keywords:
Aggregate, Simulation, Distributed Interactive Simulation
Abstract
Recently IST redesigned the Distributed Interactive Simulation (DIS) Aggregate Protocol to simplify the linkage of aggregate and virtual simulations. The major motivation behind the new Aggregate Protocol was to unify several implementations currently in use. We wanted to generalize the protocol, instead of tailoring it to a specific linkage. Another motivation was to include enough information to reasonably represent a unit in the virtual world. We included a Silent Entity System List to represent entities not issuing PDUs, and we included an Aggregate Marking so that commanders can recognize units on a PVD. We also wanted to generalize the aggregation and disaggregation process so both aggregate and virtual simulations can request a change of state. Overall, we wanted to create an Aggregate Protocol that would satisfy the needs of future Aggregate + Virtual Linkages.
This paper outlines the major decisions made while designing the Aggregate Protocol. It explains the role of the Aggregate Controller and why it warns simulations before changing a unit's state. It explains the Silent Aggregate System List and why aggregates of aggregates are allowed. It also explains the different states of an aggregate, and how they make efficient use of network and processor capability. This paper compares the forerunners of this design and discusses why their ideas were or were not included in the new DIS Aggregate Protocol. It also discusses the extensions we added to the protocol.
1. INTRODUCTION
The Aggregate Protocol was designed to save network bandwidth by aggregating entities into groups. Instead of broadcasting Entity State PDUs for each entity, one Aggregate State PDU can describe the group as an aggregate. The Aggregate Protocol was first proposed in 1990. Later, it became part of the DIS experimental protocols. The integration of aggregate and virtual simulations provided the catalyst for change in the Aggregate Protocol. Aggregate + Virtual (A+V) linkages (Franceschini, 1995) have a great interest in the DIS Aggregate Protocol, because it sets a standard for representing aggregate units in virtual simulations.
During the past few years, several projects have worked on revising the Aggregate Protocol. The newest revision, explained in this paper, was incorporated into version 2.1.3 of the DIS Application Protocols. This paper evaluates previous versions of the Aggregate Protocol, and it explains the decisions made in designing the new protocol.
2. BACKGROUND
Before the new Aggregate Protocol, three projects implemented variations of the Aggregate Protocol. This section describes the DIS 2.1.1 version the Aggregate Protocol, and it describes the different variations used by these three groups. It also describes how these variations influenced the new Aggregate Protocol.
2.1 DIS Aggregate Protocol - Version 2.1.1
After several years as an experimental protocol, the Aggregate Protocol was first included in the 2.1.1 DIS standard. This version provided a good basis, but it lacked the detail to reasonably represent aggregates in the virtual world. (See Appendix for a table of the DIS Aggregate Descriptor PDU.)
2.1.1 Entity ID List
One of the strong points of the DIS 2.1.1 Aggregate Protocol is its use of an ID list that references sub-entities that are broadcasting entity state information. This allows simulations to group entities into appropriate groups. Simulations also use this information to know which entities are involved with an aggregation.
2.1.2 Aggregate ID List
The DIS 2.1.1 Aggregate Protocol also uses an ID list that references sub-aggregates that are broadcasting aggregate state information. This allows aggregates to have several levels of hierarchy and to better represent the multiple levels of military hierarchy.
2.1.3 Aggregation/ Disaggregation Request PDUs
The Aggregation and Disaggregation Request PDUs provide a method for other simulations to request an aggregate to change states. This allows simulations to detect when aggregates are within sensor or weapons range and to request disaggregation. Aggregation and Disaggregation Request PDUs were the start of aggregate interaction in DIS.
2.2 BBS + DIS/SIMNET
The BBS + DIS/SIMNET project started with the DIS experimental Aggregate Descriptor PDU. They added several fields to provide a better representation of aggregates on the battlefield. Some fields specified the type and appearance of entities in the aggregate that were not broadcasting Entity State PDUs. This project also added a field that specified a name for the aggregate. This name was similar to the Entity Marking in the Entity State PDU.
2.3 Corps Level CGF (CLCGF)
The CLCGF project also started with the DIS Aggregate Protocol, and they too added some fields for a better representation of aggregates on the battlefield. These fields included type information like the alignment, role, and echelon of an aggregate. They also include information about the strength and capabilities of an aggregate.
2.4 Integrated Eagle/BDS-D
The Integrated Eagle/BDS-D project developed an alternative protocol to describe aggregates and to communicate the requests to change a unit's state. This protocol also allowed interaction between aggregates and entities through indirect fire. One of the strong features was the use of systems to describe entities that are not broadcasting Entity State PDUs. These systems listed the type of an entity and the number of that type in the aggregate. This method saved space over listing the type for all entities in the aggregate.
3. PURPOSE
In the development of the Aggregate Protocol, we first defined several objectives. Aggregate + Virtual Linkages provided the experience to know what is needed in the Aggregate Protocol. This section describes the three main objectives we used to develop the new Aggregate Protocol.
3.1.1 Represent Useful Groupings
Before the Aggregate Protocol, entities in DIS had no standard way of indicating their membership in a military unit or any other group. The Aggregate State PDU provided a method to specify these relationships between entities. When the Aggregate State PDU is broadcast with the Entity State PDUs of the entities it describes, the Aggregate State PDU lets other simulations know that these entities are related by some common characteristic(s). In this situation, the unit is in the disaggregated state. The most common characteristic for entity grouping is military hierarchy.
3.1.2 Reduce Network Traffic
As demands on simulation increase, it was quickly realized that the current method of representing entities would not meet the goals of 100,000 entities in an exercise. The Aggregate State PDU also provided a way to reduce network traffic by replacing many Entity State PDUs with a single Aggregate State PDU. In this situation the unit is in the aggregated state. The Aggregate State PDU also provided a significant reduction in computation needs by allowing A+V Linkages to represent aggregates at the entity-level only when they are needed. At other times, they could be represented by the aggregate simulations. To be effective, the Aggregate State PDU needed to provide enough information about the entities in aggregated units for a reasonable representation of them. This information should include the alignment, the formation, and the type of entities in the aggregate, but it should not include unused fields, because they waste network bandwidth.
3.1.3 Allow Aggregates to Change State
Because aggregates can be represented at two different levels, the Aggregate Protocol needs to allow simulations to request that a unit change its state. This request allows units to disaggregate when other simulations need the entities simulated at the entity-level. These requests also allow Aggregate Controllers to control the number of disaggregated entities present at one time.
4. MAJOR DECISIONS
This section describes the main design decisions that were made in the new Aggregate Protocol. First, it discusses the changes made to the Aggregate State PDU, and then it discusses the changes made in the process of disaggregation.
4.1 Aggregate State PDU
Many changes were made to the structure of the Aggregate State PDU. These changes were inspired by the experience of the three A+V Linkages mentioned in section 2 and by many suggestions those who reviewed the Aggregate Protocol.
4.1.1 One Aggregate per PDU
The original DIS Aggregate Protocol allowed several aggregates to be described in a single PDU. This option would save space by reducing the number of PDU headers sent on the network, but it required additional fields even if only one PDU was sent. This option also created potentially large PDUs, which might exceed the limit set by the Communications and Architecture Committee. It also required a delay in the timing of Aggregate State PDUs. For these reasons, the Aggregate State PDU was modeled after the Entity State PDU so that each Aggregate State PDU describes only one aggregate.
4.1.2 Position Information
The Aggregate State PDU includes position information in the same format as the Entity State PDU. This eliminates converting coordinates to determine the distance between entities and aggregates. Simulations can use the simple linear dead reckoning algorithm if they want smoother movement of an aggregate.
Several methods of indication the position information of an aggregate were in use when the Aggregate Protocol was revised. Some groups used the same structures used for entities in DIS. Other groups used much less precision. Although these less precise coordinates would provide detailed enough information about an aggregate, it would require more computation to convert the coordinates. Most simulations would convert the coordinates to the structures used for entities in DIS. For these reasons the Aggregate State PDU uses the same location, velocity, and orientation structures as use for the Entity State PDU.
Because an aggregate may vary in the amount of ground it covers, another field was added to specify the boundaries of the aggregate. This field specifies an area in the terrain that includes all the parts of the aggregate, it does not indicate that the aggregate covers the entire area.
4.1.3 Aggregate Specific Information
The new Aggregate State PDU includes aggregate specific information in many of the same structures as the Entity State PDU.
Like the Entity State PDU, the Aggregate State PDU includes a Force ID to identify the force common to the entities of the aggregate. Although it is allowed to group entities from different forces together, it is not recommended. In this event the Force ID will be not applicable. This field allows other simulations to determine if an aggregate is friendly, foe, or neutral. Usually, entities will not request disaggregation of friendly units.
The Aggregate State PDU also includes an Aggregate Marking field to identify marking associated with the aggregate. Like the Entity Marking field, this marking provides a meaningful identification of an aggregate. Plan View Displays can display the marking information along with an icon to represent an aggregate. This marking allows human operators and commanders to recognize specific aggregates.
The Aggregate State PDU also includes an Aggregate Type Record that specifies the specific type of an aggregate. Like the Entity Type Record, this type information includes the country and domain of the aggregate. It also specifies the method of grouping the entities. This method may be military hierarchy, entity type, or some other method. Other fields specify more about specific characteristic. For example, an aggregate grouped by military hierarchy would also specify the echelon level, the echelon type, and whether the unit includes headquarters.
4.1.4 Aggregates of Aggregates
Because of the multiple levels of hierarchy in the military, the Aggregate State PDU was designed to allow aggregates of aggregates. This allows military units to be disaggregated into their proper parts instead of disaggregating into many entities. For example, a battalion of three companies would consist of three aggregates. Each sub-aggregate would represent a company. Each sub-aggregate could then have twenty vehicles each, instead of the original battalion consisting of sixty vehicles.
4.1.5 Reference to Disaggregated Parts
When aggregates are grouping entities that are currently broadcasting Entity State PDUs, the Aggregate State PDU should somehow reference those PDUs. This referencing should also apply to aggregates with sub-aggregates that are broadcasting Aggregate State PDUs. To accomplish this referencing, the Aggregate State PDUs includes two lists. The first list includes Aggregate IDs to reference sub-aggregates, while the second list includes Entity IDs to reference sub-entities. These lists allow other simulations to monitor the network for more information about the parts of a disaggregated.
4.1.6 Information about Silent Parts
When a unit is aggregated, there are no Entity State PDUs or Aggregate State PDUs that the unit can refer to. In this case, the Aggregate State PDU needs to include some information about its aggregated parts. The Aggregate State PDU has a list to indicate the Aggregate Type of sub-aggregates and a list to indicate the Entity Type of sub-entities. These lists are organized by systems to save PDU space. Instead of listing the type of all entities and all aggregates in the unit, the PDU lists the type of an entity once, and then indicates the number of entities of that type that are in the unit. This eliminates duplicating the type information. The Silent Entity Systems List also includes a list to indicate the appearances of these entities. Many A+V Linkages will leave this list empty, because their aggregate simulation does not model the appearance of each entity, but some linkages will use it to add more information about the unit.
4.2 Process of Changing State
The Aggregate State PDU allows aggregates to be represented in the virtual environment, but it does not provide a means of interaction with the virtual world. The development of A+V Linkages created the idea of disaggregating a unit into its entity-level parts so that it can interact in the virtual world. This section describes the changes in the process used to aggregate and disaggregate.
4.2.1 Action Request/Response PDUs
Originally the DIS Aggregate Protocol included the Aggregation Request PDU and the Disaggregation Request PDU to allow simulations to request disaggregation. The suggestion was made to create a single PDU that allows for both aggregation and disaggregation requests and if possible to use existing PDUs instead of creating new PDUs. We found that the DIS Simulation Management Protocol has several PDUs that could accomplish this task. The Action Request PDU was adopted as the means of requesting a change of state in an aggregate. The flexibility in this PDU allowed the Aggregate Protocol to include the state that is being requested in an enumeration. This enumeration allows for a variety of states instead of just aggregated and disaggregated. The Action Response PDU provided an easy and efficient way for Aggregate Controllers to respond to these Action Requests. The Action Request and Action Response PDUs are shown in section 6.
4.2.2 Event Report PDUs
The Event Report PDU was included in the Aggregate Protocol as a method for the Aggregate Controller to warn other simulations that an aggregate will be changing state. This warning is primarily used in the case of a disaggregated unit that is being re-aggregated. This warning lets simulations interacting with the entities of that aggregate know that these entities will not be there after aggregation. If the simulation is still interacting with the unit, then it can request that the unit stay disaggregated.
4.2.3 Simulation-initiated Change of State
If a simulation determines that it wants to interact with the entities in a unit, it can request disaggregation with the Action Request PDU. The Aggregate Controller will then send the Action Response PDU to let the simulation know whether the disaggregation can take place. These two PDUs provide an efficient and easy way for simulations to request changes of state. They also have datum fields that allow more information about a request to be included in the PDU.
4.2.4 Aggregate Controller-initiated Change of State
If the Aggregate Controller determines that it needs to change the state of one of its units, it can send the Event Report PDU to warn other simulations, and then it can proceed with the change of state. This process allows the Aggregate Controller to fully control the state of its units to balance network and processor load, but it also allows other simulations to request a change of state.
5. CONCLUSIONS
Since the revision and wide acceptance of the Aggregate Protocol, several groups have started to implement this version of the protocol. They will show by experience that these design decisions will fit the needs of many A+V linkages. The design is generic enough to allow many different systems use it, but yet it is specific enough to avoid needing additional fields for each exercise. These designs were the result of many months of review and correction. Many people helped in the overall design of the new Aggregate Protocol.
Field Size (bits) | DIS 2.1.1 Aggregate Descriptor (State) PDU Fields | |
---|---|---|
96 | PDU Header | Standard Header |
48 | Originating Entity ID | Site - 16 bit unsigned integer Application - 16 bit unsigned integer Entity - 16 bit unsigned integer |
32 | Number of Aggregate Descriptors | 32 bit unsigned integer |
Aggregate Descriptor Record | ||
48 | Unique Aggregate ID | Site - 16 bit unsigned integer Application - 16 bit unsigned integer Aggregate - 16 bit unsigned integer |
16 | Size of Descriptor (in bytes) | 16 bit unsigned integer |
16 | Aggregate Shape | 16 bit enumeration |
16 | Number of Entities in Aggregate (M) | 16 bit unsigned integer |
16 | Number of Aggregate IDs (m) | 16 bit unsigned integer |
16 | Aggregate Hierarchical Name | 16 bit enumeration |
96 | Dimensions | X - 32 bit floating point Y - 32 bit floating point Z - 32 bit floating point |
192 | Center | X - 64 bit floating point Y - 64 bit floating point Z - 64 bit floating point |
96 | Orientation | Psi - 32 bit floating point Theta - 32 bit floating point Phi - 32 bit floating point |
96 | Velocity | X - 32 bit floating point Y - 32 bit floating point Z - 32 bit floating point |
48 | Entity ID #1 | Site - 16 bit unsigned integer Application - 16 bit unsigned integer Entity - 16 bit unsigned integer |
48 | Entity ID #M | Site - 16 bit unsigned integer Application - 16 bit unsigned integer Entity - 16 bit unsigned integer |
48 | Aggregate ID #1 | Site - 16 bit unsigned integer Application - 16 bit unsigned integer Aggregate - 16 bit unsigned integer |
48 | Aggregate ID #m | Site - 16 bit unsigned integer Application - 16 bit unsigned integer Aggregate - 16 bit unsigned integer |
Total Size = 1088 + 48 x (I + J) + 96 x (K + L) + (32 x A) x L + 64 x (M + i=1 to M [Ki / 64]) |
Field Size (bits) | DIS 2.1.3 Aggregate State PDU Fields | |
---|---|---|
96 | PDU Header | Standard Header |
48 | Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
8 | Force ID | 8-bit enumeration |
8 | Aggregate State | 8-bit enumeration (Aggregated, Disaggregated, etc.) |
64 | Aggregate Type Record | 64-bit enumeration |
32 | Formation | 32-bit enumeration |
256 | Aggregate Marking | Character Set: 8-bit unsigned integer Text: 31 characters (248 bits) |
96 | Dimensions | X: 32-bit floating point Y: 32-bit floating point Z: 32-bit floating point |
192 | Center | X: 64-bit floating point Y: 64-bit floating point Z: 64-bit floating point |
96 | Orientation | Psi: 32-bit floating point Theta: 32-bit floating point Phi: 32-bit floating point |
96 | Velocity | X: 32-bit floating point Y: 32-bit floating point Z: 32-bit floating point |
16 | Number of DIS Aggregates (I) | 16-bit unsigned integer |
16 | Number of DIS Entities (J) | 16-bit unsigned integer |
16 | Number of Aggregate Systems (K) | 16-bit unsigned integer |
16 | Number of Entity Systems (L) | 16-bit unsigned integer |
Aggregate ID List: 48 bits x I | ||
48 | Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
Entity ID List: 48 bits x J | ||
48 | Entity ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Entity: 16-bit unsigned integer |
Silent Aggregate System List: 96 bits x K | ||
16 | Number of this system | 16-bit unsigned integer |
16 | Padding | 16-bit padding |
64 | Aggregate Type Record | Enumeration set above |
Silent Entity System List: (96 + 32 x A) x L | ||
16 | Number of this system | 16-bit unsigned integer |
16 | Number of appearance records (A) | 16-bit unsigned integer |
64 | Entity Type Record | Standard record |
32 x A | Entity Appearance Record list | List of 32-bit standard records |
Variable Datum Records: 32 + 64 x (M + i=1 to M [Ki / 64]) | ||
32 | Number of Variable Datum Records (M) | 32-bit unsigned integer |
64 + Ki + Pi | Variable Datum Records | Standard records |
Total Size = 1088 + 48 x (I + J) + 96 x (K + L) + (32 x A) x L + 64 x (M + i=1 to M [Ki / 64]) |
Field Size (bits) | Action Request PDU Fields | |
---|---|---|
96 | PDU Header | Standard Header |
48 | Originating Entity/Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
48 | Receiving Entity/Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
32 | Request ID | 32-bit unsigned integer |
32 | Action ID | 32-bit unsigned integer |
32 | Number of fixed records (2+) | 32-bit unsigned integer |
32 | Number of variable records (0) | 32-bit unsigned integer |
64 | Fixed Datum #1 (Requested State) | 32-bit enumeration of type of data 32-bit enumeration |
64 | Fixed Datum #2 (Trigger Used) | 32-bit enumeration of type of data 32-bit enumeration |
64 | Fixed Datum #3 (Detection Range) | 32-bit enumeration of type of data 32-bit floating point |
64 | Fixed Datum #4 (Requested Time) | 32-bit enumeration of type of data 32-bit unsigned integer |
Total Size = 512 bits |
Field Size (bits) | Action Response PDU Fields | |
---|---|---|
96 | PDU Header | Standard Header |
48 | Originating Entity/Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
48 | Receiving Entity/Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
32 | Request ID | 32-bit unsigned integer |
32 | Request Status | 32-bit unsigned integer |
32 | Number of fixed records (1) | 32-bit unsigned integer |
32 | Number of variable records (0) | 32-bit unsigned integer |
64 | Fixed Datum #1 (New State) | 32-bit enumeration of type of data 32-bit enumeration |
Total Size = 448 bits |
Field Size (bits) | Event Report PDU Fields | |
---|---|---|
96 | PDU Header | Standard Header |
48 | Originating Entity/Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
48 | Receiving Entity/Aggregate ID | Site: 16-bit unsigned integer Application: 16-bit unsigned integer Aggregate: 16-bit unsigned integer |
32 | Event ID | 32-bit unsigned integer |
32 | Number of fixed records (2) | 32-bit unsigned integer |
32 | Number of variable records (0) | 32-bit unsigned integer |
64 | Fixed Datum #1 (Requested State) | 32-bit enumeration of type of data 32-bit enumeration |
64 | Fixed Datum #2 (Request Status) | 32-bit enumeration of type of data 32-bit enumeration |
Total Size = 448 bits |
7. ACKNOWLEDGMENT
IST's ongoing work in A+V simulation is sponsored by STRICOM and the US Army TRADOC Analysis Center as part of the Integrated Eagle/BDS-D project, contract number N61339-92-K-0002. Their support is gratefully acknowledged.
8. REFERENCES
Calder, R.B., Peacock, J.C., and Wise, B.P. (1995) "Implementation of a Dynamic Aggregation/Deaggregation Process in the JPSD CLCGF," Proceedings of the Fifth Conference on Computer Generated Forces and Behavioral Representation, Orlando FL, May 9-11 1995, pp. 83-91.
Foss, B. and Franceschini, R. (1995) "A Unified Aggregate Protocol," 13th Workshop on Standards for the Interoperability of Distributed Simulations, Orlando FL, September 18-22 1995.
Foss, B. and Franceschini, R. (1996) "A Further Revision of the Aggregate Protocol," 14th Workshop on Standards for the Interoperability of Distributed Simulations, Orlando FL, March 11-15 1996.
Franceschini, R.W. and Petty, M.D. (1995) "Linking Constructive and Virtual Simulation in DIS," Proceedings of the SPIE International Symposium on Aerospace/Defense Sensing & Control and Dual-Use Photonics, Orlando FL, April 17-21 1995.
Franceschini, R.W. and Karr, C.R. (1994) "Proposal for the Revision of the DIS Aggregate Protocol," Summary Report: 11th Workshop on Standards for the Interoperability of Distributed Simulations, Volume 1: Position Papers, Orlando FL, September 26-30 1995, pp. 425-429.
Healy, M. and Hale, C. (1994) "The STOW-E Exercise: An Implementation of the Aggregate PDU," Summary Report: 12th Workshop on Standards for the Interoperability of Distributed Simulations, Volume 1: Position Papers, Orlando FL, March 13-17 1995, pp. 75-79.
Healy, M. (1991) "A Proposal to Include the Aggregate PDU in the DIS Standard," Summary Report: Fifth Workshop on Standards for the Interoperability of Defense Simulations, Orlando FL, September 24-26 1991, pp. A79-A82.
IEEE Standards Department (1994) Standard For Distributed Interactive Simulation -- Application Protocols, Institute of Electrical and Electronics Engineers, Inc., New York NY, 1994.
IST (1994) "Standard For Distributed Interactive Simulation -- Application Protocols" Version 2.0 Fourth Draft (Revised), Contract Report IST-CR-94-50, Institute for Simulation and Training, March 16 1994.
Stober, D.R., Kraus, M.K., Foss, W.F., Franceschini, R.W., and Petty, M.D. (1995) "Survey of Constructive + Virtual Linkages," Proceedings of the Fifth Conference on Computer Generated Forces and Behavioral Representation, Orlando FL, May 9-11 1995, pp. 93-102.
Wicks, J.K. and Burgess, P. (1995) "Standard For Distributed Interactive Simulation -- Application Protocols" Version 2.1.1 (Working Draft), Contract Report IST-CR-95-06, Institute for Simulation and Training, March 9 1995.
9. AUTHOR'S BIOGRAPHIES
William F. Foss is a Research Assistant on the Integrated Eagle/BDS-D project at the Institute for Simulation and Training. He is an undergraduate student in Computer Science at the University of Central Florida. His research interest is in the area of simulation.
Robert W. Franceschini is a Principal Investigator at the Institute for Simulation and Training. He currently leads the Integrated Eagle/BDS-D project at IST. Mr. Franceschini has earned a Bachelor of Science in Computer Science from the University of Central Florida; he is currently pursuing a Master of Science in Computer Science from UCF. His research interests are in the areas of simulation, graph theory, and computational geometry.