Network-Based Synchronization for O-RAN

Introduction

Synchronization is a complex area consisting of many topics. Elementary knowledge is essential for a proper understanding of advanced issues. Therefore, the previous blog post [1] introduced the basic concepts, like the differences between frequency, phase, and time synchronization. Also, the differences between the oscillator, generator, and clock were explained, along with measurement methods, metrics, and operation of phase synchronization loops. With the basic terms assimilated, we can move on further.

In this blog, we compare the synchronization source technologies and their potential for use in specific applications. We discuss the synchronization concepts in telecommunication, followed by a detailed explanation of synchronization in O-RAN, which deals with the fronthaul interface, its different configurations, and the timing requirements.

Synchronization Sources and Technologies

In the telecom market, many synchronization technologies are available. Table 1 compares the available options [2]. The presented sources offer varying levels of accuracy. Among the methods presented, two main groups can be distinguished:

  • Wireless/Satellite signal delivery methods. The most significant advantage of GNSS-based solutions is their global availability at no additional charge. On the other hand, a serious disadvantage is their susceptibility to all kinds of signal interference, e.g., spoofing or jamming.
  • Wired signal delivery methods. Network solutions are heavily dependent on the available infrastructure and equipment. However, unlike GNSS-based methods, it is resistant to radio interference.

Table ‎1. Comparison of different time sources

TypeAccuracyAvailabilitySignal delivery methodComments
GPS40-80nsGlobalWireless/SatelliteOften used as the primary source of the synchronization signal
Galileo30 nsGlobalWireless/Satellite 
GLONASS100nsGlobalWireless/Satellite 
Beidou50 nsGlobalWireless/Satellite 
Iridium STL200ns (differential 50ns)GlobalWireless/Satellite LEO 
NTP100msDepends on the telecom networkWired 
PTP< 1μsDepends on the telecom networkWired 
SyncE±4.6 ppm (for each EEC clock on the link)Depends on the telecom networkWiredFrequency transfer only
WhiteRabbit < 1nsDepends on the telecom networkWiredOpen project, free access to all documentation
OTN (optical)20ppm/100nsDedicated connectionWired 

To obtain reference time from GNSS, you need an Oscillator synchronized to GNSS [3], mostly known as a GPS Disciplined Oscillator (GPSDO). It is a device that combines a GPS receiver with a high-quality oscillator (e.g., quartz or rubidium), the frequency of which is constantly corrected based on time signals from GPS satellites or other GNSS systems. GPSDO serves as a highly accurate frequency and time source, used in laboratories, electronic workshops, measuring equipment, or radio stations, replacing the often more expensive atomic standards.

The first historically networked time transmission protocol is NTP (Network Time Protocol) [4]. Its purpose is to transmit time information from primary servers to other servers and secondary clients over private networks and the public Internet. The NTP subnet model contains several commonly available major time servers synchronised with national standards (UTC reference). Its fine-tuned algorithms reduce errors resulting from disruptions, server crashes, or possible hostile actions. Servers and clients are configured such that information flows from the master servers towards the clients, creating a branching structure of slave servers.

The successor to NTP is Precision Time Protocol (PTP) [5], with the current version developed in 2008 as a standard for a precise clock synchronization protocol for networked measurement and control systems. It enables frequency, phase, and ToD (Time of Day) synchronization with nanosecond accuracy, implemented in the packet transport layer, so it does not require a separate dedicated clock (synchronisation) network. The operating model is based on the client/server scheme. The master clock, working as a server, broadcasts time information and responds to slave clocks through ordinary clock queries.

Synchronous Ethernet (SyncE) [6] extends the use of a clock recreated by a PLL (Phase-locked loop). The two Ethernet nodes are typically synchronized using a PLL on the receiving side. The position of the incoming bits on the receiving node is compared to the local clock, the correction is made, and it is adjusted to match the source clock. In a traditional network, the recovered clock is only used to receive correct data by adjusting the clock to the moments of rise and fall of the signals marking the bits. When the recovered clock is used to transmit data, we deal with SyncE, which can provide an accuracy of better than 4.6 ppm across the entire network.

