Basics of real-time measurement, control, and communication using IEEE 1588: Part 5
In many ways, the requirements of the telecommunications field appear at odds with the design objectives for the original IEEE 1588 standard discussed in earlier Part 1, Part 2, Part 3 and Part 4 in this series.In particular, IEEE 1588 was designed for localized industrial and instrumentation networks, hardly a description of a telecommunications network. Yet, at the very first IEEE 1588 conference in 2003, a paper was presented by Glenn Algie of Nortel [50], outlining how IEEE 1588 could be used to solve some of the emerging problems in telecommunication systems.
Since this initial presentation, there have been discussions and presentations of IEEE 1588 at several telecommunications forums, including papers by Algie, Algie and Ouellette [78], Rodrigues [83], Tonks [51], and Zampetti [85].
There have been several field trials of various implementations of IEEE 1588, but as yet no announced commitments by any telecommunications standards body, service provider, or equipment manufacturer to provide IEEE 1588-based technology in telecommunications.
This situation is expected to change but for now this discussion remains highly speculative. Much of the material in this section is based on private conversations with Glenn Algie of Nortel, and unpublished memoranda from Doug Arnold of Symmetricom, Silvana Rodrigues of Zarlink Semiconductor, and Dave Tonks of Semtech.
![]() |
| Figure 9.1. Proposed uses of IEEE 1588 in telecommunications (courtesy of Nortel) |
Background on using IEEE 1588 in
Telecom Systems
Algie envisioned the system illustrated in Figure 9.1 above. Shown in this
figureare the metropolitan core and collector networks that form the
backbone of the telecommunications systems found in most large
metropolitan areas.
These networks typically are formed with SONET and other circuit-switched network protocols. As everywhere else, there are economic forces that make the use of Ethernet-based technology attractive for this application.
Indeed, there is a trade association—the Metro Ethernet Forum1—formed with the explicit purpose of promoting the use of Ethernet in this, and other related applications. The primary driving force is the switch from circuit-based to packet-based communications for voice-over-IP (VoIP) applications.
Unfortunately, the packet-based networks do not provide the same level of timing services to enterprises as those currently derived from the circuit-switched networks.
Connections to various users are made via routers and switches located at points on the collection rings. Typical services are represented by the lettered squares A, B, C, E, and K in the figure. Each of these is separated from the core networks by a boundary termed the "user-network interface", or UNI.
In the original presentation of Algie, a number of services were identified that could benefit from timing distributed using IEEE 1588. These proposals, and others that have emerged from the presentations and discussions cited earlier are summarized here.
Algie proposed providing a stable source of IEEE 1588 timing packets to be distributed over the metro core networks. These source devices are illustrated in Figure 9.1 by the items X, Y, and Z that represent stratum 1 traceable clocks implementing IEEE 1588 master clock functionality.
These devices could be owned by the telecommunications service providers, as illustrated by items X and Y, or could be provided from the enterprise side of the UNI demarcation, as shown by item Z.
The timing information would be recovered at edge points G, B, C, E, and K. These can be on either side of the UNI demarcation. The recovered timing signals would then be used by the associated enterprise services.
The actual timing requirements for the proposed services vary. Some will require only highly accurate frequency information, whereas others require epoch information as well.
IEEE 1588 was not designed to distribute timing information over the networks topologies proposed for telecommunications. Even within a metropolitan area, the core networks will encompass many switches, each of which introduces appreciable timing fluctuations.
The method IEEE 1588 specifies for overcoming router and switch timing fluctuations is the boundary clock, and depending on the outcome of the current standardization efforts, the transparent clock.
It is unrealistic to simply assume that telecommunications companies are going to replace existing networking equipment with routers and switches that implement IEEE 1588.
If IEEE 1588 is to work as proposed, something must be done to overcome the network timing fluctuations. If epoch is important, then it will also be necessary to somehow control the symmetry properties of the network.
As the following discussion will make clear, some of these measures require special configurations of network properties such as routing tables.
Is it reasonable to expect telecommunications providers to engineer their networks for the purpose of meeting the requirements of IEEE 1588? The likely answer is yes, if they are convinced that IEEE 1588 will actually provide the needed timing using the packet-based networks.
The reason for this optimism is that these companies do this for the current circuit-switched technology. In existing switched networks, there is an elaborate system for distributing frequency based on in-line signals in the data streams between network devices.
A system of primary reference clocks (PRCs) has been established, with elaborate provision for redundancy, alternate paths, and recovery procedures. This system has required the telecommunications companies to not only engineer their networks, but also to use special equipment to recover the timing.
However, to make the initial inroads, a technology such as IEEE 1588 must be able to demonstrate adequate performance for an economically attractive set of applications using the existing network equipment.
Currently there are a number of promising proposed applications of IEEE 1588 in telecommunications in wireless networks, linking SONET rings via Ethernet, Cable TV and Internet TV, central office systems, TDM circuit emulation, and for internal timing in a wide range of telecommunication router and switching equipment.



Loading comments... Write a comment