Distributed Interactive Simulations
Early 1994, TNO decided to be the coordinator of the Distributed Interactive Simulation (DIS) demonstrations during the International Training and Education Conference (ITEC)-exhibition to be held in April 1995. The offer included the provision of technical support by the Laboratory to the participants. For the Equipment management and IT-services department (Apparatuur, IT-Voorzieningen en Instrumenten or AITV) this meant that all knowledge about networks and many dialects of Unix had to be made available. Because of uncertainties about required bandwidth and the required number of international connections, we decided to base external connectivity on the new ISDN services provided by the international telephony providers such as the Dutch PTT. Despite the first estimations by PTT-Telecom, this turned out to be a larger technical problem than expected. At that moment, PTT-Telecom had only a very limited experience with data connections via ISDN. Moreover, ISDN-routers had not yet been formally approved (no blue certification sticker). We had to hide them between all other network equipment. We also had to convince a PTT employee during the weekend to change the ‘speech only’ bit on the leased ISDN lines to speech and data services (although that was the objective of the Integrated Services Digital Network (ISDN)). In the end, only the NLR took part in the demonstrations with a flight simulator operated in Amsterdam coupled via ISDN using the DIS protocol.
In preparing of the demonstration exercises, one of the dozens of participants thought it was funny to throw a ‘bomb’ already during the preparation phase at the moment all kinds of (simulated) tanks and crew carriers took their starting positions. It took us a while to determine which participant the culprit was by analysing the logging data. At the moment that a high delegation of the Dutch Ministry of Defence visited the ITEC’94, we inserted a packet filter in the network. After a perfect demonstration, an ‘angry’ participant complaint to us and wanted to know why his projectile had not hit anything. With a straight face, we browsed through the logging, and stated that we were also surprised that apparently projectiles were apparently designated at random as ‘unexploded bomb’ by the simulation software!
Based on these experiences, the Equipment and IT Services department of TNO-FEL as well as the various DIS project leased a set of ISDN lines and purchased ISDN equipment for the relatively simple installation of high-speed connections with various international research locations such as DERA Chertsey, England (later QinetiQ) and the US Navy in Orlando, Florida (November 1994).
We used the DIS protocol mode of relative time of the systems. From the successive (UDP-based) packages, a relative time base was derived and continuously adjusted for the planes and tanks. This also happened on the other side of the connection. But was that correct? This seemed to go well for short tests. Different time clocks could, however, mean that a tank shot to barrels could still fire a shot in the simulation due to a deviating simulation time?
TNO and the US Army STRICOM investigated whether relative time -a DIS protocol functionality- at a large distance in longer duration interactive simulations was a feasible option. Experiments with the Network Time Protocol (NTP) on SUN and Silicon Graphics systems in combination with GPS clocks in Florida and The Hague showed that the relative time clocks of the remote systems increasingly diverge from each other. The conclusion was that only ‘absolute’ time clocks should be used in the DIS protocol. In The Hague, we were able -with permission- to ‘tune’ in a couple of days the system clock of a SUN system in Orlando to within a deviation of 1 millisecond per 24 hours. We also determined that the American system was located at 7243.2 km +/- 0.6 km distance from TNO and that the bits via an ISDN connection from KPN took a scenic byway of an extra 2,500 km as compared to an ISDN connection set up from the United States (112 ms versus 80 ms). A full report can be found here.
For communication during the tests, we used an Internet Relay Chat (IRC) channel #timesync. Once in a while, some outsider tried to start a conversation but they did not understand chat sequences like “ok, the hub is working!!”, “We have a T72. No movement.” “Ready for ground vehicles fast?” and dropped out the IRC-conversations soon after not getting any response.
In 1995, we also installed ISDN routers at the US Army base in Ramstein, Germany from where we connected to DSInet (IP version 5 a.k.a. ST-2 protocol -based high-speed network to globally connect simulators) and through that to an F-18 flight simulator of the US Navy in Orlando, USA. NLR provided an F-16 trainer, Thomson Training & Simulation and DRA, Farnborough provided two F-14 trainers, and TNO Soesterberg an Apache-trainer. They flew over the artificial terrain generated in The Hague and interacted with the simulated targets on the ground at ITEC’95 in the Statenhal, The Hague. Other helicopters and aeroplanes, as well as tanks, armoured vehicles and artillery support were generated by computers in the Statenhal, e.g. an M3-Bradley and an M1-Abrams. In parallel to the ITEC, an Internetworking event took place at the RAI in Amsterdam. Operated through an ISDN-link, a life 2D-situational display of the battlefield was shown at that event.
On an ISDN link (2* 64 kbps) the theoretical maximum was 128 kbps. With some 70 entities within the scenario, the measured (2-3 times compressed ) data rate was some 300 kbps. Some filtering had to take place to provide only those data of elements of direct interest to the simulators coupled to the ISDN links.
In the week before the event, all DIS systems were installed at TNO. Additional air conditioning proved necessary. In the minute after the final rehearsal, someone plugged a telephone charger into probably the last free power socket. That overloaded all the power circuits: it became very quiet.
These DIS demonstrations learned us that such a scenario with many players requires coordination with all participants using ‘time cues’. This made it possible to be in time near the action with the (TNO operated) stealth viewer application. As a result, the spectators had the best view of where the action occurred in the unfolding scenario.