Communication Transport Protocol Strategies for Rail Applications

Abstract

Current technologies for managing rail traffic such as the Global System for Mobile communications for Railway (GSM-R) will be no longer be available within the upcoming years. The European Shift2Rail Joint Undertaking (S2R-JU) proposed the Adaptable Communication System (ACS) to overcome this problem. In this work, we model the ACS by abstracting it at the Internet Protocol (IP) level, using tunnels for datagrams’ transmission as a communication bearer is available along the rail. Then, to evaluate its performance, an ACS emulator has been implemented. The core part of it is a Tunnel Manager which can establish pseudo-virtual circuits through multi-bearer tunnels, forcing datagrams on a service-basis to follow specific paths between gateways (i.e., from on-board to a train to the network-side rail control center and vice versa). The Tunnel Manager can properly select a given tunnel/bearer for sending messages (and duplicating them on redundant paths) of critical rail applications for train traffic management, relying on tunnels based on either connection-oriented protocol (i.e., the Transport Control Protocol, TCP), connectionless protocol (i.e., the User Datagram Protocol, UDP) or a mix of them. In this paper, we investigate the best solutions in terms of transport protocols for implementing tunnels through the bearers. Results are based on two main use cases: i. the position report/movement authority messages for the European Rail Traffic Management System (ERMTS) and ii. the critical file transmission, considering either TCP or UDP as tunnel transport protocol. For the first rail application, one UDP bearer can be selected only if the end-to-end channel delay is lower than 100 ms and the experienced packet loss is lower than $4\%$ in the whole crossed network. Two UDP bearers, one TCP bearer or two mixed UDP/TCP bearers should be selected in case the channel delay is greater than 300 ms and the experienced packet loss is greater than $15\%$. Considering the critical file transfer in the rail scenario, TCP should be selected with two bearers to have a throughput greater than 50 Mbit/s even for a packet loss of $1\%$.

1. Introduction

The rail sector is expected to increase enormously in upcoming years. The forthcoming Digital Transformation will be based on reducing any kind of carbon footprint, and the transport sector will be one of the most impacted sectors. In fact, rail transport will be the favored method to move people and freight worldwide due to its reduced carbon dioxide (CO${}_2$) emissions. The increase in the adoption of rail in transport has raised interest worldwide, and this will bring to some challenges for rail operators. They will be expected to operate more efficiently, thus increasing the number of trains per kilometer, as well as to guarantee safety and service quality both for passengers and freights. A few years ago, safety and optimization operations for rail traffic management and to avoid train collisions were performed by the Automatic Train Protection (ATP) system. This is a complex architecture based on track-side equipment placed at about 1–2 km in the rail path (and usually at $1.2$ km in critical points such as rail exchanges and station approaching), which signal to the train driver how to adapt the train speed [1]. This system is not very reactive to signals, which is a further problem, and it is standard in all rails crossing national borders.

Recent papers have investigated transport safety, including for example, the high in-train compressive forces that could determine train derailment [2]. Nevertheless, a first step in innovation in this field is the development of a Single European Railway Area in order to achieve fully interoperable rail in Europe. The first step has been the European Rail Traffic Management System (ERMTS) set up by the European Union in the Directive 96/48/EC [3] to specify procedures and technologies, and Directive 2001/16/EC [4] for the interoperability of the trans-European conventional railway system. This is based on the European Train Control System (ETCS) and the Global System for Mobile communications for Railway (GSM-R) and has been deployed for mainlines. GSM-R has the same characteristics of the classical GSM but it transmits on a dedicated frequency spectrum assigned to the rail operators. Moreover, dedicated base stations have been deployed by rail operators to provide connectivity services along their lines, thus supporting rail applications. Supported services are: (i.) voice communications (for rail staff and emergency calls), both for point-to-point and group calls, and (ii.) low-data rate services for railway operations (ETCS L2/L3 operations). Unfortunately, this strategy is no longer bearable due to the management of the technological infrastructure and costs. Moreover, GSM will be guaranteed until 2030.

