Delivering timing accuracy in 5G networks

By Comcores

How IEEE 1588 PTP has evolved to meet the stringent time synchronization requirements of 5G

In mobile networks, time synchronization has always been important. Each new generation of mobile networks has driven the need for increased precision and accuracy in synchronization standards and solutions. Nevertheless, 5G is different. 5G time synchronization requirements are the most demanding seen to date and have elevated the importance of time synchronization and the need for more accurate solutions.

It is 5G requirements to support Ultra-Reliable Low-Latency Communications (URLLC) services, which are driving the need for greater timing accuracy. The 5G vision of new revenue generating services like autonomous vehicle connectivity and eHealth services are simply not possible without highly accurate and reliable time synchronization.

Even services like massive Industrial Internet of Things (IIoT) and other industrial automation services require reliable time synchronization.

5G is an entirely packet-based network from the core to the antenna. The challenge for 5G networks is how to provide ultra-reliable and highly accurate time synchronization over the 5G packet network. The answer is IEEE 1588 Precision Time Protocol (PTP).

PTP profiles for 5G networks

The IEEE 1588 PTP standards provide a wealth of options and the basis for highly reliable and accurate time synchronization solutions. However, the time synchronization needs of specific applications in different industries can vary quite significantly. These specific needs are defined in separate PTP profile standards, often in collaboration with other industry standards organizations. These profiles provide guidance on how to implement PTP for the specific needs of that application. There are over a dozen profiles for applications ranging from electricity distribution networks to audio/video broadcast, industrial automation and in-vehicle communication.

For 5G, both IEEE and ITU-T provide relevant profiles that can be used to design ultra-reliable and highly accurate time synchronization solutions. These can be seen in Figure 1.

^{Click to enlarge}

Figure 1: PTP Profiles

ITU-T has defined a set of telecom standards that define the operation and timing requirements for 5G networks and time-aware devices in these networks.

The ITU-T standards include two important telecom profiles for PTP, namely G.8275.1 and G.8275.2. G.8275.1 provides the most accurate solution, but is not always practical to implement. G.8275.2 provides the next best option that can meet some of the real-world challenges that confront modern mobile carriers. We will examine these two profiles in more detail below.

In addition, IEEE also provides a couple of important PTP standards that are relevant to mobile networks. IEEE 802.1AS provides a “generalized” PTP (gPTP) profile that is a part of the Ethernet Time-Sensitive Networking (TSN) set of standards. As the name suggests, gPTP defines a PTP profile that can be used for a wide variety of applications in an attempt to reduce PTP profile proliferation.

For 5G fronthaul networks, the Ethernet TSN set of standards includes a telecom profile that also provides specifications for time synchronization. Based on ITU-T G.8271.1, the IEEE 802.1CM standard specifies fronthaul maximum time alignment errors for different classes of applications that are driving the need for more accurate boundary clocks.

ITU-T PTP Telecom Profiles

ITU-T has defined three PTP profiles for telecom applications described in specifications G.8265.1, G.8275.1 and G.8275.2:

• G.8265.1 was first used to deliver accurate frequency synchronization, but not time synchronization, to mobile base-stations
• G.8275.1 is designed to deliver both highly accurate frequency synchronization, phase synchronization and Time of Day (ToD) with support for accurate frequency synchronization from the network physical layer
• G.8275.2 is designed to deliver accurate frequency synchronization, phase synchronization and ToD with only partial support from the network where non-PTP nodes are also in the network path

G.8265.1 provides frequency synchronization in Frequency Division Duplex (FDD) mobile networks where phase synchronization is not as critical. Only PTP ordinary clocks are defined with transport of unicast PTP packets over IPv4/IPv6 networks. The PTP performance is dependent on the network implementation.

^{Click to enlarge}

Figure 2: G.8275.1 PTP Telecom Profile

For applications that need frequency synchronization over IPv4/IPv6, it is recommended to use the G.8275.2 profile going forward.

For 5G networks based on Time Division Duplex (TDD), G.8275.1 is the recommended profile to be used, but requires that all switching nodes in the network can operate as PTP Telecom Boundary Clocks (T-BCs). This means that each device has to support its own high-performance oscillator (e.g.an OXCO) and timing logic that will allow the termination and regeneration of PTP packets. It also means that each device must support Synchronous Ethernet or a similar physical layer frequency synchronization input that can meet requirements. Tests have shown that it is very difficult to meet end-to-end time error requirements without a physical layer synchronization input.¹

