White Paper

Altera® SoC FPGAs

Intel® PTP Servo Solutions

Intel® Precision Time Protocol Servo

(Intel® PTP Servo) Solution for Time
Synchronization Applications
Precision Time Protocol (PTP) is used to provide timing for an increasing number of
applications and markets.
Authors "IEEE 1588 is designed to fill a niche not well served by either of the two dominant
Kishan Shenoi protocols, Network Time Protocol (NTP) and Global Positioning System (GPS).
IEEE 1588 is designed for local systems requiring accuracies beyond those
Principal Engineer
attainable using NTP. It is also designed for applications that cannot bear the cost
Hans Brandberg of a GPS receiver at each node, or for which GPS signals are inaccessible." 9
SoC Design Engineer John Eidson (one of the founders of PTP/1588)
Markos Papadonikolakis
SoC Design Engineer
Executive Summary
Jeff Hockert To coordinate the actions of disparate electronic systems potentially dispersed
Sr. IP Technical Marketing Manager around the globe, all these systems must be synchronized in time. Such systems
Bret Gustafson include distributed databases, financial transactions, monitoring and control, and
Strategic Business Developer sensor fusion to name a few.
Intel Corp. A predominant example is that of packet-based communication networks, such
as radio access networks (RANs), which require devices to be synchronized to
function correctly and to provide advertised services. Furthermore, many other
applications rely on underlying communications infrastructure to satisfy their own
synchronization requirements.
Establishing and measuring the level of simultaneity or the temporal ordering of
events requires those events to be timestamped. In turn, these timestamps must
be associated with a common timescale. The problem is ensuring that all devices
Table of Contents forming the network are synchronized to a common “grandmaster clock” with
Executive summary. . . . . . . . . . . . . . . . . 1 sufficient accuracy and precision.
What Is Time, What Time Is It, and Early synchronization solutions employed software timestamping techniques that
Why Do We Care?. . . . . . . . . . . . . . . . . . . 2 could synchronize clocks with millisecond-level accuracy. However, many of today’s
NTP and PTP. . . . . . . . . . . . . . . . . . . . . . . 2 high-end applications demand higher accuracy. The Precision Time Protocol (PTP),
which employs hardware timestamping of packets and can achieve sub-microsecond
O-RAN and PTP . . . . . . . . . . . . . . . . . . . . 4
accuracy, was introduced to address the needs of these applications. Standardized
The S-Plane in O-RANs . . . . . . . . . . . . . 5 by the IEEE, PTP is commonly known as IEEE 1588* or just “1588.”
O-RAN and the ITU-T. . . . . . . . . . . . . . . 7
In the context of these discussions, the term “servo” refers to a software
The Intel PTP Solution. . . . . . . . . . . . . . 8 implementation of a suite of algorithms running on a processor. PTP servos are used
Intel PTP Servo implemented on Intel to synchronize the clocks in devices throughout the network. Many PTP solutions
Agilex® 7 SoC FPGAs . . . . . . . . . . . . . . . 9 are based on open-source implementations of PTP on LinuxPTP* suite, also known
by the name of its PTP engine as ptp4l.
Intel PTP Servo Performance Bench-
marks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Traditional implementations utilizing LinuxPTP employ open-source servos
Intel PTP Servo Value Proposition. . 10 available with ptp4l, but these servos are inadequate for many real-world network
deployments. To address this issue, Intel has developed a proprietary PTP servo
Conclusion. . . . . . . . . . . . . . . . . . . . . . . . 10
that can be used in all cases. The Intel PTP Servo software can be run on Intel Xeon®
Learn More. . . . . . . . . . . . . . . . . . . . . . . . 11 CPU-based motherboards, Intel® SoC FPGAs, and network interface cards (NICs)
References . . . . . . . . . . . . . . . . . . . . . . . 11 with an external digital clock synthesizer (DCS) and 1588 support.
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

