Synchronization in democratized 5G RAN Infrastructure?

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

The critical imperatives of time synchronization in 5G networks

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. 

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

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.

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

Figure 4. The NG-RAN Architecture.

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.

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

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

The case for Synchrony in Enterprise 5G deployment

Overlooking the vast waterways of Surma plains in the north eastern part of Bengal delta, I observed a natural phenomenon in my childhood that till date vivid in my mind. As migratory birds flock over the waterways during the twilight of dawn and dusk, they appear to maintain a natural symmetry of forming a sign wave across the distance horizon. The waves of flocks are seemingly phase aligned.

We rarely think about this naturally occurring phenomena when it comes to the design of network infrastructure, yet it is something de-facto in how communications devices work in a synchronicity. Whether a network is homogenous or heterogenous, imperatives of synchronicity cannot be overlooked, nor it can be ignored. Every device in a network from computers to routers, an inherent synchronization is in work by design thanks to the advent of oscillators for local reference and NTP for distributed synchrony. For many of us looking under the hood is not something we do often when it comes to designing the network. However, given the increased applications of time-sensitive transport in different industry verticals, synchronicity can no longer be assumed or overlooked. It is especially true for 5G deployments due to its common use of TDD spectrums in the Radio Access Network (RAN).

Why is Synchronicity important?

Today, an enterprise network is more hybrid, having a mix of homogeneous and heterogeneous applications that are distributed across the network. Let’s take a conventional distributed database system for example. Enterprise can no longer be able to afford having centralized coordination of stateful data scaling out within a centralized data center [1] where specific design assumptions are applied to control the network environment. Even in such circumstances common use of NTP based synchronization no longer serves the purpose of concurrency control. Moreover, enterprises are now on the verge of accepting the reality of edge and the challenges of heterogeneity that comes with it. 

Figure 1. Enterprise network slice with geo distributed database, edge processing and CBRS deployment.

Organizations are global today than ever before, and their operations are geographically distributed. Conventional distributed databases no longer serve the purpose of horizontal scalability, transactional consistency for geo distribution and geographically distributed data residency. The choice is a geo distributed database one that takes into context the complexities of time series data input at the edge, maintains data sovereignty compliance with data residency and transactional integrity [2] of geo-partitioned databases. With this geo distributed database requires a distributed sync plane that maintains highly precision traceable primary clock reference for end to end data-path. Some hyperscalers such as Google have addressed this issue of distributed synchrony with the “true time” API for their geo distributed database service “Cloud Spanner”. While enterprises can leap on solutions such as geo distributed cloud database services, there are numerous scenarios in which having resident geo distributed databases or hybrid solutions thereof are more beneficial. For the later, the importance of distributed synchrony cannot be ignored. Moreover, enterprises need distributed synchrony for many other applications e.g. CBRS and plant operations etc.

Synchrony for Private Enterprise 5G

  Delivering better cellular coverage and network mobility support to geographically distributed enterprise locations provide tremendous benefits to enterprises, from manufacturing to logistics and fleet operations. More of us are familiar with private LTE that has been increasingly penetrating enterprise networks over the last few years. Enterprise 5G a step ahead of private LTE delivering better bandwidth, reliability and inherent support for URLLC infrastructure. Furthermore, enterprise 5G can decide how to manage third-party traffic from operators or other service providers without disrupting its own traffic [3]. Interestingly 3GPP band 48 with a spectrum of 3.5GHz offers a great choice for enterprise 5G solutions. Known as CBRS (Citizen Band Radio Service), this new band offers open access to a 150MHz spectrum for use by enterprises. This service can be obtained by CBRS solutions providers who provide open access to 150MHz by using a scanning service known as SAS (Spectrum Access System) which protects against interference from higher priority users. CBRS uses TDD spectrum and thus requires high precision distributed time sync to deploy CBRS.

Figure 2. CBRS deployment as Enterprise 5G solution.

Some solutions offer a mix of LTE-A and 5G TDD spectrum allowing booth coverage and high bandwidth of up to 300 Mbps. A number of radio endpoints can be deployed in each floor of the corporate building enhancing multiservice transport capabilities over CBRS spectrum. In certain sectors (such as healthcare, hospitality, retail and manufacturing) CBRS is ideal and offers unmatched performance for mission critical applications. However, irrespective of CBRS deployment scenario distributed high precision synchronicity is a must.

Conclusion

