Time Synchronization in Telecommunication Networks

Ques: How do we synchronize the clocks across nodes in a telecom network?

Answer: Instead of relying on nodes “keeping” their own sense of time, the time is “distributed” across the network hierarchy.

Two promising solutions: Synchronous Ethernet and IEEE 1588 are presented in this article as well as their “combination” to deal with the synchronization challenge. Ultimately, the synchronization achieved is measurable both qualitatively and quantitatively using various tools and methods that are further discussed.

The new-age network deployments

It is a fact that the service providers have huge investment in legacy TDM, SONET/SDH, ATM network and equipment, however, what is also true is that they are cashing-in on the disruptive Ethernet technology (The reason is as the traffic grows exponentially along with demands for speed, bandwidth, choice, service, reliability and newer applications; service providers are looking upon on newer and better technology to retain their profit margins) by moving to IP or MPLS.

This is a move from a time-synchronized to an asynchronous medium. Although it is financially beneficial, it is also detrimental for the applications and services that rely fundamentally on the accuracy of time. These applications are designed for a network that has a small and discreetly measurable transmission delay and a significantly lower delay variation, both of which are absent in Ethernet.

A typical service level for an application/service could be:

Frame delay < 10ms
Frame delay variation 2ms
Frame error rate 0.0001%
Service disruption 50ms
Network availability 99.99%
Mean-time to repair 2h

Table: Service levels for mobile back-haul services
(Source: ADVA optical networking)

Related:  IEEE-1588 Software Design and Multi-core

Ironically, this changing scenario is the reason that we are discussing synchronization in an asynchronous network.

Timing is Fundamental

Time (and its perceived accuracy) depends upon what use we put it to.

  • Flight delays are not measured in seconds.
  • Getting your car repaired may take extra ten minutes.
  • A delay of one-day in construction may not be matters of any escalation or complaint.

We (always) have an implicit margin and a different expectation for different tasks/jobs.

Reduction of these delays, by efficient processes and technology, is sometimes taken as a measure of progress and it is worth noting that that we have come a long way from pendulums to atomic clocks. The smallest measured time till current day, is 20 attoseconds (10-18) and the theoretically derived lower limit of time measurement is 10-44 seconds, known as the Planck Time (tp). As we keep on overcoming various physical limitations, this gap would go on decreasing.

For the computing machines, needless to say, one second is a very long interval. Unlike us humans, they can talk to each other in nanoseconds and feel annoyed for micro-second delays. Just to put this into perspective:

  • A nanosecond (10-9) when compared with 1 second (in terms of length) is analogous to a measurement accuracy of size of a virus or a DNA helix while measuring the height of an average human being!

Other analogies (in order of magnitude) for comparing one nanosecond to one second are:

  • 1 paisa in 1 crore rupees
    (or 1 cent in 10 million dollars)
  • Speed of an electron versus a snail.
  • Nerve cell potential versus a Lightening strike.
Related:  What is Plesiochronous

Time is one of the most accurately measured quantities and, considering this, it is really a big achievement, when we say that a Cesium clock has an uncertainty of 5.10 x 10-16 (Error of 1 second in 60 million years!). We refer to these clocks as “Stratum-0” clock sources.

Strict timing and accuracy is needed for accurate multiplexing/de-multiplexing, framing, encoding and decoding in SONET/SDH and PDH networks, Latency measurement, etc. These requirements are at the core, edge, aggregation, access, operator and customer ends. Applications like VoIP and alike degrade in absence of strict timing. We do not have longer or shorter bits beyond a defined “explicit” margin, and if we have, we treat them as errors.

The two questions to ponder before proceeding are:

  1. Why can’t an oscillator produce 125 MHz when it is designed to vibrate at 125 MHz?
  2. Does it matter if you wear a Tissot/Rado or a Rolex, but forget to set the time in either?

Think about it, add a comment… and we shall explore this further in my next post….



Related posts

4 thoughts on “Time Synchronization in Telecommunication Networks”

  1. […] (Continuing from the previous post: “Clock Synchronization in Telecommunication Networks“…) […]

  2. […] Clock synchronization in Telecommunication Networks (The Need) […]

  3. […] continuation of time-synchronization article series, conceptually, IEEE-1588 synchronization is as simple as if you were asking the time from somebody […]

  4. […] among the available products in market and appreciate them better (after having gone through the Synchronization basics and timing-protocols and the technology-comparison etc). Two measures of quality of any single […]

Leave a Reply