Interoperability has always been at the core of what we do at CableLabs. A fundamental reason we develop specifications — beyond promoting a new technology — is to enable devices from different suppliers to seamlessly interoperate with one another.
This brings along a host of benefits, most notably that it promotes scale and competition, which in turn lowers costs and leads to a healthy, robust product ecosystem. It’s why most of the specifications that we develop at CableLabs are “interface” specifications. They define the interfaces that devices expose to each other without defining the device’s internal workings, ensuring devices will interoperate with each other while allowing suppliers room to differentiate themselves.
Interoperability can encompass multiple different aspects of how devices work with one another. Within the DOCSIS® specifications, for example, we define how cable modems (CMs) and cable modem termination systems (CMTSs) interoperate with each other at the physical layer, the MAC layer and at higher network layers. We also define how both devices interoperate with management systems. And we’ve even gone a step further, defining how to split a CMTS into two interoperable components: a Converged Cable Access Platform Core (CCAP-Core) and a Remote PHY Device (RPD) as a part of a Distributed Access Architecture (DAA). This distributed, interoperable approach has provided operators with enhanced flexibility and network performance and is now being widely deployed along with the transition to DOCSIS 4.0 technology.
Continuing to Advance Next-Generation PON Technology
The work we’ve done on coherent passive optical networks (CPON) builds upon this same core philosophy of promoting interoperability while also defining and advancing next-generation PON technology.
In December of 2025, we released a CPON physical media dependent (PMD) layer specification, which defines how an optical network unit (ONU) and an optical line terminal (OLT) interoperate with each other at the physical layer (the way they communicate over an optical medium). We also released a CPON transmission convergence (TC) layer specification to define how ONUs and OLTs interoperate with each other at the next higher network layer. Importantly, it does so by leveraging the ITU’s Common TC approach defined in G.9804.2, enabling CPON compliant devices to leverage the network infrastructure already deployed for ITU-based PON systems, adding another layer of interoperability to the mix.
These specifications provide the essential components needed for manufacturers to develop CPON devices that will interoperate with each other, a key first step for enabling the next-gen PON marketplace. But that led us to wonder: is there something more we could do to help start this nascent market?
Pluggable Optical Modules
One thing that is different in the optical networking space in comparison to DOCSIS technology is the growing momentum around pluggable devices. It has been common for some time to see pluggable optical transceivers providing 10 Gbps links, and more recently that’s even extended to 100 Gbps coherent optical transceivers using common QSFP28 form factor pluggable modules. Additionally, in the PON space it has been common for years for OLTs to feature pluggable modules that provide the physical layer optics to OLTs. There’s even been some movement recently toward pluggable modules for ONUs.
Recognizing this trend, we felt it was important to ensure that CPON technology would feature not just interoperability between ONUs and OLTs at the PMD and TC layers, but also that any pluggable modules developed would seamlessly interoperate with any host they were plugged into. This avoids single-vendor siloed solutions, which in turn promotes competition and scale.
Further, as we looked at how a module and a host might interoperate with each other, we realized a couple of very interesting things:
- That the interface we were defining that would split the OLT into two component pieces — a host and a module — could apply equally to an ONU, allowing different suppliers to focus on what they do best.
- That the interface we were defining could also be used to support combining silicon from different suppliers in an integrated device, easing integration and development for all-in-one style devices.
Taken all together, these factors drove us to develop our recently released CPON Modular Interface (MI) specification.
How Does the CPON Modular Interface Work?
In today’s coherent optics transceivers, the Forward Error Correction (FEC) functionality typically resides in the coherent DSP, which also handles other physical layer functions, and the expectation is that this would need to continue with CPON, which would require the FEC functionality to reside in the pluggable module. However, within the CPON protocol stack, the FEC functionality resides within the TC layer rather than the PMD layer. This led to our first key decision: to place the split between the host and the module within the TC layer, rather than on the boundary between the PMD and TC layers.
The other key decision that we made was not to choose a specific form factor. In part, this was driven by a desire to avoid being locked into a single form factor given how technology continues to evolve; it was also driven by the desire to include support for non-modular implementations that use chips from different suppliers. This required us to design our protocol in a manner that was specific enough to drive interoperability, yet flexible enough to support different electrical interfaces (and therefore different pluggable form factors).
After making those key decisions, the next step was to define how the bitstream would be carried from a host to a module (and vice versa).
In the downstream direction, there is a constant bitstream, which simplifies the problem somewhat. The unit of transfer (so to speak) is the FS Frame (Framing Sublayer Frame) with PSBd (PHY Synchronization Block downstream). That bitstream is first scrambled to ensure a good distribution of 1s and 0s. Then, for cases where a design requires it, devices can optionally utilize a Reed-Solomon FEC. The resulting bitstream is then distributed across the appropriate number of lanes based on the electrical interface being used between the host and module. Next, the bitstream traverses whatever electrical interface is being employed. Note that while the specification doesn’t define a specific electrical interface, it does require that devices support an appropriate one from the OIF’s CEI specification, which includes a range of options operating at different baud rates and with different numbers of lanes. Then, on the other side of the electrical interface, the bitstream is de-skewed and re-serialized, error corrected (if FEC was used) and descrambled. The net result is that the original bitstream is restored without modification.
In contrast to the downstream with its constant bitstream, the upstream in a CPON system is bursty in nature, which creates challenges for modular electrical interfaces. Therefore, the CPON MI defines a mechanism for converting burst transmission into a constant bitstream through the inclusion of Dead Time Markers (to fill space where there’s no data to transmit) and Burst Start Markers to indicate when there is data to transmit. Other than that, the upstream operates much like the downstream, except that the unit of transfer is the FS burst rather than the FS frame plus PSBd.
The final piece to the puzzle is the CPON MI management interface, through which the host is able to learn a module’s capabilities and configure them. For this purpose, we leveraged the OIF’s CMIS and Coherent CMIS specifications, with new extensions specific to supporting the requirements of a coherent PON system.
The details can be found in the recently published CPON MI specification.
What’s Next for CPON?
With the CPON MI specification, building on top of the CPON PMD and TC layer specifications and in keeping with our core philosophy of interoperability, we’ve laid the groundwork to enable manufacturers to build CPON OLT and ONU hosts and modules that interoperate with each other. This in turn sets the stage for a robust, competitive ecosystem for next generation PON devices.
The next step is now in the hands of manufacturers to decide when they are ready to build CPON devices. When they do, CableLabs — as with the other technologies we’ve developed — will be right there to support them throughout the process to ensure we can achieve the ultimate goal of a large-scale healthy ecosystem of interoperable devices from multiple manufacturers.
It’s going to be a fun ride.
