# Rationale for a New Transport Protocol in the Aeronautical Telecommunication Network

Valencia Lala, Alain Pirovano, José Radzik

► To cite this version:

Valencia Lala, Alain Pirovano, José Radzik. Rationale for a New Transport Protocol in the Aeronautical Telecommunication Network. 2023 IEEE/AIAA 42nd Digital Avionics Systems Conference (DASC), Oct 2023, Barcelona (ES), Spain. pp.1-8, 10.1109/DASC58513.2023.10311286. hal-04416989

HAL Id: hal-04416989

https://enac.hal.science/hal-04416989v1

Submitted on 3 Dec 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Rationale for a New Transport Protocol in the Aeronautical Telecommunication Network

Valencia Lala and Alain Pirovano

ENAC, Université de Toulouse, France

soa-valencia.lala@enac.fr, alain.pirovano@enac.fr

José Radzik

ISAE-SUPAERO, Université de Toulouse, France

jose.radzik@isae-supaero.fr

**Abstract**—This research work identifies the reliability needs for aeronautical telecommunication network (ATN) applications taking into account the performance metrics imposed by the standards of the International Civil Aviation Organization (ICAO), typically the Required Communication Performance (RCP) documents. The study is based on the existing OSI protocol stack simulations using OMNET++ software. The data traffic generated by each node is based on a statistical analysis of real Controller-Pilot DataLink Communications (CPDLC) log files obtained from French Area Control Center (ACC). The simulation results highlight the limits of the OSI protocols in particular at the level of the transport layer with the Connection-Oriented Transport Protocol Class 4 (COTP4) compared to TCP New Reno version that we considered in this study. Moreover, relevant analysis of these limits allows us to define the end-to-end reliability properties and mechanisms that the transport layer should provide for the future ATN/IPS networks.

**Index Terms**—datalink communication, CPDLC, COTP4, reliability

## I. INTRODUCTION

Until the 1980's, aeronautical ground-to-board communications, to ensure flight safety, were based exclusively on voice exchanges via an analog system. Faced to the growth of air traffic, radio channels were approaching saturation point. The development of digital transmission technologies enabled the deployment of a complementary means of communication allowing the exchange of text messages. Initially reserved for airlines, this system called "Datalink" has been quickly adopted for Air Traffic Control (ATC). This system, included today in a more global infrastructure called Aeronautical Telecommunication Network (ATN), is based on the radio systems with which the aircraft is equipped such as HF, VHF or satellite.

The most known datalink application is Controller-Pilot DataLink Communications (CPDLC) which permits data communications between air traffic controllers and pilots. For instance, CPDLC allows air traffic controllers to provide frequency transfer instructions to pilots or to issue ATC clearance such as flight level, heading, or speed. ATN and existing air ground communication subnetworks are based on OSI protocols since they were deployed. These subnetworks are currently entering a new stage with their next migration to the IP protocol stack encouraged by international civil aviation organizations. The main reason for this new step is to ensure better interoperability with ground networks generally based on the IP protocol stack [1].

The objective of this paper is primarily to identify the reliability needs for aeronautical applications taking into account the performance metrics imposed by the standards of the International Civil Aviation Organization (ICAO), typically the Required Communication Performance (RCP) documents. A study based on the existing protocol stack (ATN/OSI, COTP4 at the transport level) allows us to determine the performance obtained for the applications currently deployed (CPDLC and Automatic Dependent Surveillance-Contract known as ADS-C), but also to highlight the shortcomings observed for applications more demanding, whether in terms of link capacity or time constraints.

This research work and the presented performance assessment are based on simulation results. These simulations are conducted using specifically developed models. In this aeronautical network model based on OMNET++ software (omnetpp.org), the communicating nodes generate a representative data traffic based on a statistical analysis of real CPDLC log files obtained from French Area Control Center (ACC). These generated data are sent and received via a modeled ATN/OSI protocols stack with notably Connection-Oriented Transport Protocol Class 4 also called COTP4. VDL Mode 2 and L-band satellite type links have been previously characterized in order to represent the behavior of typical ATN air-to-grounds subnetworks.

