IEEE-1588 PTP protocol evolution

IEEE 1588 is the standard specification for the Precision Time Protocol (PTP) with the version 2 being the commonly deployed implementation. The IEEE-1588 PTP protocol evolution over more than a decade from v1 to v2 to v2.1

IEEE-1588 PTP protocol evolution

The first version (v1) specification released in 2002. This standard is known as IEEE1588-2002. There are some audio devices that conform to older v1 specification but as such v2 is not backward compatible to support that.

A major update (also not backward compatible) was made in 2008 calling it a version 2.0 and remains the most widely deployed implementation in the networks that require synchronization. This standard is known as IEEE1588-2008

A recent update as new as 2019 bumps up the version to 2.1 indicating that it is compatible with v2 however comes with newer features. This standard is known as IEEE1588-2019

PTP v1 vs v2

The major improvement / update in 2008 (v2) was the introduction of:

  • Transparent Clock
  • Two-step mode
  • Peer-Delay mechanism
  • IPv6 support
  • Unicast support
  • Increased message rate

PTP v2 vs v2.1

The improvements / updates in 2019 (v2.1) was the introduction of:

  • Special ports that inherently support timing (eg. WiFi 802.11, EPON etc)
  • Multi-domain interactions
  • Acceptable Master Table based on port-Identity
  • Updates to clock Identity
  • Dataset updates for Transparent clock
  • Not compatible for 2002 standard
  • Holdover-Upgradable capability
  • Domain subparts with sdoId
  • Calculation of MeanPathDelay in multiple domains

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

What is PTP (Precision Time) – An Online Training

Get a deep-dive as well as extent of the Precision Time Protocol (PTP) with the online training. It includes the time/clock concepts, software, hardware and various use-cases as well as different Network architectures in small and large deployments.

What is PTP (Precision Time) – An Online Training

This is a paid training with premium content being added continuously. To support this effort, a nominal charge gives you access to this constantly-updated material for a limited duration. Please use the below course-contents and the form to enquire further.

There are some example links that you can browse as you make your request. Each 1-to-1 session is customized to your background and existing knowledge so that you can come up to speed on PTP as soon as possible.

PTP Course Contents:

  • Fundamentals of PTP
    • IEEE 1588v2 Precision Time Protocol concepts
    • Master, Slave and Intermediate nodes
    • Timestamping and PTP Event Packets
    • PTP General and Management packets
    • Evolution of PTP protocol
  • The Best Master Clock Algorithm (BMCA)
  • Clock synchronization concepts
  • Comparison – SyncE, NTP, PTP
  • Types of clocks:
  • Clock Modes
    • End-To-End Delay Mechanism
    • Peer-To-Peer Delay Mechanism
    • Clock Steps (1-step and 2-step)
  • Transport Modes
    • Ethernet and IP transports (v4 and v6)
    • Unicast and Multicast transports (and Hybrid)
  • QoS considerations for PTP
  • Multicast consideration for PTP
  • Detailed Protocol Functionality
    • Control Packet Exchange
    • Mandatory Correction Field updates
    • Configuration and Wireshark logs
  • Testing 1588 PTP
  • Multi-hop Network Topologies
    • Full-Path PTP Network
    • Partial PTP Network
    • Packet Delay Variation (PDV) considerations
  • IEEE 1588 (Default) and other profiles
    • Broadcast (SMPTE/AES/R16)
    • Power Profile
    • Telecom
    • Other user-case and verticals (like Industrial)
  • Interactions of NTP and PTP
  • PTP software stacks and drivers

RSVP

Show your interest or send your requirements and we shall get back:

You shall receive confirmation mail of your request and we shall discuss all the things you require to be covered in the training for a fully customized and efficient experience. A calendar will be shared for selecting your comfortable timing over the week and the length of the training will vary based on the contents to be covered.

AVB Endpoints vs Network Nodes

Today we see what are the differences between an AVB endpoint (which are the AVB talkers and AVB listeners) versus an AVB compliant Network node (which connects those end-points to each other in an AVB network).

AVB is an Ethernet based Layer-2 Audio-Video bridging technology (from a Network perspective), however, any vanilla (or even high-end) Ethernet switch cannot be used to connect AVB devices, as it will not be able to provide the required Quality-of-Service though the network or be able to guarantee reservations required by AVB to operate. Let us first see how an AVB enabled Ethernet-switch is different

Normal Ethernet Switch AVB enabled Ethernet Switch
Provides Ethernet Switching capability
Can have 2 or more ports with different port-speeds
Provides MAC learning, switching, filtering etc
Supports VLANs, priorities & Multicast capability
Basically provides Ethernet Layer-2 connectivity
It needs to provide all the features
that a normal Ethernet Switch provides
N/A Needs to provide stream delivery guarantee
Has to synchronise and transfer clock
Support Stream Reservation protocol
Deliver Audio/Video payload without drops
Keep the latency within required margin
Communicate with other AVB nodes

As we see above, an AVB-enabled network gear is specialized in the way it operates and communicates with its peers. Now lets us see, how an AVB end-point is different from an AVB switch itself.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

PTP Master Clocks and GMs

PTP (Precision Time Protocol) Networks are Timing/Clock hierarchies that can support multiple Master(s) and Grand-Master(s) as the source of accurate time. Each clock-node "advertises' its capability (like clock accuracy, its source of time, it own variance etc) into the network.

