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…
1682 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…
2695 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…
3812 Read more

Archived Blogs

986 More

Timing not Telecoms

Nov 08, 2016
663 More

5G Coming Soon

Aug 22, 2016
673 More

What is 1588 PTP?

Aug 04, 2016
796 More

5G on the Horizon

Aug 01, 2016
673 More
704 More

What is a PTP Clock?

Apr 09, 2016
826 More

What is Time Error?

Oct 21, 2015
681 More

LTE-A & VoLTE Rollout

Sep 22, 2015
658 More

LTE Picks Up Speed

Aug 22, 2015
646 More

What is the Time?

Aug 22, 2015
648 More

Mobile and Sync

Aug 22, 2015
628 More

What is SyncE?

Aug 22, 2015
1230 More
717 More

Microwave Update

Aug 22, 2015
719 More

Unravelling Standards

Aug 22, 2015
695 More

Partial Progress?

Aug 22, 2015
654 More

Interpreting ITU

Aug 22, 2015
639 More

Confusion Rules!

Aug 22, 2015
661 More

Basestations Need Sync

Aug 22, 2015
666 More

ITSF 2015 Edinburgh

Aug 22, 2015
629 More

India to Follow China?

Aug 07, 2015
652 More
HOW CAN CALNEX HELP YOU FURTHER?

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