Two main proposals have been raised. One is proposed and supported by the International Union of Railway (UIC) and by the European Union Agency for Railway (ERA) by 2013. In fact, in 2015, the Technical Committee Rail Telecommunication (within European Telecommunications Standards Institute, ETSI) and 3rd Generation Partnership Project (3GPP) started to work on the Future Railway Mobile Communication System (FRMCS). This study concerns (i.) the choice of technology or technologies for communications; (ii.) the assigned spectrum for future radio communication system for railway, and (iii.) the required additional investment on new radio sites with respect to GSM-R radio sites. The second initiative has been supported by the European Shift2Rail Joint Undertaking (S2R-JU), in which the concept of Adaptable Communication System (ACS) is proposed. While FRMCS is managed by telecommunication operators, ACS has the Over-The-Top (OTT) approach, which implements the bearer independence and supports connections over multiple networks.

Other works proposed the adoption of Multi-Path Transport Control Protocol (MPTCP) to solve this problem. In [5], some experimental results have been provided, but only for increasing the overall data transfer throughput by utilizing the multihoming capabilities of communicating nodes. This is not the case required by the rail operators and it is not manageable by them, as they need technology redundancy rather than path redundancy over the same physical interface. Moreover, MPTCP also incurs performance degradation when the number of lost packets increases (i.e., the well-known problem of Transport Control Protocol, TCP) [6], instead of using a dedicated tunnel manager as proposed in this work. Other works tried to solve the rail application connectivity by efficiently characterizing the radio channels in railway environments, as in [7]. In [8], some experimentations have been presented supporting the use of cellular systems for providing rail applications in train-to-network communication. Differently from these works, we propose to overcome the necessity of dedicated radio network deployment or using public networks to provide connectivity for rail applications by managing connections at the IP level and trying to take advantage of the available radio bearers along the rail line, thus selecting the most appropriate and suitable bearer(s) based on the application requirements.

One of the contributions of this work is the analysis of user and system requirements related to the ACS designed to meet the growing needs of railway operators interested in communication for different types of critical services, where one of the most important aspects is noise resilience and the ability to manage redundancy provided by multiple bearers. The connectivity requirements particular to the ACS model have been translated into the domain of IP networks to find a reasonable abstraction and an effective and efficient implementation for some concepts, such as the representation of the redundant bearers, but using standard solutions and protocols, even if recombined in a novel way.

One of the requirements of ACS is to ensure the transmission of user data traffic on specific bearers, based on some configuration criteria such as Quality of Service (QoS). The proposed ACS model along with its implementation is based on the concept multi-bearer gateways, which allow User Agents, both users and producers of communication services, to communicate by establishing pseudo-virtual circuits by identifying each communication endpoint via an IP-address associated with a logical interface. Since there is no guarantee to ensure that IP datagrams follow precise paths, as IP forwarding is simply based on the destination address, we solved this problem by binding the agents to such logical interfaces (which are based on Linux IP Virtual Local Area Network, IPVLAN) and implementing an extension of Session Initiating Protocol (SIP) to signalling a circuit, which implies that both gateways and hosts dynamically update forwarding tables during the signaling process. So, we still rely on standard IP routing but force datagrams, on a service-basis, to follow specific protected tunnels between gateways.

The third important contribution of this work is the way we manage the tunnels’ protection, which is based on multi-path transport protocols and data duplication, in addition to retransmission mechanisms given by Transmission Control Protocol (TCP). The software we developed can combine different transport protocols with multiple protection criteria, but any complexity is hidden to the application layer which ignores how the gateway will forward the data across the bearers. Since we use standard IP protocols and technologies, the implementation is also efficient and cost-effective.

For this work, we implemented a testbed based on an emulator developed to evaluate the ACS performance. Part of the emulator has been developed in [9], where simpler use cases (e.g., tunnel protocol only based on Generic Routing Encapsulation, GRE) and metrics (e.g., latencies through Internet Control Message Protocol, ICMP) were considered. In this paper, we propose a new version of Tunnel Manager, which can set hybrid transport protocols (e.g., TCP and User Datagram Protocol (UDP), simultaneously). Moreover, a modified version of SIP has been adopted for service discovery and user registration along with new emulator for railway signalling protocols, which has been used to generate new and more realistic test-cases. To investigate the most suitable strategies in selecting transport protocols, two main rail applications have been considered: (i.) signaling and (ii.) generic data transfer (i.e., via file transfer). The first rail application is fundamental for the normal operations of the train movement and it is based on the train transmitting its position report (PR) to the remote control center, aiming at managing train traffic along the overall railways. After receiving the PR of each train, the control center evaluates the train position and the positions of the other trains, thus responding with the authorization of the movement (or movement authorization, MA), not allowing the train to reduce its speed or stop. The second rail application we considered is related to the transmission of critical files. In this case, we evaluate the available data rate and the latency required by a file transfer in case multiple bearers are adopted the ACS.

