Many 5G systems rely on reference precision timing signals for network synchronization in order to operate. Today, 5G networks generally rely on GNSS for accurate reference time and frequency. This dependency has resulted in vulnerabilities for these systems in the event of GNSS jamming/interference, data or measurement spoofing of GNSS signals, environmental conditions and/or anomalies. This use case describes how 5G systems may maintain time synchronization in the event of a loss or degradation of GNSS reference timing.

The 5G system receives GNSS precision timing signals for network synchronization.

1. The 5G system maintains time synchronization from a single GNSS timing source.
2. A GNSS service degradation or outage takes place.
3. The 5G system detects primary GNSS reference timing signals are no longer viable.
4. The 5G system receives accurate timing signals from an independent timing source, e.g. Terrestrial Beacon System [7]  [8], which can offer a timing alternative to GNSS.

The 5G system maintains accurate time synchronization during GNSS reference time service degradation.

Since Release 15, RAT-independent positioning technologies that leverage precision timing signals have been enabled in 5G systems, e.g. TBS/MBS [7]. Similar to GNSS, these technologies support positioning, navigation and timing (PNT) applications, while also being able to operate independently from GNSS. The timing features of these technologies may be leveraged to maintain reliable 5G time synchronization in the event of a degradation or loss of GNSS timing signals.

[PR 5.1.6-1] [PR 5.1.6-2] [PR 5.1.6-3] [PR 5.1.6-4]

The focus for this use-case description is power sub-stations where robust time synchronization is needed for e.g., synchro phasor and other Smart Grid applications.1

Power sub-systems use wireless means to achieve time synchronization, as is the case today leveraging GNSS receiver capabilities. In today's power sub-system, the timing resiliency is based on e.g., having multiple grandmasters leveraging multiple GNSS receivers. In this use case the 5G system is used as a supplement to, e.g., integrated as alternative radio in the grandmaster clock or as an alternative grandmaster clock with 5G capability in the power sub-system, or alternative to the GNSS, e.g., integrated with PTP grandmaster clock avoiding installation of external GNSS antenna and receiver at the power sub-station. In this use case, the smart grid is subscribed to and authorized to use the 5G timing resiliency service to ensure reliable timing signals are always available. The 5G timing resiliency service monitors the accuracy and availability of timing signals from a designated timing source and is able to provide an alternate source (e.g., 5G holdover capacity, atomic clock) in case of failure in the primary source. An SLA may be in place to establish the primary and any alternate timing sources that can be used.

This section should also describe how the timing resiliency is enhanced when the 5G system is used in conjunction with the GNSS, how the system is notified of a failure of GNSS, how the 5G system picks up the slack to keep the system running smoothly in the absence of GNSS. The UEs are preconfigured to enable the provision of time synchronization service from the 5G system. In addition to the initial pre-configuration the UEs may have, additional information may be used for dynamically configuring the management of the 5G system time synchronization network within the smart grid system. The configuration of the smart grid system includes timing service from GNSS with resiliency support provided by the 5G system. Based on the 5G time resilience requirements, the time distribution method used, and type of time synchronization device connected to the UE (e.g., DS-TT), the 5G system may configure different network entities (i.e., gNBs, UEs/DS-TTs, UPFs/NW-TTs) and the behaviour when an issue is detected (e.g., notification towards the UE or application, back-up configuration). The 5G system detects that the GNSS is experiencing a problem (e.g., loss of satellite access, detection of inconsistent timing information). The 5G system communicates the loss of GNSS to UEs or applications subscribed to the timing resilience service. Additionally, the 5G system may indicate the UEs should use the timing service provided by the 5G system until further notice instead of GNSS signal. The 5G system is configured to provide an accurate timing service for a specified holdover time. Depending on the detected problem and the impacted area, the 5G system may reconfigure its own network to ensure the distribution of an accurate timing service to the UEs. The 5G system provides timing information to the UEs using a secure mechanism. The UEs are able to verify the integrity and accuracy of the timing information provided by the 5G system The 5G system continues to monitor for a return to service by the GNSS. When the GNSS service recovery is detected, the 5G system informs the UEs or application subscribed to the resilience timing service that they can again receive GNSS timing information.

