IEEE1588 AN1307: Holdover in 5G Networks Using PTP, SyncE

AN1307: Holdover in 5G Networks UsingIEEE1588

This application note examines different methods to achieve hold-over in telecommunication networks.The document discusses the role of holdover and its evolution from legacy SONET/SDHnetworks, which depend on frequency synchronization up to modern 5G mobile telecom-munication which depend on frequency, phase, and time synchronization using IEEE1588. The methods used in achieving holdover in legacy SONET/SDH networks areno longer practical in modern 5G networks. Fortunately, the International Telecommuni-cations Union (ITU) recommends other methods of achieving the same level of holdoverperformance. This document examines each of these methods and provides lab meas-urements to compare their performance.

KEY FEATURES

• Details about Importance of Holdover andit’s evolution for 5G Networks

• 5G network limits and time error budgetaccording to the ITU-T Standards

• Different methods for implementingholdover in full and partial timing networksusing Skyworks timing solutions

• A comparison of holdover results fromPTP, SyncE, OCXO and TCXO

Skyworks Solutions, Inc. • Phone [781] 376-3000 • Fax [781] 376-3100 • [email protected] • www.skyworksinc.com1 Rev. 1.0 • Skyworks Proprietary Information • Products and Product Information are Subject to Change Without Notice • December 17, 2021 1

Table of Contents1. The Importance of Holdover . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Holdover Performance Requirements with Respect to Network Limits . . . . . . . . . . 5

3. Implementing Holdover in a Full Timing Support Network . . . . . . . . . . . . . . 6

4. Implementing Holdover in a Partial Timing Support Network . . . . . . . . . . . . . 9

5. Conclusion and Final Remarks. . . . . . . . . . . . . . . . . . . . . . . . 14

6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7. Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


1. The Importance of Holdover

Holdover plays an important role in the network. It provides a temporary source of synchronization when the primary source ofsynchronization is unavailable. Loss of primary synchronization can occur for several reasons, one of which is equipment failure.Holdover allows a technician time to repair faulty equipment or to reconfigure the network and restore synchronization.

Efficient transmission of data across legacy SONET/SDH networks relied on accurate and stable frequency synchronization. This wasaccomplished by synchronizing all network equipment to a common reference point known as primary reference clock (PRC). A fewlayers of holdover protection in this synchronization scheme allowed equipment to continue operating with minimal disruption until theproblem was resolved. It was common to expect equipment to maintain frequency synchronization up to 24 hours in a holdover modeusing a local oscillator, such as an oven-controlled crystal oscillator (OCXO) or a temperature compensated crystal oscillator (TCXO)since the stability of these oscillators is sufficient for achieving required holdover performance.

Networks that rely on both frequency and phase synchronization need an alternate approach. This is especially true for 5G mobilenetworks where it's expected that phase synchronization between two radio towers is within 3µs. Holdover using local oscillators cannotachieve the same 24-hour holdover period that was expected from the network which only relied on frequency synchronization.

One approach to distribute frequency and phase synchronization to network endpoints is to include GNSS receivers at the nodeslocated at the edge of the network. A second approach is to locate a GNSS-based primary reference time clock (PRTC) in a centrallocation and distribute frequency and phase synchronization to the edge nodes using the IEEE 1588 precision time protocol (PTP).Both of these methods are illustrated in the figure below.

Figure 1.1. Synchronizing the Edge of the Network Using GNSS and IEEE 1588 (PTP)

The International Telecommunication Union defines two types of network topologies for distributing time synchronization using PTP.These topologies are Full Timing Support (FTS), and Partial Timing Support (PTS) as shown in Figure 1.2. In an FTS network, all nodesare equipped to process PTP packets in addition to providing support for physical layer synchronization, such as synchronous Ethernet(SyncE). A telecom boundary clock (T-BC) is an example of a node that processes PTP messages in an FTS network. The combinationof PTP and SyncE offers a good solution where accurate and stable phase synchronization is required. PTP is the primary source offrequency, phase, and time synchronization while SyncE provides additional frequency stabilization especially during holdover whenPTP is temporarily unavailable.

