The rapid growth of the internet of things (IoT) makes network timing an urgent issue. As more and more devices come online, synchronization becomes critical and with many emerging applications demanding far more accuracy, it’s important that precise timing can be ensured right across the network.

One of the major issues that needs to be addressed is synchronization monitoring. In recent years, various aspects of synchronization monitoring have been raised in the Precision Time Protocol (PTP) community in various forums. As a member of the IEEE 1588 working group that defines the specification for PTP, I’ve been actively collaborating on the incorporation of solutions that better support synchronization monitoring and testing functions within the standard. In particular, I’ve suggested that the upcoming revision of IEEE 1588 includes specifications that will enable interoperable monitoring and testing of the timing performance of clocks in general, and specifically slave clock monitoring.

Keeping PTP Networks in Sync

To create an accurate timing network, PTP generally relies on a hierarchical timing topology. In this, a grandmaster clock operates at the top of the pyramid and distributes timing information to all clocks directly synchronizing to it. These clocks (termed boundary clocks) then redistribute timing to other clocks directly synchronizing to them. Slave-only clocks are at the bottom of this synchronization tree.

This makes things somewhat tricky as a slave clock can only be a reliable time source if the clock it is synchronizing to is itself accurate. In PTP it is the slave’s role to synchronize to its master clock. If this slave functionality is part of a boundary clock, any error in its timing recovery will be then passed down to its slaves. Such errors normally accumulate at a tolerable level, in line with timing network design, as timing propagates down the synchronization tree. But it is vital to assure that each component in this timing distribution is working as expected (i.e. its timing output has only a small degradation from its timing source). If any clock that is a timing source starts to distribute inaccurate timing for any reason, all other devices syncing to it may follow suit. 

Various things might go wrong in a PTP timing network: GNSS timing sources can be lost to an antenna break or severe weather, various network devices (including PTP clocks) can go down and become unavailable. Since timing is in many cases a critical infrastructure in the network, it needs to continue to provide the needed accuracy even following such an event. The PTP protocol has various mechanisms to handle such expected failure scenarios. For example, they enable the PTP timing network to transition to an alternate external timing source that still has time traceability, and reroute the network timing topology to maintain accurate timing in an appropriately deployed network. 

As a PTP timing network is a complex distributed system, in order to have high confidence in the timing distribution accuracy it is important to monitor that the network is working as expected during deployment. Such monitoring may be critical in detecting and handling of unexpected failures. A slave clock that is mal-performing and not syncing correctly to its master is an important example of such a failure. 

Slave Clock Monitoring

With the current standard, it’s difficult to monitor slave-only clocks. Unless such a clock has some sort of external physical interface available, it’s often impossible from looking at packet level data to establish the slave’s timescale (i.e. the slave’s internal representation of time later used by the applications). Many of the miniature devices being developed today (many of which will increasingly require precise timing) will find it difficult to provide a physical interface to enable verification of the slave timing performance. That will be true for both parts of the testing needed during product validation, let alone making such an interface available for monitoring during actual product deployment.

In today’s PTP networks, there are some limited ways to view a slave clock’s timing. If a slave (e.g., one using a delay request-response mechanism) embeds it’s internally acquired timestamp in an outgoing delay request message, then part of the information we would want to monitor can be attained. But as this isn’t a mandatory stage in the specifications and is not needed for the operation of the protocol, this feature doesn’t exist in equipment from many vendors. What’s more, this specific type of timestamp information is only part of what we need to observe to assist in effectively monitoring the timing network.

Sending a Message

One way that the monitoring of slave clock performance can be enhanced is by the slave providing access to information it already collects during regular PTP operation (e.g., the timestamp I mentioned earlier and other such timestamps). The slave can send this information to the monitoring nodes (these could, for example, be integrated into other PTP nodes, and in particular the slave’s master). This information could be distributed using generic messages already specified in the PTP protocol. The protocol enables messages with additional type-length-value (TLV) suffixes to be expanded. New TLVs can be defined to support transfer of new data, and this data can be attached to already defined PTP signalling messages. 

The ability to send this information will give a boost to the ability to define packet-based testing for slave clocks, specifically helping to tackle the problem of smaller equipment being harder to test using physical signals. While the slave will have to become more and more compact to fit into the application devices, the packet-based testing could reduce the need for testing via such interfaces. The same technology also enables slave clock performance in a running PTP network to be remotely monitored.

That’s why I’m looking forward to the expected addition of such slave monitoring features in the next version of IEEE 1588. It and other new features will enable better, more exhaustive testing of PTP clocks and monitoring of PTP networks. Such monitoring may be essential in assuring split-second timing precision needed in upcoming applications from 5G cellular networks to smart electrical grids to the expected billions of devices in the IoT.