This paper is structured in four sections as follows. Section II introduces the operating principle of the CPDLC application and the COTP4 protocol. Section III describes the modeling process and simulation of the ground-to-board communication based on ATN/OSI. Section IV discusses the COTP4 simulated performance which is compared with TCP New Reno version. As a main result of our study, we highlight the relevant reliability mechanisms that the transport protocol should provide for the future ATN/IPS. Finally, section V concludes this research work.

## II. OPERATING PRINCIPLE OF ATN/OSI

### A. Specification of ATN/OSI

The ATN aims to connect data communication networks and services used by the global aviation industry. In order to enable the interoperability of avionics and ground data subnetworks, it is composed of application entities and communication services. The key objective of the ATN is to ensure continuous and transparent end-to-end communication between ground
and aerial applications, which is primarily covered by the transport layer. The OSI protocol stack, developed by the ISO in the early 1990s to define different layer interfaces and guarantee very high dependability for end-to-end communications, serves as the foundation of ATN/OSI [2].

The communication infrastructure for ATN/OSI consists of an air-to-ground subnetwork including VHF Ground Stations (VGS), VDL Mode 2 and SATCOM links, a set of air-to-ground routers, and a set of ground-to-ground routers for the interconnection with other OSI architecture model such as Air Navigation Service Providers (ANSPs) as shown in Fig. 1.

The overall architecture requires the use of ATN ground-to-ground routers which provide the interfaces between the various physical local ground networks within the end system operating entities and the airborne side. The ATN traffic is encapsulated and sent over the various radio link networks using the Subnetwork Dependent Convergence Function (SNDCF). The ATN end systems explicitly encompass the entire 7-layer protocol stack which hosts the appropriate application(s) [3].

Fig. 2 displays the complete ATN/OSI protocol stack. The CPDLC application is the most known datalink communication. The COTP4 is the basic transport protocol of ATN/OSI. This protocol constituting the main object of our study operates with Connectionless Network Service (CLNS).

<figure><img src="image_2.png" /><figcaption>Fig. 2. ATN/OSI protocol stack.</figcaption></figure>

## B. Illustration of CPDLC Principle

So far, the CPDLC services are only deployed in certain areas of the airspace. In the case where both Direct Controller-Pilot Communications (DCPC) VHF voice and CPDLC are available in the airspace, the controller and pilot have to choose voice for time critical communication. The CPDLC downlink refers to the message sent from the pilot to the controller and reversely for the uplink communication. Moreover, the

CPDLC provides a variety of services, including Datalink Initiation Capabilities (DLIC), ATC Microphone Check (AMC), ATC Communication Management (ACM), and ATC Clearance (ACL) [4]. The CPDLC must operate with respect to the RCP defined by ICAO Doc 9869 standards. The RCP refers to the reliability and the allocation time.

## C. Concepts of COTP4 Transport Protocol

COTP4 was designed to provide a reliable service over an unreliable network. This protocol can operate on Connection Oriented Network Services (CONS) and Connectionless Network Services (CLNS). As mentioned in previous subsection II-A, ATN/OSI operates with CLNS network. The needs of the application(s) supported by a certain ATN end system determine how a particular mode of the transport layer service is implemented and used. COTP4 provides various features in CLNS mode, including flow control between peer transport entities, detection and recovery from Transaction Protocol Data Unit (TPDU) loss, duplication, corruption, and out-of-sequence delivery via TPDU numbering on DT-TPDU, AK-TPDU, ED-TPDU, and EA-TPDU. Furthermore, the inclusion of time-out mechanisms implies retransmission procedures, enabling COTP4 to handle a loss of TPDU unnoticed by the network service provider, and the use of a checksum mechanism is optional [5]. COTP4 protocol implementations for air-to-ground sub-networks must support configurable values for all timers and protocol parameters [2].

## D. Congestion Control Mechanism for COTP4 and TCP

Congestion corresponds to the saturation of nodes in the network, causing delays in the routing of data until they

