Timing & Synchronization in O-RAN
1. Introduction
The Open Radio Access Network (O-RAN) architecture is revolutionizing the telecom
industry by enabling vendor-neutral and flexible network deployments. However, one
of the most critical aspects of O-RAN is timing and synchronization, which
ensures smooth and efficient communication between different network elements,
particularly between the O-RAN Distributed Unit (O-DU) and O-RAN Radio Unit
(O-RU).
Synchronization is essential for maintaining network performance, avoiding
interference, and ensuring seamless handovers in 4G and 5G networks.
2. Why is Synchronization Critical in O-RAN?
a) Avoiding Interference in TDD Networks
Time Division Duplex (TDD) systems rely on precise timing to separate uplink
and downlink transmissions.
A timing mismatch can lead to cross-link interference, affecting network
quality.
b) Seamless Handover and Mobility Support
Mobile users rely on smooth transitions between cells.
Poor synchronization can cause call drops and data packet loss.
c) Fronthaul Delay Management
O-RAN uses an Ethernet-based fronthaul, which introduces packet delay
variation (PDV).
Precise synchronization helps mitigate timing drifts due to transport network
fluctuations.
d) Multi-Vendor Interoperability
O-RAN allows components from different vendors to work together.
Consistent and standardized timing mechanisms ensure seamless operation
across vendors.
3. O-RAN Synchronization Architectures (LLS-C1,
C2, C3, C4)
O-RAN Working Group 4 (WG4) defines multiple Low Layer Split (LLS)
synchronization architectures:
LLS-C1: Synchronization from O-DU
Primary Sync Source: O-DU
How it Works: In this configuration the DU performs as a PTP Boundary
Clock (BC) sourcing the Timing signal from the GM and then directly
connected to the RU to synchronize it.
LLS-C2: O-DU Sync + GNSS Backup
Primary Sync Source: O-DU
Backup Sync Source: GNSS/GPS at O-RU
How it Works: Like LLS-C1 topology, in this configuration the DU performs as
a PTP BC for distributing the network Timing towards the RU. One or more
PTP switches are allowed to be installed in between. These fronthaul
PTP switches may function as Telecom Boundary Clocks as specified by ITUT G.8273.2. Transparent Clock (TC) switches are also allowed as BC
replacement as long as they comply with G.8271.1. The allowed number of
switches is limited by total frequency and time error contributions introdued by
all switches in the chain as specified in Annex H of the O-RAN.WG4.CUS.
This topology requires the support of PTP on all elements on path.
LLS-C3: Independent Sync Network
Primary Sync Source: IEEE 1588 PTP Grandmaster or SyncE
How it Works: O-RU gets synchronization from an independent network, not
from O-DU. Network timing distribution from a PTP Grandmaster located
within the fronthaul network, between DU sites and RUs remote sites. One or
more PTP switches are allowed in the fronthaul network. This widely adopted
topology benefits the most from introducing an integrated PTP Grandmaster
and PTP Switch, which provides the ideal solution for fronthaul timing and
transport.
LLS-C4: Hybrid (O-DU + Sync Network)
Primary Sync Source: O-DU
Backup Sync Source: Independent sync network (PTP/SyncE)
How it Works: O-RU can synchronize with either O-DU or an external sync
network. In cases where the fronthaul transport network is partially or in full is
not upgradable to meeting the target performance at the RU as specified
G.8271.1, a local Timing source option (typically GNSS) is allowed.
4. Timing Protocols Used in O-RAN
To ensure synchronization, O-RAN relies on various industry-standard timing
protocols:
a) Precision Time Protocol (PTP) - IEEE 1588v2
PTP is a packet-based time synchronization protocol that provides
nanosecond-level accuracy over Ethernet and IP networks. It is commonly
used in O-RAN, 5G.
Key Features
o
o
o
o
High precision (sub-microsecond to nanosecond accuracy).
Works over Ethernet, IP, and MPLS networks.
Uses a Master-Slave architecture.
Supports hardware timestamping for enhanced accuracy.
PTP Clock Types
o PTP defines several clock types that participate in synchronization:
Clock Type
Function
Grandmaster Clock Primary time source in a PTP network. Distributes time to all
(GM)
other clocks.
Boundary Clock
Connects multiple PTP domains and forwards
(BC)
synchronization while compensating for delays.
Transparent Clock Measures and corrects delays in network switches to improve
(TC)
synchronization.
Ordinary Clock
Endpoints (e.g., O-DU, O-RU) that synchronize to a
(OC)
Grandmaster or BC.
PTP Synchronization Mechanism
PTP synchronization happens through message exchanges:
1️. Sync Message → Grandmaster sends time information to the slave
clock.
2️. Follow-up Message → Provides more accurate timestamps if hardware
timestamping is used.
If your hardware supports PTP:
o The exchange is called a one-step message exchange, and we
only send a sync message that contains the T1 value.
If PTP is done in software:
o PTP uses a two-step message exchange because of additional
delays.
This means that after the sync message, we send a follow-up
message immediately, including the T1 value.
o The T1 value won’t be in the sync message.
o The follow-up message means, “The sync message you just
received was sent at the time specified in the T1 value”.
3️. Delay Request Message → Slave clock measures round-trip delay.
o
4️. Delay Response Message → Master clock responds with delay
measurement.
5️. Correction Mechanism → Slave clock adjusts timing based on delay
calculations.
Here are the two formulas to calculate these two values:
delay = ((t2 - t1) + (t4 - t3)) / 2
offset = ((t2 - t1) - (t4 - t3)) / 2
In above example, delay = 1sec, offset=10 sec
PTP Profiles Used in Telecom Networks
o ITU-T G.8275.1 (Full Timing Support Profile) → Requires PTPaware network devices (Boundary and Transparent Clocks).
o ITU-T G.8275.2 (Partial Timing Support Profile) → Works over
networks that don’t fully support PTP.
Advantages of PTP
High accuracy for mobile networks (±1.5 µs).
Can work over Ethernet/IP-based fronthaul networks.
Scalable across distributed O-RAN architectures.
b) Synchronous Ethernet (SyncE)
SyncE is an Ethernet-based frequency synchronization technology that
ensures all devices in a network operate on a common frequency. Unlike PTP,
which synchronizes time, SyncE only synchronizes frequency.
Key Features
Provides highly stable frequency synchronization over Ethernet.
Uses physical-layer synchronization (instead of packets like PTP).
Works seamlessly with PTP to improve overall synchronization accuracy.
How SyncE Works?
1️. Clock Distribution → A master clock (e.g., PRC – Primary Reference
Clock) injects a stable frequency into the network.
2️. Ethernet PHY Layer Transmission → SyncE propagates this frequency
across network switches and routers.
3️. Recovered Clock → End devices recover the clock frequency and stay
synchronized.
SyncE Components
Component
Function
EEC (Ethernet Equipment
Clock)
Maintains and distributes frequency
synchronization.
SSM (Synchronization
Status Message)
Ensures proper selection of the best
clock source.
PRC (Primary Reference
Clock)
High-accuracy clock that provides the
initial frequency reference.
ITU-T Recommendations for SyncE
o G.8262 → Defines SyncE architecture and performance
requirements.
o G.8264 → Defines Ethernet Synchronization Messaging Channel
(ESMC) for clock selection.
o G.781 → Specifies the Synchronization Network Architecture.
Advantages of SyncE
o Provides very stable and low-jitter frequency synchronization.
o
Works alongside PTP to improve O-RAN timing accuracy.
o
Supports long-term holdover, preventing network timing failures.
c) Global Navigation Satellite System (GNSS)
Used as a backup synchronization source in LLS-C2 and LLS-C4.
Provides absolute time synchronization.
Why Are Both PTP and SyncE Needed?
Requirement
SyncE
PTP (IEEE 1588v2)
Frequency Synchronization Yes
Yes (indirectly)
Time Synchronization
No
Yes
Phase Synchronization
No
Yes
Layer of Operation
Physical (Layer 1) Network (Layer 2/3)
Accuracy
±16 ppb
±1.5 µs
Effect of Network Load
No impact
Affected by network delays
5. Network Setup for SyncE and PTP
Synchronization
Components Involved:
Grandmaster Clock (PTP GM): Provides the master time reference.
O-DU (Distributed Unit): Acts as a PTP Boundary Clock (BC) and
SyncE source.
Fronthaul Transport Network: Supports both SyncE and PTP-aware
switches (Boundary Clocks or Transparent Clocks).
O-RU (Radio Unit): Acts as a PTP slave and SyncE client.
Synchronization Flow:
1️. Grandmaster Clock (GM) distributes time and frequency to the O-DU.
2️. O-DU forwards SyncE (for frequency) and PTP (for time/phase) to the ORU.
3️. O-RU synchronizes its clock based on received SyncE and PTP
signals.
Example Configuration of PTP (IEEE 1588v2) on O-DU
Assuming a Linux-based O-DU (with ptp4l and phc2sys), the following
commands configure PTP:
bash
CopyEdit
# Enable PTP Hardware Clock (PHC) on Network Interface (e.g., eth0)
sudo ethtool -T eth0
# Configure ptp4l as a Boundary Clock (BC) to distribute time to O-RU
sudo ptp4l -i eth0 -m -f /etc/ptp4l.conf --step_threshold=1.0
# Synchronize the system clock with PTP
sudo phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m
PTP Configuration File (/etc/ptp4l.conf):
ini
CopyEdit
[global]
# General Configuration
twoStepFlag 1
logAnnounceInterval 1
logSyncInterval 0
logMinPdelayReqInterval -2
syncReceiptTimeout 3
delayAsymmetry 0
# PTP Profile
gmCapable 0
priority1 128
priority2 128
domainNumber 24
This configuration sets up O-DU as a PTP Boundary Clock (BC) to
forward time to O-RU.
Example Configuration of SyncE on O-DU
SyncE is configured on the Ethernet interface (e.g., eth0) using hardware
timestamping.
bash
CopyEdit
# Enable SyncE on Ethernet interface
sudo ethtool --set-phy-tunable eth0 sync-e on
# Configure clock source for SyncE
echo "eth0" | sudo tee /sys/class/net/eth0/device/clock_source
# Verify SyncE status
sudo ethtool -m eth0
This ensures that SyncE frequency synchronization is propagated from
O-DU to O-RU.
Example Configuration of PTP & SyncE on O-RU
O-RU must be configured as a PTP slave and SyncE client to receive
synchronization.
bash
CopyEdit
# Run ptp4l in Slave mode to sync with O-DU
sudo ptp4l -i eth0 -m -s -f /etc/ptp4l-slave.conf
# Sync system clock with PTP
sudo phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m
# Enable SyncE on O-RU Ethernet interface
sudo ethtool --set-phy-tunable eth0 sync-e on
PTP Slave Configuration File (/etc/ptp4l-slave.conf):
ini
CopyEdit
[global]
twoStepFlag 1
clockClass 255
priority1 255
priority2 255
domainNumber 24
This ensures O-RU receives PTP time synchronization from O-DU and SyncE
frequency synchronization.
6. Best Practices for O-RAN Synchronization
Deployment
1️. Choose the right topology:
Small-scale deployments → LLS-C1
Reliable sync with backup → LLS-C2
High-precision networks → LLS-C3 or C4
2️. Use boundary clocks and transparent clocks to reduce synchronization
errors over Ethernet transport.
3️. Implement GNSS as a backup source to prevent sync failures.
4️. Monitor synchronization metrics continuously to detect and correct drifts.
7. Conclusion
Timing and synchronization are fundamental to O-RAN networks, ensuring efficient
and stable 5G performance. Depending on deployment needs, different
synchronization architectures (LLS-C1 to C4) can be used, leveraging technologies
like IEEE 1588 PTP, SyncE, and GNSS.
Choosing the right synchronization strategy and implementing best practices will
enable telecom operators to build high-performance, reliable, and scalable ORAN networks.
References:
O-RAN Synchronization Configurations, https://www.fibrolan.com/PTP-Switch
Introduction to Precision Time Protocol (PTP),
https://networklessons.com/cisco/ccnp-encor-350-401/introduction-toprecision-time-protocol-ptp
O-RAN Control, User and Synchronization Plane Specification,
https://specifications.o-ran.org/specifications