PON performance monitoring works in three layers — the PON transport layer (ITU-T G.984.3 alarms and BIP-8), the management channel (ITU-T G.988 OMCI performance counters), and the service layer (802.3ah / 802.1ag / Y.1731 measured as ES, SES and UAS) — and any troubleshooting that skips a layer sends you in circles.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
The reason layering matters is simple: when the optical path is degrading, the packet loss the service layer reports is a symptom, not a cause. When the optical path is clean and packets still drop, the problem is usually a VLAN, a queue, or something upstream — not the fiber. Each layer answers a different question, and reading them in the wrong order wastes hours.
BIP-8 on the PON transport layer tells you whether the optical path itself is healthy; it counts errored blocks, not lost packets, and it is directional.
OMCI performance counters per ONU arrive in 15-minute and 24-hour buckets under ITU-T G.988. A 32-bit byte counter wraps in under 28 seconds at full upstream rate, so counter width is a procurement question, not a detail.
ES, SES and UAS translate "the user says it is slow" into numbers that map directly onto SLA availability clauses.
One cut trunk fiber should produce one alarm, not several hundred — that takes suppression and root cause correlation, which only work if the device exposes parent-child alarm relationships.
Performance data in a PON comes from three places, one per layer.
PON transport layer. ITU-T G.984.3 defines the frame structure and the alarms: BIP-8 interleaved parity checks, LOS (loss of signal), LOF (loss of frame), LOAi (activation failure), plus ONU ranging error. This layer only looks at the optical path and the PON frames themselves — it does not care what service rides on top.
Management channel. ITU-T G.988 defines OMCI performance management. Counters report at 15-minute and 24-hour granularity and cover per-ONU bytes received and sent, errored frames, optical power, temperature and port state. This is where single-terminal detail lives.
Service layer. IEEE 802.3ah (EFM OAM), IEEE 802.1ag (CFM) and ITU-T Y.1731 define connectivity and performance measurement: ETH-CC for connectivity, LM for loss, DM for delay, rolled up into ES/SES/UAS availability metrics.
| Layer | Standard | Main readings | Question it answers | Granularity |
|---|---|---|---|---|
| PON transport | ITU-T G.984.3 | BIP-8, LOS/LOF/LOAi, ranging error | Is the optical path itself healthy? | Per PON port |
| Management channel | ITU-T G.988 (OMCI) | 15-min / 24-hour PM, optical power, temperature | What is this ONU doing right now? | Per ONU |
| Service layer | 802.3ah / 802.1ag / Y.1731 | ETH-CC, LM loss, DM delay, ES/SES/UAS | Is the subscriber's service passing, and how much is it losing? | Per service |
The ordering rule: lower layers explain upper layers, never the reverse. Clean optics plus service-layer loss points at configuration; rising optics errors plus service-layer loss points at the plant. In other words, fiber optic monitoring is read bottom-up, while fault isolation also runs bottom-up — which is why the two disciplines get confused with each other.
BIP-8 is the bit-interleaved parity in G.984.3. Every downstream frame carries one checksum byte; the receiver recomputes it and compares. It answers "did this frame get corrupted in transit", not "did the subscriber lose packets".
Two readings habits matter.
First, it counts errored blocks, not errored bits. A block with one bad bit and a block with eight bad bits both count once. You cannot derive a BER from it — only a trend.
Second, it is directional. Downstream BIP-8 is detected and reported by the ONU and reflects the OLT-to-ONU direction; upstream is detected by the OLT and reflects ONU-to-OLT. If only one direction climbs, the problem sits in that direction's path or module — it is not "the whole link going bad".
LOS and LOF are harder alarms than any error count. LOS means no light is arriving; LOF means light arrives but the frame is out of sync. Either one means that ONU's service is down, full stop — there is nothing to read in the error counters.
In practice BIP-8 earns its keep by separating "degrading optics" from "misconfiguration". Steady BIP-8 while a user reports loss effectively rules out the optical path. Climbing BIP-8 means look at attenuation and modules first, and leave the VLANs alone.
G.988 reports PM counters in 15-minute buckets, and a 24-hour total is assembled from 96 of them. Fine granularity is the benefit; overflow is the price.
Take a 32-bit byte counter. Its maximum is 2³² − 1 = 4,294,967,295 bytes. Full upstream GPON rate is 1.244 Gbit/s, which moves about 155 MB per second:
4,294,967,295 ÷ 155,000,000 ≈ 27.7 seconds
So a 32-bit counter wraps in under 28 seconds at full rate. A 15-minute bucket is 900 seconds — it would wrap roughly 32 times inside a single bucket, and a value read from a 32-bit register is meaningless. That is why the engineering requirement is blunt: PM counters must be 64-bit, or the device must sample and accumulate inside the bucket. Ask "is your PM counting 32-bit or 64-bit" during selection; you cannot fix it after the fact.
The quieter trap is bucket retention. Most devices keep only the most recent buckets — commonly 96, meaning 24 hours. A fault from two days ago has already been overwritten; all you have is the daily rollup. Long-term trends require the network management system to poll and store regularly. The device will not keep it for you.
Users say "lagging". OLT monitoring needs measurable quantities. In the ITU-T Y.1731 and G.826 framework, three metrics do most of the work:
ES (Errored Second): a second containing at least one errored block counts as one ES.
SES (Severely Errored Second): a second where errored blocks reach or exceed 30% counts as one SES.
UAS (Unavailable Second): after 10 consecutive SES the path is declared unavailable, and those seconds count as UAS.
They escalate: ES counts "seconds with errors", SES counts "seconds with bad errors", UAS counts "seconds gone". Availability = (total seconds − UAS) ÷ total seconds.
The payoff is comparability. Different services, vendors and links all reduce to the same scale, and the numbers map straight onto contracts — the "99.9% availability" written into a carrier agreement is calculated on UAS. Loss percentage is a different tool: use ES/SES/UAS for SLA, use loss ratio for capacity analysis, and do not substitute one for the other.
A 1:128 PON port, subscribers reporting "slow in the evenings". Take one 15-minute bucket.
Known: window = 900 s; 12 s contained errored blocks; 3 of those 12 s had errored-block ratios at or above 30%; upstream BIP-8 climbed noticeably faster than downstream.
Step 1 — ES. ES = 12 s, so ES ratio = 12 ÷ 900 = 1.33%.
Step 2 — SES. SES = 3 s (the seconds at or above 30%).
Step 3 — UAS. UAS needs 10 consecutive SES. With 3 non-consecutive ones, UAS = 0.
Step 4 — availability. (900 − 0) ÷ 900 = 100% on the strict UAS basis. The error-free-second ratio is (900 − 12) ÷ 900 = 98.67%.
Step 5 — direction. Upstream BIP-8 outpacing downstream puts the problem in the ONU-to-OLT direction. Combined with the evening pattern, suspect upstream burst collisions or one ONU transmitting abnormally — not downstream attenuation.
| Metric | This example | Suggested threshold | Verdict |
|---|---|---|---|
| ES ratio | 1.33% | 15-min > 1% | Over line, alarm |
| SES | 3 s | 15-min > 0 | Over line, watch |
| UAS | 0 | > 0 | Normal |
| Upstream BIP-8 | Higher than downstream | Any one-direction growth | Points to the ONU side |
| Error-free seconds | 98.67% | > 99.5% healthy | Low |
The verdict: performance degradation, not an outage. Against a 1% ES threshold this port is already over the line and should alarm; against UAS = 0 nobody needs a truck roll. Start remote OLT monitoring — per-ONU upstream byte counts and optical power trends — before anything else.
Thresholds are not constants. Video tolerates loss (it buffers); voice and gaming care about delay and jitter; industrial control tolerates no loss at all. The same counters need different thresholds per service, or you will either alarm daily or miss the real event.
Cut one trunk fiber and here is what the OLT produces: 128 ONUs all report LOS, each ONU's three services raise one alarm each, plus port-down and VLAN alarms — several hundred entries in seconds. There is exactly one fault and a wall of noise.
Alarm suppression and root cause correlation fix this:
Suppression: while a parent alarm is present, child alarms it causes are masked. While LOS is present, that ONU's "service down" and "low optical power" alarms are not raised.
Correlation: alarms under the same fiber or the same splitter aggregate into one entry with a scope label — for example "ODN branch 3, 12 ONUs affected".
Configuration order matters: define the hierarchy first, then the suppression relations. The usual hierarchy is fiber/port → ONU → ONU UNI port → service. When a parent clears, child alarms must be re-evaluated rather than simply restored, or the recovery floods the screen a second time.
This sounds like an NMS feature, but it only works if the device side exposes the parent-child relationships. If the OLT reports "ONU down" without "down on which splitter branch", no management system can correlate it.
Collecting only 24-hour rollups. The daily bucket averages the night fault into the day. Keep at least 15-minute granularity for 7 days or evening-degradation patterns vanish.
Watching alarms but not counters. An alarm is binary; a counter is continuous. Optical power drifting from −22 dBm to −26 dBm triggers nothing at the alarm threshold, yet it is nearing the sensitivity limit — and the error and retransmission counters move first.
One threshold for the whole network. PON ports with different split ratios and distances have different baselines. Error baselines for 1:128 and 1:32 differ by roughly an order of magnitude; a single threshold guarantees false positives. Group thresholds per PON port — it is the cheapest improvement available.
Where the PON uplink rides on an industrial switch, the switch's port counters and module DDM form a second observation plane: the PON side sees ONU-to-OLT errors, the uplink side sees OLT-to-metro loss and optical power. When the two disagree, the problem is usually inside the OLT. The port statistics capability sits under Rayin's industrial Ethernet switch range.
Rayin's L102P mini GPON OLT manages ONUs through OMCI and provides performance counters at both 15-minute and 24-hour granularity; the exact counter width and retained bucket count should be confirmed against the software version. ONU-side optical power and temperature ride the same OMCI channel, so aligning the three segments — optics, ONU, service — is a configuration exercise, not a project. Device specifics are on the PON access page.
BIP-8 is incrementing. Does that mean the optical path is definitely faulty?
No. BIP-8 counts PON frame checksum results, and a transceiver running near its limits — receive power close to sensitivity, or a module running hot — also produces errors without any fiber break or degraded splice. Read the shape: whether it is one-directional, whether it tracks temperature, and whether the count follows a module swap.
Is an errored second the same thing as packet loss?
No. ES counts seconds containing at least one errored block; loss ratio counts packets as a percentage. One percent ES can coexist with very low loss (one bad packet per second) or very high loss (the bad second dropped 30% of its packets). Use ES/SES/UAS for SLA accounting and loss ratio for capacity work — neither substitutes for the other.
Why does a 15-minute counter sometimes read absurdly low?
Almost always 32-bit wraparound. At full 1.244 Gbit/s upstream a 32-bit byte counter wraps in under 28 seconds, so a 900-second bucket wraps more than 30 times. Require 64-bit counters, or confirm the device samples and accumulates within the bucket. This has to be settled at selection time; it cannot be patched afterwards.
One trunk fiber failed and the management system raised hundreds of alarms. How should that be handled?
With suppression and correlation, not with human filtering. The device side has to expose the fiber → ONU → UNI port → service hierarchy so the NMS can mask child alarms when a parent is present. If the equipment only raises isolated alarms, group by ONU-ID manually: a large set of ONUs going LOS at the same moment points at the trunk or a splitter, not at individual terminals.
Can service-layer delay be measured without dedicated test instruments?
Yes. Y.1731 DM sends measurement frames between the two endpoints and yields one-way or round-trip delay, provided both ends support it and — for one-way figures — clock sync is good enough. Without that capability, fall back to ping RTT trends: crude, but it catches step changes.
GPON Network Inspection Checklist: 5 Steps Before a Fault Happens
Network Latency, Jitter and Packet Loss: QoS Targets That Matter
Mini OLT Software Functions: CPU, Memory and Temperature Monitoring
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