<figure><img src="image_3.png" /><figcaption>Fig. 1. ATN/OSI communication infrastructure.</figcaption></figure>
are eventually lost. Congestion management is one of the
important roles of transport protocols in ensuring end-to-end
reliability.

COTP4 avoids congestion issues by using Congestion Expe-
rienced Flags (CE-Flags) in the Network Protocol Data Units
(NPDUs) received from the network layer. The window size
determines the number of DT TPDUs allowed to be sent
without acknowledgment. This window size is defined and
updated by the transport entity receiving the data based on
the number of NPDUs received signaling congestion. If the
number of NPDUs received with CE-Flags is less than 50%
of the total number of the received NPDUs, the window size
should be incremented by adding 1. Otherwise, the receiving
transport layer might reduce the window size by multiplying it
by the window decreasing factor in range of 0.75 to 0.95 [2].
Then, the updated window size is advertised to the transport
entity sender with the acknowledgment. Subsequent TPDUs
will be sent within the advertised window size.

Since its first release, several TCP variants have been
introduced and standardized. Regarding the congestion control
mechanism they propose, most of them are based on the
Additive Increase Multiplicative Decrease (AIMD) algorithm
[6]. The primary goal of this AIMD algorithm is to take
into account events on the sender side in order to additively
increase or multiplicatively decrease the flow sending rate. In
this study, we consider the TCP New Reno version which is
relatively old but widely known and representative of how a
congestion control algorithm should operate. TCP New Reno
manages congestion through various phases such as slow start,
congestion avoidance, and multiplicative decrease. The slow
start mechanism allows the sender to increase exponentially
its congestion window (cwd) size up to a threshold (ssthresh)
each time previously sent data are acknowledged. When the
threshold is exceeded, the congestion avoidance phase begins
and the congestion window size continue to increase but
linearly. In the same time, the receiver indicates in each
segment a receiver window size (rcwd) to give a value
of its capacity. When sending data, the sender entity uses
a window size, known as the inflight size, which is the
minimum between cwd and rcwd. During the slow start and
congestion avoidance phases, the events taken into account
are the acknowledgment of previously sent data. The data loss
detection are the events that trigger the multiplicative decrease.
For instance, in case of isolated losses of TPDU, the inflight
size is divided by two and its new value is stored as the new
value for the threshold [7], this is known as fast retransmit/fast
recovery technique.

III. SIMULATION OF GROUND-TO-BOARD
COMMUNICATION BASED ON ATN/OSI

This section investigates on the simulation and modeling of
datalink communication between pilot and controller.

A. *Objective of the Simulation*

The simulation model aims to allow the comparison of
performance in terms of end-to-end delay for the COTP4 and

TCP transport protocols. To obtain such a comparison, it is
necessary to model not only the protocols themselves, but also
the traffic sources typical of the aeronautical context and the
components of the ATN network.

Two traffic sources are considered in this study:

* A source of traffic models the CPDLC messages ex-
changed between aircraft and the control center based
on message log files obtained from South West and West
ACC of France. The generated traffic have variable size
between 28 B to 375 B. Fig. 3 depicts a sample of
messages size for one-hour period, from 7am to 8am,
on one day in the year 2022.

* A second generic traffic source allows the sending of files of variable size as they could be generated by future aircraft maintenance applications, crew management, etc.

B. *Description of ATN/OSI Modeling*

In this work, ATN/OSI was modeled with end sytems and
the core network. As illustrated in Fig. 4, ATN end system can
be an aircraft or a control center. This end sytem is modeled
by considering the application layer, which generates traffic,
the transport layer, which includes transport protocols (COTP4
and TCP), the network layer, which transmits packets and
control information from the ATN network, and a link layer,
which serves as an interface to transmit frames to/from air-
ground links.