These PTP networks could be Ethernet, or use IP/UDP as transport protocols or even MPLS. There are implementations and design considerations to support IEEE 1588 on Wireless links too. And then, we have DeviceNet, ControlNet and ProfiNet etc that support PTP.

As we have seen in previous articles, the PTP messages themselves could be transported in a Multicast mode or use Unicast communication, and the recent standard also supports Mixed mode (Unicast+Multicast)

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Hardware Time-stamping in PTP 1588

The Hardware that supports PTP event-message time-stamping makes the synchronization much more accurate. As you can see in the figure below, the same timestamps can be gotten from various layers:

  1. Software
  2. Kernel
  3. Driver
  4. MAC
  5. PHY

The lower (nearer) we go to the physical-layer, the more accurate and exact time we can use to find when a particular PTP packet was received from or transmitted to the line/wire.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

PTP Transparent clocks 1-step 2-step

Why Transparent Clock

Transparent clocks are used in PTP topologies in order to improve the accuracy of the end-station synchronization. The reason is that time-unaware devices introduce varying amount of path-delay between the clock-source (master) and end-station (slave). Unless the master and slave are directly connected, or all the devices in between then are time-aware the inaccuracy increases due to varying amounts of queue-delays and path-delays of different nodes and links.

How Transparent Clocks work

Transparent clocks are much simpler that full-featured Boundary clocks because the aim of a transparent clock is to make itself invisible (of sorts) from their own effect on transport of time across the PTP topology. They do this by timestamping PTP packets as they ingress (with a timestamp T1) and at egress (with a timestamp T2) and putting this delta-difference (T2 - T1) as a correction-field (CF) in the PTP packets. Such a device (called an End-to-End or E2E TC) removes its internal delay (and thus delay-variation) by informing the end-station about its own CF.

Working of a PTP Transparent Clock

Types of Transparent clocks

There are 2 types of Transparent clock:

  • The ones that measure their own delay (E2E)
  • The ones that also measure the link-delay (P2P)

The additional logic in the latter TC is that, it uses PDelay_Req and PDelay_Response packets with its peer-device to calculate the link-delay and adds that to the residence time (T2-T1) calculation ie.

Correction Field = Link Delay + Residence time

There is another way to classify Transparent clocks:

  • The ones that use 1-step clock
  • The ones that use 2-step clock

The difference in the latter is that they use a Follow-up message to convey the Correction-Field as they cannot update the delta (residence time) on the fly.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

IEEE 1588 PTP Clock Modes and Transports

IEEE-1588 PTPv2 has various clock-modes that can work with different Transport-layer technologies like Ethernet, IPv4, IPv6 as well as MPLS, DeviceNet, ControlNet, etc. Here we look at the various scenarios and cases on how PTP can serve different network use-cases with its different configuration combinations.

Ethernet Mode

S. No. Transport Clock Mode Delay Mechanism Clock Steps
1 Ethernet Boundary End-to-End 1
2 Ethernet Boundary E2E 2
3 Ethernet Boundary Peer-to-Peer 1
4 Ethernet Boundary P2P 2
5 Ethernet Transparent E2E 1
6 Ethernet Transparent E2E 2 (2-step)
7 Ethernet Transparent P2P 1
8 Ethernet Transparent P2P 2
Table 1: IEEE-1588 Clock Modes with Ethernet Transport

The PTP communication in Ethernet mode using the specific Multicast MAC address(es). These come in two varieties, the general Multicast address (01-1B-19-00-00-00) and the reserved Multicast address (01-80-C2-00-00-0E). While the former is used to deliver General (Announce etc) and event (Sync, Delay_Req etc) messages, the latter is specifically used for peer-delay (Pdelay_Req etc) messages.

1588 Sync and Delay Req

Let us look at the PTP messages and then map them to each of the modes and transports tabulated above.

S. No. Message Type Destination MAC Timestamps
1 Sync Event 01-1B-19-00-00-00 T1, T2
2 Follow_Up General 01-1B-19-00-00-00 T2'
3 Delay_Req Event 01-1B-19-00-00-00 * T3
4 Delay_Resp General 01-1B-19-00-00-00 * T4
5 PDelay_Req Event 01-80-C2-00-00-0E T1, T2
6 PDelay_Resp Event 01-80-C2-00-00-0E T3, T4
7 #P_Follow_Up General 01-80-C2-00-00-0E T3'
8 Announce General 01-1B-19-00-00-00 NA
9 Management General 01-1B-19-00-00-00 NA
10 Signaling General 01-1B-19-00-00-00 NA
Table 2: PTP Message Types and Destination

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AVB – Traffic Classes

The traffic in an AVB Network is classified into Class-A, Class-B, Control Traffic, and the rest as Best-Effort. These streams are identified by, unique (application generated) Stream-ID, destination Multicast MAC address, and classified based on VLAN ID and priority. Each stream defines the worst-case packet-size, frequency of such packets so that the intermediate nodes know the amount of bandwidth to be reserved to deliver them to the listener(s).

