Blog: Frequency reference choices for packet networks

All modern transport networks are based on packet transport technologies. While synchronisation in digital networks has always been important, it has become absolutely critical with the new generation of networks and applications. This blog article explains the type of clocks for packet transport and identifies a single superset reference clock that fits every packet clock application.

Over recent years, packet-based synchronisation deployments have matured a great deal. Packet-based clock recovery is significantly more challenging than physical layer clocks for a number of reasons: the low rate of time stamps as significant events, time-stamping accuracies, traffic and queuing delay variations, and network asymmetries. 

The choice of oscillators for a particular application depends on several factors. The primary ones are the bandwidth required by the servo and the wander generation needed for the system. An additional important decision factor around oscillators is the holdover requirements of the system. Let's look at the evolution of packet network requirements over the years and how this has influenced the choice of oscillators used.

ITU-T G.8262: Ethernet Equipment Clocks (EEC)

The transition to packet networks providing synchronisation started with the introduction of ethernet equipment clocks, similar to the version of clocks deployed in synchronous slave equipment clocks in SDH networks. The ITU-T defined the requirements of physical layer synchronisation on ethernet clocks in its G.813 Recommendation. Adopting the oscillator specifications from the earlier G.812 recommendations for SDH, the oscillator requirement was confined to reference clocks with a 300ppb temperature stability, 10ppb/day ageing and 4.6ppm lifetime accuracy. This requirement combines the option 1 and option 2 of G.813, which are in place to address different types of traditional network hierarchies. 

The new version of EEC, Enhanced Ethernet equipment clock G.8262.1 focuses on only one type of networks, the oscillator requirement is same as the previous generation of equipment. 

When combined with a packet clock, the SyncE clock works as the physical layer clock assist which will be the reference clock for packet servo operations. In most common implementations, the reference clock for SyncE will also be the master clock of the system which will address all superset of requirements of the system including holdover.

The basic requirements for a Synchronous Ethernet clock is captured below:

ITU-T G.8263: Packet-based Equipment Clock – Frequency (PEC-F)

In the protocol layer, the very first standard to come into force was the packet equipment clock–frequency (PEC-F) defined by G.8263. The recommended loop bandwidth here is 1mHz. The wander generation requirement for the oscillator is 10ppb pk-pk frequency versus temperature requirement and 1ppb/day ageing. The free run accuracy of the oscillator has to be 4.6ppm lifetime accuracy.

The PEC-F clock requirements are summarised as below:

ITU-T G.8273.2: Telecom Boundary / Slave Clocks

The full on-path supported networks have Telecom Boundary Clocks and Telecom Slave Clocks as defined in G.8273.2. This clock model assumes the physical layer recovered clock is supporting the protocol layer recovery as a reference clock with an overlap of bandwidths. It ensures the best of both worlds: the oscillator's higher short- to medium-term stability and higher long-term stability of the network recovered clock. In theory, the requirements on the oscillators are the same as the requirements on the EEC clocks. All practical implementations use Stratum 3E devices. Stratum 3E specifies a 10ppb pk-pk frequency versus temperature performance, 1ppb/day ageing and 4.6ppm lifetime accuracy.

ITU-T G.8273.3: Telecom Transparent Clocks

G.8273.4 defines Telecom Transparent Clocks, which measure and adjust for packet delay. With no built-in servo requirement, the stability requirement on the oscillator is the same as for the frequency-only physical layer equipment clocks.

ITU-T G.8273.4: Assisted & Patrial Timing Supported Clocks

A partial on-path timing support clock is when some network elements support clocking functionality without physical layer support. The servo implementations are below 1mHz, requiring an oscillator that is better than Stratum 3E requires. Assisted Timing support clocks refer to having the PTP assistance to GNSS, assuming the latter being the primary clock reference to the system. Most GNSS clocks have a 1Hz (1PPS) into the servo system, requiring a loop bandwidth of ~10-30mHz. Combining these two loop filter bandwidth requirements means that the oscillator performance for G.8273.4 APTSC (Assisted and Partial Timing Supported Clocks) has to exceed the Stratum 3E specifications.

ITU-T G.8266: PEC Master Clock for Frequency

G.8266 defines the master clock for PEC-F, the frequency-only clocks. These follow the exact specifications for G.812 at 1ppb temperature stability and 0.2ppb/day ageing.

ITU-T G.8272: Primary Reference Time Clocks (PRTC)

The G.8272 defines Primary Reference Time Clocks (PRTC) as generally supported by atomic clocks. A further specification, PRTC-B, defines Access or Metro locations, which do not need holdover requirements. An oscillator that can support filtering of clocks down to or sub-mHz range is recommended in such applications.

Several new standards have left the holdover requirements to the operators to select, but a common requirement with holdover-based oscillators is to limit phase error of 1.5uS within 4-8 hours of operation.

One oscillator for all packet clocks

In many deployments, it may be useful to consider fitting all requirements mentioned above across all the standards into one oscillator. An oscillator with 1 ppb peak-to-peak temperature stability, ±0.2 ppb/day ageing, 0.1 ppb/°C temperature sensitivity and ±4.6 ppm lifetime stability can be used for any of the above situations.

A summary of an OCXO device that would meet all requirements of packet clocks is illustrated below:

Rakon's oscillator for all packet clocks' is the ROX2522S3, a discrete OCXO with thermal compensation, or when a longer holdover is needed (24-hour), the ROD2522S2, a PPS disciplined OCXO with smart compensation.

If you have any questions about your particular use case or our backhaul synchronisation products, please get in touch with us.

Would you like more content like this delivered to your inbox?

Subscribe to our emails now!