Business users are increasingly adopting 5G for a myriad of use cases depending upon industry verticals: smart manufacturing, smart grid, healthcare, hospitality and retails. For this, high precision synchronization is inherent and must be considered beforehand prior to deployment. Moreover, today’s enterprise heterogeneous network cannot ignore the synchrony for many other applications from geo distributed databases to application of machine visions. Given the increasing need for high precision synchrony, a strategy for enterprise network synchronicity should include a clustered approach for secured resilient timing as well as geo distributed synchrony to support a myriad of geographically distributed applications. 

Reference

1.    Section, 2020. The Challenges of Distributed Databases at the Edge. Section.io.

2.    Lamb, C., 2021. The Guiding Principles for Cloud-scale, Geo-distributed Databases. DATABASE JOURNAL.

3.    Paolini, M., 2019. CBRS: Should the enterprise and venue owners care? Senza Fili. 

Addressing 5G Sync Plane Issues

Addressing 5G Sync Plane Issues

As the fronthaul networks are upgraded to support higher bandwidth for LTE Advanced technologies and 5G, MNOs (Mobile Network Operators) are face with unparalleled challenges to comply with stringent requirements for the synchronization or sync plane across the network. We are witnessing paradigm shift in traditional telecom networks that rendering the transport networks in two distinct parts: RAN (Radio Access Network) and Packet core. However, this process of disaggregation of otherwise tightly coupled transport system into two functionally distinct elements is not easy. It requires decoupling of tightly integrated network functions into bite size pieces for processing, improve bandwidth to deliver enhanced human experience and facilitate advanced application services. This transformation in technologies and the implementations thereof requires that timing information distributed in a precisely frequency and phase-aligned networks for advanced applications to function. The problem is that 5G requires precision time distribution due to TDD spectrums and time critical applications. In traditional 4G, time synchronization requirements are not as stringent as 5G and thus reliance on GPS and GNSS is good enough. However, a sync loss in 5G TDD deployment such as CBRS could be disastrous. Similarly, all other time critical applications such as V2X and IIOT etc would suffer catastrophic failure. This implies that 5G network need careful sync plane design, one that cope with GNSS/GPS sync loss and capable of providing high precision time distribution across the network from a PRC (Primary Reference Clock) or Primary Reference Time Clock (PRTC). 

Method of Timing Distribution

The job of a PRTC is to continually sync with Universal Coordinated Time (UTC) and distribute it across the networks. It may use a combination of GPS/GNSS, Atomic Clock or Cesium Clock and timing distribution mechanisms to achieve this. There are several mechanisms to carry timing information throughout the networks that includes SyncE, BITS (Building Integrated Timing Supply), IRIG (Inter Range Instrumentation Group) time code type B (IRIG-B) and 1PPS (1 Pulse per Second). All these technologies are dedicated timing signals requiring a physical connection specifically for timing. One exception is that SyncE can coexist in a physical connection of a packetize network; in other words, same port of an ethernet switch can implement SyncE and transport packets for shared physical link.

Apart from dedicated timing signals, there are other packet base solutions for timing distribution as well, e.g., NTP (Network Transport Protocol) and PTP (Precision Time Protocol). Both protocols require no specific connection for timing and best suited for packetized networks. While NTP is a common time distribution protocol for computer networks and in existence for nearly three decades, PTP (IEEE 1588) is relatively new. It is defined by IEEE 1588 specification in 2002. Since it’s inception, PTP has gained increase attention due to the possibility of achieving sub nanosecond accuracy when used in conjunction with PRTC for primary clock source and SyncE to distribute Timing information.

The following table shows different methods of timing distribution and relative timing accuracy for each. A point to note here is that both NTP and PTP supports TOD, phase and frequency synchronization making them ideal for today’s packetized networks. However, NTP is less suitable for applications and network where sub nano seconds to microsecond accuracy is needed e.g. 5G TDD deployments such as CBRS, mmWave etc.

Table 1. Methods of Timing Distribution.

Table 1. Methods of Timing Distribution.

Note: A network with SyncE (Synchronous Ethernet) and PTP together can achieve sub nanosecond accuracy as evident in white rabbit experiment by CERN.

