Keywords

1 Introduction

In many railways, including high-speed lines, in Europe and all over the world, train-to-ground communication is based on the Global System for Mobile Communications for Railways (GSM-R) technology, which was established between 1995 and 2000 as part of the European Rail Traffic Management System (ERTMS) standard. After more than twenty years of successful deployment, the GSM-R technology is showing some limitations and weaknesses. Hence, several initiatives have been launched over the past decade to prepare the ground for defining a new standard communication technology for ERTMS.

At the European level, the European Union Agency for Railways (ERA) has defined a roadmap for the definition and implementation of a new telecommunication standard for railways [20]. Another actor involved in this transition is the Future Railway Mobile Communications System (FRMCS) group, established by the International Union of Railways (UIC), and the Next Generation Radio for Rail (NG2R) working group of the European Telecommunications Standards Institute (ETSI). In 2020, UIC released the “FRMCS On-Board Architecture Functional Requirements Specification (FRS)”. The currently ongoing European project 5GRAILFootnote 1 aims at verifying the first set of FRMCS specifications and standards by developing and testing prototypes of the FRMCS ecosystem.

Today, it is widely agreed that the GSM-R successor will provide all-IP connectivity to end devices, including on-board units, and will be convergent, i.e., able to carry traffic generated by different applications [2]. Besides guaranteeing adequate Quality of Service (QoS) to train control traffic, which is crucial for safe and comfortable operation [19], a significant challenge for such a convergent infrastructure is represented by the ability to provide mobile broadband access to travellers [18]. Initially, most stakeholders believed that next generation communication systems for railways would be based on LTE-R, which is derived from fourth generation cellular standard Long Term Evolution (LTE), and its advanced version LTE-A [12]. With the advent of the fifth generation cellular architecture (i.e., 5G) for public telecommunication infrastructures, the adoption of 5G as the basis for future generation railways has been considered [9], in particular, to address the communications demands of travellers and security applications (e.g., video-surveillance) [21].

In the past few years, public 5G networks have been commercially deployed in several countries. The majority of them conform to the Non-Stand-Alone (NSA) 3GPP specifications, which basically allow the adoption of 5G New Radio (NR) base stations as extensions of the 4G EPC core network. This is an interim solution that is gradually overcome by new deployments conforming to the Standalone Architecture (SA). Only these new deployments will be able to fully benefit from the potential of 5G Core, whose design is based on new emerging networking paradigms, such as “softwarization” and virtualization of network functions. In particular, 5G Standalone deployments will be able to support ultra-reliable and low-latency communications (URLLC), a special type of communication that suits the stringent requirements of mission-critical applications. In the literature, it is widely agreed that a key enabler for URLLC services is control-plane programmability, which can be achieved through the adoption of Software Defined Networking (SDN) [1, 7, 15, 22]. SDN allows a centralized control of network devices by physically separating control and data plane. In traditional networking, the control plane functionality is embedded in the device itself. With SDN, the control plane is located outside of network devices and is performed by a logically centralized SDN controller, i.e., a software running on a commodity server.

In general-purpose networking environments, the control plane logic implements generic communication “intents”, typically expressed in terms of Quality-of-Service requirements and/or security policies. In our work, we move from the assumption that the control plane logic governing a railway communication infrastructure may be finely tuned to take into account the specific requirements and characteristics of the system. For instance, the train trajectories and timings may be considered as partially known in advance and this knowledge may be properly taken into account for resource management during handovers. This is, in essence, what we refer to as the “domain-aware control plane”. In particular, in this paper we illustrate a methodological framework that is able to automatically generate the control plane logic of software defined railway communication networks. The framework integrates formal modelling, analysis tools and techniques into a programmable control plane specifically tailored to railway communication infrastructures. We introduce the concept of domain-awareness in the network control plane as an SDN-enabled feature that allows to achieve application-specific advantages besides those purely expressed in terms of network KPIs (Key Performance Indicators) such as QoS. To that aim, we propose a reference architecture in which domain-awareness in the control plane is obtained by taking into account information not only gathered by network devices but also coming from ad-hoc communication gateways that are able to detect relevant signalling events. In the proposed architecture, the actual behaviour of the SDN controller is governed by applications that are able to react to specific triggers of the communication and re-configure network devices accordingly. The flexibility and customizability of the network control plane is particularly suited to accommodate the communication requirements arising from new railway paradigms, such as moving block. Such an evaluation of the SDN potential in the railway context is in line with the growing interest of academy and industry in developing innovative solutions for future railway communications [17].

