企业官网建设流程全解析

简介：华为4G&5G故障分析处理及典型案例课件，面向网络优化工程师、基站维护人员及通信专业学习者，系统梳理了4G/5G网络日常维护中的常见故障与处理思路。内容基于华为与省级运营公司合作整理的113篇实际案例，重点解析小区故障、时钟类故障、小区服务能力下降三大高频问题，并结合典型场景展示排障过程，如LNR共主控站点版本升级后小区不可用、基带板无法启动时，通过核查主控板槽位配置并下电冗余单板恢复业务的完整操作。同时给出备份数据、收集信息、确定范围、定位原因、排除故障、验证结果、联系支持的七步标准化流程，帮助维护人员建立清晰排障框架。资源为单个PPTX演示文稿，约5.67MB，共1个文件，适合直接用于班组培训、故障复盘或个人自学。该资源已有239人次学习浏览，可作为网络优化实战参考。

1. 华为4G&5G故障分析处理的起点：别急着动参数

华为4G&5G故障分析处理，很多时候不是从告警开始的，而是从群里一条“谁改过参数”开始的。周一早上，某地市网优后台看到LTE接通率掉了2个百分点，华为U2020上一排小区亮起“小区不可用”和“上行干扰”告警。4G和5G的故障分析处理，从来不是从某个counter或信令截图开始的，而是从把“现象”翻译成“可能的失败域”开始的。这个标题里的PPT，说白了就是把一套可复用的定位框架装进了文档。这里不重复那些写在培训胶片里的定义，而是按一线网优和后台维护最常见的做法，把华为4G&5G故障分类、MML定位命令、参数边界和几个踩过的坑串起来，给新手一条能走通的路，也让熟手回头check一下自己的排查顺序。

2. 华为4G&5G故障分类与信令定位方法

2.1 先把故障按“物理—传输—接入—干扰—参数”切成五块

4G和5G共用一套无线接入逻辑，差异主要在接口和流程。华为的eNodeB和gNodeB告警虽然命名不同，但故障域可以统一划分为：物理层（站点断电、光模块劣化、RRU/AAU驻波比高）、传输层（S1/X2/N2/N3链路闪断、SCTP偶联抖动、时延丢包）、无线接入层（RRC建立失败、随机接入失败、RLC重传高）、干扰类（上行PRB干扰带高、下行邻区同频干扰）、参数算法类（邻区漏配、定时器不合理、负荷均衡策略错误）。这五块不是并列关系：物理层异常会表现为传输或无线层指标恶化，所以排查顺序一般先看硬件侧，再看传输和信令。

故障分类的目的不是给事件贴标签，而是决定先跑哪一条命令。小区不可用优先查传输和基带资源；CQI掉坑优先查覆盖和干扰；切换成功率低优先查邻区和X2。把问题的“第一现场”定准，后面才会快。我在处理华为4G&5G故障时，习惯先在脑子里过一遍“这个现象如果断网三天，最可能卡在哪个环节”，再决定动哪个方向的MML命令。

2.2 信令跟踪：用RRC和NGAP把“用户失败”翻译成“网络原因”

华为网管上的信令跟踪一般分为小区级跟踪、用户级跟踪和接口消息跟踪。出现批量用户掉线或接通失败时，优先做小区级RRC跟踪，过滤s1ap、ngap和rrcConnectionSetup等消息类型。4G看S1口和X2口，5G看NG口和Xn口；如果是NSA组网，还要同时挂锚点4G小区的信令，因为不少5G失败实际发生在4G侧。

跟踪时长控制在5到10分钟，抓到一定数量的失败样本后停止。重点看三个点：随机接入响应有没有回、RRC重配置完成消息有没有回来、上下文释放的原因值是什么。比如RRC连接建立失败，多数情况是上行干扰或RACH资源不足；RRC重配置失败，则要看失败消息里携带的cause，常见是RadioNetwork: reportProbe或RadioNetwork: normalRelease，前者对应覆盖空洞，后者则可能是参数变更被UE拒绝。这两种原因的处理路径完全不同，不能只对着失败率数值调参数。

2.3 MML命令把网管上的信息拉齐

在华为U2020或iManager维护台上，最常用的是下面几条MML命令，建议把这组命令串成一个检查脚本，每次开故障会的直接贴上去：

