Introduction
Timing is very important for Radio Access Network (RAN) for error free packet delivery to the Mobile devices and controlling the inter-site interference by keeping SFNs, Transmission and reception in sync. In 4G, traditional RAN usually a BBU (Baseband Unit) or DU (Digital Unit) is equipped with a GPS antenna port to meet the timing and synchronization requirements and all the Cell Site remain sync with GNSS.
While moving to Open RAN or Virtual RAN (vRAN) the DU is not more proprietary hardware, everything is moving to COTS hardware or Cloud Infrastructure. These Cloud based or COTS based hardware usually do not have local source of Timing & Synchronization (e.g. GPS) although may have Hardware Clock (PHC ) which requires timing correction regularly and use a network based Timing Source e.g. IEEE 1588 PTP.
Precision Time Protocol (PTP) provides an efficient way to synchronize time on the network nodes. This protocol uses Master-Slave architecture. Grandmaster Clock (Master) is a reference clock for the other nodes, which adapt their clocks to the master.
The PTP over transport network reaches to the Servers on the NIC (Network Interface) and then kernel and Operating System extract the timing information from the PTP packets and further can be used by different application running on the Serves.
Linux has developed ptp4l, phc2sys and pmc application to manage PTP packets provided on the NIC and driving timing stamps, updating and correcting the hardware clock and maintaining the clock status.
- ptp4l: It means ptp for linux (ptp4l) and it does software implementation of Boundary Clock (BC) and Ordinary Clock (OC) on the hardware node
- phc2sys: It means Physical Hardware Clock to System clock (phc2sys). phy2sys synchronize two or more clocks in the system, typically used to synchronize the system clock to PTP/PHC clock
- pmc – It means PTP Management Client (pmc). It allows ptp 1588 basic management access for ptp4l by sending management messages to PTP nodes.
PTP Implementation in Operating System
In Linux operating system, PTP support is divided between the kernel and user space, for example, the kernel includes support for PTP clocks provided by network drivers (since hardware PTP relies on physical NIC to provide hardware clock. The actual implementation of the protocol is known as linuxptp, a PTPv2 implementation according to the IEEE 1588v2 standard for linux.
Further, linuxptp package includes ptp4l, phc2sys and pmc programs for clock synchronization.
In above diagram, end to end flow is clock is shown, from receiving at the Network Interface Card (NIC) to being used by application in User Space.
- NIC Driver with PTP is a common Linux network driver, which support hardware PTP; we can use ‘ethtool -T <interface_name> to check the PTP capability of hardware NIC
- Network Stack is an implementation of the Precision Time Protocol (PTP) according to IEEE standard 1588v2 for Linux
- ptp4l Linux application implements Boundary Clock (BC) and Ordinary Clock (OC), it synchronizes PTP hardware clock (PHC) to remote master clock
- phc2sys Linux application synchronizes two or more clocks in the system, typically it is used to synchronize the system clock to a PTP hardware clock (PHC)
- System RTC is real time clock generates CLOCK_REALTIME
- KVM virtual ptp driver can helps all the VMs in the same compute node to achieve equal time accuracy by using one ptp capable NIC as time source.
- ptp_kvm.ko is a kernel module in Vritual Machine with gettime method can be able to provide hosts realtime clock. This allows chrony to synchronize host and guest (VM) clocks with high precision.
Other Consideration for Timing in Cloud Environment
Telco Cloud are much more complex and not always have PTP NIC, The NIC port can be deployed with SR-IOV, DPDK technologies and as a Engineer we may need to take more considerations while configuring and using ptp.
- Network Timing Protocol (NTP): In Most of the Clouds NTP is installed by default and when we want to use ptp both have to co-exist, whether feeds PTP source to NTP or vice versa. We shall consider the possible impact on service or components that reply on NTP.
- DPDK: PTP uses PHC (PTP Hardware Clock) framework in kernel network driver to get/set hardware timestamp and adjust hardware PHC time. NIC with dpdk enabled doesn’t use kernel network driver which in turn cannot be used as PTP time source. although dpdk library supports basic time functionalities like get/set methods, we cannot use it without a proper user space program or OVS that interact with these dpdk methods. so whether user should pay attention to this issue during deployment or we should build an isolation on dpdk enabled and ptp enabled NICs.
- SR-IOV: With sriov enabled NICs, user can either choose PF passthrough to get accurate time from PTP or use kvm virtual ptp driver to sync system time to host real time clock. but if one chooses to pass ptp enabled PF to VM, then host and other VMs in the compute node may lost ptp time source if that PF is the only configured ptp interface. So the workaround would be either user is aware of the PTP configuration on sriov PF (Physical Function) and not to attach that PF to any of VMs or we build an isolation during deployment to avoid potential break of the only PTP time source. Another issue with using sriov PF as PTP source is that VF (Virtual Function) cannot share the PHC of PF simply because there is no such hardware resource allocated to VF.
References:
- Sync your cloud with PTP
- Precision Time Protocol on Linux by Fujitsu
Related Posts:
- O-RAN Fronthaul Synchronization Configuration
- IEEE 1588: Precision Time Protocol (PTP) for Telecom Networks
- Virtual machine vs Container
- Hypervisor