All time distribution methods should adhere to respective standards e.g. ANSI, Telcordia and ITU-T requirements for PRC (Primary Clock Source) or PRS (Primary Clock source) and time synchronization mechanisms. In a typical deployment, Stratum 1 level clock is considered as PRC/ PRS for the network. A Stratum 1 is part of clock hierarchy level defined by ANSI for which Stratum 0 is atomic clock that provides input to Stratum 1. Where atomic clock inputs are not available, the PRC/PRS may take input from GPS/GNSS or Cesium Clock and a combination thereof as required. At Stratum 2 level, time servers generally get time reference from Stratum 1. The sync plane design should consider respective ANSI and ITU-T standards together for optimal outcomes. It is also useful to define a sync plane that is backward compatible. The figure below shows a relative map between ANSI clock hierarchy and ITU-T recommendations for frequency plane and time/phase plane (e.g. ITU-T PTP profile). 

Figure 1. Clock Hierarchy levels for timing source

Figure 1. Clock Hierarchy levels for timing source

This relative map as presented in figure above is not an exact representation rather an attempt to broaden the understanding of clock hierarchy levels for timing source and distribution. Such understanding will help readership to implement the concept in network synchronization design. For a given network synchronization deployments, e.g. fronthaul, ITU-T recommendations should be understood in two distinct planes: frequency and time/phase. In the frequency plane, a set of ITU-T recommendations defines characteristics of the clock and timing distribution: G.811 & G.811.1 defines PRC and enhanced PRC (ePRC) respectively. 

Figure 2. Timing Distribution and applicable ITU-T standards in frequency and time/phase plane.

Figure 2. Timing Distribution and applicable ITU-T standards in frequency and time/phase plane.

SyncE (Synchronous Ethernet) is a good example of frequency plane timing distribution. Similarly, PTP (a protocol set defined by IEEE1588) timing distribution can be better understood by applying time/phase plane characteristics and requirements set forth in ITU-T recommendations G.8271 & G.8272 etc as depicted in the diagram above. Please note, frequency and time/phase sync planes can be managed and routed independently.

5G Splits and Sync Plane

Implementation of timing distribution is generally done in both frequency and time/phase planes planes due to underlying network requirements. Hence, understanding of the concept is important for 5G sync plane design as such network must be frequency and phased aligned. 5G as defined in 3GPP standards distinctly divides the network concept into two elements: RAN (Radio Access Network) and Packet Core. An obvious indication that packet network will be pervasive in 5G deployments. Even in the deployment of 4G, it is discernable that packetization and penetration of ethernet in fronthaul is increasingly becoming a reality. Packetization and ethernet technologies are fundamental conduit for flexible network configuration, virtualization and improved services.

In 5G deployments, RAN can be deployed in many split options and that is for good reasons: first, it allows easier decoupling of hardware and software. Secondly, network functions can be virtualized and processed in COTS (Common Off The Shelf) servers. These process of decoupling and virtualization significantly reduces CAPEX and OPEX and at the same time removes constraints of vendor locked systems. The concept of decoupling is not new, in fact cloud providers and data centers are benefiting from the implementation of this concept of “disaggregation” or “open networking”. For simplification, decoupling, disaggregation, open networking and whitebox terms are synonymous. For example, the concept of decoupling as in whitebox is implemented through DCSG (Disaggregated Cell Site Gateway), a project of TIP (Telecom Infrastructure Project) to provide telecom service providers a choice of vendor neutral networking solutions. The DCSG aims to replace CSR (Cell Site Router), a vendor locked product that help aggregate cell sites. It is an “open networking” initiative that takes into the benefit of decoupling and vendor neutral approach to help telecom service provider reducing their CAPEX and OPEX for fronthaul aggregation. Similarly, OpenRAN is a project of TIP that aims to decouple basestations or Base Band Unit (BBU). The BBU provides RF (Radio Frequency) processing services to cell towers. While DCSG provides whitebox solutions to replace CSR, OpenRAN initiative create standards for decoupling hardware and software for radio access networks. Both these projects help tremendously in 5G split options deployments.

5G specification allows fronthaul to be created in 8 different split options. Depending upon split options and fronthaul connectivity technologies, time sync requirements slightly differs. For example, for CPRI connectivity PTP is ideal whereas RoE (Radio over Ethernet) implementation requires both PTP and TSN are implemented in different segments of the network. The diagram below depicts four common split options for 5G deployments: option 1 (upgraded 4G), option 2 (5G standalone), Option 7 (dual connectivity) and Option 8 (vRAN/ORAN). For the sake of sync plane discussion, other options such option 3, option 4, option 5 and option 6 are not presented here.

