SE 4C03 Winter 2004Distributed Interactive SimulationApplicationsWritten by Michael StoverApril 6, 2004IntroductionThis project will be investigating the IEEE protocol that defines DistributedInteractive Simulations (DIS). This protocol, which is numbered 1278 by IEEE, defineshow simulation applications interact with each other over a network. When using theDIS protocol, applications communicate by passing each other data messages, which arecalled protocol data units (PDUs). There are at least ten different types of PDUs and theyrange from describing the state of an object in a given simulation to issuing a servicerequest for an object. For the purposes of this project, the Entity State PDU, whichdescribes the state of an object, will be investigated. A complete description of the EntityState PDU is not possible in a report this size. The purpose of this report is to introducethe reader to the DIS protocol and examine a few select fields in detail. How DIS relatesto the UDP protocol will also be examined, and real world applications of this protocolwill be given.The DIS and UDP ProtocolsDIS is an application layer protocol and has many similarities to the UDP andTCP protocols, which are at the transport layer. An Entity State PDU has required datafields with a structure that is similar in many ways to a UDP datagram. For example aUDP datagram has two main parts, the header which consists of four fields and is 64 bitslong, and a data portion. Similarly an Entity State PDU consists of a header and Figure 1: UDP segment structure 2data portion as well. Since DIS is at the application layer and UDP is at the transportlayer, a PDU is entirely encapsulated in the data portion of a UDP datagram. In the sameway, a UDP packet (header and data) is entirely encapsulated in an IP Datagram which isat the IP layer. Further information concerning the UDP protocol will be discussed laterbut now the PDU and its fields will be described further.The PDU HeaderAll PDUs have a header in the same way that all UDP Datagrams have a header.This header is needed to provide a simulation application with needed information so thatthe remainder of the PDU can be properly interpreted. As is evident from the belowdiagram the header contains 4 fields and is 32 bits in length. Of particular interest are thelast two fields. Figure 2: A PDU Header 1PDU Type: The PDU Type is very important and indicates the type of the PDUmessage. There are 10 types defined by the standard including Entity State ,Fire andDetonation PDUs. Since the size of the field is 8 bits, the number of types couldconceivably grow to 256. Based on this field a simulation application can properly parsethe remaining fields in the PDU. This is very important since the names of fields andthere sizes change depending on the Type of the PDU. Further information on thedifferent types of PDUs can be found in the IEEE standard. Length: The length of the PDU is very important since the size of an Entity State PDUcan vary in length based on the number of articulation parameters contained in the PDU.The length of the PDU (including the header and data portion) is defined as 1152 + 128nbits, where n is the number of articulation parameters. It should be noted that the size ofthe PDU is restricted by the maximum size of a UDP datagram, since the PDU iscontained entirely within the data portion of a UDP datagram. Two Addition Fields of the PDUThere are numerous additional fields in the Entity State PDU, and two select fields willnow be described. For a complete listing of fields and their size and location within aPDU, the referenced IEEE standard should be investigated.Figure 3: Timestamp and Entity Location 1Timestamp: An Important field in the data portion of the Entity State PDU is theTimestamp. This field keeps track of the time at which a PDU has been sent. The PDUpackets are sent across a network using the UDP protocol, which is an unreliableprotocol. It is possible, due to network congestion, for PDUs to appear out of order for aspecific entity. If such a situation occurred the destination application could examine thePDUs and only use the PDU with the most recent timestamp. Entity Location: Another important section of the PDU is the world coordinates record,which gives an entity’s position in the world, based on real world coordinates in the X, Yand Z directions. This record allows for entities to have locations associated with themthat are identical to actual locations on earth, and helps to make DIS simulations morerealistic. The units for this record are in meters and a high precision can be reached sinceeach of the 3 fields in this record are represented by a 64 bit floating point number. Asindicated by the below picture the origin is the center of the earth and the exact positionof an entity on the earth can be determined by adding the X, Y and Z coordinate vectorsof an entity. A simple example is to determine the position of an aircraft entity that isdirectly over both the Equator and the Prime Meridian. As the below picture shows, theY and Z values for this entity will be zero, therefore the position of this entity is entirelymade up of the X value. Whether the aircraft is in the air or on land can be determined bycomparing the X coordinate with the WGS 84 standard, which gives exact dimensions forthe shape of the earth. This standard can be used to determine the distance from thecenter of the earth to the surface at a given point on earth.Figure 4: Geocentric Coordinate System 1Real World ApplicationsImplementations of the DIS protocol in network applications are great examples of theadvantages of having a UDP protocol, which is not reliable and is based on best effort.All the information about an entity’s state is contained entirely in one PDU, which is inturn contained entirely in the data portion of one UDP packet, therefore a given UDPpacket is independent of every other packet. An application, which controls a tank entity,can emit the state of this entity through an Entity State PDU to the other applicationsparticipating in the simulation. This information will be sent at frequent intervals and isnot dependant on reliable communication. If a PDU is lost or delayed when travelingalong a network, the destination applications do not need to recover the lost information,but can simply wait for the entity’s next Entity State PDU. This next PDU will containupdated and complete information on