The Smart Grid can use 5G system as a resiliency backup to their GNSS receiver based (or wired) time synchronization systems to improve availability and reliability of the time synchronization. Alternatively, existing GNSS receiver-based solutions may be replaced with a 5G system-based solution where it improves efficiency and/or reliability.

Many 5G system features specified in Rel-16 and expected in Rel-17 will be required for the use-case:

• Time synchronization to UTC leveraging 5G system C-Plane and/or U-Plane
• Support for IEEE 1588 PTP
• Propagation delay compensation, to ensure that time synchronization can be conducted accurately across wide area deployments needed for power sub-station support
• Exposure framework supports time synchronization based on the needs of the service

This use case describes the need for secure clock signals to be made available to devices and application servers in a reliable manner by a 5G timing resiliency service. The clock signals may be used for timing synchronization in a variety of applications, such as highly sensitive industrial IoT applications, Power grid, commercial banking and stock trading platforms. All these application domains are highly time sensitive and provide critical infrastructure. As such, these domains may be subject to attacks by spoofing the clock source. To prevent such attacks, in all these scenarios, the clock signals can be accepted only if they are authenticated to be genuine without any manipulation by an external source. Hence it is essential that there is a means to verify the authenticity and integrity of these clock signals.

Devices and application servers connecting to a 5G system providing a 5G timing resiliency service are expected to go through the 5G authentication process. As part of 5G authentication, the subscription records for these devices are verified and they are authorized for service. During this process, the devices also learn to generate the application specific keys. Hence when these devices invoke the 5G timing resiliency service, and receive the clock signals, it is possible to verify the authenticity of the clock server as well as verify the integrity of the clock signals.

The 5G timing resiliency service needs to support multiple granularity and accuracy KPIs based on what these clock signals provided by the 5G system are used for. For example, there can be premium service with high accuracy and redundancy, whereas ordinary service may be just time of the day up to minutes. Hence the clock signals need to be made available based on the service subscription.

The UEs connected to 5G system are mutually authenticated and authorized for the 5G timing resiliency service. The UEs such as industrial precision robots requiring clock signals have a subscription for timing service. The 5G system is able verify the identity of the UE and authorize it for a timing service with the precise granularity needed. The UE, after completing the authentication and authorization, is able to invoke the timing service either through a specific API or a messaging interface. The UE is able to authenticate the clock server (source of clock signal) as genuine or not. If the UE finds that the clock server is failing the authentication verification, the UE does not accept the timing signals. The UE is also able to verify the integrity of clock signals received. If the integrity check fails, the UE doesn't accept the signals. Similarly, an application server also is able to connect to the 5G system. To receive required clock signals provided by the 5G system, the application server may be connected to the 5G system either over a wireless link or a wireline interface.

Currently TS 22.104 has requirements on timing which provide the base for additional requirements for a timing service.

[PR 5.3.6-1] [PR 5.3.6-2] [PR 5.3.6-3]

