华为TD-LTE站点常见告警处理：驻波、光口、GPS与传输故障排查指南

简介：面向 TD-LTE（4G）站点维护与优化人员，这份华为设备故障告警处理文档系统性梳理了 RRU 射频单元、BBU 基带单元和 GPS 三类常见告警。文档逐一给出告警影响、可能原因与处理建议，并配合 MML 命令、驻波查询、负载测试、馈线倒换、硬件更换等手段，覆盖射频通道异常、光模块收发异常、单板温度异常、星卡天线故障与系统时钟失锁等典型场景，适合一线网优和基站工程师作为现场排查参考。资源为单个 PDF 文件，压缩包大小 752KB，内容按射频单元、基带单元、GPS 分类编排，并附处理小结，目录清晰便于快速定位。已有 740 人学习下载。读者可获得从告警现象判断、远程复位到上站处理工具与备件准备的完整排障思路，其中融合了网管信息、MML 命令与现场检查要点，有助于提升 TD-LTE 站点故障响应效率。

1. TD-LTE站点告警处理：凌晨的电话，一半是驻波比，一半是光口

凌晨两点被值班电话叫醒，十有八九是站点上报了驻波比告警或者小区不可用。TD-LTE(4G)网络里，华为设备在存量站点里占比很高，日常故障告警处理基本围绕eNodeB的射频模块、光口链路、时钟源和传输接口展开。这篇笔记把华为站点常见的故障告警按“什么告警、影响多大、怎么查、怎么处理、处理完怎么验证”写全，适合刚接手后台的运维人员、三方协维和需要自己上站的工程调测工程师。目标是把一套可复现的处理流程，替代掉“看告警、猜原因、重启试试”的救火式老路。

2. 先看懂告警再碰设备：华为eNodeB告警的分类逻辑与影响判断

刚入职的时候老师傅跟我说的一句话，到现在我都觉得是这行最值钱的忠告：告警处理的第一步不是去清告警，而是先分清楚这个告警是“大病”还是“小灾”。华为eNodeB的告警通过U2000或U2020网管上报，每条告警都带着告警Code、告警名称、严重级别、定位信息、发生时间和恢复时间。很多人一上来直接看告警名称，这不够，名称相同的告警，发生位置不同，处理方式可能完全相反。

2.1 告警Code、严重级别与模块归属：一张表分清“大病”和“小灾”

华为设备的告警Code是定位问题的第一把钥匙。比如光模块告警和光口链路告警，Code不同，背后的处理方向完全不同；同样是RRU退服，有的根因在光模块，有的根因在供电，有的根因在天馈。先记Code再想操作，能省掉大量无效排查。

严重级别是第二层判断标准。华为网管上常见的是紧急、主要、次要、提示四级，级别直接决定处理时效，也决定你要不要半夜爬起来。

第三层是模块归属。华为TD-LTE基站常见告警归属四大模块：射频天馈模块（RRU、天线、馈线）、光口链路模块（BBU到RRU之间的光纤和光模块）、时钟同步模块（GPS天线、馈线、时钟板）、传输接口模块（S1/X2接口、PTN侧链路）。为什么要把模块归属说在前面？因为告警影响面和恢复方式完全不一样。射频告警通常影响单个小区；光口链路告警可能打掉一个RRU下挂的所有小区；GPS失步在TD-LTE里直接导致整站退服，因为TDD对时间同步要求极高；传输接口故障轻则切换异常，重则用户无法附着。拿到告警先往这四类里放，再决定要不要上站。

2.2 根告警与衍生告警：告警风暴里先动哪一个

站点出现批量告警时最容易犯的错误，是看到哪条告警用处理哪条。我一般会把告警按发生时间升序排一遍，最先出现的那条大概率是根告警，后面跟的一串基本是衍生告警。比如RRU光口LOS告警先出现，随后跟着RRU退服、小区不可用、业务不可用，这时候核心是解决光口链路，而不是去碰小区配置。

判断根告警还有一个技巧：看告警之间的依赖链。华为网管上，很多衍生告警的定位信息里会直接带上关联的告警Code。比如“小区不可用”告警的原因类型里可能写明“光口链路故障”或“GPS失步导致”，这就省掉了猜的过程。如果网管版本比较老，看不出关联关系，就按“先硬件后软件、先底层后高层”的顺序排查：光口链路、GPS、传输这些物理链路永远是优先级最高的，因为它们一旦出问题，上面所有业务都会跟着倒。