There are many circumstances where the requirements of G.8275.1 cannot be met. This can be because parts of the network include switches and routers that cannot support PTP or Synchronous Ethernet input. In these circumstances, G.8275.2 can be used to provide the best time synchronization possible.

G.8275.1 profile

The G.8275.1 profile is designed to provide the most accurate time synchronization solution within the timing budget constraints of +/-1.5μs from the Primary Reference Time Clock (PRTC) to the antenna outlined in the ITU-T standard G.8271.1, “Network limits for time synchronization in packet networks with full timing support from the network”. The PRTC is a reliable source of phase, frequency and time, such as Global Navigation Satellite Systems (GNSS).

To meet the requirement of +/-1.5μs, G.8275.1 specifies that only T-BC clocks are used, which means there is only one hop between each T-BC reducing the impact of buffering in each device leading to packet delay variation.

To achieve this kind of performance, G.8275.1 stipulates that the network physical layer provides a suitable frequency synchronization input at each T-BC allowing each boundary clock to be synchronized, or to be more precise, to allows the clocks to be “syntonized”. Syntonization refers to the adjustment of two clock circuits so that they operate at the same frequency. This is referred to as full timing support from the network.

This can be achieved using Synchronous Ethernet at the physical layer. The combination of Synchronous Ethernet input and regeneration of PTP timing at each node enables a highly accurate time synchronization across multiple hops in the network while meeting the tight end-to-end accuracy budget. The quality of the T-BC clocks will determine the number of hops that can be tolerated. In Figure 3, class A and B T-BC clocks are shown, but there are also definitions for class C and D clocks that provide even more accurate performance with timing errors less than 10 ns and 5 ns respectively.

^{Click to enlarge}

Figure 3: G.8275.1 Architecture and Network Limits

For class C and D clocks, study is ongoing with respect to end-to-end timing budgets. For example, class C allows double the number of hops in theory, but can also allow looser specs for link asymmetry compensation or PRTC performance. Class C and D clocks are expected to be required in fronthaul network cluster configurations to ensure that relative time error requirements are met between RUs when there are multiple hops between the local PRTC at the CU and DU and the RUs.

G.8275.2 profile

One of the disadvantages of G.8275.1 is that every node has to support a T-BC with a certain level of accuracy requiring a physical layer frequency synchronization input. This is not always possible and therefore an alternative solution is needed. G.8275.2 allows PTP packets to be distributed using IPv4/IPv6 unicast rather than L2 multicast as used in G.8275.1. This enables PTP packets to be distributed over non-PTP networks and across L2 boundaries.

Because each node in the network does not have a physical layer frequency synchronization support, this is referred to as partial timing support from the network and the network limits for time synchronization are defined in a separate standard, namely ITU-T G.8271.2. Clocks are given an extension to indicate that they provide partial support, so a boundary clock in G.8275.2 is referred to as a T-BC-P rather than T-BC.

To achieve acceptable accuracy, T-BC-Ps are installed at strategic points in the network. In G.8275.2, PTP can be used in hybrid and nonhybrid modes:

• In hybrid mode, PTP is used for phase synchronization and ToD distribution in the network with Synchronous Ethernet support for frequency synchronization at T-BC-Ps
• In non-hybrid mode, PTP is used without Synchronous Ethernet support

While not as accurate as G.8275.1, G.8275.2 addresses real-world issues with respect to re-use of existing network installations and network sharing that mobile operators need to address. Real-world deployments of 5G can often involve traversing multiple networks owned by different operators, which might or might not offer a time synchronization service. G.8275.2 therefore provides some flexibility in delivering time synchronization over multiple networks.

G.8275.2 can also be used as an alternative to G.8265.1, which also delivers unicast PTP packets over IPv4/IPv6 networks, but only supports ordinary clocks. G.8275.2 provides a more flexible and potentially more accurate solution than G.8265.1 for the same use cases.

^{Click to enlarge}

Figure 4: G.8275.2 Architecture

Ethernet TSN and Mobile Fronthaul Requirements

Ethernet TSN encompasses many IEEE standards but from a time synchronization point of view, the relevant standards are IEEE 802.1AS, IEEE 802.1CM and the recent update IEEE 802.1CMde.

IEEE 802.1AS