The focus for this use-case description is financial sector. Markets and market participants are highly interconnected, absolutely accurate time stamping is essential to determine exactly who made what trade, and precisely when. Market participants may execute orders on stocks in seconds or microseconds depending on the type of trading activity (e.g. high-frequency algorithmic, voice trading systems, human intervention, concluding negotiated transactions, etc). Without a reliable common reference time to provide synchronized time stamps, transactions across locations and stock exchanges are impossible to audit or to detect wrongdoing. To achieve a more regulated timekeeping system, the European Securities and Markets Authority (ESMA) has issued new rules in support of the MiFID II (Markets in Financial Instruments Directive II) regulations [12]. The Regulatory Technical Standard (RTS) 25 is a part of the standards developed by ESMA in the context of MiFID II. RTS 25 defines standards for clock synchronization [13]. Similar to MiFID II, U.S. Securities and Exchange Commission (SEC) introduced Rule 613 and the Consolidated Audit Trail (CAT) to accurately track all activity throughout the U.S. markets in National Market Systems (NMS) securities. Rule 613 requires electronic trading business clocks to be accurate to the National Institute of Standards and Technology (NIST) clocks (i.e. 50 ms for automated orders, 1s for manual orders). MiFID II generally has the strictest requirements when it comes to time stamping (i.e. ≤100μs for high frequency algorithmic trading, ≤1s for voice trading, human intervention, or concluded negotiated transactions, and ≤1ms for other type of trading activities), and is of relevance also to foreign regions as foreign regimes need to have regulations of comparable quality in order for companies in that regime to transact with European entities. To ensure MiFID II compliance, market participants must have the ability to demonstrate where the timestamp is applied and that it remains consistent, it is not enough just having an accurate time source. Satellite signals or systems that provide direct traceability to the UTC time issued and maintained by a timing centre listed in the BIPM Annual Report on Time Activities are considered as acceptable as time sources. However, if satellite signals are used, the ESMA states the users should be aware of the relevant risks with those signals and must mitigate them [15]. In addition to document and monitor their timing network architecture, market participants also need to consider impacts MiFID II compliance brings in their system such as the security and integrity of the reports collected (e.g. access management that ensures only a certain group of nodes can access the data, authentication to protect the data, data integrity to maintain the consistency and accuracy of the data).

MiFID II and MiFIR regulation requirements mandate firms and venues to time stamp events accurately to UTC and to an appropriate level. Particularly, article 4 of RTS 25 [13] also states: In this use case, both the time synchronization at the end devices (to enable the time stamp accuracy required) and how the time synchronization is distributed to these devices (to enable UTC traceability) are crucial to comply with MiFID II regulation. The market participant is subscribed to and authorized to use the 5G timing resilience service to receive accurate absolute time, directly traceable to UTC, resilient and worldwide available. The 5G timing distribution and resilience service ensures time traceability through either real-time monitoring (e.g., the continuous comparisons of the clock to ensure the device is working properly) or offline (e.g. calibration of the equipment) handling of the following:

• A continuous chain of comparisons with known uncertainties.
• Time equipment calibration.
• Continuous monitoring to demonstrate compliance and correct functioning.
• Calibration evidence and monitoring results to be archived.

For UTC traceability, each link involved in the time dissemination chain from the reference time scale UTC up to the point of provision must be documented, as illustrated in Figure 5.4.2-1. An SLA will be in place to establish the time synchronization accuracy and traceability requirement to UTC. The time synchronization accuracy provided by the 5G System domain at the output of the 5G Device will be a suitable portion of the target requirement applicable at the application layer of the Financial customer domain, as an example in order to meet 100 μs, the 5G System domain could provide at least 10 μs accuracy.

1. The 5G system and the market participant establish an SLA for the 5G timing resilience including UTC traceability and required accuracy of the time distribution service.
2. The 5G system provides UTC timing information to the UEs using the 5G timing resilience service.
3. The 5G system maintains time synchronization to UTC time scale at the UE, monitors the time distribution and ensures UTC traceability.
4. The 5G system provides UTC traceability evidence to subscribed applications.

The financial sector can use 5G system as a solution to access UTC and comply with MiFID II requirements. The 5G system can be used in collaboration with or as backup to other timing solutions used already by financial markets such as atomic clocks, NTP servers, GNSS, UTC(k) delivery over fiber (e.g. NPLTime or similar services).

Many 5G system features specified in Rel-16 and expected in Rel-17 will be required for the use-case:

• Time synchronization of UE to UTC leveraging 5G system C-Plane and/or U-Plane
• Time distribution from device to local data network using Ethernet, PPS, etc
• Support for IEEE 1588 PTP
• Propagation delay compensation
• Exposure framework supports time synchronization based on the needs of the service