企业官网建设流程全解析

简介：《华为4G&5G故障分析处理及典型案例》PPT课件，是一份面向网络优化工程师、基站维护人员及通信项目管理者的故障处理参考材料。内容基于华为与省公司合作的真实维护实践，系统整理了自2020年9月以来收集的113篇4G/5G故障案例，并聚焦小区故障、时钟类故障、小区服务能力下降三大高频问题，给出定位与排除思路。课件明确归纳了备份数据、收集信息、确定范围、定位原因、排除故障、确认结果、联系支持七步处理流程，并通过LNR共主控站点升级后小区不可用的典型案例，演示了从现象检查到命令操作的完整排障路径。资源包为单份PPT文件，共1个文件、大小5.67MB，内容紧凑、逻辑清晰，既可用于团队内部技术培训，也可作为日常维护的速查手册。目前已有239人浏览学习，适合需要提升4G/5G故障响应效率与处理能力的网络优化从业人员。

1. 华为4G/5G故障分析处理：113个真实案例能让你少走多少弯路

干通信维护的都知道，故障处理最怕的不是故障本身，而是定位过程像无头苍蝇。我从省公司维护科拿到这份华为4G&5G故障分析处理及典型案例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 GNBCUNGINTERFACE

STR 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:SN=6,SW=OFF,FOCPWROFF=YES;

下电后观察15分钟左右，单板状态正常，4G/5G业务恢复。这里有个硬规则：同一个机框内同一制式不能承载在不同主控板上。以后遇到共主控站点业务异常，先查是否有多余的主控板占资源。

另一个案例是5G站点AAU替换后小区基带资源生效失败。原因是3DMIMO和5G共框、且5G已开通4G未开通的情况下，AAU5619替换成AAU5636后出现控制权冲突。排查发现NR侧控制权未知，AAU版本低于NR主控版本时无法自动升级，因为NR无控制权。最终解决方法是NR侧下电4G主控单板，再复位本端5G主控单板。这个案例说明共框分离主控场景里默认高制式有控制权，但异常情况下会被低制式抢占，遇到小区建立失败不要只盯着无线侧，控制权归属也是关键。

3.2 X+Y共板混配：小区天线模式冲突的规格边界

亳州一个站点扩容A频段小区失败，原因为"基带板小区天线模式冲突"。处理过程很有代表性：先查询小区绑定，发现1小区是多RRU共小区，2槽基带板型号为UBBPd9，1小区配置2T2R，2/3/4/8小区配置8T8R，形成了X+Y共板混配场景。扩容前X=3，Y=2，X+Y=5满足UBBPd9共板混配规格；扩容1个8T8R小区后X=4，不满足规格，所以小区起不来。

这个案例的价值在于给了一个明确结论：通道数不同的RRU尽量不要绑在同一块基带板上，X+Y共板混配最大支持2种通道。实际扩容前，一定要先算清楚X+Y的数量是否超过基带板规格。我建议把每种基带板支持的最大物理小区数和通道组合做成表格，扩容前先查表，而不是等告警了再临时加板。

3.3 时钟类故障：外部干扰和帧偏是隐蔽杀手

时钟类故障排在案例类型第二名，典型的告警有时钟参考源异常、IP时钟链路异常、GNSS星卡天线故障、GNSS星卡锁星不足。案例1是GPS干扰器导致集中机房周围8个站点GPS无法搜星。排查过程很经典：GPS搜星数为0、有时钟参考源异常告警，周边空旷无遮挡，更换GPS和主控板问题依旧，最后用频谱仪中心频率1580MHz、带宽20MHz扫描，在垃圾运输车内发现-70dBm的干扰信号。原因是司机为了躲避公司GPS超速监控，在车内装了GPS干扰器。

这个案例提示我们，GPS外部干扰已成为时钟问题主要原因之一，硬件无问题时要及时排查干扰。做时钟故障处理，排查顺序最好是：搜星状态→天馈安装环境→硬件替换→频谱仪扫干扰，不要一上来就换板子。

案例2是扩容小区帧偏配置异常导致时钟失步。宿州某站点出现基站时钟失步告警，但小区状态全部正常，GPS搜星正常。查小区频点配置发现8小区是F频段，其他小区是E频段，而帧偏配置里E频段配置了277560Ts，8小区没有配置。生效帧偏查询显示所有小区均为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:CN=0,SRN=0,SN=2,OPTN=1; BLK CPRIPORT:CN=0,SRN=0,SN=2,OPTN=2;

闭塞光口后观察AAU设备CPRI断链情况，能快速判断光路对应关系。5G C-RAN站点占比高，光路鸳鸯问题一定要重视，尤其在验收阶段就该做完整的收发光测试，而不是等告警了再排查。

3.5 小区服务能力下降：SFN物理小区数与实际不符

小区服务能力下降告警常见于射频资源、基带资源、跨板链路资源不满足配置规格或CA业务配置异常。合肥一个高铁FDD1800站点上报该告警，定位信息为通道异常。处理流程是：DSP CELLPHYTOPO查RRU工作状态正常；LST EUCELLSECTOREQM查小区绑定物理小区为5个；LST CELL核查SFN小区物理小区数量配置为6，与实际不符。修改命令：

MOD CELL:LOCALCELLID=3,MULTIRRUCELLFLAG=BOOLEAN_TRUE,MULTIRRUCELLMODE=SFN,CPRIETHCOMPRESSIONRATIO=2_TO_1,SECTOREQMNUM=5;

改完配置后告警消除。这个案例的核心教训是：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能帮你把同样的问题变成条件反射，希望帮到你。

本文还有配套的精品资源，点击获取