PRC/PRS is not broken.

For reliability reasons, it is

unrealistic to expect all global telecommunication networks to be synchronized to a single PRC/ PRS. Real
networks use a flatter timing distribution structure with a number of PRC/PRS running independently. Each
telecom pro- vider usually has its own PRC/PRS, which means that the worldwide telecommunication network
con- sists of synchronized islands con- nected with plesiochronous links.

While PRC/PRS and SSU/BITS are usually implemented as standalone products with tim- ing-only
functionality (no data transmission), SEC/SMC are almost exclusively implemented as a part of networking
product such as an add-drop multiplexer.

Traditional vs. synchronized

Traditional Ethernet was origi- nally intended for transmission of asynchronous data traffic, mean- ing there was
no requirement to pass a synchronization signal from the source to destination. In fact, the old 10Mbit/s
(10Base-T) Ethernet is not even capable of synchronization signal trans- mission over the physical layer
interface because a 10Base-T transmitter stops sending pulses during idle periods.

A 10Base-T transmitter simply sends a single pulse (“I am alive” pulse) every 16ms to notify its presence to the
receiving end. Of course, such infrequent pulses are not sufficient for clock recovery at the receiver.

Idle periods in faster Ethernet flavors (100Mbit/s, 1Gbit/s and 10Gbit/s) are continuously filed with pulse
transitions, allowing continuous high-quality clock re- covery at the receiver—good can- didates for
synchronized Ethernet.

Figure 1 highlights Gigabit Ethernet over copper (1000Base- T). To reduce clutter, each node has only two
ports, although typically each node has multiple ports. Gigabit Ethernet over cop- per provides an additional
chal- lenge for SyncE implementation, which does not exist in Ethernet over fiber.

Figure 2: Synchronization does exist in Ethernet on each hop between two adjacent nodes, but it is not passed from hop to
hop.

Figure 3: Passing synchronization is relatively simple—take the recovered clock from the node receiving synchronization
and with this clock, feed all nodes that are transmitting synchronization.

Juniper
Business
Use Only
Juniper
Business
Use Only
2 eetasia.com | EE Times-Asia

Gigabit Ethernet over copper uses line coding and transmis- sion over all four pairs of CAT-5 cable to
compensate for limited bandwidth of twisted pairs used in CAT-5 cables. The transmission is done in both
directions simulta- neously, similar to ISDN and xDSL where DSP algorithms have to be used for echo
cancellation.

The echo cancellation is greatly simplified if the symbol rate (fre- quency at which data is transmit- ted) is
identical in both directions. This is accomplished with a GbE master/slave concept.

The master generates a trans- mit clock locally from free-run- ning crystal oscillator and the slave recovers the
master clock from the received data and uses this recovered clock to transmit its own data. Master and slave are
determined during the auto- negotiation process. The master is generally assigned randomly using a seed value
but it can also

be set manually.
Figure 2 illustrates that syn-

chronization does exist in Ethernet on each hop between two adja- cent nodes, but it is not passed from hop to
hop. Passing synchro- nization is relatively simple—take the recovered clock from the node receiving
synchronization and with this clock, feed all nodes that are transmitting synchroniza- tion (Figure 3).

Juniper
Business
Use Only
Of course, the recovered signal needs to be cleaned with a PLL to remove jitter generated from the clock
recovery circuit before be- ing fed to the transmitting device. Ports need to be manually set in the clock path to
alternate the master and slave function (only for 1000Base-T).

This is not an issue for Gigabit Ethernet over fiber (1000Base-X) or for 10GbE (10GBASE) because one fiber is
always used for trans- mission and the other for recep- tion—there is no bi-directional

transmission on a single fiber. Thus, there is no need for master and slave functions.

Any Gigabit or 10GbE PHY device should be able to support synchronized Ethernet, so long as it provides a
recovered clock on one of its output pins. The recovered clock is cleaned by the PLL and fed to the 25MHz
crystal oscillator input pin on the PHY device. Some new Ethernet PHY devices provide a dedicated pin for the
synchronization input. The advantage of this approach is that frequency input can be higher than 25MHz—
higher clock fre- quencies usually have lower jitter. In addition, this approach avoids any potential timing loop
prob- lems within the PHY device.

Clean jitter

From the discussion so far, it ap- pears that the only requirement for a PLL used in SyncE is to clean jitter from
the recovered clock,

which can be accomplished with general purpose PLLs. However, the PLL used in SyncE must pro- vide
additional functions beyond jitter cleaning.

For example, if the receiving PHY device (Node 2, PHY 1 in Figure 3) gets disconnected from the line, the
recovered clock fre- quency will either stop or start to drift depending on the implemen- tation of the clock
recovery circuit. The general purpose PLL will pass this big frequency change to the transmitting PHY device
(Node 2, PHY 2 in Figure 3). As a result, not only is the transmission of syn- chronization signal going to fail,
but the data transmission could fail as well.

The PLL used in SyncE must be able to detect failure of the recovered clock and switch the PLL to either
another good refer- ence in the system or into hold- over mode. Requirements for SyncE are outlined in the
timing characteristics of synchronous Ethernet equipment clock (ITU G.8262/Y1362) specifications. These
specifications are based on ITU-T G.813 specification for SDH clocks. The major require- ments of ITU-T
G.8262/Y1362 are the following:
• Free-run accuracy—The ac-