This paper gives an introduction into time synchronization discontinuous timescale that is adjusted by leap seconds
using PTP and discusses the roles and relationships between to account for the difference between the definition of the
the IEEE, the Open RAN Alliance (O-RAN Alliance), and the second and the rotation of the earth around the sun.
International Telecommunication Union (ITU), including the
Coordination of actions between disparate entities requires
fact that O-RAN specifications are linked to several ITU-T
all entities involved to be synchronized in time. Even though
recommendations and IEEE specifications.
this property is applicable in a wide range of industries and
It also presents an example hardware implementation of applications, it is most evident in communication networks.
the Intel PTP solution using an Intel SoC FPGA as part of an Such networks require devices to be synchronized to function
O-RAN application. should read: Hardware timestamping is correctly and to provide advertised services. Furthermore,
performed by the Ethernet PHY/MAC functions in the FPGA's many applications utilize communications networks, relying
transceiver chiplets. Also reported is the efficacy of the Intel on the underlying communications fabric as their backbone to
PTP Servo relative to an open-source servo, as determined by establish any required synchronization. As a result, the need
performance benchmarks. for synchronization is becoming ubiquitous.
Almost every application that needs to establish or measure
the level of simultaneity or the temporal ordering of events will
What Is Time, What Time Is It, and Why Do We timestamp those events. Such timestamps must be aligned
Care? for events occurring in geographically disparate locations
Time is difficult to define. As Saint Augustine of Hippo (A.D. around the globe. These applications will fail miserably if the
354-430) famously said: “What, then, is time? If no one ask of timestamping is not associated with a common timescale. It is
me, I know, but if wish to explain to him who asks, I know not.”1 not uncommon for such applications to rely on their underlying
communications networks for this purpose, although other
In the first book of The Hitchhiker’s Guide to the Galaxy by approaches, such as obtaining UTC-traceable time “from
Douglas Adams, one of the characters notes: “Time is an the sky” using GNSS receivers, may also be employed. There
illusion. Lunchtime doubly so.” Although this was intended are many such application examples, including distributed
as an “off-the-cuff” remark, many contemporary physicists databases, multi-media, shared documents, stock trades,
agree that time may well be illusionary. Today, most physicists sensor fusion, multi-player gaming, and monitoring, to name
no longer consider time to be an independent property or a few.
quality and argue that there really isn’t such a thing as space
that contains things and there isn’t really such a thing as time
during which events occur. 2,3 NTP and PTP
At the macro level in which humans exist, of course, time The fundamental concepts underlying packet switching
is experienced as a subjective reality. Following Einstein’s networks were first proposed in the 1960s and deployed in the
publication of the general theory of relativity in 1915, it’s now 1970s. In the early days, various techniques were employed to
understood that time can speed up and slow down in the synchronize clocks in the network elements. Circa 1985, the
presence of cosmological bodies with different masses and NTP, which follows the UTC time standard, was introduced
velocities. This property is exemplified by global navigation to achieve clock synchronization between computer systems
satellite system (GNSS) constellations in which the clocks on over packet-switched, variable-latency data networks.
satellites need to be constantly corrected to account for the
NTP, which is still in use today, is usually implemented using
relativistic effects of their orbits around the Earth.
software timestamping of packets and can synchronize clocks
Our need to know the time and our sociological and with millisecond-level accuracy. NTP is a robust method
technological requirements have evolved. As technology that can be used even over the general internet. However,
grew, so did people’s need to know the time more accurately. millisecond accuracy is insufficient for many of today’s high-
Railroads provide a classic example. In England, up until the end applications, including industrial measurement and
latter part of the 18th century, time was normally determined control systems, financial transactions, sub-sea acoustic
in each town by a local sundial. As a result, the time in a town arrays, and 5G/6G RANs. PTP, which employs hardware
or village could differ by as much as 20 minutes from the time timestamping of packets and can achieve accuracy in the sub-
in London. This wasn’t a problem when traveling between microsecond range, is a natural choice for these applications.
towns and cities on foot or by horse-drawn carriage could
The first version of PTP, standardized by the IEEE and
take days or weeks. However, it did become problematic
commonly known as IEEE 1588 or just “1588,” was published
with the introduction of railroads circa the 1820s and 1830s,
in 2002. The second version was published in 2008, and
when even relatively small discrepancies in time could cause
the most recent version was published in 2019. IEEE 1588
confusion, disruption, and accidents.
includes a profile concept defining PTP operating parameters
Commensurate with advances in timekeeping technologies and options. Several profiles have been developed for
is the need for an agreed-upon standard. Today, one such various applications by the corresponding standardization
entity is known as International Atomic Time (TAI), which is bodies, including telecommunications by ITU, electric power
maintained by the BIPM (Bureau International des Poids et distribution by IEEE/IEC and audiovisual implementations
Mesures [French], a.k.a. International Bureau of Weights and by SMPTE. PTP can potentially synchronize multiple clocks
Measures [English]). TAI is a continuous timescale based to nanosecond accuracy on networks that employ this
on a weighted average of the time kept by over 450 atomic
clocks across 80 national laboratories worldwide. Although
it is based on TAI, Coordinated Universal Time (UTC) is a

2
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

technology. PTP follows the TAI timescale while maintaining a leap-second correction to provide UTC.
The IEEE 1588 standard defines the hierarchical master-subordinate architecture requirements for clock distribution. An
amendment to the current PTP standard called IEEE1588g-2022 advocates the use of “timeTransmitter” for master and
“timeReceiver” for subordinate, but this has not been widely adopted at the time of this writing.
A simplified hierarchical example for telecommunication networks is shown in Figure 1. The primary clock, insofar as the network
is concerned, is the telecom grandmaster clock (T-GM). The time inside the T-GM is derived from an accurate source such as a
GNSS receiver. The T-GM can drive multiple telecom boundary clocks (T-BCs), and each T-BC can drive multiple telecom time
subordinate clocks (T-TSCs). A T-BC may have two aspects: it is subordinate to the T-GM and a master to its T-TSCs.

A T-GM can drive Each T-BC can drive

GNSS multiple T-BCs multiple T-TSCs

M S M S
(a) Pre-synchronization
Grandmaster Boundary Subordinate
Clock (T-GM) Clock (T-BC) Clock (T-TSC)

Synchronization is Synchronization is
GNSS achieved using hardware achieved using hardware
timestamped packets timestamped packets

M S M S
(b) Post-synchronization
Grandmaster Boundary Subordinate
Clock (T-GM) Clock (T-BC) Clock (T-TSC)

Figure 1. High-level representation of a simplified PTP hierarchy.

There may be many more layers to the hierarchy than are PTS implementation, wherein one or more devices are PTP-
shown here, such as T-BCs driving T-BCs, but these will be unaware.
omitted from this paper for simplicity. Furthermore, telecom
A master and its subordinate both contain digital clock
transparent clocks (T-TCs) are not shown here, which are
synthesizer (DCS) and time-of-day (ToD) functions that they
devices that don’t contain clocks themselves, but instead
employ to keep track of the current time. The ideal goal is to
update the timestamps on packets as they pass through the
have the ToD stored in a subordinate exactly match the ToD
device with appropriate transport delays associated with the
device. stored in its master.