The paper is organized as follows. In Section 2, the rail context is described and the main rail applications and their requirements are recalled. Furthermore, in Section 3, the ACS architecture and its characteristics are detailed. In Section 4, the proposal of registration of the rail applications in the whole network to make them available to clients is described. In Section 5, the testbed implemented is presented in order to evaluate the potentials of ACS. In Section 6, results of the emulator and the testbed are reported. Finally, conclusions are drawn in Section 7.

2. The Railway Context

2.1. Rail Environment

Rail lines differ according to the speed at which a train can travel. They can be divided into the following types: i. Mainline, which connects cities and sometimes crosses nations, and usually has a dedicated high-speed line for passengers; ii. Regional, used to connect between cities but is a low-capacity passenger line; iii. Metro/Urban, which crosses part of city, a city or connects neighbor cities, and is usually dedicated to urban mass transit; iv. Freight, which connects cities and sometimes crosses nations, and is dedicated to transporting freight, thus no passengers are allowed.

2.2. Railway Applications and Users

In the rail sector, applications are related to the users and typical use cases in the rail world. It comprises (but is not limited to) drivers, persons on platforms (e.g., dispatchers and traffic controllers), persons at level crossings, conductors on-board trains (responsible for operational and safety duties such as ticket collection, observing door closure, performing safety tasks in case of an emergency/accident), catering, security and train preparation staff on-board trains, and train and track-side maintenance staff.

Within this sector, it is possible to identify the following service categories [10,11]:

• Signaling. This refers to the transmission of safety-related information regarding the movement of trains, needed for the operational work of train transport services. It refers to the regular and frequent message exchange between an application on-board a train and a corresponding ground application used to allow trains to move a distance with a speed based on track limitations and known braking capabilities of the specific train. Then, it is fundamental to know the current position of the train at all times and the characteristics of the rail environment where the train is moving. Typically, the train sends its position to the remote-control center (namely, the position report, PR) and the control center responsible of the safety of the train and of the on-board passengers sends back the authorization for movement along the rail line (namely, the movement authority, MA). Examples of this protocol are Computer-Based Train Control (CBTC) in the urban/metro line and the ERTMS/ETCS in the other rail environments.
• Critical voice. This is related to communication between internal staff such as driver(s) and controller(s) or emergency calls. In the first case, it regards operation and movement of the train and can be one-to-one or a group call. In the second case, it informs driver(s) and controller(s) about possible hazards along the track (e.g., people near the rail line, obstacles on the track). Voice over IP (VoIP) with an Adaptive Multi-Rate Wide Band (AMR-WB) speech codec is implemented up to $23.85$ kbit/s, plus transport and application protocol overhead. Due to its nature, latency and setup time should be low even at a high speed of mobility.
• Critical video. This provides highly reliable and available real-time video streams supporting the train operations. It can be from the train to the ground and vice versa. Typical use cases include automatic obstacle detection for Automatic Train Operation (ATO), monitoring of doors inside trains and people on platforms. Two options are possible: uplink Closed-Circuit TV (CCTV) for surveillance and downlink Platform TV (PTV) for platform surveillance, thus different requirements may be available.
• Critical data. This refers to generic applications important to the train operation and to prevent damage to people or to one o more elements of the infrastructure. Examples are downloading data needed for a journey to a single location, connecting a smart object controller on the wayside to the inter-locking systems and detecting possible train interruptions, above all, for freight trains (i.e., the vehicle integrity).
• Non-critical data. This refers to non-critical services for the operation of the transport service. Possible cases are: i. predictive maintenance: transport vehicle sends to the remote control center the report of on-board sensors in order to give information on the vehicle’s status to perform a predictive maintenance; ii. public announcements: along the track as well as close to the stop station, public transport staff can spread out public announcements generally related to non-periodic activities such as information on vehicle delays, changes in scheduling, and accidents along the way; iii. Passenger Information System.
• Passenger connectivity. Based on government requests, this refers to providing Internet connectivity both to passengers for personal reasons (as if they are at home or in a coffee shop) as well as business passengers (thus improving their productivity). Examples are document access, video streaming and call conferences, and entertainment/gaming. Connectivity can be provided through access nodes within the train.

