IEEE 1588-2008 perspectives and opportunities

The revised Precision Time Protocol presents opportunities and some real-life challenges.

André Marais, Symmetricom Inc -- EDN, October 21, 2010

View as PDF

The PTP (Precision Time Protocol), which the IEEE defined under 1588-2008, represents a step change in the distribution of time and frequency across WANs (wide-area networks). The telecommunications industry is, in parallel, evolving to packet-transport systems, isolating services and systems from their clock sources. As a result, the mobile sector, in particular, represents the first large-scale opportunity for IEEE 1588.

Synchronization defined

The words you speak and the images you see are analog, but transporting these base signals on a large scale is impractical. To make the process manageable and scalable, you digitize the signals and transport them over synchronous networks. A common frequency digitizes and rebuilds an acceptable reproduction of the voice and video signals at the remote end, meaning that the frequency at the source must be the same as the frequency at the destination. The transport networks also need a stable frequency for capacity multiplexing, service encoding/decoding, and quality-of-service measurements.

Every location in the network must operate at the same frequency, or exhibit synchronization. TDM (time-division-multiplexed) networks transport frequency, and the local oscillators in all transport and switching devices can connect to a centralized primary reference clock with accuracy of 1×10⁻¹¹ or better. Unfortunately, TDM networks do not seamlessly transport the frequency, and this issue affects the clock’s quality as the clock passes through the network. Synchronization-supply units remove the jitter and wander that affect the instantaneous frequency stability.

The universal demand for broadband data, especially mobile broadband services, and the price that consumers are willing to pay have driven a change in transport technologies. IP (Internet Protocol)-based packet networks increase the bandwidth and reduce the cost per bit transported. L2/L3 (Layer 2/Layer 3) packet networks are associated with Carrier Ethernet and IP transport and are now in wide use because they meet the investment goals: increased bandwidth and reduced cost per delivered bit.

L2/L3 networks do not need synchronization to transport packets. By the same token, L2/L3 networks do not transport synchronization, isolating services and applications from their traditional frequency source, the transport clock. Delivering more bandwidth for less, therefore, comes at a price. Synchronization and quality of service are not natural to L2/L3 networks, and engineers must consciously implement them in the system.

Many services need synchronization, but wireless base stations today have the largest stake in frequency and time distribution. The frequency stability of the air interface between the cell tower and the handset supports handing off a call between adjacent base stations without interruption. Synchronization for base stations is therefore central to the quality of service an operator provides.


A high percentage of the 2.3 million cell sites in service today depend on the TDM backhaul for their frequency source. Backhaul is the voice- and data-transport system between the cell tower and the centralized controller. Cell-phone users’ wide adoption of mobile broadband has led to a transition from TDM to Carrier Ethernet, isolating the base stations from their traditional clock reference. The industry cannot avoid the Ethernet migration, and it now requires a different but cost-effective method of delivering synchronization to base stations.

IE 1588 overview

The IEEE created Version 1 of the 1588-2002 standard in 2002 to provide precision timing across LANs (local-area networks) for test-and-measurement and industrial-control applications. Segments of these industries needed to provide widely distributed sensors and actuators with a common time for coordinated measurement and control but without the need for an overlay timing infrastructure. The timing had to travel inband with the sensor traffic.

IEEE 1588 allows the accurate transfer of precision time from the master clock to the client clock through an asynchronous packet network. IEEE 1588 devices have a tree hierarchy, with the master clocks residing in centralized facilities and slave devices residing in remote locations that require time, frequency, or both. Note: This article uses the terms “grandmaster” and “server” interchangeably; it also uses the terms “client” and “slave” interchangeably.


It is difficult to know in advance the time when the packet will leave. In most cases, protocol designers add an optional second step. The two-step approach lets the Sync message transport the estimated value of t1; the Follow_ Up message transports the actual value of t1, thus eliminating estimation errors. The slave uses t1, t2, t3, and t4 to calculate the round-trip delay and the clock offset—the difference between the server clock and the slave.

Assume that the one-way delay is half the round-trip delay. You can then determine the slave-clock offset using the following equations: (one-way delay)=[(t2−t1)+(t4−t3)]/2; slave offset=(t2−t1)−(one-way delay). You can now correct the slave-clock time using smoothing techniques and clock-offset values. A servo loop supports the recovery of frequency from the time-of-day clock. The process repeats multiple times a second, keeping the two clocks the same, or synchronized.

Precision with 1588-2008

Version 1 of the 1588 protocol provided an effective method of distributing precise time over LANs, grabbing the attention of the telecommunications industry. Teaming with test-andmeasurement and industrial-control partners, the IEEE developed a second version of the 1588 protocol to support WAN requirements. The result, IEEE 1588-2008, or PTP Version 2, includes a number of improvements to support the stringent needs of the telecommunications network. These improvements include higher message rates, hardware time-stamping, shorter message formats, unicast messaging, service reliability, and 1588 profiles.

