The integration of large drones flying under instrument flight rules in controlled airspaces is a complex task, yet a desirable objective. One of the main facilitator in this situation is the control of Air Traffic Management over most of the surrounding aircraft. The Air Traffic Controller Operators (ATCOs) maintain the separation between aircraft even if the drone is not able to do it by itself and can divert the required flights in case of emergency.
However, to benefit from the ATC, the remote pilote needs to communicate properly with the ATCOs. And that is a crucial issue highlighted in numerous projects involving real time simulations and actual flights, as will be seen later. Indeed, the communication between ATC and a RP goes through numerous channels with each one of them adding a certain amount of latency, see below.
This figure represents the different times (in seconds) allowed for each step (A-Z) for a two-way communication. The values are given for the Expiration Time (ET), i.e. the maximum time allowed for the message to be transmitted, and for the nominal Transaction Time (TT). Note that the latency is shared by three actors : the ATC (C-D and M-N), the network service provider (D-F and J- M) and the RPAS (G-H). So the maximum acceptable latency for the RPAS depends on the performance of the two other actors. Existing requirements impose a 10 seconds maximum limit on the total latency. However, this number includes the human reaction time; in facts, the latency allowed for the system, for a one way message, varies between 130ms and 485ms depending on the airspace [1].
Two european large scale demonstrator have studied the effect of latency on ATC/RPAS communications : ODREA [2] and TEMPAERIS [3]. In both experiments, a latency of 4 seconds has been introduced in real time simulations with actual ATCOs who relied mainly on two strategies to deal with the issue. The first one consist in using larger separation minima between the RPAS and the surrounding traffic, which led to a higher traffic density. The second one was to use optimized trajectories in anticipation of possible issues due to latency. It was noted that with a 4s latency, clearances where executed under 27s, with most of them well below 20s, so in an acceptable timeframe.
On the ATCOs side, a 4 seconds lag was perceived as manageable for “en route” and “initial approach” phases; but was deemed unacceptable for final approach, take-off, landing and taxiing phases. One of the main obstacle in approach phases is the message scrambling problem: when two, or more, messages are received at the same time, they collide making both of them incomprehensible. So, not only communication with the RPAS is impaired, but communication with other aircraft can be impacted too.
Though strategy changes or clearance updates were not needed, the simultaneous insertion of as few as three RPAS led to an increase in ATCOs’ workload, a decrease in airport capacity, and delays in commercial flights. As a results, it was not recommended to allow drones in airport with more than 20 movement per hour. Future work on latency impact in approach phases was advised.
The latency problem is an issue with the current C3link architecture though using terrestrial networks for voice communication remains and option and such networks are currently being deployed, e.g. in France. However, this poses two new problems: first, the message has to be rebroadcasted for the RPA’s surrounding aircraft awareness; second, interfaces are needed to transmit the message when flying above a territory not equipped with ground network, e.g. during cross-border operations, and these interfaces will add to the latency. In the mean time, ad-hoc solutions have been proposed like creating VHF channels dedicated to RPAS with a given latency.
References:
[1] EUROCAE WG-73, Concept of RPAS Required Communication Performance Methodology for the Command, Control and Communication Link, V0.,1, 2015.
[2] ODREA project, http://www.odrea.org, SESAR-JU
[3] TEMPAERIS project, http://www.tempaeris.org, SESAR-JU