The last service category has been included in the description although it is not a requirement for rail operations. Nevertheless, it has been receiving great interest both from passengers and governments for people’s satisfaction, societal demands and as an economic driver.

Table 1. Services and requirements for the rail case [11].

Service Category	Service Examples	Required Bit Rate
Signaling
	ERTMS (e.g., PR and MA); Request for rescue cases;	<1 kbit/s
Critical video
	Video inside the cabin; Video outside the cabin	0.1–2 Mbit/s per camera
Critical voice
	Call from/to vehicle staff; Audio from passengers in danger;	30–48 kbit/s (Single call)
Critical data
	Vehicle integrity; Images inside/outside the vehicle	1–5 kbit/s; 100 kbit/s
Non-critical data
	Tele maintenance; Public announcement; Passenger Information System	100–500 kbit/s in uplink, <100 kbit/s in downlink

reports the service categories, the functional requirements of communication for each of them in terms of required bit rate and some service examples or supporting applications.

2.3. The ACS Approach and Its Architecture

In the ERMTS/ETCS, some supported features such as emergency calls are strictly integrated into the communication technology (i.e., GSM-R), thus depending on its implementation. In other terms, the network capabilities and application requirements should be independent to avoid serious issues since the evolution of the communication technology may have a different timeline with respect to the application innovation and vice versa. The need to abandon GSM by 2030 due to its decommissioning forces us to move railway applications to other communication technologies that may not support the same capabilities as GSM-R but may support others. It becomes fundamental to separate the communication bearer considered as transmitting technology with respect to the rail application as a functionality supported by the rail system. This is the bearer independence concept, which is reported in Figure 1.

According to the Bearer Independence Principle (BIP), two or more user applications communicate over a single or multiple networks without any dependence of the specific bearer capability (i.e., network or access technology). In practice, data can be transported on a bearer based on Internet Protocol (IP) provided by one of the available technologies. Reliability, mobility, throughput increase and service continuity may be obtained by bearer duplication or selection. The management of IP-based bearers should consider the QoS and Quality of Experience (QoE) as perceived by the rail application running on top of the transport protocols, i.e., end-to-end (see Figure 1).

The flexibility of this approach allows us not to be strictly tied to any communication technology but also allows for the developments and updates that a telecommunications operator implements in its networks or only in parts of it (e.g., in the main cities), forcing the rail operator to solve the train traffic management in other ways (such as with local technologies or track-side elements).

The Adaptable Communication System (ACS) defined in [11,12] has been designed in accordance with the BIP approach. Further description has been presented in [13]. Its implementation is realized through the ACS Gateways (ACS GWs) installed on board and in the network. ACS GW is able to interface with several and different communication bearers (both wired and wireless) to provide end-to-end connectivity for railway applications from the On-Board Unit (OBU) to the Radio Block Centre (RBC) server where the rail applications of the rail operator run, and vice versa. A general scheme of the ACS architecture is reported in Figure 2.

The interfacing of ACS GW with the bearers is realized at the IP level to fully implement the BIP concept. The applications can communicate through the ACS GW able to manage more IP-based bearers, that can be both alternative and/or traditional, public or private. The ACS GW can not control the bearer itself but it can select the most suitable bearer according to the measured QoS parameters (e.g., latency, packet loss and bit rate), as provided by the Mobile Network Operator (MNO) based on the requirement of the specific rail application, such as those in Table 1 [12]. To this purpose, ACS-GW implements an additional communication layer based on IP protocol and independent of each bearer, as shown in Figure 3.

The On-Board ACS GW (OG) is the communication node between the local device (host) where the On-Board Application (OA) runs and the communication bearers are, provided for example by 3GPP terrestrial networks such as 4G LTE or 5G and non-3GPP networks (such as satellite [14]). The OG is directly connected to the ACS GW on the network side (namely Network ACS GW or NG) through an ACS tunnel over one or more radio communication bearers available in a specific area and time. Above the ACS tunnel between the OG and the NG, the OA is committed to establish an IP link directly to the application on network side, namely Network Application (NA). In this way, the ACS GW can guarantee the required QoS/QoE targets thanks to multi-link connections in different wireless networks and an intelligent and efficient use of the available communication bearers. From a network topology point of view, two or more ACS GWs can also be connected using a peer-to-peer network scheme enabling ad-hoc or mesh connectivity.