// 1. 查看所有小区的运行状态和业务状态 DSP CELL; // 2. 查看某个小区最近3天的告警历史 LST ALMLOG: ALMTYPE=ALL, STARTTIME="2025-01-01 00:00:00", ENDTIME="2025-01-03 23:59:59"; // 3. 查看小区上行干扰统计（PRB级） DSP CELLULINTERF: LOCALCELLID=0; // 4. 查看SCTP偶联状态（4G与核心网、5G与AMF都依赖它） DSP SCTP; // 5. 查看小区信道状态和用户数 DSP CELLSTAT: LOCALCELLID=0;

这组命令有三个共同点。第一，DSP类命令只读不下发，可以放心执行；第二，LOCALCELLID不是“第几个扇区”，它是eNodeB/gNodeB内部的小区编号，和CellID有映射关系，拿不准时先执行LST CELL确认；第三，STARTTIME/ENDTIME一次只查3天，时间跨度太大会拖死网管。在5G侧，同样的命令可以用DSP NRCELL、DSP NRCELLULINTERF代替，参数结构基本一致，但小区对象名称会带NR前缀，防止和4G小区混淆。

2.4 一张表把故障现象映射到定位命令

这张表的用法不是逐条比对，而是与告警和KPI一起看。比如上行干扰高同时存在小区不可用，那先解决不可用，因为干扰次数可能是小区重建后大量用户接入引发的临时拥塞。同一张表在不同版本网管上命令名会有差异，但“先看状态、再看告警、最后看信令”的顺序不变。

3. 华为4G&5G故障分析处理中的无线侧典型案例

3.1 小区被闭塞的快速恢复操作

小区不可用分两类：维护态闭塞和故障态闭塞。维护态是人为执行了BLK CELL，故障态则是基站检测到SCTP断链、RRU失联或License失效自动闭塞。用DSP CELL看到状态为BLOCKED时，先别急着UBL CELL，要分清原因。如果是传输闪断导致的闭塞，直接解闭通常能恢复；如果是RRU光模块异常，解闭后几分钟又会复发，反而会给投诉处理留下“你们根本没有修复”的话柄。

常见的操作序列是：先DSP ETHPORT看光模块收发光功率，再LST SCTP看偶联状态，确认传输侧没问题后再UBL CELL。解闭塞的MML命令：

// 解除指定小区的闭塞状态 UBL CELL: LOCALCELLID=0; // 查看解闭后的小区状态，是否进入Normal DSP CELL: LOCALCELLID=0;

解闭后要观察至少10分钟，分两个维度看：小区是否再次闪断、用户接入是否恢复正常。如果解闭后很快又闭塞，且没有新告警，常见原因是基带单板CPU高负荷或SCTP链路存在周期性异常。这种情况下要检查传输侧的路由配置，不要反复操作UBL CELL，因为每次解闭都会触发小区重建，反而加剧负荷。

3.2 上行干扰的排查与算法开关

上行干扰是4G和5G后台最常见的“用户投诉型”故障，典型现象是RRC连接成功率正常，但上行丢包率高、VoLTE语音断续。在华为设备上，先看干扰带分布：DSP CELLULINTERF会把PRB分13个等级上报干扰值，等级0最低，等级12最高。如果小区全带宽干扰都在等级12，大概率是外部干扰源；如果只在特定频段，则可能是系统内邻区干扰或射频器件杂散。

// 查看小区各PRB的上行干扰功率 DSP CELLULINTERF: LOCALCELLID=0, ULINFERTHRD=12;

ULINFERTHRD是显示干扰阈值的参数，单位是dBm，只影响显示不过滤数据。排查外部干扰时，配合DSP RRU看天线端口驻波比，排除馈线接头进水或天线驻波告警。如果驻波正常，再调用网管的干扰检测算法，生成PRB级实时曲线，判断干扰是持续还是周期出现。内部干扰源在排除外部源后才考虑，常见的是RRU的TDD收发切换时序异常或基带板件性能劣化。

对算法参数的调整，常见做法是在MOD CELL中打开上行干扰抑制开关，并调整干扰检测阈值。注意：这个开关的作用是让基站调度时避开干扰PRB，用容量换质量。在干扰源确认前不要打开，否则KPI会被压得更差，还会被核心网判定为“小区覆盖质量差”。

3.3 切换失败的邻区核查和参数边界