还要注意实时告警和历史告警的区别。有些站点白天频发、晚上自动恢复，这类间歇性告警往往比持续告警更难缠，不能因为恢复时间有了就关单，需要看频次和发生时段。告警风暴处理完后，还要在网管上做一次全量确认，避免有告警被“顶掉”漏看。

3. 四大高频告警的处理流程与关键参数：驻波、光口、GPS、传输逐个拆

华为TD-LTE站点的日常告警里，出镜率最高的就是驻波比告警、光口链路告警、GPS失步告警和S1/X2链路故障。这四类加起来能占后台工单的八成以上。每类的排查路径我都按“网管查什么参数、现场测什么指标、命令怎么敲、故障怎么隔离”来做，照着走基本不会跑偏。

3.1 RRU驻波比告警：从网管查到天馈检测的完整动作

驻波比告警的本质是天馈系统阻抗不匹配，射频能量反射过大。常见原因是馈线接头进水、接头松动、馈线弯折半径过小、天线内部故障，甚至RRU射频通道自身功率检测器件漂移。

第一步，在网管上看告警详情，记录RRU编号、通道号和上报的驻波比值。华为RRU驻波比告警阈值默认一般配在1.5左右，超过1.5就会触发告警；不同RRU型号的告警阈值可以通过配置修改，我习惯先看当前配置而不是直接下结论。

// 查询RRU驻波比和通道状态（LMT或U2000 MML终端执行） DSP RRU: CN=0, SRN=0, SN=0; // 查询RRU射频通道的发射状态 DSP RFCH:;

执行完后看返回结果里的“驻波比”字段。如果驻波比在1.2以下，说明射频通道本身没问题，重点怀疑告警阈值配置过严或者RRU检测单元异常；如果驻波比在1.5以上，基本可以认定天馈系统有问题，准备上站。

上站之后拿天馈测试仪（Site Master或同类产品）在RRU射频出口测驻波比和回波损耗。判断标准我按两条走：驻波比小于1.5算合格，大于2.0可以直接判定天馈故障。中间值1.5到2.0之间，要结合现场环境判断，重点检查接头是否有进水痕迹、馈线是否有硬弯、天线是否被鸟啄或雷击。

这里有个常见的坑：天馈测试正常，但RSSI底噪异常高。这说明问题不在驻波，而在无源互调（PIM），接头氧化或连接器内异物会导致互调信号干扰上行通道。普通天馈测试仪测不出互调，必须用互调测试仪。处理方式也很费工：重新制作馈线接头、替换连接器、清洁天线端面。遇到反复驻波告警又测不出问题的站点，一定要往这个方向走。

3.2 CPRI光口链路告警：光模块、光纤、板卡三级排查

BBU和RRU之间通过CPRI链路承载IQ数据，光纤或光模块故障直接导致RRU脱管。光口链路告警的排查路径很清楚，三级排查就够了。

// 查询光模块收发光功率 DSP OPT: CN=0, SRN=0, SN=0; // 查询光口链路状态 LST OPT:; // 查询RRU注册状态和链路状态 DSP RRU:;

第一级看光模块功率。华为设备光模块正常发射光功率一般在-3到0 dBm左右，接收光功率在-20 dBm以上算健康；低于-25 dBm时链路误码率会显著上升，低于灵敏度阈值就会产生LOS告警。这个数值不是固定的，不同速率、不同波长的光模块规格差异很大，我一般先对比本端发射和对端接收，两头都低是光纤问题，本端正常对端收不到是链路中间有问题。

第二级看光纤。清洁光纤端面这件事被很多人忽略，实际上光口告警里一大半是端面污染。清理时用光纤清洁笔或酒精棉轻擦端面，不要用手碰，也不要用嘴吹。清理完重新插上，在网管上看告警是否恢复。没恢复就把光纤两头对调，如果告警跟着走，说明是光纤本身的问题，直接换纤。

第三级看板卡和端口。光纤没问题、光功率也正常，但告警就是清不掉，这时候要怀疑光模块插槽接触不良或板卡端口损坏。换个空闲端口试一下是最快的验证手段。光模块本身也有寿命问题,长时间高温运行会出现发射光功率劣化，替换一个同规格模块就能定位。

整个处理过程里，最忌讳的是直接跳级复位RRU。光模块或光纤问题没有排除之前，复位RRU只会让业务再闪断一次，告警甚至会原样回来。

3.3 GPS失步告警：馈线、避雷器、时钟源配置三步走