3. Modelling the ACS

In this section, the description of the ACS model is provided and used for the testbed implementation and to evaluate its performance.

A conceptual representation of the elements related to the new communication system based on ACS can be represented as in Figure 2, which contains the essential components of an ACS-based network architecture. From left to right we schematized the on-board host devices where user agents (UAs) run. Such devices are connected to an on-board ACS Gateway, which exposes interfaces to offer connectivity to the User Agents towards the bearers and through them to services exposed by server User Agents connected to the network ACS GW. The bearers, at the centre of the figure, can be imagined as channels implemented with different technologies for transporting IP network traffic.

Regardless of any complexity related to how the components of Figure 2 can be implemented, the ACS can be effectively represented by means of a network of hosts and related network interfaces, distinguishing between physical network interfaces (e.g., the ones representing the bearers) and logical network interfaces (i.e., the tunnel interfaces across the bearers and User Agent logical endpoints). Finally, none of unnumbered interfaces need to be represented in the topology since they are transparent in terms of IP addressing.

Figure 4 represents such a logical model where physical and virtual interfaces are part of the ACS layered network topology. The scheme of ACS topology places the gateways at the centre. The host devices where the User Agents run (by means of client and server applications) are connected to each adjacent gateway. So, the on-board devices are connected to the OG, and Network Devices are connected to the NG. The connectivity between on-board and ground user agents is established by a virtual circuit. A virtual circuit is nothing more than a defined path (through routes and IP tunnels) between two ACS User Agents. The gateway role is to abstract any complexity due the presence of multiple bearers and provide the necessary signaling mechanism for service registration and circuits’ establishing.

A virtual circuit is obtained by IP routing and multi-path tunneling. Multi-path tunnels are created between the two gateways. The number of bearers and transport technologies involved in a multi-path tunnel depend on configuration, which is meant to ensure a required QoS. A tunnel can be associated to multiple aggregated bearers via a redundancy mechanism based on multi-path transmission techniques.

The second important aspect of virtual circuit is the logical address (and the logical device) used to represent the endpoints of a virtual circuit and to identify the User Agent in the ACS network. Each User Agent, which can represent either a client or a server of a service, is identified by a unique IP address resolved by the Domain Name System (DNS) once an agent is registered.

From the implementation point of view, each host device can create a virtual network device by using IPVLAN Driver [15] as a result of a control plane signaling based on the SIP [16] and DNS protocols. Each IPVLAN logical interface represents the endpoint of a virtual circuit.

4. Implementation of the ACS Control Plane

The creation of the virtual circuits is based on a signaling protocol, and the paradigm adopted for the ACS is the same as the SIP, which is a well-known application layer network protocol used to create, modify and terminate sessions between two or more participants.

The ACS GWs and ACS Host Devices implement the SIP to provide end-to-end application management functions related to the connection status, session setup, QoS parameters required and negotiated, IP address settings, user authentication and profiling. More in detail, the SIP has been used to provide User Agents with the capability to register themselves to a Registrar to have assigned a logical IP address. The registration process of the User Agent is made hop-by-hop, which means each User Agent connects directly on the adjacent gateway. The OG assumes the role of SIP Proxy in the control plane, while the NG acts as SIP Registrar. SIP messages between two SIP User Agents are propagated hop-by-hop (as shown in Figure 5) since each host of the network needs to keep a local network topology database updated and a related routing table via SIP protocol message exchange. The SIP registration mechanism allows the SIP participants to announce or request a service.

A SIP session and a related virtual circuit are created by an invitation mechanism, as described in RFC 3261 [16]. In Figure 6, a sequence diagram shows an example of on-board User Agent which is registering to the network gateway via an OG (acting as SIP proxy) to be assigned with a logical IP of the ACS network.

Once two User Agents are registered, they can create a session and consequently a virtual circuit by using the SIP INVITE method, as shown in Figure 7.

A circuit between two agents is composed of IPVLAN logical interfaces, which identify the end points of the circuit, and the tunnel interface via the local access interface that each gateway exposes to the agents. How the packets go through the bearers is decided by the gateway based on a given configuration, but such complexity is hidden to the agents, which can only address the virtual interfaces related to the multi-path tunnels. A simplified version of the ACS topology can schematically show how a virtual circuit is established. The schema shown in Figure 8 is the one used to carry out our performance tests.