The ATN network is modeled in two stages as presented
by Fig. 4. This model distinguishes between the air-ground
data link (aircraft to/from base station) and the core network.
The air-ground datalink part is based on the replay of time
series from a model of the VDL Mode 2 link. This model
has been developed by ENAC and ISAE/Supaero. It provides
notably a measurement of the one-way transaction time giving
the delay measured between the application layer on the sender
side and the application layer on the receiver side. This makes
it possible to consider the effects of resource sharing between
the aircraft and the base station. The VDL Mode 2 link is
characterized by AVLC sublayer and waiting times induced by

<figure><img src="image_4.png" /><figcaption>Fig. 3. CPDLC messages size.</figcaption></figure>
<figure><img src="image_5.png" /><figcaption>Fig. 4. ATN/OSI model description.</figcaption></figure>

the CSMA p-persistent access technique as well as possible retransmissions due either to collisions or to losses. This induces a fairly high variability in the frame transfer time, as shown in Fig. 5 and Fig. 6.

The ATN core network is characterized here by periods of congestion such as can be caused by the convergence of data flows on the output buffer of a router or a switch. Congestion is modeled by a queuing model. During congestion periods, background traffic representing on average 85% of the output capacity is generated. This results, depending on the capacity of the delay-bandwidth buffer, in delays and a variable loss rate. In the case of a classic IP network, it is often adopted as a rule of thumb to set the buffer size to C\*RTT where C is the output link capacity and RTT the end-to-end round trip time objective in the network. The value of 200 kB was retained in the simulation, i.e. a target RTT of less than 2 s on a 1 Mbit/s link. As ATN networks mainly rely on MPLS label switching, a larger buffer size leads to a larger RTT target for the benefit of a very low packet loss rate.

According to [8], the set of requirements for RCP specifications are based on the transaction time, continuity, availability and integrity. The communication transaction time begins when the controller sends the instruction to the aircraft. Then it ends when the controller receives an indication of the response, which refers to Required Communication Monitored Performance (RCMP). There are different RCP types for CPDLC performance requirements, such as RCP 130, RCP 240, and RCP 400. Among these different RCP types, RCP 240 is eligible for oceanic and remote continental in terms of Required Communication Technical Performance (RCTP) and performance monitoring. Fig. 7 illustrates the RCTP of RCP 240, which is used as reference for this study.

<figure><img src="image_6.png" /><figcaption>Fig. 5. VDL Mode 2 Uplink delay.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 6. VDL Mode 2 Downlink delay.</figcaption></figure>
<figure><img src="image_8.png" /><figcaption>Fig. 7. Illustration of RCP 240 allocation time.</figcaption></figure>

# IV. DISCUSSION ON COTP4 SIMULATED PERFORMANCE

## A. Performance Comparison of COTP4 and TCP Protocols

The two protocols rely on very different flow control and congestion avoidance methods. As detailed in subsection II-D, COTP4 assumes network collaboration with explicit conges- tion notification (ECN). Losses are mitigated by retransmis- sions, but they have no impact on the amount of data that the transport layer is required to transmit. On the contrary, TCP relies mainly, if not exclusively on the Internet, on considering losses as implicit signal of congestion. The ECN option exists but has not been implemented in a practical way.

Analysis configurations are defined with the following op- tions:

* The transport protocol can be COTP4 or TCP New Reno.

* Applications are either “generic” or “CPDLC”.

* Congestion periods are introduced on predefined time intervals. The size of the bandwidth-delay buffer makes it possible to compare the behavior with a bounded delay and losses, or with an unbounded delay and no losses.

The main performance metric is the end-to-end application delay (time needed for data to be transferred from source to sink). In the case of CPDLC, it is particularly necessary to verify compliance with RCP objectives.

## B. End-to-End Delay Analysis

To evaluate the performance of COTP4 and TCP, two different scenarios using the generic and CPDLC applications introduced earlier was simulated. For each scenario, period- icals congestion and delay are added in ATN core network as described in subsection III-B. The first congestion period starts at 50 s and ends at 100 s, and the second period is from 250 s to 300 s of simulation time, which is indicated by blue background in the different plots showing the obtained results. These congestion periods are modeled to be randomly lossless