Between any master and subordinate, a network of switches Both NTP and PTP achieve synchronization through the
and/or routers can exist. In PTP for telecom parlance, exchange of timestamped packets. To achieve the highest
the network may provide full-timing support (FTS) or possible levels of accuracy, all packets should be timestamped
partial-timing support (PTS). In the FTS case, whereby all as physically close as possible to the interface between
intervening network elements are PTP-aware, minimal the network device and the network channel. The simplest
packet delay variation is experienced by the timing packets. exchange involving three packets is depicted using PTP
By comparison, packet delay variation can be substantial in a terminology in Figure 2.

Master Subordinate
ToD DCS ToD DCS

MAC/PHY PHY/MAC

Sync_M
Timestam essage
ped packe
Time t1 t

Time t2
uest
Delay_Req ac ket
mped p
Timesta Time t3

Time t4
Delay_R
esponse

Figure 2. High-level visualization of PTP packet exchange between master and subordinate.
3
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

At time t1, the master initiates the exchange by transmitting a variation. There’s also the drift problem over time in the
Sync_Message packet to the subordinate. This packet contains subordinate’s local oscillator. However, it's possible to achieve
a timestamp of t1 representing the time-of-departure of sub-microsecond synchronization by continually exchanging
the packet from the master. When the subordinate receives packets and employing sophisticated algorithms running in
this packet, it augments the original timestamp with its own the subordinate.
timestamp of t2, representing the arrival time. The value (t2
Other aspects of the network may also change over time.
– t1) is the sum of both the master-subordinate transmission
Existing devices may be replaced, new devices may be added,
delay (∆MS) and the subordinate’s time offset from the master
and legacy devices may be removed. Furthermore, the current
(OFM). The OFM is the “error” in the subordinate’s clock.
trend to virtualizing network functions adds an additional layer
In the past, primarily due to limitations in the hardware, it of complexity. For all these reasons, timing synchronization is
was challenging to embed the t1 timestamp in the outgoing an ongoing process.
Sync_Message packet on the fly. To overcome this problem,
One final point is that people often confuse synchronization
PTP allows for a "two-step" mode whereby the precise value
with delay and latency. In many systems, such as 5G radio
of t1 is conveyed in a Followup_Message (not shown here),
networks, there’s a desire to minimize delays and latencies
transmitted after the Sync_Message. Recent advances in
between two communication endpoints, but this has
hardware – for example, the F-Tile transceivers in Intel SoC
nothing to do with synchronization per se. The only goal of
FPGAs – mean the t1 timestamp can be embedded in the Sync_
synchronization is to ensure that the value of the ToD clock
Message packet on the fly. In PTP parlance, this is referred to
in any subordinate matches the value of the ToD clock in that
as a "one-step" mode.
subordinate’s master, and this is true from the lowest level
The subordinate regularly sends a Delay_Request packet back subordinate up the hierarchy to the grandmaster clock.
to the master. In addition to the original t1 and t2 timestamps,
the subordinate stores a timestamp t3 representing the
time-of-departure of the Delay_Request packet from the O-RAN and PTP
subordinate. When the master receives this packet, it records
as t4 the timestamp representing the time-of-arrival. The Since the demand for mobile communications is growing
master responds by sending a Delay_Response packet to the dramatically concerning the number of users and the amount
subordinate. This packet contains t4 , and thus the subordinate of data each user consumes and generates, our focus will now
now has all four timestamps (t1, t2, t3 , and t4). The value (t4 – turn to PTP implementations in the context of RANs.
t3) is recognized as the difference between the subordinate- The Open RAN Alliance or O-RAN Alliance4 is a worldwide
master transmission delay (∆SM) and the OFM. community of mobile network operators, vendors, and
Assuming the transmission delay is symmetric (i.e., ∆SM = research and academic institutions that is dedicated to
∆MS), then the subordinate can compute its OFM from these evolving radio access networks into being smart and open.
four values as well as the one-way delay, or time-of-flight As connectivity demands and the number of connected
(ToF), of the time-stamped packets. devices are growing, so is the necessity for a flexible RAN
This is not a “one-and-done” process. For example, since this is architecture. An Open RAN (O-RAN) is a non-proprietary
a packet-based network, there is no fixed delay path between implementation of a RAN that allows interoperability between
the master and the subordinate, which means different cellular network equipment provided by different vendors.
packets can take different routes and traverse different As the O-RAN Alliance defines the typical 5G RAN, the base
devices, thereby taking different durations to traverse the station is split into three logical nodes—the O-RAN radio unit
network. Even with a fixed route, the packets may encounter (O-RU), the O-RAN distributed unit (O-DU), and the O-RAN
queues in routers and switches that introduce packet delay central unit (O-CU). This is depicted in Figure 3.

5G O-RAN User
Equipment

Core Central Distributed Radio

Network Unit Unit Unit UE
Backhaul Midhaul Fronthaul
CN O-CU O-DU O-RU

Multiple O-CUs can be Multiple O-DUs can be Multiple O-RUs can be UE

connected to a CN connected to a single O-CU connected to a single O-DU

Figure 3. High-level visualization of a 5G O-RAN.