White Rabbit (WR) technology uses PTP technologies to enable sub-nanosecond synchronization [7]. The WR project was established at CERN to create an Ethernet-based network that would have low latency, with packet arrival time that would be deterministic, as well as the entire network would be transparent and ensure high accuracy of time distribution. The WR Network (WRN) is based on and is fully compatible with existing standards such as Ethernet (IEEE 802.3), Synchronous Ethernet (SyncE), and PTP (IEEE 1588). The WRN network consists of White Rabbit Nodes and White Rabbit Switches connected via fiber optic or copper links. WR allows you to integrate nodes and switches that are not White Rabbit compatible and achieves sub-nanosecond synchronization accuracy. It uses SyncE to distribute a common frequency across the network.

OTN (Optical Transfer Network) [8] is a low-level protocol that allows time transfer over a public telecommunications network with a stability of 100ns if the circuit is not used for other purposes. You can provide UTC directly from research sites such as NIST, but a direct link to such a place is required. If it is possible to calibrate the line precisely, an accuracy of less than 100ns can be maintained. The method can act as a backup time source for GNSS systems.

Synchronization in Telecommunications

Commercialization of synchronization solutions occurs mainly due to the needs of telecommunications networks. Technologies such as NTP, PTP, or SyncE were created due to the demand from operators. The development of more accurate synchronization was forced with the introduction of the fifth generation of 5G wireless systems over the past decade. For the basic operation of the 5G network, the time synchronization requirements of the LTE/LTE-Advanced and LTE-Advanced Pro, namely the accuracy of time synchronization at the level of 1.5μs, are sufficient. However, to launch advanced MIMO  transmission, at each carrier frequency, it is necessary to synchronize with an accuracy better than 100ns. There are three ways to ensure this level of synchronization:

  • Each base station is equipped with a clock synchronized to the GNSS. The transmission network is not involved in the synchronization process. Accuracy depends on the functioning of GNSS.
  • Central distribution of the time standard using WR technology, which additionally requires PTPv2 and SyncE in the hardware transmission layer to work properly. The solution provides the best accuracy.
  • In a hybrid solution, point-placed clocks are synchronized to GNSS, and then the time signal is propagated using the existing synchronization network (PTP, SyncE) until the synchronization accuracy drops to 100ns. This is the cheapest solution, which operators often choose.

The correct functioning and synchronization of the network are possible when each element meets telecommunications standards, whith ITU-T (International Telecommunication Union – Telecommunication Standardization Sector) being the most prominent example. Transmission systems and networks, including synchronization, can be found in ITU-T section G [9]. Standardization documents specify acceptable parameters for clocks and sources. Similarly, for the entire network, there are standards, or for a given technology such as PTP or SyncE.

Synchronization in O-RAN

In the context of synchronization, the O-RAN standard mostly relates to Open Fronthaul (OFH) [10, 11], i.e., a standardized interface that connects the O-DU (O-RAN Distributed Unit) and the O-RU (O-RAN Radio Unit). Traditionally, this interface was vendor-proprietary (e.g., CPRI), which didn’t allow mixing and matching components from different suppliers. O-RAN introduces open, interoperable specifications to enable multi-vendor deployments. The functionality of the OFH is divided into logical planes, each serving a distinct purpose for the interaction between the O-DU and O-RU (see Fig. 1), namely:

  • User Plane (U-plane),
  • Control Plane (C-plane),
  • Synchronization Plane (S-plane).
Figure 1. OFH information Types

Figure 1. OFH information Types

The synchronization plane (S-plane) in O-RAN provides mechanisms to maintain precise time and frequency alignment between the O-DU and O-RU. Such synchronization is a prerequisite for the reliable execution of O-RAN functionalities, including TDD frame structure alignment, inter-carrier aggregation coordination, phase coherence for MIMO, and accurate beamforming operations. S-plane uses PTP and SyncE technologies on top of Ethernet (Fig. 2).

Figure 2. OFH S-Plane

Figure 2. OFH S-Plane

O-FH may be synchronised utilising various modes, as outlined by [12] from O-RAN WG4, which has established the following four configurations (see Fig. 3):

  • Configuration LLS-C1 (LLS-C1): utilises a point-to-point connection between the O-DU and O-RU employing the network timing option. This represents the most straightforward topology for implementing network timing, in which the O-DU provides direct synchronisation to the O-RU.
  • Configuration LLS-C2 (LLS-C2): closely resembles LLS-C1, wherein the O-DU serves as both the PTP and SyncE master to provide network timing for the O-RU. The synchronization SYNCE+PTP master is positioned at the O-DU. Additionally, all Ethernet switches within the fronthaul operate as Telecom Boundary Clocks (T-BC).
  • Configuration LLS-C3 (LLS-C3) enables network timing distribution from PRTC/T-GM to O-RU across both central and remote sites. This configuration allows for the deployment of one or more PRTC/T-GMs (serving as SYNCE+PTP masters) within the fronthaul network, facilitating precise timing distribution to O-DU and O-RU nodes.
  • Configuration LLS-C4: (LLS-C4) utilizes a local PRTC (typically a GNSS receiver) to provide timing to the O-RU and does not rely on the fronthaul for timing and synchronization. This configuration requires either an additional timing interface or an embedded circuit within the O-RU to support timing, which may result in increased cost (GPSDO on O-RU and O-DU).
