一只 ONU 常发光，整栋楼断网：PON 上行时隙冲突的定位与处置
核心要点：PON 的上行是时分复用的，同一时刻只允许一只 ONU 在自己的时隙里发光。只要有一只 ONU 持续发光，它就会占满本属于其他用户的时隙，让同一个 PON 口下的几十户一起"随机掉线"。这类故障不掉光功率、不报断纤，最容易被误判成 OLT 板卡故障或"线路问题"。本文给出一条可复现的定位路径，以及锁定之后先隔离、再换件的处置顺序。
一、上行是"轮流说话"，不是"一起说话"
很多人把 PON 想成一根"大家共用的水管"，其实下行和上行的机制完全不同。下行方向，OLT 以 2.488 Gbit/s 连续广播，每只 ONU 只取自己该收的帧；上行方向总共只有 1.244 Gbit/s，由 OLT 统一分配时隙，每只 ONU 只在被授权的那个时间窗口里打开激光器，其余时间必须关断。
这就是为什么"常发光"是一个结构性故障，而不是性能下降。一个不按授权时间发光的 ONU，等于会议室里一直喊话的那个人：不是把音量调小，而是让所有人都听不清。其他 ONU 的突发信号与它叠加，OLT 侧的接收判决被破坏，表现就是整口的误码率飙升、测距失败、反复上下线。
顺带澄清一个误解：红光笔一般不干扰上行业务，它只是污染光功率读数；真正会打垮整口的是接了 1310nm 光源的设备——备用 ONU 或光模块被插到了在用分光器上。
二、整口一起掉线，却查不出光衰
常发光 ONU 的现场特征相当固定，认出这套组合，就不必再逐户测光功率。
- 同一个 PON 口下多户同时异常，跨品牌、跨楼层，故障户数随时间变化；
- 掉线是"几秒到几分钟后自己回来"，没有固定周期，但往往集中在晚间业务高峰；
- 到现场测单户光功率，读数居然正常，甚至比对端还好；
- OLT 侧可以看到 CRC 或误码计数上升、ONU 反复测距、注册超时，告警里却很少有"光衰"字样；
- 关键线索：拔掉某一根纤或重启某一台 ONU 之后，整口突然恢复，过几小时或几天又复发。
最后这一条几乎可以定性：光衰不会因为"拔了别人的纤"而恢复。
三、三个来源：硬件坏、软件乱、人为接错
定位到户之后，还要知道它为什么会常发光，否则换上去的新机可能再犯一次。
| 来源 | 典型迹象 | 现场判断方法 |
|---|---|---|
| 激光器或驱动电路损坏 | ONU 曾遭雷击浪涌、进水受潮、供电异常；机壳发热明显 | 断电重启后仍持续发光；换一只同型号即恢复 |
| 固件与状态机异常 | 集中在同一批次或同一固件版本；多发生在升级中断、异常断电之后 | 核对 SN 批次与版本号，同类事件出现两次即按批次处理 |
| 人为与外部注入 | 施工、割接、测试期间突然发生；备用设备被插到在用分光器 | 对齐故障起始时间与施工记录，优先查空闲端口 |
第三类最容易被忽略，也最容易重复。硬规矩是：在用分光器的空闲端口一律戴帽，测试光源与备用 ONU 不得接入在用 ODN。
四、先分清是"常发光"还是"光太弱"
这两种故障的上报说法几乎一样——"我们这栋楼又掉线了"。用下面四行就能分开，不必上仪表。
| 观察项 | 常发光 ONU | 光衰过大 | ONU 电源异常 |
|---|---|---|---|
| 影响范围 | 整个 PON 口多户随机 | 单户或单条分支 | 单户 |
| ONU 收光功率 | 正常甚至偏高 | 明显偏低 | 读不到 |
| OLT 侧误码 | 明显上升 | 轻微或无 | 无 |
| 拔纤测试 | 拔掉某分支即恢复 | 拔纤后仍不通 | 与拔纤无关 |
如果四条都指向第一列，就不要花时间测每户的光功率了——那只会得到一堆"正常"的数字。
五、五步定位：从整口压到单户
- 确认范围。同一 PON 口下三户以上同时异常、跨品牌跨楼层，先按公共段故障处理，不要从"某一户的网线"开始查。
- 取 OLT 侧证据。导出该口的误码计数、测距失败日志、ONU 上下线时间分布。把掉线时间与施工、上电、雷雨记录对齐，往往能直接锁定时间窗。
- 断开馈线做一级判断。拔掉 OLT 到一级分光器的馈纤，看误码是否停止。停止说明干扰源在 ODN 侧；不停止才回头查 OLT 端口与光模块。
- 按分光器分支做二分。两级分光时，先断开一级分光器的某几条输出支路（通常对应楼层或弱电井），一次排除一半户数。误码消失的那一半，就是故障源所在的分支。
- 逐口收敛到户。在目标支路的二级分光器上逐个端口拔纤，直到误码归零，剩下的那只 ONU 就是源头。酒店与公寓尽量在弱电井作业，不进客房。
以常见的两级分光规模计，两人配合大致 60 到 90 分钟可以收敛到户，不含与客户解释的时间。
六、二分法的六个操作细节
- 从靠近 OLT 的一侧先切。一级分光器的输出支路一次能排除的户数最多；营业时段不便进弱电井时，排到错峰窗口，而不是从客房侧一个个试。
- 每拔一根就记一次。时间、端口、误码是否归零，三样都要写下来。回插之后没有记录，整轮工作就白做了。
- 不要用"逐户断电"代替拔纤。常发光的 ONU 断电确实会停，但你不知道是哪台，逐户断电等于把整栋楼扫一遍。
- 拔下的跳纤立即戴帽。裸端面在弱电井里待十分钟，端面污染就够让下一轮测试失真。
- 先恢复非故障分支。锁定源头后，立刻把其他分支插回去，让大部分用户先回来，再单独处理那一户。
七、锁定到户之后：先隔离，再换件，最后追根因
顺序错了，往往会救回一户、拖垮一片。
第一步是隔离，不是换件。把该 ONU 从在用 PON 口摘除——逻辑去激活或物理断开都行——让整口先恢复。这一步的价值是先把几十户的故障停掉。
第二步给客户临时终端。从备件池取一只备用 ONU，现场十分钟换机，比"寄回厂家等返修"的体验好得多。备件不是成本，是把 MTTR 从几天压到一小时的唯一手段。
第三步追根因。翻这只 ONU 的 SN 批次、固件版本、安装时间与供电环境。如果同批次、同版本已经出现第二例，就按批次处理：停发该批次、批量升级或整批更换。
第四步归档，并且做物理标记。在返修单上写清"常发光"，机身上贴红标，与好件分区存放。最常见的事故不是第一次故障，而是这只坏机被当成好件重新装回了网络。
八、预防：把运气变成机制
- OLT 侧：启用设备自带的常发光或异常发光检测，并把误码阈值、测距失败次数做成告警。只看"在线 ONU 数"是不够的——常发光时在线数可能一直是满的。
- 施工侧：在用 ODN 的空闲端口一律戴帽；测试光源不进在用分光器；新旧设备分区存放。
- 备件侧：返修件与好件物理分开，红标制度写进仓库作业规范。
- 值班侧：把"整口随机掉线先怀疑常发光 ONU"写进一线话术，避免上来就换 OLT 板卡、换上联模块。
九、一张现场记录表，比记忆可靠
这类故障常常隔几个月复发一次，靠记忆复盘一定会走样。建议每处理一次就填一行。
| 字段 | 记录内容 |
|---|---|
| 时间与范围 | 发现时间、影响户数、涉及的 PON 口与分光器编号 |
| 证据 | 误码计数变化、测距失败次数、掉线时间分布 |
| 收敛过程 | 拔纤顺序、每次拔纤后的误码变化、锁定到的端口 |
| 故障机信息 | SN、批次、固件版本、安装日期、供电与安装环境 |
| 处置与复发 | 是否换机、是否返修、三个月内是否再次发生 |
同一只 SN 在三个月内出现两次，就该直接报废。判断依据不是"还能不能注册"，而是"它会不会再拖垮整口"。
十、设备侧：PON 口就是故障域
所以设备选型时，端口数量不是越多越好，而要跟建筑体量与运维能力匹配。
- 单栋公寓、小型园区：32 口 vOLT（ZH-vOLT32）一台覆盖一栋，故障域天然被限制在一栋之内。
- 中型酒店（100 至 300 间客房）：64 口 vOLT（ZH-vOLT64），按楼层分配 PON 口，出问题时只影响一层，排查范围也可控。
- 多业务高带宽场景（IPTV 加监控加客控）：XG-PON 万兆平台（ZH-VOLTXG64），上下行余量更大，给突发与误码留出缓冲。
一句提醒：把三百间客房塞进两个 PON 口，等于把风险集中到一个点上。省下的是端口，赌上的是整栋楼的可用性。
结语
常发光 ONU 不是偶发故障，而是共享介质上必然会出现的一类结构性故障。它真正的成本不在设备，而在于"没人知道该往哪儿查"，于是每次都从零开始，把几十户的投诉拖成几天。把它写进值班流程与备件制度，比换一台更贵的 OLT 有效。记住三句话：先判整口，再二分，最后单户；先隔离，再换件；返修件贴红标。
联系我们
如果正在为酒店、公寓或园区排查整口随机掉线的 PON 故障，欢迎与 AINOPOL 讨论。我们可以一起核对 PON 口分配、分光结构与设备批次。
- 邮箱：zhenghui.xu@sczhgx.com
- WhatsApp：+86 17612849559
- 官方商城：shop.sczhgx.com