Needless to say, the Audio/Video streams are mapped to the highest priority traffic classes A/B, which are:

  • Class-A streams: Produce frame(s) at 8 KHz (or 125 micro-seconds) and support an end-to-end latency of 2 milliseconds.
  • Class-B streams: Produce frame(s) at 4 KHz (or 250 micro-seconds) and support an end-to-end latency of 50 milliseconds.

This is followed (in priority) by Control Traffic. The control-plane traffic is important for all the state-machines and signaling, however, are not as much latency-bounded as the AV streams. The control traffic is also mostly event-based, majorly non-periodic and much smaller in volume when compared to the AV and other data-traffic. This includes PTP control frames, MSRP BPDUs and other protocol exchange like IGMP and multicast etc.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AVB – Multicast Streams

The Audio Video Bridging (AVB) supports unicast, as well as multicast AV streams. Without going too much into the obvious benefits of multicasting, the AVB uses MAAP (MAC Address Acquisition Protocol) or configured multicast MACs for these types of AV streams. Each multicast stream goes to a unique MCast address.

Furthermore, the AVB multicast is selective in the sense that the streams will be delivered to only those ports where the listeners have requested them and are ready to receive them. On top of this, the MSRP ensures that each node has enough resources to participate in the delivery over the Multicast tree. If no multicast listeners have requested, the talker itself will stay silent.

Multicasting

An AVB Multicast is a Layer-2 (Ethernet based) Multicast, not a Layer-3 (IP based multicast). While it is possible that Multicast IP gets mapped to a Multicast Destination MAC Address, however, the underlying data-flow (for the Audio Video streams) is going to use the Ethernet Muitlcast Destination MAC address to replicate the traffic to the individual ports of an AVB enabled bridge/switch.

Information Flow

The Talkers and Listeners discover and enumerate with the help of AVDECC protocol, while the MAC addresses are assigned by configuration or use MAAP to allocate. Furthermore, the AVTP is used to transfer the AV data payload from the multicast talkers to the listeners. This happens only after the MSRP has ascertained the availability of resources like bandwidth, memory etc for loss-less and low-latency delivery of the AV essence.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AVB – Audio Video Streams

An AVB (Audio Video Bridging) Network consists of AVB-enabled bridges that use the VLAN based priority to classify the incoming streams into traffic classes. Traffic from non-AVB devices or different-domain is considered out of the AVB boundary and treated best-effort.

Talker(s) can create one or more streams and Listener(s) can subscribe to one or more streams. While the intermediate networking devices to monitor the (requested) stream bandwidths and allocate resources to allow/deliver them within the required constraints of bandwidth and latency.

In an AVB N/w, the AV streams are initiated only after:

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

What is Plesiochronous

In this short article and your next 2 minutes, you are going to learn "What is Plesiochronous" and (be careful - once you know it you cannot un-know it), you can brag about this concept (and this seemingly-complicated word) to your friends (and foes). So, what is it? What does Plesiochronous really mean and what is it used for?

It is related to TIME (you guessed it right, due to the word "chronos"), but what is so special? If you have been following this website, we have talked in detail about "time and clock synchronization" in a series of articles, however, Plesio+chornous is "slightly" different (pardon me for the pun).

Well, if two or more things (clocks/actions/waves/bits/pendulums) are "almost" synchronized, but not 100% exactly synced, these are Plesiochornous. This is NOT the same as syntonization.  Here is the summary:

Asynchronous: Without any frequency synchronization. (As the frequency itself is not the same, there is no need to talk of phase synchronization as sometimes you will see them match and other times it will be running out)

Asynchronous Pendulum clocks

Syntonize: To only match the frequency, without regards to the phase. Here the phase difference will be seen but that difference will remain constant, as opposed to what we see in asynchronous system. Mesochronous: Same frequency, however, unknown phases.

Phase difference

Synchronous: In exact lock-step with the source. To synchronize is to match the frequency (and phase) with the source. (Note: The term "phase" tends to become over-encompassing though as we start considering longer duration of time. Eg. Seconds should match exactly, Minutes should also match, so should the hours, and day, month, year, etc. To avoid the confusion with the phase/tick the synchronization of other bigger duration is known as ToD (Time of day) synchronization, not just plain phase synchronization). Isochronous: A term used for the events occurring  at equal time intervals.

Pendulum Clock Synchronous

Plesiochronous: In nominal sync with the source, only slightly different within margin.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Measures of synchronicity – Accuracy of Time

Although it is just easier to buy the equipment available to test the synchronism of two independent systems, we discuss here the measures of synchronicity - Accuracy of Time. The reader would thus be able to choose 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 oscillator and clock are Jitter and Wander. And measures of synchronization achieved between two different clocks or oscillators, through whatever means, are TiE, MTIE, TDEV etc. These are explained further.

Quality of an Oscillator

Jitter

Jitter is any deviation in the rise or fall instant of any pulse, or, change in pulse width introduced due to any such deviation. The best method to visualize jitter is if several clock cycles or pulses are superimposed on one another, the resulting pattern would tend to lose its sharpness and edges for a high jittery clock as compared to a clock that has lesser jitter. Jitter, however, does not mean that the frequency is even marginally different. A 10 MHz oscillator with higher jitter would still oscillate 10 million times in a second; however, not all those vibrations would be of exactly the same width (or duration) and would differ slightly. A few would be a little shorter while others a little longer, but in all divide 1 second into 10 million “almost” equal parts. The preciseness of this “almost” is the Jitter characteristic of the oscillator.

