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

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…
575 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…
1874 Read more

A Better Way to Find and Fix Network Issues

Dec 18, 2018
When identifying the remedy can be as challenging as finding the cause of the network…
619 Read more

Archived Blogs

Timing not Telecoms

Nov 08, 2016
156 More

5G Coming Soon

Aug 22, 2016
157 More

What is 1588 PTP?

Aug 04, 2016
198 More

5G on the Horizon

Aug 01, 2016
150 More
175 More

What is a PTP Clock?

Apr 09, 2016
173 More

What is Time Error?

Oct 21, 2015
147 More

LTE-A & VoLTE Rollout

Sep 22, 2015
145 More

LTE Picks Up Speed

Aug 22, 2015
153 More

What is the Time?

Aug 22, 2015
149 More

Mobile and Sync

Aug 22, 2015
143 More

What is SyncE?

Aug 22, 2015
169 More
163 More

Microwave Update

Aug 22, 2015
166 More

Unravelling Standards

Aug 22, 2015
172 More

Partial Progress?

Aug 22, 2015
151 More

Interpreting ITU

Aug 22, 2015
155 More

Confusion Rules!

Aug 22, 2015
156 More

Basestations Need Sync

Aug 22, 2015
165 More

ITSF 2015 Edinburgh

Aug 22, 2015
157 More

India to Follow China?

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

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