Thinking of deploying Edge Platform in Mobile network?
More specifically, an all-in-one MEC platform that can host diverse applications, starting from IoT to gaming, from 4G/5G core to RAN applications like CU and DU
Then you must know the importance of synchronization features for the platform.
This is a quick guide to the best practices of deploying synchronization in the RAN network and why it is critical to support PTP clocking in the Edge platform.
In fact, accurate time synchronization is so critical for 4G/5G that without it, service performance can degrade considerably.
For example, handover issues, slow throughput, dropped calls, cell sites interfering with each other, are few of the many issues that can happen.
Right synchronization features like PTP/IEEE 1588v2 on MEC platform can help here!
But isn’t GNSS (Global Navigation Satellite System) which is easily available on all radio sites, can provide frequency, time synchronization and phase synchronization.
Correct, but it may not be the optimum approach. On the other hand, combining GNSS with PTP is a better approach. To elaborate on this point, we need to first understand what is PTP?
What is PTP/1588v2?
PTP stands for “Precision Time Protocol”, also known as 1588v2. IEEE defined it in the 1588-2002 standard. It uses packets to transport frequency, time, and phase information in a most efficient and low-cost manner. This protocol works in master slave architecture. To get the time-of-day information (ToD), PTP uses GNSS as a reference.
To understand PTP further, we should understand the main three types of clocks.
Types of PTP/1588v2 clocks
Grandmaster Clock (GM)
It is the primary source of the clock in the network. It then sends the time across the network. A grandmaster clock is also the major distributor of time in the network. There can be multiple GMs in the network for redundancy purpose or if the network is large.
Boundary Clock (BC)
A Boundary clock is both slave and master clock. It takes a timing message in, adjusts for the delay, and then sends a new master clock signal down the network.
Slave Clock (SC)
Other devices that sync to the master’s time are referred as slave clocks. A slave clock cannot synchronize another clock.
There are several other clock types, like ordinary clock and transparent clock. However, for our discussion, it is sufficient to know about these clocks.
As shown below the three clock types create a chain exchanging PTP/1588 packets.
Normally, G.8275.1 telecom profile from ITU-T is used in mobile networks, which requires that every node in the synchronization chain should have BC functionality.
So far, so good.
But let’s go back to our original question. Why do we need PTP when we have GNSS? We can answer this if we know the shortcomings of using the GNSS only approach.
An easy way of synchronization is to use GNSS at all base stations
GNSS is a mandatory source for time/phase synchronization. It is the only source that can provide time of day (ToD). Traditionally, operators have been using primarily GNSS to synchronize their base stations because they want to quickly roll out their services (as shown below), however we see some issues with this approach.
The issue with using GNSS only approach
We see four issues with this topology:
- First, it is NOT OPEX friendly as it needs GNSS on every radio site, and thus requires maintenance for the GNSS antenna and GNSS receiver on every site.
- Second, it is NOT an option for indoor coverage, nor an option for geographical areas that have GPS coverage issues because of the line-of-sight issue.
- Third, it does not have a backup. In case a GNSS receiver fails, a certain site can lose synchronization altogether.
- Last but not the least, GPS spoofing and jamming are not unheard of and thus using GNSS only approach entails security risks. Therefore, it is recommended on reducing the GNSS footprint (we will need it for the time of the day (ToD) information)
Combining GNSS with PTP through PTP aware transport/edge is the best strategy
A better approach (Option 1) would be to implement a PTP source in the network and feed the base stations from the common source. Also, to have a secondary PTP GM as a backup source.
CU and DU sit in the Edge data centers and are normally part of the MEC platforms. Thus, the MEC platforms must support the boundary clock functionality (BC) for this topology. This overcomes almost all the issues described above.
For the operators who still want to use the GNSS at the radio sites, there is an option 2, that keeps GNSS at the radio site, but adds a back GM at the DU site. Here also, the MEC platform should support the PTP functionality.
Conclusion: Edge Platforms must support PTP/1588v2
CU and DU are important pieces of the transport chain of any mobile network and are part of edge applications. The platform where CU/DU are hosted must be PTP aware. It must support the Boundary clock (BC) functionality. Without the BC feature, they cannot take part in the sync chain and hence unable to provide the important clocking needed for the radio stations. Translating it to ITU-T telcom profile, each edge platform must support G.8275.1 as a minimum feature.
Lanner’s HTCA Platform with sync functionality
Lanner’s hyper-converged all in one MEC HTCA platforms HTCA-6600 and HTCA-E 400 provide switch blades to support PTP/ 1588v2, complying with ITU T G.8265.1 and G.8275.1 profiles, suitable for diverse applications such as RAN (CU, DU) CDNs, Anti-DDoS NGFW, BRAS and MEC.
HTCA-6600 comes as High Availability Chassis 6U size with 6 x86 CPU Blades and 6 I/O Blades.
HTCA-E400 is a compact size platform that supports 5x 1U compute sleds or 2x 2U+1U compute sleds with 450mm Short Depth suitable for Edge Deployment.