4
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

Simply put, O-RUs are where the conversion between digital The 3rd Generation Partnership Project (3GPP)5 is an umbrella
and analog RF takes place; O-DUs are where much of the real- term for a group of standards organizations developing
time signal processing is implemented; and O-CUs are where mobile telecommunications protocols. The O-RAN Alliance
the timely, but not quite real-time, processing such as call- has adopted several key timing requirements from the 3GPP
control is performed. related to time alignment error (TAE). As discussed in 3GPP
TS 38.133 and 3GPP TS 38.104, these requirements state that
The fronthaul interface between an RU and a DU, typically
the relative time error (i.e., the TAE) between two antennas
implemented using an Ethernet network, is the most
of a cluster must be less than 130 ns; furthermore, that the
bandwidth-intensive and time-sensitive portion of a 5G
error between any two antennas in general, must be less
O-RAN. In the case of pre-5G telecommunications standards,
than 3 μs. It is common to consider the time at the network's
timing synchronization was often treated as an afterthought
core, essentially a primary reference time clock (PRTC), as the
and effectively “shoehorned” in after the fact. By comparison,
time reference for the subtending wireless network. It is also
in addition to the management plane (M-plane), the control
common practice to allocate one-half of the TAE allocation to
plane (C-plane), and user plane (U-plane), the O-RAN
each path between two endpoints and the common source.
specification for the fronthaul interface also includes a
synchronization plane (S-plane), which embraces the To ensure interoperability among O-RU vendors, O-RAN
collection of requirements about timing and synchronization. characterizes the timing synchronization capabilities – in the
form of maximum absolute time error (|TE|) – of an ORAN
O-RU in a way that is compliant with both classes defined in
The S-Plane in O-RANs the enhanced Common Public Radio Interface (eCPRI) and
Delivering the high data rates promised by 5G necessitates an IEEE 802.1CM standards. Based on these standards, O-RAN
architecture whereby multiple network stations communicate specifies two O-RU timing synchronization classes: a regular
simultaneously with the user equipment (UE). To complete O-RU with |TE| ≤ 80 ns and an enhanced O-RU with |TE| ≤ 35
this complex task, sophisticated signal processing is involved. ns (the O-RU time error accumulates as other contributors
In practice, combining the signals from two radio units (RUs) is are added to the network). These two classes correspond to
effective only if the RUs involved in the collaborative exercise Cases 1.1 and 1.2 (Section 6.4.1 of IEEE 802.1CM), respectively,
are tightly synchronized.7 where the PTP T-TSC clock is integrated in the enhanced Radio
Equipment (eRE).
O-RAN specifications recognize that timing is a critical part of
wireless systems. The S-plane addresses these requirements. With respect to the O-RAN specifications8 (Table H.2, ORAN-
Of special importance is the timing that is implicit at the very WG4.CUS.0-v07.00.01), an enhanced O-RU can be deployed in
edge of the network, which is—in wireless systems—the networks of Categories A, B, and C as defined in Section 4.2 of
antenna of the RU. The timing properties are measured for Requirements for the eCPRI Transport Network V1.2. Hence,
specificity at a hypothetical reference point corresponding targeting and meeting the timing requirements of a Class C
to the air interface. The electrical signal in the antenna T-TSC, per ITU-T G.8273.2, is adequate for O-RU deployment
element(s) is converted to an analog radio frequency (RF) in any Category A, B, or C network. This is illustrated in Figure
signal and vice versa. It is quite common to have an electrical 4.
test point in the RU that embodies the signal's necessary
timing and synchronization properties at the air interface.
The conventional timing reference is a 1 pulse-per-second
(1PPS) signal, whose electrical and physical characteristics are
defined in the ITU-T G.703 recommendation.

Legend
PRTC: Primary Reference Time Clock (ITU-T G.8272. G.8272.1)
T-GM: Telecom Grand Master (ITU-T G.8272)
T-BC: Telecom Boundary Clock (ITU-T G.8273.2)
T-TSC: Telecom Slave Clock (ITU-T G.8273.2)
CU: Control Unit (O-RAN)
DU: Distributed Unit (O-RAN)
RU: Radio Unit (O-RAN)
|TEL|: Absolute Low Pass Filtered (0.1 Hz) Time Error

T-TSC

PRTC T-GM
M

M
O-RU UNI

Local PRTC
PRTC O-RU
O-CU
T-BC Relative Time Error between O-RU UNI
|TE|relative ≤ 100 ns (Cat. B, Case 1.1)
S
Fronthaul S |TE|relative ≤ 60 ns (Cat. A, Case 1.2)
T-TSC (Requirements for the eCPRI Transport Network V1.2 )
Midhaul M

S M Remote PRTC S
T-BC
T-GM M

Time Error Budget for Fronthaul

O-RU UNI

±100 ns O-DU |ΤΕL|≤ 95 ns, if using regular O-RU

ITU-T G.8272 |ΤΕL|≤ 140 ns, if using enhanced O-RU O-RU
(ORAN WG4.CUS, Table 11.3.2.1-1)

|ΤΕL|≤1325 ns (ORAN WG4.CUS, Table 11.3.2.1-1)

Time Alignment Error between antennas
TAE ≤ 260 ns (Cat. B)
|ΤΕ|≤ 1100 ns (Requirements for the eCPRI Transport Network V1.2) TAE ≤ 130 ns (Cat. A)
(3GPP TS 38.104)
|TE| ≤ 1500 ns (ITU-T G.8271, Accuracy class 4)

