{mpullen,vlaviano}@gmu.edu

Délégation Générale pour l’Armement, Paris, France

mmoreau@bacon.gmu.edu

Keywords: HLA, RTI, selectively reliable transmission, data distribution management, dual-mode multicast

ABSTRACT: In order to understand the HLA and bring our work into compatibility with it, we have been investigating design and implementation alternatives for a light-weight RTI to be used with distributed virtual simulation and interfaced to DIS simulations. We are now in the process of prototyping such an RTI for small to medium-scale federations. This approach grew out of our earlier Dual-Mode Multicast (DMMC) prototype that was described in [FrPu97]. The communications portion of our RTI functionality largely will be met by including the Selectively Reliable Transmission Protocol (SRTP), described in our previous work [PuLa96] and elaborated in a companion paper, to manage exchange of simulation state among instances of the RTI. In addition to SRTP we are creating a set of data distribution management functions adequate to support a virtual mode federation. This paper describes the selected set of data management functions and our rationale for their selection, together with our experiences in designing and implementing the light-weight RTI over SRTP as an evolution of DMMC.

This paper reports on the results of our effort to understand the new DoD High Level Architecture (HLA) as applied to distributed virtual simulation, by creating and using a light-weight Run Time Infrastructure (RTI). At GMU we have done experimental work for several years in areas related to scale-up of Distributed Interactive Simulation (DIS) to large-scale battlefield simulations (tens to thousands of active objects). As a result we have created prototypes for base technologies fundamental to the communications aspects of the RTI. The light-weight RTI is therefore a transitional effort which takes what we know about DIS and uses it to support distributed virtual simulation within the context of the HLA. Our starting points for this effort were the Selectively Reliable Transmission Protocol (SRTP), the Dual-Mode Multicast architecture (DMMC), and the definition of the HLA. We report here the results of this effort, which focused on how our existing prototypes might be modified to support the HLA, and on implementation of the Data Distribution Management (DDM) features necessary to make the resulting light-weight RTI usable.

The Selectively Reliable Transmission Protocol was developed at George Mason University to support large scale DIS. Our inspiration for using selective reliability to support the compression of entity state information using a reference/offset scheme came from Danny Cohen's work with the DIS community [Coh94a,Coh94b]. SRTP, used with the User Datagram Protocol (UDP), provides a selectively reliable transport service that embodies a tradeoff between minimal latency and reliability. SRTP exploits the known properties of DIS traffic, reducing network capacity requirements by transmitting, using real-time best-effort multicast, only those data elements, such as position, that change frequently. Those data that change rarely, or not at all, are transmitted reliably one time. This approach follows from the fact that transmission parameters low latency and high reliability, most often seen as alternatives, are in fact end points in a range of options.

To date the principal transport protocols used for DIS have been the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP provides reliable data transport but is not appropriate for large scale multicast communications because of the phenomenon known as "ACK implosion". TCP requires that a receiver send a positive acknowledgement (ACK) in response to data segments. If the multicast group is large, this control traffic can create enough congestion that the transmission of future data segments is impaired severely. As a result broadcast and multicast virtual simulations typically use UDP, which as a best effort transport protocol does not use ACKs. However, this forces each application to provide for reliability on its own when it is required. SRTP provides a standardized set of communication services than can be combined with UDP to provide reliable transmission of data that change rarely, intermixed with best-effort transmission of frequently-changing data. It also provide relevance filtering needed for multicast group assignment. The result is a considerable reduction in network capacity requirements to support DIS.

Considering an application that performs dead reckoning with a heartbeat, and normally sends a PDU of length f bits, if the information that changes frequently requires a PDU of s bits and the long PDU is sent one out of M times, the ratio of bits sent under SRTP to bits sent without SRTP is:

r = 1/M+ ((M-1)/M)(s/f)

For the representative DIS case f=1300 bytes, M=10 PDUs, and s=100 bytes this ratio .17, corresponding to an 83% reduction in traffic bits as compared to using only dead reckoning. This result is independent of the heartbeat interval for dead reckoning.

As shown in Figure 1, SRTP provides relevance filtering and three transmission modes: mode 0 for best-effort multicast, mode 1 for receiver-reliable multicast, and mode 2 for reliable datagram service. Modes 0 and 1 were designed to facilitate the transmission of entity state information, while mode 2 was designed for the transmission of dynamic interactions between pairs of entities without the overhead of TCP connection management. Figure 1 summarizes the functions of SRTP.