PTS networks on the other hand distribute synchronization across nodes that may not be able to process PTP and may not supportSyncE. These networks tend to have much shorter transmission paths with fewer nodes but can still offer good performance.

AN1307: Holdover in 5G Networks Using IEEE1588 • The Importance of Holdover


Figure 1.2. Full Timing Support Network (FTS) , Partial Timing Support Network (PTS) and Partial Timing Support Networkwith APTS clocks

Two types of end nodes are commonly found in a PTS network:• An assisted slave clock (T-TSC-A) which uses GNSS as its primary source of synchronization with PTP as a holdover source• A slave clock with additional packet delay filtering (T-TSC-P) and SyncE as a possible holdover source

Note that SyncE is not always available in a PTS network, so a stable local oscillator needs to provide the holdover function at the slavenode in this case. The methods in which each of these clocks manage holdover is illustrated in the image below.

Assissted Partial Timing Support (APTS) is a special case of PTS networks that have APTS clocks at the network edge as shownin Figure 1.3 . Here, the GNSS receiver acts as the primary source providing time synchronization and PTP is used as the holdoverreference.

Figure 1.3. Holdover Modes of Slave Clocks in FTS Networks, PTS Networks and PTS Networks with APTS clocks

AN1307: Holdover in 5G Networks Using IEEE1588 • The Importance of Holdover


2. Holdover Performance Requirements with Respect to Network Limits

The requirement of a 24-hour holdover originated from legacy SONET/SDH networks that only supported frequency synchronization.This holdover period gave technicians a reasonable amount of time to repair a failure in the synchronization chain. It also allowed endapplications, such as mobile communications radios that depended on a stable frequency reference from the network to maintain their3GPP frequency accuracy requirement of ±50 ppb. OCXOs with Stratum-3 level performance of ±37 ppb stability over 24-hours wereused to meet these requirements.

The evolution of TDD mobile radios in 5G networks have placed even more stringent requirements on the synchronization network. Notonly do radios need to meet the ±50 ppb frequency requirement, they also need to meet a 3µs phase alignment between radio towersto ensure proper call handoff. The International Telecommunications Union has developed new standards with proposed budgetsthat assign phase error limits to the synchronization path guaranteeing that each radio is within ±1.5µs from a common point in thenetwork. ITU-T G.8271.1 defines the budget for full timing support networks, while G.8271.2 covers the budget for partial timing supportnetworks.

The image below shows the network reference model defined by G.8271.1 and G.8271.2 with proposed phase error limits for variousfailure scenarios. Depending on the scenario, it is expected that holdover maintains time error as low as ±250 ns. The different classesfor the network nodes are defined by G.8273.2 standard.

Figure 2.1. Network Reference Model and Time Error Budgets

The following sections compare practical holdover implementations that allow this level of phase accuracy.

AN1307: Holdover in 5G Networks Using IEEE1588 • Holdover Performance Requirements with Respect to Network Limits


3. Implementing Holdover in a Full Timing Support Network

In a full timing support network, every node in the synchronization path is PTP aware and supports SyncE. A typical implementation ofa T-BC/T-TSC used in a FTS network using a Skyworks' clock device and AccuTime software is shown in the image below. In its normaloperating mode, the PTP servo steers the DCO which is used to generate a synchronous frequency for the ToD counter. The recoveredSyncE clock provides frequency stability for the 1588 PLL between DCO updates and a stable reference for the SyncE PLL.

Timestamps

Packet I/O Time

Stamper

ToD Adjust

OCXO/TCXO

ToD

PTP

Freq

Time Stamper

Packet I/O

Sync

E

Reco

vere

d Sy

ncE

PHY Slave

PHY Master

1PPS

DCO Control

1588 PLL

SyncE PLL

Stack

Servo

CPU

DCO

