transceiver-db/blog-training-data/blog-063-100g-zr-coherent-pluggable-timing.md

title	slug	type	category	tags	seo_focus_keyword
100G ZR Coherent Pluggables and Timing: Why These Transceivers Care About PTP and SyncE	100g-zr-coherent-pluggable-timing-ptp-synce	deep-dive	Coherent Optics	100G ZR coherent PTP SyncE timing QSFP28 DSP DWDM	100G ZR coherent pluggable timing PTP SyncE

The 100G ZR specification (OIF-400ZR and its 100G subset implementations, as well as the slightly older OpenROADM coherent pluggable standards) introduced a category of transceiver that behaves fundamentally differently from SR4 or LR4 optics in ways that aren't immediately obvious from the QSFP28 form factor they share. The most overlooked of these differences is timing sensitivity. A 100GBASE-SR4 optic doesn't know or care about the time of day. A 100G ZR coherent module contains a DSP that absolutely does.

What's Inside a Coherent Pluggable

A QSFP28 SR4 module contains a VCSEL array, a photodetector array, and passive optical components. The signal encoding is straightforward NRZ (Non-Return-to-Zero) at 25.78125 Gbps per lane. There's no local oscillator, no carrier phase recovery, no DSP performing coherent signal processing.

A 100G ZR module—take the Acacia (Cisco) QSFP28 ZR or the Lumentum QSFP28 DWDM coherent as examples—contains a narrow-linewidth tunable laser, an IQ modulator, a coherent receiver with 90° optical hybrid, and a coherent DSP chip. The modulation format is DP-QPSK (Dual Polarization Quadrature Phase Shift Keying) for 100G at 50 GHz spacing. The DSP performs chromatic dispersion compensation, polarization mode dispersion tracking, carrier frequency recovery, and phase noise compensation—all in real time.

The coherent DSP needs a frequency reference to maintain its internal timing and, more critically, to define the DSP's FEC (Forward Error Correction) frame timing. If the DSP's frequency reference drifts, the FEC frame alignment drifts, and once the FEC frame is misaligned, the error correction engine stops working and BER (Bit Error Rate) rises sharply. The transition from functional link to failed link can happen in seconds when timing loss occurs.

Frequency vs. Phase: What Coherent DSPs Need

The precision timing requirements for coherent pluggables exist at two levels: frequency accuracy and phase alignment.

Frequency accuracy affects the coherent DSP's ability to lock its carrier recovery loop to the incoming optical signal. The local oscillator (the tunable laser) and the incoming optical carrier from the far end must be within the DSP's carrier recovery pull-in range, which is typically ±1.5 GHz for modern coherent receivers. This frequency accuracy requirement is met by the laser tuning accuracy, not by network timing—it's a hardware specification of the coherent module itself.

Phase alignment is where SyncE and PTP matter. Coherent pluggables used in OTN (Optical Transport Network) or Ethernet transport roles often need to pass through timing information from one end to the other. More directly relevant: the host router or switch port feeding the coherent pluggable must provide a sufficiently clean transmit clock to the module. The ZR specification requires that the host-side electrical interface provide a clock with accuracy better than ±20 ppm under normal conditions and better than ±100 ppm under holdover.

The PTP Connection: Why It's Not Just for Telcos Anymore

PTP (Precision Time Protocol, IEEE 1588-2008 and the newer IEEE 1588-2019) distributes sub-microsecond timing accuracy across packet networks. In the telecom world, PTP is mandatory for LTE and 5G base station timing. In the coherent transport world, PTP becomes relevant when the coherent transport link itself needs to be timestamped or when the coherent module participates in a timing chain.

For 100G ZR specifically, PTP matters in two scenarios. First, if the ZR link is carrying timing-sensitive traffic (SyncE over Ethernet, 1588 timing streams), the coherent DSP needs to preserve timing transparency—it cannot introduce asymmetric delay that would corrupt PTP offset calculations. Second, if the router port that hosts the ZR module is a PTP Boundary Clock (BC) or Transparent Clock (TC), the ZR link's latency characteristics need to be known and stable for the BC/TC to account for link-side delay correctly.

Modern coherent ZR modules from Coherent Corp., Acacia/Cisco, and Lumentum specify a per-module propagation delay and a delay variation (jitter) floor. The propagation delay through the DSP is typically in the range of 1–3 μs, which is significant for PTP sub-microsecond applications. The delay variation—the variation in DSP processing time between packets—is typically under 100 ns, which is within acceptable bounds for most G.8275.1 (telecom profile) PTP applications.

SyncE: The Physical Layer Timing Standard

SyncE (Synchronous Ethernet, defined by ITU-T G.8262 and G.8264) distributes frequency synchronization via the Ethernet physical layer clock. The idea is simple: the Ethernet PHY on a SyncE-capable port slaves its transmit clock to the received clock, making the physical layer timing chain a frequency distribution network.

The interaction with coherent pluggables is subtle. A 100G ZR module that is used as the physical layer for a SyncE link needs to preserve the input clock frequency across the coherent DWDM span. The ZR specification requires that the module's clock recovery from the host electrical interface be SyncE-transparent—meaning the module retains the timing information encoded in the electrical lane and forwards it optically to the far end.

Not all 100G ZR implementations are equally SyncE-transparent. Some first-generation ZR implementations used their internal DSP clock as the retiming reference, effectively breaking the SyncE chain across the coherent span. This was a known issue with certain early Acacia modules and was addressed in firmware updates. Before deploying 100G ZR in a SyncE timing chain, verify that the specific module firmware version is SyncE-transparent. This is documented in vendor release notes but is frequently missed during evaluation.

What Happens When You Ignore Timing Requirements

The failure mode for ignoring timing requirements in a coherent ZR deployment is not dramatic—the link typically comes up and passes traffic initially. The problems emerge over time.

First: frequency wander. If the host router port is not providing a stable frequency reference (because SyncE is not configured, or because the port's reference clock is coming from a free-running oscillator rather than a locked source), the coherent DSP's frequency tracking loop will see long-term frequency drift. The DSP's acquisition range is wide enough to handle this for weeks or months, but eventually the cumulative drift can exceed the pull-in range and the link will drop. The troubleshooting path is non-obvious because the link was working fine the previous week.

Second: timing chain corruption. In a network where the coherent ZR link is part of a PTP timing path, a SyncE-opaque ZR module introduces an asymmetric delay that biases PTP offset calculations. This appears as a slowly growing time error on PTP slaves downstream of the coherent link—the clocks appear stable but are systematically offset from true time.

Third: holdover failure. Coherent DSPs in ZR modules maintain an internal holdover oscillator to ride through brief reference clock interruptions. The holdover accuracy is typically ±100 ppm for 24 hours (per G.8262 SyncE ESEC specification). If the network relies on ZR modules for timing distribution and the reference clock fails, the DSP's holdover quality determines how long the timing chain remains within acceptable bounds before alarms are triggered.

The summary for operators: deploy 100G ZR in timing-sensitive networks only after confirming SyncE transparency in the specific firmware version you're running, verify that the host router port provides a SyncE-locked or PTP-disciplined reference clock, and document the ZR DSP propagation delay for any PTP Boundary Clock calculations. These checks take less than an hour on a lab unit before deployment and prevent a category of subtle failure that is otherwise very difficult to diagnose in production.