The remainder of this paper is organized as follows. Section 2 introduces ERTMS and its main constituents. Section 3 presents the reference SDN architecture integrated in ERTMS. Section 4 describes the approach for the automatic synthesis of control plan logic using model-checking approaches. Section 5 describes how the SDN control logic can be supported by formal models. Section 6 addresses current implementation of the prototype aimed at providing a proof-of-concept of the approach. Finally, Sect. 7 summarizes conclusions and future directions.

2 The European Rail Traffic Management System

The European Rail Traffic Management System (ERTMS) is the first international standard for train command-control and train-to-ground communication. Initially defined and deployed in Europe to guarantee the interoperability of the European railway signalling systems, ERTMS has also been applied in many other countries all over the world. The ERTMS specifications include ETCS, i.e., the European Train Control System. ETCS provides two main features: in-cab signalling, i.e., information and commands for the train driver displayed in the cabin by a Driver Machine Interface (DMI), and Automatic Train Protection (ATP), i.e., the ability to activate warning signals and brakes to slow-down stop the train in case its speed exceeds the allowed speed profile. The ETCS reference architecture includes several subsystems: On-Board Unit (OBU); line-side, which is responsible for providing geographical position to the on-board subsystem; track-side, which is in charge of monitoring and controlling the movement of trains. The most important component of the track-side system is the Radio Block Centre (RBC). RBC is a computing system, whose aim is to ensure a safe inter-train distance on the track area under its supervision.

The ETCS control action is performed by an interaction between the RBC and the Euro Vital Computer (EVC), which is part of the OBU system. Such an interaction happens through a Communication Session established by means of the EURORADIO protocol and the GSM-R network. Figure 1 shows the interaction between RBC and EVC. RBC is also in charge of sending emergency stop messages and channel vitality messages that are needed by the EVC to react to situations when the communication channel is temporarily compromised due to unavailability, interferences, or other issues causing interruption or corruption in message stream. The RBC manages train movement using Movement Authorities (MAs). A train MA is a included in a specific message sent by RBC to EVC containing a data vector defining the maximum distance and allowed speed profiles associated to the track section ahead of the train. An MA includes the End of Authority (EoA), i.e. the stop location that the train is not authorized to pass until a new MA is issued. RBC issues MAs by combining: a) static information about the railway track layout and track elements, and b) dynamic information on train positions and track occupancy obtained from the trains and the interlocking system, respectively. A single RBC is in charge of continuously and concurrently controlling a number of connections with trains, depending on the characteristics of the GSM-R network. In large railways, traffic control is assigned to different cooperating RBCs. Each RBC is associated to an RBC track area. Hence, it may happen that, during a train’s journey, its control is switched from one RBC to another; such a procedure is known as “RBC handover”.

Fig. 1.
figure 1

Main ETCS components and their interconnections.

Full size image

3 Software-Defined Communication Networks for Railways

A generic SDN architecture for future railways is depicted in Fig. 2, where we identify a Radio Access Network (RAN) and an SDN-enabled Core and Aggregation Network. Several recent works have proposed the use of the SDN paradigm in cellular networks, both in the core and in the radio-access parts of the infrastructure. A programmable control plane allows, in fact, a more flexible management of traffic flows and a more efficient handling of user mobility in these networks. The adoption of SDN in the mobile backhaul part of the railway communications infrastructure has been already proposed in the literature [11]. We consider the adoption of a programmable control plane in a railway network infrastructure as a valuable architectural innovation that opens-up new opportunities. We will briefly discuss such potential advantages in the following.

Differentiated End-to-End QoS for Vital and Non-vital Flows. By monitoring network conditions and by taking into account current ETCS signalling requirements in a given RBC area, a programmable SDN controller may provide differentiated QoS to the various network traffic flows (e.g., ETCS signalling, video-surveillance, passenger information, infotainment, etc.).

Flexible Resource Management. Network resources may be dynamically allocated to applications depending on the current network status. For instance, infotainment flows may be allocated a reduced bandwidth in congested areas. Furthermore, SDN may also be used to partition network resources among different tenants (i.e., network slicing).

Reactive Control Policies. Softwarization may be used to implement effective topology- and application-aware reconfiguration strategies after network failures (e.g., loss of nodes) and/or anomalous application-level events (e.g., loss of MA). In case a failure is detected, network may be progressively reconfigured to guarantee a fast recovery for vital services.

Proactive Control Policies. Softwarization may also be used to pre-configure network devices for efficiently managing large number of correlated traffic flows. For instance, when the railway communication network infrastructure is also used to provide Internet connectivity to passengers, a proactive management of handovers may lead to significative improvements of mobility management.