Figure 3. 5G splits and Sync Plane requirement

Figure 3. 5G splits and Sync Plane requirement

One of the major considerations for time sync plane design is time error budget and ITU-T did a great job specifying requirement for complex sync plane design. The ITU-T G.8271.1/Y.1366.1 specifies time error budget or tolerance for fronthaul network which must be adhered while implementing timing distribution. A group of eNB, gNB or RU can form a sync cluster within a basestation cooperating cluster for which Time Error budget should be <260ns. The overall network budget should be <1.5µs (1.1 µs preferred).

Figure 4. Time Error Tolerance consideration for 5G mobile transport (Ref: ITU-T G.8271.1/Y.1366.1).

Figure 4. Time Error Tolerance consideration for 5G mobile transport (Ref: ITU-T G.8271.1/Y.1366.1).

This guidance though helpful, operators must consider time error budget specific to their deployment scenarios considering requirements of ITU-T G.8271.1. For example, despite ITU-T specifying max hop count 5 nodes between GM to basestation cooperating cluster, a Tier 1 decided to deploy maximum of two nodes from T-GM (Grand Master Clock) to T-TSC (Transparent Clock). The operator choose to use ITU- Rec 8275.1for the edge and ITU- Rec 8275.2 for the core in their 5G option 7 sync plane design. Here, coordinated PRTC sync plane was implemented using ITU-T recommendation G.8275.2.

Figure 5. An example of Tier 1 5G option 7 sync plane deployment.

Figure 5. An example of Tier 1 5G option 7 sync plane deployment.

In this scenario, multiple RUs (Radio Units) are connected to DU (Distribution Unit) and DUs are directly connected to CU (Central Unit). The PTP grand master is connected to CU while DU implemented boundary clock. On the backend, PRTC-B and ePRTC coordinated synchronization is used for effective fault tolerance in case of a sync path failure. This deployment is a good example of how operator may choose to decide sync plane design bassed on their own time error budget calculation.

Similarly, deployments for 5G option 8 may requires specific consideration on sync plane since sync cluster span over different segment of network. Here, sync cluster may include vRU (virtual Radio Unit) and other VNF (Virtual Network Function) related to RAN functions. 5G option allows separation of the RF and PHY layers thus splitting sync cluster and extending it over to COTS server as VNF (please refer figure 6).

Figure 6. Typical Sync plane for OpenRAN or ORAN deployment

Figure 6. Typical Sync plane for OpenRAN or ORAN deployment

Option 8 poses great challenge for estimation of sync cluster time error budget and how such deployment manages overall network time error tolerance. Figure above depicts a typical deployment in which vRU and vBBU etc implemented in COTS server for which orchestration and management is done through ORAN controller. For such deployments, COTS server should include HW assisted PTP and embedded GNSS timing input in case a T-GM (PTP Grand Master) is not in each rack. In ideal setup, each rack should deploy a T-GM with GNSS input. Given the price point of T-GM for 16 to 32 clients, putting T-GM at each rack is viable. Trimble provides cost effective GPS/GNSS antenna and PTP grand master that would be useful in such sync plane design.

Summary

ITU-T recommendations for Time error tolerance should be defacto in 5G sync plane design whether in fronthaul or CBRS deployment. Placing a T-GM after one or two T-BC hop away is a great way to design 5G with ample room for time error budget. Given that the price of T-GM in lower client counts is much cheaper, deploying T-GM at CU after one or two hops is a viable and cost effective option. This type of design provides improved time error tolerance for fronthaul. If you are considering 5G sync plane design, please visit http://www.trimble.com/timing for product and solutions offered by Trimble.

Trimble offers an extremely cost effective T-GM, Antenna and GNSS timing module for edge making design of fronthaul sync plane much easier and cost effective. 

Tech Giants joins the fight against dangerous microbe “COVID-19”

Tech giants are thronging to help fight against coronavirus joining the growing numbers of educational and research institute. It is an unprecedented effort in which “corporate america” and research institutes are extending helping hands to government for the war on coronavirus.  A consortium is formed in which IBM, Microsoft, Amazon and Google are now joined by Lawrence Livermore National Lab (LLNL), Argonne National Lab (ANL), Oak Ridge National Laboratory (ORNL), Sandia National Laboratory (SNL), Los Alamos National Laboratory (LANL), the National Science Foundation (NSF), NASA, the Massachusetts Institute of Technology (MIT) and Rensselaer Polytechnic Institute (RPI) pooling together compute powers to fight coronavirus. This public-private COVID-19 High Performance Computing (HPC) Consortium intends to unleash 330 petaflops of computing power for the research on SARS-COV-2 or COVID-19 (the form of coronavirus that caused recent pandemic that infected 300K+ people around the globe).