and lossy. The Sender Maximum Segment Size (SMSS) of COTP4 and TCP is settled to 500 B.

a) Scenario 1: Considering pilot sending messages to controller using CPDLC application. As specified in subsec- tion III-A, the size of the message generated by CPDLC are different and the persistence time to keep the end systems connected until connection release time was considered.

The messages end-to-end delay, in Fig. 8, indicates that COTP4 is slower than TCP. The lossless congestion period has less effect on the delay but the lossy congestion period increases the end-to-end delay to 1.8 s for TCP and 3.7 s for COTP4. The advertised window size of COTP4 is promptly increased after each data acknowledged when there is no ECN with the data received, as shown in Fig. 9. However, during and after congestion detected, the window size is maintained for a short period of time before being increased. Contrarily to COTP4, the *cwnd* size of TCP is not affected by lossless congestion and only when data loss occurred that the *cwnd* size decreases and starts a fast recovery as shown in Fig. 10.

b) Scenario 2: Using a generic application, we consid- ered pilot, on-board system or flight crew, sending files to a ground end system. In this scenario the size of the files generated have variable size between 1.5 kB to 5 kB and the connection is established without persistence time.

As illustrated by Fig. 11, we have average 5 s delay difference between COTP4 and TCP for the case of lossless congestion. However, when the congestion becomes lossy, COTP4 end-to-end delay increases up to around 18 s. Fig. 12 explains the behaviour of large packet size transmission higher than 500 B. It can be emphasized that the advertised window size is fixed to 1 during the congestion. The advertised window size increases randomly up to more than 4 times without congestion. Fig. 13 displays the behavior of lossy congestion for TCP. It can be seen that the *cwnd* size is instantaneously increasing up to around 35 kB when the congestion is starting. During the lossy congestion, the *cwnd* size is decreasing until

<figure><img src="image_9.png" /><figcaption>Fig. 8. Messages end-to-end delay with congestion.</figcaption></figure>
<figure><img src="image_10.png" /><figcaption>Fig. 9. COTP4 window size.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Fig. 11. Files end-to-end delay with congestion.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>Fig. 10. TCP Window size.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Fig. 12. COTP4 window size.</figcaption></figure>

minimum average value around 2.5 kB followed by a fast recovery behavior.

### C. COTP4 and TCP Performance Analysis

In general, as exemplified in the previous section, we observe better performance with TCP than with COTP4. However, some cases highlight very long end-to-end delays with TCP.

The operation of COTP4 is closely linked to the construction hypotheses of ISO/OSI networks. Congestion control relies solely on the cooperation of intermediate nodes which must explicitly notify congestion situations using Explicit Congestion Notification (ECN). Fig. 14 shows how ECN notification blocks the advertised window to size 1 for message transfers starting during congestion periods. It is also worth noting the slow dynamics of the progression of the window size outside congestion periods. The numbering by segments is here also

<figure><img src="image_14.png" /><figcaption>Fig. 13. TCP Window size.</figcaption></figure>
<figure><img src="image_15.png" /><figcaption>Fig. 14. COTP4 congestion control analysis.</figcaption></figure>

<figure><img src="image_16.png" /><figcaption>Fig. 15. TCP congestion control analysis.</figcaption></figure>

a limitation that we do not find in TCP where the numbering is done in bytes.

Hence, COTP4 is not suitable for a heterogeneous architecture. ATN networks now combine several technologies: air-ground datalinks in the process of being transitioned to ATN-IPS, links using IPSec tunnels as for example in the case of SwiftBroadband Inmarsat satcom system, MPLS core networks and IP local networks.

On its side, TCP is generally designed for the transfer of flows generating sequences of segments. As a result, we observe a behavior poorly suited to the very sporadic CPDLC traffic. Fig. 15 illustrates how TCP reacts when a segment carrying a CPDLC message is lost. If there are no other transmitted segments in the same stream, the retransmission relies solely on the RTO mechanism. However, this timing

