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.

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. 

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.

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.

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.

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.

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.

Time synchronization is critical to 5G infrastructure and fundamental conduit of the network. It begins with the very spectrum on which the fifth generation (5G) RAN (Radio Access Network) depends upon. The 5G Radio spectrum uses TDD (Time Division Duplex) as the preferred method of spectrum usage. In TDD, a single frequency is shared for uplink and downlink communications. Given the scarcity of spectrum, TDD allows efficient use of spectrum. That’s not to say that FDD technique of spectrum usage cannot be done in 5G. However, the latter is a rarity and requires two frequencies for communications, an ineffective use of spectrum to say the least.

As depicted in the figure above, much of 5G spectrums use TDD usage technique instead of FDD. The former requires highly precise time synchronization to divide a spectrum in time slots for uplink and downlink communications and more importantly, protect the communications from interference.

Time Sensitive Networking (TSN)

Due to this inherent need for precise time synchronization 3GPP defined TSN (Time Sensitive Networking) as the preferred architecture for the 5G system (5GS). The TSN is defined by a set of standards under IEEE802.1 sub-group. A further detail about TSN can be found at https://1.ieee802.org/tsn/ . The TSN specifies among other things, time synchronization for fronthaul, time sync for time sensitive applications, QoS and flow control etc. While a complete deployment of TSN solution would be difficult until prices of TSN switch become affordable, the 5GS implementation can be achieved using a combination of boundary clock and edge grandmaster. 

Each TSN reference clock shown in the diagram above can be replaced with cost effective boundary clock/edge grandmaster like Trimble’s Thunderbolt™ GM200. You may find details about this product at https://timing.trimble.com . The GM200 provides TSN profiles for fronthaul synchronization and the same device can act as boundary clock or a grandmaster. Understanding the concept of 5GS is important as it implies the need for highly distributed and precise time synchronization to keep 5G network optimized and operational.

The 5G System (5GS)

In addition to specifying TSN as the fundamental conduit of 5GS, the 3GPP also defines the 5GS in mainly two parts: NG-RAN (NextGen Radio Access Network) and 5G core (5GC). It is mainly a packetized network and the penetration of ethernet is increasingly visible. Today, Ethernet found its way to the tower providing enormous bandwidth to Radio Unit (RU) with either eCPRI or ROE ( Radio over Ethernet). The trend of packetization in telecom infrastructure is not new but 5G makes it more consumable.

More importantly, the 5GS architecture also allows network decomposition (or better grouping the network in bite size pieces) relatively easier. This grouping of network elements allows decoupling network functions in a way that eliminates the need for vendor agnostic hardware centric solutions. The buzz word for decoupling of network functions is NFV (Network Function Virtualization), a mouthful but in fact is nothing but treating network function as a n application as you would in the computer world.

THE NG-RAN ARCHITECTURE

Out of two main sub networks of the 5GS, NG-RAN addresses fronthaul elements and midhaul. The backhaul is between NG-RAN and 5GC. Collectively, NG-RAN and 5GC can be deduced as Xhaul (please refer to the figure below). The NG-RAN architecture splits the BBU (Baseband Unit) functions known as gNB (in 5G) in two parts:  DU (Distributed Unit) and CU (Central Unit). Referring back to our conversation on network decomposition, DU and CU is an example of how network decomposition is materialized in 5G deployment. 

The O-RAN alliance ( https://www.o-ran.org/ ) specified operational and configuration standards extending the concept of 3GPP NG-RAN architecture. Later, the Telecom Infrastructure Project (TIP) [ https://telecominfraproject.com/ ] initiated by Facebook extended this defining OpenRAN concept.

O-RAN/OpenRAN initiatives

The idea behind O-RAN and OpenRAN is to create specification, APIs, hardware, software and test configurations for vendor agnostic solutions for which the entire industry can participate and contribute. The former defines standards relating to interface definitions, configurations and other constructs for Xhaul while the latter facilitate industry wide participation and contribution to develop vendor agnostic solutions for 5G fronthaul and midhaul. This distinction is important for readership and designers to better understand O-RAN and OpenRAN concepts. For example, if you are developing or deploying OpenRAN, the O-RAN specification will come handy to define interface and configuration for the said.

The concept of OpenRAN can be further understood considering how 3GPP 5G NG-RAN architecture suggests the split of the radio protocol stack as depicted in the figure below.

The diagram above merges the concept of NG-RAN and O-RAN/OpenRAN to show how radio protocol stack is split to achieve network decomposition. Most common split is 7:2 in which RF and LPHY (lower PHY) of the radio protocol stack remain in Radio Unit and UPHY (Upper PHY) to URLC (Upper Radio Link Control) are processed within DU (Distributed Unit). The PDCP (Packet Data Convergence Protocol) function is performed at CU (Central Unit). Further details about OpenRAN and synchronization information are available in my book, “NextGen Network Synchronization”. I suggest readership interested in synchronization to rent or buy a copy of the book for reference.

Please note, as suggested in the diagram (figure 5a), the entire split end-to-end requires synchronization meaning RU to CU, the designer must consider highly precise synchronization. Recently, TIP specified the need for synchronization from DU to CU and suggested the deployment of SyncE between DU and CU.

Typical Deployment of OpenRAN

There is an increased momentum towards adoption of OpenRAN concept although implementation may vary, much of the OpenRAN design construct remains the same. In it, 3 to 9 RUs are connected per DU and the DUs are connected either directly or through a switch known as CSR (Cell Site Router) or DCSG (Disaggregated Cell Site Gateway) to CU.

Please note, the DU may be able to implement a grandmaster or boundary clock while the RU implements a slave clock. Trimble has a range of solutions for all these devices: a GNSS timing module either single band (ICM 360) or dual band (RES720) can be inserted to RU and DUs. For the said configuration, Trimble offers even better solutions that bring GNSS timing capabilities and PTP in a single embedded board known as Thunderbolt™ GM310. If the configuration of DU requires an external clocking device, Thunderbolt™ GM200 offers two-in-one solutions: boundary clock and grandmaster. Please note, all OpenRAN deployment must consider ITU-T guidelines for end-to-end time error budget of less than 1.1µs.

WHERE DO WE GO FROM HERE?

I am publishing another article that will extend OpenRAN synchronization concept further and will provide guidelines for various sync configuration options for the readership. Until then, if you prefer to learn about 5G OpenRAN Sync and other network synchronization details, please read my book “NextGen Network Synchronization”. The book can be considered a reference guide for the readership interested in synchronization design for various networks.