Figure 3a. The O-RAN Alliance defines four time-distribution deployment models.
Figure 3b. The O-RAN Alliance defines four time-distribution deployment models.

Figure 3. The O-RAN Alliance defines four time-distribution deployment models

The O-RAN standard provides timing requirements, but they are built upon the 3GPP specifications. Table 2 shows RU-to-RU (connected to one DU) synchronization requirements established by 3GPP [13]. A Time Alignment Error (TAE) is a discrepancy in the timing of signals transmitted from different antenna ports within a base station, crucial for advanced wireless features like Transmit (Tx) Diversity, MIMO, and Carrier Aggregation in cellular networks. It represents the maximum timing difference allowed between signals from various antennas, measured against a common reference. Excessive TAE degrades radio performance, making precise time synchronization and alignment in the backhaul and fronthaul essential for network health. The full potential of MIMO is unlikely to be required in the first generation of 5G equipment because only WR technology can provide sufficient accuracy right now, and this technology is not widely spread.

Table 2. RU-to-RU synchronization requirements under 3GPP TS 38.104 for base stations

ApplicationRadio-to-radio TAE
MIMO transmission, at each carrier frequency65 nsec
intra-band contiguous carrier aggregation, with or without MIMO260 nsec
intra-band non-contiguous carrier aggregation, with or without MIMO3 µsec
inter-band carrier aggregation, with or without MIMO3 µsec

Summary

In this blog post, we have described the different sources of the synchronization signal and associated technologies. The concepts of synchronization of telecommunications networks were discussed. Correct synchronization is an essential element of the telecommunications system, because without accurate synchronization, it is impossible to ensure the appropriate QoS levels. The issue is complex, and during the design process, each device used and the entire network must meet telecommunications standards, with several standardization bodies involved, including ITU-T, 3GPP, and O-RAN.  The synchronization included in the O-RAN standards is based on the well-known technologies such as PTP and SyncE. Furthermore, the synchronization architecture of the OFH interface allows different configurations depending on the available resources in the existing network.

Stay tuned for #AllThingsWireless!

References

[1] https://rimedolabs.com/blog/time-synchronization-in-telecom-networks/

[2] https://gssc.esa.int/navipedia/index.php

[3] https://tf.nist.gov/general/pdf/2297.pdf

[4] https://datatracker.ietf.org/doc/html/rfc5905

[5] https://www.nist.gov/system/files/documents/el/isd/ieee/tutorial-basic.pdf

[6] https://www.albedotelecom.com/src/lib/WP-SynE-explained.pdf

[7] https://www.ieee802.org/802_tutorials/2013-07/WR_Tutorial_IEEE.pdf

[8] https://www.viavisolutions.com/en-us/literature/g709-optical-transport-network-otn-white-papers-books-en.pdf

[9] https://www.itu.int/itu-t/recommendations/index.aspx?ser=G

[10] https://www.5gtechnologyworld.com/how-ieee-1588-synchronizes-5g-open-ran/

[11] https://www.techplayon.com/o-ran-fronthaul-transport-synchronization-configurations/

[12] O-RAN Control, User and Synchronization Plane Specification 18.0 https://specifications.o-ran.org/download?id=881

[13] 3GPP TS 38.104 https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3202

Acknowledgment

Many thanks to Marcin Dryjanski for his guidance during my work at Rimedo Labs and tips for this blog post.

Author Bio

Paweł Kubczak received the M.S. degree from Poznan University of Technology in 2013. He continues his studies at the Faculty of Electronics and Telecommunications and is preparing his Ph.D. thesis. His research interests include phase-locked loops and network synchronization, digital measurement systems, time interval error measurement, randomness in digital logic, microcontrollers, and Field Programmable Gate Arrays. Currently works in RIMEDO Labs as a project manager.