Figure 3.1. Implementation of a T-BC/T-TSC in a FTS network Using a Skyworks' Clock Device and AccuTime Software

The chart below shows time error measurements of this system when synchronized to ideal PTP and SyncE sources. The data wasnormalized to remove any constant time error or path delay asymmetries. The oscillators were also kept in a controlled environment at25˚C and were allowed to soak for a day before starting the test. The objective was to observe the stability of the output clocks whilesynchronized over a 24-hour period. Data shows virtually identical time error performance with both an OCXO and TCXO. It shows thatthe reference oscillator stability has much less of an impact when a SyncE source is available. However, it should be remembered thatthis was an ideal SyncE source with no wander.

AN1307: Holdover in 5G Networks Using IEEE1588 • Implementing Holdover in a Full Timing Support Network


Figure 3.2. Time Error Performance with PTP Plus SyncE Synchronization

When PTP becomes unavailable, SyncE acts as the main source of stability with the OCXO or TCXO providing an additional level ofstability. The image below shows the time error performance for this case.

This also shows excellent time error performance. It's clear from the data shown here that holdover using SyncE as a stabilizationsource easily meets the 24-hour holdover requirements.



Figure 3.3. Time Error Performance with SyncE as a Holdover Source



4. Implementing Holdover in a Partial Timing Support Network

As seen in the previous section, SyncE provides an excellent source of holdover when PTP becomes unavailable. However, partialtiming support networks may not have SyncE available, so alternative methods of holdover are necessary. Assisted partial timingsynchronization clocks, such as a T-TSC-A, solves the holdover problem in a different way. Its primary source of synchronization isfrom GNSS. As a backup, PTP is available as a holdover reference if GNSS fails. Assuming that SyncE is not available, the PTP servooperates with the OCXO or TCXO as a source of stabilization. Figure 4.1 shows a typical implementation using Skyworks' clock deviceand AccuTime software. The chart below shows time error measurements for this case.

Timestamps

Packet I/O Time

Stamper

ToD Adjust

OCXO/TCXO

PTP

Freq

Time Stamper

Packet I/O

PHY Slave

PHY Master

DCO Control

1588 PLL (free-run)

Stack

Servo

CPU

ToD

1PPS

1PPSToD

GNSS Receiver

DCO

Figure 4.1. Implementation of a T-BC-A/T-TSC-A (APTS Clocks) Using Skyworks' Clock Device and AccuTime Software

AN1307: Holdover in 5G Networks Using IEEE1588 • Implementing Holdover in a Partial Timing Support Network


Figure 4.2. Time Error Performance with PTP as a Holdover Source

Although the time error performance of PTP without SyncE is not as good as the one with the support of SyncE, it is still a valid sourceof 24-hour holdover when GNSS is unavailable. For the APTS clocks, G.8271.2 recommends holdover up to 72 hours after the GNSSreference is lost. This is easily possible using PTP as the holdover source.

Clocks in partial timing networks that don't have access to GNSS may need to rely solely on the local oscillator for holdover. This isthe case for a T-TSC-P clock that does not have access to SyncE. The image below shows the implementation of this clock. The chartbelow shows time error measurements for this case.



Timestamps

Packet I/O Time

Stamper

ToD Adjust

OCXO/TCXO

ToD

PTP

Freq

Time Stamper

Packet I/O

Sync

E

Reco

vere

d Sy

ncE

(opt

iona

l)

PHY Slave

PHY Master

1PPS

DCO Control

1588 PLL

SyncE PLL

Stack

Servo

CPU

DCO

Figure 4.3. Implementation of a T-BC-P/T-TSC-P in a PTS Network Using Skyworks' Clock Device and AccuTime Software



Figure 4.4. Time Error Performance with Local Oscillator as Holdover Source

It becomes obvious that using a local oscillator as a holdover reference has its limitations. Meeting 24-holdover is no longer possible.An expanded view of the holdover measurements for both the OCXO and TCXO local oscillators is shown in the charts below.



Figure 4.5. Time Error Performance with Local Oscillator as Holdover Source (Magnified View)

