SCTP偶联断告警处理总结
X2告警处理总结
1名称：X2告警处理总结提交人：陆强 提交日期：2013-5-2软件版本：EMB5116_TD-LTE_V3.20.00.22.05******************************************************************************************************************** 问题描述：前期在分析每日告警的时候发现X2链路告警占了很大比例，经过一段时间的处理，总结X2告警产生的根本原因在于存在邻区关系的两个基站之间的SCTP 链路没有建立成功，解决办法是排查两个基站之间的邻区关系，找出邻区关系中与规划数据不一致的数据，修改成一致之后即可消除告警。
因此，要想解决此告警，准备知识是掌握基站邻区关系添加的正常流程，以此为基础进行邻区关系异常状况的梳理解决。
邻区关系添加关键参数：源基站ID ，源基站小区ID ，邻基站ID ，邻基站小区ID ，邻基站PCI ，邻基站TAC 。
由于存在宁波基站割接至华为EPC 的情况，X2告警除了核查以上参数之外，还需要关注移动国家码，移动网络码等相关参数是否正确配置。
几类X2故障处理方法：1.对端基站IP 改变引起X2链路告警。
由于基站搬迁等其他原因，基站IP 地址更换，导致源基站至IP 更换站点的SCTP 链路建立失败。
删除源基站至此邻基站的无效SCTP 链路，并删除源基站至此邻基站的邻小区关系，按照新IP 重新添加源基站至此邻基站邻区关系。
涉及参数项包括：外部邻小区，邻小区关系。
只需在存在X2链路告警的基站操作即可解决。
2.基站冗余SCTP 链路引起X2链路告警。
源基站与SCTP 链路建立失败的对端基站不存在邻区关系，此邻基站到源基站的邻区关系也不存在；对端基站不存在或者两个基站距离很远，不可能有邻区关系。
这些情况可能是基站开通时配置数据自带的冗余邻区关系，或者已经搬迁或者拆除的基站，删除即可消除X2告警。
5G网络设备常见故障处理
2.告警原因分析、处理方法
天馈类告警分析，处理方法：
告警码 198098465 天馈驻波比异常
告警原因 驻波比设置门限问题 RRU安装的工艺问题导致，防水问题 RRU设备自身通道故障
天馈线缆存在挤压、弯折，或馈缆损坏
198094848 天线校正失败
天馈线缆连接故障 校准线连接松动或者错误
时钟类告警分析，处理方法
6.GNSS接收机搜星故障
● 告警原因：
➢ GNSS天馈连接线缆异常； ➢ GPS天馈方向有建筑物阻挡； ➢ 周边环境存在干扰。
• 排查步骤：
• 1.进入诊断测试界面查看GPS配置是否生效、天馈状态是否正常；
• 2.检查GNSS天馈线缆连接，确保连接正常，且GPS天线安装符合工程规范（GPS天线竖直方向±45°范围内无遮挡物），确保良好的卫 星视通条件；
1.判定是否高业务期，若是，建议扩容解决 2.更新处理功能更强的最新单板(CCE1,BPN2)
2.告警原因分析、处理方法
传输类告警分析，处理方法：
告警码
告警原因 本端或对端偶联参数配置错误
198092230 SCTP偶联断
传输链路故障
198099803 网元断链告警源自网元与OMM服务器链路断 网元配置IP不正确 传输故障导致 网管服务器异常
• 1.首先检查和网管断链基站的范围，是个别基站还是大量基站,如果是大量基站断链，优先核 查传输是否存在断点，电力是否成片停电的情况；
• 2.针对单个站点断链，上站核查BBU至PTN间跳纤是否存在断点，光模块收发光是否正常； • 3.从网管侧路由跟踪，查看那一跳路由之后不通，联系传输核查； • 4.从基站侧使用LMT工具登录CC板，检查能否PIING通传输网关，能ping通则联系传输后续
MME X2闪断经验总结
青岛LTE网络S1、X2闪断造成切换成功率低经验总结现场先对LTE网内的邻区进行梳理，SCTP链路现在外场版本最多是32条。
现在删建的原因主要是由于多个无效数据导致，现场梳理完后，对于反复建立的问题就出消除的。
查看基站的异常日志。
X2告警显示如下：产生时间:2014-05-15 19:12:35告警级别:4-警告告警告警类型:3-处理错误告警告警上报类型:异常产生重复次数：214故障源:机架:0 机框:0 插槽:1告警模块名称:HL_AP告警编号:11194告警子原因:255:无效是否确认:否注释 :X2建立失败告警解释:X2建立失败故障后果:对设备的影响：无影响；对业务的影响：无影响；对设备的影响的详细描述：无；对业务的影响的详细描述：无修复建议:程序自动后处理：无；预处理操作建议：无；远端处理建议：无；近端处理建议：无附加信息:File:/x2ap_x2setup.c,Line:1517, KeyParameters:100,70,19,39,8,42074,对于对端地址为：100.70.19.39 这条链路故障原因是：8，这个8表示邻基站表已满。
查看邻基站表存在12个无效基站信息：，建议现场将邻基站无效信息删除，将基站间邻区重新规划。
将无效的邻区全部删除。
（SCTP偶联索引为：invalid 为无效）MME反复建立是由于收到核心网发来的abort。
MME反复建立是由于收到核心网发来的abort。
SCTP链路实例31：到核心网MME链路，配置对端地址为：10.70.254.3/10.70.254.4：打印消息如下循环：未建、故障、驱动配置成功、驱动建立成功、与对端连接成功、正常；(修改): 第1个MME组ID(adjeNBMmeGroupId1), 实例31, 值变为： 32769(修改): SCTP偶联索引(adjeNBSctpIndex), 实例31, 值变为： 15(修改): SCTP链路建立状态(sctpStatus), 实例31, 值变为：未建(修改): 运行状态(sctpSignalBearStatus), 实例31, 值变为：故障(修改): SCTP链路建立状态(sctpStatus), 实例31, 值变为：驱动配置成功(修改): SCTP链路建立状态(sctpStatus), 实例31, 值变为：驱动建立成功(修改): SCTP链路建立状态(sctpStatus), 实例31, 值变为：与对端连接成功(修改): 运行状态(sctpSignalBearStatus), 实例31, 值变为：正常实例24：到另一个基站链路，对端地址为：100.70.19.59打印消息如下循环：与对端连接成功、正常、未建、故障、驱动配置成功、驱动建立成功；(修改): SCTP链路建立状态(sctpStatus), 实例24, 值变为：与对端连接成功(修改): 运行状态(sctpSignalBearStatus), 实例24, 值变为：正常(修改): SCTP链路建立状态(sctpStatus), 实例24, 值变为：未建(修改): 运行状态(sctpSignalBearStatus), 实例24, 值变为：故障(修改): SCTP链路建立状态(sctpStatus), 实例24, 值变为：驱动配置成功(修改): SCTP链路建立状态(sctpStatus), 实例24, 值变为：驱动建立成功正常X2建链消息如下：(修改): 移动国家码(adjeNBPlmnMcc), 实例5, 值变为： 000(新建): 行状态(adjeNBRowStatus), 实例5, 值变为：行有效(修改): 邻eNB全球ID(adjeNBGlobalId), 实例5, 值变为： 18(修改): 移动国家码(adjeNBPlmnMcc), 实例5, 值变为： 460(修改): 移动网络码(adjeNBPlmnMnc), 实例5, 值变为： 00(修改): 第1个MME组ID(adjeNBMmeGroupId1), 实例5, 值变为： 32769(修改): SCTP偶联索引(adjeNBSctpIndex), 实例5, 值变为： 2(修改): SCTP链路建立状态(sctpStatus), 实例5, 值变为：驱动建立成功(修改): SCTP链路建立状态(sctpStatus), 实例5, 值变为：与对端连接成功。
告警问题总结
如果该告警一直存在，最终会导 致基站GPS 时钟源不可用
小区建立失败，所有业务中断。
当小区建立失败或小区退出服务，并且原 因不是配置管理员人为闭塞时，产生此告 警
小区状态与基带资源、射频资源、CPRI资源 和传输资源这些物理资源有关，也与 License有关。在物理资源不足、物理资源 故障或物理资源被闭塞的情况下，小区状态 会因为无可用的物理资源而变为不可用。即 使物理资源可用但License不足时，也会导 致小区不可用。多模场景下，由于共享资源 受限（如频率、功率），也会导致小区不可 用。当小区状态变为不可用，且该状态持续 90秒（默认）未恢复时，将产生该告警。当 小区状态变为可用，且该状态持续15秒（默 认）一直可用时，则上报告警恢复。告警产
射频单元承载的业务中断。
BBU和射频单元之间通过电缆或者光纤进 行连接。当BBU与射频单元间的维护链路 出现异常时，产生此告警。
在链形组网下，下级射频单元的连接链路中 断，下级射频单元承载的业务中断。如果基 站工作在CPRI MUX特性的组网，本制式为汇 聚方且故障端口为提供汇聚功能的端口时， 会造成对端制式的业务中断。 当BBU与下级射频单元之间的光纤链路 在环形组网下，射频单元连接链路的可靠性 （物理层）的光信号接收异常时，产生此 下降，下级射频单元的激活链路将倒换到备 告警。 份链路上，在热环配置下对业务没有影响， 在冷环配置下业务会出现短暂中断。 BBU与下级射频单元的光模块的收发性能轻 微恶化，可能导致下级射频单元承载的业务 质量出现轻微恶化。
基站将主动去激活所有与异常的S1接口相关 的小区，并释放此前已经成功接入到这些小 区内的所有在网用户。新的用户将无法接入 到这些小区。
当射频单元与对端设备（上级/下级射频 单元或BBU）间接口链路（链路层）数据 收发异常时，产生此告警。
中兴基站LTE告警分类梳理及处理思路
1、确4认、P更R换RUP侧RR网U线后连观接察正常
PRRU
2、确认PB侧网线连接正常 3、更换相应网线后观察
1、通过软4、件更管换理P查RR询U基后站观运察行版本是
主控板
否完整 2、重新下载、预激活、激活生效确实
1、通过软件管理版查本询基站运行版本是
主控板
否完整 2、重新下载、预激活、激活生效确实
ENODEB CAL(校准)口线缆接错 重要
ENODEB
射频通道衰减一致性异 常
重要
RRU校准口的同轴线缆错误连接到了普通的天 线通道上。
射频通道功率差异大于告警门限。
ENODEB
天线校正失败
重要
天线校正失败。
ENODEB
LTE小区退出服务
重要
小区被删除或故障时上报此告警。
ENODEB
退服类故 障
ENODEB
普通
OMC没有配置单板，但实际槽位有单板时上报 该告警。
ENODEB
单板通讯链路断
重要
单板的通讯链路断时上报该告警。
单板类故 障
ENODEB
风扇故障
普通
风扇出现故障时上报该告警。
ENODEB
TX通道基带输入信号异 常
重要
基带单元发给射频单元的基带IQ数据功率超过 了额定功率，或者低于最低功率。
ENODEB
RRU链路断 RRU光纤时延超限
光模块不可用 光口接收链路故障
PB链路断
严重 严重 普通 重要 严重
当RRU单板软件心跳丢失超过设定周期时，上 报该告警。
在给定的提前量TA下，当BBU测量出的RRU光纤 时延值超出了RRU的处理范围时，上报该告警
。
1、光模块不在位时上报该告警； 2、光模块发送故障时上报该告警
华为交换机告警处理手册
华为端局告警处理手册目录1. MSC SERVER处理分册 (3)1.1 告警箱处于离线状态 (3)1.2、FE端口故障 (3)1.3、WCKI时钟参考源丢失 (4)1.4、控制框与业务框通信失败 (5)1.5、BAM到主机通讯失败 (7)1.6、BAM到主机连接中断 (8)1.7、与NTP服务器断连 (9)1.8、Q922链路故障 (10)1.9、TCP链路故障 (11)1.10、CPU过载 (12)1.11、单板网口协商失败 (14)1.13、许可证文件即将失效 (15)1.14、计费中心长时间未取话单 (16)1.15、心跳中断 (17)1.16、双机倒换 (18)1.17、私网中断 (19)1.18、IP资源失效 (21)1.19、备份连接失败 (22)1.20、单板故障 (23)1.21、许可证即将过期告警 (24)1.22、许可证已经过期告警 (25)1.23、电源输出开关关闭 (26)1.24、H.248 SCTP链路故障 (27)1.25、MGW退出服务 (29)1.26、MTP目的信令点不可达 (30)1.27、MTP路由传输禁止 (32)11.28、MTP链路故障 (33)1.29、MTP缓冲区拥塞 (35)1.30、M2UA链路故障 (37)1.31、SCCP目的信令点禁止 (38)1.32、SCCP子系统禁止 (40)N => 联系对端局点确认其子系统是否恢复。
(42)2. MGW处理分册 (42)2.1 FE级联网口故障 (42)2.2 风扇框通讯故障 (43)2.3 NET单板时钟检测异常 (46)2.4 NET单板时钟失锁 (49)2.5 GE级联光口故障 (51)2.6 NET单板时钟失锁 (53)2.7 NET单板时钟配线故障 (54)2.8 级联光口故障 (56)2.9 GE通道光模块故障 (58)2.10 TDM通道光模块故障 (61)3.11 BLU时钟检测异常 (63)2.12 信令链路故障告警 (65)2.13 SPF扣板链路故障 (67)2.14 L2UA链路组故障 (70)2.15 L2UA链路故障 (71)2.16 单板软件异常告警 (73)2.17 SIWF故障告警 (75)2.18 控制平面拥塞 (77)2.19 单板故障 (78)2.20 告警箱断链 (81)2.21 单板上存在故障的半永久 (82)2.22 参考源丢失 (84)2.23 虚拟媒体网关迁移出业务态 (85)1. MSC SERVER处理分册1.1 告警箱处于离线状态告警含义1. 告警解释当BAM与告警箱之间通信中断时间超过10秒钟后，系统将产生该告警。
SCTP偶联断告警处理总结
故障处理经验案例---SCTP偶联断告警处理总结使用建议：在阅读本文档的同时参阅如下资料：故障现象描述LTE基站上报"SCTP偶联断"告警，在告警详细信息中的附加文本会提示具体偶联号。
可能伴随的相关告警有：网元断链告警、基站退出服务（基站上报）、TD NodeB退服告警（RNC上报）、S1断链告警、X2断链告警。
故障分析排查思路一、确定具体SCTP偶联号及类型。
在告警详细信息的“附加文本”指示具体偶联号。
目前LTE基站存在3类偶联：TDS基站与RNC的SCTP偶联、LTE基站与EPC的SCTP偶联、LTE基站与LTE基站之间的SCTP偶联。
二、在基站端、OMC服务器、核心网侧做ping检测。
LTE使用IP分组传输技术，出现传输类故障时可以通过ping方法定位故障节点。
下图是LTE 双模基站IP传输逻辑图。
LTE双模基站IP传输逻辑图双模基站配置有3个IP，分别是基站维护IP、基站LTE业务IP、基站TDS业务IP。
可在配置表中的“SCTP参数配置”中确定哪两个IP分别用于TDS业务和LTE业务，在“OMC通道”配置项中确定哪个IP用于基站维护。
三、检查对应SCTP偶联本端（基站侧）、PTN传输、SCTP偶联对端（EPC/RNC/基站）配置是否正确。
图（1）SCTP参数配置图图（2）OMC通道配置图故障排查方法1)ping包检测故障节点EDMS ping包检测界面见下图所示。
图（3） Ping包检测界面“Ping基站网关”右侧下拉列表中的地址都需要保证能ping通，不通的话说明对应传输链路故障。
双模基站有3个网关，分别是TDS网关、LTE网关、维护网关。
LTE单模基站没有TDS网关。
对于特定基站，ping基站网关时实际ping 的就是图（4）中"172.39.1.1"、“100.64.36.129”、“100.92.36.129”这三个地址。
“Ping OMC服务器”功能可以检测基站到网管服务器之间链路状态。
SCTP偶联中断故障处理案例
SCTP偶联中断故障处理故障现象：诺西端局CSGS45的单块ESB板故障，造成SCTP偶联的主通路中断，由于现网局间SCTP偶联均配臵了双通路，单块ESB板故障并不会导致局间SCTP偶联中断。
而实际情况是，CSGS45至中兴局向部分SCTP偶联中断，而到华为局向和其他诺西局向的SCTP偶联均正常，也就是说SCTP的双通路并未起到保护作用，对此，我们进行了分析，并排除了故障。
原因分析：分析判断可能原因：1、备用通路不通2、诺西端局硬件或配臵问题3、中兴端局硬件或配臵问题原因排查：SCTP（STREAM CONTROL TRANSMISSION PROTOCOL 流控制传输协议）能在两个端点之间提供稳定、有序的数据传递服务，在SIGTRAN协议的应用中，SCTP 上层用户是SCN 信令的适配模块（如M2UA、M3UA），下层是IP网。
偶联实际上是在两个SCTP端点之间建立的连接关系，任何时刻两个SCTP端点之间能且仅能建立一个偶联。
通路则是一个端点将SCTP分组数据发送到对端端点特定传送地址的路由。
在现网中，如下图1所示，两个端局之间配臵了4个偶联，每个偶联具有主备两条通路，并采用了心跳机制，即当某条通路空闲时，本端端点会生成相应的心跳消息并通过该空闲通路发送到对端端点，而对端端点收到消息后将立即发回对应的心跳确认消息。
该机制被用来随时监视偶联通路的可用情况，当某一条通路故障时，数据传送将立即切换到另一条通路上，以此来保持SCTP偶联的可靠性和稳定性。
通路1图1 局间偶联示意图图2 诺西端局偶联配臵示意图如上图所示，诺西端局的偶联建立在GISU板上，每一块GISU板对应一个偶联。
每个偶联的两条通路分别通过两块ESB板连接直IP承载网，进而与对端局相连。
本次故障起因为ESB1板故障，但单块ESB板故障只会导致偶联2条通路中的1条通路中断，根据偶联的心跳机制，数据传输将立即切换到另一条通路上，整个偶联将不会受影响。
SCTP偶联中断故障处理案例
SCTP偶联中断故障处理故障现象：诺西端局CSGS45的单块ESB板故障，造成SCTP偶联的主通路中断，由于现网局间SCTP偶联均配置了双通路，单块ESB板故障并不会导致局间SCTP 偶联中断。
而实际情况是，CSGS45至中兴局向部分SCTP偶联中断，而到华为局向和其他诺西局向的SCTP偶联均正常，也就是说SCTP的双通路并未起到保护作用，对此，我们进行了分析，并排除了故障。
原因分析：分析判断可能原因：1、备用通路不通2、诺西端局硬件或配置问题3、中兴端局硬件或配置问题原因排查：SCTP（STREAM CONTROL TRANSMISSION PROTOCOL 流控制传输协议）能在两个端点之间提供稳定、有序的数据传递服务，在SIGTRAN协议的应用中，SCTP上层用户是SCN 信令的适配模块（如M2UA、M3UA），下层是IP网。
偶联实际上是在两个SCTP端点之间建立的连接关系，任何时刻两个SCTP 端点之间能且仅能建立一个偶联。
通路则是一个端点将SCTP分组数据发送到对端端点特定传送地址的路由。
在现网中，如下图1所示，两个端局之间配置了4个偶联，每个偶联具有主备两条通路，并采用了心跳机制，即当某条通路空闲时，本端端点会生成相应的心跳消息并通过该空闲通路发送到对端端点，而对端端点收到消息后将立即发回对应的心跳确认消息。
该机制被用来随时监视偶联通路的可用情况，当某一条通路故障时，数据传送将立即切换到另一条通路上，以此来保持SCTP偶联的可靠性和稳定性。
通路1图1 局间偶联示意图图2 诺西端局偶联配置示意图如上图所示，诺西端局的偶联建立在GISU板上，每一块GISU板对应一个偶联。
每个偶联的两条通路分别通过两块ESB板连接直IP承载网，进而与对端局相连。
本次故障起因为ESB1板故障，但单块ESB板故障只会导致偶联2条通路中的1条通路中断，根据偶联的心跳机制，数据传输将立即切换到另一条通路上，整个偶联将不会受影响。
各类故障原因分析
各类故障原因分析各类故障告警归类：1）设备、板卡故障：2M头子故障、控制面板、GPS暂时不能锁星，20DB耦合器坏、4G,熔丝烧了2）停电引起：设备供电恢复、空开跳闸、该点业主电力检修引起，现来电后恢复。
学校放假，POP已改停用3）环境原因：微波故障，天气恶劣引起4）不明原因、误告警：闪断告警、瞬断告警、嘉兴信产产生的告警（假告警）、接口无业务、用户频繁注册引起、轮巡后恢复、直放站版本过低。
5）隐性故障重启后恢复：网优重启设备引起、平台刷新后恢复、重新插拔监控卡、拉起后恢复、传输重新倒换电路后恢复正常。
6）工程原因、割接设备：下挂RRU退服引起，现已恢复。
施工队施工引起、电力改造断电、设备拆除、扇区不在使用、电力施工引起停电、离线测试、与联通共站，准备搬迁，POP停用, 设备测试7）室内分布故障：低噪过高引起设备离线8)升级、割接其他工程原因：设备例测引起、TM设备下电退网引起、省公司已删除HSTP到杭州TSH1的信令路由，因此有告警、已不用9)本地光缆的设备、板卡故障：更换整流模块，更换尾纤。
10)接头接触不良：头子松动、2M虚焊、7/8馈线头子故障引起11）2M出租，传输线路故障：2M线断了、传输故障12)13)光缆故障：光缆改道14)光功率异常：光路衰耗告警已恢复正常、经过光路部门处理后到设备尾纤处衰耗为-11db，设备已恢复正常。
15）站点还未开通、工程调测中：站未投点、此站为闭站状态、扇区人工闭塞状态，网优在调整。
16）固网软交换：系统负荷高、系统性能告警故障：话务量承载过高,性能QoS轻微告警,信令负荷性能门限阀值告警，不影响业务，无需处理。
18 系统数据出错：同步当前告警恢复、数据表CRC校验错误，重新校验后正常。
19) 天线问题：GPS蘑菇头松动20）市政、业主：21）（交换）非本端故障：用户关设备引起、参数配置错误引起,对端设备故障。
一、SCTP偶联重传超过阈值——承载网导致的瞬间重传比例增大。
SCTP偶联断告警处理总结
➢故障处理经验案例---SCTP偶联断告警处理总结使用建议：在阅读本文档的同时参阅如下资料：故障现象描述LTE基站上报"SCTP偶联断"告警，在告警详细信息中的附加文本会提示具体偶联号。
可能伴随的相关告警有：网元断链告警、基站退出服务（基站上报）、TD NodeB退服告警（RNC上报）、S1断链告警、X2断链告警。
故障分析排查思路一、确定具体SCTP偶联号及类型。
在告警详细信息的“附加文本”指示具体偶联号。
目前LTE基站存在3类偶联：TDS基站与RNC的SCTP偶联、LTE基站与EPC的SCTP偶联、LTE基站与LTE基站之间的SCTP偶联。
二、在基站端、OMC服务器、核心网侧做ping检测。
LTE使用IP分组传输技术，出现传输类故障时可以通过ping方法定位故障节点。
下图是LTE 双模基站IP传输逻辑图。
LTE双模基站IP传输逻辑图双模基站配置有3个IP，分别是基站维护IP、基站LTE业务IP、基站TDS业务IP。
可在配置表中的“SCTP参数配置”中确定哪两个IP分别用于TDS业务和LTE业务，在“OMC通道”配置项中确定哪个IP用于基站维护。
三、检查对应SCTP偶联本端（基站侧）、PTN传输、SCTP偶联对端（EPC/RNC/基站）配置是否正确。
图（1）SCTP参数配置图图（2）OMC通道配置图故障排查方法1)ping包检测故障节点EDMS ping包检测界面见下图所示。
图（3）Ping包检测界面“Ping基站网关”右侧下拉列表中的地址都需要保证能ping通，不通的话说明对应传输链路故障。
双模基站有3个网关，分别是TDS网关、LTE网关、维护网关。
LTE单模基站没有TDS网关。
对于特定基站，ping基站网关时实际ping 的就是图（4）中"172.39.1.1"、“100.64.36.129”、“100.92.36.129”这三个地址。
“Ping OMC服务器”功能可以检测基站到网管服务器之间链路状态。
智能网告警预处理方法（东信北邮）
进行派单， 并电话通 知维护人 员。
进行派单， 并电话通 知维护人 员。
SCP5 至 STP 共
32 条 LNK ，
SCP31/32 至
STP 各开 32 条， SCP61/62 至
STP 分别 32 条
/16 条 。 根 据
LINK 中断的条
控制要低一 些
当前 SCF 进 当前 SCF 单个 scf 进程 不需要干预，系 不 需 要 派 无
程 的 日 志 文 进程的日 的 日 志 文 件 统 会 自 动 进 行 单
件过长
志文件过 超 过 一 定损过高
呼损过高
当一定时间 内呼叫失败 数超过一定 门限时出现 此告警
如果此告警只 如 果 频 繁 是偶尔出现，可 出 现 则 需 以不进行干预， 要 联 系 维 如果出现频繁 护 人 员 查 则 需 要 检 查 系 找原因，并 统 及 与 系 统 连 进行派单。 接的实体是否 正常
SCP 与 网 管 前置机物理 连接中断，或 是网管进程 存在问题。
SMP 与 网 管 前置机物理 连接中断，或 是网管进程 存在问题。
cpu 负荷超过 门限
对于此类告警 监控人员通过 在主机 上 ping 对端 ip， 以及 traceroute 对端 ip 来判断 是否 为物理连接问 题。如果物理连 接正常，请查看 网管进程是否 运行正常。 对于此类告警 监控人员通过 在主机 上 ping 对端 ip， 以及 traceroute 对端 ip 来判断 是否 为物理连接问 题。如果物理连 接正常，请查看 网管进程是否 运行正常。 观察是否有进 程占用 CPU 很 高，不用做预处 理
9、中兴通讯LTE产品常见故障处理
> 内部公开
常用维护方法（3）
8. 仪器仪表测试分析 利用仪器仪表可测量系统的运行指标、环境指标、链路状况、无线 指标，将测量结果与正常情况下的指标进行比较，分析产生差异的 原因。经常使用的仪器仪表有万用表、驻波比测试仪、频谱仪。
© ZTE Corporation. All rights reserved.
> 内部公开
抓包工具——Wireshark使用介绍
2. 在弹出的对 话框内，选 择网卡和过 滤条件后， 点击Start按 钮。
© ZTE Corporation. All rights reserved.
目录
1
故障处理概述
2 常用工具介绍
3 典型故障分析
—传输 —时钟 —光口类 —RRU&RTR —网管
> 内部公开
网元与网管断链
• 故障现象 基站出现前后台断链或一直无法正常建链的问题。
• 故障原因 引起前后台断链的原因很多，主要如下几类：
1. 基站带宽资源配置太小导致前后台断链； 2. OMMB配置中心与网元通讯IP配置错误导致前后台不建链； 3. OMC后台基站数据配置错误导致前后台不建链：
• 故障原因 1. 单板锁相环工作异常； 2. 硬件故障； 3. 锁相环无参考时钟输入或参考时钟质量太差； 4. 输入方向的IQ链路失锁。 • 故障处理
该故障一般可以通过复位、拔插单板的方法进行处理，若复位拔插无法恢 复告警，则需更换故障单板。
© ZTE Corporation. All rights reserved.
192.254.2.16(槽2) RRU IP:
X2切换 - X2及相关SCTP链路告警分析
X2及相关SCTP链路告警分析1 现象描述现网不断出现SCTP及X2链路故障告警。
2 告警信息告警描述：告警ID：25888 SCTP链路故障告警和29204 X2接口故障告警现网一直出现不能消除的不影响业务的告警。
3 原因分析1、对端没有添加X2 Interface导致本端的SCTP链路告警。
2、两端的小区有不可用小区导致X2链路不通告警。
3、在网管上ping测试，由本端ping对端X2的IP，查看是否传输不通。
4、查看X2链路的本端和对端IP与SCTP链路配置是否一致。
4 处理过程1、目前现网的X2是通过SON 自建立的模式，正常的情况不用手动添加X2Ineterface。
不存在对端未添加的问题。
2、怀疑是自建立的X2链路有问题，让其重新自建立，于是试点删除一个站点的本对端X2接口，第二天有用户接入时自建立，又重新出现X2告警和对应的SCTP 链路故障告警。
3、如果一端小区闭塞或者小区不可用，也会出现X2告警，因为两端链路建立失败，但是通过DSP CELL查询本端和对端的所有小区的状态都属于正常状态，所以也排除了小区不可用的可能。
4、通过在网管上LST SCTPLNK，通过Ping命令ping X2链路所属的本端到对端的IP地址，发现无法Ping通。
于是查询本端和对端的SCTP LINK，比对后确定两端都有相对应的SCTP链路，而且IP地址没有错误。
DSP SCTPLNK:;+++ 2013-10-29 14:54:46O&M #143921%%/*39587941*/DSP SCTPLNK:;%%RETCODE = 0 执行成功查询SCTP链路状态----------------链路号柜号框号槽号本端第一个IP地址本端第二个IP地址本端SCTP端口号对端第一个IP地址对端第二个IP 地址对端SCTP端口号出流数入流数工作地址标识闭塞标识SCTP链路状态状态改变原因状态改变时间0 0 0 6 100.83.143.46 0.0.0.0 36412 100.83.255.1 100.83.255.2 36412 17 17 主路径解闭塞正常正常2013-09-25 16:23:461 0 0 6 100.83.143.46 0.0.0.0 36412 100.83.143.53 0.0.0.0 36412 0 0 主路径解闭塞断开链路故障2013-10-16 13:51:272 0 0 6 100.83.143.46 0.0.0.0 36412 100.83.143.68 0.0.0.0 36412 17 17 主路径解闭塞正常正常2013-10-16 13:51:45(结果个数= 3)--- ENDDSP SCTPLNK:;+++ 2013-10-29 14:54:46O&M #136471%%/*39587945*/DSP SCTPLNK:;%%RETCODE = 0 执行成功查询SCTP链路状态----------------链路号柜号框号槽号本端第一个IP地址本端第二个IP地址本端SCTP端口号对端第一个IP地址对端第二个IP 地址对端SCTP端口号出流数入流数工作地址标识闭塞标识SCTP链路状态状态改变原因状态改变时间0 0 0 6 100.83.143.53 0.0.0.0 36412 100.83.255.1 100.83.255.2 36412 17 17 主路径解闭塞正常正常2013-09-27 10:41:011 0 0 6 100.83.143.53 0.0.0.0 36412 100.83.143.68 0.0.0.0 36412 17 17 主路径解闭塞正常正常2013-10-16 13:51:282 0 0 6 100.83.143.53 0.0.0.0 36412 100.83.143.46 0.0.0.0 36412 0 0 主路径解闭塞断开链路故障2013-10-16 13:51:28(结果个数= 3)--- END5、那么如果配置和小区状态都是合理的，而且可以Ping通，但是链路却是断链的，最有可能的就是PTN所配置的X2传输不通，于是找到传输PTN端，与传输沟通后发现可能是ARP自动学习动能所导致的。
常见传输告警处理
问题/告警解释 传输的物理层有问题
传输的物理层有问题
E1/T1信号丢失告警
传输的物理层有问题 E1/T1线路AIS告警 传输的物理层有问题
E1/T1帧失步告警 传输的物理层有问题 E1/T1滑帧告警 传输的物理层有问题 E1/T1环回故障 E1/T1高误码率门限告警 E1/T1高误码率告警 IMA组配置失败告警 传输的物理层有问题 传输的物理层有问题 传输的物理层有问题 传输的链路层有问题
SCTP链路断开告警
解决步骤 一般是E1链路不通导致，工程上先排查E1 1. 一般是E1链路不通导致，工程上先排查E1； 2. 检查E1远端链路状态。 1. 一般是E1链路不通导致，工程上先排查E1，确保E1物理链路 正常； 2. 该告警表明无接收信号，需要检查RNC和NODEB配置： 1）确认是E1还是T1； 2）帧格式是否一致； 3）编码格式是否一致。 3. E1要排除错接的情况。 一般是E1链路不通导致，工程上先排查E1 1. 一般是E1链路不通导致，工程上先排查E1； 2. 该告警表明E1链路上帧同步丢失，能够接收信号，但E1数据帧 同步不上，需要检查链路上的干扰问题。 1. 一般是E1链路不通导致，工程上先排查E1； 2. 该告警是由时钟不同步引起的，RNC默认是主，NODEB侧为 从。 1. 由于E1做环路导致，需要去环； 2. 之后需要在RNC和NODEB侧进行RST IMAGRP的操作。 一般是E1链路不通导致，工程上先排查E1 一般是E1链路不通导致，工程上先排查E1 检查IMA配置或者重启MPTA 1. 一般由E1引起，E1链路恢复，该告警即可恢复； 2. 如果E1状态正常，则需要检查RNC和NODEB侧IMA配置是否 一致； 3. 如果一致，需要确认在RNC和NODEB进行对接中，如果RNC 和NODEB已经进行了协商，之后是否E1被物理插拔过，并在 RNC侧执行RST IMAGRP把IMA组状态恢复正常。 1. 一般由E1引起，E1链路恢复，该告警即可恢复； 2. 如果E1正常该告警仍然不恢复，则需要检查： 1）RNC和NODEB侧配置是否一致； 2）是否存在错接情况； 3）是否存在1组IMA和多组IMA相连接的情况，例如RNC侧为1 个IMA组，而NODEB侧为多个IMA组； 4）确认IMA组本端无环回。 3. 在RNC侧执行RST IMAGRP把IMA组状态恢复正常。 1. 一般由E1引起，E1链路恢复，该告警即可恢复； 2. 如果E1正常该告警仍然不恢复，则可能IMA组里有多条链路， 但是链路质量不同，可以通过剔除某个链路来排查相关链路质 量； 3. 在RNC侧执行RST IMAGRP把IMA组状态恢复正常。 1. 一般是E1链路不通导致，工程上先排查E1； 2. 如果E1状态正常，则需要检查RNC和NODEB两侧配置的最小 激活链路数，该值默认是1。
SCTP偶联断告警处理总结
➢故障处理经验案例---SCTP偶联断告警处理总结使用建议：在阅读本文档的同时参阅如下资料：故障现象描述LTE基站上报"SCTP偶联断"告警，在告警详细信息中的附加文本会提示具体偶联号。
可能伴随的相关告警有：网元断链告警、基站退出服务（基站上报）、TD NodeB退服告警（RNC上报）、S1断链告警、X2断链告警。
故障分析排查思路一、确定具体SCTP偶联号及类型。
在告警详细信息的“附加文本”指示具体偶联号。
目前LTE基站存在3类偶联：TDS基站与RNC的SCTP偶联、LTE基站与EPC的SCTP偶联、LTE基站与LTE基站之间的SCTP偶联。
二、在基站端、OMC服务器、核心网侧做ping检测。
LTE使用IP分组传输技术，出现传输类故障时可以通过ping方法定位故障节点。
下图是LTE 双模基站IP传输逻辑图。
LTE双模基站IP传输逻辑图双模基站配置有3个IP，分别是基站维护IP、基站LTE业务IP、基站TDS业务IP。
可在配置表中的“SCTP参数配置”中确定哪两个IP分别用于TDS业务和LTE业务，在“OMC通道”配置项中确定哪个IP用于基站维护。
三、检查对应SCTP偶联本端（基站侧）、PTN传输、SCTP偶联对端（EPC/RNC/基站）配置是否正确。
图（1）SCTP参数配置图图（2）OMC通道配置图故障排查方法1)ping包检测故障节点EDMS ping包检测界面见下图所示。
图（3） Ping包检测界面“Ping基站网关”右侧下拉列表中的地址都需要保证能ping通，不通的话说明对应传输链路故障。
双模基站有3个网关，分别是TDS网关、LTE网关、维护网关。
LTE单模基站没有TDS网关。
对于特定基站，ping基站网关时实际ping的就是图（4）中""、“、“这三个地址。
“Ping OMC服务器”功能可以检测基站到网管服务器之间链路状态。
“Ping”功能可以实现“以一个基站本地IP为源端ping任意一个目的IP”功能，比如ping LTE核心网IP、PTN设备IP。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
➢故障处理经验案例---SCTP偶联断告警处理总结使用建议：在阅读本文档的同时参阅如下资料：故障现象描述LTE基站上报"SCTP偶联断"告警，在告警详细信息中的附加文本会提示具体偶联号。
可能伴随的相关告警有：网元断链告警、基站退出服务（基站上报）、TD NodeB退服告警（RNC上报）、S1断链告警、X2断链告警。
故障分析排查思路一、确定具体SCTP偶联号及类型。
在告警详细信息的“附加文本”指示具体偶联号。
目前LTE基站存在3类偶联：TDS基站与RNC的SCTP偶联、LTE基站与EPC的SCTP偶联、LTE基站与LTE基站之间的SCTP偶联。
二、在基站端、OMC服务器、核心网侧做ping检测。
LTE使用IP分组传输技术，出现传输类故障时可以通过ping方法定位故障节点。
下图是LTE 双模基站IP传输逻辑图。
LTE双模基站IP传输逻辑图双模基站配置有3个IP，分别是基站维护IP、基站LTE业务IP、基站TDS业务IP。
可在配置表中的“SCTP参数配置”中确定哪两个IP分别用于TDS业务和LTE业务，在“OMC通道”配置项中确定哪个IP用于基站维护。
三、检查对应SCTP偶联本端（基站侧）、PTN传输、SCTP偶联对端（EPC/RNC/基站）配置是否正确。
图（1）SCTP参数配置图图（2）OMC通道配置图故障排查方法1)ping包检测故障节点EDMS ping包检测界面见下图所示。
图（3）Ping包检测界面“Ping基站网关”右侧下拉列表中的地址都需要保证能ping通，不通的话说明对应传输链路故障。
双模基站有3个网关，分别是TDS网关、LTE网关、维护网关。
LTE单模基站没有TDS网关。
对于特定基站，ping基站网关时实际ping 的就是图（4）中"172.39.1.1"、“100.64.36.129”、“100.92.36.129”这三个地址。
“Ping OMC服务器”功能可以检测基站到网管服务器之间链路状态。
“Ping”功能可以实现“以一个基站本地IP为源端ping任意一个目的IP”功能，比如ping LTE核心网IP、PTN设备IP。
“Ping基站网关”和“Ping OMC 服务器”是“Ping”的一个功能子集。
提示:1. EDMS提供了三种ping包功能：ping基站网关、ping omc服务器、ping特定IP。
后台人员ping包检测方法A、t elnet登录OMC服务器，IP地址为OMC服务器地址；B、telnet登录基站，IP地址为基站管理网元IP地址；C、进入Ushell；D、P ad到MGR.EXE进程；E、使用“brsping”指令ping远端IPF、操作实例见下：-bash-3.2$ telnet 100.92.1.181 //telnet到基站正在尝试...连接到 100.92.1.181。
换码字符为 '^]'。
(none) login: zte //输入基站用户名及密码Password:Processing /etc/profile... Done# ushell //进入ushell-> Please input password!->***-> Login success!!ushell tool menu:------------------------------------------------------------------------------'ps' or 'PS' list process run on the board'pr xxx' or 'PR xxx' take over xxx process printf info'npr xxx' or 'NPR xxx' not take over xxx process printf info'db xxx' or 'DB xxx' debug xxx process printf info'ndb xxx' or 'NDB xxx' not debug xxx process printf info'pad xxx' or 'PAD xxx' debug and take over xxx process printf info'npad xxx' or 'NPAD xxx'not debug and take over xxx process printf info'pall' or 'PALL' display current debug and take over info'ncheck' or 'NCHECK' Do not check another ushell exist'check' or 'CHECK' Do check another ushell exist'Q' or 'q' cancel all process debug and printf info'exit' or 'EXIT' cancel ushellxxx is process id you want to debug or take over printf info ------------------------------------------------------------------------------ $$ps //显示进程及对应PIDPID USER VSZ STAT COMMAND1 root 1304 S init2 root 0 SW [softirq-high/0]3 root 0 SW [softirq-timer/0]4 root 0 SW [softirq-net-tx/]5 root 0 SW [softirq-net-rx/]6 root 0 SW [softirq-block/0]7 root 0 SW [softirq-tasklet]8 root 0 SW [softirq-sched/0]9 root 0 SW [softirq-hrtimer]10 root 0 SW [softirq-rcu/0]11 root 0 SW [watchdog/0]12 root 0 DW [chkeventd/0]13 root 0 SW< [events/0]14 root 0 SW< [rt_events/0]15 root 0 SW< [khelper]16 root 0 SW< [kthread]17 root 0 SW< [rt_kthread]37 root 0 SW< [kblockd/0]42 root 0 SW< [khubd]83 root 0 SW [pdflush]84 root 0 SW [pdflush]85 root 0 SW< [kswapd0]86 root 0 SW< [aio/0]621 root 0 SW [mtdblockd]678 root 1254m S /MGR.EXE //ping检查需要pad的进程MGR.EXE680 root 9156 S /tftp683 root 1304 S telnetd685 root 1312 S inetd686 root 1312 S -/bin/./ash697 root 0 SWN [jffs2_gcd_mtd0]854 root 457m S /Product_lte_tdd.so 90 93 V3.10.10P30R1 /AGT_LTE_TDD.EXE885 root 349m S /Product_td.so 91 139 TDS_V330501P03 /AGT_TD.EXE1204 root 1316 S -sh1205 root 1332 R ushell1206 root 1332 S ushell1207 root 1332 S ushell1208 root 1304 R sh -c ps1209 root 1308 R ps$$pad 678 //pad 到MGR.EXE进程[678]ushell enter print modushell enter debug mod //系统提示pad成功$$brsping "172.36.1.1" //进行ping检测，注意字母及格式。
此处ping TDS网关2)后台人员检查基站侧数据配置是否正确3)TDS配置参数检查4)LTE配置参数检查5)传输人员检查相应传输链路是否正常6)后/前台人员与传输人员核对传输物理位置及参数配置是否一致故障排查步骤如果基站同时上报“网元断链告警”，则先处理网元断链告警，处理完网元断链告警后再处理SCTP偶联告警。
基站断链故障处理方法请参考《网元断链告警处理手册》。
在“SCTP偶联断”告警详细信息的附加文本中确定具体断链偶联号及偶联类别，据此选择如下对应方法处理。
一、TDS SCTP偶联故障1.1、在前台/后台进行ping包检测。
前台使用EDMS的“Ping基站网关”功能，ping TDS网关；后台登录基站使用brsping TDS网关。
如果ping不通，进入1.2步。
如果能ping通则跳到1.3步继续检查。
1.2联系传输后台，询问基站至RNC整条传输是否有故障，保证中间传输设备的正常。
1.3、检查基站侧VLAN、IP、SCTP等TDS偶联相关参数配置。
检查项如下图（n）至图（m）所示。
图（4）IP层配置-列表图（5）TDS SCTP参数配置图（6）TDS IP参数图(7)DS VLAN参数1.4、检查RNC侧VLAN、IP、SCTP端口等RNC侧相关传输参数图（8）“IPPORT配置”接口信息图（9）“IPPORT配置”SUPERVLAN成员口配置信息图（10）“Iub局向配置”基本信息图（11）“Iub局向配置”传输路径信息图（12）“Iub局向配置”IP配置信息图（13）“Iub局向配置”NBAP链路信息图（14）“IP路径组配置”信息1.5、与传输核对TDS传输参数是否一致。
核对的参数包括PTN设备ID、槽位号、端口号，TDS VLAN。