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.

Related

Blog Library