IEEE 802.1AS defines a different profile for PTP otherwise known as “generalized” or gPTP that has recently been updated. It is similar to ITU-T telecom profiles in being based on layer 2 multicast. Instead of referring to ordinary clocks, boundary clocks and transparent clocks, IEEE 802.1AS refers to time-aware bridges and timeaware end-stations. A time-aware bridge is similar to a boundary clock, but where its operation is tightly defined so that it operates more like a transparent clock.

Only time-aware devices are allowed in the network allowing a peer-delay mechanism to be used. Each port on a PTP device sends a peer delay request message to the port it is directly connected to. The connected port then responds with a peer delay response message. The requesting port finally stores the propagation delay measured between the 2 ports.

IEEE 802.1CM and IEEE 802.1CMde

IEEE 802.1CM is an Ethernet TSN profile for Time- Sensitive Networking for mobile Fronthaul networks including 5G. From a timesynchronization perspective, IEEE 802.1CM assumes the use of IEEE 802.1AS and includes latency requirements that are important to consider. The requirements are closely aligned with ITU-T specifications for network limits for time synchronization in packet networks with full timing (G.8271.1), which means that Synchronous Ethernet physical layer frequency synchronization is also required in this standard.

G.8271.1 was updated in March of 2020 with new timing requirements for fronthaul networks. IEEE 802.1CMde is a recently released update to 802.1CM that takes these new requirements into account.

In fronthaul networks, an important consideration is relative time-error between radio units, especially in Time Division Multiplexed (TDD) radio networks, such as those in 5G. Each RU must align its transmission windows to ensure reliable communication without interference. The relative timing error needs to be lower than 65 ns between co-located RUs, 130ns for RUs sharing a clock in the same building and 260 ns for RUs sharing a clock, but situated in different buildings, as shown in Figure 5.

^{Click to enlarge}

Figure 5: 5G Fronthaul Timing Requirements

These stringent requirements are leading to fronthaul architectures where additional GNSS satellites are deployed to provide additional PRTC sources for the fronthaul network as well as at the antennae where possible to improve synchronization performance. This also opens the option of separate timing domains, which is especially attractive in providing 5G services to industrial automation, automotive and avionics applications where other PTP profiles can be used.

The additional PRTC sources can be at the CU or the DU and there can be multiple hops to the RU. For this reason, it is assumed that class C T-BCs will be required in the fronthaul to meet the relative timing requirements.

Figure 6 provides an example of a RAN network implementation where multiple PRTC sources are provided. Notice that there are two CUs, one of which is not time-aware. A PRTC solution is therefore needed at the DU connected to this CU. Fronthaul Gateways (FHG) and Converged Access Switches (CAS) will also be needed in the RAN. The CAS is co-located with a DU pool of several DUs, which can provide time sync. FHGs can require their own PRTC source, which can be in addition to other sources available as is shown at the bottom of Figure 6. For remote microcells, direct connection to GNSS can be necessary in order to provide time synchronization as shown in the figure.

As the figure also shows, both G.8275.1 and Ethernet TSN can co-exist and supplement with the RAN taking advantage of Ethernet TSN features.

^{Click to enlarge}

Figure 6: Example of RAN synchronization with multiple fronthaul time sources

Non-mobile application of telecom profiles

The increased accuracy of PTP supported by telecom PTP profiles and Ethernet TSN is driving adoption of these profiles for non-mobile applications. The first case is where the telecom PTP profiles have been adopted directly for GNSS backup solutions, while the second case is an example where the telecom profiles interwork with other PTP profiles specific to a particular industry, such as are used directly and the second case is where 5G is used to provide services for industrial automation, automotive and avionics.

GNSS backup solutions

In G.8275, the Assisted Partial Timing Support (APTS) architecture is defined where PTP is used as a backup timing source to a local timing reference, such as GNSS, for up to 72 hours. In these cases, PTP is not the primary timing source, but only a backup.

There are a number of cases where this can be relevant, especially as GNSS jamming and spoofing are becoming increasing concerns. For example, power distribution networks rely on GNSS input at each substation to synchronize phase. In these circumstances, PTP based on the ITU-T profiles can be used to provide a reliable APTS backup.

In general, any network that relies on GNSS as the primary timing source can use the APTS architecture and telecom PTP profiles to implement an extremely reliable backup.

5G services for industrial automation, automotive and avionics

