What is Noise Transfer?

In the ITU-T Recommendations, clock specifications are typically specified under five different categories:

Noise Generation
Noise Tolerance
Noise Transfer
Transient Response
Holdover

Of these, the one that often generates the most confusion is Noise Transfer. What does it mean, and why is it commonly specified using a bandwidth?

Clock Bandwidth

A clock is a device for tracking the progress of time. For clocks or watches in our homes, we set them to the correct time (according to our reference time, for example, this might be from the radio announcer), and they “tick” based on the frequency of their local oscillator (e.g. a pendulum or a quartz crystal). After some period of time, we need to adjust them, because the “tick” isn’t at precisely the right rate, and the clock starts to deviate from the correct time.

All clocks behave in a similar way, and the electronic clock systems such as the ITU-T clock types are no different. They all employ a local oscillator (usually a quartz crystal), and they all need an input reference to tell them what time it is (or in some cases, what frequency they should be running at). They periodically compare their time (or frequency) to the reference input, and adjust their local time or frequency accordingly. In between these adjustments, the local time or frequency is controlled by the local oscillator.

The adjustment rate is normally much faster than a person adjusting the clock on the wall, and the adjustment system may average together multiple comparisons before adjusting the time, reducing the influence of any error in the comparison. This gives rise to the concept of the “bandwidth” of a clock.

You can think of a clock as a filter. We know that over long time intervals, the clock is controlled by the input reference (the periodic reset operation), while over short intervals, it is controlled by the local oscillator, as shown below:

Flip that around into the frequency domain, and this means that the clock will “follow” any low-frequency variation in the input reference (variations over long time periods), but “reject” any high frequency variations – over short time intervals, it will just follow the local oscillator instead. Therefore the clock is behaving as a low-pass filter, and the bandwidth of that filter is the frequency at which it starts to “reject” higher-frequency variations.

Correspondingly, from the point of view of the local oscillator, it acts as a high-pass filter. Any high-frequency variations in the oscillator (e.g. jitter or wander) that are above the clock bandwidth will be seen on the output of the clock.

Noise Transfer Specification

“Noise Transfer” therefore describes the way that “noise” on the input reference is passed to the output of a clock. From the point of view of a clock, “noise” means variations in time relative an ideal, perfect clock. The principal metric used to describe how noise is passed from input to output is the clock bandwidth.

For example, the noise transfer of an EEC Option 1 (the synchronous Ethernet Equipment Clock) is described in clause 10.1 of G.8262 as: “The minimum bandwidth requirement for an EEC is 1 Hz. The maximum bandwidth requirement for an EEC is 10 Hz.”

Clock Functions

Some clocks are “clean-up” clocks. They are intended to “clean up” the input reference by filtering out much of the noise. These clocks tend to have very low bandwidth.

Sometimes cleaning up isn’t required, but the clock’s purpose is just to replicate the input, or sometimes to translate that into a related frequency (e.g. multiply up in frequency). These clocks might be termed “followers”, and tend to have higher bandwidths.

As an example of the different types of clocks, the following diagram shows the G.803 synchronisation reference chain (taken from Figure 8-5 of G.803). This describes the way synchronisation was distributed in the SDH network architecture. It shows the PRC (Primary Reference Clock), as the source of frequency for the chain. This is connected by a chain of up to 20 SECs (SDH Equipment Clocks; “follower” clocks with bandwidth between 1 and 10Hz), until they get to the SSU (Synchronisation Supply Unit). This is a “clean-up” clock, with a very low bandwidth of 3mHz. Then there can be another chain of EECs, followed by another SSU. In total, the reference chain can consist of up to 10 SSUs and 60 EECs.

So why not make all clocks “clean-up” clocks? Surely, getting rid of noise is a good thing? Well, as you can see above, telecom systems are very large, and can consist of long chains of clocks. The downside of a very low bandwidth can be that a clock takes a long time to settle. For example, an SSU Type 1 clock with a bandwidth of 3mHz will take several minutes to settle.