Figure 4. TAE requirements in O-RAN architectures.

5
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

In addition to adhering to 5G standards, many RANs must support legacy 4G infrastructure. For example, 4G radios typically
employ the CPRI for their fronthaul transport, whereas 5G radios typically use eCPRI. In cases where the network must
accommodate both 4G and 5G infrastructure, a device called a fronthaul gateway (FHGW) is often used to perform CPRI to
eCPRI conversions, including the lower L1 signal processing, which include fast Fourier transform (FFT) and Physical Random
Access Channel (PRACH) functions.
With respect to synchronization in the fronthaul, the O-RAN Alliance has identified four low-level split (LLS) configurations
called LLS-C1, LLS-C2, LLS-C3, and LLS-C4. This is illustrated in Figure 5.

LLS-C1: LLS-C3:

GNSS GNSS

PRTC/ PRTC/
T-GM T-GM
Sync Flow Sync Flow

Direct Ethernet Link Fronthaul

O-DU O-RU O-DU Network O-RU
Carrying PTP/SyncE

LLS-C2: LLS-C4:

GNSS GNSS GNSS

PRTC/ PRTC/ PRTC/

T-GM T-GM T=GM Sync Flow
Sync Flow
Sync Flow

Fronthaul Fronthaul
O-DU O-RU O-DU O-RU
Network Network

Figure 5. O-RAN LLS-C1, LLS-C2, LLS-C3, and LLS-C4 configurations.

LLS-C1 involves a point-to-point connection between the DU In practice, all of this means that the grandmaster, master, and
and the RU where the DU is the PTP synchronization source subordinate clock elements embodying a PTP synchronization
for the RU. LLS-C2 extends things further, in that Ethernet solution must be capable of being deployed anywhere in
switches are included between the DU and the RU, and these the O-RAN infrastructure, including the O-RUs, O-DUs, and
switches may also act as PTP T-BCs (or T-TCs as discussed in FHGWs.
the next section). In the case of LLS-C3, the T-GM is a distinct
device and timing entity included in the fronthaul network,
distributing timing to both the DU(s) and the RU(s). Finally, in
the case of LLS-C4, the O-RU receives its timing and frequency
references locally (e.g., by utilizing a directly connected GNSS
receiver) and independently from the fronthaul and the O-DU.

6
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

O-RAN and the ITU-T

As one of the oldest international organizations still in operation, the International Telecommunication Union (ITU)6 is a
specialized agency of the United Nations responsible for information and communication technologies. The ITU comprises
three sectors or branches: development ( ITU-D), radio communication (ITU-R), and standardization (ITU-T). In addition to radio
access networks, many other industries derive their standards based on ITU recommendations.
O-RAN specifications are linked to several ITU-T recommendations and IEEE specifications. As many as 18 ITU-T recommendations
are included in O-RAN by reference. The methodology of delivering the appropriate timing to the RU is based substantially on
the G.826x and G.827x families of ITU-T recommendations. A summary of the ITU-T recommendations invoked by O-RAN is
provided in Table 1.

ITU Recommendations Reason for Referencing in O-RAN Specifications

Describe the PTP profiles that should be used for full timing support (FTS) networks and partial timing
G.8275.1 and G.8275.2
support (PTS) networks, respectively.

Describe the network limits for FTS and PTS networks, respectively. One important piece of information
found here is the definition of the reference points A, B, C, and D, of which B and C are of specific interest in
G.8271.1 and G.8271.2 the O-RAN context. For example, the O-RU UNI corresponds to reference point C in LLS-C2. The “network
limits” means the “noise” an O-DU or an O-RU can expect on its input and that it needs to handle while
meeting the requirements on the output.

Describes the timing characteristics of a PRTC and the PRTC combined with a T-GM. G.8272.1 establishes
G.8272 more stringent requirements for an enhanced PRTC (ePRTC). This is relevant for an O-DU with local
synchronization.

Describe the timing characteristics of a T-BC and T-TC, respectively, that are deployed in fronthaul networks
with full timing support. G.8273.2 also describes the timing characteristics of the T-TSC which is the fronthaul
G.8273.2 and G.8273.3 endpoint in the O-RU and the midhaul endpoint in the O-DU. It’s worth pointing out that an O-DU is not a
T-BC. G.8273.2 also defines four classes of T-BC with different requirements on timing accuracy. For the most
stringent Enhanced O-RU specification the Class C (max|TE| < 30 ns) subordinate suffices.

G.8273.4 Describes the timing characteristics of a T-BC and a T-TSC in a fronthaul network with partial timing support.

Describes a network architecture in Appendix III where the PTP profiles of the midhaul and the fronthaul are
G.8275
different, specifically if one is FTS and the other is PTS.

Provides definitions of a variety of metrics. Section 3.1.20 defines some of the time error measurements used,
G.8260
specifically Max|TE|, cTE, and dTE.

Describes the architecture for Synchronous Ethernet (SyncE). Appendix VI provides guidance on test
G.8261
conditions for networks that do not have full timing support.

Define the jitter and wander requirements to which all network equipment in the fronthaul supporting SyncE
G.8262 and G.8262.1
(and enhanced SyncE) should comply.

G.8264 Defines the ESMC format that should be used for SyncE.

Defines the quality levels used in the synchronization status message (SSM) signaling over Ethernet slow
G.781
message channel (ESMC).

