Make OLT and ONU Inventory Agree with the Fiber Plant
An operational model for keeping OLT configuration, ONU identity, subscriber ownership and outside-plant records synchronized.
An operational model for keeping OLT configuration, ONU identity, subscriber ownership and outside-plant records synchronized.
Four systems describe the same service
A fiber subscriber exists in at least four places: the commercial customer record, the OLT configuration, the physical splitter/drop plant and the live telemetry system. Incidents become slow when these descriptions disagree.
Customer
Who owns the service and which package is intended?
Logical access
Which OLT, PON, ONU ID, profiles and VLANs deliver it?
Physical path
Which feeder, splitter ports, drop and termination carry it?
Observed state
What registration, optical and Ethernet evidence exists now?
Choose immutable and replaceable identities
The database primary key should not be an ONU ID assigned on one PON; that value can change during reprovisioning. Preserve vendor serial or other authorization identity, chassis/slot/port context, current ONU ID and device lifecycle separately.
| Identifier | Stability | Use |
|---|---|---|
| Inventory record ID | Permanent | Joins history, customer and work orders |
| Vendor serial/LOID | Device lifetime | Registration and replacement control |
| OLT/PON/ONU ID | Provisioning lifetime | Commands and live polling |
| Drop/splitter port | Physical assignment | Fault radius and field navigation |
Discover without auto-authorizing
An unconfigured ONU appearing on a PON is useful evidence, not permission to activate service. Place discoveries in a queue that shows serial, first/last seen, PON and any vendor/model data. Activation should require a customer/work-order association and an approved service template.
Compile service intent into vendor commands
Keep a vendor-neutral service intent—management mode, subscriber VLAN, UNI policy, bandwidth profile and required telemetry—then map it through a driver for each supported OLT family and firmware. Do not claim support because login succeeds; support means the required operations are implemented and tested.
- Validate capability. Confirm model, firmware, PON type and required command set.
- Reserve identity. Lock the customer/device/PON association during provisioning.
- Render commands. Produce an auditable plan from approved intent.
- Apply and capture output. Stop on classified errors rather than continuing blindly.
- Read back. Verify ONU, VLAN, profile and UNI state from the device.
- Commit inventory. Mark active only after observed state matches intent.
Poll operational data through a capability contract
CLI, SNMP and vendor APIs expose different detail. Define required fields and a preferred source per driver: system identity, uptime, PON state, ONU registration, last-down reason, optical levels, UNI state and traffic counters. Missing data should be “unsupported” or “unavailable,” never fabricated from another linked device.
When CLI is authoritative, parse prompts, pagination and firmware variants using fixtures captured from real devices. SNMP can provide standardized interface counters as a fallback, but its endpoint and forwarded port must resolve to the OLT—not a MikroTik sharing the same management address.
Reconcile desired and observed inventory
- Authorized on OLT but absent from billing inventory.
- Active customer linked to an ONU no longer present.
- ONU discovered on a different PON without an approved move.
- Service VLAN or profile differs from intended package.
- Splitter/drop assignment missing for an active ONU.
- Replaced device still authorized on another port.
Present these as reconciliation exceptions with ownership and age. Do not automatically delete unknown configurations; they may represent a service not yet imported or an emergency field change.
Close the loop after field work
A completed installation or repair should update the logical and physical record together. Capture ONU serial, OLT/PON position, splitter ports, drop reference, installation optical levels and photographs where policy allows. A later fault can then compare live state with a known-good baseline.
Research basis: GPON/EPON access concepts and vendor OLT operational interfaces. Every driver must be validated against the exact brand, model and firmware before it can modify production configuration.