Skip to main content
shopping_basket Basket 0
Login

An Introduction to IEEE 1588 Precision Time Protocol

Andrew Back
0

Precision Time Protocol, in operation

PTP adoption gathers momentum with applications that include low latency digital audio, power distribution, Industrial IoT, mobile networks and even particle accelerators.

IEEE 1588 Precision Time Protocol (PTP) has been around for some time, with the first version of the standard being published almost 20 years ago, back in 2002. Since then it has undergone two further revisions and what initially found use in much more niche applications, has gone on to find an increasing number of uses, with applications and device support growing all the time.

In this article, we’ll take a look at PTP basic operation and the different versions of the standard, and then a selection of typical applications and hardware which provides support for IEEE 1588.

Basics

Basic operation of a IEEE 15888 Precision Time Protocol (PTP)

An obvious comparison to make is between PTP and the Network Time Protocol (NTP) which is commonly used by servers, network equipment and devices which need to keep track of time but don’t have a real-time clock (RTC), such as Raspberry Pi SBCs, for example. However, whereas NTP is capable of synchronising clocks to within a few milliseconds, PTP is capable of achieving far better sub-nanosecond accuracy, with many more potential uses as a result.

PTP achieves such high accuracy by employing a more advanced protocol and where possible by using hardware timestamping, instead of this being done in software; which is to say that timestamps are added right as packets enter and leave network ports. Hence Ethernet hardware needs to have IEEE 1588 support and ideally not just the end devices, but network equipment also.

Elements of an IEEE 1588 network have different clock roles and these are as follows:

  • Ordinary Clock. Only has one port and can be:
    • Master. Distributes time to slaves.
    • Slave. Synchronizes times with the master.
  • Boundary Clock. Has multiple ports and is used to help scale the network.
  • Transparent Clock. Also has multiple ports and helps in scaling.

The simplest PTP network consists of two nodes functioning as Ordinary Clocks, where one is master and the other slave. Typically the master would obtain time-of-day (ToD) from a primary source such as GNSS and therefore be designated Grandmaster. The slave would then sync to the master, with network propagation delays being taken into account as an average value is computed based upon the path forwards and backwards delays.

Obviously, this makes the Grandmaster a point of contention and PTP networks can be scaled out via the use of Boundary Clocks. These have multiple ports, effectively integrating both slave and master functions, to enable them to synchronise time both up and downstream.

Propagation delay can be computed using an end-to-end mechanism between slave and master, or peer-to-peer between each network element in the path. In the case of the former this is simple enough when the connection is just a wire, but much less so when there are variable delays from one or more network elements such as switches in the path. The peer-to-peer mechanism addresses this by having each element measure the delay between its input port and the device at the other end, with an appropriate correction being added to PTP messages.

Transparent Clocks take this one step further by the correction added to messages including the propagation delay through the network element.

With the above in mind, we can see how we really need all the elements involved in a PTP network to have IEEE 1588 support, otherwise, performance will be compromised. For example, with delay calculated end-to-end on a path via non-IEEE 1588 network switches, there may be clock jitter as the propagation delay varies according to network load and hence the size of switch queues.

This is something of a simplification and we’ve skipped a few details, such as the different message types, clock selection and time stamping modes, but this should give at least a basic understanding.

Versions

As noted earlier there are three different versions of IEEE 1588: 2002 (PTP v1), 2008 (PTP v2) and 2019 (informally, PTP v2.1). It’s important to note that 2008 is not backwards compatible with 2002, whereas 2019 is backwards compatible with 2008.

PTP v2 benefits from improved accuracy, precision and robustness over v1; amongst other things, the 2008 standard introduced the Transparent Clock and the concept of profiles, which specify operating parameters and options for particular applications. Profiles have been defined for applications including telecommunications, electric power distribution and audiovisual.

IEEE 1588-2019 adds numerous additional optional and backwards compatible features, such as modular transparent clocks, new message types, security features, performance reporting, and the ability to use a physical layer frequency reference such as Synchronous Ethernet (SyncE).