800 petaflops of computing power to fight the dangerous microbe

This is unparalleled: world have never seen so much compute powers put together for the greater-good of humanity. The dangerous microbe that rendered the world in a grinding halt is about to get it’s dirty secretes revealed. FoldingatHome [1] which uses crowdsource computing resources for scientific research now has over 470petaflops of computing power at it’s disposal to reveal the dirty secretes of the dangerous microbes “COVID-19” [2]. Couple that with the combined computing power of 330 petaflops from the recently formed public-private HPC (High Performance Computing) consortium [3], you get nearly 1.8M cpu cores and 100K of GPU cores and counting. Researchers are encouraged to submit proposal for both FoldingatHome and HPC consortium to bring the best of what they could do with the arsenals of computing powers at their disposal. To submit a proposal for HPC consortium, please visit https://covid19-hpc.mybluemix.net/ .   

“Decisive action from America’s science and technology enterprise is critical to prevent, detect, treat, and develop solutions to COVID-19. The White House will continue to be a strong partner in this all hands-on-deck approach. We thank each institution for voluntarily lending its expertise and innovation to this collaborative effort, and call on the United States research community to put artificial intelligence technologies to work in answering key scientific questions about the novel Coronavirus,” said Michael Kratsios, U.S. Chief Technology Officer, The White House [4].

AI enabled Open COVID-19 Research

While nearly 1.8M CPU cores and 100K of GPU Cores are at work to reveal the dirty secretes of the dangerous microbe “SARS-COV-2 (Coronavirus COVID-19), US president Donald Trump made a call to action through the White House “Office of Science and Technology Policy”  to tech community for lending a helping hand on the machine readable COVID-19 datasets [4]. In response to the call, IBM, Amazon (AWS), Microsoft and Google joined many other research institutes specifically Allen Institute for AI to enlisted AI enabled COVID-19 dataset. The newly formed COVID-19 Open Research Dataset (CORD-19) forum [5] will provide a free AI-enabled open database to global researchers for quicker, surer access to resources relating to coronavirus and how to stop it. CORD-19 takes advantages of AI tools to organize more than 44,000 scholarly articles about the COVID-19 disease and the SARS-CoV-2 coronavirus that causes it [6]. This dataset enables researchers around the world to apply recent advances in natural language processing to generate new insights in support of the fight against this infectious disease [5]. Details about this datasets and other information is available at https://pages.semanticscholar.org/coronavirus-research .

Reference

  1. Innovaxtech, 2020. Lend your CPU and GPU to Crowdsource Computer Networks for the fight against COVID-19. Available online at https://innovaxtech.com/index.php/en/blog-list/technology/cpu-gpu-crowdsource-computer-networks-covid-19
  2. HOTHARDWARE,2020. Folding@home Flexes 470 PetaFLOPS Compute, Surpassing Top Supercomputers In COVID-19 Research Push. Available online at https://hothardware.com/news/foldinghome-flexes-470-petaflops-compute
  3. COVID-19 HPC, 2020. The COVID-19 High Performance Computing Consortium. Available online at https://covid19-hpc.mybluemix.net/
  4. White House, 2020. Call to Action to the Tech Community on New Machine Readable COVID-19 Dataset. Available online at https://www.whitehouse.gov/briefings-statements/call-action-tech-community-new-machine-readable-covid-19-dataset/
  5. CORD-19, 2020. COVID-19 Open Research Dataset (CORD-19). Available online at https://pages.semanticscholar.org/coronavirus-research
  6. GeekWire, 2020. AI2 and Microsoft join the White House’s push to enlist AI for the war on coronavirus. Available online at https://www.geekwire.com/2020/ai2-microsoft-team-tech-leaders-use-ai-war-coronavirus/
  7. FierceHealthcare, 2020.  Amazon, Microsoft launch initiatives to accelerate COVID-19 research and testing. Available online at https://www.fiercehealthcare.com/tech/amazon-microsoft-launch-initiatives-to-accelerate-covid-19-research-and-testing