5G OpenRAN and O-RAN Synchronization

In my previous article, I discussed about the typical synchronization requirements in 5G xhaul network. To set the background, please peruse it at https://www.dhimanchowdhury.com/2021/08/11/the-critical-imperatives-of-time-synchronization-in-5g-networks/ .

Traditionally, fronthaul is defined as the fiber-based connection in RAN infrastructure between the Baseband Unit (BBU) and Remote Radio Head (RRH). In such a setup, the underlay radio protocol stack remains relatively untouched: BBU processes the entire stack once physical layer processing is complete at RRH.

In contrast, 5G specification allows splitting of radio stack in eight different areas allowing portability and decomposition of RAN infrastructure. These splits are known as “option” and illustrated in the figure below: 1a indicative of various 5G split options and 1b describes how these split options fit in different parts of 5G BBU (gNB). Please note, the 3GPP specification of 5G specifies that the network should accommodate end to end TSN (time Sensitive Networking) for the proposed decomposition.

Figure 1. Radio protocol stack splits in 5G.

For further details on how to design TSN based (or alternative thereof) 5G fronthaul, please read my book “NextGen Network Synchronization”.

DEMOCRATIZATION OF 5G RAN INFRASTRUCTURE

This concept of 5G fronthaul decomposition is further democratized by O-RAN (later OpenRAN) into composable hardware and software encouraging wider industry participation. If you need clarification on O-RAN and OpenRAN, please read the first article in this series at https://timing.trimble.com/blog/why-is-synchronization-critical-to-5g-networks/ .

The idea advocated by OpenRAN for this notion of decomposition is to break the shackle of vendor locked systems to vendor agnostic systems while bringing in the collective innovation of industry to endow better solutions for 5G fronthaul. In O-RAN/OpenRAN concept (please refer figure 1b), RF and lower PHY of Radio protocol stack is processed in Radio Unit (RU) and Upper PHY to RLC (Radio Link Control) is processed in DU (Distributed Unit) and much of packetization starting at PDCP (Packet Data Convergence Protocol) to layer 3 encapsulation are done at CU (Central Unit). In O-RAN/OpenRAN model of RAN infrastructure, RU is known as O-RU, DU is known as O-DU and CU is known as O-CU.

This concept of RAN infrastructure decomposition is well received by the industry and to date I am observing an increase deployment of O-RAN fronthaul infrastructure concept. The figure below presents a simplified version of RAN network decomposition, In this setup, RU is connected DU over fiber link for which the underlay is Ethernet whether it is for eCPRI or RoE (Radio over Ethernet). Furthermore, DU to CU and CU to 4G EPC or 5G Core are also connected through ethernet link. 

Figure 2. Typical 5G OpenRAN/O-RAN setup.

The synchronization is more stringent for the link between RU and DU, however a recent release of TIP(Telecom Infrastructure Project) OpenRAN memo specifies SyncE between DU and CU. The SyncE (Synchronous ethernet) can be understood as a physical handshake between two clocks residing at two endpoints of a link typical at the NIC (Network Interface Card) or Ethernet Switch. The OpenRAN model pretty much adopted the concept of “Open Networking” for RU, DU and CU. In it, whitebox type of “off the shelf” hardware is used for RU, DU and CU solutions. More specifically, DU and CU utilize standard “off the shelf” servers while the RU may or may not use “off the shelf” servers. Irrespective of how the deployments are done synchronization remains a critical imperative of the network configuration.

O-RAN MODEL FOR SYNC PLANE DESIGN

Synchronization is critical in 5G networks and more importantly in the fronthaul design. O-The RAN alliance has defined four types of S-Plane (Synchronization Plane) configuration modes for timing distribution in the RAN infrastructure. The S-Plane configuration modes are specified in O-RAN Control, User and Synchronization Plane Specification (O-RAN.WG4.CUS.0-v05.00) and mainly addresses sync plane configuration between O-RU and O-DU. These configuration modes are known as follows:

