A rogue ONU is a terminal that transmits outside its assigned time slot — usually a laser stuck in continuous mode — and it takes down every subscriber on the PON port, not just its own, because the OLT burst receiver can no longer resolve anyone's preamble.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
The hard part is not the technology. It is that the fault moves into somebody else's living room. The OLT reports a whole port down, the call centre gets a cluster of complaints from one neighbourhood, and somewhere at the end of a splitter branch a small terminal is quietly transmitting non-stop.
GPON upstream at 1310 nm and 1.244 Gbit/s is shared. The OLT slices time into 125 μs frames and assigns slots by ranging result, so only one ONU should be transmitting at any instant.
Two failure modes exist: continuous transmit, where the laser never turns off, and wrong-timeslot transmit, where the timing is wrong. The first is more common and far more destructive.
The symptom is port-level, not subscriber-level. With a 1:128 split, one faulty terminal can take 128 households offline at once.
Location is a bisection exercise on the splitter tree, not a command-line exercise on the OLT. The physical path costs about 24 actions; the remote path costs about 20 deactivations if you keep a usable registration list.
GPON downstream is broadcast and upstream is shared. ITU-T G.984.2 sets the upstream wavelength at 1310 nm and the upstream rate at 1.244 Gbit/s. The OLT divides time into 125 μs frames and hands out slots according to ranging results — that is TDMA, and in theory exactly one ONU transmits upstream at any moment.
Two kinds of terminal break that rule.
Continuous transmit. The laser should only fire inside its own slot. A failed driver circuit, runaway firmware or a damaged optical module can leave it on permanently. Its light is present across the entire upstream timeline, so when another ONU's burst arrives it lands on top of a signal that never stopped. The OLT burst receiver cannot separate the two. This is the majority of field cases and the most damaging.
Wrong-timeslot transmit. The ONU transmits for the right duration but at the wrong moment. Typical causes are a bad ranging value — an incorrect equalisation delay setting, an ONU moved without re-ranging at the OLT, or an unstable supply causing internal clock drift. It only collides with its neighbours inside its own incorrect slot, so the blast radius is smaller, but it is much harder to distinguish from the symptoms.
ITU-T G.984.3 defines a framework for handling misbehaving terminals inside the ONU activation state machine and the upstream overhead: the OLT can monitor for upstream anomalies during registration and deactivate the offending ONU once it decides. In practice, most field work still relies on a human finding it.
Understanding this is what keeps you from chasing the wrong symptom.
The OLT burst receiver has to re-establish signal amplitude decision and clock recovery on every single frame, using the preamble bits at the head of each ONU's burst. If a continuous light source is present upstream, the receiver sits permanently in a high optical power state. When a weaker burst arrives, the decision threshold has already been pushed up, the preamble is swallowed, and the entire upstream frame fails to decode.
So the downstream symptom is not "one household dropped". It is every ONU on that port dropping, or cycling up and down repeatedly. At a 1:128 split ratio, a fully loaded port means 128 subscribers losing service at the same time. Complaints cluster in one area, and on the operator side you see the bit error rate on one PON port of one OLT climbing while a large number of ONUs bounce between O3, O4 and O5.
The ONU that is actually causing it has no idea. It keeps transmitting, keeps trying to register, and simply finds that service does not work.
Before anyone travels, narrow the scope from the whole OLT to one port, then to one branch. OLT troubleshooting starts with the port counters; the splitter tree comes afterwards.
| Clue | Normal | Dragged down by continuous transmit | What it tells you |
|---|---|---|---|
| PON port upstream errors / BIP | Near zero | Climbing continuously | Direct evidence of upstream burst demodulation failure |
| ONU online state | Stable O5 | Mass re-registration, bulk drops | Happening almost simultaneously within one port |
| Registered ONU count on that port | Matches provisioning | Number keeps jumping | Drop, re-register, drop again |
| Upstream optical power reading | Varies with traffic | Stuck at a high value for long periods | Some OLTs read upstream power; continuous transmit shows as "always present" |
| Fault footprint | Single point | Whole port, more concentrated under one splitter | Separates a port fault from a single-subscriber fault |
One rule of thumb is worth memorising. If every subscriber under one splitter on a PON port is down while branches on other splitters are also affected, treat it as a port-level fault. If only one splitter branch is completely down, with none of its subscribers reachable and other branches healthy, suspect a continuous-transmit terminal on that branch first. In the second case the rogue signal has already drowned out the other ONUs inside that branch alone.
The main actor in location is the splitter hierarchy, not the OLT command line. This is where GPON troubleshooting differs from switch work: nearly all the useful information sits in the physical plant rather than in a table you can query. The sequence below is ordered by time cost, cheapest first.
| Step | Action | Expected result | Note |
|---|---|---|---|
| 1 | Record the SN and optical power of every registered ONU on the port into a list | A baseline | Some readings will be missing while the port is unstable |
| 2 | Deactivate ONU registrations one at a time on the OLT (illustrative — commands differ by platform, follow the actual CLI) | If the port recovers after one deactivation, the source is identified | Deactivation interrupts that subscriber, so coordinate a maintenance window |
| 3 | Disconnect the output branches of the first-stage splitter and reconnect them one at a time | The port degrades again when a specific branch is reconnected, so the source is on that branch | One to three minutes of observation per reconnection is enough |
| 4 | Disconnect each output of the second-stage splitter on that branch | Narrows to a specific second-stage branch | A second-stage branch usually maps to a building or a unit |
| 5 | Disconnect or swap terminals one by one within the branch | Reaches the terminal | The port recovers once the continuous-transmit terminal is replaced |
Steps 2 and 3 can be swapped. Deactivating registrations leaves the physical plant untouched, which suits remote work at night. Disconnecting splitters needs no OLT credentials, which suits a site where only construction crews are available. Every step after the third divides the search area by the branch count, so the more splitter stages there are, the faster each action converges.
The slow part in the field is not the location logic but the physical work of confirming household by household. If the last splitter stage still has eight households to visit, that is hours of work. Steps 2 and 3 exist precisely to avoid that stretch.
On a port with a long history of this, the fiber splitter loss budget is worth re-checking at the same time. A link running with only a few dB of margin turns any upstream anomaly into a hard outage immediately, which is why the same fault looks catastrophic on one port and tolerable on another. The PON splitter loss figures article has the per-stage numbers.
Once the source is confirmed, the order of handling is fixed at three steps and cannot be reordered. Most OLT troubleshooting time is lost between the first and the second, waiting for someone to confirm the port has actually recovered.
Step one, isolate immediately. Issue Tx Disable to that ONU from the OLT, or deactivate its registration, so the upstream light stops. Deactivation is faster than cutting power and does not depend on anyone being on site. Where remote shutdown is not supported, the only option is to unplug the fibre patch cord at the terminal.
Step two, restore service. After isolation the port error rate should fall back to baseline quickly, and the remaining ONUs will come back online within a few registration cycles. There is a detail that gets missed here: when a large number of ONUs re-register at once, the OLT processes them one after another, and on a fully loaded 1:128 port full recovery takes longer than a single re-registration. Do not decide "it is still broken" halfway through and start operating again.
Step three, repair or replace the terminal. If the cause is a damaged optical module, swapping the module fixes it. If it is a driver circuit or firmware problem, field repair costs more than a replacement. And if a second unit from the same batch shows up within six months, sample the whole batch — optical module ageing tends to correlate by production lot.
Take the mini GPON OLT L102P from Rayin's current line, where a single PON port supports 1:128 splitting — up to 128 ONUs on one port. The ODN is built as one 1:8 stage plus one 1:16 stage. First-stage insertion loss is about 10.5 dB, the 1:16 stage about 13.8 dB, so the two-stage fiber splitter loss comes to roughly 24.3 dB. Add about 1 dB for connectors and splices and the total sits near 25 dB. Class B+ optical budget under ITU-T G.984.2 is 28 dB, which leaves around 3 dB of margin. That is why a fully loaded 1:128 link has so little headroom that any continuous-transmit event shows up immediately as errors.
Now the blast radius. 128 households at an average of three terminals each — ONU, router and two devices — means a single continuous-transmit event affects roughly 384 terminals. Seen from the first-stage splitter, one branch carries 16 households; all 16 on the source branch go down, and the other seven branches also fail because the upstream is drowned out. All 128 households are affected without distinction.
Now the location time. On the bisection path, the first 1:8 stage needs an expected 8 disconnect-and-reconnect actions, the 1:16 stage needs 16, so 24 physical actions in total. At one minute of observation each, that is about 24 minutes, excluding travel. On the remote deactivation path, the worst case is 128 deactivations at 20 seconds each, about 43 minutes, but nobody has to be on site. In practice the better method is to filter the SN list first and exclude terminals with normal traffic records in the last 30 days, which usually cuts the candidate set to 10 to 20, and about 20 deactivations then identify the source in roughly 7 minutes.
The difference between the two paths is whether someone has to travel. Remote deactivation removes travel and door-to-door time, at the price of needing OLT management access and a usable registration list — and that list is something you build in normal operation, not during a fault.
| Measure | How | Cost and boundary |
|---|---|---|
| ONU registration binding | Allow registration only against a whitelisted SN or Password | New subscribers need a process; second-hand terminals need cleaning |
| Terminal admission control | Permit only self-supplied or certified ONU models | Existing third-party terminals need a transition period |
| Upstream monitoring alarms | Threshold alarms on PON port error rate and online ONU count | Too tight and it alarms daily; too loose and it catches nothing |
| Splitter ledger | One-to-one mapping between first and second stage branches and buildings and ports | Needs a one-off investment; reconstructed afterwards it will be wrong |
| Terminal sampling | Sample the whole batch when a second unit from the same lot fails | Sampling consumes test bench capacity |
The best value in that table is the splitter ledger plus registration binding. The ledger turns GPON troubleshooting from a search into a lookup, and registration binding shuts out the largest single variable — a terminal nobody recognises — before it can register.
Rayin's OLT line, including the 1-port and 2-port mini GPON OLT and the 4-port and 8-port box models, has split-ratio guidance per model on the PON access page. Where an industrial site carries video and PLC traffic over optical switches instead, the access layer guidance sits under the industrial Ethernet switch range.
The whole port is down. How do I tell a failed OLT optical module from a continuous-transmit terminal?
Look at the shape of the errors. A failed module usually shows the upstream optical power reading disappearing or sitting abnormally low, and the symptom does not change after a module reset. A continuous-transmit terminal typically shows continuous upstream light with errors that track traffic volume, while downstream broadcast on the PON port stays normal. Register a known-good ONU directly on the OLT port as a test: if its slot is measured normally at the receiver, the OLT transmit and receive side is fine. Another fast check is to deactivate every ONU registration on the port — if the errors stop immediately, the problem is on the terminal side.
Can a continuous-transmit ONU recover by itself?
Almost never. Continuous transmit usually comes from a laser driver circuit or optical module hardware failure, which is not self-recovering. The minority caused by firmware anomalies can come back briefly after a reboot but will recur within hours to days. Leaving it on the network only keeps interrupting the whole port, so once confirmed it should be isolated and replaced.
Does the OLT detect and isolate these terminals automatically?
Some OLTs support detecting upstream optical anomalies and automatically deactivating the suspect ONU, by monitoring continuous upstream light duration or error anomalies and matching against recently registered terminals. That narrows the search but does not replace it, because a wrong-timeslot terminal does not produce continuous light and detection sensitivity is limited. And with automatic deactivation left on by default, an occasional misjudgement takes a healthy subscriber offline. The safer approach is to use the feature as an alarm and leave the action to a person.
Why does every subscriber under one splitter drop, and other splitter branches too?
Because upstream is shared. The first-stage splitter combines all branch light onto one feeder fibre that runs to a single PON port on the OLT. A continuous-transmit signal from any branch travels that feeder into the receiver, raises the decision threshold, and makes burst demodulation fail for the whole port. The footprint is defined by the PON port, not by the splitter.
Is a fully loaded 1:128 port more prone to this?
In probability terms, yes. 1:128 means the most terminals per port and the highest two-stage insertion loss — about 10.5 dB for the 1:8 plus about 13.8 dB for the 1:16, close to 24 dB — so the link has only a few dB of margin and almost no tolerance for upstream anomalies. Recovery also takes longest, because 128 ONUs have to re-register in sequence. That is why fully loaded ports should have ONU registration binding and upstream error alarms enabled together.
OLT Burst Mode Receiver: Why Upstream Optics Must Receive in Bursts
Plan the PON Splitter Hierarchy: 1-Stage vs 2-Stage and dB Budget
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