5. ACS Emulator

5.1. Testbed

The testbed of Figure 8 is based on a network of four Linux boxes, two of which are used to simulate the ACS GWs. As a relevant example of a virtual circuit and its implication on routes and multi-path tunnels, the scheme reports a configured virtual circuit used to carry out the performance test where different tunnel configurations were tested.

Each gateway of such a simulated network can be configured to assume the role of the OG or the NG. As shown in Figure 8, the OG is simulated by a Linux box named host1 and a network gateway by a Linux box named host2. Each gateway (i.e., Linux box) has three network Fast Ethernet interfaces, where each Ethernet link is a 100 Mbit/s crossover link:

• One is used to allow the agents (running on host3/host4) to access the ACS network (interface named fe3). This interface is configured to provide access to any on-board/network User Agent which is registered to provide or use a service (e.g., file storage, transmitting a video, etc.). Such an interface is controlled by a Dynamic Host Configuration Protocol (DHCP) server which assigns private IP addresses to the host3/host4 eth0 interface via a DHCP client running on such hosts. So, each pair eth0/fe3 represents an LAN between a gateway and the host where the agents run.
• Two Ethernet network interfaces (fe1 and fe2) are used to represent the bearers. From a topological perspective, a bearer is a physical device which can be identified by an IP address. For our emulations, static IP addresses were assigned to such interfaces.

Linux boxes named host3 and host4 are used to run the User Agents, which can be thought as server/client applications along with the logic to be registered and connected each other via virtual circuits created by SIP sessions. A User Agent can be registered either as service provider or as service client. Each service endpoint can be identified by a unique identifier, which is conveniently represented by an assigned IP address along with a symbolic name. The IP address is assigned dynamically once the registration of an agent is completed. An agent running on host3 can directly communicate with the gateway running on host1 (which simulates an OG). While an agent on host4 can directly communicate with the gateway running on host2 (which simulates the NG).

5.2. ACS Emulator Software

We designed and implemented the software that manages the gateways (whose architecture scheme is represented in Figure 9), which has been written to adopt the SIP protocol (a SIP proxy/dedicated server plays this role) and to manage the tunnels via a component named Tunnel Manager (TM). The ACS TM relies on Linux Tunnel Addressing Protocol (TUN/TAP) module [17] to create virtual network devices used to represent the endpoint interfaces of multi-path tunnels. Such software also relies on existing Linux third party software applications such as dnsmasq [18] for supporting DHCP and DNS protocols.

On each ACS gateway a Tunnel Manager executes, along with a SIP server (which have been integrated on the same application), a DNS server and a DHCP server (implemented by dnsmasq). The Tunnel Manager is responsible for handling the tunnel multi-path based on different transport protocols (such as UDP and TCP). Each tunnel is represented via a virtual network device driver created using the TUN/TAP Linux module. IP datagrams transmitted by a gateway through a tunnel interface are handled by the Tunnel Manager. This component receives IP datagrams sent or forwarded by the Linux Kernel to the tunnel interfaces (in outbound), envelopes them in transport protocol messages (or segments) with an additional header, and finally sends such application messages to each bearer interface of the tunnel, thus implementing a multi-path. Further optimizations can be included such as those implementing reinforcement learning [19].

The Tunnel Manager running on the receiving gateway receives the transport messages containing the inner IP datagrams from each bearer interface. It discards any duplicates and extracts and announces the original IP datagram to the Kernel through the local tunnel interface (handled by TUN/TAP module). The Kernel protocol stack layer, in turn, decides the final destination of the datagram. An example of such flow is represented in Figure 10. This implementation hides any bearer redundancy complexity, offering a simple outbound gateway from/to on-board/network side of ACS.

6. Results

This section reports the results of the testbed described in the previous section. Two main cases were considered: the transmission of the ERTMS signaling (i.e., PR/MA within the required time for guaranteeing the train operations) in Section 6.1 and the transmission of a critical data in Section 6.2.

Performance tests were executed creating several tunnel configurations combining 1 or 2 bearers and using either UDP or TCP as tunnel transport protocol or a mix of them but any case can be easily extended. Different types of tests were conducted to measure different aspects in all tunnel configuration scenarios, by using several tools. To measure bandwidth and data transfer performance, Iperf3 was used [20], which is a well-known networking tool capable of producing standard performance measurements for networks, creating data streams to measure the throughput between the two endpoints (i.e., User Agents) for producing as output a time-stamped report of the amount of data transferred and the throughput measured.

