9 minute read

TECH EXCLUSIVE

Understanding Virtual

Primary Reference Time Clock & 5G Network Timing Architectures

Advertisement

Jim Olsen

Senior Technical Staff Engineer, Applications Microchip Technology

With the rollout of 5G networking technologies, we’re seeing greater momentum in both cellular mobile operator and Long-Term Evolution (LTE) private network environments. The 5G New Radio (NR) technology leverages time division duplex technology. This requires that new radio deployments to maintain phase alignment accuracy to a Universal Coordinated Time (UTC) Global Navigation Satellite System (GNSS) based timing source to within +/-1.5 microseconds. It is important to understand time error mitigation techniques for networkbased timing delivery using Precision Time Protocol (PTP) for 5G timing architectures. Also, the concept of a virtual Primary Reference Time Clock (vPRTC) is critical for network operators to make sound infrastructure decisions. Given that timing is a critical component of the infrastructure, network-based timing architectures that use PTP for 5G fronthaul applications need time error allocation engineering to ensure the timing requirements.

In wireless communications, co-channel radio interference is the most common issue related to timing. When a Global Navigation Satellite System (GNSS) (e.g. GPS, Galileo, Beidou) receiver is deployed at a cell site, it must track satellites properly to allow for time slot transmission assignment. In turn, this ensures that radios operating in adjacent or close frequencies don’t interfere with each other. If a GNSS receiver fails or stops tracking properly in a radio cluster with overlapping coverage, it can cause the radio connected to the GNSS receiver to interfere with adjacent radios as the timing degrades or accumulates phase error. Since radios typically use low cost, low performance oscillators to help cut costs, timing degradation occurs very quickly.

When timing begins to degrade, either the radio needs to be removed from service or the services affected by the timing degradation need to be turned off immediately to avoid interference issues. A PTP network-based timing service can be deployed to help mitigate this type of failure scenario. In a PTP network-based timing service, the radios in the cluster are synchronized to a PTP grandmaster clock with an integrated GNSS receiver. In case of failure or tracking issues with the GNSS in the PTP grandmaster clock, the radios that are synchronized to the grandmaster clock will remain phase aligned relative to the adjacent radios. Therefore, interference is no longer an issue. High-quality oscillators deployed in the PTP grandmaster clock can help maintain time alignment to UTC for extended periods. Also, including PTP-based backup scenarios in the architecture can help maintain UTC traceable time in failure scenarios. This approach is very resilient and cost-effective. Other advantages include phase alignment of radio clusters in GNSS failure scenarios, the ability to bring GNSS deployment to centralized points of presence of security. In addition, good line-of-sight to the satellite constellation can be carefully engineered. The below diagram shows the distribution of PTP to 5G radio cluster over ethernet optics fronthaul technologies. Networkbased timing service delivery using PTP offers a strong case both from the business and technical points of view.

Figure 1. This shows a GNSS timing receiver with a grandmaster clock function and is an example of a distributed timing architecture in a fronthaul architecture. Timing is delivered from the grandmaster clock to the radio over the Ethernet Common Public Radio Interface (eCPRI) link.

With the evolution and advancement of timing and transport technologies, there are several enhancements and alternatives to 5G timing architectures for fronthaul applications. The objective of this article is to introduce and explore the concept of Virtual Primary Reference Time Clock (vPRTC), flesh out some of the advantages of the associated timing and transport technologies and architectures. The diagram of the PTP network-based timing delivery service architecture above leverages a distributed GNSS timing receiver. With technology advancements related to full-onpath support for PTP streams, we see the emergence of new classes of boundary clocks in switches and other devices. These reduce the time error produced by these devices in a time transfer path using PTP. This makes it possible to meet stringent timing requirements of 5G applications such as 1.5 microseconds or 260 nanoseconds without requiring the GNSS Timing receiver/PTP Grandmaster function to be in close proximity to the PTP clients in the 5G radio.

In a network-based PTP timing delivery architecture for high accuracy applications such as 5G timing applications, every nanosecond of time error counts. Therefore, it is important to eliminate or mitigate as many sources of time transfer error as possible. There are two concepts around time transfer error mitigation that are part of time error budget allocation engineering.

The first concept is focused on the GNSS source of time, consisting of a GNSS timing receiver and a PTP grandmaster clock function. A GNSS timing receiver used for time transfer in telecom applications is known as a Primary Reference Time Clock (PRTC). PRTC technology can be classified into three categories based on how close the GNSS maintains time accuracy to UTC when tracking and extracting time for the GNSS satellite constellations. In PRTC Classification A, the PRTC A is required to be within +/- 100 nanoseconds of UTC. UTC refers to the time reference extracted for the GNSS satellite constellations, when tracking properly. In PRTC Classification B, the PRTC B must be within +/- 40 nanoseconds of UTC when tracking properly. In the enhanced PRTC (ePRTC) classification, the ePRTC needs to be within +/- 30 nanoseconds of UTC when tracking properly. In ePRTC, there is an additional requirement related to GNSS vulnerability. This adds a holdover specification that the ePRTC must be within 100 nanoseconds of UTC for at least two weeks if the GNSS reception fails or is compromised. To achieve this, achieved by co-locating a cesium atomic clock reference with the GNSS timing receiver function. Learning algorithms in the ePRTC learn the offset between the cesium atomic look and the GNSS UTC reference. If the reference becomes unavailable, the algorithms can compensate for the offset of the cesium and maintain UTC traceable time for an extended period.