curacy of PLL output when it is not driven by a reference should be equal or better than ±4.6ppm over a time
period of one year. This is a very accurate clock relative to the clock accuracy for tra- ditional Ethernet
(±100ppm).

• Holdover—The PLL con- stantly calculates the aver- age frequency of the locked reference. If the reference
fails and no other references are available, the PLL goes into holdover mode and generates an output clock
based on a calculated aver- age value. Holdover stability depends on the resolution of the PLL averaging
algorithm and the frequency stability of the oscillator used as the PLL master clock.

Figure 4: Timing in a carrier-grade SyncE system is composed of two timing cards that feed clocks to multiple line cards via
a common backplane.

Juniper
Business
Use Only
Juniper
Business
Use Only
•

Reference monitoring—The PLL needs to constantly

monitor the quality of its input references. If the refer- ence deteriorates (disappears or drifts in frequency), the
PLL raises an alarm (interrupt) and switches to another valid reference.

• Hitless reference switching—If the PLL's reference fails, it will lock to another available reference without
phase dis- turbances at its output.

• Jitter and wander filter- ing—The PLL can be viewed

as a jitter and wander filter. The narrower the loop band- width, the better the jitter and wander attenuation.

• Jitter and wander tolerance— The PLL should tolerate large jitter and wander at its input, and still maintain
synchro- nization without raising any alarms.

These stringent requirements can be met only with a DPLL similar to DPLLs used for SONET/ SDH clocks.
The major difference

is that a SyncE DPLL needs to be able to lock and generate clock frequencies used in Ethernet (25MHz,
125MHz and 156.25MHz), as opposed to telecom clocks (19.44MHz, 155.52MHz) used in SONET/SDH.

Carrier-grade SyncE systems must provide highly reliable op- eration under all network condi- tions. To do this,
the most critical components within the system are made redundant, including timing.

eetasia.com | EE Times-Asia

Figure 5: A next-generation DLC requires Ethernet and telecom clock frequencies.

Juniper
Business
Use Only
Timing in a carrier-grade SyncE system is composed of two timing cards that feed clocks to multiple line cards
via a common backplane (Figure 4). All line cards synchro- nize to the clock coming from an active timing
card. If the active tim- ing card clock fails (i.e. the card is unplugged), line cards will synchro- nize to the clock
coming from the redundant timing card. Switching from one timing card to the other should not cause any
interruption or failure in the system.

Having two timing cards pro- tects against an internal failure if one of the cards fails. As seen in Figure 4, to
protect from external clock reference failures, the tim- ing cards are designed to be able to synchronize to more
than one reference. A timing card accepts references from multiple sources, selects one, cleans it from phase
noise with a DPLL, and distrib- utes it to the line cards via the

backplane. The DPLL is the most important part of the timing card. Timing card DPLL references can come
externally from a SSU/BITS, internally from line cards, or from the other timing card in the sys- tem. Timing
card DPLLs should meet all ITU-T G.8262/Y1362 re- quirements.

As seen in Figure 4, the line cards each have a DPLL that is used for jitter reduction and fre- quency translation.
For example, frequency translation is required to convert from the 25MHz back- plane clock to one or more
clocks required by the Ethernet PHY, such as 125MHz, 156.25MHz, 155.52MHz or any other.

The line card DPLL must also provide hitless switching between the active and redundant clocks and provide
clock continuity for a short period, such as when the active clock unexpectedly disappears before the system de-

tects active reference failure and switches the line card DPLL to lock to the redundant reference. Like any
DPLL, a line card DPLL requires a crystal oscillator.

However, this can be a low- cost oscillator as the line card DPLL is not required to go into holdover (except for
short time periods when switching between active and redundant clocks). For long-term holdover, the system
relies on a timing card DPLL. Therefore, a timing card DPLL requires higher quality crystal oscillators (TCXO,
OCXO).

Smaller SyncE systems that do not need timing redundancy will generally have only one DPLL. This DPLL
should meet all require- ment of the timing card DPLL and the line card DPLL combined. This DPLL should
have narrow loop bandwidth, good holdover (TCXO or OCXO required), hitless reference switching and very
low

intrinsic jitter. Depending on the application, this DPLL might also need to generate telecom fre- quencies such
as 8KHz, 2.048MHz, 1.544MHz, 34.368MHz, 44.736MHz and many others.

Juniper
Business
Use Only
Figure 5 illustrates a next-gen- eration Digital Loop Carrier (DLC) requiring Ethernet and telecom clock
frequencies. DLCs are in- stalled in the neighborhood to ag- gregate traffic from multiple POTS, xDSL and
T1/E1 to minimize the number of the lines going to the Central Office (CO) and increase xDSL data rates by
shortening the length of the copper lines.

Aggregated traffic is carried to the CO via a fiber cable or several copper lines. Traditionally, DLCs have used
SONET/SDH or T3/E3 to transmit data between the DLC and CO. However, these links are being replaced by
Ethernet because of its lower capital and operational costs.

4 eetasia.com | EE Times-Asia

Juniper
Business
Use Only