当前位置：文档之家 › SCTP偶联断告警处理总结

SCTP偶联断告警处理总结

  • 格式：docx
  • 大小：3.29 MB
  • 文档页数：15

➢故障处理经验案例---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。

合集下载

X2告警处理总结

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网络设备常见故障处理

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闪断经验总结

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）间接口链路（链路层）数据 收发异常时，产生此告警。