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.
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 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.
Comments