We have been investigating distributed simulation networking approaches for the synthetic battlefield that are able to support large numbers of active objects (approaching 100,000) on the battlefield. For economical implementation, this problem requires use of multicast networks to reduce bandwidth requirements and simulator input of a DIS exercise or an HLA federation. The multicasting problem at this level, known as the "large scale multicast environment", requires highly scalable protocols to work. To date the most popular method of assigning objects to multicast groups has been interest management where the simulation in segmented into groups by geographic region.

Figure 1: SRTP Functions

An approach that we have investigated, called Dual Mode Multicast (DMMC) [PuWh95,FrPu95], provides a scalable solution for distributed simulation. It utilizes one (or a few) exercise-wide multicast group(s) on the WAN and an interest management scheme to select at each simulator from a large number of possible multicast groups on the LAN. The basic premise of DMMC is that, because it is not possible to know in advance which simulators will interact in a practical exercise, WAN backbone capacity must be provisioned sufficient to support the maximum data flow that can be generated by the simulators between any two sites. This being so, there is no additional cost if the data packets needed to depict the behavior of each simulator are sent in a single WAN multicast group that distributes them to each site.

DMMC is implemented by having a filtering process at each Application Gateway (AG), that 1) forwards all PDUs generated locally to an exercise-level multicast group; and 2) processes all PDUs coming from the rest of the exercise, removing or filtering any PDUs that are not needed locally, and multicasting those remaining PDUs to the local simulators. Figure 2 shows the DMMC architecture.

Figure 2: DMMC Architecture

This section describes our understanding of the DoD High Level Architecture (HLA) for Modeling and Simulation, as reflected in our prototype light-weight RTI.

One of the objectives of the DoD in the Modeling and Simulation field, as described in the DoD M&S Master Plan [DMSO95], is to develop a common technical framework for M&S. Currently the highest priority effort is to "establish a common high-level simulation architecture to facilitate the interoperability of all types of simulations among themselves and with C4I systems, as well as to facilitate the reuse of M&S components." This High Level Architecture (HLA) must provide interoperability and standardized infrastructure where possible, making live, virtual and constructive simulations work together, despite, for example, heterogeneous time management mechanisms. Services necessary to support the HLA are provided by a single logical component, called Run Time Infrastructure (RTI), which supports execution, object and time management, and data exchange. We have chosen to limit our light-weight RTI to real-time, virtual distributed simulation.

The HLA is defined by three baseline technical definition documents: the HLA Rules, which describes the general principles defining the HLA and its federations and federates; the Interface Specifications, which provides a specification for the functional interfaces between federates and the RTI; and the Object Model Template, which provides a template for documenting information about classes of simulation or federation objects and their attributes and interactions.

The HLA RTI is the software implementation of the Interface Specification [DMSO97a]. The services provided by the RTI are divided into six groups: Federation Management, Declaration Management, Object Management, Ownership Management, Time Management and Data Distribution Management. The RTI is in part intended to increase the scalability of an exercise (when compared to the DIS protocol), by reducing the data set required to be processed by the receiving federate and the message traffic over the network. The Declaration Management (DM) provides a class-based filtering mechanism and the Data Distribution Management (DDM) provides a more complex value-based filtering mechanism.

The HLA requires federates to declare their requirements to generate and receive object state information and interactions. Each federate subscribes and publishes the corresponding object and interaction classes through the DM, specifying if necessary the attributes it is concerned about. The published classes determine to which class membership of objects that the federate is going to register, the attributes it is going to provide to the federation, and the attributes it may acquire through the Ownership Management services. This information is also used by the RTI to control the flow of data among the federates by performing class-based filtering. A federate which subscribes to the attribute values of an object class will receive all updates of the specified attribute values for the registered objects of that class which are "in scope".

The DDM provides an alternative way of filtering the data, based on the values of the attributes. The federates express their interest in sending or receiving data in a multidimensional coordinate system, called a routing space, by defining regions. A region is a set of extents, which are described by a set of ranges in the dimensions of the routing space. A region can be a rather complex area defined by the union of several hyper-rectangles in the space. The DDM can be used in one of several ways:

• Specifying an update region and associating this update region with a particular object means that the federate will ensure that these characteristics of the object will fall within the bounds of the associated region when an attribute update is issued.

• Specifying a subscription region for a given object or interaction class, the federates tell the RTI to only deliver data of that class which fall within the bounds of the region.