To measure round-trip time (RTT) and message loss rate we used the “ping” command, which operates by sending ICMP echo request packets to the target host and waiting for an ICMP echo reply. The program reports errors, packet loss, and a statistical summary of the results, including the minimum, maximum, the mean round-trip times (and standard deviation of the mean). Finally, a traffic generator tool (named udpTrEmu) was developed to simulate the Railway Signaling use-cases related to several traffic profiles typical of railway signaling, whose reference parameters were extrapolated from the requirements on GSM-R networks for ETCS support [21]. Impairments were added through Linux Traffic Control (tc) with Network Emulator (netem) commands directly on the bearer physical interfaces [15]. Netem allows us to add delay, packet loss, duplication and other characteristics to packets outgoing from a selected network interface. Netem is built using the existing QoS and Differentiated Services (diffserv) facilities in the Linux kernel.

6.1. Results on Rail Procedures

As described in the introduction, the signaling service is not a bandwidth-requiring service but it is very important for the train operation that the PR and its response MA are received within a given timeline. In Figure 11, the behavior of the considered PR/MA procedure within ETCS has been reported. As shown in Figure 11a, PR or MA can be lost twice before an MA is correctly received within $\xi$ seconds, thus not stopping the train movement or reducing its speed. On the contrary, in case of high packet loss, the procedure timeline is not respected since no MA is received within $\xi$ seconds (see Figure 11b). Additionally in Figure 11c, the procedure timeline is not respected due to packet loss and high channel delay.

Based on requirements in [21], we investigate whether a 128-byte packet of MA arrives with a delay higher than $\xi =1.5$ s. We suppose the train transmits a PR packet every ${\delta }_P=0.5$ s. We considered that one or two bearers are set up by the Tunnel Manager and for each of them we can select TCP or UDP as transport protocol strategy. Then, we can have five possible combinations: (i.) 1 TCP bearer; (ii.) 1 UDP bearer; (iii.) 2 TCP bearers; (iv.) 2 UDP bearers; (v.) 1 TCP bearer and 1 UDP bearer. We considered an outage in the PR/MA protocol when an over-limit event occurs. Then, we reported the outage probability defined as:

$$P_{out}=1-\mathrm{PR}\left\{\mathrm{at}\mathrm{least}\mathrm{one}\mathrm{MA}\mathrm{packet}\mathrm{is}\mathrm{received}\mathrm{within}\xi \mathrm{seconds}\right\}$$

(1)

Figure 12 reported the outage due to PR/MA over-limit as a function of the overall packet loss ratio in the network for a delay of 100 ms between the OG and the NG. All five transport protocol strategies were considered.

In order to stress the PR/MA rail application, high packet loss rates in the whole network were set. This considers all two-way end-to-end paths (i.e., from the on-board gateway to the network gateway in the remote control center and return for the authorization) including the wireless access network, which has the highest packet loss probability, the network operator network and the transport network to the rail operator center. In many cases (even when only one bearer is used), the train receives at least one MA within $\xi =1.5$ s. In fact, if one PR packet is lost the subsequent may arrive to the control center within $\xi$ s. As expected, in case one single bearer is selected, the over-limit rapidly increases. The worst performance occurs with UDP since $P_{out}=0.1\%$ is obtained for a packet loss of $5\%$. If TCP is adopted, performance increases since the Tunnel Manager is able to require a packet retransmission, and due to the overall delay of the whole path of 100 ms in the considered case, it arrives in time (i.e., within $\xi$ s). $P_{out}=0.04\%$ is obtained for a packet loss of $10\%$. As expected, the best performance occurs in case of 2 bearers using TCP.

Figure 13 reports the outage due to PR/MA over-limit when TCP is selected as transport protocol for one bearer (solid lines) and two bearers (dashed lines). Several overall network delays ranging from 0 ms to 400 ms were considered.

As expected, increasing the delay causes an increase in the over-limit percentage of the rail application due to the reduced possibility to retransmit a lost packet. In case of one single TCP bearer, the outage is $0.1\%$ for channel losses of $16\%$ and delay of about 50–100 ms, but it reduces to lower than ${10}^{-5}$ when two TCP bearers are used by the Tunnel Manager. In case of a low-delay channel, two TCP bearers can tolerate a packet loss of about $20\%$ (quite unrealistic in current networks but realistic only in very noisy wireless channels).

