# End-to-End Delay Model for Train Messaging over Public Land Mobile Networks
## 2 Scenario and Test Trials  
Experimental activities have been developed in the framework of the ESA ARTES 20 3 InSat Project [18], which foresees realization of a railway testbed for testing satellite navigation and communication technologies for rail applications under real operational conditions. Trials have been focused on the standard train signalling services. Data have been recorded over the railway line connecting the towns of Cagliari and Olbia in the Sardinia Island (Italy). The considered railway line is about 300 km long and the maximum allowed train speed is 150 km/h, actually limited to 130 km/h (which is the maximum speed of the Minuetto Diesel traction trains used on the line). Tests and demonstrations have been performed reaching the maximum speed. During the four weeks of the test campaign, two trips per day, each lasting 3:50 h each way, have been performed. The cellular, GPS (Global Positioning System) and satellite antennas have been placed on the roof top of the train with an unobstructed view to the sky. For the test, we have used the machine-to-machine (M2M) service provided by the Vodafone (Italy) 2G/3G public mobile access network. The selected operator provides roaming to other mobile networks in case of a lack of Vodafone coverage. The satellite link has been provided by the Inmarsat Satellite (Broadband Global Area Network (BGAN) configuration). The on-board equipment includes the EVC and a Location Determination System (LDS) on board unit (OBU). Both EVC and LDS functionalities have been emulated by software running on a portable PC. The RBC emulator has been hosted by a server cluster located at TriaGnoSys lab facilities (Munich, Germany) [19]. The schematic diagram of the considered onboard measurement system is depicted in Figure 1. The additional Real-Time Kinematic (RTK) GPS receiver in Figure 1 has been used for improving localization with the augmentation network. For our purposes, only the radio sub-system is of interest. For the trial setup, the delay components contributing to the EVC-to-RBC E2E delay have been made evident in the scheme in Figure 2.  
Figure 1: Test trial: (a) schematic diagram of the onboard architecture of the measurement system; (b) GPS and radio antennas on the train roof. Figure 2: Delay components contributing to the overall end-to-end (E2E) delay between the transmitted and received messages—EVC to RBC link. In the scheme in Figure 2, we have implicitly assumed that the MNO network may include Internet segment(s). We have no information if messages in the Vodafone network have been routed over the Internet and/or on any other operator's private network. In general, it may be expected the public MNO could send its protected/high priority traffic over dedicated networks, which may rest on the incumbents' networks of the traversed countries. From the analysis of the recorded data we have observed that Vodafone's network behaves well most of the time. The minimum recorded values for the E2E delays vary between 40 ms up to 60 ms. In general, the E2E delay accounts for: the (possible) message enqueue in the transmitter before transmission and the serialization time (\(T_{Q\_TX}+T_{Ser}\)), the time for message propagation in the network (\(T_{N\_NR\_prop}\)) and the time \(T_{Server}\) required for the message at the network output to reach the corresponding application at the RBC. A scheme similar to that in Figure 2 can be devised for the RBC-to-EVC link. Since we are interested in E2E delay and message loss experienced by railway applications running in the RBC and EVC, channel modelling has been restricted to the characterization of the E2E delay formally defined as the difference between \(T_{RX}\) and \(T_{TX}\):  
\[E2E=T_{RX}-T_{TX}, \tag{1}\]  
where \(T_{TX}\) is the message transmission time and \(T_{RX}\) is the (corresponding) receive time of the message. During trials, each message has been uniquely identified by its progressive sequence number (message identifier, ID). The transmit timestamp is attached to the message at the application level.