Defines some basic measurement concepts used, specifically fractional frequency offset (FFO) and maximum
G.810
time interval error (MTIE).

G.811 Defines a PRC, which is an allowed clock type in the fronthaul.

Table 1. ITU-T recommendations used in O-RAN CUS specifications.

7
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

The ITU-T considers two principal cases of network • Any filtering must meet the air interface's ±50 ppb
architecture referred to as FTS and PTS. These architectural frequency offset requirement. Traditional wireless has
concepts were briefly mentioned in the NTP and PTP always had a 50 ppb requirement, but 5G/O-RAN specifies
discussions earlier in this paper. this requirement over a short observation interval of 1 ms.
In an FTS architecture, every device between a master clock • Any additional filtering necessary to suppress wander in
and a subordinate clock must be PTP-aware and participate the physical layer to meet the Max|TE|antenna time-error
in the protocol. That is, each device must be either a T-BC requirement.
or a T-TC. The intent is to defeat the packet delay variation
• Any filtering necessary to defeat packet delay variation
introduced by queues in packet-switching schemes, but T-BCs
if the fronthaul network has one or more PTP-unaware
and T-TCs achieve this differently. T-BCs act like “relays” by
devices (i.e., the PTS model).
providing a subordinate function upstream and relaying the
synchronized time downstream. T-TCs modify a correction • Support for O-RU cascade mode operation.
field in the timing packet as it traverses the device by an
amount equal to the residence time of the packet in the device.
The Intel PTP Solution
As was noted earlier, IEEE 1588 provides for the tailoring of
In the context of these discussions, the term “servo” refers to
PTP to its deployment environment via the use of profiles.
a software implementation of a suite of algorithms running
The ITU-T has defined a profile for FTS in recommendation
on a processor. The servos running in subordinate clocks use
G.8275.1. It should be noted that, whereas the ITU-T considers
timestamps to establish the correct time relative to the master
physical layer frequency synchronization (PLFS) as optional,
clock, even when individual packets experience transmission
in O-RAN it is assumed that the FTS architecture includes
delay variation.
PLFS in the form of SyncE.
For implementing PTP, Intel utilizes the open-source
By comparison, in the case of a PTS architecture, there may
LinuxPTP suite, which includes the ptp4l protocol engine.
be one or more PTP-unaware devices between a master clock
Traditional implementations utilizing LinuxPTP employ open-
and a subordinate clock. As a result, there could be substantive
source servos available with ptp4l. These servos are more
packet delay variation that must be accommodated by the
than adequate for many real-world network deployments
subordinate. The ITU-T has defined a profile for PTS in ITU
implemented using a FTS architecture. For example, the
recommendation G.8275.2.
Intel O-RU Enablement Package itself employs one of these
O-RAN prefers that the fronthaul and midhaul networks follow servos. Having said this, these servos don't provide any
the FTS model, which however is a more costly implementation. protection against the high levels of jitter experienced in PTS
The specification also includes a more realistic and practical network architectures. For these cases, Intel has developed
approach in that the requirements include the recognition a proprietary PTP servo that can be run on Intel SoC FPGAs,
that, for various reasons, fronthaul and/or midhaul networks Intel Xeon® CPU-based motherboards, and network interface
may, in practice, fall into the PTS category. cards (NICs) with an external digital clock synthesizer (DCS)
and 1588 support. Furthermore, this servo also has extensions
O-RAN borrows from ITU-T Rec. G.8273.2 for the T-TSC based that allow the device to operate as a T-GM when provided
on the assumption that the fronthaul network follows the with an external time reference, such as GNSS. It’s important
FTS model. However, in O-RAN documentation, the asterisk to note that users can take full advantage of the Intel PTP
shown in T-TSC* indicates that: “additional noise filtering to timing solution without making any changes to their LinuxPTP
meet 3GPP may be required.” This additional filtering could installation. An illustration of the PTP software architecture
include: utilizing the Intel PTP Servo is shown in Figure 6.

Linux
Shell (CLI)

Servo Package (Binary)

ESMC
USER

Timestamps pushed to custom

State m/c pmc ts2phc phc2sys ptp4I servo via UDS socket Intel PTP
Servo

Ethool Linuxptp 3.1.x (unmodified) IP Stack

(user) HAL
Socklib
UDP/TCP
System calls (Devfs, ioctls)
IP DCS Driver
Ethernet
DCS Init, DCO Adjustment
Kernel

Kernel clock related modules, utilities

Ethernet /dev/spidev
RTC /dev/ptp[x] /dev/spidev
Driver
Ethtool Driver (char driver) (net driver) Register access (serial)

MAC Time Corrected Clock

HW Stamper DCS
GNSS (with Support)
Clock, PHC
HW

Receiver
RTC Recovered Clock
PHY OCXO

Network

Figure 6. PTP software architecture using the Intel PTP Servo. 8

White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

The Intel PTP Servo software can run on Intel Xeon CPU- programmable fabric, while the Linux kernel and PTP
based motherboards, Intel SoC FPGAs, network interface software, which includes the Intel PTP Servo, run on the
cards (NICs), and many other platforms with external DCS and FPGA’s hard processor subsystem (HPS). Using the timestamps
1588 support. encapsulated in the S-plane packets, the servo establishes the
correct time-of-day and determines any phase and frequency
An example hardware implementation of the Intel PTP timing correction factors that must be applied to the ToD function
solution using an Intel SoC FPGA is illustrated in Figure 7. and the board-mounted DCS device. DCS devices suitable for
Hardware timestamping is performed in the Ethernet PHY/ O-RAN applications are available from multiple suppliers, and
MAC functions. The packet filter, direct memory access the Intel PTP Servo can work with any suitable device.
(DMA), and ToD functions are all implemented in the FPGA’s

