# Communication Transport Protocol Strategies for Rail Applications
## 6 Results
### 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). Figure 10: Tunnel Manager packet processing. 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-\text{PR}\{\text{at least one MA packet is received within $\xi$ seconds}\} \tag{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 11: PR/MA Procedure with a PR transmission period \(\delta_{P}\), a channel latency \(\delta\) and a MA receiving threshold \(\xi\): (**a**) successful case; (**b**) unsuccessful case due to high packet loss; (**c**) unsuccessful case due to high packet loss and high channel delay. 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).