Figure: Non-aligned edges represent Jitter
(Source: RCN)

In the above figure, both the clocks have same frequency, but the jittered clock has its edges displaced off at several instants. Jitter can be caused by power supply noise, heat generated by the oscillator itself and can affect any electronic circuit or system or network or application that is sensitive and requires precise instants for functioning including VoIP and IEEE 1588. The PDV that affects the IEEE 1588 is nothing but “jitter”, and we just call it packet-delay-variation in context of packet switched networks. Jitter is but a statistical dispersion in the delay of events (clock pulses or packets). It can be Gaussian (random) dispersion or deterministic based on duty-cycle or due to interference. Jitter is specified in Unit Intervals (UI), such that one UI of jitter is equal to one data bit-width, irrespective of the data rate. For example, at a data rate of 2048 kbit/s, one UI is equivalent to 488 ns, whereas at a data rate of 155.52 Mbit/s, one UI is equivalent to 6.4 ns. Jitter causes bit-errors in networks.

Wander

Wander is a low-frequency variation in the clock signal when compared to a precise clock. Ideally, a low-frequency jitter is known as a wander and is measured in nanoseconds

Clock Wander vs Clock Jitter

Wander manifest as a phase-shift in the clock over periods greater than one second. Unlike jitter, it is easier to imagine wander as the slight and gradual sways in the speed (ticks) of a clock to and fro, sometimes becoming faster and sometimes slower (due to aging, temperature changes). Wander, since it is accumulating in nature, can only be partly filtered out and causes incorrect synchronization or even total loss of synchronization. Voice calls (fixed or cellular) will be lost, fax machines will misprint, and data will be lost or frequently retransmitted, the reason enough we are studying synchronization here.

Subscribe

Lock

Besides jitter and wander there is “drift” in clock frequency which may be unidirectional, bi-directional or cyclical. Imagine drift as a change in the position of an un-anchored ship on a coast, it may drift away with wind or the waves or come closer. Here coast and the ships are analogous to two different (independent) clocks and if not anchored (synchronized) would drift apart. Eg. On a radio transmitter, frequency drift can cause a radio station to drift into an adjacent channel, causing illegal interference.

Jitter and Wander, both have an amplitude and frequency. Wander variations occur over a period greater than 0.1 s (10 Hz), and vary over time.  Therefore, wander measurements must be performed over a longer period of time (e.g., 24 h). Unlike jitter testing, wander testing requires a very stable reference clock (i.e., a Cesium or Rubidium clock).

Synchronous Ethernet standards have requirements for DPLLS that have strict guidelines for jitter tolerance and introduction by employing anti-jitter circuitry in the hardware. In 1588, the clock servo algorithms should have necessary jitter filtering and PDV filtering. Only then those time-stamps can be used to synchronize precisely.

Quality of Synchronization

TIE

Time Interval Error (usually a time-plot) is the phase difference between the measured signal and the reference signal in nanoseconds.

Your watch is sometimes a few nanoseconds ahead of mine and sometimes behind due to jitter or synchronization latency or some other reason. When this difference is plotted on a time-scale, it shows something like the following figure. The lesser the spread and amplitudes of spikes in this graph, the better the synchronization. Also if you are able to draw a trend-line in this data, it would denote a wander and drift in the clock. The whole idea of 1588 synchronization algorithm is to process the available time-stamps and figure out this trend-line, in the presence of network anomalies and impairments.

MTIE

MTIE plot

Maximum Time Interval Error (or Maximum TIE) is a quantitative measure of the worst case phase variation of a signal with respect to a perfect signal over a given period of time. It denotes a peak-to-peak wander and is a monotonically increasing graph usually on a log scale. In simple terms, over a given window size, the maximum TIE is plotted on the log scale. The window keeps on moving ahead with time elapsed and any new maximums (worst cases) are plotted. Eventually the graph stabilized to the maximum worst-case error seen in that time. The telecom standards have provided masks for the MTIE that define an upper limit for this error for selecting an oscillator or testing synchronized clock quality.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Comparison – SyncE, NTP, GPS, IEEE-1588

