华为4G/5G故障处理：113个真实案例教你快速定位

简介《华为4G5G故障分析处理及典型案例》PPT课件是一份面向网络优化工程师、基站维护人员及通信项目管理者的故障处理参考材料。内容基于华为与省公司合作的真实维护实践系统整理了自2020年9月以来收集的113篇4G/5G故障案例并聚焦小区故障、时钟类故障、小区服务能力下降三大高频问题给出定位与排除思路。课件明确归纳了备份数据、收集信息、确定范围、定位原因、排除故障、确认结果、联系支持七步处理流程并通过LNR共主控站点升级后小区不可用的典型案例演示了从现象检查到命令操作的完整排障路径。资源包为单份PPT文件共1个文件、大小5.67MB内容紧凑、逻辑清晰既可用于团队内部技术培训也可作为日常维护的速查手册。目前已有239人浏览学习适合需要提升4G/5G故障响应效率与处理能力的网络优化从业人员。1. 华为4G/5G故障分析处理113个真实案例能让你少走多少弯路干通信维护的都知道故障处理最怕的不是故障本身而是定位过程像无头苍蝇。我从省公司维护科拿到这份华为4G5G故障分析处理及典型案例PPT时第一反应是终于有本可以照着抄作业的案例库了。它汇总了从2020年9月开始收集的113篇日常维护故障案例覆盖4G、5G和网管其中TOP3高发类型是小区故障、时钟类故障和小区服务能力下降。这份资源不是教科书式的原理讲解而是把一线遇到的真实现象、定位步骤和解决命令整理成册适合刚接手基站维护的新人也适合每天跟告警打交道的网优和工程人员。我拆完这份材料后最大的感受是很多故障翻车都栽在配置细节和物理链路这种小事上而案例库恰好把这些坑提前标出来了。2. 故障处理七步法为什么先备份再查日志是铁律2.1 七步处理流程里最容易跳过的是第1步华为给出的故障处理总体思路分了七步备份数据、故障信息收集、确定故障范围和类别、定位故障原因、排除故障、确认故障是否排除、联系华为技术支持。顺序看着平淡但实际操作里很多维护人员一上来就急着定位原因跳过备份结果操作失误或者状态回退不了把简单故障搞成重大事故。我一般拿到工单后会强制自己走一遍先看一眼备份时间戳确认数据库、告警信息、日志文件都有一份。尤其是涉及基带板下电、主控复位、版本升级这类危险操作备份就是后悔药。比如案例里用OPR BRDPWR下电主控板这种操作一旦把业务板下错了没有配置备份恢复就要花半天。所以七步法的第1步不是形式主义是保住饭碗的底线。2.2 故障信息收集具体要收什么信息收集不是简单地截个图而是要尽量收集五类信息告警的名称和定位参数、问题出现的时间点和频率、站点拓扑和版本信息、最近做过哪些变更操作、现场物理环境状态。PPT里每个案例的【问题描述】只有一两句话但背后隐含的信息收集清单非常明确。比如时钟类故障案例里GPS无法搜星维护人员先查了GPS搜星状态、卫星数为0、有时钟参考源异常告警然后又排查了安装环境、更换GPS和主控板最后才用频谱仪定位到干扰源。如果一开始不收集干扰排查所需的周边环境信息很可能盲目换硬件。我的做法是建立一张故障信息收集表按网络层、物理层、配置层三行记录确保不漏项。2.3 用命令核对配置时的关键参数案例里大量使用MML命令做配置核查有几个命令值得单独记住STR CFGCHK LST OPTLOG LST GNODEBFUNCTION DSP GNBCUNGINTERFACESTR CFGCHK用于启动配置核查会生成结果文件比如案例中提到的000060.XML。LST OPTLOG用于查询最近一次基站上传日志的服务器IP这能帮你判断上传的校验文件去了哪台服务器。LST GNODEBFUNCTION是查gNodeB标识用于排查NG接口故障。DSP GNBCUNGINTERFACE查Ng接口状态。这些命令的共同点是先用一条命令缩小范围再打开对应的结果文件精确定位。我踩过的坑是只看命令输出摘要不看XML里的dbvalue和appvalue差异导致配置不一致问题反复出现。案例里专门提到速率和双工模式的数据库值与应用值不一致时要重新配置ETHPORT为千兆全双工并复位基站才能恢复。3. 高发故障类型拆解小区故障、时钟类、配置数据不一致3.1 小区故障先看物理资源再看License小区故障是案例数量最多的类型告警解释里明确说小区状态与基带资源、射频资源、CPRI资源、时钟资源和传输资源有关License不足也会导致小区不可用。处理顺序应该是先查物理资源状态再查配置和License不要一上来就复位基站。最典型的案例是LNR共主控站点版本升级后小区不可用所有AAU不在位所有基带板无法启动。处理步骤先是检查设备面板发现6槽多配了一块主控板。这个站点是4G/5G共主控本来只能配置7槽一块主控板6槽主控没有业务却占用资源导致7槽业务板起不来。解决办法是对6槽主控下电OPR BRDPWR:SN6,SWOFF,FOCPWROFFYES;下电后观察15分钟左右单板状态正常4G/5G业务恢复。这里有个硬规则同一个机框内同一制式不能承载在不同主控板上。以后遇到共主控站点业务异常先查是否有多余的主控板占资源。另一个案例是5G站点AAU替换后小区基带资源生效失败。原因是3DMIMO和5G共框、且5G已开通4G未开通的情况下AAU5619替换成AAU5636后出现控制权冲突。排查发现NR侧控制权未知AAU版本低于NR主控版本时无法自动升级因为NR无控制权。最终解决方法是NR侧下电4G主控单板再复位本端5G主控单板。这个案例说明共框分离主控场景里默认高制式有控制权但异常情况下会被低制式抢占遇到小区建立失败不要只盯着无线侧控制权归属也是关键。3.2 XY共板混配小区天线模式冲突的规格边界亳州一个站点扩容A频段小区失败原因为基带板小区天线模式冲突。处理过程很有代表性先查询小区绑定发现1小区是多RRU共小区2槽基带板型号为UBBPd91小区配置2T2R2/3/4/8小区配置8T8R形成了XY共板混配场景。扩容前X3Y2XY5满足UBBPd9共板混配规格扩容1个8T8R小区后X4不满足规格所以小区起不来。这个案例的价值在于给了一个明确结论通道数不同的RRU尽量不要绑在同一块基带板上XY共板混配最大支持2种通道。实际扩容前一定要先算清楚XY的数量是否超过基带板规格。我建议把每种基带板支持的最大物理小区数和通道组合做成表格扩容前先查表而不是等告警了再临时加板。3.3 时钟类故障外部干扰和帧偏是隐蔽杀手时钟类故障排在案例类型第二名典型的告警有时钟参考源异常、IP时钟链路异常、GNSS星卡天线故障、GNSS星卡锁星不足。案例1是GPS干扰器导致集中机房周围8个站点GPS无法搜星。排查过程很经典GPS搜星数为0、有时钟参考源异常告警周边空旷无遮挡更换GPS和主控板问题依旧最后用频谱仪中心频率1580MHz、带宽20MHz扫描在垃圾运输车内发现-70dBm的干扰信号。原因是司机为了躲避公司GPS超速监控在车内装了GPS干扰器。这个案例提示我们GPS外部干扰已成为时钟问题主要原因之一硬件无问题时要及时排查干扰。做时钟故障处理排查顺序最好是搜星状态→天馈安装环境→硬件替换→频谱仪扫干扰不要一上来就换板子。案例2是扩容小区帧偏配置异常导致时钟失步。宿州某站点出现基站时钟失步告警但小区状态全部正常GPS搜星正常。查小区频点配置发现8小区是F频段其他小区是E频段而帧偏配置里E频段配置了277560Ts8小区没有配置。生效帧偏查询显示所有小区均为277560Ts添加8小区TL双模2_5帧偏后故障恢复。这个案例提醒我们扩容小区或新开站时帧偏必须与大网保持一致否则会出现严重干扰或时钟故障告警。实际操作中帧偏不一致导致的干扰非常隐蔽网管上不一定立刻报出来往往要等到用户投诉速率低才发现。3.4 配置数据不一致STR CFGCHK定位鸳鸯线的思路配置数据不一致告警有两个来源一是配置数据生效时运行数据与用户配置不一致二是RRU链/环组网结构与实际不一致。滁州高铁站点的案例展示了标准排查流程STR CFGCHK启动配置核查结果为不一致文件为000060.XML再用LST OPTLOG查到上次上传日志的服务器IP把XML传到服务器临时目录后检查发现速率和双工模式dbvalue与appvalue不一致重新配置ETHPORT为千兆全双工后复位基站恢复。另一个更典型的案例是45G共主控站点上报RRU组网拓扑类型与配置不一致。告警定位信息显示链环尾配置异常用户配置的射频接口板槽位2端口2实际使用的槽位2端口1初步怀疑鸳鸯线。通过下电AAU验证收光再闭塞CPRI端口确认BBU侧发光问题最后工程队上站发现BBU侧1/2口发光接收纤芯存在鸳鸯情况整改后恢复。这里的关键命令是BLK CPRIPORT:CN0,SRN0,SN2,OPTN1; BLK CPRIPORT:CN0,SRN0,SN2,OPTN2;闭塞光口后观察AAU设备CPRI断链情况能快速判断光路对应关系。5G C-RAN站点占比高光路鸳鸯问题一定要重视尤其在验收阶段就该做完整的收发光测试而不是等告警了再排查。3.5 小区服务能力下降SFN物理小区数与实际不符小区服务能力下降告警常见于射频资源、基带资源、跨板链路资源不满足配置规格或CA业务配置异常。合肥一个高铁FDD1800站点上报该告警定位信息为通道异常。处理流程是DSP CELLPHYTOPO查RRU工作状态正常LST EUCELLSECTOREQM查小区绑定物理小区为5个LST CELL核查SFN小区物理小区数量配置为6与实际不符。修改命令MOD CELL:LOCALCELLID3,MULTIRRUCELLFLAGBOOLEAN_TRUE,MULTIRRUCELLMODESFN,CPRIETHCOMPRESSIONRATIO2_TO_1,SECTOREQMNUM5;改完配置后告警消除。这个案例的核心教训是FDD小区合并后必须及时更新SFN小区物理小区数量TDD不涉及此参数。很多维护人员只改小区合并状态忘记同步物理小区数量导致告警一直挂在网上。3.6 S1/NG/X2/XN链路故障先ping通再查标识接口故障告警的根源可能是SCTP链路故障、协议层配置错误、对端合法性检查不通过。合肥某SA站点小区故障原因是Ng不可用。处理步骤很标准查Ng接口状态显示底层链路故障用业务IP ping核心网4套AMF都通检查EPGROUP ID、跟踪区域标识正确最后下载NR网元报表发现gNodeB标识与另一个站点冲突。这里值得学习的是顺序先验证IP连通性再查协议配置最后查网元标识。很多人一看到底层链路故障就去查传输但实际上业务IP能ping通就说明传输没问题问题在高层。最终修改gNodeB标识后复位基站恢复。退网站点要及时清理冗余的gNodeB标识否则新站复用同一个标识就会产生冲突。4. 华为4G/5G故障排查避坑指南翻车率最高的5个实操细节4.1 盲目复位主控板反而造成业务中断现象站点出现小区不可用告警维护人员直接复位主控板结果不仅告警没消除业务中断时间还延长了。原因很多告警的根本原因在配置或物理链路上复位主控板只是让设备重启并没有修复问题如果是共主控场景复位还可能触发控制权抢占有风险。解决严格按照七步法先收集告警定位信息、查配置核查结果再决定是否需要复位。只有确认主控板死机或版本加载失败时才复位而且复位前要备份数据。4.2 更换电调天线后忘记重新绑定序列号现象宿州某站点更换电调天线后上报天线设备维护链路异常告警查询小区状态却正常。原因新电调的序列号和旧的不一致但配置里绑定的还是旧序列号。电调天线的子单元ID没有同步更新导致维护链路建立失败。解决更换电调后必须执行SCN ALD重新扫描然后用扫描到的新序列号重新绑定。我现在的习惯是凡是涉及电调天线更换的工单都会在备注里强制写上已重新扫描并绑定序列号避免被下一个维护人员当成漏配。4.3 忽略告警门限把正常电流误报成欠流现象黄山部分站点配置电调天线后反复出现射频单元ALD电流异常告警告警定位信息中的电流为36~39mA。原因当前欠流告警门限是默认的40mA但实际电调天线工作电流只有35mA这本身是正常的。各天线厂家的电流告警门限不一样不能全用华为默认值。解决联系天线厂家获取准确的欠流告警门限然后用MOD RETPORT修改门限。这个案例的教训是告警门限不是永远不变的加电调天线前必须向天线厂家要门限参数否则会制造大量无效工单。4.4 1588v2协议类型不一致相位偏差显示NULL现象黄山某站点频繁上报IP时钟不可用告警网管查询相位偏差值为NULL。原因基站发送Delay_Req后收到大量Resp正常应该1个Req对应1个Resp。核对发现基站侧配置的是Two step协议而传输侧配置的是One step协议类型不一致导致报文拥塞。解决把传输配置协议改为One Step后故障恢复。遇到相位偏差为NULL优先排查协议类型是否一致其次才是调整1588v2报文发送频率。4.5 帧偏配置漏配时钟失步还查不出原因现象宿州某站点基站时钟失步告警但小区状态、时钟源参考状态、GPS搜星全部正常。原因扩容的F频段小区没有配置帧偏而其他E频段小区配置了277560Ts生效帧偏显示所有小区均按277560Ts运行F频段小区帧偏与大网不一致。解决添加F频段小区的TL双模2_5帧偏后恢复。这个坑很隐蔽因为现有小区状态都正常时钟参考也正常只差一个帧偏参数。现在每次扩容后我都会用一条命令批量对比同站或邻站的帧偏配置确保新开小区与现网一致。5. 把113个案例变成你自己的快速定位手册别人整理好的案例库直接看一遍印象不深真正有价值的是把它们转成能在网管上快速执行的检查序列。我的做法是把PPT里每个案例的处理步骤抽象成故障现象→排查命令→定位参数→解决命令四列的表格然后按故障类型归类。比如小区故障我在手册里写先查单板状态DSP BRD、再查小区绑定LST CELL、查基带板型号和共板混配规格、最后查License占用。时钟类故障先查搜星数DSP GPS、查帧偏配置LST TADV或者LST CELLFRAME、查1588v2协议类型。配置数据不一致直接跑STR CFGCHK然后看上传到服务器的XML文件。电调天线类先查RET端口配置和电流门限再查ALD扫描序列号。链路故障按ping IP→查EPGROUP→查gNodeB标识的顺序来。这样做的好处是遇到新故障时不用从零开始先对照手册把最常见的三个原因排除掉剩下的小概率原因再考虑联系华为技术支持。我自己吃过一次亏有个站点反复上报GPS锁星不足我按手册查了天线、查了星卡、查了主控都没问题最后才发现是附近工地新装了带GPS干扰的塔吊。从那以后我在时钟类排查手册里加了一条现场电磁环境确认每次遇到GPS类告警都强制走一遍频谱扫描。这份113个案例的PPT能帮你把同样的问题变成条件反射希望帮到你。本文还有配套的精品资源点击获取