If all the clocks in the chain had such a low bandwidth, the whole chain would take many hours to settle. Any disruption, such as a protection switch, would cause large swings lasting several hours at the end of the chain, magnifying the effect of the disruption.

On the other hand, by using high-bandwidth “follower” clocks, the disturbance can be over in a matter of seconds, and the synchronisation chain is back in business.

Secondly, the bandwidth of the clock determines the type of local oscillator required by the clock implementation. The high-pass response of the clock to noise on the local oscillator means that if the clock bandwidth is reduced (removing more noise from the input), correspondingly more noise is admitted from the local oscillator.

Therefore, clocks intended to “clean-up” the input reference by filtering with a low bandwidth require a more stable oscillator than clocks that are just intended to “follow” the input reference. The ultra-stable clocks required by devices such as an SSU are very expensive compared to the oscillators in a “follower” clock, both in terms of money, but also power consumption.

G.8273.2 Telecom Boundary Clocks

ITU-T Recommendation G.8273.2 describes the specification of a Telecom Boundary Clock (T-BC). A T-BC is actually two clocks combined. Firstly it contains a frequency clock, using SyncE to provide a stable, accurate frequency reference. As we’ve seen earlier, an EEC is defined in G.8262 to have a bandwidth of between 1 and 10Hz.

Secondly, it contains a time clock. This takes an input reference in PTP format, sets its internal time to match the input, and generates an output clock, again in PTP format. In PTP terms, this is known as a Boundary Clock (BC). The clock bandwidth for this BC is defined to be between 0.05 and 0.1Hz. However, instead of using a local oscillator to “tick” for periods less than 0.1Hz, it uses the output of the EEC.

In diagram form, it looks like this:

In terms of the noise transfer of the clock, there are now two inputs which can affect the time output. We know that the time clock bandwidth (from PTP input to PTP output) is defined to be a low-pass filter with a bandwidth between 0.05 and 0.1Hz:

This means that, since a T-BC uses the SyncE input as the local oscillator for the time clock, the time clock also acts as a high-pass filter to any noise on the SyncE input. However, we know that the clock bandwidth of the EEC itself is defined to be a low-pass filter between 1 and 10 Hz:

Therefore any noise on the SyncE input to the device will be first low-pass filtered by the EEC, and then high-pass filtered by the time clock, creating a band-pass function:

The New Synchronisation Reference Chain

The modern equivalent to the G.803 reference chain for SDH clocks is defined in G.8271.1. This describes a number of different Hypothetical Reference Models (or HRMs) for how chains of clocks can be constructed. The two main models are called “HRM2” (or the congruent scenario), and HRM3 (or the non-congruent scenario).

HRM2 is shown in Figure 10, and consists of up to 20 clocks in the chain. Each PTP clock also contains an EEC. The frequency distribution (SyncE) and the time distribution (PTP) follow the same path all along the synchronisation chain. This is why it is known as the “congruent scenario”.

The shared path means that much of the noise generated along the chain is the same all the way along. Transients generated at one location affect both the PTP and SyncE all the way down the chain, and noise tends to accumulate. For many operators, this is the preferred scenario, since they can plan the synchronisation network as a whole, not separating the frequency and time plane.

HRM3 is the opposite extreme. While it still consists of up to 20 clocks in a chain, the SyncE input to each EEC is assumed to come from an entirely separate frequency distribution chain, so there is no common-mode noise present. In the worst case, it could be traceable back to a separate PRC, so there might be small long-term frequency differences of up to 2 parts in 10¹¹ between every SyncE signal.

The benefit of this scenario operationally is that operators can plan the time plane and the frequency plane entirely separately. This can make it easier to plan for protection of the synchronisation path, since the frequency path and the time path are entirely decoupled. Therefore a failure in one chain doesn’t necessarily lead to a failure in the other.