The 2019 edition of the standard is actually based on the White Rabbit (WR) extensions to IEEE-2008, which were developed by CERN and partners to provide a fully deterministic Ethernet-based network for data transfer, plus sub-nanosecond accuracy time sync. As such White Rabbit is at the very high-performance end of PTP and used in applications such as the LHC particle accelerator.

Applications

Before we get on to applications let’s next take a look at the types of synchronisation which PTP can be used to provide:

  • Frequency. Transferring a common frequency reference.
  • Phase. Enabling alignment to the edge of a common seconds time.
  • Time-of-Day. Synchronising year/month/day/hour/seconds etc.

Frequency and phase synchronisation are often a requirement in telecommunications networks. For example, in mobile networks where transmitters and receivers must be precisely locked to a given frequency, otherwise, there will be performance degradation or handsets may even fail to find the network. Meanwhile, phase alignment is similarly important across base stations and cells, otherwise framing will be misaligned and mobility, e.g. cell handover, may cease to function correctly.

Time-of-Day is likely the most useful type of synchronisation, with a great many potential applications. Although it should be noted that all three types of sync can be provided by the same PTP infrastructure and in many cases equipment will provide access to more than one type.

The original (2002) PTP committee was focused mainly on applications such as T&M and industrial automation — however, PTP initially proved most popular in telecoms applications. The reason being that it coincided with the switchover from TDM network infrastructure — which due to its synchronous nature transferred frequency and phase — to Ethernet and TCP/IP, hence something was needed to enable this to be transferred over modern network technology instead.

However, PTP is now being used in an increasingly diverse range of applications, with the equipment providing support for this out-of-the-box and industry-specific standards being developed that build on top of IEEE 1588.

Time-Sensitive Networking

IEEE 802.1AS clocking hierarchy

IEEE 802.1AS clocking hierarchy, Wikipedia.

One of the originally intended use cases for PTP was industrial automation and here it’s being used as a foundation technology for the Time-Sensitive Networking (TSN) set of standards, which provide real-time communication with hard time boundaries for end-to-end latencies. TSN is implemented as extensions to Ethernet standards and in the main, 802.1Q, which defines VLANS and network switches. However, given the strict latency requirement, devices need to have a highly accurate common reference clock and this is where PTP comes in.

TSN requires 1588 hardware timestamping and errors are generated if sync falls outside of expected bounds. In addition to which, TSN timing packets have priority scheduling and this requires the use of network switches that are compliant to IEEE 802.1AS-2011, Generic Precision Time Protocol (gPTP).

TSN also includes standards such as:

In short, these provide scheduling, traffic shaping and fault tolerance features, that enable Ethernet to be used in real-time industrial applications.

Audio Video Bridging

Certification mark given to AVnu compliant AVB products

Certification mark given to AVnu compliant AVB products.

Audio Video Bridging (AVB) is a set of standards that provide improved synchronisation, low latency and reliability for Ethernet networks in audiovisual applications. Thereby enabling common Ethernet infrastructure to be used for multiple audio and video streams, where previously there would have been incompatible standards such as S/PDIF and SDI, with the associated cable sprawl.

Tight sync between multiple streams is often needed with audiovisual applications, such as for lip sync between video and related audio. Low latency is also a common requirement and jitter can be particularly problematic. AVB addresses such needs via the standards IEEE 802.1AS (gPTP) time synchronisation, 802.1Qav and VLAN tags for traffic shaping, and 802.1Qat SRP.

AVB is actually a precursor to TSN and in 2012 the AVB task group within the IEEE was renamed to Time-Sensitive Networking and continued to expand upon their work.

Power Networks

Hierarchy of PTP clocks in a substation

Hierarchy of PTP clocks in a substation, Wikipedia.

There are numerous applications for PTP in electrical power distribution networks, such as sophisticated power monitoring, grid synchronisation and fault diagnosis. Here PTP can offer many benefits over traditional solutions such as IRIG-B, while offering far better performance than NTP and being much more scalable, easier to deploy and more resilient that GNSS alone.

Relevant standards include:

Telecoms profiles although developed for a different domain are seemingly sometimes used in power distribution applications. For example, where existing network infrastructure is based on telecoms technology, such as certain inter-substation networks. In some cases there will also be a mixture of standards and PTP may be converted to a pulse per second signal or IRIG-B etc.