TD-LTE是TDD系统，空口收发依赖严格的时间同步，GPS失步会直接导致站点退服。处理GPS告警的顺序，我固定按硬件、链路、配置三步走，不要上来就改时钟源参数，改完大概率还是失步。

// 查询GPS卫星跟踪状态和可见星数 DSP GPS:; // 查询GPS星卡版本和当前定位状态 LST GPS:;

硬件看天线。GPS天线上方如果有遮挡，比如周围新起了高建筑、天线被树叶盖住，可见星数就会掉到不足四颗，失步告警随之而来。站顶检查时注意天线朝向和安装仰角，天线附近有金属遮挡也会反射干扰信号。

链路看馈线和避雷器。GPS馈线接头进水是高频故障，馈线接头是室外最脆弱的地方，进水后信号衰减加剧，但白天太阳一晒又能恢复部分性能，表现出来就是夜间GPS失步、白天恢复的间歇故障。避雷器击穿也会导致同样的表现，而且肉眼不易发现，需要用万用表量避雷器两端导通特性，或者直接替换一个确认完好的避雷器对比。

配置看时钟源优先级。华为eNodeB支持GPS时钟和1588时钟同步，默认优先级一般是GPS优先。如果现场部署过1588，但配置错乱导致时钟源来回切换，也会出现周期性失步告警。查询时钟源配置时确认优先级设置和你现场实际情况一致，不一致就修改成正常值。

GPS告警处理完不代表就收工了，必须确认GPS状态要在“锁定”或“同步”状态才算恢复，有些站点在定位状态“未锁定”时告警也会暂时消失，靠的是欺骗性保持，这种状态撑不了多久。

3.4 S1/X2链路故障告警：基站侧和传输侧怎么划清界面

S1接口是基站到核心网的接口，X2接口是基站之间的接口，这两个接口故障表现差异很大。S1故障会直接导致用户无法附着和会话建立失败，属于必须立即响应的告警；X2故障通常表现为切换异常和负荷均衡失效，业务还能用，但用户体验已经变差。

处理链路故障的第一个动作是查告警范围。如果告警面板上出现多个站点同时上报传输类告警，大概率是传输侧或核心网侧的批量故障，先看传输网管有没有同步告警，不要自己先跑站点。

// 查询S1/X2链路状态 DSP SCTP:; // 查询传输网络层配置 LST TNL:; // 查询以太网端口状态和光模块信息 DSP ETH:;

在基站侧确认端口状态正常、光模块正常后，就要和传输侧做界面划分。常见做法是让传输侧在PTN设备上做环回测试，基站侧配合确认物理层是否恢复，然后再确认SCTP链路是否重建。这里要看的一个关键参数是SCTP链路状态，如果一直是DOWN，说明应用层连接没起来，物理链路光正常也不行。

排障过程中，我不建议一上来就动IP配置。IP地址和VLAN配置出错引发的链路故障，反复修改只会越弄越乱。正确姿势是先确认物理层和链路层，再往上层走。物理层看光口是否UP，链路层看端口是否有错包，上层看SCTP状态，一层一层剥。

4. 告警处理避坑：5个翻车场景的现象、原因与解决顺序

处理告警这么多年，踩坑踩出来的教训比书本上学到的多得多。下面这五个场景是现网里反复出现的“玄学”问题，每个都按现象、原因、解决的顺序写。遇到类似的情况，先对照一下再动手。

4.1 驻波告警反复出现，天馈测试却正常

现象：站点驻波比告警隔三差五上报，上站用天馈测试仪测驻波比和回波损耗全部合格，重新插拔接头后告警恢复，过几天又原样报出来。

原因：天馈接头存在隐性进水或接头接触面氧化，测试时机不对。晴天测试时水分蒸发，测试结果正常；夜间或雨后水气渗入，驻波比飙升。另一个可能原因是RRU射频通道的功率检测器件本身漂移，检测值不准。

解决：处理隐性进水不是擦干表面就行，要把接头打开，检查密封胶圈和防水胶带，重新制作冷压头，做好排水孔。如果两次上站都找不到天馈问题，直接换一个RRU射频通道对比；换通道后不再告警，就是RRU内部检测异常，报障换RRU。

4.2 光模块换了新的，光口告警依旧在

现象：光口LOS告警上报，现场更换了同规格新光模块，清洁了本端光纤端面，告警不恢复，光功率测试显示收光正常但链路还是起不来。

原因：这类问题多半不在本端，而在对端。光纤链路中间有法兰盘连接，远端端面污染或法兰盘对接不良也会导致链路误码，但光功率值未必会立刻掉到门限以下。还有一种情况是光模块规格不匹配，比如单模多模不匹配、波长不一致，虽然能收到光但信号质量很差。

解决：先用光功率计和OTDR测整条链路损耗和事件点，别只测本端；把对端光模块拔出来清洁端面再插回去，同时检查法兰盘是否有灰尘。核对两端光模块的波长、速率和传输距离等级，必须完全一致。处理完要在网管上确认LOS告警恢复，不能只看光功率数值正常就关单。

4.3 GPS失步重启恢复，几天后又复发

现象：GPS失步告警伴随小区退服，上站重启BBU后小区恢复，告警消失。但过了几天，同一个站点又在凌晨出现同样的告警，重启又恢复。

原因：GPS信号质量已经在门限边缘，白天信号稍好能维持锁定，夜间或天气变化时信号衰减加重，触发失步。硬件上常见是GPS馈线接头氧化、避雷器性能劣化或馈线弯折处受损。重启BBU只是让接收机重新捕获卫星，并没有解决信号衰减的问题。

解决：不要再重启了，换掉GPS跳线并重新做接头才是根治。GPS避雷器是容易被忽视的环节，劣化时表现为时好时坏，直接用替换法换新避雷器。处理完之后连续盯一周的GPS星数和同步状态，确认夜间不掉才关单。GPS馈线长度如果超规格，信号损耗是固定的，改配置解决不了，只能缩短馈线或换有源GPS天线。

4.4 告警清除后没有复测，业务暗伤留了一周

现象：故障告警在网管上恢复，工单关闭。第二天网优反馈该站点RSSI底噪抬升、切换成功率下降，用户投诉增多，但网管上已经看不到任何活动告警。

原因：把故障处理等同于告警消除，漏掉了恢复后的性能验证环节。告警恢复只说明网元状态回到了正常，不代表空口质量和业务体验已经恢复。尤其在天馈故障处理后，天线系统可能带伤工作，比如天线内部单元损坏但驻波比仍在告警门限内，这种状态网管告警系统是发现不了的。

解决：处理完必须做复测三件事——查小区的实时状态、查RSSI和RSRP指标、查看切换成功率。天馈类和光口类告警处理完，至少观察24小时性能指标再关单。我现在带的团队，工单关闭条件里强制加了一条：处理人在关闭前要附上处理后的指标截图。

4.5 多条告警同时上报，先复位主控板的全闪断教训

现象：一个站点突然上报多个RRU链路告警、小区不可用告警，值班人员为了快速恢复业务，直接对BBU主控板执行了复位操作。结果业务没有按预期恢复，整个站点的用户全部闪断了一次，部分小区在复位后注册得更慢。

原因：批量RRU告警往往不是基站单板的问题，而是传输侧中断或某个上级光路中断导致的连带告警。复位主控板会让BBU整机重启，所有用户都会掉线，但引起告警的根源没有被处理，重启完成后链路依然中断，业务恢复不了。

解决：看到批量告警时，先看这些RRU是不是挂在同一根上级光纤或同一条传输路由上。如果在同一个光链路下，根因大概率在汇聚点，而不是单个RRU。先把传输侧或光链路恢复，再在网管上确认基站侧告警是否自动恢复。主控板复位要放在最后，而不是放到第一。

5. 把处理流程固化成工具：MML命令组合、告警数据二次分析与闭环管理

告警处理不能每次都靠人肉翻网管，最高效的做法是把固定动作沉淀成命令组合和脚本，让工具帮我们做重复劳动。这一章把我平时用的命令组合和数据处理方法交出来，都是现网实操验证过的东西。

5.1 常用MML命令组合：查告警、查光模块、查GPS、查小区一套走完

华为设备的MML命令在LMT或者U2000的MML终端里执行，命令不长，但组合顺序有讲究。我的习惯是先看整体状态，再看细节，最后才做操作。下面这组命令是我处理单站故障时固定执行的“开场白”。

// 查询当前活动告警，ALMTP=ALL表示查全部告警 LST ALMFAULT: ALMTP=ALL; // 查询所有RRU的注册状态和驻波比 DSP RRU:; // 查询光模块收发光功率 DSP OPT:; // 查询GPS星卡状态 DSP GPS:; // 查询小区状态 DSP CELL:;

执行顺序有讲究：先LST ALMFAULT看全局，知道站点现在处于什么状态；再DSP RRU看射频侧，DSP OPT看光模块，DSP GPS看时钟源，DSP CELL看小区。如果告警指向传输类故障，再补一条DSP SCTP和LST TNL，而不是一上来就把所有命令都跑一遍，输出太长反而看不出重点。

命令执行时注意参数范围，CN、SRN、SN代表框号、单板槽位号、子卡号，不确定的时候可以留空查询全部。不同版本的eNodeB命令名会有细微差异，以实际版本执行help确认即可。

告警清除的命令要放在恢复确认之后。华为网管上RMV ALMFAULT可以清告警，但清告警的本质是“在网管数据库里抹掉记录”，设备侧若还存在故障，告警很快就会重新上报。所以我的铁律是：先修复，再清告警；清除后刷新一次确认告警不回来了才算完。

5.2 告警导出与批量分析：用Python把重复性工作交给机器

单个站点手动处理没有问题，但一接手几十个站点的告警核查，人工翻网管效率太低。U2000网管支持把告警导出为CSV文件，拿到这个文件后用Python做统计分析，能快速发现站点规律，比如哪类告警最多、哪个站点告警反复、哪些告警总是成对出现。

import csv from collections import Counter # 读取U2000导出的告警CSV，注意文件编码带BOM with open('alarm_export.csv', 'r', encoding='utf-8-sig') as f: rows = list(csv.DictReader(f)) # 筛选尚未恢复的告警，按告警名称统计频次 active_alarms = [r for r in rows if r.get('恢复时间', '').strip() == ''] top_alarms = Counter(r['告警名称'].strip() for r in active_alarms).most_common(20) print(f"当前活动告警总数: {len(active_alarms)}") for name, count in top_alarms: print(f"{count:5d} {name}")

这段脚本的逻辑很简单，但很实用。U2000导出的CSV表头在中文网管上是中文的，不同版本字段名略有差异，运行前先打开文件看表头名称，把字段名改成实际列名，不能直接照抄。编码用utf-8-sig是对付带BOM的文件，不用的话第一列列名会带上乱码字符。

更进一步的批量分析是把告警按站点ID分组，统计每个站点的告警频次和重复告警率。重复告警率是一个很敏感的信号：同一个站点同一类告警一个月内出现三次以上，说明根因没有真正解决，只是每次清掉了表面现象。这类站点应该进重点整治清单，而不是继续被动响应。

5.3 告警闭环三件套：确认、标注、复测，一个都不能少

流程层面最容易出问题的地方，不是技术不行，而是闭环做得稀碎。我现在推动团队执行告警闭环三件套，做完三个动作才算处理完一个告警。

第一个动作是确认。告警发生时，先在网管上确认告警是否仍然存在，有些告警在传输闪断后会自动恢复，不确认就派单上站，就是在浪费人力。

第二个动作是标注。处理完成后在网管或工单系统里填写根因分类和具体处理动作。不要写“现场处理完成”这种废话，要写“馈线接头进水，重新制作冷压头并做防水”，这样下次同类告警出现时，查工单就能直接定位方向。

第三个动作是复测。复测不只是看告警恢复，还要按我在第4章里说的，跑一遍小区状态、RSSI、RSRP、切换成功率四个检查项。告警处理完但业务指标变差了，比告警没处理更糟糕。

6. 从救火到防患：用告警基线管理减少夜间被叫醒

6.1 给站点做告警健康度评分：用一周数据排出整治优先级

告警处理做得好的团队，不是处理速度快，而是让告警根本不要发生。我自己的做法是每个季度给维护区域内的站点做一次告警健康度评分，用一周的告警数据算出分数，排在前列的站点进整治清单。

总分超过80分的站点，意味着它每周都在消耗人工处理成本，这类站点不要只做被动响应，要安排一次彻底上站检查，把根因刨出来。这套评分对于GPS间歇失步、驻波比反复上报这类“薛定谔故障”特别有效，数字不会说谎。

6.2 把经验固化成规则：当自动化辅助成为常态

告警数据导出后，可以用参数规则自动识别可疑站点。比如GPS馈线进水导致的间歇失步，规律往往是夜间失步、白天恢复、一周内多次上报，这种模式完全可以通过脚本标记出来，优先派单。一套简单的Python脚本加上告警CSV，就能把一个区域的告警按“疑似隐性故障”和“普通故障”分流，白天集中处理高优站点，夜间值班压力会明显降下来。

这几年处理故障最大的教训是：不要急着复位，先看告警的辈分，根因不清就不该动手；根因清了，就不要只把告警刷掉，要做复测、要留记录、要反哺到基线管理里。希望帮到你。

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