Advanced Network Services. A centralized control plane also enables new services, both for end-users (e.g., infotainment content caching) and the railway operator (e.g., traffic logs).

Fig. 2.
figure 2

SDN-enabled wireless backhaul for railways.

Full size image

Figure 3 proposes a reference architecture for domain-aware SDN control applied to railways. Both the SDN Controller and the railway subsystems, i.e., on-board and track-side, are connected to the network by means of wired links, which are represented in the figure by continuous lines. Red lines represent communication flows established between the railway signalling endpoints, i.e., RBC and EVC. In this paper, we assume a one-to-one association between RBC and SDN controllers.

Fig. 3.
figure 3

Reference architecture for domain-aware SDN control in railways.

Full size image

The control plane logic is governed by a customized application that interacts with the SDN controller through its northbound API. Such application can be modeled as a state machine that reacts to different events by instructing the SDN controller so that it can change the configuration of network switches; this is represented by dashed lines in Fig. 3. Some examples of relevant events are: (a) the occurrence of a specific network traffic condition (e.g., a link utilization exceeds a given threshold), (b) the detection of an emergency message sent by the RBC, or (c) a hardware failure in a network switch. To capture such events, a set of probes need to be set by the SDN controller. Some of these events could be obtained either directly from the SDN network switches, or by deploying specialized application-aware monitoring devices. This latter solution could leverage a Communication Gateway in charge of receiving unencrypted vital commands from the RBC, of extracting from them the relevant events, according to predefined probing rules, and of sending them to the SDN Controller; this is represented by the white arrow in Fig. 3.

4 Automatic Synthesis of Control Plane Logic

In order to perform an automatic synthesis of control plane logic in railway applications, it is necessary to investigate how to implement a network controller of a convergent SDN-based communication infrastructure that is able to automatically configure network devices by considering specific communication requirements of different traffic flows. Since signalling is essential for the proper operation of the entire railway, network control logic must be able to react to specific signalling events. To that aim, we propose a model-driven methodological framework based on three layers that leverages formal methods to automate network configuration. A global view of the framework is presented in Fig. 4.

Fig. 4.
figure 4

Methodological framework to automate network configuration.

Full size image

In the specification layer, railway and network specialists provide the following inputs: (i) a model of network topology; (ii) a finite-state-machine representing the signalling protocol from which the relevant states of the signalling system and a related set of events can be deduced, and (iii) technological and application constraints. These information are used to generate sets of configuration rules and a state-machine modeling the behaviour of the SDN control plane. The configuration layer combines the state machine and the configuration rules to generate an application instructing the SDN controller through a controller-specific northbound API. The network layer is the physical communication network, whose control plane consists of the SDN controller and of the domain-aware application. A single set of configuration rules defines a bidirectional flow path on the network connecting two specific end points, namely RBC and EVC. To establish a given network path between the two end-points, proper configuration rules need to be injected into each of the switches located along the path. In the following, we will refer to the switch connected to RBC as the root node, and the base station that provides wireless connectivity to the EVC located in the moving train as edge node. The problem of generating the flow paths between RBC and EVC is a constrained routing problem, where not only the network graph topology is considered, but also a number or variables and constraints must be taken into account in order to meet the requirements of a convergent communication infrastructure. To that aim, events must be identified that require a re-configuration of the network. We consider three classes of events that could trigger the activation of a new configuration:

  1. 1.

    Base station handover (i.e., the train moves from a base station to the next along the track);

  2. 2.

    Network and hardware failures;

  3. 3.

    Application-level relevant events (e.g., an emergency event).

We use model checking to automatically generate the configuration rules [6] and Dynamic State Machines (DSTM) [3] to model the network controller. DSTM is a recent extension of hierarchical state machines whose main advantage with respect to other state-based formalisms is that a DSTM machine can be parametric and dynamically instantiated. In this application, a DSTM machine models how the network must be configured to support the communication between RBC and a single train: a state models a specific network configuration at a specific time, while a transition models the occurrence of a network re-configuration, triggered by the events considered above (e.g., train movement, network device failures, application-level alarms, emergency conditions, etc.). Each instance of the DSTM model corresponds to a specific train under the supervision of the RBC. The configuration layer translates the DSTM model into executable code, which is then executed in the network layer. How this application is coupled to the SDN controller depends on the adopted SDN technology. The problem of making the controller able to detect and react to the expected events included into the network controller model may be only partially solved by current SDN implementations. How to expose the application-level semantics to the network controller is an open research challenge.