We, now have enough information to compare various synchronization methods after we went through the clock synchronization basics and the Synchronous Ethernet (SyncE), IEEE-1588 technologies. In this section we would look at various factors through which we can have a comparison - SyncE, NTP, GPS, IEEE-1588 and evaluate these technologies:

  • Network Load: Sync-E works at the physical layer and is independent of congestion or network load. It would work whether traffic is present or the link is idle. Also, except for 10-pps ESMC messages, Sync-E does not load the network in order to achieve synchronization. Even the accuracy achieved is not dependent on the rate of ESMC messages which is only a control protocol for its functioning. IEEE 1588 works at layer-2 and layer-3 and all its messages contribute to the congestion and are affected by it. A higher PDV is the root cause of not being able to achieve the accuracy. A higher accuracy can be achieved by using a higher rate of messages in 1588, but this itself is a cause of congestion on the network and increase in sensitivity to the PDV. NTP (Network Time Protocol) also behaves like 1588 since it uses UDP as its transport protocol and has similar consequences and contribution to Network Congestion. GPS, on the other hand is a time-broadcast service. The GPS signals are always available, any place near the earth that has unobstructed line of sight to GPS satellites.
  • Scalability: GPS is highly scalable, and so is Sync-E because an increase in the number of receivers for GPS, does not load the satellite itself. Sync-E’s ESMC protocol is a unidirectional, multicast where clients can join or leave and are fully responsible for their own synchronization. IEEE 1588 (and NTP) involves a lot a work from the master. More clients means more communication and queries that the master has to reply to and are thus scalable to the extent the standards dictate by limiting the number of slaves per master or con-current peer-to-peer connections. Any increase in client requests in 1588 and NTP also contributes to network congestion which is detrimental to their own system.
  • Support: GPS, 1588 and NTP are supported on all systems that can be connected to the network or that can see the sky without any obstruction. Sync-E can be supported on all varieties of Ethernet; however, there are some complicated issues on 10 Mbps links and 100 Base-T links. 10Base-T transmitter stops sending pulses during idle periods and sends “I’m alive pulse” every 16 ms while in 1000Base-T it is possible to pass-on the synchronization but then you have manually set all alternating ports to Master/Slave.
  • Special Equipment: Sync-E requires changes in the timing cards and PLLs as discussed. 1588, for a precise operation, requires time-stamping and classification of PTP messages at the hardware level. NTP is same as 1588 in this regard and works better the more closer the time-stamp is to the hardware or the software driver. GPS requires special GPS receivers.
  • Time-of-Day: 1588, NTP and GPS support ToD synchronization with varying accuracies. Sync-E does not deliver ToD.
  • Reliability: Sync-E does one thing (frequency locking) and does it properly. The frequency and phase synchronization in Sync-E is most reliable and highly scalable. 1588 can be used for frequency, phase and time synchronization but its reliability is yet to be proven over different networks and scenarios. GPS is riddled with interference problems, atmospheric and multi-path effects.

Comparison - SyncE, NTP, GPS, IEEE-1588

  Sync-E

 

(Layer 1)

1588/NTP

 

(Layer2/3)

GPS
N/w Load No Yes No
Scalable Yes Limited Yes
Support Ethernet Everywhere Everywhere
Special Equipment DPLL H/w Time Stamping GPS receiver
ToD No Yes Yes
Reliability Guaranteed Not proven Interference

Here are some of the comparison numbers between 1588 and NTP for Clock synchronization:

  PXI Backplane IEEE 1588 NTP on IP
Resolution ~0.01 ns ~50 ns <1x107 ns
Jitter ~0.002 ns ~100 ns ~3x106 ns
Distance ~0.5 m <400 m Worldwide
Sample Rates 100s of MHz <100 KHz <10 Hz
Cabling n/a CAT 5 Ethernet Ethernet, etc.
Topology User-defined Auto-resolve, master/slave Peer-to-peer

 Table: Compare synchronization alternatives
(Source: National Instruments)

Combination

IEEE 1588 and Synchronous Ethernet together make a synergetic combination. This is because:

Subscribe

Lock

  1. Sync-E is extremely reliable at L1 and not affected by network congestion, so two nodes can be synchronized in frequency and phase accurately. This mean, my watch is now, neither faster nor slower than yours. Also, it means a one second in my watch is precisely equal to the one second in your watch till the last nanosecond.
  2. IEEE 1588 can deliver a highly accurate Time-Of-Day using 64-bit time-stamps and measurement of mean-path delay between nodes. If clocks are already syntonized, 1588 can phase-synchronize them much more accurately, and with a lesser demand on the network bandwidth for trying to achieve the same accuracy if it were used alone.

Combination Synchronous Ethernet and IEEE-1588

Figure: Sync-E and 1588 combined
(Source: National Semiconductor)

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

IEEE-1588 Software Design and Multi-core

From a high level, IEEE-1588 software design and multi-core design and implementations consist of time-stamping hardware, protocol parsing software and filtering and clock correcting algorithm. The prior article mainly dealt with how the time-stamps were exchanged between master and its various slaves while the next article would deal with the related algorithms. This section deals with how all this gets tied together as a complete system and solution that achieves synchronization.

In order to keep the operating-system and stack latencies from adding up, it is beneficial to time-stamp the packets as close to the hardware as possible i.e. when a PTP message leaves the master or when it reaches the slave. This requires a special time-stamping circuit with a Real Time Clock in the hardware. This hardware either has to understand the protocol (so as to insert the RTC value at the correct offset in the message), or otherwise, maintain a buffer or queue that the protocol parsing software can pick time-stamps  from, for each received or transmitted message.

Secondly, due to the above requirement, it becomes necessary for the hardware to be aware of messages that are PTP versus the other normal packets. This is because only PTP packets would need to be time-stamped. Such classified packets are separate from data-traffic and can then be switched to the 1588 protocol parsing software directly without requiring another slower classification at the software level.