The need for higher message rates arose to meet stability objectives. Using inexpensive client oscillators, the client must undergo more frequent updating. The revised PTP standard supports as many as 128 transactions/second, a large increase over the original maximum of one transaction/second.

Although the standard does not explicitly require hardware time-stamping, more frequent time-stamp updates have no value unless they are accurate. Hardware time-stamping on both the master and the client delivers the targeted submicrosecond accuracy.

To reduce the impact on network-bandwidth consumption, PTP shortened the original 165-octet (8-bit) message to 44 octets by placing information about the clock source and quality into a separate Announce message, which transfers less frequently.

The original standard supported only multicast message exchanges. IEEE 1588-2008 added support for unicast messaging. Unicast allows each client to listen to messages only from its master, reducing the processing power and cost of the client. More important, unicast messaging allows a unique relationship between the client and the server, supporting different synchronization messaging rates, inband status, and performance monitoring.

Carrier-class service means few outage minutes per year. In reality, some packet network paths experience occasional failures. L2/L3 networking takes care of rerouting the data, but interruptions in IEEE 1588 flows have a higher impact. IEEE 1588-compliant clients can select an alternative network grandmaster if the primary one fails.

The protocol specification aims to satisfy a range of applications and to achieve a specification with many options, including unicast and multicast. The IEEE created application profiles to ensure interoperability. Profiles define which options in the protocol specification clients must use. They also stipulate the interoperation of servers and clients that adhere to the profile definition.

IEEE 1588 defines only the default profile, which targets use in industrial-automation applications. The telecommunications industry has defined a telecom profile in the ITU-T (International Telecommunication Union-Telecommunication Standardization Sector) G.8265 recommendations. The protocol has defined new profiles, and compliance with the correct profile is as important as compliance with the overall specification.

Impact on performance

The clock-recovery algorithm has the biggest impact on the performance of a 1588 system, but network behavior also defines the attainable performance. Packet delay, or latency; packet loss; and packet errors typically characterize network performance. These attributes, however, have almost no impact on packet-timing protocols.

The distinction is often blurry between managing the packet-network metrics and managing 1588 performance. Packet statistics are not sufficient for managing and reporting on the synchronization system. In addition to the network behavior, high-quality oscillators have an inherent stability that improves the quality of the output frequency and phase. Product designers must find a balance between the cost of the oscillator and the desired performance.

Making it work

IEEE 1588 has the potential to become as ubiquitous as NTP (Network Time Protocol), but reaching that milestone means that multiple markets and applications will need to adopt it. The simplicity, scalability, and interoperability of the components will, however, define the extent to which 1588 will achieve that goal.

A time-and-frequency approach is only as good as its component parts. The origin of the time and frequency is the grandmaster clock (server). The IEEE 1588 time originates at the server and propagates through the network to the clients. Grandmaster clocks start with a good reference source, such as a GPS (global-positioning system) for time and frequency or a T1/E1 reference signal from a collocated primary reference clock. Because most server clocks now use GPS receivers, many industry participants consider IEEE 1588 as a distributed-GPS scheme. In addition to the source reference, grandmaster clocks should have high-quality oscillators to maintain accuracy if the system loses the reference for a time.

Grandmasters serve synchronized flows to many clients, so the serving capacity of the server is important. For example, a network with 300 clients using 64 transactions/second translates to a server capacity of 39,000 messages/second. The servers must hardware time-stamp the Sync and Delay_Req messages.

Because server clocks are so important, you must eliminate single points of failure. A high-quality server has redundant power supplies, redundant clocks, and network-interface protection. Wide deployment also means that you must be able to remotely monitor, manage, and upgrade the servers.

The server is central to synchronization, and it must be accurate, stable, and reliable. The client, however, has a tougher job. It lives at the end of the network and must contend with what is happening both in the cloud, including traffic levels, failures, and rerouting, and in the local area, including temperature changes and power-supply failures.

The fundamental choice for PTP Version 2 clients relates to oscillator quality, cost, and form factor. The better the client’s local oscillator, the better it can handle whatever comes its way. However, better oscillators cost more, and reducing cost is the ultimate goal with the cellular-backhaul packet upgrade. The best PTP clients support as many as 128 messages/second and use hardware time-stamping to minimize induced jitter. The design of the oscillator servo is just as important to getting frequent low-jitter time stamps. The servo is the circuit in the PTP client that directs the oscillator to speed up or slow down after the reception of a new message. With good design of these factors, the best PTP clients can support cellular-backhaul frequency and time-reference requirements with low-cost oven-controlled crystal oscillators.

The best PTP Version 2 clients support the best-master-clock algorithm to reduce timing transients during path reroutes and unicast to allow the tuning of message rates for the best performance. Also, some network operators like to manually assign PTP clients to primary and backup grandmaster clocks. In this way, the operators will know the effect of network outages on each client. The best PTP clients allow this approach. Another feature of same-vendor PTP grandmaster-clock/client combinations is the ability of clients to report their performance status, enabling operators to conveniently monitor timing quality of service.

