FTTH ONU Turn-Up and Acceptance: A Verifiable Workflow

A field technician mounts an ONU, powers it up, and calls the NOC: the customer’s laptop still can’t browse. Was the fiber spliced correctly? Is the ONU registered on the right PON port? Are optical levels inside spec, or is a dirty connector dragging RX down? Without a repeatable turn-up and acceptance workflow, these activations turn into repeat truck rolls, disputed installs, and support tickets that never quite close. This guide walks through an end-to-end FTTH turn-up sequence that produces evidence at each step, so an activation either passes acceptance cleanly or fails with a specific, actionable reason.

When the Turn-Up Workflow Starts

The workflow begins when a work order transitions from “provisioned in the office” to “physically installed at the premises.” That trigger matters: office provisioning and field installation are different failure domains, and treating them as one step is how bad acceptances slip through. A turn-up should only proceed when the drop is spliced, the ONU is powered, and the subscriber record already carries a plan, service profile, and intended PON assignment.

Pre-Conditions to Confirm

Before anyone touches optics, confirm the basics. The subscriber exists in your billing and network records. The service plan and bandwidth profile are attached. The intended OLT, PON port, and ONU serial or MAC are recorded on the work order. If any of these is missing, stop: an unregistered or mismatched ONU will discover onto the network but never map to the right customer, and you will spend the afternoon untangling it.

Step One: Discovery and Identity Verification

Once the ONU is powered, it should appear on the OLT as an unauthorized or pending unit. This is your first hard checkpoint. The serial number the OLT reports must match the serial on the work order. A mismatch here almost always means the wrong ONU was installed, two work orders were swapped, or someone transposed digits during dispatch.

Do not authorize an ONU whose reported identity does not match the order. Silent authorization of a mismatched unit is the root cause of a large share of “customer says internet is down but our system shows active” tickets, because the traffic and billing are attached to the wrong subscriber.

Failure Checks During Discovery

• ONU never appears: check power, check the fiber is seated, and confirm the PON port is the one you expect.
• ONU appears on the wrong PON port: the physical patching does not match the design; correct the record or the patch, not both blindly.
• Duplicate serial or MAC: a cloned or reused ONU is on the network; quarantine before authorizing.

Step Two: Provisioning to Profile

With identity confirmed, apply the service profile: the bandwidth limits, VLAN or service mapping, and any voice or IPTV configuration the plan requires. The goal is that two technicians turning up the same plan produce byte-identical configurations. Free-hand configuration is where drift starts, and drift is what makes the next fault impossible to diagnose because no two ONUs are configured the same way.

What “Provisioned” Actually Means

Provisioned does not mean “the ONU registered.” It means the ONU registered and received the correct profile and the profile matches the plan on the subscriber record. Reconcile all three. If the plan says 300 Mbps but the applied profile caps at 100 Mbps, the customer will complain within a week and the ticket will bounce between billing and NOC until someone rechecks the turn-up.

Step Three: Optical Acceptance Checks

Optical levels are the single most useful acceptance measurement in FTTH, because they catch physical problems that configuration cannot. Read the ONU RX (light the ONU receives from the OLT) and the ONU TX (light the ONU sends upstream), and confirm both fall inside the operating window for your PON standard and optics vendor. Validate the exact thresholds against your OLT and ONU documentation and your PON design budget; do not rely on a memorized number.

Reading the Numbers

Low ONU RX usually points to a dirty or poorly seated connector, a tight bend, a bad splice, or a split ratio and distance combination that exceeds your loss budget. Abnormal TX can indicate a failing ONU laser. A reading that sits right at the edge of spec is not a pass to celebrate; it is a fault scheduled for a rainy week. Record it, flag it, and decide whether to clean, reseat, or re-splice before you leave.

Do the Comparison

Compare this ONU’s readings to healthy units on the same PON port. If one drop reads several dB worse than its neighbors, the problem is almost always in that drop, not the OLT. This neighbor comparison turns a single ambiguous reading into a clear diagnosis.

Step Four: Service Validation and Sign-Off

Physical and optical health do not prove the customer has service. Validate the end-to-end path: the ONU obtains its intended addressing, the session establishes, and a real throughput or reachability test succeeds at the customer-facing port. Only then does the work order earn acceptance.

1. Confirm ONU discovered with matching serial and PON port.
2. Apply and verify the service profile against the billing plan.
3. Read and record ONU RX and TX; confirm both are in spec.
4. Establish the session and run a reachability or speed check at the premises.
5. Capture all readings against the subscriber and mark the order accepted.

“Done” means every one of those checks passed and the results are stored where the next engineer can see them. If any check fails, the order stays open with the specific failing step named, so the follow-up is targeted rather than a blind revisit.

How ISPbills Supports This Workflow

ISPbills connects subscriber, billing, support, and network workflows in one operational system, which is exactly what a clean turn-up needs, because identity, plan, and optical evidence all have to line up against one subscriber record. For discovery, ISPbills provides OLT and ONU auto-discovery across supported vendors, so a newly powered ONU surfaces for identity verification instead of hiding on the OLT until someone notices. Verify that your specific OLT and ONU models are supported in your deployment before you depend on this.

For the provisioning step, ISPbills provisioning templates help you apply the same service profile the same way every time, which is how you stop configuration drift between technicians. During acceptance, ISPbills offers PON-port monitoring and optical RX/TX signal visibility across supported vendors, so the RX and TX readings that form your acceptance baseline live alongside the subscriber and plan rather than in a screenshot that gets lost. The operational handoff that becomes simpler is the field-to-NOC transition: because discovery, profile, and optical evidence sit together, the NOC can confirm acceptance without a phone call, and the next fault starts from a known-good baseline. Confirm which of these capabilities are available on your plan and validate their behavior in your environment before rollout.

A Decision Standard for Acceptance

Adopt a single rule your team can apply without debate: an FTTH turn-up is accepted only when identity matches the work order, the applied profile reconciles with the billing plan, optical RX and TX are inside documented spec, an end-to-end service test passes, and all of that evidence is recorded against the subscriber. If any element is missing or marginal, the order stays open with the failing element named.

Before you standardize this workflow, validate your PON optical thresholds against your OLT and ONU vendor documentation and your own loss budget, confirm your provisioning templates against your current service plans, and check that your record-keeping meets any local regulations that apply to your operation. The value of this workflow is not that it makes turn-ups faster on a good day; it is that it makes a bad turn-up fail loudly at the premises, while a technician is still standing there, instead of quietly failing into a support queue a week later.

Research basis: ISPbills product documentation; Broadband Forum technical resources. Validate implementation details against the software releases, contracts, configurations, and local regulations governing your network.