Printed Circuit Board (PCB)

Hardware timestamping Intel® SoC FPGA
takes place within the
Ethernet PHY/MAC functions
FPGA Fabric
eCPRI O-RAN
Linux Kernel
IP IP
+ LinuxPTP (ptp4I)

PHY/MAC
PHY/MAC

Ethernet
Ethernet

C/U/S/M packets + Intel PTP Servo

C/U Packets

Packet DMA
HPS
Filter Tx/Rx

S/M Packets Phase

offset
ToD

ToD 1588 Clock

HPS = Hard Processor Subsystem Frequency

SyncE offset
DCS ToD = Time of Day DCS
DCS = Digital Clock Synthesizer

Master Subordinate

Figure 7. Example PTP hardware architecture with the Intel PTP Servo running in an Intel SoC FPGA.

This example shows eCPRI and other O-RAN intellectual Intel PTP Servo implemented on Intel Agilex 7
property (IP) functional blocks implemented in the FPGA’s
SoC FPGAs
programmable fabric. These functions would be replaced
with other IP functions depending on the target application, As illustrated in the previous section, one possible Intel PTP
such as industrial measurement and control systems, financial timing solution implementation is based on Intel devices
transactions, and sub-sea acoustic arrays. such as Intel Agilex 7 SoC FPGAs. These devices provide the
extreme capacity and performance demanded by applications
Once again, it’s important to remember that this is just one like O-RANs, the network core, and data centers. Intel Agilex 7
possible implementation example. The same servo software FPGA F-Series and I-Series are built on the Intel 10 nm SuperFin
can be run on NICs, on Intel Xeon CPU-based motherboards, process technology, depicted in Figure 8. The F-Series devices
and many other platforms with external DCS and 1588 are targeted at a wide range of high-end applications, while
support. the I-Series devices are intended for bandwidth-intensive
applications.

Figure 8. Example members of Intel Agilex 7 SoC FPGAs

9
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

The Intel Agilex 7 family includes FPGAs and SoC FPGAs. Both support hard interfaces in their fabric for external DDR4 memory
and include a secure device manager (SDM). SoC FPGAs also include a hard processor subsystem (HPS).
A chiplet, also known as a “tile,” is a small integrated circuit die containing a well-defined subset of functionality. In addition to
the main FPGA die, Intel Agilex 7 devices contain two to six transceiver (XCVR) tiles. These XCVR tiles are connected to the main
FPGA die using Intel embedded multi-die interconnect bridge (EMIB) technology, an elegant and cost-effective approach to the
in-package high-density interconnect of heterogeneous chips. The result is that the chip and chiplets combine as a single large
die.
Intel Agilex 7 SoC FPGAs support multiple types of XCVR Tiles, including E-Tiles, F-Tiles, P-Tiles, and R-Tiles. Different members
of the Intel Agilex family provide different combinations of these tiles. In addition to various general-purpose input/output
(GPIO) and high-speed SerDes interfaces, F-Tiles can support up to 400 Gbps Ethernet. Similarly, in addition to a range of other
GPIO and high-speed SerDes interfaces, R-Tiles can support PCIe* Gen 5 and Compute Express Link (CXL) interfaces.
Of particular interest in the context of this paper is the fact that both E-Tiles and F-Tiles support PTP hardware timestamping
with an accuracy of ±1.5 ns (for 10 – 100 GbE line rates) and in combination with Intel PTP Servo provide a Class-D (ITU-T
G.8273.2) capable solution.

Test Case FTS (G.8273.2, Noise Gen) PTS (G.8271.2) Without Support (G.8261, TC12)

Intel PTP Servo ptp4l PI Servo Intel PTP Servo ptp4l PI Servo Intel PTP Servo ptp4l PI Servo

|TE| <5 ns <5 ns 1 μs 138 μs 4 μs 85 μs

Table 2. Comparison of 1PPS absolute time error measurements between Intel PTP Servo and ptp4l

