By Alain Sultan, 3GPP MCC

The benefits of standardizing railway telecommunications are clear: it improves interoperability, safety, reliability, and efficiency, and it reduces the risk of communication failures. It also makes it easier for railways to work together, which is particularly important for international rail traffic.

The Railways community has trusted 3GPP to provide standards for Railways telecommunications, which has answered the demand by creating and maintaining specific standard(s).

This relationship between railways and (then European-only) telecommunications standardisation body actually started even before the creation of 3GPP: the first railways-specific telecommunication standard, GSM-R (Global System for Mobile Communications-Railway), is a "spin-of" of GSM, which was developed by ETSI SMG and was later inherited by 3GPP.

As the maintenance place for the GSM standard, 3GPP was also the place where GSM-R was continued.

For market-timeline aspects, there was no railways-specific version of the 3GPP's 3G system (UMTS). But then the links between 3GPP and the Railways community became tighter with 4G system (LTE) and even more with 5G, as presented below.

The Railways Community: UIC and ETSI TC RT

Union Internationale des Chemins de fer (UIC)

The Railways companies (train companies, train equipment manufacturers, regulators, etc.) is well structured, with in particular the "internal union for railways", based in France and known under its French name: "Union Internationale des Chemins de fer (UIC)", welcoming members from all around the world.

