# Towards Intelligent, Programmable, and Open Railway Networks
## 4 Intelligent Railway Network Architecture
The R1 application protocol is based on the REST (REpresentational State Transfer) solution and uses hypertext transfer protocol (HTTP) procedures and JavaScript object notation (JSON) objects. The R1 policies are not critical to train control and trackside control, have temporary validity, and may be dedicated for an individual onboard train control system, Euroloop, interlockings, or dynamically defined groups of ETCS entities. The R2 interface between the RMAO and the REC provides platform resources and workload management. It enables the deployment and life-cycle management of virtualized functions that run on the REC. The R3 interface is between the RMAO and the railway network functions for management support. It is used for functions by which software management, file management, configuration management, and fault management may be achieved. The IR interfaces connect the onboard train control units, Euroloops, interlockings, and control center to the TSICU. The procedures executed over the IR interface are related to the exchange of information between ETCS entities or to notifications about internal events or events triggered by external entities and the required reaction. These procedures define the required status and mode changes of the ETCS entities (train driver, the trackside equipment, the onboard equipment) on a contextual level. Examples of procedures include mission starting and mission ending, shunting, and overriding, e.g., in case of a failed signal, train joining or splitting, train orientation changing, and indicating of track conditions. The full list of procedures and their detailed descriptions may be found in [31]. The proposed intelligent railway network architecture supports at least three control loops involving different RBC functions:  
* Non-real-time control loops running at the TTICU level;
* Near-real-time control loops running at the TSICU level;
* Real-time control loops running at the level of the onboard train control system and trackside equipment. The control loops are executed simultaneously at different levels and may or may not interact with each other depending on the use case. The typical execution time for use cases involving non-real-time control loops is 1 or more seconds; the near-real-time control loops are on the order of 10 milliseconds or more; control loops in the ETCS entities can operate below 10 milliseconds. The timing of the control loops is dependent on the use case. The following use case illustrates the role of the logical entities in the proposed intelligent railway architecture. The use case describes the motivation and solution for temporary train speed control based on inspection of railway tracks and preventive maintenance. One of the top causes of train derailing is track-related issues. ML-based trackside equipment maintenance can predict fault occurrence before assets fail and can issue train speed commands in the affected area to avoid taking a critical train out of service and disrupting the system. Numerous datasets covering different domains of the railway sector and that have been used to provide ML-based solutions are reviewed in [32]. One of the ML-based solutions described gathers information about the mechanical behavior, the railway track state, and reasons for possible problems. A sensor system using optical fibers monitors tracks and collects information about track performance. The railway track performance may vary significantly along the track length, and knowledge about it helps in track maintenance; in some cases, it may be critical for train speed along the track. The goal of the use case is to determine the temporary train speed along a track section based on knowledge about track performance. The entities involved are as follows. The TTICU is responsible for training, deployment, and updating of ML models related to track performance in the TSICU, and for rail policy generation and provisioning.