Contrary to Sync-E, software plays the major role in IEEE 1588 while hardware lends a helping hand. The major responsibilities of the software are:

  1. Setting up the system based on the capability of the slave and advertisement by the master.
  2. Selecting the master clock by processing the Announce messages.
  3. Forming and maintaining the set of {t1, t2, t3, t4} time-stamps. These time-stamps, as we have seen before, come from different kinds of messages (t1, t2 from Sync message; t3, t4 from Delay response message). These messages have unique sequence numbers, so that the correct association can be formed. The parser also has to take care of the follow-up time-stamps if the master supports a two-step clock. In the real world scenarios, packet loss/re-ordering would render any set incomplete and such cases of packet-loss have to be handled gracefully by the software, as in such cases the rest of the collected time-stamps have to be discarded or re-arranged after a programmed time-out for each set.
  4. Processing the collected time-stamps and running the clock-correction algorithm to correct the DCO (Digitally controlled oscillator)
  5. Switch the hardware to locked, holdover or free-running states.
  6. Provide PTP system management and monitoring interface to the user through CLIs and APIs.

The 1588 Protocol stack is the full suite of message parsers and generators for all the defined message types in the 1588 PTP standard. The clock correction algorithms, on the other hand, only require the extracted time-stamps for processing to calculate the corrections for the Digital Clock Oscillator. Thus these two parts can work as separate threads doing their respective job with dedication and exchanging the necessary information through standard interfaces.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

IEEE-1588 synchronization

In continuation of time-synchronization article series, conceptually, IEEE-1588 synchronization is as simple as if you were asking the time from somebody and (s)he replying after looking at his/her watch. You would then correct your watch accordingly. This is simply:

Time to be set = Time told + some delay
But this simplicity just ends here.

Let us look at some of the issues we would face in the above scheme:

  1. To be very precise, you might want to calculate the exact delay it took him/her to tell you the time.
  2. In addition compensate for the time it would take you to set your own watch accordingly.
  3. What if this person is 4 km away and fastest way he can tell you the time is writing it on a piece of paper and sending through a homing pigeon? (No other source available)
  4. For calculating above delays whose time would you consider? Your own watch is not working as expected and you of course cannot borrow that person’s watch and there is no other reference.
  5. You definitely have no way of knowing when this carrier started flying towards you or if he lost his way in between, once or more, and took some breaks too.
  6. You probably want to send your own pet homing pigeons, to fly to him and back, to get an idea of flying latency by dividing this time by half.
  7. And if the delay you finally approximate is significantly more than the preciseness with which you want to set the time in your watch? Is it even possible?
  8. Maybe you plan to average out these delays over several trips to get a better approximation.
  9. Would your calculations be generic enough to give you the correct result, if this homing pigeon were to be replaced with a homing-duck or on the contrary if this person can tell you the time directly by calling on your phone?
  10. Wouldn’t your averaging process get skewed if you got no intimation of this abrupt change in carrier? Is there a way to know looking at the time-stamp? What if it is just a gradual but continuous slip?
  11. How would you conclude that your time is finally set and accurate w.r.t. that person? There is no second/third reference.
  12. Would you set your watch only once or correct it at every instance of the pigeon’s flight?
  13. Would you benefit by employing more than one flying carriers?

These questions are not an exaggeration of the situation, because in the computer networks the IEEE 1588 synchronization protocol aims at providing nanosecond accuracy even when the packets that are carrying the time-stamp data have millisecond latencies and sudden, random variations in delay, PDV (Packet Delay Variation), due to congestion, link failures and in addition the dynamic route changes, that remain invisible to the communicating nodes at two ends.

Let us now see how IEEE 1588v2 (version 2) works and accomplishes synchronization. The next figure is what you would commonly see no matter where you start reading about this technology because it depicts the idea very neatly:

IEEE-1588 synchronization

(Source: RTA Automation)

There are various interesting things to note in this figure:

  1. There are two time-lines (Master on left and Salve on right hand side) that depict the time in their respective clocks at any instant.
  2. Slave is a system that wants to synchronize its time with the Master clock. Master may be any system that is itself a very precise clock or getting synchronized from somewhere else.
  3. Slave clock (as you can see on top) starts from a garbage value (30) which is un-important and ir-relevant as it has to finally correct this time.
  4. It is also unimportant “when” the slave wants to synchronize with master. Slave system can boot-up at any time and wish to synchronize no matter what time it is.
  5. In IEEE-1588 synchronizaion, a Master system sends “Sync” messages (periodically) to the interested slaves. These are a type of PTP (Precision Time Protocol) messages that are sent over the IP protocol and contain the time-stamp (t1) when this packet left the master (like when the homing pigeon starts flying).
  6. This Sync Message reaches the slave system at time (t2). Note here that t1, t2 are not comparable with each other as they come from different clocks running independently, at least one of which (slave) contains a garbage value to start with. The only thing common between them is that both are the same physical quantity i.e. TIME. Also, we have discussed before that, it is not wise to say that slave is behind or ahead of master until we know for sure that slave is not faster or slower than the master. Otherwise no matter how much precisely we correct the slave clock, it will drift off.
  7. Once the Sync message has reached, the slave has two time-stamps t1 and t2. The slave can set its own time as equal to t1, but then it would not have accounted for the network delay (the time it took pigeon to fly to you) and a mere subtraction of these two would not give any meaningful information as both these clocks started at different unrelated and unknown times.
  8. In order to estimate this network delay, the slave sends a “Delay-Request” message back to the master at time t3, and the master replies to this with a “Delay-Response” message containing its own time t4, giving slave four different time-stamps to calculate the delay between master and slave, i.e. a set of {t1, t2, t3, t4}
  9. There is a concept of “Follow-up” message, but I will defer it for a later discussion.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Synchronous Ethernet (SyncE)