Figure 1: countries of origin of UIC Members (source:  https://uic.org/about/about-uic/)

Among a multitude of topics, UIC has handled the transition from a variety of (mostly analogue) communication systems to an international, digital, system, that they choose to be GSM-based: GSM-R, presented below.

ETSI Technical Committee "Railway Telecommunications" (ETSI TC RT)

Once they adopted GSM-R, several UIC members got involved in the creation of a GSM-R dedicated ETSI Technical Committee, called "RT" for Railways Telecommunications. This group is still active, and presented in https://www.etsi.org/committee/rt

ETSI TC RT is a group of specialists with both railway and industry members. It is continuing and developing the work of ETSI related to the maintenance and the development of the GSM-R standard, initially with ETSI SMG (defining GSM and GSM-R), then with 3GPP.

TC RT's main task is to maintain the specifications for the use of GSM to meet the requirements of the railways, and to update and develop the existing ETSI standards in response to relevant European Directives.

TC RT is also working, in collaboration with the railway industry, on permanently improving the GSM-R system with respect to e.g. roaming for international trains and to offer solutions to all the new requirements from users in Europe and world-wide.

To maintain the GSM-R standard, TC RT submits Change Requests to 3GPP for updating the "plain" GSM standard accordingly, but also handles three dedicated ETSI specifications, namely:

• EN 301 515: Requirements for GSM operation on railways
• TS 102 610: Usage of the User-to-User Information Element
• TS 102 281: Detailed requirements for GSM operation on Railways

Note that RT's outputs are brought to 3GPP through the companies involved in both committees (and not directly under the name of RT, which is not a legal entity). On the other hand, from Release 17, UIC delegates are directly involved in 3GPP.

Source: ETSI RT Leaflet, https://www.etsi.org/committee/rt

Before 3GPP: GSM-R

The GSM-R context: EIRENE and MORANE

The creation of a pan-European system for railway telecommunications was initiated in the 1990s by the Union Internationale des Chemins de Fer (UIC) under the project EIRENE (European Integrated Radio Enhanced Network) and the European Union with the project MORANE (MObile radio for RAilway Networks in Europe).

As a result of these projects and ETSI specification work, GSM-R was selected as the interoperable radio system for Railways and was mandated by a European Decision in 1997. Thirty-two UIC members signed a Memorandum of Understanding (MoU) committing the signatories to use GSM for Railways (GSM-R) for their radio applications. GSM-R implementation began in Europe in 20001.

Since then, GSM-R has continued its expansion not only towards Eastern Europe but also worldwide, including countries such as China, India, Algeria, Turkey and Saudi Arabia.

What is GSM-R?

GSM-R is a standard that defines the use of GSM as a network for rail transport infrastructure operators.

GSM is a 2G-cellular mobile system that is still being used by billions of people around the world. It is a digital system that uses a combination of time division multiple access (TDMA) and frequency division multiple access (FDMA) to provide voice and data services to mobile devices. GSM is used for a wide range of applications, including voice calls, text messaging, and mobile internet access.

GSM-R is a specialized version of GSM that is designed specifically for use in railway communication systems. It is used by railway companies to provide voice and data communication between trains, stations, and control centers.

Figure 2: A GSM-R terminal and Control Center

One of the key differences between GSM and GSM-R is the frequency band they operate on. GSM-R (with extended bands) operates on 873 MHz to 880 MHz for uplink, and on 918 MHz to 925 MHz for the downlink [ETSI TS 102 933-1: Railway Telecommunications; GSM-R improved receiver parameters; Part 1: Requirements for radio reception]. "Non-RT" GSM operates on a much wider range, spanning worldwide from 890 MHz up to 1990 MHz (with gaps, i.e. not all frequencies between 890 and 1990 MHz are allocated to GSM, e.g. in Europe, the GSM-R frequencies are not usable by "non-RT" GSM.). The exact bands allocated to each GSM operator are specified by the national regulator, and this changes over time: nowadays, some of the GSM frequencies are re-allocated to more recent systems (this is called "refarming").

Besides dedicated frequencies, GSM-R makes an extensive use of some (rather-specific) GSM Features, such as: functional addressing, location-dependent addressing, and some Private Mobile Radio (PMR) features such as "Voice Group Call Service", "Voice Broadcast Service" and "Priority and Pre-emption".

The adoption of GSM-R has been a gradual process, managed by UIC, which managed the roll-out plan and handled issues that arose at deployment. The adoption of GSM-R has since then been mandated by the European Union, i.e. every new railways telecommunication system in Europe has to be GSM-R.

The GSM-R standard implements a number of applications and requirements specific to the railway environment, including data and voice communications at speeds of up to 350 km/h.

Sources: RT leaflet, https://uic.org/rail-system/gsm-r/

Early 3GPP Releases:

Initial Release ("Release 99", 1999) to Release 9 (2009)

In the 3GPP's early years, the interactions between railways and 3GPP were somehow limited: 3GPP was mainly focussed on the third generation of mobile telephony, also known as UMTS. But this new technology was not adopted by the Railways community: it came too early, since they had just adopted GSM-R.

More generally, the 3GPP and the Railways timelines are different: 3GPP is (at least initially) general public-oriented and produces a new Release roughly every 2 years, and a new Generation (incompatible with previous ones) roughly every 10 years, as shown below - also showing the initial confusion in Releases naming: the regular incremental pattern started only from Rel-4 in 2001.

Figure 3: the "Generations" (top), the "Releases" (middle), and the years (bottom)

This frequency suits the wide-audience habits of changing phone (User Equipment, UE) roughly every two years. For the Railways community, as for several other industries, the needs evolve much less rapidly and the return on investment takes longer.

In this context, the railways community decided not to have any 3G-based system.

So, during 3GPP's first decade of existence (roughly from 1999 until Release 9 in 2009), and since 3GPP was focussing on UMTS, there was almost no interactions between the 3GPP and the Railways communities.

There was actually no interaction at all in Release 99, nor in Release 5, 6, 7 and 9. The Releases 4 and 8 enhancements are detailed below.

In Release 4 and 8, some specific, mostly radio-independent, enhancements/corrections were introduced.

Improvements on Speech-related items (ASCI, VGCS, VBS) used by GSM-R

In Release 4 (in 2001), some GSM-R improvements were introduced under the Work Item "Advanced Speech Call Items (ASCI) enhancements", relating to Voice Group Call Service (VGCS, in TS 43.068) and its associated control (TS 44.068), and to Voice Broadcast Service (VBS, in TS 43.069) and its associated control (TS 44.069), thus impacting also the layer 3 (UE to CN) of the radio interface (TS 24.008).

More precisely, the European Commission's Technical Standards for Interoperability (TSI), asked for GSM-R to be enhanced to cover High-Speed Train (HST) Interoperability. These enhancements were: the possibility to add operator-to-dispatcher information, the definition of ASCI related event records, and the introduction of VGCS/VBS ciphering. Also, several independent corrections were made, that can be considered as maintenance of the ASCI feature.

In Release 8 (in 2008), some additional (optional) VGCS functions were introduced, mostly targeted for railway applications, but also usable by public networks, in particular for communication of public authority officials. These were the ability to send and receive a small amount of data between group members, including dispatchers, requiring short round trip (500ms) without impacting voice quality of the group call; and to send an indication/small amount of data from service subscribers to the network. This was intended as a simple means (e.g. pressing a single button) to request dispatchers to rejoin a group call, without having to make a point-to-point call for contacting the dispatcher (which would have required too many MMI actions).

This was covered by the "EVA" Work Item (Enhancements for VGCS Applications), which involved several 3GPP groups: SA1 or the service aspects and for VGCS/VBS and GPRS Interactions (covered in TS 42.068, 42.069), some protocol aspects (covered by CT1 in TS 43.068, 44.068 and by CT 4 in 29.002), as well as some radio aspects, covered by GERAN2 in TS 44.018, 48.008.

It was also in Release 8 that some commonalities between the requirements of the Railways community and the one of the public authorities (also called "Mission Critical") were first identified: both communities indeed moved from a dedicated network (e.g. TETRA, P25) to a "spin-of" of the 3GPP system that will cover their specific needs, i.e. a very-secured, resilient, system, enabling mostly group calls, possibly involving a "central entity" (dispatcher) and up to several hundreds of participants (bigger groups using mostly push-to-talk or text-based communication).

LTE 3GPP Releases: Release 10 (2011) to Release 14 (2017)

Again, there was no interaction at all between 3GPP and UIC/RT in Release 10 and 11: 3GPP was mostly focussing on specifying its 4G system ("basic" LTE was actually specified as early as Release 8), when the UIC still recommended to use GSM-R. However, it is possible for a railways company -in agreement with its local regulators- to obtain specific frequencies for railways and deploy LTE in these specific bands, thus creating "LTE-R". This is what happened in South Korea with "Korail" railway company (https://uic.org/com/enews/article/south-korea-korail-launches-new-ktx-eum-high-speed-train ).

In this context, the LTE improvements, and in particular the ones intended to Mission Critical/Public Safety community, also become usable by Railways companies having deployed LTE-R. The LTE features of particular interest for Railways are GCSE_LTE, ProSe and MCPTT, and are described below.

However, on a more general level, UIC is rather focussing on basing its next "Future Railway Mobile Communication System" (FRMCS) directly on 5G (https://uic.org/projects/future-railways-mobile-communications-systems-solutions ).

Group Communication System Enablers for LTE" (GCSE_LTE)

In Release 12 (2014) is introduced the "Group Communication System Enablers for LTE" (GCSE_LTE). This is mostly an adaptation to LTE of the GSM-R's Voice Group Call Service (or equivalent capacity of Tetra or P25) capacity to handle group communication. It enables efficient group communication, with dynamic groups with mobile users and dispatchers. It supports large groups (up to several thousands of users) and offers service continuity for transitions between unicast and multicast bearers.

The figure below shows a typical GCSE_LTE configuration:

Figure 4: typical GCSE_LTE configuration

Its specification involved several 3GPP groups: SA1 for the Service Requirements in TS 22.468, SA2 for the architecture in TS 23.458/23.768, SA3 for the security aspects in TS 33.246, CT3 and CT4 for the higher-layers protocol aspects and RAN3 for "Group Call eMBMS congestion management for LTE".

Proximity-based Services (ProSe)

Closely related to Group Communication is a brand-new LTE-only feature, also introduce in Release 12, called "Proximity-based Services" (ProSe). ProSe enables devices to detect other devices in proximity and allows devices in proximity to communicate directly. For commercial applications (including railways), it enables to reduce the network load (or, conversely, to increase the capacity in a given bandwidth). For Critical Communications, it also enables communication without network coverage.

Figure 5: ProSe overview

ProSe involved several 3GPP groups: SA1 specified the Stage 1 in TS 22.278 and TS22.115, SA2 for the Stage 2 in TS 23.303 (preliminary study in TR 23.703), SA3 for security aspects in TS 33.220 and 33.303, SA5 for charging aspects in TS 32.277 (preliminary study in TR 32.844), CT1 (TS 24.333 and 24.334), CT3 (TS 29.343), CT4 (TS 29.344 and 29.345) and CT6 (TS 31.102) for the protocol aspects. The radio aspects were covered by RAN1, RAN2 and RAN4, with two dedicated studies in TR 36.843 and 36.877, and finally impacting several existing TSs (36.101, 36.133, 36.211, 36.212, 36.213, 36.214, 36.300, 36.304, 36.306, 36.321, 36.322, 36.323, 36.331, 36.413, 36.423). The testing aspects were handled by RAN5.

Mission Critical Push To Talk over LTE (MCPTT) and its evolutions: Rel-13 onwards

In Release 13 (2015) is introduced "Mission Critical Push To Talk over LTE" (MCPTT). Here again, the main target is public safety (the emergency services), for which it is an essential functionality, but it can also be used for commercial uses such as (railways) companies.

MCPTT is actually a major Release 13 Feature. It is the 3GPP’s solution to replace former dedicated networks used by the police, firemen, etc. It supports communications between several users (“group call”) and between pairs of users (“private calls”).  It works when there is LTE coverage (“on-network”) but also even when there is no LTE coverage (“off-network”).

When in the “on-network” context, MCPTT uses the standard LTE coverage, using the capabilities offered by Group Communications System Enablers for LTE (GCSE_LTE presented above).

In the “off-network” context, MCPTT uses the ProSe E-UTRA direct (UE-to-UE) Communication path. The ProSe direct communication path does not traverse the network infrastructure. Off-network can be chosen even when there is network coverage.

SA1 highlighted the improvements needed on the radio access (E-UTRAN), the core network (the EPC) and the application-layer functionality, including applications supported by UEs and external network elements (e.g. Application Servers) to support Mission Critical voice for LTE.

Both unicast and broadcast bearer are used by GCS AS for transferring application signalling and data. In Rel-13 MCPTT, only voice/audio media type is supported. In TS 22.179, AMR-WB is recommended for voice codec.

In order to support MCPTT service, GCS AS acting as media source delivers RTP payload to the UEs. In downlink direction, RTP based voice/audio delivery over EPS bearer is fully supported by MTSI specification already. In TS 23.468, it is decided that the data transferred via MBMS bearer(s) by the GCS AS is transparent to the BM-SC.

In TS 26.346, hybrid streaming delivery is supported. The UE receives streaming content from either PSS server or MBMS. In TS 23.468, for service continuity between unicast delivery and MBMS delivery, the UE communicates with GCS AS directly to maintain the service continuity. The discrepancy between those 2 specifications needs to be clarified.

Based on the analysis in TR 36.868, the E2E delay for media transport over MBMS bearer is beyond requirements. The E2E delay for media transport is different between EPS bearer path and MBMS bearer path. A MCPTT UE-A receiving RTP payload over EPS bearer will ahead of another MCPTT UE-B receiving the same RTP payload over MBMS bearer. This un-sync issue degrades the user experience and may impact the MCPTT UE-B requesting permission to transmit. This WI proposed to address this un-sync issue.

To better support MCPTT, the procedure, metadata element and value of element/attribute can be optimized considering the mechanisms defined in TS 23.468.  At the same time, the guidance of MBMS for MCPTT helps for interoperability.

Here again, several 3GPP groups were involved in its specification: SA1 for the Stage 1 in TS 22.179, SA6 - a new group initially dedicated to the Public Safety community- handled its Stage 2 in TS 23.179 (with a preliminary study in TR 23.779), SA3 for security aspects mostly in TS 33.179, SA4 for the codec and media aspects in TS 26.179 (with a preliminary study in TR 26.879). The protocol aspects were handled by CT1, CT3, CT4 and CT6, covering all aspects: IMS Profile to support MCPTT (in TS 24.980), call control (TS 24.379), floor control (on and off network) (TS 24.380), Broadcast Call Control and Floor Control (also in TS 24.379 and TS 24.380), Group management (TS 24.381), Identity management (TS 24.382), Management Object (TS 24.383), and Configuration management (TS 24.384).

In Rel-14, the Rel-13 MCPTT is enhanced with new functionalities. The main one is that, whereas Rel-13 was offering only voice MCPTT, Rel-14 now also offers data ("MCData") and video ("MCVideo"). As a reminder, although mostly targeting at mission critical services, it can be also used for public safety applications and also for general commercial applications e.g. utility companies and railways.

The 5G 3GPP Releases: Release 15 (2018) to Release 19 (2024)

With UIC targeting to evolve railways telecommunication from GSM-R, a 2G-based system, to a 5G-based system for the so-called "FRMCS" (Future Railway Communication System), the links between UIC/RT and 3GPP (via the companies involved on both sides) are getting more active in these later Releases.

Release 15 onwards: FRMCS/MONASTERY series of Work Items

(based on Nokia's SP-180854 for Phase 1, SP-200941 for Phase 2 and SP-220485 for Phase 3)

The railway community is considering GSM-R, with 2G-based technology, to be completely replaced around 2030.

The "MONASTERY" series of work items introduce the requirements to support the specific communication needs of railways.

It does this study as a gap analysis compared to Mission Critical's needs, covered by the "MCX" specifications set (MCX=MCPTT, then MCCore, MCData, MCVideo): the Mission Critical Communication framework specified by 3GPP is used as bases for railway communication and is continuously extended with railway specific functionality.

It spreads over Release 15 ("MONASTERY" phase 1), Rel-16  ("MONASTERY2", phase 2) and Rel-17 ("eMONASTERY2", phase 3) and ("MONASTERYEND" for the complete gap analysis).

This work initially started in 2014 in the UIC by an activity to collect the user scenarios to be supported by a Future Railway Communication System (FRMCS). As those user scenarios could not be mapped easily onto use cases in 3GPP, a Technical Report (TR22.889) was written summarising 3GPP style use cases, to come up with requirements for introduction in normative specifications.

The term "FRMCS" is used in UIC still and includes more than just the Mobile Communication System for Railways standardised by 3GPP. In the figure below, the light grey dotted boxes are in scope of 3GPP. The darker grey cross hatched boxes are also taken care of by 3GPP in maintaining the GSM legacy.

Figure 6: High-level relation of the Mobile Communication System for Railways / FRMCS and legacy systems

"Mobile Communication System for Railways" (MONASTERY) introduces the outputs of the study in TR 22.889 into normative work, and adapts the 3GPP system to provide communication to railway users. The MONASTERY will eventually resemble GSM-R and other legacy system in use nowadays and will additionally provide communication capabilities beyond what those systems support. It will provide higher data rates, lower data latencies, multimedia communication, and improved communication reliability.

To facilitate smooth migration from legacy communication systems to the Mobile Communication System for Railways, interworking requirements between legacy communication systems and the Mobile Communication System for Railways are provided.

Amongst others, Mobile Communication System for Railways provides emergency group communication, low latency and high reliable data and video service in high-speed train environment. Amongst others it has the following important features:

• Prioritized emergency group communication, train control data and video service
• Seamless connectivity in high-speed railway moving environments
• Low latency and high reliable data and video service
• Real time train monitoring and management for safe train operation
• Reliable location tracking including tunnel condition
• Legacy railway communication interworking to GSM-R system
• Specialised forms of addressing used for railway communication

Basically, railway communication services can be categorized into:

• Train control services
• Maintenance services
• Railway specific services (such as Railway Emergency Call, functional addressing, and location-based addressing)
• Other services (providing train crews or train Drivers with information of train operation and interworking with the existing railway communication systems)

In phase 1 ("MONASTERY", Rel-15), two additions are made to MCPTT group calls (while on-network) to support railway requirements : MCCore now supports a limited "functional alias" functionality, which is a role-based addressing for railways; as for MCPTT, it now supports multiuser talker control, an additional way of floor control allowing a defined number of talkers talking at the same time in a group communication rather than just one talker at a time.

In its Phase 2 (Rel-16), the "MONASTERY2" feature covered additional specification, on top of Rel-15, to support the specific communication needs of railways for MCPTT group and private calls and on enabling the use of functional aliases in MCPTT private calls, MCVideo and MCData service. It also corrects inconsistencies and clarifies ambiguities.

The main new functionalities include: the multi-talker functionality (e.g. to allow a MCX User to manually override multi talker requests); the support of supplementary services for railway communication (private calls). A lot of focus was put on interworking between FRMCS and GSM-R and a lot of refinement effort was spent on the handling and the integration of functional alias into the 3GPP system.

In its Phase 3 (Rel-17) ("eMONASTERY2" and "MONASTERYEND"), the Mission Critical Communication were enhanced with new functionality required by the railway community to support call forwarding and call transfer for private MCPTT calls. The MCData IP connectivity service was extended to support functional aliases and an MC service user can select an appropriate functional alias when be called by another MC service user. The relationship between MC service groups and the use of functional aliases is clarified, including those functions preventing de-affiliation when using a specific functional alias(es) or providing a list of functional aliases used by affiliated group members. For MCVideo services the use of functional aliases was added and is now available as for MCPTT. A functional alias as target address for MCPTT private emergency calls was specified and can be used as alternative to MCPTT IDs. An MC service user can now request an application layer priority, which allow arbitration of multiple service requests by MC service servers.

Radio adaptations to support mobiles moving at over 350 km/h

This section addresses configurations that take place only with High-Speed Trains (HST), i.e. it addresses the system impact of mobile phones moving at speeds approaching -or exceeding- 350km/h while staying at ground level (i.e. not in airplanes). Indeed, in the 3GPP specifications, the maximum speed guaranteed is 350km/h, but this speed is reached, or even exceeded, by some high-speed trains - the record is held by the French TGV at about 575 km/h but some commercial lines regularly exceed 350 km/h.

As early as Release 7, a first study was conduced on 3G, called "Study on Performance Evaluation of the UE behaviour in high-speed trains with speeds up to 350 kmph" (RANFS-HSTrains, WID in RP-060412).

High-Speed train support by LTE - Performance enhancements for high-speed scenario in LTE (LTE_high_speed, Rel-14) and its "further enhancements" (LTE_high_speed_enh2, Rel-16)

Based on NTT DOCOMO's RP-192721 (Rel-14) and RP-192721 (Rel-16)

In Release 13, the "Study on performance enhancements for high-speed scenario in LTE" (FS_LTE_high_speed, WID in RP-150159) targeted to evaluate the LTE performance for UEs moving at speeds up to 350 km/h. No normative was done as a result of this Study in this Release.

It is in Release 14 that this study led to enhance the mobility and throughput performance to specify the requirements for UE RRM, UE demodulation and base station demodulation, considering the two types of operator’s practical deployments:

The first case, shown in Figure 7, is where no specific installation is deployed to handle high-speed trains, i.e. UEs in the train use the "standard" LTE eNBs.

Figure 7: HST's use of the "standard" LTE eNBs ("Non-Single Frequency Network")

Alternatively, the other case, shown in Figure 8, is where a Single Frequency Network (SFN) is deployed. A SFN uses dedicated antennas deployed along the train track, called "Remote Radio Heads" (RRH). In this case, the baseband unit (BBU) is connected to the RRH, e.g. using fibre. 

Figure 8: HST's use of a dedicated "Single Frequency Network" (SFN)

Compared to the previous solution (use of standard LTE), this SFN solution provides better connectivity but at a higher cost.

These Release 14 enhancements were conducted both for non-SFN and for SFN, but only for LTE single carrier, i.e. not covering Carrier Aggregation (CA).

In Release 16 ("LTE_high_speed_enh2", WID in RP-181482), further normative work was done as to improve the mobility and throughput performance, now considering CA and speeds up to 500 km/h. To this aim, it enhances RRM, UE demodulation and base station demodulation: it first specified the enhanced RRM core requirements in TS 36.133 ("Requirements for support of radio resource management"), then it specified the impacts on RRC signals to meet these requirements in TS 36.331 ("Radio Resource Control").

About the RRM enhancements: in the Release 14 cases (limited to 350 km/h and single carrier), the latency requirements under DRX configuration up to 1.28s DRX cycle were enhanced by reducing the cell identification delay in connected mode and cell reselection delay in idle mode.

In Release 16, considering Carrier Aggregation and speeds up to 500km/h, the cell identification delay and measurement period on 1.28s DRX cycle are further reduced and another set of Enhanced RRM requirements is performed. Also, a larger maximum autonomous time adjustment step is applied when the downlink bandwidth is wider than 10MHz for enhanced UL timing adjustment requirements in connected mode.

About UE and base station demodulation enhancements: in Release 14, UE and base station demodulation requirements were enhanced for both cases of operator’s practical deployments shown in figures 7 and 8.

In Release 16, regarding the CA case in SFN (figure 8), the requirements specified in Rel-14 are expanded to Dual Connectivity's Secondary Cells (SCells) as defined in TS 36.331. Regarding speed up to 500 km/h, additional requirements are introduced to ensure the PDSCH/PUSCH/PRACH demodulation performance with larger Doppler shift.

High-Speed train support by 5G NR

5G radio ("NR" for New Radio) uses two different Frequency Ranges (FR), namely FR1 and FR2.

Figure 9: the two NR's FR:FR1 and FR2

The radio propagation characteristics are quite different for the two ranges, thus work has been conducted separately, sometimes in different Releases, for each Frequency Range.

Rel-16 NR support for high-speed train scenario for frequency range 1 (NR_HST) and its Rel-17 enhancements (NR_HST_FR1_enh)

Based on CMCC's RP-200776 (phase 1) and RP-220631 (phase 2/enhancements).

In Rel-16, NR_HST (WID in RP-191512) specifies the UE RRM requirements and UE demodulation requirements for single carrier scenario for FR1 for velocity is up to 500km/h and the carrier frequency is up to 3.6GHz covering both TDD and FDD. 

For RRM, both enhanced requirements for NR intra-RAT measurement and enhanced requirements for inter-RAT measurement between NR and EUTRA are specified. The enhanced requirements for NR intra-RAT include NR cell re-selection requirements, NR cell identification requirements, beam management requirements. The enhanced requirements for inter-RAT measurement between NR and EUTRA include EUTRA inter-RAT measurement requirements and NR inter-RAT measurement requirements, both idle mode and connected mode are considered.

For UE demodulation, HST-SFN (multiple RRHs are connected to one BBU with fibre), HST single tap and multi-path fading channel are considered. For HST-SFN, the maximum doppler shift is 1667Hz (500km/h + 3.6GHz) and 870Hz for 30KHz SCS and 15KHz SCS respectively. For HST single tap, the maximum doppler shift is 1667Hz and 972Hz for 30KHz SCS and 15KHz SCS respectively. For multi-path fading channel, the maximum doppler shift is 1200Hz and 600Hz for 30KHz SCS and 15KHz SCS respectively. For BS demodulation, at least HST single tap is considered. And the maximum doppler shift is 3334Hz and 1740Hz for 30KHz SCS and 15KHz SCS respectively.

In Rel-17, NR_HST_FR1_enh (WID in RP-210833) specifies the same aspects as the Rel-16's WI (enhanced RRM requirements and demodulation requirements to support the speed of up to 500km/h and carrier frequency of up to 3.6GHz), but this time for the Carrier Aggregation (CA) case.

For RRM, to guarantee the mobility performance for FR1 HST with velocity up to 500km/h, both enhanced requirements for NR inter-frequency measurement and enhanced requirements for CA scenario are specified in TS 38.133: the enhanced requirements for NR inter-frequency measurement include NR cell re-selection requirements, time period for PSS/SSS detection, time period for time index detection and measurement period requirements. The enhanced requirements for CA include both measurement on activated SCells and measurement on deactivated SCells.

For UE demodulation requirements for CA, both HST-SFN (High Speed Train Single Frequency Network) joint transmission scheme and DPS (Dynamic Point Selection) transmission scheme are considered, and the requirements are specified in TS38.101-4. With speed of up to 500km/h and carrier frequency of up to 3.6GHz, the maximum doppler shift is 1667Hz and 870Hz for 30KHz SCS and 15KHz SCS respectively. For 15KHz SCS, specify PDSCH requirements on single carrier of BW of {5, 10, 15, 20, 25, 30,35, 40, 45, 50} MHz. For 30KHz SCS, specify PDSCH requirements on single carrier of BW of {5, 10, 15, 20, 25, 30, 40, 50, 60, 80, 90, 100} MHz. 

Rel-17 NR support for high-speed train scenario in frequency range 2 (NR_HST_FR2)

Based on Ericsson's RP-220191.

This Rel-17 WI ("NR_HST_FR2", WID in RP-210800) covers NR's FR2, and more particularly frequencies up to 30GHz. This case is quite different from the previous ones on LTE and NR FR1 because, with NR FR2, the radio wave transmitted by Base Stations outside the train cannot penetrate the train, so the conclusions and enhancements of other 3GPP WIs (for either LTE or NR) with operating bands up to 3.5GHz do not apply to NR FR2.

For 5G services to be usable by the train passengers, a train roof-mounted high-power device is needed, that is used as a relay between outdoors's base stations and in-train UEs.

Figure 10: 5G NR FR2 HST scenario: train rooftop UE, serving as relay [TR 38.854]

This work item specifies the NR UE RF requirements, RRM requirements and BS/UE performance requirements, for speed up to 350km/h. Note that speeds higher than 350 km/h (as 500 km/h considered with FR1) are not yet possible with FR2.

In this WI, the FR2 HST deployment scenarios are studied, based upon which FR2 HST channel models are provided accordingly. From radio resource management (RRM) and demodulation perspectives, FR2 HST scenario is focused and evaluated, with the feasibility of FR2 HST scenario being technically confirmed.

For UE RF requirement, FR2 power class 6 for band n257, n258 and n261 is newly introduced, which is corresponding to the UE type of high-speed train roof-mounted UE. Relevant UE TX and RX RF requirements for power class 6 are specified, in which the TX and EIS spherical coverage requirements are defined over the newly introduced spherical coverage evaluation areas. For UE beam correspondence requirement, the applicability rule and requirement side conditions are specified.

The RRM requirements for FR2 HST scenarios are introduced and enhanced over existing FR2 RRM requirements. Specifically, the enhancements for FR2 HST are introduced on cell re-selection, RRC connection mobility control, gradual timing adjustment, SSB based radio link monitoring and beam failure detection, intra-frequency measurement and L1-RSRP/SINR measurement. The new requirements of one-shot large UL timing adjustment and TCI state switch delay are specified for FR2 HST scenarios.

The BS/UE performance requirements are discussed for FR2 HST scenarios, which will be further completed in the performance phase of this WI.

Introduction of 900MHz NR band for Europe for Rail Mobile Radio (RMR)

This Rel-17 work item ("NR_RAIL_EU_900MHz", WID in RP-211495) adds the support of Railways communications for bands n100 in CEPT countries.

It deals with the use of the Rail Mobile Radio spectrum in the 900MHz frequency band, which was assigned by the ECC Decision (20)02 [2] for the use by the railways in Europe.

It addresses all the necessary precautions to make the paired spectrum of 874.6-800/919.4-925MHz usable for 5G NR.

Introduction of 1900MHz NR TDD band for Europe for Rail Mobile Radio (RMR)

This Rel-17 work item ("NR_RAIL_EU_1900MHz_TDD", WID in RP-211542) deals with the use of the Rail Mobile Radio spectrum in the 1900MHz frequency band, which was assigned by the ECC Decision (20)02 [2] for the use by the railways in Europe, in CEPT countries.

It addresses all the necessary precautions to make the unpaired spectrum of 1900-1910MHz usable for 5G NR.

Release 18 and Release 19

Release 18 and 19 are still ongoing at the time this document is written. As such, no stable summary can be provided.

The items being specified in Release 18 are:

The only Rel-19 item identified so far is:

References

3GPP Work Plan

See a listing of all work & study items here:  https://www.3gpp.org/ftp/Information/WORK_PLAN/ .

References for Railways:

List of all items in the 3GPP Work Plan which name or acronym contains "Rail", "train", or "FRMCS":

See other work & study items here:  https://www.3gpp.org/ftp/Information/WORK_PLAN/ .

In the Excel sheet Work Plan, filter on the acronym column for "VGCS", "MC", "FRMCS", "GCSE" and "MONASTERY".