Requirement 3: Allow to vary the amount of latency in the data link between the

As mentioned in Chapter 2 and in the Specification phase, the simulation of the latency on the data link should be bidirectional; the latency appears when the operator sends a command to the UCAV and the latency should also appear in the presentation of the flight parameters and visualization of the aircraft towards the operator. Before treating the realization of the latencies, the latency inside the local network should be determined. A ping from one of the computers to the other computer in the network results in the image in figure 5.9:

Figure 5.9: Ping to the other computer on the LAN

It can be deducted that the reaction time in the network is less than 1 millisecond. This way it can be ensured that the influence of network latency is so small, that it will not have impact or addition to

simulated latencies.

Before delving into an approach to realise the simulation of latencies in the MVP, a clear designation of latencies should be performed. Latency from this point will be referred to as the time in milliseconds that is required for a round trip; meaning from the operator towards the UCAV and from the UCAV back to the operator on a full-duplex data link. This is coherent with reality and what was specified in the Specification phase. A Round Trip Time of 250ms denotes the following; the operator sends a command that is received by the UCAV only after the latency of half the round trip time (125ms) and the operator receives all information coming from the UCAV 125ms later than the UCAV actually send it. In the MVP, it will take 250ms before the operator sees the impact of his or her commands.

To realize the latency, two instances of FlightGear running on different computers are configured in a master/slave fashion where one computer (the master) sends its controls towards the slave and the slave routes its FDM data towards the master, both utilising the UDP protocol on the same destination and receiving port, as depicted in figure 5.10.

Figure 5.10: Two FlightGear instances coupled in a master slave fashion through UDP (blue lines) on port 5500

In this configuration, one FlightGear instance, the slave instance, possesses no FDM but solely routes the control input of a joystick or the Bridging Application (or both) towards the master instance over UDP. The separate UDP stream between the two instances is denoted by the blue lines in figure 5.10 The master utilises this information to locally perform all FDM calculations. The FDM information that the master has calculated is returned to the slave instance where it is utilised to control the air- craft on the slave instance. Now, two aircraft are visualised on both FlightGear instances, where the

master instance receives the controls from the slave instance and the slave instance receives the FDM information from the master instance. When no delay is applied, the two separate aircraft rendered on both FlightGear instances will move in sync. However, if a delay of for example 125 ms, is deliber- ately introduced on both separate UDP streams between the instances, the instances will receive the necessary information only after that delay. In chronological order: The joystick or control data from the Bridging Application processed by the slave instance is send towards the master instance over the delayed UDP stream, arriving at the master only after 125ms instead of directly. The master instance calculates the FDM information and sends it back to the slave instance over another delayed UDP stream, which causes the FDM information to arrive at the slave only after 125ms.

During usage, the operator sees two visualisations: One visualisation (that of the master) which shows what one would see if he or she was actually present at the position where the UCAV resides. This means that only the delay of the controls is visual (one way delay). However, the operator is actually located in his or her GCS. Thus he or she should see the delayed visualisation of his or her actions. This visualization is present on the slave instance since it receives the FDM information with a delay in respect to the master instance. The visualisation of the slave lags that of the master instance with the set delay. This way, by looking at the visualisation of the slave instance, the operator sees a RTT delay that is realised in a fashion that is coherent with reality.

To clarify, the Master instance henceforth referred to as ”Theatre View”, there it displays the situ- ation as it is taking place. The Slave instance is henceforth referred to as the ”Ground Control Station” since it displays the situation as the operator in his or her GCS will see. Summarized in figure 5.11:

Figure 5.11: Two FlightGear instances coupled in a master slave fashion through UDP (blue lines) on port 5500

Inducing delay on the UDP is performed by leveraging the functionality of the Netem package on Unix based operating systems [87]. Netem provides Network emulation for testing protocols and allows for the emulation of variable delay, loss, duplication and re-ordering of data packets that are handled with both UDP and TCP. The FlightGear options for the master and slave are defined as follows:

2 3 −−n a t i v e−fdm = s o c k e t , out , 6 0 , i p a d d r e s s o f s l a v e , 5 5 0 0 , udp 4 −−n a t i v e−c t r l s = s o c k e t , i n , 6 0 , , 5 5 0 0 , udp 5 −−fdm = a u t o m a t i c s e l e c t i o n 6 7 S l a v e : 8 9 −−n a t i v e−fdm = s o c k e t , i n , 6 0 , , 5 5 0 0 , udp 10−−n a t i v e−c t r l s = s o c k e t , out , 6 0 , i p a d d r e s s o f m a s t e r , 5 5 0 0 , udp 11−−fdm = e x t e r n a l

The commands for setting a delay on all outgoing traffic from both the master and slave machines can be realised with a queuing discipline command and consequently applying a filter to only affect the traffic outbound on port 5500. The following commands can be inserted in the command line of Unix based operating systems:

1 sudo t c q d i s c add dev e t h 0 r o o t h a n d l e 1 : p r i o priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 sudo t c q d i s c add dev e t h 0 p a r e n t 1 : 2 h a n d l e 2 0 : netem d e l a y 3000ms

3 sudo t c f i l t e r add dev e t h 0 p a r e n t 1 : 0 p r o t o c o l i p u32 match i p d p o r t 5500 0 x f f f f

f l o w i d 1 : 2

The user can set separate delays for each data stream and Netem furthermore includes options for applying delays with different distributions rather than a fixed delay. In reality, the delay will not be fixed, but may vary with a certain deviation based on a normal distribution. Netem possesses the ability to apply a delay with variation:

1 sudo t c q d i s c change dev e t h 0 r o o t netem d e l a y 100ms 20ms d i s t r i b u t i o n normal

The distribution tables are compiled on the operating system itself. It is also possible to configure a distribution based on own experimental data [87]. For the MVP, a batch script is written that allows the user to select the latency on a UNIX machine. This batch script is included in appendix J

To recap, the latency present on the data link can be simulated by placing to FlightGear instances into a master-slave configuration and deliberately introducing a delay between the data links of these two instances. This is achieved with the aid of Ubuntu functionality. The uplink and downlink are sep- arate datastreams and can furthermore be individually delayed. This is a simulation of latency which is true to real life UAV systems.