Evolving railway communications for 5G and FRMCS

Railways are going digital, and advanced communications systems will be essential. The future of mobile railway communications as set forth in the Future Railway Mobile Communication System (FRMCS) standard accommodates different wireless technologies including 5G and even satellite communications. But, the industry is settling on 5G as the best choice to ensure interoperability between different national systems. To support the most advanced features of 5G, such as slicing, the transport network – the fixed part of the infrastructure connecting the radio access network to the core – will need to evolve.

Most railway operators will look to their existing backbone communications network, which they currently use for a wide variety of safety, operational and passenger services. Typically, these are multiservice networks based on IP/MPLS and use optical fibre and microwave for transport over longer distances. While these current backbone networks have many strengths, to support FRMCS/5G, they will need to be upgraded to support end-to-end slice orchestration, slice control and assurance, time synchronisation and cloud internetworking.

Dynamic transport slices

The railway services that 5G will need to support range from automated train operations (ATO) and Interlock to CCTV, and IoT sensors. These have very different quality of service (QoS) requirements. 5G can allocate network resources dynamically depending on the mix of services it needs to support. Where ATO, for example, has stringent latency parameters for train control, CCTV is delay tolerant but requires significant bandwidth. 5G can tailor its resources specifically to meet the needs of each service.

One of the ways that 5G can ensure that the service requirements are met consistently is to use network slicing. Slicing is a way to set up something much like individual virtual private networks or VPNs, essentially assigning specific network resources to ensure that service performance levels are met for the duration of their use.

Figure 1: 5G virtually slices the network and determines the performance parameters required for each slice to meet the service or application needs.

This is hard to implement in most backbone networks because the different domains such as IP and optical don’t normally talk to each other. Imagine that an automated train operation is initiated. The 5G radio network allocates ultra-low-latency services to the application. The 5G core network also supports it. However, it turns out that the underlying optical link is congested or fails. It thus becomes impossible to provide the low-latency service to ATO.

Transport slice control and assurance

For slicing to work end-to-end, it must be implemented in the radio, core and underlying IP and optical/microwave transport network domains. And because 5G is a cloud-native technology that runs in both central and edge data centres, the slice must be supported in the data centre networks as well.

This requires a slice orchestrator that can talk to and control network elements in the three discrete domains mentioned above that historically haven’t been connected. The slice orchestrator must work with a controller in each domain to deploy, monitor and assure the end-to-end slice performance is met. Additionally, managing the multi-layer IP/optical backbone network using disjointed network managers for each layer and ad hoc tools is a daunting challenge since information about each layer is stored in its own management silo with no coordination.

The critical upgrade to the railway operator’s backbone network to make 5G slicing possible is the backbone network manager. It is tasked with supporting the end-to-end slice in tandem with the end-to-end slice orchestrator. The backbone network manager takes up the role of transport slice controller and performs cross-layer management for the IP, optical and microwave layers. Equipped with a northbound API, the backbone becomes fully programmable to respond to changes. For example, using the northbound API, the backbone can connect with the end-to-end 5G slice orchestrator, and is able to receive the service request from the slice orchestrator, reserve resources to set up the path across the various backbone domains and then proactively measure, using telemetry, that the slice is performing as required by the new service.

Figure 2: Closed loop service assurance automates slice optimisation using telemetry.

If the telemetry indicates, in the case of ATO for example, that the required latency performance is not being met, it then instructs the transport slice controller to re-optimise the path to ensure that the delay is eliminated. In a traditional railway operator’s backbone, this wouldn’t normally be easy or instantaneous because operators have only an isolated view of the IP/MPLS and optical/microwave topologies. Thus, it takes a lot of manual effort to identify and visualise the end-to-end path between two peering routers that traverse the optical layer.

Again, the cross-layer backbone manager solves this issue. It is able to construct a multi-layer topology (using LLDP snooping and traffic counts) and use this to analyse different paths, identifying which ones share the same underlying (failing) transport links, and which use different links. Network automation is used to analyse these different links and switch the slice onto a different (available) path.

Time synchronisation

With FRMCS/5G, time synchronisation is needed. Synchronisation is not new to rail communications. GSM-R base stations along the track have always needed a frequency reference to drive RF carriers. Traditionally, frequency synchronisation is distributed using line timing over synchronous physical links such as T1/E1, DS3 and OC-3/STM-1. With an IP/MPLS-based backbone network, synchronous Ethernet has become the prevalent means to distribute frequency synchronisation.

However, line timing cannot evolve to support time synchronisation. Rail operators need to implement IEEE1588v2 in their backbones, a standard originally designed for critical industrial automation. Thus, backbone routers need to support advanced 1588v2 capabilities such as grand master clock (GMC) and boundary clock (BC) to distribute accurate timing information required by the 5G radio base stations. In addition, as 5G base stations (gNB in 5G terminology) are deployed along the tracks, track switches would also need to support BC capabilities.

Figure 3: Cloud interworking with cloud-native 5G core.

Internetworking with the cloud

As mentioned above, one of the additional network domains that are critical to internetwork is the data centre network (or the fabric in IT terminology). This is achieved using a data centre gateway, which allows IP/MPLS to internetwork with the data centre fabric. It uses Ethernet virtual private network (EVPN) to interwork at the Ethernet layer, IP layer and BGP layer, enabling network agility to support dynamic cloud computing. IP/MPLS also provides a graceful evolution path to segment routing, ready for total adoption of a dynamic, elastic cloud-based digital rail environment in the future.

The digital railway future

Railway operators are embracing a digital train-to-ground future. Using FRMCS/5G, they will be able to wirelessly connect railway personnel, rolling stock, machines, applications and services throughout their operations. A critical piece of this 5G story is updating their existing converged IP/MPLS backbone networks with new capabilities including network automation, multi-layer management, time synchronisation distribution and cloud internetworking. This evolution will enable their existing network to thrive in the digital future, including meeting the new requirements for FRMCS/5G.

Hansen Chan is an IP Product Marketing Manager at Nokia, and has a special focus on digital industries and public sector. He has worked with critical infrastructure network operators and telecom service providers worldwide for more than 25 years.