The second concept is called full on-path support and is focused on the transport network and equipment. In this model, the PTP time stamps do not pass through the switches and routers in the path between the GNSS based PRTC quality grandmaster clocks and the end application PTP clients in the Radio Unit (RU). Instead, the PTP time stamp flow is terminated at the ingress point of the switch. It regenerates with a grandmaster clock function at the egress ports of the switch. This process, known as a

Boundary Clock (BC) function, helps mitigate the time error of the switching element. It achieves this by measuring and compensating for the variable delay on the time stamps introduced by the switching fabric of the switch. Over time, the BC technology used inside the switches has evolved, making room for improvements in time transfer error when network-based timing delivery using PTP is implemented. When BC technology was first introduced, there was a single classification that defined the maximum time error allowed for the switch that incorporated the BC function. Now, there are multiple BC classifications for switches that enable much lower maximum time error classifications. They also make it possible for a GNSS based grandmaster clock function to be positioned at a greater distance in the network. They are also positioned over many more switching hops from the PTP clients in the RU. As defined in the ITU standard G.8273.2, Boundary Clock functions recover time transfer from a PTP input and fall into the category of a Telecom-Time subordinate/client clock (T-TSC). The Boundary Clock classification as well as the T-TSC time error functions are bounded by a maximum allowable Constant Time error (cTE). This is the mean of the time error expressed as a single number and compared to an accuracy specification. While BC technology enables mitigation of the time transfer error of the switching devices, it does not allow for mitigation of time error due to the introduction of any additional network-based asymmetry.

Below is a table that describes the ITU standards-based Boundary Clock/T-TSC classifications and associated cTE boundaries.

Figure 2. This table identifies the various boundary clock classes and their associated time error allocation budget requirements are identified.

With advances in technology for both Primary Reference Time Clock and Boundary Clock functions, a network-based timing service using PTP can extend the reach of the timing service from the GNSS source of time to the end RU applications. This is true for both distance and number of switching hops and maintain high levels of accuracy. It provides an alternative to distributed GNSS timing architectures where the GNSS source of time can be located in more centralized location closer to the core of the network. Called the virtual Primary Reference Clock (vPRTC), this concept can be engineered over Ethernet/ packet switching or Dense Wave Division multiplexing (DWDM) optical transport networks.

There are three components in vPRTC architecture. A GNSS source of time with a PTP grandmaster clock function is the first one. This can either be of PRTC B (+/- 40ns) or ePRTC (+/- 30ns) quality. An ePRTC, which adds a cesium atomic clock can be co-located with the GNSS timing receiver to improve the timing accuracy of the GNSS receiver relative to UTC. This helps address GNSS vulnerability issues and holdover performance the and also provides the extended holdover capabilities, <100 nanoseconds to UTC for a minimum of two weeks, if the GNSS signal is compromised. The network itself is the second component. This includes the network transport architecture between the GNSS source of time and the end RU PTP application. For proper time error allocation and mitigation, the transport segment of the vPRTC must provide Full on Path support with Boundary Clock classification capabilities of class C or D. The third segment is the network edge access location. The PTP time stamp flow is delivered to the end RU PTP timing application. This location must create a vPRTC function within the PTRC A specifications of <100 nanoseconds to UTC through recovery and regeneration of the PTP timing flow. The PTP timing flow is then delivered to the end RU PTP timing application over the Fronthaul network segment.

Figure 3 depicts the vPRTC concept in a Class C boundary Clock Full on Path support transport network.

Figure 3. This drawing depicts a packet network configured as a Virtual Primary Reference Time clock (vPRTC) using Class C Boundary Clock time error allocation.

Summary

Advancements in networking technologies enable highly accurate time transfer over longer distances and longer chains of network elements. Therefore, operators now have a choice of introducing the GNSS-based source of time for 5G timing architectures at various locations from the edge to the core of the network. With the vPRTC architecture, there is an added technical advantage related to resiliency and redundancy. Configuring the vPRTC in an east-west configuration with two locations for the GNSS source of time and grandmaster function makes the ePRTC or PRTC redundant. This configuration is also conducive for bidirectional PTP timing flows for ring or liner ring network architectures. Here, timing and traffic are delivered from the opposite direction via a fiber cut. This adds a layer of resiliency and redundancy to the architecture.

The evolution of As 5G networks will make both distributed GNSS PTP timing architectures and centralized vPRTC PTP architectures viable commercial and technical options for global operators as well as 5G LTE private networks. Assuming that the underlying network topology is available, taking care in design can help build the most robust and reliable timing architecture.

This article is from: