Multi-vendor GPON at scale: a study of what breaks between 20K and 200K ONTs

The FTTH industry's open secret is that "multi-vendor GPON" works fine at small scale and breaks in four specific ways as the operator grows. This study looks at the transitions between 20K, 50K, 100K and 200K ONTs, based on production deployments we have watched.

The Broadband Forum and ITU-T maintain the primary specifications: [ITU-T G.984](https://www.itu.int/rec/T-REC-G.984.1/en) for GPON, [G.987](https://www.itu.int/rec/T-REC-G.987/en) for XG-PON and [G.9807](https://www.itu.int/rec/T-REC-G.9807/en) for XGS-PON. Compliance to those specs is not the problem. Interoperability with the operator's billing, monitoring and provisioning stack is.

The four things that break

1. 1OMCI dialects. Every OLT vendor implements OMCI (ITU G.988) with quirks. At 20K ONTs the operator has memorised the top three quirks. At 200K they have unwritten scripts to work around dozens.
2. 2ONU provisioning latency. Vendor UIs generally work at 20K. Above 100K the vendor UI becomes a bottleneck for onboarding — the network can serve subscribers faster than the tool can enrol them.
3. 3Optical power baselines drift silently. A batch of ONUs installed a year ago is drifting toward a threshold; the operator does not know because per-ONU historical baselines were never captured. This is the leading cause of surprise mass-outage.
4. 4Alarm correlation across vendors is manual. A trunk fibre cut causes each vendor OLT to raise its own alarm shape; without a common vocabulary the NOC opens four incidents for one event.

The 20K–50K transition

Operators between 20K and 50K subscribers usually run 2–4 OLT chassis, often from two vendors. The manual overhead is still manageable — one lead network engineer holds the operational knowledge in their head. The failure mode is single-person-dependency: when that engineer leaves, tribal knowledge leaves with them. Netxol's [multi-vendor OLT solution](/solutions/olt-management) is designed to externalise that knowledge into the platform.

The 50K–100K transition

Between 50K and 100K, the operator typically hires a NOC team of 3–6 engineers and starts feeling the alarm-correlation gap. The vendor UIs no longer scale; a unified console becomes an operational necessity, not a nice-to-have. Optical baseline drift starts producing surprise outages if per-ONU history is not captured.

The 100K–200K transition

Above 100K the operator is running 8–20+ OLTs across multiple POPs. At this scale, OLT configuration management (change validation + audit + rollback) becomes the difference between a working ISP and a very expensive lottery. Netxol NMM handles OLT configuration through validation + audit — see [Netxol NMM](/products/modules/nmm) for the full capability set.

Optical power monitoring as the leading indicator

Of the four failure modes, optical power drift is by far the most valuable to instrument early. Per-ONU Tx/Rx dBm captured continuously, with per-unit baseline retention and threshold alarms, converts a surprise fault into a scheduled maintenance window. It is the single monitoring feature we would recommend an operator implement first.