• An additional service is available to modify the region according to the changes of object characteristics during the simulation.

• The regions are used by the RTI to deliver attribute updates and interactions. For an object, the attributes will be routed from the sender to the federates which have subscribed to these attributes for the class (or a super-class) of this object and which have specified a subscription region which overlaps the update region of the attributes.

• Before delivering any attribute, the RTI must inform the federate that a new object is in-scope, and use the Discover Object service. When the subscription regions of a receiving federate no longer overlap with any update region of the object, the RTI tells this federate to remove the out-of-scope object. A problem associated with this approach is to choose the size of the region, and the criteria to modify this region. The "real" region in the physical world changes over time; in order to capture the interests of the federate as efficiently and accurately as possible, without requiring too much computation, the RTI must artificially widen the subscription regions, and choose how often the regions should be updated. This approach is called a "physically correct" filter strategy.

The light-weight RTI focuses on Declaration Management and the Data Distribution Management issues necessary to support distributed virtual simulation. Therefore several services defined under the HLA have not been implemented. We started with a minimal level of complexity, omitting several groups of services that we believe are less important in the virtual simulation domain. For this reason, the HLA Ownership Management and Time Management functionalities have been completely omitted. Because our focus was real time simulation, the mechanism for controlling the advancement of federates along the time axis could be by-passed. Similarly, in order to support a federation execution only a few Federation Management services are necessary. Federates only need to create, join, leave and destroy the federation. Therefore, pausing and saving the exercise were not implemented in our version.

Most object management services are available in the light-weight RTI. However, due to the fact that we are concerned only with real time and therefore do not support the Time Management services, the retraction mechanism did not make sense because the simulations in question will not permit "undo" actions.

Declaration and Object Management services, which are our main concern, are available according to the version 1.1 of the HLA Interface Specification. During our implementation the HLA has continued to evolve. We had some difficulties with the interpretation of the specifications and found some coherence problems between Declaration Management, Object Management and Data Distribution Management. For example, the interactions could not be filtered using the Routing Space mechanism, because it was not possible to send an interaction with a region designator. Therefore our version of Data Distribution Management has been implemented with emphasis on filtering and routing issues rather than on "physically correct" filter strategies.

Although the SRTP and DMMC were designed in order to work with DIS, their features can be used to implement the Declaration Management and Data Distribution Management. Under the HLA, the DMMC Application Gateway is easy to convert into a component of the RTI. It becomes a local process, providing RTI services for all the federates on the LAN and routing the data through the federation according to the DDM and the DMMC scheme.

The grid based filtering strategy used in DMMC provides simple mechanisms for routing information between the federates. This approach is in accordance with the initial implementation described in the HLA DDM Design Document [DMSO97c]. The main difference is that we are using multicast groups to implement the "stream" abstraction, because when used with SRTP, they appeared to provide more appropriate communication services than TCP.

Mapping between grid cells and multicast groups is performed by our RTI. The list of the available multicast groups and the description of the routing space (including not only the number of dimensions but also the range of meaningful values on each dimension) is used as initialization data. The routing space is divided into fixed and equal sized cells (the effectively used extents on each dimension are used here), and each cell is associated statically to a different multicast group. Whenever an HLA region is created, it is associated with overlapping cells and with the corresponding multicast groups. If the region is used as a subscription region, the federate will subscribe to the corresponding groups. If the region is used as an update region, the federate will send the updated attribute values to the mentioned groups.

SRTP, with minimal adaptation, can serve as the basis for the data distribution management and declaration management functions of a light-weight RTI. The transport functions of SRTP can be used to provide three of the four types of transport services described in the RTI interface specification as shown in Table 1. The fourth function, fully reliable transport, is not provided, because we do not believe it is feasible to perform in real time.

Table 1: Providing HLA Services with SRTP

and TCP

The best effort transport service clearly maps to SRTP mode 0, best effort multicast. The minimum rate service can be provided by adding an RTI-generated heartbeat to SRTP mode 0. The mode 0/1 data stream service that was built into SRTP for the transmission of entity state data provides state consistent service. The fourth transport service described in the RTI interface specification, reliable service, guarantees ordered delivery of all data to all subscribed receivers. SRTP does not provide such a service because we do not know how to provide it in real time across a large multicast group.