Figure 14 reports the outage due to PR/MA over-limit when UDP is selected as transport protocol for one bearer (solid lines) and two bearers (dashed lines). Several overall network delays ranging from 0 ms to 400 ms were considered.

As expected, UDP presents lower performance with respect to TCP due to lack of retransmissions. As an example, for UDP with one bearer the outage is lower than ${10}^{-4}$ when the channel delay is negligible and for packet loss equal to no more than $5\%$. In contrast to the TCP cases in Figure 13, UDP is more sensitive to using more than one bearer, showing a good improvement in the over-limit performance in cases where two UDP bearers are used. In fact, $P_{out}={10}^{-4}$ is obtained for channel delays of 100 ms and a packet loss of $10\%$.

Figure 15 reports the packet loss of the overall network as a function of the channel delay for several transport protocol strategies. Results in this figure are very useful to the Tunnel Manager in selecting the proper strategy based on the experienced packet losses as well as the measured delay in the network channels in order to respect the requirement $\xi$ of the rail application with a given outage over-limit $P_{out}<{\varphi }_0$. In Figure 15, an over-limit threshold ${\varphi }_0=0.1\%$ was selected. This means that for ${\varphi }_0=0.1\%$, we have a couple of $<packetloss,delay>$ values, according to the Figure 12, Figure 13 and Figure 14 for each transport protocol strategy.

For example, in case of a delay of 200 ms, the Tunnel Manager can select UDP and activate two bearers if they experience a packet loss of $7\%$ or can activate a second TCP bearer (thus having one TCP bearer and one UDP bearer) in case it experiences a packet loss of $15\%$. In case the wireless channel is particularly noisy (e.g., $20\%$), two TCP bearers should be considered in order to guarantee the over-limit outage of ${\varphi }_0=0.1\%$, even for a channel with 300 ms of delay.

6.2. Critical Data Transfer

For data transfer simulation, Iperf3 was used in the scenarios with a single bearer or two redundant bearers (either using TCP or UDP transport protocols for the tunnels). We tried several scenarios, including adding delay (from 0 to 400 ms) with/without additional packet loss.

Figure 16 reports the impact of induced packet loss on the bearers on the tunnel interfaces. Multi-path tunnels are consistently more resilient than single-path-based ones. In this configuration, a $5\%$ packet loss rate was well-tolerated. As expected, the drop in performance (in terms of throughput) is less pronounced for multi-path tunnels. The TCP protocol proved to be more effective than UDP as the packet loss rate increases.

Figure 17 reported the throughput as a function of latency in this case for one and two bearers and for TCP and UDP as transport protocols between OG and NG. The throughput progressively decreases as latency increases. In the presence of packet loss, this occurs in a more accentuated way (already for a packet loss equal to $1\%$ the degradation is tangible). However, even in this case, the presence of two bearers produced a clear improvement (especially when using TCP as tunnel protocol).

7. Conclusions

In order to counteract the GSM-R disposal in the coming years as a communication technology adopted by rail operators in traffic train management, the European Shift2Rail Joint Undertaking (S2R-JU) proposed the adoption of the Adaptable Communication System (ACS) based on the Over-The-Top (OTT) approach, which implements bearer independence and supports connections over multiple networks. In this work, a testbed was implemented aiming at emulating the ACS behavior in order to evaluate ACS performance. In particular, we considered the duplication of messages in managing critical rail applications for train traffic management and investigated the best solutions in terms of transport protocol solutions for implementing tunnels through the on-board gateway and the network gateway. Two main rail applications were analyzed: the position report/movement authority for ETCS/ERTMS signaling and the critical data transfer (i.e., file transmission), considering both UDP- and TCP-based tunnel transport protocols.

Results showed that for the first rail application, one UDP bearer can be selected only if the end-to-end channel delay is lower than 100 ms and the experienced packet loss is lower than $4\%$ in the whole crossed networks. Two UDP bearers or one TCP bearer or two mixed UDP/TCP bearers should be selected in case the end-to-end channel delay is greater than 300 ms and the experienced overall packet loss is greater than $15\%$. Considering the critical file transfer in the rail scenario, TCP should be selected with two bearers to have a throughput greater than 50 Mbit/s, even for a packet loss of $1\%$.