In simple terms, Synchronous Ethernet extends the use of a PLL (Phase locked loop) clock to transmit data. At a very crude level, this, and only this, is the whole conceptual working of Synchronous Ethernet.

Synchronous Ethernet Functionality
Synchronous Ethernet Functionality (Picture Credit: http://www.oscilloquartz.com and Andre's blog)

At the physical layer, two Ethernet peer nodes are already synchronized through a PLL for the RX (receiving) end. A PLL works by using a negative feedback loop to lock. Just the way we tune a guitar: listening to a tuning-fork, plucking the string, comparing the sound and correcting the tension. In Ethernet, the receiving node monitors the incoming bits, compares their alignment and timing with its own, corrects it local oscillator and locks to the source. But, the story ends there. The extracted time is just used to receive the correct data by aligning clock to the incoming bits’ rise and fall times. But, when the same extracted clock is used to send the data out, it is called Synchronous Ethernet.

This post is in continuation to the series of posts on Synchronization in Telecommunication Networks. Previous posts:

Sync-E Hardware Expectations

The Sync-E concept, although straight forward, puts a lot of requirements at the hardware level for proper functioning. Few of these are:

  • Jitter/Wander tolerance, filtering and transfer
  • Reference Monitoring
  • Detect disconnection and switchover or holdover
  • Holdover stability
  • Hitless reference switching
  • Continuous averaging of locked reference
  • Support for active and backup Timing Card and hitless switching
  • Support 25, 125, 156.25 MHz and translation etc

Adhering to the standards the Synchronous Ethernet can provide better than 4.6 ppm accuracy across the network versus the conventional Ethernet (where free-running clocks have accuracy of 100 ppm between peer nodes).

Sync-E Software Requirements

The hardware would work efficiently with the given requirements. The software’s function in Synchronous Ethernet is more of a helping hand to the Hardware to function effectively. The ESMC (Ethernet Sync Message Channel) protocol is designed to communicate the Quality Level (QL) of the clock to the participating nodes. The nodes can thus decide, based on this information, the best source to lock to, thus forming a clock tree and hierarchy. The Sync-E standard (ITU-T G.8264) provides the rules to decipher the SSM (Synchronization Status Message) QLs.

Subscribe

Lock

The software standard defines the following:

  • Message encapsulation and priority
  • Quality level encoding (to inter-operate with SONET/SDH clock quality levels)
  • Best reference selection and Fail-over Switching
  • Handling bad PDUs (protocol data units) and preventing SSM floods
  • Distinguishing & handling events and information
  • Ten pps & five second rule: Ethernet’s slow-protocol PDUs have an upper limit of 10-pps and Sync-E follows this. Also, if a system does not receive ESMC packets for 5 seconds, it should switch-over to a different clock source.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Synchronization in Networks

(Continuing from the previous post: "Clock Synchronization in Telecommunication Networks"...)

Like layers in a network, time synchronization consists of two basic layers:

  • Phase synchronization; and
  • Frequency Synchronization

(Read more about Synchronous / Asynchronous / Isochronous / Plesiochronous)

It is extremely easy to grasp this concept by considering the day-to-day questions:

  1. Why do you always make me wait?

It means the other person’s watch is behind (or your watch is ahead) of agreed-upon time. A 4 ‘o clock in other person’s watch might translate to 4:10 pm in yours. This is a phase error and requires phase synchronization.

  1. Is my watch/clock faster?

Faster is not only ahead. You may set it to behind a standard clock, but, eventually it would run ahead of it. This is a frequency error and it points to the paradoxical question, “Is my one second shorter than your one second?” Paradoxical, because the label 1-second is exactly 1 second, the rest manifests as error in the device.

Starting to apply these concepts in electronics, networking equipment and computer systems, we come to the point of addressing the first question, “Why can’t oscillators run at 125 MHz when they are designed to run at 125 MHz”? This is more of a physical and practical limitation to achieve the desired accuracy (accuracy, as we defined before, is an expectation, explicit or implicit). Theoretically it is easier to say 125 MHz, but practically what is being asked for is 125.000000000 MHz oscillator. The more zeros (or digits after the decimal place) it has, the more preciseness is being asked for. Routers and computers cannot be equipped with cesium clocks, as a cesium clock is a whole laboratory setup in itself and not just a small crystal.

Figure: Cesium Clock
(Source: National Institute of Standards and Technology)

Later we will see what is clock jitter and wander that define the quality of a clock. Higher quality comes at a premium price while equipment manufacturers are at a constraint to reduce the BOM (Bill of Material). Thus, an oscillator would specify that it can run at 10 MHz +/- 1 Hz (that is, 10.000001 to 9.999999 MHz).

Subscribe

Lock

An error of 1 Hz in 10 MHz means that:
The uncertainty of the crystal is 1 in 10,000,000.
Which is, 1 part per 10 million = 0.1 ppm
or, 100 ppb (parts per billion)

“Parts-Per” notation is a very important dimension-less quantity that just denotes a proportion and is important because you can compare many different un-related objects and services. Like the above accuracy is analogous (in order of magnitude) to, the following:

A packaging plant, packages 10 million chocolates, and only 1 out of them turn out to be bad.

One thing to emphasize is that, this error (+/- 1 Hz) is not just two numbers one positive and one negative, but infinite variations between those two extremes, depending on the heat generated, crystal stability, aging etc. Thus we have a range of XOs (crystal oscillators) sporting different technologies like: TCXO (Temperature Compensated), OCXO (Oven Controlled), TCOCXO (Temperature Compensated Oven Controlled), OCVCXO (Oven Controlled Voltage Controlled) oscillators to choose from, for specific needs. [Not covering details of oscillators in this paper]

Distribution of Time

A better quality oscillator provides better stability and less wander, akin to saying that you would have to set the time less often than you would on a cheaper quality clock. However, if you have the opportunity to set the time more frequently, then you might as well use the cheaper clock itself.

This is, in simple words, the whole idea of distribution of time, which brings us to the second question, “Does it matter if you wear a Tissot/Rado or a Rolex, but forget to set the time in either”? So, we can now equip a router or a network node or a computer system with a cheaper oscillator, because we can run a synchronization protocol that would “measure” and “correct” the error of the local RTC and free-running clocks at every minute, second or sub-second interval.
      

A very-stable clock is required only when you want to set-it once and refer to it many times later and expect it to be correct every time. Functionally, it is possible to emulate this for a more economical watch if it corrects itself every minute without your intervention, probably through a GPS receiver or Network Time Protocol. What needs to be ensured then, is, that the clock is stable for just 1 minute, as we are anyways going to correct it after that period. With the data traffic growing exponentially, the per-bit transfer cost is plummeting giving us the means to have more control-traffic in-band, thus changing the economics to deploy synchronization protocols that would not only offset the cost of precise oscillators but also make systems more flexible.

Before entering a mission the army men would sync-up their wrist watches, similarly, the network nodes would sync-up automatically at defined and periodic intervals with each other based on some derived or defined hierarchy. Thus the person with the most accurate time, because (s)he is the proud owner of an expensive time keeping device, would dictate it to others, who would further propagate it down-the line to their peers. However, like information turns into gossip with each participating node further away, similarly, the quality of time information degrades as it traverses different nodes.

Let us consider this time propagation as broadcasting service on a radio program. Consider three separate channels in your radio:

  • Channel-1: Frequency Broadcast
    Free-running ticks at regular intervals.
  • Channel 2: Phase Broadcast
    A periodic pulse or heart-beat after a defined set of ticks.
  • Channel 3: ToD (Time of Day) Broadcast
    RTC (Real Time Clock) value at regular intervals.

Let us now map various available synchronization solutions to these channels:

  1. Common clock source: Depending on hardware design, all 3 channels are possible.
  2. GPS clock distribution: Usually channel 3. Thus, any system that is receiving the GPS signals would receive the same time-of-day periodically and can align and correct its own clock. There is a risk of wandering off on signal interruptions, depending on local oscillator quality.
  3. Analog phase-locked loop: Usually channel 1 or 2. The receiver is un-aware of the time-of-day on the source system, but due to the frequency adjustments, the participating nodes are syntonized (i.e. they remain in phase lock with each other). This is the level where the Sync-E (Synchronous Ethernet) operates.
  4. Adaptive clock recovery: Depending on the defined packet-rate and actual arrival rate, the receiver can adjust its own clock. This is analogous to channel-1.
  5. Time-stamp in packet: Each packet contains an RTC time-stamp, i.e. the time-of-day information. Since an RTC time-stamp contains both time and tick information, it is a super-set of all three channels. This is where 1588 operates.

And here is the ready-reference matrix for this:

  Frequency Phase ToD
Common Clock
GPS    
Sync - E  
Adaptive    
IEEE 1588

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

Time Synchronization in Telecommunication Networks

Clock synchronization across network nodes is the problem at hand. Instead of relying on elements “keeping” their own sense of time, a “distribution-of-time” approach is talked about here. The two promising solutions: Synchronous Ethernet and IEEE 1588 are presented in their approach, requirements, design and as an interesting comparison as well as a “combination” to deal with the challenge. Mandatory Sync-E hardware expectations and advanced 1588 concepts are covered. Ideas regarding modularization, extensions and software algorithmic requirements are individually defined. Plus, a new way of looking at IEEE 1588 software partitioning as a multi-threaded application or on a multi-core is presented.

In addition, the synchronization achieved is measurable both qualitatively and quantitatively using various tools and methods that are enumerated.

The changing scenario

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, with the demands of the customers (like speed, bandwidth, choice, service and reliability) and newer applications, service providers are looking upon on newer and better technology to retain their profit margins (despite of competition and lower end-user costs) by moving to IP or MPLS, Ethernet, TDM Circuit Emulation and Mobile Backhaul.

This move, from a time synchronized to an asynchronous medium, although financially beneficial, is 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 would 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 backhaul services
(Source: ADVA optical networking)

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 while a delay of a day in construction may not be matters of any escalation or complaint. We have an implicit margin and a different expectation for each one of them. 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.

Subscribe

Lock

For the computing machines, needless to say, one second is a 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.

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.

content-security

...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

You cannot copy content of this page
%d bloggers like this: