Realisation
Xentech Solutions Logo
Services
Case Studies
Technology

+44(0)1727 867795

enquiries@xentech.co.uk

Contact Xentech Solutions
+44 (0) 1727 867795

 

Please contact
Kevin O’Brien
Managing Director
Xentech Solutions Ltd

©2012 Xentech Solutions Ltd

Last Updated 09/01/2012 10:34:56

Privacy Policy | Terms of Use

Latest News:

1 October 2011

Xentech Solutions sponsor Freescale Technology Day in Milton Keynes, UK on 10th November 2011

 

 

 

 

 

12 June 2011

Xentech Solutions sponsor Freescale Technology Days in Swindon and Manchester, UK on 14th and 16th June 2011.

 

Contact
News
Home Services Technology Realisation About Us Contact SiteMap
Contact
FreescaleLogo
Services Technology Realisation Case Studies
News17
News18

CES Clock Recovery and Distribution Techniques

The increased demand for data services is forcing telecommunication operators to upgrade their networks to meet the higher bandwidth requirements.

The installed telecommunications network was designed for voice, and is not suited to the high bandwidth requirements of data now seen from worldwide internet usage. The E1 (2048Mbps) and T1 (1544Mbps) User Network Interfaces (UNI) traditionally provided by the telecommunication operators are not able to provide sufficient bandwidth to the user, who now expect performance and bandwidth comparable to their LAN. New users are demanding higher-bandwidth xDSL connections into the telecommunications network.

LAN ethernet technology offers bandwidth for a fraction of the price of telecommunications equipment. The telecommunication operators have realised the potential, and are starting to replace the existing SDH/SONET networks with ethernet networks to benefit from the lower Capital Expenditure (CapEx) and Operational Expenditure (OpEx) costs, and the increased bandwidth provisioning to the customer.

Telecommunications networks (SDH/SONET) are synchronous, ie all clocks within the network can be traced back to a single source (a Primary or Common Reference Clock). Synchronisation within the network allows all equipment connected to the network to use the same clock, and therefore ensure that data is not lost due to timing slips.

The primary disadvantage is that the synchronous network that allows error-free communication between any end-station on the same network, is no longer available from a Metro Ethernet Packet Switched Network (PSN). Clock distribution is a major challenge that has yet be satisfactorily resolved. Clock synchronisation across a network can only be achieved when all clocks are derived from a Common Reference Clock.

CLOCK DISTRIBUTION AND RECOVERY

Clock synchronisation across a telecommunications network is critical as it ensures that no data is lost due to buffer slips and overruns. Lost data on a voice call is a minor inconvenience, with occasional clicks reducing the quality of the call. Lost data during a data transfer can cause retransmissions, increases the transfer time, or can cause connected devices to fail to operate. Synchronisation ensures that all receivers are operating at the same frequency as the transmitters, and no data is lost due to clock frequency mismatches.

The CES Processor provides the data plane processing to enable constant bit rate E1/T1 streams to be carried over a packet switched IP or MPLS ethernet network. The packets containing the TDM data are transparently carried over the Metro Ethernet PSN so that the TDM streams can be reconstructed at the far end. The TDM interfaces at both ends need to be synchronised to meet the requirements defined in the G.823 (E1) and G.824 (T1) timing standards.

An ethernet network is asynchronous; there is no link between the frequency used to transmit and receive data on two different devices and the packet delay between two devices is not constant. Therefore, unless there is an external means of clock distribution, the receiver is required to recover the frequency of the transmit clock. The two main methods of clock recovery are Differential and Adaptive. Differential clock recovery uses a Common Reference Clock at both ends to synchronise the transmit and receive clocks. If a Common Reference Clock is not available, adaptive clock recovery must be used, where the rate of received packets is used to calculate the transmit clock frequency.

The other key aspect of clock distribution is the source of the Common Reference Clock. There are established methods of delivering the Common Reference Clock, for example from GPS, but the IEEE 1588-2008 standard appears to offer a much lower cost and more versatile alternative.

Clock Recovery Methods

a) Differential Clock Recovery

Differential clock recovery requires a Common Reference Clock in order to operate. The transmitter measures the relationship between the local clock and the Common Reference Clock, and sends this information to the receiver alongside the data traffic. The receiver uses this information to recover a clock with the same relationship to the Common Reference Clock, so good frequency matching can be achieved. The recovered clock is not affected much by Packet Delay Variations (PDV), since the recovered clock is related to the common reference.

