多载波扇区软件告警协同处理案例:光路闪断与RRU硬件隐患的排查(续篇)

上篇案例小结与拓展处理策略

(1)更换光模块可能解决了最明显的故障点,仍可持续观察该扇区和AAS模块的运行状态。

(2)基础工作中,针对最常见的光路故障点,优先尝试更换光模块、清洁光纤接口等操作,解决大部分显性问题。

(3)拓展处理:若后续再次出现类似软件告警,在不影响业务的前提下,可以尝试将本扇区(如第2扇区)的RRU与相邻扇区(如第1扇区)的RRU进行对调观察,进而定位共扇区下RRU隐患问题。

一、小区告警与初步排查

同一个5G室分站点相隔不到三周,扇区-2再次上软件错误告警,2小区不可用,如下:

经查询,扇区-2状态DISABLED,而RRU状态正常,如下:

扇区-2下挂RRU-3和RRU-4,光路信息正常,如下:

二、站点问题排查

根据上篇拓展处理思路,多载波扇区上软件告警,尚难以定位到RRU-3还是RRU-4,故进行倒换验证,当前5G站点下有两个扇区,分别是扇区-1和扇区-2,并分别下挂RRU-1/2和RRU-3/4。

倒换前

倒换后

20多分钟过后,提取光路信息,发现RRU-3 TX通道无发射信息,而且驻波值偏高,如下:

5G扇区-1上软件错误告警,1小区不可用,现象同原扇区-2,如下:

关闭RRU-3后,1小区可用,如下:

再次激活RRU-3,半小时后扇区-1再次上软件错误告警,如下:

在此期间,扇区-2正常,经倒换的RRU-3,使得扇区-1复现两次软件错误告警,小区不可用,因此故障源头出自RRU-3,已通知代维现场更换。

三、小结

通过RRU交叉倒换法,精准定位了导致小区频繁上报软件错误告警并退服的故障根源为RRU-3硬件故障。

本次排查遵循上次拓展思路,将故障现象复现并转移,结合光路信息检测(如TX无发射、驻波值偏高等),进一步锁定RRU-3发射链路异常问题,而且只要RRU-3是激活态,故障现象就会复现,最终确认故障源头。

相关推荐
wWYy.3 分钟前
Linux发送数据包的过程
linux·网络
小嵌同学8 分钟前
Linux 内核中的 Per-CPU 机制详解
linux·运维·arm开发·嵌入式
云飞云共享云桌面13 分钟前
自动化设备厂 10 人研发团队,如何共用一台服务器做 SolidWorks 建模?
运维·服务器·网络·3d·自动化·制造
筝筝ba32 分钟前
Configure IP Address Via Different User Roles And Verify(1)
服务器
QH1392923188041 分钟前
NVIDIA H200 H300服务器
运维·服务器·开发语言·网络·信息与通信
xixiaoyunya42 分钟前
中小微企业轻量组网方案的技术选型与实践:从传统专线到软定义隧道的成本与效能分析
服务器·php·apache
Hello-FPGA43 分钟前
嵌入式LINUX 设备 ip配置后怎么保存才能掉电不消失?
linux·运维·服务器
奥莱维1 小时前
KNX酒店方案_KNX专用线与高端酒店技术逻辑
java·服务器·前端·数据库
工业一体机老司机1 小时前
Linux工业一体机自启动服务配置:systemd服务单元编写与开机优化实战
java·linux·服务器
zhixingheyi_tian1 小时前
Linux 之 ssh
linux·服务器·ssh