Monitoring servers is easy; users have for many years been managing similar devices over DCNs (data-communication networks) in centralized locations. But the timing community has never had to manage tens of thousands of devices, especially in situations in which they are beyond the reach of the DCN. In addition, client installations are at the ends of multiple VPN (virtual-private-network) links or on Ethernet segments that you cannot bridge to the DCN, and data connectivity between the client and element manager is impossible.

Monitoring the clients, whether external or embedded, must occur in telecommunication applications. Fortunately, the 1588 designers included management messages for inband management through the server. Element managers can access and monitor the installed clients through the server. Features such as client auto-discovery and bulk firmware upgrades allow the deployments to scale.

Simple deployment guidelines ensure the best 1588 results. First, select a high-performance, high-reliability grandmaster clock (server) that has the capacity for the number of clients you expect now and in the future. Second, select a high-quality 1588 client that works over the protocol in use—for example, native Ethernet, Ethernet over SDH (synchronous digital hierarchy), microwave, and xDSL. Embedded clients will become commonplace, but standalone clients reduce early deployment risks and serve the large installed base of legacy devices that can accept only the T1/E1-synchronized reference. The next step is locating the servers by determining the message rate of the server and the PDV that each client will experience. Cost considerations encourage the use of fewer servers functioning through more switches and routers, and robustness calls for the use of more servers with fewer links between the server and slave. The application will govern the balance between the two, with telecommunication networks favoring robustness. You can check the grandmaster’s capacity by dividing the maximum transaction rate by the number of served clients and the number of transactions per second. If the demand exceeds the capacity, you can add modules or even grandmasters to share the load. Served clients are the clients that should routinely obtain synchronized flows from a grandmaster and those that could request the service if their grandmaster’s clock fails. Finally, each client must have access to a backup grandmaster clock in the case of failure.

Beyond telecom

IEEE 1588 is a new utility, and the network is the only limit on the applications for this utility. IEEE 1588 will work for any network-connected application, service, or device that needs time, frequency, or both. The industry will develop new 1588 profiles for different applications. Mobile-backhaul applications now have the largest interest in 1588 and should drive high-performance approaches that will operate over diverse and congested networks.

Other applications for IEEE 1588-2008 include industrial automation, distributed test and measurement, military deployments, and distribution of time to power-industry secondary plants. These examples are not exhaustive but demonstrate the wide applicability of IEEE 1588 beyond the telecommunications sector.

Getting to market

Grandmasters will find wide deployment, and they typically work with small, half-rack 1588 clients—translators that convert IEEE 1588 synchronized flows to TDM signals. Embedding IEEE 1588 clients is a natural differentiator between similar products, and leading network-equipment manufacturers are integrating clients into their products.

Time to market is critical, and embedding third-party clients supports product differentiation and reduces development time. Clients are the most sophisticated elements of the technology, and you should leave the clock-recovery and servo algorithms to the specialists. Fortunately, soft clients and integrated chip modules are readily available for embedding into products.

It is important to note that PDV patterns are different for native Ethernet, microwave, and xDSL. Understanding the network is important when selecting third-party clients. Soft clients are typically more dynamic and easier to upgrade.

The road ahead

IEEE 1588-2008 is a viable means of distributing time over LANs and WANs, and it repairs the broken synchronization chains through packet networks. The protocol has reached specification maturity, and the road ahead involves simplifying the implementation of 1588. Focus areas for the short term include defining application-specific profiles and characterizing the behavior of physical layers on the end-to-end performance of the system. Building on that knowledge, you can expect high-performance autosensing algorithms for client devices. The industry will also focus on developing metrics that characterize a network’s ability to support 1588, test tools to measure those metrics, and deployment and troubleshooting of the test tools.

IEEE 1588 is a new utility for distributing precise time and frequency over packet networks for a range of applications. With a considerable amount at stake, the telecommunications industry has led the way, particularly in the mobile-backhaul arena. Alternatives to 1588 exist, but no one-size-fits-all option exists. As a result, these options will find use in some areas of the network. IEEE 1588, however, exceeds the target of 16 ppb and meets the 3-µsec phase-accuracy goals over managed Ethernet, making it the preferred approach, particularly for the time-constrained TDD (time-division-duplex) and MBMS (multimedia-broadcast/multicast-service) modes of LTE (long-term-evolution) technology.

A lot has been learned from efforts in the telecommunications market, as reflected in the solution sets deployed in adjacent markets. Ultimately, product managers can differentiate products that depend on time, frequency, or both by embedding IEEE 1588 clients into their platforms. Proven off-the-shelf clients will allow engineering teams to meet R&D plans and deliver high-performance products.

---

Reference

"Evolution to LTE," Global Mobile Suppliers Association, Aug 26, 2009, www.gsacom.com.