Time synchronization is critical to 5G infrastructure and a 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.

5G spectrums and various bands

Figure 1. 5G spectrums and various bands.

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 into 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. Further details about TSN can be found on the IEEE 802.1 website. The TSN specifies, among other things, time synchronization for fronthaul, time sync for time sensitive applications, QoS, and flow control. While a complete deployment of TSN solution would be difficult until the prices of TSN switch become affordable, the 5GS implementation can be achieved using a combination of boundary clock and edge grandmaster. 

Figure 2. The 5G System (5GS) TSN Architecture.

Figure 2. The 5G System (5GS) TSN Architecture.

Each TSN reference clock shown in the diagram above can be replaced with a cost-effective boundary clock/edge grandmaster like Trimble’s Thunderbolt™ GM200. The GM200 provides TSN profiles for fronthaul synchronization and the same device can act as a 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 the 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.

The 5G System Architecture

Figure 3. The 5G System Architecture.

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

The NG-RAN Architecture

Out of the two main sub-networks of the 5GS, NG-RAN addresses fronthaul and midhaul elements. The backhaul is between NG-RAN and 5GC. Collectively, NG-RAN and 5GC can be deduced as Xhaul (as shown in 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 are examples of how network decomposition is materialized in 5G deployment. 

Visualization of NG-RAN Architecture.

Figure 4. The NG-RAN Architecture.

The O-RAN alliance specified operational and configuration standards extending the concept of 3GPP NG-RAN architecture. Later, the Telecom Infrastructure Project (TIP), initiated by Facebook, extended this defining OpenRAN concept.

O-RAN/OpenRAN initiatives

The idea behind O-RAN and OpenRAN is to create specifications, APIs, hardware, software, and test configurations for vendor-agnostic solutions in 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 facilitates 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 specifications will come in handy to define the interface and configuration.

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.

A Visualization of the OpenRAN and Radio protocol stack split concept

Figure 5. The OpenRAN and Radio protocol stack split concept.

The diagram above merges the concept of NG-RAN and O-RAN/OpenRAN to show how the radio protocol stack is split to achieve network decomposition. The most common split is 7:2 in which RF and LPHY (lower PHY) of the radio protocol stack remain in the 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.

Please note, as suggested in the diagram above (figure 5), the entire split end-to-end requires synchronization, meaning the RU to CU 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 the adoption of the 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.

Typical OpenRAN Deployment

Figure 6. Typical OpenRAN Deployment.

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 in either a single band (ICM 360) or dual-band (RES720) can be inserted into RU and DUs. For this kind of configuration, Trimble offers even better solutions that bring GNSS timing capabilities and PTP into 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 an 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.  

Author: Dhiman Deb Chowdhury