Intel PTP Servo Performance Benchmarks Intel PTP Servo Value Proposition
The efficacy of the Intel PTP Servo relative to an open-source Some of the key benefits of the Intel PTP Servo are:
servo is depicted in Table 2. The maximum absolute time error
• Architecture designed to support O-RAN (FTS and PTS).
is shown for three cases: FTS, where there is essentially zero
packet delay variation, and two cases of PTS for different • Superior performance in PTS and networks without
levels/types of packet delay variation. timing-support relative to the ptp4l PI Servo.
Concerning FTS, it’s important to note that the requirement in • DCS-agnostic solution.
the CPRI specification is ±8.138 ns. Observe in Table 2 that the
Intel PTP Servo achieves less than 5 ns. • Support for the open-source ptp4l solution vs. competing
proprietary solutions with DCS lock-in.
The most challenging situation for the O-RU is if the fronthaul
is of an LLS-C2 configuration with PTS. This can be tested by • Portable timing solution scaling across current and future
applying noise to the input of the O-RU according to G.8271.2 Intel FPGA and Intel eASIC™ products with HPS, with a
Section 7.3.2, which describes the limits at reference point C strong roadmap and feature enhancements.
for applications in accuracy Class 4 (i.e., ±1.5 μs) as described Please get in touch with your local Intel sales team for more
in G.8271 in Table 1. information.
The network limits provided in G.8271.2 are conservative and
can be viewed as a “worst-case” for 5G network deployments.
As seen in Table 2, the Intel PTP Servo achieves 1 μs (these Conclusion
results have been proven to be DCS independent) compared All communication networks require an appropriate level
to the ptp4l proportional-integral (PI) servo solution, which of clock synchronization across the different devices that
can achieve only 138 μs. For a network operator, this equates comprise the network. The necessary level of precision
to the ability to use an existing legacy network between the and accuracy is both application and device dependent. For
DU and the RU, thereby avoiding the costs associated with example, based on frequency-division-multiplexing (FDM)
investing in a new FTS network. principles, legacy telecommunications networks required just
frequency synchronization, also called syntonization. These
networks further classified the synchronization requirements
in terms of levels or strata. At the network core, where the
requirements were most stringent, lived the Stratum 1 clocks,
while Stratum 4 clocks were found at the edge where the
requirements were the least stringent.

10
White Paper | Intel® Precision Time Protocol Servo (Intel® PTP Servo) Solution for Time Synchronization Applications

By comparison, modern networks based on packet- Learn More

switching principles can perform their packet-based
functions asynchronously. However, at the network edge, • Synchronization and Timing in Telecommunications,
where the rubber meets the road, the need for precise and Kishan Shenoi, 2009, ISBN 978-1-4392-2632-2
accurate synchronization remains because the service or
• Synchronizing 5G Mobile Networks, Dennis Hagerty,
application demands it. This is exemplified by mobile wireless
Shahid Ajmeri, Anshul Tanwar, 2021, ISBN 978-0-13-
communication systems where precise timing is required at
683625-4.
the most extreme edge of the network, which is the antenna
of a base station. To achieve this economically and reliably, • Measurement, Control, and Communication Using IEEE
high-performance clocks are placed closer to the core, and 1588, John Edison, 2006, ISBN 978-1-8462-8250-8
suitable distribution methods such as PTP and SyncE are used
• WSTS: NIST-ATIS Workshop on Synchronization and
to provide accurate timing towards the edge.
Timing Systems (https://wsts.atis.org/)
Wireless usage and bandwidth expectations are growing
• ITSF: International Timing and Synchronization Forum
rapidly. The RAN infrastructure to support this growth needs
(http://www.telecom-sync.com/)
to be properly synchronized. The O-RAN community has
recognized this phenomenon and expressed the need for
stringent synchronization as detailed in the S-Plane body of
requirements. Intel Whitepapers
• Build Efficient and Cost-Effective mMIMO Solutions with
PTP is the chosen methodology for achieving this
Intel Agilex 7 FPGAs
synchronization. Intel provides a significant body of technology
for implementing end-to-end O-RAN solutions. In the context • Build More Cost-Effective and More Efficient 5G Radios
of this paper, Intel provides a superior PTP solution that can with Intel Agilex FPGAs
be applied in both FTS and PTS network architectures.
• Flexible Performance for 5G vRAN Deployments
In the case of an example PTP implementation employing an
• Enabling 5G Fronthaul
Intel SoC FPGA, the Intel PTP Servo-based solution achieves a
peak-to-peak time error of fewer than 5 ns in an FTS (G.8271.1) • Intel’s Accelerated Virtual Cell Site Router Solution
network architecture, dramatically beating the +/-8.138 ns
requirement in the CPRI specification. Furthermore, in the
case of a PTS (G.8271.2) network architecture, the Intel PTP Intel Devices and IP
Servo-based solution achieves a peak-to-peak time error of
only 1 μs compared to the 138 μs result when using an open- • Intel Agilex SoC FPGAs
source ptp4l servo. • Intel RAN FPGA Solutions
It’s important to remember that timing synchronization is • Intel FPGA IP
essential for many applications. Although the body of this
paper has concentrated on the demands of radio access
References
networks, the Intel PTP Servo applies to a wide range of
cutting-edge technologies, including industrial measurement
1
In Search of Time: The History, Physics, and Philosophy of
and control systems, financial transactions, and sub-sea Time, Dan Falk, ISBN 0312603517
acoustic arrays. 2
The Order of Time, Carlo Rovelli, ISBN 073521610X
3
Reality Is Not What It Seems: The Journey to Quantum
Gravity, Carlo Rovelli, ISBN 0735213933
4
https://www.o-ran.org
5
https://www.3gpp.org
6
https://www.itu.int
7
Kishan Shenoi, Fundamentals of Synchronization and
Timing, WSTS-2023 Tutorial Session, March 2023.
WSTS 2023 Virtual Tutorial available at https://wsts.atis.
org/2023-tutorial
8
O-RAN Working Group 4 (Open Fronthaul Interfaces WG),
Control, User and Synchronization Plane Specification,
O-RAN.WG4.CUS.0-R003-v11.00.01, Feb. 24, 2023.
9
Eidson, John C. (April 2006). Measurement, Control and
Communication Using IEEE 1588. Springer. ISBN 978-1-
84628-250-8.
Intel technologies may require enabled hardware, software or service activation.
No product or component can be absolutely secure.
Your costs and results may vary.
© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. *Other names and brands may be claimed as the property of others.

Please Recycle WP-01325-1.0

11