切换失败里最能体现“参数背锅”的案例是邻区Offset设置不合理。典型的错误是把小区个性偏移CIO当成“调这个可以让切换更容易”，实际调大了反而会导致A3事件过早触发，UE切入目标小区后信号快速变差，产生大量切换失败和无线链路失败。这种问题在华为4G&5G故障分析处理中排查优先级很高，因为用户感知表现为“信号满格但打电话断断续续”。

查看和修改邻区参数的命令：

// 查看本小区与邻区的切换关系参数 LST EUTRANINTRAFREQNBR: LOCALCELLID=0, NBRCELLID=100; // 修正邻区的A3偏置和小区个性偏移 MOD EUTRANINTRAFREQNBR: LOCALCELLID=0, NBRCELLID=100, A3OFFSET=2, CELLINDIVIDUALOFFSET=0;

这里A3OFFSET是事件触发偏置，CELLINDIVIDUALOFFSET是单小区偏移。华为网管中这两个参数的单位都是dB，取值范围一般是-15到15。注意A3OFFSET的公共部分会影响所有邻区，CELLINDIVIDUALOFFSET只影响指定小区，所以排查时先看后者。一个可复用的经验：如果切换失败集中在某个邻区，先把CIO改为0，保留A3OFFSET默认值，观察一小时后看切换成功率曲线，再决定下一步。

3.4 调整前后必须收集的5个值

在每次做无线参数调整之前，先拉一组基线数据，否则无法证明参数改动是否有效。这5个值缺一不可：当前小区的接通率、切换成功率、上行PRB干扰带均值、每用户平均吞吐率、以及故障开始的确切时间点。调整后至少观察一个完整忙时，再对比这组数值。很多时候改完参数指标没变，是因为问题根因根本不是参数，而是某个RRU隐性故障或X2链路闪断。

这张表是给后台同事看的，不是为了应付汇报。参数调整类故障最怕“今天调一个、明天调一个”，最后说不清是哪个动作生效。把基线、动作、结果三列固定下来，复盘时直接对着表格指认问题点。

4. 5G故障分析处理：T304定时器、波束恢复与邻区案例

4.1 T304定时器调不好，5G切换就半途而废

5G切换流程里有一个容易忽略的定时器T304，从UE收到RRC重配置消息（包含同步重配）开始计时，直到UE在目标小区完成随机接入并反馈RRC重配置完成。T304超时意味着切换失败，UE会回到源小区发起RRC重建。华为的gNodeB上这个定时器以毫秒为单位配置，默认值常见为1000ms到2000ms，不同版本默认值有差异。

为什么T304超时会成为“5G全网排障”里的高频项？因为5G使用高频段，UE在切换过程中如果波束方向没对准目标小区，或者目标小区随机接入资源紧张，随机接入过程会重传多次，消耗掉整个T304窗口。处理时先看失败信令时标：从RRC重配置下发到收到RRC重配置完成的时间，如果普遍接近定时器上限，就把定时器往大调；如果远小于上限，调定时器没用，应该查目标小区随机接入参数。

// 查看5G小区切换相关定时器参数 LST NRCELL: LOCALCELLID=0; // 修改T304定时器，常见范围内调到2000ms MOD NRCELLSWITCH: LOCALCELLID=0, T304TIMER=2000;

注意：T304不是越大越好。调得越大，切换成功率的表面数值确实会好看，但UE在目标小区无线环境差时会被“硬拉”在失败链路上，反而增加掉线。一般建议从默认值往上加500ms到1000ms，并配合目标小区的RACH参数一起调。参数名以现网版本为准，我在不同系列网管上见过T304Timer、t304、hopt304等写法，定位时先搜“T304”关键字，不要只记一个命令。

4.2 波束故障恢复：5G比4G更容易踩的坑

5G基站的覆盖和调度与波束强相关，波束故障恢复BFR是UE在检测到当前波束质量变差后主动发起恢复的机制。当BFR被频繁触发，表现为大量RRC重建和下行丢包。排查时先看AAU的驻波告警，再看波束配置表和物理小区标识PCI规划，特别留意同频邻区PCI是否冲突。

一个常见的错误是：为了提升覆盖把波束宽度调小，却没有同步调整波束扫描周期。波束扫描周期变长后，UE在切换或波束恢复时会延迟收到同步信号块，从而拖慢随机接入过程。华为网管的波束配置在MOD NRDUCELL或MOD NRRFSLOTCONF相关页面中，这里不需要硬记参数名，重点是调完波束后要做路测验证，别只看小区级RSRP均值。我在做5G故障分析处理时，遇到4G没有的“波束失败恢复”，会先把AAU日志导出，看是否存在BF Recovery Success比例持续低于某个阈值，再决定是调波束还是换RRU通道。