Hardware

Equipment must provide hardware support in order to fully benefit from PTP and, as noted previously, not just end devices, but also all network equipment along the path that carries 1588 time synchronisation. Fortunately, whereas such network equipment used to be harder to find and much more expensive, it is now becoming more common and affordable, thanks to the growing adoption of PTP and technologies that are based upon this, such as AVB.

So let’s start by taking a look at network equipment.

Infrastructure

MOTU 5-port AVB Ethernet switch

MOTU 5-port AVB Ethernet switch.

Unless you have a very simple network indeed, a switch will be required and this should have PTP support — along with perhaps support for other standards or sets of standards as appropriate, e.g. AVB, TSN and IEEE 1588 profiles. Speaking of AVB, affordable examples of PTP switches include those which are designed with audiovisual applications in mind, such as the one pictured above.

MOXA 5-port switch with IEEE 1588 PTPv2

MOXA 5-port switch with IEEE 1588 PTPv2.

Industrial Ethernet switches with PTP hardware support are also available, along with much larger rack-mounted switches from vendors such as Cisco, plus solutions from specialist vendors that are targeted at specific applications, such as instrumentation.

MOXA 5-port switch with IEEE 1588 PTPv2

Microsemi TimeProvider 5000.

A PTP network is also going to need at least one Grandmaster and ideally more than one for resilience. The TimeProvider 5000 equipment pictured above can support up to 2,000 PTP clients, with support for a GNSS primary time source, plus quartz and rubidium oscillator options for higher performance holdover in the event that the primary time source is temporarily lost.

PTP clients

Schneider PM8000 3-phase energy meter

Schneider PM8000 3-phase energy meter.

Examples of client devices include the Schneider PM8000 series of 3-phase energy meters (913-9649) , which are able to use PTP v2 for time synchronisation. These advanced energy meters can be used with tools such as Schneider’s EcoStruxure Power Monitoring Expert, which is able to gather data from many meters, including waveforms that have been captured as a result of system anomalies. With such applications, the use of high accuracy time synchronisation can make it possible to pinpoint the cause of problems in electrical power distribution networks.

A number of development boards feature Ethernet hardware with support for PTP, such as the BeagleBone Black

A number of development boards feature Ethernet hardware with support for PTP, such as the BeagleBone Black (125-2411) , as illustrated in this project by Mudassar Ahmed.

The Raspberry Pi Compute Module 4 also has Ethernet hardware that features PTP support

The Raspberry Pi Compute Module 4 (206-4849) also has Ethernet hardware that features PTP support, with software support for this currently in development.

low power platforms include the NXP Freedom-K64F

Examples of more deeply embedded / low power platforms include the NXP Freedom-K64F (905-3779) , which features a 120MHz Arm Cortex-M4 microcontroller.

In addition to which network interface cards with PTP support are available.

Software

Fully integrated products such as Schneider PM8000 energy meters will have turnkey PTP support courtesy of their firmware, plus associated software applications. General support on Linux systems is provided via ptp4l and friends, which enable a system to be configured as an Ordinary Clock or a Boundary Clock, and to synchronise the system clock to the PTP hardware clock. Enhanced proprietary solutions are also offered by PTP hardware vendors.

For deeply embedded solutions an RTOS such as Zephyr may be used, which includes TSN/gPTP support for the aforementioned Freedom-K64F platform, amongst others.

Wrapping up

As we have seen IEEE 1588 PTP is a powerful solution for providing high accuracy time synchronisation, that can be scaled across Ethernet networks with different classes of client devices and a broad range of applications. In addition to which it may be used for frequency and phase synchronisation, which is something that we’ve not covered in any detail here, but obvious uses for which in addition to telecommunications, include test and measurement, and scientific applications.

Andrew Back

Open source (hardware and software!) advocate, Treasurer and Director of the Free and Open Source Silicon Foundation, organiser of Wuthering Bytes technology festival and founder of the Open Source Hardware User Group.

Recommended Articles

DesignSpark Electrical Logolinkedin