The three units that comprise Open RAN 5G networks need precise timing to properly interoperate. Standards such as IEEE 1588 dictate what is needed, but it’s up to design engineers to properly implement timing circuits.
5G networks, with their promise of increased bandwidth and improved responsiveness, impose new challenges on equipment designers and network architects. One such challenge comes in the precise synchronization of radios and other network equipment. The move towards open-standard networks, such as Open RAN, means equipment from different vendors must seamlessly interoperate. Timing can make or break that interoperability.
Mobile telecommunications networks can be regarded as being introduced in different generations roughly every 10 years or so. Every new generation supports faster speeds and increased functionality. As Table 1 shows, 5G supports higher bandwidth, faster download speeds, real-time interactivity, and many more connected devices than previous generations. Therefore, it drives more stringent requirements on the wireless network and the timing devices that support it.
|
||||||||||||||||||||||||||||||||||||
| Table 1. Overview of wireless communication evolution. |
When fully implemented, 5G will go well beyond just cell phones.
The ITU report “Minimum requirements related to technical performance for IMT-2020 radio interface(s)” refers to three major use cases:
- Enhanced mobile broadband (eMBB)
- Ultra-reliable and low-latency communications (URLLC)
- Massive machine type communications (mMTC)
Achieving reliable operation by synchronizing the radios in a cellular network has long been a concern, but 5G brings significant new challenges. First, 4G introduced the optional concept of time-division duplex (TDD), which requires time, rather than just frequency synchronization among radios. 5G extends this as a key basis of the network. Second, not only does 5G require time alignment of radios but the precision of this alignment is much greater, at least within local clusters of radios, to support advanced features that enable the demanded high bandwidth and low latency associated with 5G.
IEEE 1588 and 5G
GNSS constellations such as GPS, BeiDou, and Galileo are typically viewed as a means of providing location information; they can also provide precise time and hence frequency too. Traditional cellular networks have used local GNSS receivers to meet their synchronization needs. Everyone from network operators to national governments is becoming more aware that direct reliance on just GNSS, such as using a single local receiver, is highly problematic. Such problems come both in terms of operational considerations such as robust antenna placement and, increasingly, security concerns around intentional or accidental interference.
These issues bring considerable interest in mechanisms that allow the distribution of precise time over the same data network to which radios and other equipment already connect. Such network-based time can function as the sole source of synchronization, or it can combine with a local GNSS receiver for increased redundancy. Although the ultimate source of network time may still be GNSS, the concept mitigates many of the concerns by deploying multiple and geographically separated GNSS receivers. Specified by IEEE 1588-2008 (recently expanded as IEEE 1588-2019), Precision Time Protocol (PTP) has rapidly become the method of choice for network precise time distribution and is a central part of the O-RAN standards for Open RAN [2].
PTP is the protocol that allows for time synchronization from the PTP master (also known as a grandmaster) to the PTP clocks in the network, using PTP messages. The protocol is based on a two-way exchange of timing messages. It provides for the distribution of time from the PTP grandmaster and estimation of the path delay. In today’s networks due to factors such as different fiber lengths, asymmetry in the downstream and upstream routes, and asynchronous network traffic, path delay error estimation must be compensated for to ensure reliable time synchronization of the PTP nodes in the networks to the PTP grandmaster.
To limit the effects of upstream and downstream path asymmetry and packet delay variation (PDV), IEEE 1588 has specified the “boundary clock” (T-BC) and “transparent clock” (T-TSC) functions with PTP message timestamping in the hardware layer. A boundary clock receives the PTP timestamps, adjusts for the delay, and then creates a new master time signal to pass down the network to more devices.
Several ITU-T recommendations — ITU G.8265.1, G.8275.1, G.8275.2, G.8273.2, and G.8273.4 — address time, phase, and frequency synchronization. These recommendations define reference synchronization networks, where the synchronization is generated by time-synchronization masters or PRTCs, which are typically based on GNSS technology and where the reference timing signal is carried across a network of clocks. Frequency synchronization in these reference networks is carried over the physical layer, typically using synchronous Ethernet (SyncE). The time synchronization reference is carried through PTP, where the PRTC is the source of time for the PTP Grandmaster, also known as the Telecom Grandmaster (T-GM).
Two PTP profiles have been defined for the use of PTP in telecom networks: G.8275.1 and G.8275.2
The purpose of the G.8275.1 profile — PTP with full timing support (FTS) from the network — is to meet the highest accuracy, which requires the implementation of an IEEE 1588 telecom boundary and or transparent clock in every node in the timing distribution network. Figure 1 shows an example of FTS.
Figure 1. G.8275.1 FTS uses SyncE to distribute time over the physical layer.
When designing equipment supporting FTS, one key parameter is the class of operation, which refers to one of four performance classes, A through D, defined in ITU-T G.8273.2. As Table 2 shows, Class A has the most relaxed requirements and Class D has the most stringent. Class C is the spec that most, if not all operators, are targeting for 5G fronthaul equipment.
|
||||||||||
| Table 2. Boundary and Transparent clock performance requirements for FTS Networks. |
G.8275.2, which defines PTP with partial timing support from the network, supports service providers who need to operate time/phase synchronization over existing networks. Partial timing support (Figure 2) reduces barriers to entry into LTE-A systems where there are legacy network nodes that are not PTP boundary-clock enabled.
Figure 2. Partial timing support works with legacy clocks.
Assisted partial timing support (APTS) makes use of PTP as a backup for GNSS (Figure 3). It is an important implementation of the G.8275.2 profile.
Figure 3. G.8275.2 APTS network illustration
5G gNB and Timing
Open RAN disaggregates 5G base stations, referred to as gNodeB (gNB), into three logical units: radio unit (RU), distributed unit (DU), and centralized unit (CU).
In a 5G radio-access network (RAN) architecture, the baseband unit (BBU) is typically split into the CU and DU. Fronthaul is between the DU and RU using enhanced CPRI (eCPRI); this is packetized and can be carried over Ethernet with other traffic. 5G fronthaul is made more flexible and scalable by employing eCPRI for control and data and using Synchronous Ethernet (SyncE) and PTP for timing synchronization. This now requires synchronization at the radio unit. Backhaul is the connection between CU and the 5G core (5GC). There is also now a midhaul (MH) connection between the CU and DU. The CU function is typically virtualized, and there is a strong desire to also virtualize the DU. Figure 4 shows how.
Figure 4. 5G networks use SyncE and PTP to transport time from boundary clocks and transparent clocks.
The DUs must synchronize to within 3 µs of each other, meaning that if they use IEEE 1588 from a central time source, then the maximum allowable time error between the source and the DU clocks is 1.5 µs (another DU could be 1.5 µs off in the opposite direction, giving 3 µs error between the two). This can typically be met using PTP over an FTS, PTS, or APTS network.
The fronthaul network timing requirements, on the other hand, are typically much more stringent because they must support advanced radio features such as carrier aggregation and distributed MIMO. In these applications, there can be many RUs connected to one DU and the time alignment between the radios is more demanding. Specifically, there are four classes of radio-to-radio time alignment that apply for all the radios attached to a single DU based on the following requirements:
To support all categories for RU-RU time alignment, the DU and RU boundary clocks must support G.8275.1 FTS Class C or better (see Table 2 Boundary and transparent clock performance requirements for FTS Networks).
In addition to gNB base stations, 5G must support small cells, particularly regarding mmWave and private networks. The term “small cell” is often used loosely with different definitions based on factors such as user capacity or transmit power/coverage area. In the most common definition, a small cell will integrate the functionality of a DU, RU, and potentially CU. This means that small cells connect directly to the core or backhaul network and have synchronization requirements comparable to those of a DU: ±1.5 µs to the source of time. These more relaxed requirements let small cells synchronize using FTS, PTS, or APTS networks.
O-RAN sync overview
The O-RAN Alliance develops standards for the implementation of DU and RU equipment — termed O-DU and O-RU — along with the connectivity between the two. These standards include details of synchronization requirements and implementation.
O-RAN defines four possible topologies for fronthaul network synchronization, LLS-C1 to LLS-C4:
Apart from LLS-C4 (which uses local GNSS receivers for synchronization), IEEE 1588 synchronizes the O-DU and O-RU units (the front haul network) together, either from a time source in the O-DU (LLS-C1,2) or in a switch within the fronthaul network (LLS-C3). The O-DU itself also requires synchronization in real-time, which can be done either using IEEE 1588, or with a local GNSS receiver.
Figure 5. The O-RAN Alliance defines four time-distribution deployment models.
O-RAN networks will likely target category A/B. See Table 3, RU-to-RU (connected to one DU) synchronization requirements. Category C doesn’t support the advanced radio features that are key to 5G, and category A+ is unlikely to be practical or required in the first generation of 5G equipment. To meet these synchronization requirements, O-RAN fronthaul networks will require IEEE 1588 FTS. In other words, if there are one or more switches in the fronthaul network, then they must include T-BC functionality.
|
|||||||||||||||
| Table 3. RU-to-RU (connected to one DU) synchronization requirements. |
Boundary clocks and transparent/slave clocks
As Figure 6 shows, PTP requires multiple hardware and software components working together:
- A low-bandwidth PLL clock device for SyncE wander filtering and jitter-attenuated SyncE frequency generation
- A digitally controlled (DCO) or numerically controlled (NCO) oscillator to allow alignment of the local clock frequency to that of the PTP master
- Time-stampers for ingress and egress Ethernet frames at either the PHY or MAC layer
- A 32-bit time-of-day (ToD) counter to provide the time reference to the time-stampers
- A CPU to run the software components
- A PTP stack implementation and a time and frequency recovery servo
Figure 6. Illustration of the key elements needed to implement a PTP boundary and or transparent clock.
Designers of a PTP-based network need to consider the fact that both hardware and software components must work together. While it might be tempting for hardware and software engineers to work in isolation, with the former often assuming that the latter will integrate open-source software, this often results in an underperforming product and longer development cycles. Instead, engineers should think of designing with PTP as a system-wide effort, with careful consideration being given to how the hardware and software interact. Many hardware component vendors provide PTP software, either fully proprietary or opensource based, to use alongside their hardware and this can considerably lessen the development effort, cost, and time to market.
Conclusion
Accurate time and frequency synchronization across the network is critical for 5G radio performance. 5G applications that require very low latency, including industrial automation and coordinated multi-point (CoMP), will require tight synchronization. With the right hardware and software, system designers can plan on their 5G radios to address synchronization requirements for current and future applications.
Filed Under: 5G, FAQ, Featured, Featured Contributions, Timing
Great article.