The downside is that a Common Reference Clock is required at each end station, which can prove expensive.

b) Adaptive Clock Recovery

When there is no Common Reference Clock available to the receiving end of the link, adaptive clock recovery must be used. The clock recovery mechanism monitors the packet stream received from the Metro Ethernet PSN, and calculates the clock frequency based on the rate of data received.

The adaptive clock recovery offers good high-frequency jitter filtering, but is prone to wander due to Packet Delay Variation (PDV). The CES Processor Vendors have their own adaptive clock recovery algorithms, and performance varies depending on the Metro Ethernet PSN performance and loading. Many vendors claim to meet G.823 (E1), G.824 (T1), and G.813 (Timing characteristics of SDH equipment slave clocks (SEC)), although the network conditions during these tests is often unspecified.

c) Free Running Oscillators

The two customer sites are separated by a Metro Ethernet PSN, and a reference clock is not available at either site. The local oscillators (represented by fservice) are used to clock the data in and out at the transmitter (Tennant A) and the receiver (Tennant B). If fservice is equal at both ends, the system will work fine. However, it is not possible to match two local oscillators precisely, they drift in relation to each other, and service slips occur. This may be a viable solution for voice-only services, but is not a feasible solution for data or backhaul services or where the quality of service is important.

Note that this implementation can be used for short-term hold-over and free- running state during a fault condition. Also note that the transmit fservice (at Tenant A) could be derived from a Common Reference Clock.

Common Reference Clock Distribution

a) Hybrid TDM/Metro Ethernet PSN

The hybrid installation assumes that the TDM network is being replaced with a Metro Ethernet PSN, so that a synchronisation signal / clock is already available at each end station. In this case, clock recovery is not required at each end station as the Common Reference Clock can be used directly.

The obvious disadvantage is the maintenance of a parallel network, and the Opex costs will be higher.

b) GPS used as a Reference Clock

The technology for GPS Synchronisation Receivers is widely available, and is currently widely used to provide network synchronisation. The 1Hz or 10MHz clock from the GPS receiver feeds a differential clock recovery algorithm or a PLL to synchronise the clocks at all end stations within the network.

However, it is not without its problems. It is very expensive to install and operate. Uptime is <95%, so an expensive high precision holdover oscillator is required, antenna installation is required at every site, and requires regular calibration. The performance is also adversely affected by atmospheric conditions and physical location.

c) Synchronous Ethernet

Synchronous Ethernet uses the traditional telecommunication operator approach to synchronisation, by synchronising the network. Clock recovery is not required as the end stations recover the clock directly from the network.

Synchronous Ethernet is currently under investigation by IETF and IEEE Working Groups, and standards are not defined. If agreement is reached, it will take several years (if at all) before standards are available. Legacy Metro Ethernet PSN equipment cannot support synchronous ethernet, and new chipsets and equipment must be developed to support the standards. As a result, it will not be possible to benefit from the low cost of existing ethernet equipment.

d) Out of Band Timing Packets (eg IEEE 1588 Timing over Packet (ToP))

IEEE1588-2008 is a clock distribution and synchronisation protocol. It uses hardware time-stamping of timing packets to obtain an accurate picture of the network delays between the end stations (slaves) and a IEEE1588 Master device, located somewhere in the network. The clock recovery algorithm uses the accurate time stamp to provide accurate clock alignment of both frequency and phase. Since the recovery mechanism is based on timestamps and not packet rates, it is not as susceptible as Adaptive clock recovery to delay variations within the network.

CONCLUSIONS

There is no optimum solution for clock recovery. To provide a flexible solution to our customers, we need to support multiple methods of clock recovery, and need to support multiple reference clock sources.

If frequency synchronisation (syntonisation) only is required, adaptive Clock Recovery should give acceptable performance as the primary clock, and an OCXO (or maybe TCXO) can be used as a hold-over clock source.

If frequency and phase synchronisation is required, or high-stability frequency syntonisation is required (eg mobile backhaul), various solutions are available. Hybrid TDM/PSN network will give both frequency and phase synchronization. GPS is a viable solution, but is expensive to implement, and is prone to down-time. For a PSN-only network, IEEE1588-2008 looks like it will offer the best solution.