MENU

SRMP Home

DIS-HLA Gateway
Gateway Download

NGI-FOM with SRMP
Demo Configuration

Publications

NetLab Home




Selectively Reliable Multicast Protocol
DIS-HLA GMUGateway
System Documentation

Contents

Gateway Overview

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

Path:
 .;
C:\RTI\Winnt-4.0-VC6\bin;
C:\RTI\Winnt-4.0-VC6\lib;
C:\jdk1.3.1\bin;
C:\jdk1.3.1\lib;

Class path to run GMUGateway:
 .;
C:\vrtp\dis-java-vrml.jar;
C:\RTI\Winnt-4.0-VC6\hla-rti13-java1.jar;
C:\RTI\Winnt-4.0-VC6\gmuGateway.jar;
C:\ProgramFiles\CosmoSoftware\CosmoPlayer;
C:\XML4J-3_2_0\xerces.jar;
C:\XML4J-3_2_0\xercesSamples.jar

Class path to compile the source code of GMUGateway:
 .;
C:\vrtp\dis-java-vrml.jar;
C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\source;
C:\ProgramFiles\CosmoSoftware\CosmoPlayer;
C:\XML4J-3_2_0\xerces.jar; C:\XML4J-3_2_0\xercesSamples.jar

Software Download

For running the complete application, the following software is required:

  • Run Time Infrastructure (RTI)
  • XML4J-3_2_0 (XML)

    • 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 documented in DIS-Java-VRML Javadoc . For example, to know the values taken by fields of EntityStatePdu, see the java documentation for the NPS software in DIS-Java-VRML Javadoc 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”.    IST-TR-97-08

    See DIS-HLA.fed in
    C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\gateway
    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.

    1. The first gateway instantiated creates the federation and joins the federation.
      Subsequent gateways instantiated will then join the federation.
    2. The first gateway initializes the RTI simulation handles for the list of classes;
      Only the objects of these classes can be published/subscribed.
    3. Every PDU received by the gateway is checked for the EntityID.
    4. 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.
    5. 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.
    6. 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.
    7. 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


    PARAMETER:
    FederationSection.DataDistribution.StrategyToUse
    (StrategyToUse Simple)

    PARAMETER:
    FederationSection.Networking.BundlingOptions.UDP.MaxTimeBeforeSendInSeconds
    (MaxTimeBeforeSendInSeconds 0)

    PARAMETER:
    FederationSection.Networking.BundlingOptions.UDP.MaxBytesBeforeSend
    (MaxBytesBeforeSend 0)

    PARAMETER:
    FederationSection.Networking.BundlingOptions.TCP.MaxTimeBeforeSendInSeconds
    (MaxTimeBeforeSendInSeconds 0)

    PARAMETER:
    FederationSection.Networking.BundlingOptions.TCP.MaxBytesBeforeSend
    (MaxBytesBeforeSend 0)

    PARAMETER:
    FederationSection.Advisories.AttributeScopeAdvisories.LazyObjectDiscovery
    (LazyObjectDiscovery Enabled)


    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 srmp_mode.txt 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 best-effort data one by one and reliable 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 .




    Last updated: 11/29/2008