mechanism is dedicated for detecting connection failures and induces a very strong reaction: drastic reduction of *ssthresh* threshold, slow start restart with an initial window of 1 SMSS. This behavior is not what is expected for an event that does not reflect any loss of end-to-end connectivity.

In mass flow case as previously described with generic traffic sources, TCP performance is only affected by any losses in the core network. Introducing ECN management could result, as with COTP4, in overreaction to events that do not affect end-to-end performance, as shown in Fig. 16. Compared to the RCTP of RCP 240, the highest end-to-end delays retrieved from COTP4 and TCP simulations respect the expected transaction time (TT). We have from Fig. 7 that the required end-to-end delay (TT/2) is equal to 60 s.

In the future ATN/IPS it will be necessary to find a versatile
<figure><img src="image_17.png" /><figcaption>Fig. 16. End-to-end delay analysis for TCP.</figcaption></figure>

transport layer capable of managing very sporadic flows and
at the same time more demanding transfers as generated by
new applications.

V. CONCLUSION

A research work on the performance analysis of COTP4 and TCP transport protocols has been carried out in order to determine the characteristics of a transport layer adapted to the ATN context. For this, we have developed a specific set of ICAO-compliant models in addition to previous models developed for air-ground datalink analysis. These models use the OMNET++ framework. The considered applications are CPDLC exchanges and transmission of files from aircraft to control center. The results have been evaluated in reference to CPDLC RCP [8].

The COTP4 protocol appears to be poorly suited to the migration from ATN/OSI to ATN/IPS paradigm. On the one hand, the hypotheses on the operation of the core network and the weak dynamics of the flow control, do not allow obtaining good performance as soon as the capacity requirements increase. On the other hand, the TCP mechanisms are poorly suited to very sporadic applications such as CPDLC.

This first work allows us to identify the potential weaknesses
of COTP4 and TCP. Future work in this study will focus on
specifying a transport layer to meet complex needs such as:

* the requirements of the CPDLC application, in particular with a fast retransmission mechanism in the event of loss of an isolated message,

* the requirements of future ATN applications with the support of flow transfers,

* and the management of the heterogeneous characteristics of the new air to ground datalinks and their simultaneous availability in some situations.

ACKNOWLEDGMENT

The authors would like to thank Area Control Centre
(ACC) of Bordeaux (France) for providing data to perform
the simulations.

REFERENCES

[1] R. D. Apaza and L. Popescu, "The way to the future has already started: ICAO Aeronautical Telecommunication Network (ATN) using Internet Protocol Suite (IPS) Standards and Protocol evolution update," IEEE/AIAA 37th Digital Avionics Systems Conference (DASC), London, UK, pp. 1-6, 2018.

[2] ICAO, "Manual on Technical Specifications for ATN using ISO/OSI Standards and Protocols," ICAO Doc 9880, 2nd ed., Montréal, 2016.

[3] EUROCAE, "ATN/OSI and ATN/IPS comparison," EUROCAE COMMUNICATION, 2016.

[4] A. Lehto, I. Sestorp, S. Khan, and A. Gurtov, "Controller pilot data link communication security: A practical study," Integrated Communications Navigation and Surveillance Conference (ICNS), pp. 1-11, 2021.

[5] ISO, "Information technology - Open Systems Interconnection - Protocol for providing the connection-mode transport service," ISO/IEC 8073, 4th ed., 1997.

[6] S. Mascolo and L. Grieco, "Additive increase early adaptive decrease mechanism for tcp congestion control," in 10th International Conference on Telecommunications, 2003. ICT 2003., vol. 1, 2003, pp. 818-825 vol.1.

[7] J. Himeedah, A. Hamouda, M. Taher and S. Sati, "TCP Congestion Analysis of Wired and Wireless Links Using NS3," 2022 IEEE 2nd International Maghreb Meeting of the Conference on Sciences and Techniques of Automatic Control and Computer Engineering (MI-STA), Sabratha, Libya, 2022, pp. 361-365

[8] EUROCAE, "Safety and performance standard for baseline 2 ATS data communications (baseline 2 SPR standard)," EUROCAE COMMUNICATION, 2014.