• Configuration LLS-C1 (LLS-C1): This configuration specifies network timing distribution from O-DU to O-RU via point-to-point topology between central site and remote site [1].
• Configuration LLS-C2 (LLS-C2): In this configuration, one or more ethernet switches are allowed for network timing distribution from O-DU to O-RU between central sites and remote sites. The interconnection among switches and fabric topology (for example mesh, ring, tree, spur etc.) are out of scope of this configuration and subject to deployment decisions [1].
• Configuration LLS-C3 (LLS-C3): In this setup, network timing distribution is done from PRTC/T-GM to O-RU between central sites and remote sites. One or more Ethernet switches are allowed in the fronthaul network. Interconnection among switches and fabric topology (for example mesh, ring, tree, spur etc.) are deployment decisions which are out of the scope of O-RAN specification [1].
• Configuration LLS-C4: (LLS-C4): In this configuration local PRTC (Primary Reference Time Clock) provides timing input to O-RU [1].

CONFIGURATION LLS-C1 (LLS-C1)

The LLS-C1 config specifies a point to point link between Radio Unit (O-RU) and Distributed Unit (O-DU). In this configuration, O-RU directly synchronizes with O-DU. Such synchronization can be done using both PTP and SyncE for resilient timing.

Figure 3. The LLS-C1 configuration using Trimble’s timing solutions.

At Trimble, we offer products that provide flexibility and resiliency in sync plane design. For LLS-C1, O-RU vendors can integrate GNSS timing modules such as ICM 360 or ICM720 for single or dual band GNSS based timing solutions to their O-RU. These timing modules provide both 1PPS and 10Mhz as clock output that can be used as stable clock input to O-RU. Alternatively, O-RU Vendor can choose GM310 as an embedded slave clock with GNSS and PTP (IEEE1588) timing capability. Similarly, Trimble GM310 can be integrated in O-DU servers as boundary clock or Grand Master clock providing timing input as needed. If O-DU vendors choose to not have an integrated timing solution, Trimble’s GM200 can be used as an external stand-alone Boundary or Grandmaster clock for this solution.

CONFIGURATION LLS-C2 (LLS-C2)

For the LLS-C2, O-RAN specification suggested using one or more switches in between O-RU and O-DU as shown in the figure below. The specification does not exclusively state the fronthaul switch is PTP aware or unaware and leaves the implementation at the discretion of the user. It is possible to use standard PTP unaware switch to keep cost down while using Trimble’s solutions of ICM360/720 and GM310 as suggested in the figure below.

Figure 4. The LLS-C2 configuration.

If the user prefers to use CSR (Cell Site Router)/DCSG (Disaggregated Cell Site Gateway) type fronthaul switch that integrates a boundary clock, they are most welcome to do so. In that case, CSR vendors are hereby suggested to use Trimble GM310 as ordinary clock for their solution.

Please note that PTP is required for deployment in both LLS-C1 and LLS-C2.

CONFIGURATION LLS-C3 (LLS-C3)

The LLS-C3 configuration specifies that both O-RU and O-DU implement slave clocks and fronthaul switches connected to a grandmaster for clock source. The specification does not state whether the fronthaul switch should integrate boundary clock. For this configuration, it is possible to use PTP unaware switch for single hop count, but a grandmaster clock must be connected to the switch.

Figure 5. The LLS-C3 configuration.

In cases where multiple hope counts are needed, users should deploy the CSR or DCSG type fronthaul switches that integrates embedded ordinary clock (e.g. Trimble’s GM310).  

CONFIGURATION LLS-C4 (LLS-C4)

Similar to LLS-C1, the LLS-C4 is also a point-to-point link but the configuration does not use PTP between O-RU and O-DU. However, the specification suggests the use of Local PRTC for each. Specifically for the O-RU implementation, O-RAN specification recommends the use of additional noise filtering. As depicted in the figure below, O-RU and O-DU integrate local PRTC and not use PTP between them as backup.

Figure 6. The LLS-C4 configuration for local PRTC.

For this configuration, users will find Trimble’s X1 disciplined clock very useful. The disciplined clock provides significant holdover time incase of GNSS failure and at the same time a very stable clock as output. It is an ideal clock device for LLS-C4 configuration.

Reference

1. O-RAN, 2021. Control, User and Synchronization Plane Specification: O-RAN.WG4.CUS.0-v05.00. O-RAN Fronthaul Working Group.