The ITU-T has recently released a revision of G.8273.2, the recommendation describing the performance standards for boundary clocks in the network. This revision adds two new high-accuracy clocks, Classes C and D to the original Classes A and B. The purpose of the new clocks is to be used in the new fronthaul networks, particularly in the context of 5G, which has some very strict timing requirements. For the most accurate Class D clocks, there has been a change to the way the performance of the clock is defined. This blog tries to explain why the change has been made, and what it means.
A G.8273.2 boundary clock receives time from the previous clock, smooths out any noise in the input (i.e. acts as a low-pass filter), and sends out a cleaner version of the clock. Therefore, in terms of the amount of noise passed down the chain of clocks, it is only low-frequency noise (or “wander”) that accumulates down the chain. The high-frequency noise (or “jitter”) is filtered out by each clock in the chain. The bandwidth of the filter in a G.8273.2 clock is defined to be between 0.05 and 0.1Hz.
During the development of G.8273.2, it was first proposed that the clocks should have two parameters, the constant time error (cTE), and the low-pass filtered dynamic time error (dTEL). Between them, these two parameters indicate the amount of noise that would accumulate along the chain. Roughly speaking, the noise generated by the clock would be cTE ± (dTEL/2). The divide-by-2 is because dTEL is specified as a peak-to-peak limit (MTIE is basically a peak-to-peak wander over time).
The maximum time error, max |TE|, was originally introduced as a tolerance limit. The reason was that if the only parameters were cTE and dTEL, there would be no limit on the amount of high-frequency noise on the output of the clock. This high-frequency noise, or jitter, could be beyond the tolerance of the next clock in the chain. Therefore max |TE| was introduced to limit that. You might ask “why not use the high-frequency dTE parameter to control this (dTEH)?” The answer is that there was no dTEH parameter in the first published version of G.8273.2 (May 2014), but that was soon corrected in Amendment 1 (January 2015).
With Class A and Class B clocks, max |TE| was quite sensibly set quite high, at 100ns and 70ns accordingly. PTP interfaces always contain quite a bit a high-frequency noise for various reasons, such as quantization errors and resolution – especially at lower Ethernet rates such as 1G. Since they had no role in accumulated noise down the chain, there was no reason to make them really tight. For Class C and Class D clocks, it was proposed to use a new metric, max |TEL| - a low-pass filtered version of max |TE|. There were several reasons for this:
People had forgotten the original reason for max |TE| – for noise tolerance – and were proposing unnecessarily tight values for it.
dTEH had been introduced to control the high-frequency components, so there was no real requirement for max |TE| any more.
With an unfiltered measurement such as max |TE|, a single bad point causes the measurement to fail the limit. This was not so much of a problem with Class A and Class B, where the limits were high, but with the very tight limits on max |TE| being proposed for Classes C and D it would have been a big problem.
Some operators wanted a headline 5ns specification for Class D. That number was based on noise accumulation, for which max |TE| was the wrong parameter. Max |TEL| was a much more appropriate parameter, since it indicated the amount of noise that would accumulate down the chain. Therefore using the filtered version, max |TEL|, enabled the headline 5ns specification to be achieved.
Some participants opposed the use of max |TEL| for Class C, and wanted to continue the same methodology that was used for Class A and Class B. They argued that max |TEL| doesn’t tell the whole story, because the different components will add in different ways. cTE tends to add linearly, while dTEL adds as an RMS sum. Combining the two into one parameter loses that information. Therefore it was agreed to continue using the existing performance metrics for Class C, while Class D used the new max |TEL| parameter. With max |TEL| set to 5ns for Class D, it makes almost no difference if the number is added linearly, or if it is split out into separate components and added separately.
So that’s the background to the new clock performance specifications.
Here are a few related Q&A I also answered recently:
Q: How come Class D needs lower pass filter when spec for the Max |TE|? Why is it important for Class D to have filter here?
Max |TEL| indicates the amount of noise accumulating down the chain. Secondly, it would be difficult for vendors to achieve a 5ns unfiltered max |TE| specification, because PTP tends to generate quite large high-frequency noise.
Q: Will there be specs for cTE, dTE, MTIE/TDEV for Class D as well?
It is possible, these are marked as “for further study”. However, in practice I don’t think these will be agreed, as it’s hard enough to meet 5ns. What if the limit was set to say 3ns cTE and 2ns dTEL? If a vendor achieved the 5ns max |TEL| but had 4ns cTE and 1ns dTEL, does that mean the clock won’t work properly? By the rules, the clock would be non-compliant, but in the application it would almost certainly work fine. Therefore in reality I don’t expect any vendors will agree to further subdividing the 5ns limit.
Q: For Class C and D clocks, these specs are for noise generation. How about noise tolerance/transfer/transient response/holdover?
Noise tolerance for Class C and Class D is for further study at present, as the network limits for chains of Class C and Class D clocks are not yet agreed.
Noise transfer (PTP to PTP/1pps) of Classes C and D is the same as for Classes A and B, as the bandwidth of Class C and D clocks is the same.
Noise transfer (SyncE to PTP/1pps) of Classes C and D is similar to Classes A and B. The difference is that Class C and D clocks contain an enhanced EEC, not an ordinary EEC. The bandwidth of an enhanced EEC is between 1 and 3Hz, while an ordinary EEC is from 1 to 10Hz. This affects the noise transfer from SyncE to PTP of the T-BC.
Transients and holdover are for further study at present. There are no current proposals being discussed, although I expect some will be made during future meetings.
Tim Frost
Strategic Technology Manager
