NGI-FOM with SRMP
Selectively Reliable Multicast Protocol
GMUGateway is a protocol translator developed in Java for distributed simulations.
It provides the interoperability among the different types of simulation architectures.
The current version of GMUGateway converts Distributed Interactive Simulation (DIS)
protocol to High Level Architecture (HLA) Run-Time Infrastructure (RTI) service calls, and vice versa.
It is specific to the NPS DIS-Java-VRML implementation (on the DIS side) and the RPR-FOM (on the HLA side).
Using GMUParser, GMUGateway reads a configuration file and retrieves necessary information for the GMUGateway
configuration. This information includes IP address and port numbers for receiving packets
from or sending packets to.
The configuration file is written in the Q-XML language which is a Quality of Service (QoS) and Configuration
Specification Language. Q-XML is easy to use, able to express the full range QoS requirements and
configuration information, and compliant to XML, an evolving standard for information representational
languages. GMUParser uses XML Parser for Java from IBM AlphaWorks.
After setting up the configuration, GMUGateway creates an HLA RTI federation and joins the
federation as a federate, and then it translates from DIS to HLA and from HLA to DIS. For the translation
from DIS to HLA, it publishes the types of objects and interactions it will generate to the federation,
and continuously receives packets from a specified IP address and port. It generates objects or
interactions according to the types of the DIS Protocol Data Units (PDUs) into the federation.
For the translation from HLA to DIS, it subscribes the types of objects and interactions it will receive,
and whenever it receives a service call to reflect the attribute values of a registered object or an
interaction, it creates a DIS PDU with a corresponding type, and sends it to a specified IP address and port.
Path and Classpath Variables
Class path to run GMUGateway:
Class path to compile the source code of GMUGateway:
For running the complete application, the following software is required:
Run Time Infrastructure (RTI)
PDUs - Objects/Interactions Mapping
As per the DIS protocol, many kinds of PDUs are specified. NPS software DIS-Java-vrml
application does not support all those PDUs. The PDUs supported by the NPS software are well
For example, to know the values taken by fields of EntityStatePdu, see the java
documentation for the NPS software in
and go to the
DIS Data Dictionary
link in the class description. All PDUs supported
by NPS software are handled in GMUGateway.
The way PDUs are mapped into
objects/interactions, is well explained in detail in
Institute for Simulation and Training, “HLA Gateway Release 2.1 User Guide”.
for details about the various objects/interactions of RPR-FOM supported by GMUGateway.
Any new PDUs to be supported and corresponding object classes should be added in this file.
Gateway Process Flow
The following are the ordered events in GMUGateway processing for DIS to HLA.
- The first gateway instantiated creates the federation and joins the federation.
Subsequent gateways instantiated will then join the federation.
- The first gateway initializes the RTI simulation handles for the list of classes;
Only the objects of these classes can be published/subscribed.
- Every PDU received by the gateway is checked for the EntityID.
- Depending on the PDU field values, corresponding HLA object is created.
For example, if the PDU is pduType ESPDU, (the type of the PDU is determined by
pduType field in the ProtocolDataUnit class) the gateway will create an object of
leaf class of BaseEntity. There are several subclasses derived from BaseEntity class,
like MilitaryAirLandPlatform and MilitaryLandPlatform. The leaf class to be instantiated
is determined by the value of the entityDomain field in the ProtocolDataUnit class.
If the entity playing is helicopter for example, MilitaryAirLandPlatform object is instantiated.
The hierarchy of the classes and which class object corresponds to which PDU, is well
explained in gateway documentation cited above.
- If the entity ID is not already present in the hashtable which stores the RPR-FOM
objects with the key of the EntityID, the gateway creates the corresponding object.
If the entity ID is present, it calls the object attributes update method.
- The update object attributes method sends the packet details to the federation. As the
gateway has already published those objects to the federation, the federates which
subscribed for them receive the updated values of the packets. The updates are
accomplished by call back functions provided by RTI software, not the gateway.
- If any exceptions occur or when the application closes, the gateway resigns the
federate from the federation. The last federate to resign destroys the federation.
Changes in RTI-NG RID File
Changes at application level :
We do not want RTI to bundle the various update transactions or interactions because SRMP does the bundling.
We write the transport mode of each attribute of objects and interactions defined by user into the
file. When we send the data of an object, we send the whole attribute set (objectclass.update method)
only when we receive data about a new object (DIS Entity). After that, with every update, we send out
only the attribute values updated as
data one by one and
as a bundle
(objectclass.update_check method). When attributes are bundled, in RTI level, it checks the hash of
first attribute handle and the object class handle for the transport mode .