Electronic Design
What’s Behind The IEEE 1588 Protocol?

What’s Behind The IEEE 1588 Protocol?

IEEE 1588 (1588) is a packet-based two-way communications protocol specifically designed to precisely synchronize many clocks to sub-microsecond resolution. The 2008 version of the protocol defines different clock classes and the syntactic language between these classes of clocks. 

IEEE 1588 (1588) is a packet-based two-way communications protocol specifically designed to precisely synchronize many clocks to sub-microsecond resolution. The 2008 version of the protocol defines different clock classes and the syntactic language between these classes of clocks.

A master clock, when selected via the best master clock algorithm, provides the time base to all clocks in its domain. The primary reference time clock’s (PRTC’s) value of the time base is periodically captured with timestamps, usually once every second. The PRTC receives its own timing from an atomic clock either directly or via GPS satellites. The timestamps created represent the current value of time at the PRTC.

Using the 1588 protocol, these timestamps are inserted into “sync” packets in specially defined fields, with a special Ethertype reserved for the 1588 protocol. These packets are forwarded into the network as Ethernet packets or Internet protocol (IP) packets using user datagram protocol (UDP) as the packet type.

The clock class that receives and uses the timestamps to produce clock signals for applications is called an ordinary clock. The ordinary clock is located in the wireless basestation and must be able to derive the fundamental drive clock from the timestamp it receives from the PRTC.

In basestations with frequency division duplexing (FDD) radio technology, the ordinary clock must be capable of algorithmically filtering for the true rate of change in the PRTC timestamp generator to deliver the radio drive clock with better than 16 ppb in the target fundamental frequency.

For basestations with time division duplexing (TDD) radio technology, the ordinary clock has to derive precision frequency and “phase.” In this context, phase is the incidence in time when the GPS 1 pps occurs in the PRTC timestamp generator. All basestations in the cluster or alignment community need this coincidence of phase occurrence. The “type” of radio determines the phase coincidence requirement. The Third Generation Partnership Project (3GPP) and International Telecommunications Union (ITU) standards organizations define those requirements.

According to the 1588 protocol, the master sends a 1588 frame called the “Sync” message and inserts a timestamp at the time-stamping point. The slave receives the Sync message with the timestamp inserted by the master clock. For frequency recovery, this is all that is needed for the algorithm to derive a frequency reference for the basestation. 

But if phase and time-of-day (ToD) are required, as for LTE TDD and LTE-Advanced, the slave has to be able to measure the flight time of the packet from master to slave to synchronize the 1-pps rollover between the master and slave and calculate the time at the slave. To do so, the slave sends a “Delay_Request” message back to the master.

The delay request message does not include a timestamp. It simply remembers the time it sent the Delay_Request message. The master then sends back a “Delay_Response” message. The Delay_Response message includes the time at which the master received the Delay_Request message. So, now the slave has four timestamps altogether. From these four timestamps, the slave can calculate the flight time of the packet. 

The mathematical expectation of the 1588 protocol is network path symmetry. This means the protocol assumes the upstream and downstream paths between the grandmaster clock and ordinary clocks are equal in the flight time of packets between them. The path delay in each direction is made up of three types of delay component: link distance, serialization, and packet delay variation.

Link distance and serialization rate offsets are the two static asymmetry components. This means they don’t change and are “invisible” to the algorithm in the ordinary clock. Careful network engineering practices can minimize both of these sources of impairment.

The third delay component is the actual variation in packet delay propagation as packets pass through the intermediate nodes between the grandmaster and ordinary clocks. This packet delay variation (PDV) is the primary cause of 1588 ordinary clock computation errors.

The 2002 version of the standard was created for use on single segment Ethernet local-area networks (LANs). It was prohibited for “sync” packets from a grandmaster clock to “cross” LAN boundaries. The 1588 boundary clock (BC) was designed to straddle the interface between two Ethernet LANs. The side of the BC on the LAN interface with the grandmaster clock operates as an ordinary clock. The side of the BC on the other side of the LAN segment interface acts as a grandmaster to the ordinary clocks on that segment.

The PDV of a single-segment LAN is non-existent, so the BC was able to transfer the time base of the true grandmaster to its community of ordinary clocks with virtually no phase of frequency offset. The BC also prevented the cross segment ordinary clocks from “seeing” the actual grandmaster, reducing the load on that clock.

The transparent clock (TC) was created for the updated IEEE 1588-2008 version of the standard out of the recognition that 1588 packets would be traveling over large networks that would have numerous intermediate nodes between the grandmaster clock and the ordinary clock. It was also understood these intermediate nodes would add PDV to the flight times of each packet, which could result in a flight time asymmetry on the upstream and downstream paths.

Two versions of the TC were defined: end-to-end and peer-to-peer. The TC is “transparent” to the transport network protocol used by 1588. As the various TC components “measure” the delays in the nodes and links, these measured values are placed in a 1588 packet field named the “correction” field.

As each pair of TC components makes a time measurement, the result is “added” to the correction field. These time measurements are expressed in nanoseconds. When the 1588 packet arrives at its targeted ordinary clock, the 1588 protocol calls for the clock to extract the contents of the correction field and subtract the correction field value from the computed flight time derived by the difference in time base value between the “master” and ordinary clocks’ time bases. The expected result of this process is a drastic reduction in realized PDV, making the ordinary slave clocks’ filtering algorithm less complex and less costly.

The ITU-T formed a study group to work on the creation of IEEE 1588-2016 because of numerous incongruities and vagaries in IEEE 1588-2008 needing clarification or definition. As spectrum usage becomes more and more densely packed, tighter control of frequency precision and shrinking of guard band periods will be inevitable. This is done with more precise timing delivery and alignment capability.

The future of extremely precise timing delivery will almost certainly be a standards-based interaction between an IEEE 1588-type terrestrial timing delivery, combined with a more secure GPS/GNSS delivery system to master clocks. IEEE 1588 is the only standardized terrestrial mechanism today to deliver phase/time via a packet-based network with nanosecond accuracy.

Martin Nuss is the CTO and vice president, technology and strategy, of Vitesse Semiconductor. He also serves on the board of directors for the Alliance for Telecommunications Industry Solutions (ATIS). He is a fellow of the Optical Society of America and a member of IEEE as well. He has a doctorate in applied physics from the Technical University in Munich, Germany. He can be reached at [email protected].


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.