Partial Support for Partial Timing

For a long time now, operators have been asking about how to use PTP to transfer time across their existing networks. Vendors say it’s possible, but the standards are not there. At least, until now. The ITU-T have just taken a big step forward with the agreement of G.8271.2 at their June meeting. What this standard does is define the requirements on the network for PTP to be able to work accurately over existing networks. This is termed “partial timing support from the network” – partial, because not all (or potentially, none) of the switches or routers in the network provide any support for the PTP protocol, and therefore PTP messages are simply forwarded, just like any other packet. This leads to a build-up of PDV, which affects the time accuracy if it is too large.

The document defines network limits for two main use cases. Firstly, PTP used as a backup to a local GNSS time source. This was the original use case presented by some of the big American operators. They already had a GPS time source at the basestation site (courtesy of the older CDMA systems used in N. America), but needed a backup source of time in case of failure. For example, a major issue with GPS is antenna failure due to weather – snow, ice, lightning, wind etc.

The second use case is for in-building timing distribution. In this case, there will be a GNSS antenna on the roof, and the time is distributed from there to a number of small cells dotted around the building over the building LAN using PTP. In this case, the network is assumed to be very small, to constrain the build-up of PDV and delay asymmetry.

Why the title – “partial support for partial timing support”? This is because the job is not done yet. ITU-T have defined the requirements on the network, but they haven’t yet defined the requirements on the PTP slave clocks. In other words, all PTP slave clocks on the market today aimed at this application are proprietary, and there is no standards-defined performance specification that they have to meet. That’s the next step in the roadmap, and that will likely prove even harder to agree than the network requirements.

Tim Frost
Strategic Technology Manager, Calnex Solutions.

Recent Blogs

Related Blogs

banana skin

Will SD-WAN really be the savior?

Mar 13, 2019
The only way to prove it is to get validation on how it will perform against your needs…
1661 Read more
Four Boardroom Members

How to Optimise Your IT Network and Spend

Feb 06, 2019
Network emulation can be a key tool to overcome barriers in getting the most out of your…
2669 Read more

Responding to IT Network Issues

Jan 22, 2019
If simple remedial scripts are not enough to fix an IT network issue, a more…
3799 Read more

Archived Blogs

979 More

Timing not Telecoms

Nov 08, 2016
657 More

5G Coming Soon

Aug 22, 2016
669 More

What is 1588 PTP?

Aug 04, 2016
788 More

5G on the Horizon

Aug 01, 2016
664 More
698 More

What is a PTP Clock?

Apr 09, 2016
818 More

What is Time Error?

Oct 21, 2015
672 More

LTE-A & VoLTE Rollout

Sep 22, 2015
651 More

LTE Picks Up Speed

Aug 22, 2015
638 More

What is the Time?

Aug 22, 2015
644 More

Mobile and Sync

Aug 22, 2015
621 More

What is SyncE?

Aug 22, 2015
1220 More
711 More

Microwave Update

Aug 22, 2015
714 More

Unravelling Standards

Aug 22, 2015
690 More

Partial Progress?

Aug 22, 2015
647 More

Interpreting ITU

Aug 22, 2015
633 More

Confusion Rules!

Aug 22, 2015
655 More

Basestations Need Sync

Aug 22, 2015
661 More

ITSF 2015 Edinburgh

Aug 22, 2015
624 More

India to Follow China?

Aug 07, 2015
646 More

Click your area of interest below for more tutorials and real-world case studies.