An ONU firmware upgrade is not a switch upgrade, because one failed image does not take down one device — it takes down every subscriber behind that image at once. The plan that survives is a version matrix, a small first batch, written pass criteria, and a rollback trigger nobody has to argue about at 3 a.m.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
A switch upgrade affects one box you can reach; a PON-side upgrade affects every terminal on a PON port, and a GPON port can register up to 128 ONUs. Blast radius is the whole difference.
ITU-T G.988 defines software image managed entities so a new image can be loaded into an inactive slot and then activated, which is what makes a controlled activation — rather than a blind overwrite — possible.
Rollback has to be triggered by a threshold, not by a feeling. Write the number down before the window opens: registration failure rate, reboot count, or complaint rate.
Both are "firmware", and almost nothing else is shared.
| Dimension | Switch firmware upgrade | ONU firmware upgrade |
|---|---|---|
| Blast radius | One device, usually locally reachable | Every terminal loaded with that image; a GPON port registers up to 128 ONUs |
| Physical access | You can usually walk to it | The terminals are on customer premises |
| Rollback | Dual image, local console, minutes | Remote, and depends on the terminal being able to accept a re-activation command |
| Failure signature | One device offline | A queue of support calls, all at once |
| Timing constraint | Often a scheduled outage | Must fit a window when subscribers are asleep |
That first row is the one that dictates everything else. On a switch, a failed image is an inconvenience you fix with a console cable. On a PON, the same failure is a service event.
A version matrix is one table: which terminal models, which current image, which target image, and which PON ports carry which combination.
| Combination | Risk | Action |
|---|---|---|
| All terminals on one PON port at the same target version | Lowest | The steady state to aim for |
| Two versions on one PON port, both tested against the OLT release | Acceptable short term | Finish the batch rather than leaving it mixed |
| Two versions where the older one is not qualified with the current OLT release | High | Upgrade or isolate that group before anything else |
| One terminal model with no qualified target image | Blocking | Do not include it in the batch; escalate to the vendor |
| Terminals from more than one vendor on the same port | Highest | Separate by PON port where possible, and test each vendor separately first |
The risk in mixing is not philosophical. Different releases can expose different OMCI managed entity behaviour, and a PON port serving terminals that answer the OLT differently is where intermittent, hard-to-reproduce faults come from.
Roughly 500 subscribers per batch, with the first batch deliberately smaller and deliberately chosen.
| Batch | Size and selection | Window | Observe | Rollback trigger |
|---|---|---|---|---|
| 0 — pilot | 20 to 50 terminals you can reach and that include at least one of every model in the network | Low-traffic window | 24 to 48 hours, with active monitoring | Any registration failure, or more than one unexplained reboot |
| 1 | 5% of the base, chosen to include every OLT port you will touch later | Window 1 | 48 hours | Registration failure rate above the pre-agreed threshold, or complaint rate above baseline |
| 2 | 25% | Window 2 | 48 hours | Same thresholds as batch 1 |
| 3 | Remaining subscribers | Window 3 | 7 days of close monitoring | Same, plus a hold on batch 4 |
| 4 | Catch-up: terminals that were offline during their window | Rolling | Until the matrix shows one version | N/A |
Two rules make this work. Never skip from the pilot to the full base, and never let a batch boundary fall on a Friday — the observation window needs a working day behind it with staff available.
Write them as numbers, because "it looks fine" is not something two engineers will agree on at 3 a.m.
| Indicator | How it is read | Typical stop threshold |
|---|---|---|
| Registration failures | Count of terminals that fail to re-register after activation | Any increase over the pre-upgrade baseline in the pilot; a set percentage thereafter |
| Unexpected reboots | Reboot counters or uptime resets on activated terminals | More than one per hundred activated terminals in the observation window |
| Support contact rate | Calls per thousand subscribers compared with the pre-upgrade week | A material rise over baseline, agreed in advance |
| Optical performance | Received power and error counters for activated terminals | No degradation attributable to the new image |
| Service-specific checks | A voice call, a video stream, a speed test on sampled lines | All sampled services pass |
Rollback itself needs the same discipline: know in advance whether the platform supports re-activating the previous image remotely, and if it does not, know how many technicians you would need and how long that would take. Discovering that during the incident is the failure mode this plan exists to prevent.
Three situations justify cancelling a planned window.
| Situation | Why not | What to do instead |
|---|---|---|
| The release fixes nothing that affects your network | Every upgrade carries risk; an unnecessary one carries risk with no benefit | Defer, and document why |
| A peak event is imminent — holiday period, major local event, billing cycle | The observation window will be unrepresentative and the impact larger | Move the window |
| Your spare and support cover is not in place | Rollback needs people and hardware | Fix the cover first, then reschedule |
"Because the version is old" is not a reason on its own. A terminal running a stable image with no known exposure is a lower-risk state than one mid-migration.
| Service | Roughly how long before it is noticed (industry-typical) | Comment |
|---|---|---|
| Broadband browsing | A minute or two of interruption is tolerated if it is one-off | Repeated interruptions generate calls |
| Voice over IP | Seconds; a call drop is noticed immediately | Schedule voice-heavy lines outside daytime |
| Live video streaming | Seconds; buffering is visible | Streaming peaks in the evening |
| Business or monitored circuits | Immediately, with contractual consequences | Give these their own window and notice |
The standard approach is a window in the small hours, advance notice, and a statement of what the subscriber should do if the service does not return: power cycle once, wait a stated number of minutes, then call.
How large should the first batch be?
Small enough to be observable and large enough to be representative: 5% of the base is a common figure, and the selection matters more than the size because it must include every terminal model and every OLT port you plan to touch later.
How long should the observation window be?
Long enough to cover a full daily usage cycle. 24 to 48 hours after the pilot and 48 hours after each subsequent batch is a typical pattern, with a longer monitoring tail after the final batch.
Can a failed ONU upgrade be rolled back remotely?
It depends on the platform and on the terminal being able to accept a re-activation command. ITU-T G.988 defines software image managed entities that support loading an inactive image before activation, but whether the platform exposes remote re-activation has to be confirmed before the window, not during it.
Is it safe to leave two versions running on one PON port?
Short term, and only if both are qualified against the OLT release you are running. Long term it is a source of inconsistent behaviour, so finish the batch rather than settling into a mixed state.
What is the single most common cause of a bad upgrade window?
Skipping the pilot, or running the pilot on terminals that do not represent the network. A pilot that only covers one model tells you nothing about the other three.
PON-side upgrades fail on blast radius, not on technology: version matrix, small representative pilot, numeric pass criteria, and a rollback path you have already tested. For a small operator running a mini GPON OLT, the same four steps apply at a smaller scale, and the discipline matters just as much because the subscriber count behind one port is still 128 at most, not one.
OLT Management in Practice: CLI, Web and SNMP for the Central Office
Bulk Provisioning on an OLT: Line Profile and Service Templates
ONU Authentication: How an OLT Decides Which Devices to Trust
GPON Network Inspection Checklist: Five Steps Before a Fault Happens
The management-channel and protocol statements above come from public industry sources — ITU-T G.984.4 and ITU-T G.988 (the ONT management and control interface, including the software image managed entities used to load and activate an image) and the GPON transmission rates defined in the ITU-T G.984 series. Statements about what a platform can do are deliberately general, because capabilities differ between releases; confirm them against your own release notes. The method, worked examples and wording are written by Sara, who checked each figure against those sources before publication. Anything presented as an industry-typical value is labelled as such; nothing here is a measured figure from a Rayin product unless it says so.
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
