IEEE 1588

IEEE 1588 Unplugged – An introduction to IEEE 1588

SYNOPSIS Synchronization becomes a necessity when devices working at a distance from each other must also work in conjunction. In such scenarios, a local clock, or Master Clock, synchronizes with the device clocks networked within the same system. Due to this need for synchronization, IEEE 1588 was released as a standard of protocol in 2002.

However, if two clocks are set at the same rate, there is no guarantee that they will stay in synchronization. This is why the process of synchronization is continuous. Several factors can cause two identical clocks to lose synchronization. Causes such as differences in temperature, the age of the clocks themselves, and the rate of frequency can all affect the quality of synchronization. It is because of these factors that a need for clock synchronization arose.

SYNCHRONIZATION IEEE 1588 provides fault tolerant synchronization for different clocks along the same network. There is very little bandwidth consumption, processing power, and setup. IEEE 1588 accomplishes all of this by using the precision time protocol, or PTP. The time protocol synchronizes all clocks within a network by adjusting clocks to the highest quality clock. IEEE 1588 defines value ranges for the standard set of clock characteristics. The Best Master Clock (BMC) algorithm determines which clock is the highest quality clock within the network. The BMC (grandmaster clock) then synchronizes all other clocks (slave clocks) in the network. If the BMC is removed from the network or is determined by the BMC algorithm to no longer be the highest quality clock, the algorithm then redefines what the new BMC is and adjusts all other clocks accordingly. No administrator input is needed for this readjustment because the algorithm provides a fault tolerant.

Bidirectional Multicast Communication is used by the slave clocks to synchronize to the IEEE 1588 grandmaster clock. A ‘sync’ packet containing a timestamp from the grandmaster clock contains the exact time that the timestamp left the grandmaster clock. A ‘follow up’ packet may also be sent by the grandmaster clock which contains the timestamp of the ‘sync’ packet. This allows an accurate timestamp of the ‘sync’ packet by the grandmaster clock. There are times when the exact transmission time is prevented from being known until the entire packet is sent without and collisions detected. This is because of the collision detection and random back-off mechanism of Ethernet/IP communication. Once the packet is completely sent, it is impossible to alter the packet’s contents.

The grandmaster and slave clocks trade ‘sync’ packets back and forth and timestamp the transmissions upon receipt. By combining the slave’s offset from the master and network propagation delay, the difference of the ‘sync’ packet’s departure and arrival timestamps can be calculated. Using the offset measured at this point, the clock can readjust itself and the offset between master and slave can be reduced to the network propagation delay only. The delay between master and slave ‘sync’ packets, and vice versa, implies that IEEE 1588 operates on the assumption the network propagation delay is symmetrical. It is because of this assumption that slave can determine and readjust for the propagation delay. In order to do this, the slave creates a ‘delay request’ packet and timestamps it upon departure. The master clock then timestamps the packet upon receipt and sends it back to the slave, a ‘delay response’ packet. The network propagation delay is then determined by finding the delay between these two timestamps.

The sending and receiving process of the synchronization packets allows the slave clocks to accurately measure and offset between the salve’s own clock and the master clock. Standard methods of clock adjustment implementation are not outlined by IEEE 1588; it only provides a standard protocol for the exchange of messages between clocks. The benefit of this is that clocks from different manufactures are still able to synchronize with each other.

QUALITY OF SYNCHRONIZATION There are several factors that can affect the exactness of synchronization between clocks within an IEEE 1588 network. Frequency changes in the a clock’s local timing source, which may occur in between in ‘sync’ packets, can cause a clock to lose synchronization from the other clocks in the same system. In order to counteract any possible lost synchronization, high stability timing sources can be used, as well as shortening the time in between ‘sync’ packets. To further improve the timeline of synchronization, Temperature Controlled Crystal Oscillators (TXCOs) and Oven Controlled Crystal Oscillators (OCXOs) can be used. A clock’s resolution can also affect the preciseness of the timestamps sent in the precision time protocol. The higher the clock’s resolution is, the more accurate the timestamp on the ‘sync’ packets. Jitter from an intermediate networking device, such as hubs and switches, can also affect the system’s accuracy of synchronization.

The quality of the Ethernet based IEEE 1588 system and how it was setup can also affect the quality of synchronization. To setup the best synchronized system, one must trade-off between exactness of synchronization, cost, and distance needs. For low speed events that do not depend on time, a standard NTP synchronization over internet, which allows for millisecond level synchronization, will suffice. IEEE 1588 is still an excellent alternative for systems needing sub-microsecond synchronization in geographically arranged systems.

NETWORK HIERARCHIES IEEE 1588 boundary clocks, also known as transparent switches, are an effective way to reduce jitter found in an Ethernet based IEEE 1588 system. A switch, acting as a boundary clock, runs the PTP protocol and is synchronized to the master clock. The boundary clock in turn acts as a master clock to all slaves within the same network. Using this setup, all internal latencies and jitter can be compensated for and does not affect the exactness of the synchronization.

Delay_Resp, Delay_Req, Follow_up, and Sync messages are not passed by boundary clocks. The boundary clock’s port will behave like an ordinary clock in regards to synchronization and the best master clock algorithm within a subnet. Whichever port of the boundary clock identifies the master clock will be selected as the slave port. Within the selected subnet, this port is a slave. This will then cause all other ports of the boundary clock to synchronize to the slave port. A parent-child hierarchy of master-slave clocks is determined by the boundary clocks. If cyclic path occur in the network hierarchy, the best master clock algorithm lowers the logical hierarchy to an acyclic graph.

There is an alternative to boundary clocks, which is the use of transparent switches. A transparent switch does not behave as a PTP node within an IEEE 1588 system. Instead, a transparent switch alters the timing contents of PTP packets to compensate for the delay caused by the switch. A transparent switch then calculates how much time a ‘sync’ packet spends within the switch and modifies the timestamp of the immediate ‘follow up’ packet to make up for the delay. PTP nodes can operate as if they were part of a large LAN segment connected by hubs by using transparent switches.

USES FOR IEEE 1588 Precise synchronization would be valued in these applications:

Telecommunications

Power Plants

Industrial Automation

Test & Measurement

Robotic Control

Product Selector

Connect your:

To a:

If you can't seem to find the product that you need don't hesitate to give us a call.
1800 821 496

Testimonial

We provide different PLC platforms depending on customer requirements and I have found the 460MSA and 435NBX gateways from RTA to be user-friendly and have cut down our project configuration time considerably. The web interface saves time in not having to lug a laptop out to the field to make changes and the user manuals are straight forward and informative.