# Communication Transport Protocol Strategies for Rail Applications
## 2 The Railway Context
### 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 \begin{table}
\begin{tabular}{c c c} \hline \hline
**Service Category** & **Service Examples** & **Required Bit Rate** \\ \hline Signaling & & \(<\)1 kbit/s \\  & \(\bullet\) & ERTMS (e.g., PR and MA); & \\  & \(\bullet\) & Request for rescue cases; & \\ Critical video & & & 0.1–2 Mbit/s per camera \\  & \(\bullet\) & Video inside the cabin; & \\  & \(\bullet\) & Video outside the cabin & \\ Critical voice & & & 30–48 kbit/s (Single call) \\  & \(\bullet\) & Call from/to vehicle staff; & \\  & \(\bullet\) & Audio from passengers in danger; & \\ Critical data & & & \\  & \(\bullet\) & Vehicle integrity; & 1–5 kbit/s; \\  & \(\bullet\) & Images inside/outside the vehicle & 100 kbit/s \\ Non-critical data & & & 100–500 kbit/s in uplink, \\  & \(\bullet\) & Tele maintenance; & \(<\)100 kbit/s in downlink \\  & \(\bullet\) & Public announcement; & \\  & \(\bullet\) & Passenger Information System & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Services and requirements for the rail case [11]. 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.