A TCXO can only expect to maintain phase within the G.8271.1 and G.8271.2 budget limits for a matter of minutes. An OCXO on theother hand has much better performance and can extend the holdover period over several hours. It's also important to keep in mindthat all measurement data was captured using a well-controlled environment with a constant temperature of 25 ̊C. In a real system, theambient temperature of the local oscillator may vary considerably and shorten holdover times shown above.



5. Conclusion and Final Remarks

This document shows that new methods of implementing holdover are necessary for achieving 24-hour holdover performance to meetthe requirements of 5G networks. Equipment that has access to a SyncE reference can achieve the same level of performance in bothnormal operation and holdover using less costly TCXOs. On the other hand, equipment without SyncE benefits from using a moreexpensive OCXO especially where holdover performance is concerned.

Full timing support networks offer the best overall performance, but partial timing support networks (i.e. APTS) can also achievegood performance with the use of GNSS as a primary source of synchronization and PTP as a holdover reference. Otherwise, clockequipment designed for PTS networks benefit from using a highly stable OCXO especially when trying to achieve the best holdoverperformance.

The table below summarizes the holdover performance of different network equipment described in this document:

Table 5.1. Holdover Performance Summary for different types of networks

Full Timing Support (FTS) clocks

T-BC/T-TSC

When a SyncE source acts as the holdover reference, 24 hoursholdover requirement is satisfied easily. The time error perform-ance is the best in this scenario.

Partial Timing Support with APTS clocks

T-BC-A/T-TSC-A

When PTP acts as the holdover reference, these networks canmeet the 72 hours holdover requirement. The time error perform-ance may not be as good as with SyncE.

Partial Timing Support (PTS)

T-BC-P/T-TSC-P

When SyncE is available as holdover reference, 24 hour holdoverrequirement is satisfied. In absence of SyncE, holdover is possi-ble with the local oscillator as the reference but may not meet 24hour holdover. In this case, an OXCO with very high stability givesmuch better performance than a TCXO.

AN1307: Holdover in 5G Networks Using IEEE1588 • Conclusion and Final Remarks


6. Glossary

cTE: Constant Time Error - type of error which arises due to the asymmetries between two nodes in the network.

DCO: Digitally Controlled Oscillator

dTE: Dynamic Time Error - error occurred due to frequency and phase wander of the local oscillator in the clock devices.

FTS: Full Timing Support - Network with all the nodes that are PTP aware

GNSS: Global Navigation Satellite System

IEEE: Institute of Electrical and Electronics Engineers

ITU-T: The International Telecommunication Union - Telecommunication Standardization Sector

OCXO: Oven Controlled Crystal Oscillator

1PPS: One Pulse Per Second

PRC: Primary Reference Clock

PRTC: Primary Reference Time Clock

PTP: Precision Time Protocol - Protocol defined by IEEE 1588 used for time synchronization throughout the network

PTS: Partial Timing Support - Network with PTP unaware nodes

SDH: Synchronous Digital Hierarchy

SONET: Synchronous Optical Networking

SyncE: Synchronous Ethernet - ITU-T standard for transmitting clock signals over the Ethernet physical layer.

T-BC: Telecom - Boundary Clock - equipment used to extend the transmission path between T-GM and T-TSC.

T-BC-A: Telecom - Boundary Clock Assisted

T-BC-P: Telecom - Boundary Clock with Partial timing support

T-GM: Telecom - Grandmaster - generates PTP timestamp messages using the 1PPS and ToD information received from GNSS

T-TSC: Telecom - Time Slave Clock - final node in the network which provides synchronized time, frequency, and phase to endapplications

T-TSC-A: Telecom - Time Slave Clock Assisted

T-TSC-P: Telecom - Time Slave Clock with Partial timing support

TCXO: Temperature-Compensated Crystal Oscillator

ToD: Time of Day - PTP packets are time-stamped with ToD to distribute time synchronization