Ethernet TSN provides a number of different profiles beyond the 802.1CM/CMde profiles for fronthaul networks. This includes the IEC 60802 TSN profile for industrial automation, the IEEE P802.1DG TSN profile for Automotive In-vehicle Communication and the IEEE P802.1DP TSN profile for Aerospace Onboard Ethernet Communications. All of these rely on IEEE 802.1AS as part of the Ethernet TSN group of standards.

As we have seen in ITU-T G.8271.1 and IEEE 802.1CMde, alternative PRTC sources can be introduced in the 5G fronthaul network. This opens the possibility of multiple clock domains, which can be exploited to ensure accurate time synchronization for 5G URLLC services. Through interworking functions, it is possible for the fronthaul network to implement time synchronization according to IEEE 802.1CMde, while a different PTP profile, potentially an Ethernet TSN profile based on IEEE 802.1AS, can be implemented from the 5G RU to the factory floor, within the vehicle or within the aircraft.

Comcores PTP Intellectual Property implementations

Building a solution that can meet the stringent requirements of ITU-T and IEEE PTP standards has become a major challenge. The requirements for extreme levels of accuracy and precision demand high resolution implementations with expert knowledge of both software and hardware.

Comcores PTP Intellectual Property (IP) provides a reliable implementation that accelerates the development of mobile devices like Radio Units (RUs), Centralized Units (CUs) and Distributed Units (DUs), as well as other mobile routing and switching devices. The PTP implementation provides well defined interfaces and is thoroughly tested with verifiable methods and hardware test configurations so mobile equipment manufacturers can be confident in integrating the IP into their design.

High-Performance, Siliconagnostic PTP Implementation

The Comcores PTP IP implementation is highly configurable and easy to use making it ideal for integration into mobile device development projects. The hardware IP is implemented in VHDL-93 and can be used in any RTL implementation, like ASICs, ASSPs and FPGAs while the software IP is implemented in C++. This enables the IP to be configured for multiple operating modes supporting different PTP profiles.

Point-to-point latency is automatically calculated and the solution also provides programmable eMAC and PHY ingress and egress latency compensation. The IP is pre-integrated with Comcores´ own MAC as well as with Intel and Xilinx Ethernet MAC cores and can be easily integrated with other MAC/PCS implementations. To enable customer-friendly implementation, a PTP hardware sub-system implementation is provided by Comcores that includes pre-integrated MAC, PCS and DMA IP as well as supporting PTP software.

^{Click to enlarge}

Figure 7: Comcores PTP IP Implementation

Reference designs are available to enable more efficient testing including sample application software.

Reliable and Tested Implementation

The Comcores PTP IP implementation includes both hardware and software and provides a highly reliable and accurate solution. The functional implementation is shown in Figure 8.

Multiple ports are supported using generic values defined in the hardware register, XML configuration file or via the management interface. The timestamp is inserted by the driver software with the local clock controlled by the PTP software stack via the kernel.

The implementation is already proven in O-RAN O-RU solutions and has been tested with Intel FlexRAN O-DUs on a system-wide scale. This has provided valuable experience and insight on how to ensure successful deployment of state-of-theart PTP time synchronization solutions for 5G fronthaul networks.

^{Click to enlarge}

Figure 8: Comcores PTP IP Software and Hardware

Table 1: PTP Profile implementations that can be delivered by Comcores

^{Click to enlarge}

Keep up with stringent time synchronization requirements

The deployment of 5G and introduction of URLLC services will demand more precise time-synchronization solutions. Existing mobile equipment will need to be upgraded or replaced to meet the stringent timing requirements outlined in available standards.

Comcores PTP IP implementations provide a reliable and up-to-date implementation of relevant PTP standards and profiles required for 5G mobile equipment. Designed for ease of integration, the Comcores PTP IP can ensure the rapid introduction of new or updated PTP solutions that can meet 5G requirements.

With experience in both hardware and software, Comcores can provide the design support you need as well as continuous updates as new requirements and standards emerge. With a platform agnostic solution that supports major FPGA vendors out-of-the-box with complete reference designs and application software, Comcores can provide a complete solution.

For more information on Comcores IP solutions and access to Comcores PTP IP contact us

¹ Source: AN1208: Choosing the Correct Oscillator to meet Your IEEE 1588v2 Network Synchronization Holdover Requirements (silabs.com)

If you wish to download a copy of this white paper, click here