The data that is being distributed among the federates in an HLA federation can be broken down into attributes and interactions. Attributes are properties of objects, while interactions are events that involve two or more objects. SRTP, originally designed for DIS, supports the transmission of entity state information (object attributes in HLA terminology) through a data stream comprised of mode 0 and mode 1 data. This carries over into our light-weight RTI, where we use SRTP modes 0 and 1 to transmit object attribute information. SRTP mode 2 was designed to support interactions. This design viewed interactions as happening between exactly two entities, one of which initiated the interaction. These interactions were viewed as single, discrete events, such as a missile colliding with a tank. Under these circumstances SRTP could improve on TCP by providing a reliable, connectionless service, avoiding the overhead of establishing a connection. However, the HLA requires that interaction data be delivered to all objects within scope of the interaction, a function most appropriately performed by multicast. Therefore we transmit interactions using SRTP mode 1, followed by a sufficient number of empty mode 0 transmissions to give a high probability that lost transmissions will be detected.

The combination of DMMC and SRTP provides a straightforward implementation of DDM. SRTP provides relevance filtering of data on the basis of both category code and destination multicast group. These features are used to support both data distribution and declaration management.

The RTI allows two types of filtering, class based filtering and data based filtering. The object and interaction classes defined in the federation object model (FOM) for a federation are mapped to SRTP categories. The SRTP category filtering mechanism is then used to provide RTI class based filtering as part of its declaration management services. As part of the data distribution management scheme, geographic regions are associated with multicast groups. The SRTP multicast group filtering mechanism is used to provide RTI data based filtering. Table 2 describes how the SRTP mechanisms map to HLA concepts.

Table 2: How HLA is Supported by SRTP

The SRTP categories and the ability to register/unregister a category provides a good way to implement Declaration Management. The large number of available SRTP categories allows static association of each category with a given object or interaction class. Registering a given class is then strictly equivalent to registering an SRTP category. For objects, SRTP provides a coarse grained filtering, thus it is necessary to select the subscribed attributes when an "update attribute values" message arrives. This problem does not exist for the interactions, where only the requested data are delivered by SRTP.

It is an explicit requirement of the HLA that interactions should be delivered to all the subscribing federates, and that the target of an interaction is specified as part of the interaction parameters. The RTI does not make a distinction between a one-to-one interaction (such as a collision) and a one-to-many interaction, such as a radio emission. This seems to us to be a shortcoming of the HLA. The RTI could offer the possibility to send an interaction to a given entity in a DIS-like manner, in order to avoid an unnecessary multicast transmission. However, in order to remain consistent with the HLA definition, we have implemented interactions in multicast.

Our RTI has a distributed architecture. The different components pass service description information among themselves using TCP to send and receive the services information (which must be delivered reliably and are rather infrequent) and using SRTP to send and receive simulation data, as shown in Figure 3. Each LAN has a Federation Server, which manages the creation and destruction of federation executions. These servers are fully interconnected.

Figure 3: RTI Architecture (one federation)

The server network is described in an RTI initialization file, containing the list of the server hosts and two port numbers. One is an external port number, used by the servers to communicate with each other. The other one is an internal port number used by the federates on the LAN to send requests to their local Federation Server. In order to optimize communication, the server should run on the same host as the RTI Gateway. When the network is ready, additional servers may join it, or may leave it if they are not supporting any federation.

When the CreateFederationExecution service is first called by a simulation application, a message is sent through the RTI Ambassador to the local Federation Server. This will create an RTI Gateway process, and send a message to all the other servers, asking them to do so.

The federation Runtime Initialization Data (RID) describes, for each LAN, the RTI Gateway host (which must be the same as the corresponding server host), the port numbers for inter-gateway communication and federate-to-gateway communication, and the multicast groups to will be used for the exercise. The gateways are fully connected together. A gateway is not allowed to join the federation after the execution has started (this would cause consistency problems), but may leave if it is no longer supporting any federate on its LAN.

We emphasize that, due to the hierarchical organization derived from DMMC, federates on the LAN are only connected to each other and to the RTI Gateway using TCP, restricting this undesirable non-multicast many-to-many interconnection to the scope of the LAN.

The RTI Gateway is an extension of the DMMC-AG shown in Figure 1. It performs the filtering/forwarding tasks according to the DMMC approach and provides RTI services to the federates on the LAN. It also provides the other gateways with aggregated updates for objects being simulated on its LAN. This hierarchical organization simplifies operation of the RTI. A gateway receives subscription and publication from local federates and from remote gateways, which are handled in a similar way. A gateway will request attribute value update from a local federate or from a remote gateway, and in turn forward the request to its locally concerned federates. The gateway allows the federates to join and leave the federation execution, and provides them with object IDs. It is aware of the local and remote registered interests in term of classes and regions, and of the locally and remotely simulated objects.

Another important function of the RTI Gateway is to map regions to multicast groups for each routing space. This is done whenever a new region is created or when an existing region is modified. The list of the available multicast groups, the WAN multicast group and a LAN default multicast group are part of the RID. A catchall group is used to send data when no update region has been specified (it corresponds to a region including the all routing space). All federates automatically subscribe to this group. Associated with the mapping function is the filtering/forwarding of simulation data. Data sent on the LAN by the federates are forwarded on the WAN using the exercise multicast group if a remote gateway has subscribed to the category of the message, and a remote gateway has subscribed to the multicast group that this message is to be sent on. When the gateway receives a message from the WAN, it checks whether one of the local federates have subscribed to the category and the multicast group; if not, the message is discarded.

The functions of the light-weight RTI are implemented as a library programmed in C++ which supports the RTI Ambassador interface to the HLA 1.0 services. Service requests are either processed locally or sent to the RTI Gateway on the internal port number. Simulation data are sent using the RTI. A fine-grain filtering process removes unsolicited attributes or interactions. The library also deals with out of scope objects.

Due to the lack of available simulations using the RTI and DDM, it was not easy to test our implementation. We developed a very simple federate to test the basic abilities and the correct behavior of the software: objects moving in a two dimensional routing space come in-scope and go out-of-scope and they can send interactions when an other object comes into sight. We also used this federate to determine the performance of the RTI, which was approximately 100 attribute updates per second (we hope to improve this performance considerably in later versions). However, testing with a simple federate was not sufficient to validate fully our approach and implementation.

In order to make more appropriate tests at a larger scale, we decided to use ModSAF 3.0 and to develop a translator between DIS and HLA. This task has been the second major part of our work and is now ongoing. The translator is an independent piece of software which sends/receives PDU like a DIS simulation, converts them into RTI service requests and sends/receives RTI requests like a federate. Figure 4 shows the organization of the translator.

Figure 4: DIS to RTI Translator

The principal input to the translator is the Entity State PDU (ES-PDU). The main difficulty in mapping this PDU to the UpdateAttributeValue service is that the RTI is attribute-oriented, providing only the values of modified attributes, while DIS applications send full-state PDUs at a minimum rate. Therefore, the translator must keep a copy of all known HLA objects and DIS entities. Also, when it subscribes or publishes an object class, it must do so for all attributes of the class, and not only to a subset of the available attributes. The adaptation mechanism is as follows:

• When it receives a PDU, in order to update only the modified values, the translator must compare the new values against the previous values before sending the update. The translator also verifies the simulation time of the PDU, in order to detect out-of-order packet delivery.

• If no ES-PDU has been received recently for a given entity, the translator may delete the corresponding object.

Whenever the translator receives new attribute values from the RTI, it must dead reckon the previous saved object state and apply the partial update before sending the full state as an ES-PDU. Because attribute updates are delivered by the RTI using the best-effort communication service, they may be out of order, in which case they are ignored. If no attribute update has been received recently for a given object, the translator will dead reckon and send an ES-PDU after a given period of time to generate a heart beat.

The other important point in testing our RTI is Data Distribution Management. Our DIS to RTI translator uses a two dimensional geographic routing space for objects. The update and subscription regions are described as rectangles centered on the object concerned, and are the same for all the attributes. We are progressively turning all the PDUs into translator calls. Experimental PDUs and not-yet translated PDUs are just being forwarded through a transparent "back door" in the RTI.

Our RTI will also be upgraded, as soon as possible, according to the version 1.2 of the HLA Interface Specification with a more mature and stable DDM.

We have reported here a light-weight implementation of the HLA RTI for real-time distributed virtual simulation, based on existing software prototypes from out SRTP and DMMC work. In developing this RTI we have determined that several HLA functions are not required, in particular Time Management, Ownership Management, and the retraction function. The major RTI functions Declaration Management and Data Distribution Management were reasonably straightforward to implement using SRTP and DMMC. Limited testing has shown our RTI to be functional, however a full test will require completion of our current effort to build a DIS-to-RTI translator, in order to use ModSAF to test the RTI with a significant data load.