The way noise accumulates between each of these models is different. In order to determine if the chain of clocks is able to deliver the time accuracy required at the end point, a range of different simulations have been run. These simulations were used to choose between different bandwidth options, the timestamp quantisation error, and the packet rate. The simulations and the different options investigated are described in detail in ITU-T Supplement G.Sup65.

The final parameters chosen were:

PTP message rate of 16 messages/s
Timestamp quantisation of 8ns or less
Time clock bandwidth between 0.05 and 0.1Hz
Frequency clock bandwidth between 1 and 10Hz (already defined by G.8262)

With these parameters, the simulations showed that the noise accumulation should be well within the limits expected, and allow the end application to meet the time accuracy requirement of better than 1500ns, even for the longest chains of up to 20 clocks, and for both deployment scenarios.

What will happen if the T-BC doesn’t meet Noise Transfer?

The short answer is, possibly nothing, depending on the specific failure type. Clock bandwidth is always a trade-off between the amount of noise in the chain, and the amount of noise generated by the local oscillators. Such trade-offs can have many different solutions

However, care must be taken if the specification is not met. As mentioned earlier, lower bandwidths are not necessarily better in the context of a chain of clocks. This is particularly true for the congruent scenario, where noise tends to add more linearly because every node in the chain experiences the same noise.

If each T-BC has a low bandwidth, then any disturbance in the frequency plane, such as a protection switch generating a transient, can accumulate along the chain of clocks. However, if the bandwidth is higher, the clocks can correct themselves much quicker and the transient doesn’t accumulate in the same way.

Therefore, even if a more stable oscillator is used to compensate for the lower bandwidth, the overall chain of clocks might be less stable and correct much slower after a transient event.

The simulations show that the clocks work together as designed to meet the end goal. They do not show that if the noise transfer function is different, the system will not work – but they don’t show it will work, either. If a vendor decides that the system would work better by designing it another way, they are free to do that, but they have to demonstrate to their customers why it will work better and persuade them to disregard the ITU specifications.

G.8273.3 Telecom Transparent Clocks

ITU-T Recommendation G.8273.3 describes the specification of a Telecom Transparent Clock (T-TC). A T-TC does not perform any filtering on the PTP signal, therefore there is no PTP to PTP noise transfer specified for T-TC, the only requirement in this respect is that the T-TC is not permitted to amplify time error on its output.

Some consideration can be made with respect to Physical layer frequency (e.g. SyncE) to PTP noise transfer, this is similar to a T-BC. The Physical layer signal at the T-TC input is filtered by a G.8262 clock (in the case of class A or B) or G.8262.1 clock (in the case of class C). The corner frequency of the related low-pass filter is between 1 Hz and 10 Hz for T-TC classes A and B, and between 1 Hz and 3 Hz for Class C

On T-TC PTP output, the noise is transferred for frequencies below the Nyquist frequency corresponding to the largest between 8 Hz (due to the G.8275.1 PTP packet rate of 16 packets per second), and the frequency related to the residence time (e.g., 50 Hz in the case of 10 ms residence time). For the purpose of Physical layer frequency to PTP noise transfer, filtering on the PTP layer corresponds to a high pass filter that in the worst case can be considered to have a corner frequency of 8 Hz.

As shown in the figure below, by combining the Physical layer frequency input low-pass filtering and the high-pass filtering, for Class C there is no band-pass defined and the Physical layer signal should be filtered in the full band (-20dB). In case of classes A and B, a hypothetical implementation may result in noise transfer within a band-pass between 8Hz and 10 Hz, however in practice this hypothetical noise is not measurable as it is above the 16 packet per second Nyquist frequency of 8Hz, additionally a maximum 10 ms residence time (corresponding to high-pass bandwidth of 50 Hz) is recommended by G.8273.3 so that no physical layer frequency noise is transferred.

Therefore, in conclusion, for all T-TC’s it should be verified that there is no noise (meaning a gain of -20dB or lower) transferred from the input Physical layer to the PTP layer output.

GdotWhat?

What does Noise Transfer Mean?