Multi-vendor OLT and GPON / XGS-PON management — under one console.
Huawei, ZTE, FiberHome, CDATA, V-SOL, HSGQ, BDCOM, Nokia and more — abstracted behind one vendor-neutral interface. Cards, ports and environment are monitored continuously. ONTs are auto-discovered (including unauthorised ones), provisioned in seconds and reclaimed cleanly. Optical Tx/Rx power thresholds catch a degrading splice weeks before the subscriber does.
FTTH operators running mixed-vendor OLT estates who are tired of juggling four vendor UIs.
OLT and PON management is the technical differentiator that separates general-purpose network tools from ISP platforms. LibreNMS, Zabbix and SolarWinds all treat an OLT as another SNMP device. That is technically true and operationally useless.
Netxol NMM models the OLT natively: cards, ports, PON trees, ONUs. Discovery finds every OLT and every attached ONT — including the ones that plugged themselves in without going through the sales system, which every operator has more of than they admit. Vendor differences are hidden behind an adapter layer, so a Huawei OLT, a ZTE OLT and a FiberHome OLT all present the same operational vocabulary.
Optical monitoring is the quiet win. Continuous Tx/Rx power measurement per ONU produces a signal that is subtle but true: a splice degrades gradually over weeks before it fails hard. Threshold rules land as an early alarm — the operator schedules a maintenance window, not a firefight — and customer-facing outage minutes drop measurably.
ONT provisioning is the operational win. A subscriber signup that used to trigger a phone call to the network engineer to "activate the ONT on port 3/1/12" becomes a one-click event on the shared graph. Deactivation on churn is symmetric: the ONT is reclaimed cleanly and returned to inventory, so it does not become a phantom line item on next year's asset register.
Four moves.
Discover the OLT estate
Auto-inventory Huawei, ZTE, FiberHome, CDATA, V-SOL, HSGQ, BDCOM, Nokia and other mainstream OLTs.
Provision + reclaim ONTs from one place
One-click ONT activation. Clean deactivation on churn. No shell sessions on the OLT.
Monitor optical power continuously
Per-ONU Tx/Rx dBm with threshold alarms — the earliest warning of a degrading splice or a dirty fibre.
Plan PON capacity by port
Per-port utilisation trend across the whole estate — shows exactly where congestion will appear next.
Every vendor, every PON standard, every ONT.
The Netxol NMM OLT layer is the piece that makes the platform a real ISP tool instead of a general-purpose network monitor. It abstracts the mixed-vendor fibre plant that most operators actually run, models the OLT natively (chassis, cards, ports, PON trees, ONTs), auto-discovers attached ONTs (including rogue ones), provisions and reclaims cleanly, and monitors optical power continuously so a splice degradation becomes an early alarm instead of a mid-outage phone call. The sections below walk through the specific vendors and technologies.
GPON (G.984) — the workhorse standard
ITU-T G.984 GPON delivers 2.488 Gbps downstream / 1.244 Gbps upstream over a passive optical distribution network, typically with a 1:32 or 1:64 split ratio and a 20 km reach. Netxol NMM models every GPON OLT natively: OLT / chassis / card / port / PON tree / ONU. Per-ONU capacity is tracked in real time; per-port oversubscription is visible on a heat map; upstream congestion is called out per PON port so the operator can rebalance splits before the subscriber notices.
- ITU-T G.984 native modelling
- 2.488G down / 1.244G up
- 1:32 and 1:64 split ratios
- 20 km standard reach
- Per-PON capacity heat maps
XGS-PON (G.9807) — 10G symmetric fibre
ITU-T G.9807 XGS-PON delivers symmetric 10 Gbps in both directions, on the same physical fibre that carries GPON — enabling gradual migration where new subscribers land on XGS-PON while legacy subscribers stay on GPON on the same OLT. Netxol NMM models XGS-PON side-by-side with GPON and shows per-ONU technology in the same subscriber record, so the CRM and Billing pieces reference the correct plan tier automatically.
- ITU-T G.9807 XGS-PON support
- Symmetric 10 Gbps
- Coexists with GPON on the same fibre
- Per-ONU technology on the graph
- Plan-tier awareness in CRM / Billing
Huawei OLTs — MA5800, MA5680T, EA5800
Huawei OLTs are the largest single vendor in the FTTH market — MA5800-X17 (17-slot chassis, up to 30k ONTs), MA5680T (legacy but still deployed), EA5800 (compact, 8-slot). Netxol NMM has a native Huawei adapter that speaks Huawei-specific line-card commands (GPBH, GPBD, GPFH cards), reads optical power from the MA5800 diagnostic interface, and provisions ONUs without the operator ever needing a Huawei-shell session. The Huawei MML command set is fully supported for advanced operators who still want CLI escape.
- MA5800-X17 (up to 30k ONTs)
- MA5800-X15 / X7 / X2
- MA5680T (legacy)
- EA5800 series compact chassis
- GPBH / GPBD / GPFH line cards
- Native optical-power read
- MML CLI escape when needed
ZTE OLTs — C300, C320, C600, C650, C650V2
ZTE is the second-largest OLT vendor in the operator markets Netxol targets. The Netxol NMM ZTE adapter supports the C300 / C320 (10G / GPON), C600 / C650 / C650V2 (chassis-scale XGS-PON and 25G-PON ready), and the smaller ZXA10-series. Card management (GTGO, GTGH, GTGHK) is abstracted through the same OLT vocabulary as Huawei, so operators moving between vendors do not have to relearn their operational language.
- C300 / C320 GPON
- C600 / C650 / C650V2 XGS-PON
- C650V2 25G-PON ready
- ZXA10 compact OLTs
- GTGO / GTGH / GTGHK card management
- Unified vocabulary with Huawei / FiberHome
FiberHome OLTs — AN5516, AN6000
FiberHome is heavily deployed in Pakistan, Bangladesh, Vietnam, Nigeria, Ghana and across Sub-Saharan Africa. Netxol NMM ships a FiberHome adapter that handles the AN5516-01 / AN5516-06 (large chassis GPON), the AN6000 (XGS-PON), and the smaller AN5008. Optical power is read directly from ONU pon-onu-status commands; card presence and health from card show; provisioning through native FiberHome commands wrapped behind the vendor-neutral API.
- AN5516-01 / AN5516-06 GPON
- AN6000 XGS-PON
- AN5008 compact
- Native optical-power read
- Vendor-neutral API wrapper
CDATA, V-SOL, HSGQ — the value-vendor tier
For value-tier deployments — small ISPs, greenfield builds, MDU rollouts — CDATA (FD1000 / FD1104 / FD1508 / FD1616), V-SOL (V1600G / V2801 / V2802 / V2804), and HSGQ (E series) are common OLT choices. Netxol NMM has adapters for all three. These OLTs are typically single-chassis / single-card units; the Netxol model still treats them as OLT → PON → ONU consistently, so the operator sees the same operational vocabulary as they would on a Huawei MA5800.
- CDATA FD1000 / FD1104 / FD1508 / FD1616
- V-SOL V1600G / V2801 / V2802 / V2804
- HSGQ E-series
- Single-chassis modelling
- Same vocabulary as tier-1 vendors
BDCOM, Nokia, DASAN, Raisecom — every other mainstream vendor
The other mainstream OLT vendors — BDCOM (P3310, P3316, P3608), Nokia 7360 ISAM FX (large-carrier deployments), DASAN (V5824G / V8240 / V8102), Raisecom (RC series) and Alphion — all have adapter support. If your operator estate mixes vendors, the Netxol NMM console shows them all as one estate, one map, one alarm inbox, one PON-tree browser. The vendor tag is metadata, not a UI split.
- BDCOM P3310 / P3316 / P3608
- Nokia 7360 ISAM FX (Alcatel-Lucent lineage)
- DASAN V5824G / V8240 / V8102
- Raisecom RC series
- Alphion, Sundray, Iskratel on roadmap
ONT auto-discovery — including rogue detection
Every operator has ONTs on their network that did not come from the sales system. A neighbour lent one to a friend; a residential-tier ONT ended up on a small-business drop; a contractor swapped out an ONT during a repair and did not log it. Netxol NMM discovers every ONT on every OLT continuously and surfaces the ones that do not match the CRM subscriber record — the "rogue ONT" list is visible to the operator on day one, and the CRM can be sent an action to reconcile.
- Continuous ONT auto-discovery
- Rogue ONT surfaced against CRM
- CRM reconciliation actions
- MAC + serial + PON port fingerprinting
- Historic first-seen date recorded
OMCI (G.988) configuration
OMCI (ONT Management Control Interface, ITU-T G.988) is the language spoken between an OLT and its attached ONT. Netxol NMM speaks OMCI natively for the four major vendor variants (Huawei OMCI, ZTE OMCI, FiberHome OMCI, standard OMCI) — traffic profiles, DBA profiles, GEM ports, T-CONTs, service ports, VLAN forwarding, upstream QoS. Complex OMCI operations that used to require a vendor-shell session are one-click actions on the NMM console.
- G.988 OMCI native support
- Traffic / DBA / GEM / T-CONT profiles
- Service port + VLAN forwarding
- Upstream QoS by ONT class
- Vendor-specific OMCI variants abstracted
Optical power monitoring — the leading indicator
A splice does not fail all at once. It degrades — 0.1 dB, 0.3 dB, 0.5 dB — over a period of days or weeks, until it crosses the threshold at which the ONT drops link and the subscriber calls in. Netxol NMM records per-ONU Tx / Rx dBm continuously; threshold rules land as an early alarm on the graph, referencing the affected subscriber automatically. Operators using Netxol regularly avoid outages that would have happened otherwise. See /blog/optical-power-leading-indicator for the operational study.
- Per-ONU Tx / Rx dBm continuously
- Baseline captured at ONT install
- Threshold rules by ONT class
- Alarm names affected subscriber automatically
- Historic optical trend on subscriber record
PON capacity planning
Every operator eventually oversubscribes their PON. A 1:32 GPON split with an aggressive peak-hour load will queue upstream. Netxol NMM shows per-PON port utilisation over time, per-ONU contribution to the port, and a predictive view of when the port will require re-splitting or an XGS-PON overlay. The planning conversation stops being anecdotal and starts being data-driven.
- Per-PON port utilisation trend
- Per-ONU contribution attribution
- Predictive congestion warning
- Re-splitting recommendation engine
- XGS-PON overlay planning aid
Migrating off vendor EMS — Huawei UMA, ZTE NetNumen, Nokia AMS
Operators typically arrive at Netxol NMM from a mixed-vendor pile: Huawei UMA / U2000 / iMaster NCE for the Huawei OLTs, ZTE NetNumen for the ZTE OLTs, Nokia AMS for the Nokia OLTs — plus a subscriber spreadsheet or two. The Netxol migration flow reads the vendor EMS configuration exports, reconciles them against the actual OLT state discovered on first Netxol contact, imports the ONT inventory, and preserves the historic optical-power baseline where the vendor EMS retained it. Nobody has to re-configure their fibre plant.
- Huawei UMA / U2000 / iMaster NCE import
- ZTE NetNumen export import
- Nokia AMS import
- Auto-reconciliation against live OLT state
- Historic optical baselines preserved
- Dry-run migration mode
Everything you get with this playbook.
We usually pair this playbook with Netxol Core X20.
The X20 is engineered for large fibre operators who serve hundreds of thousands of subscribers across dozens of POPs. Dual-socket EPYCs, half a terabyte of memory, and enough network throughput to keep telemetry, provisioning and billing running without ever blinking.
Operators already running this play.
Questions we get on the first call.
How long does it take to go live?
Small deployments complete in under a week from unboxing the Core to first paying subscriber; larger rollouts scoped in weeks not months.
Do we need to change our existing hardware?
No. NOS ships adapters for every mainstream OLT and router. You keep the gear you own; we replace the tooling above it.
What happens to our data?
Everything stays on your Core appliance by default. Backups go to your object store of choice. No subscriber data leaves your rack unless you turn on an opt-in telemetry channel.
Can we migrate from another platform?
Yes — we run a scoped migration project with matching data mappings and cut-over windows. Standard editions include the first migration.
Other stories in this shape.
The Netxol ACS ships with NMM. It handles CWMP for legacy CPE, USP (TR-369) with MQTT and WebSocket for modern devices, TR-181 device modelling, TR-143 speed tests, zero-touch onboarding by service profile and a firmware repository with staged rollouts and rollback. And because it lives on the shared graph, a CPE change and a subscriber-plan change are the same conversation.
ReadOutcomeShip an ONT to a subscriber. When they plug it in, NOS provisions it, binds it to their record, and lights up their plan — without a technician touching a config file.
ReadOutcomeMost of what a NOC does at 3 a.m. is small, boring and repeatable. NOS is built to notice those patterns, act on them safely, and keep humans in the loop for anything that isn’t routine.
Read