[BrHa97] Braudaway, W. and S. Harkrider, "Implementation of the High Level Architecture into DIS-based Legacy Simulations", 1997 Spring Simulation Interoperability Workshop, March 1997

[Coh94a] Cohen, D., "NG-DIS-PDU: The Next Generation of DIS-PDU (IEEE-P1278)" 10th Workshop on Standards for the Interoperability of Distributed Simulations, March 1994

[Coh94b] Cohen, D., "Back to Basics", 11th Workshop on Standards for the Interoperability of Distributed Simulations, September 1994

[DMSO95] Defense Modeling and Simulation Office, DoD Modeling and Simulation Master Plan, U.S. Department of Defense, October 1995

[DMSO96] Defense Modeling and Simulation Office, High Level Architecture Rules Version 1.0, U.S. Department of Defense, August 1996

[DMSO97a] Defense Modeling and Simulation Office, High Level Architecture Interface Specification Version 1.1 Final Draft, U.S. Department of Defense, February 1997

[DMSO97b] Defense Modeling and Simulation Office, High Level Architecture Object Model Template Version 1.1, U.S. Department of Defense, February 1997

[DMSO97c] Defense Modeling and Simulation Office, HLA Data Distribution Management: Design Document Version 0.5, U.S. Department of Defense, February 1997

[FrPu97] Frosch, K. and J. Pullen, "Design and Prototype of a Dual Mode Multicast Application Gateway", 1997 Spring Simulation Interoperability Workshop, paper 97S-SIW-121, March 1997

[IEEE95a] Institute of Electrical and Electronics Engineers, Inc., Standard for Distributed Interactive Simulation, IEEE Standard 1278.1, 1995

[IEEE95b] Institute of Electrical and Electronics Engineers, Inc., Standard for Distributed Interactive Simulation - Communication Services and Profiles, IEEE Standard 1278.2, 1995

[MZPB95] Macedonia, M., M. Zyda, D. Pratt, D. Brutzman, and P. Barham, "Exploiting Reality with Multicast Groups: A Network Architecture for Large-Scale Virtual Environments", IEEE Computer Graphics and Applications, September 1995

[PuLa95] Pullen, J. and V. Laviano, "A Selectively Reliable Transport Protocol For Distributed Interactive Simulation", 13th Workshop on Standards for the Interoperability of Distributed Simulations, paper 95-13-102, September 1995

[PuLa96] Pullen, J. and V. Laviano, "Prototyping the Selectively Reliable Transport Protocol", 14th Workshop on Standards for the Interoperability of Distributed Simulation, paper 96-14-089, March 1996

[PuLa97a] Laviano, V. and J. Pullen, "Selectively Reliable Transmission Protocol" (draft-laviano-srtp-01.txt), Internet Draft (Work in Progress) March 1997

[PuLa97b] Pullen, J. and V. Laviano, "Adding Congestion Control to the Selectively Reliable Transmission Protocol for Large-Scale Distributed Simulation", Fall 1997 Simulation Interoperability Workshop paper 97F-SIW-018, September 1997

[PuWh95] Pullen, J. and E. White, "Dual Mode Multicast for DIS", 12th Workshop on Standards for the Interoperability of Distributed Simulations, March 1995

[Smit15] Smith, J., "Adapting ModSAF Applications to Comply With The HLA", 15th Workshop on Standards for the Interoperability of Distributed Simulations paper 96-15-048, September 1996

J. Mark Pullen is an Associate Professor of Computer Science and a member of the C³I Center at George Mason University, where he heads the Networking and Simulation Laboratory. He holds BSEE and MSEE degrees from West Virginia University, and the Doctor of Science in Computer Science from the George Washington University. He is a licensed Professional Engineer and a Fellow of the IEEE. Dr. Pullen teaches courses in computer networking, and has active research in networking for distributed virtual simulation and networked multimedia tools for distance education. Dr. Pullen recently received the IEEE's Harry Diamond Memorial Award for his work in networking for distributed simulation.

Vincent P. Laviano is a graduate student in Computer Science at George Mason University, and a Research assistant in the C³I Center Networking and Simulation Laboratory, where he has specialized in networking for distributed virtual simulation.

Marc O. Moreau is a graduate of the École Polytechnique of France and attended the École Nationale Supérieure de Techniques Avancées to complete a specialization in computing and networking. He is currently working with the Networking and Simulation Laboratory on the George Mason University C³I Center under an internship sponsored by the French Ministry of Defense.