AN1307: Holdover in 5G Networks Using IEEE1588 • Glossary


7. Revision History

Revision 1.0

December, 2020• Initial release

AN1307: Holdover in 5G Networks Using IEEE1588 • Revision History


Copyright © 2021 Skyworks Solutions, Inc. All Rights Reserved.Information in this document is provided in connection with Skyworks Solutions, Inc. (“Skyworks”) products or services. These materials, including the information contained herein, are provided by Skyworks as a service to its customers and may be used for informational purposes only by the customer. Skyworks assumes no responsibility for errors or omissions in these materials or the information contained herein. Skyworks may change its documentation, products, services, specifications or product descriptions at any time, without notice. Skyworks makes no commitment to update the materials or information and shall have no responsibility whatsoever for conflicts, incompatibilities, or other difficulties arising from any future changes.

No license, whether express, implied, by estoppel or otherwise, is granted to any intellectual property rights by this document. Skyworks assumes no liability for any materials, products or information provided hereunder, including the sale, distribution, reproduction or use of Skyworks products, information or materials, except as may be provided in Skyworks’ Terms and Conditions of Sale.

THE MATERIALS, PRODUCTS AND INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING FITNESS FOR A PARTICULAR PURPOSE OR USE, MERCHANTABILITY, PERFORMANCE, QUALITY OR NON-INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT; ALL SUCH WARRANTIES ARE HEREBY EXPRESSLY DISCLAIMED. SKYWORKS DOES NOT WARRANT THE ACCURACY OR COMPLETENESS OF THE INFORMATION, TEXT, GRAPHICS OR OTHER ITEMS CONTAINED WITHIN THESE MATERIALS. SKYWORKS SHALL NOT BE LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO ANY SPECIAL, INDIRECT, INCIDENTAL, STATUTORY, OR CONSEQUENTIAL DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUES OR LOST PROFITS THAT MAY RESULT FROM THE USE OF THE MATERIALS OR INFORMATION, WHETHER OR NOT THE RECIPIENT OF MATERIALS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Skyworks products are not intended for use in medical, lifesaving or life-sustaining applications, or other equipment in which the failure of the Skyworks products could lead to personal injury, death, physical or environmental damage. Skyworks customers using or selling Skyworks products for use in such applications do so at their own risk and agree to fully indemnify Skyworks for any damages resulting from such improper use or sale.

Customers are responsible for their products and applications using Skyworks products, which may deviate from published specifications as a result of design defects, errors, or operation of products outside of published parameters or design specifications. Customers should include design and operating safeguards to minimize these and other risks. Skyworks assumes no liability for applications assistance, customer product design, or damage to any equipment resulting from the use of Skyworks products outside of Skyworks’ published specifications or parameters.

Skyworks, the Skyworks symbol, Sky5®, SkyOne®, SkyBlue™, Skyworks Green™, Clockbuilder®, DSPLL®, ISOmodem®, ProSLIC®, and SiPHY® are trademarks or registered trademarks of Skyworks Solutions, Inc. or its subsidiaries in the United States and other countries. Third-party brands and names are for identification purposes only and are the property of their respective owners. Additional information, including relevant terms and conditions, posted at www.skyworksinc.com, are incorporated by reference.

Portfoliowww.skyworksinc.com/ia/timing

SW/HWwww.skyworksinc.com/CBPro

Qualitywww.skyworksinc.com/quality

Support & Resourceswww.skyworksinc.com/support

ClockBuilder ProCustomize Skyworks clock generators, jitter attenuators and network synchronizers with a single tool. With CBPro you can control evaluation boards, access documentation, request a custom part number, export for in-system programming and more!

www.skyworksinc.com/CBPro

Skyworks Solutions, Inc. | Nasdaq: SWKS | [email protected] | www.skyworksinc.comUSA: 781-376-3000 | Asia: 886-2-2735 0399 | Europe: 33 (0)1 43548540 |

Documents

IEEE1588 AN1307: Holdover in 5G Networks Using PTP, SyncE