4.3 邻区漏配：5G邻区添加案例里的“第一坑”

5G邻区漏配比4G更隐蔽，因为NSA和SA并存时，漏配可能发生在4G锚点侧，也可能发生在NR侧。一个典型场景：某商场高层室分，终端在NR小区A下显示信号满格，但业务始终卡顿，跟踪信令发现UE一直在小区A做RRC重建立，原因值是too late handover，说明UE在小区边缘发起了切换，但目标小区B没有出现在邻区表里。这种案例不会直接显示“邻区漏配”告警，只能靠信令和邻区表反查。

// 查看5G小区已配置的NR邻区列表 LST NRNCELLRELATION: LOCALCELLID=0; // 按PCI反查邻区是否存在（避免PCI混淆） DSP NRCELL: ALL;

漏配的原因大多是前期邻区规划导出表与现网PCI不一致，尤其是新开站或扩容后没有自动同步邻居关系。修复时不能只加一条邻区，还需要检查源小区和目标小区的PCI是否冲突。添加邻区的命令各版本差异较大，但都会在邻区关系表里带“是否支持B1测量”“切换出是否允许”两个开关，缺一个都可能在切换信令里出问题。这也呼应了“5G邻区添加案例”里最常见的一条经验：加邻区后要立刻做一次业务验证，不能只看邻区状态变为“Effective”。

4.4 5G全网排障的MML命令清单

把上面几个场景的命令串成一张检查单，方便现场应急时直接粘贴到网管执行窗口：

// 查5G小区状态与连接用户数 DSP NRCELL: LOCALCELLID=0; // 查NG口和Xn口状态 DSP SCTP: LOCALCELLID=0; // 查NR上行干扰 DSP NRCELLULINTERF: LOCALCELLID=0; // 查邻区关系和切换参数 LST NRNCELLRELATION: LOCALCELLID=0;

这个清单只做“入口”，具体的定时器调整、波束参数调整需要回到网管页面逐项确认。5G故障处理和4G最大的不同在于，很多根因藏在波束、BWP和CSI这些4G时代没有的对象里，排查时要先看物理层再看RRC层，否则容易把时间浪费在无关告警上。

5. 把故障分析处理经验做成一份能复用的PPT

5.1 每页PPT回答一个“为什么失败”

华为4G&5G故障分析处理及典型案例的PPT，如果只是把告警截图贴上去，价值不大。比较实用的做法是，每个案例按“现象—影响面—根因—动作—验证—固化”六页推进，每页只回答一个问题，并附上信令跟踪截图和MML命令。截图里把关键信令折叠成一行，比如RRC重配置失败的时间戳、失败原因、小区ID，读PPT的人不需要看完整解码就能定位。

5.2 用MML日志作为“证据链”的唯一来源

PPT中涉及参数调整的每一页，都附上调整前后的MML回执，例如MOD CELL的操作返回值。只写“调整A3OFFSET为2”没有说服力，把回执里的“执行结果”和操作频次截下来，同时标注操作时间。回执中的操作序号可以用来和其他同事核对，避免动结论时对不上实际变更。这个习惯对“华为4G&5G故障分析处理”类PPT尤其重要，因为跨班次协作时，操作日志是唯一不会说谎的记录。

5.3 沉淀一份“参数回退表”

案例复盘后，真正能被团队带走的是这张表：故障现象、改动参数、改动方向、回退命令、观察时长。下次这个参数再出问题，可以直接在PPT的附录里找到回退路径。在华为网管上，回退参数的操作通常是对同一条MML命令再执行一次，需要你把旧值和新值都记录下来，否则回退也只是“拍脑袋”。常见做法是把回退命令写进备注页，并标注“至少观察一个完整指标周期”。

5.4 验证结果用“对比曲线”而不是“单一数值”

案例验证不要只留一个改善率数字，要留下忙时曲线。比如切换失败率在14:00到15:00之间从1.5%降到0.3%，这个曲线能证明大部分时段都稳定，而不是某个点偶然恢复。做PPT时把曲线放在最后一页，后面备注“参数生效时间”，这样评审和后续翻历史PPT的人，可以直接顺着这个时间点去查操作日志，再复制一套排查路径。

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