Fig. 5.
figure 5

SDN control plane logic using DSTM formal models.

Full size image

5 SDN Control Logic Supported by Formal Models

A basic control logic for exemplary purposes is depicted in Fig. 5. We consider a railway communication network consisting of 6 base stations covering the whole track, 3 switches and 16 links. We suppose that the network carries different communication flows: the so-called “vital” flow generated by signalling, and non-vital flows generated by the on-board infotainment services. The root node of both communication flows is the switch named s0. The DSTM model on top of Fig. 5 represents the network controller and specifies the control logic. The model consists of two machines: Main and Train Manager. The Main machine is in charge of detecting the connection requests from trains entering the RBC area. When a new train enters the area, a new instance of the Train Manager machine is created and executed by entering the “box” element of the language, i.e., the rectangle in the Main machine model. The Train Manager machine, on the top-right of Fig. 5, is a specific instance of the “box” element and models the control logic in terms of management of the communication flows for the specific train. Each state of such machine is associated to the configuration rules establishing the bidirectional communication paths for both vital and non-vital flows, in specific conditions. The states from RBC-BS0 to RBC-BS5 represent nominal communication conditions, in particular each state RBC-BSi models the specific network configuration allowing the considered flows between the root and the edge node BSi, when the train is on the track portion covered by the base station BSi. For each state RBC-BSi the controller model envisages the occurrence of possible events, such as device failures, which require the activation of a different network configuration. Figure 5 shows the part of the DSTM model related to the handling of a link failure event occurred when the train is connected to BS0. Furthermore, the detection of an emergency event at ETCS application protocol level leads to a different configuration supporting vital communication flows (i.e., signalling), while offering degraded service to non-vital flows.

6 Current Implementation

We used GraphML [5] to describe the network topology and device features, and Spin [13] as model checker to generate network configurations. The SDN-enabled railway network has been implemented by emulation. In the current prototype, the SDN control plane relies on OpenFlow [16]. The emulated network devices and end-system (RBC and EVC) are instantiated by means of the Mininet-Wifi emulator [10]. The SDN controller is Floodlight, a Java-based modular OpenFlow controller. Floodlight is used to proactively configure switches by receiving flow specifications from external entities, through a REST API. By executing a Python script, Mininet-WiFi instantiates the emulated nodes and runs real network programs in the emulated hosts. By using Mininet-WiFi, it is possible to reproduce node mobility and evaluate the impact on applications of variable network conditions (e.g. due to handovers) over time. Emulated end-systems are virtually connected to access point devices through emulated wireless links. Currently, Mininet-WiFi is only able to emulate IEEE 802.11-based wireless networks and not cellular networks; that was not an issue, since our interest was in the evaluation of the capability of the fixed part of the network to reconfigure its forwarding rules to follow train movements.

7 Conclusions and Future Directions

In the context of next generation communication networks applied to intelligent transportation systems, we discuss in this paper the advantages in applying the SDN paradigm to future railways. In fact, next generation smart-railways will be increasingly based on novel communication and networking paradigms, including the Internet of Things [14] requiring high performance and bandwidth due to the need for manipulating large amounts of data to support machine learning applications [4], high reliability and low latency to enable emerging signalling paradigms such as moving block and virtual coupling [8], as well as flexibility, dynamic context-awareness, adaptation, scalability, and support for advanced multimedia services.

In this paper, we introduced the concept of domain-awareness in the control plane of new generation communication networks used in railway applications, in order to achieve specific advantages besides those typically guaranteed by a plain SDN management (such as flexibility, fault-tolerance, and QoS). To that aim, we provided a reference architecture in which domain-awareness in the control plane is obtained by taking into account information gathered by network devices and by ad-hoc communication gateways that are able to detect relevant signalling events. In the proposed architecture, the actual behaviour of the SDN controller is governed by domain-aware applications to react to specific triggers and re-configure network devices accordingly. We also defined a methodological framework based on model-driven principles and formal methods aimed at automatically generating SDN control plan logic.

Future efforts will be aimed at refining the prototype to design experiments aimed at matching railway-specific requirements with the new communication and networking paradigms enabled by SDN technologies and their softwarization potential. Furthermore, with the stabilization of 3GPP standards for 5G networks, we also aim at improving the integration of our approach in 5G architectures, where separation of mission-critical control traffic and passengers’ traffic can be achieved by exploiting the network slicing functionality envisioned by most recent releases of 5G standards and where the Core Network is organized around a collection of properly orchestrated Network Functions.