S1断链告警处理案例
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通则联系传输后续
VOLTE异常事件典型案例分析
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。
此处属于测试软件问题，应该予以剔除。
（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。
2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。
S1链路漏配导致切换成功率低问题处理
S1链路漏配导致切换成功率低问题处理摘要：S1链路漏配导致切换成功率低问题处理。
关键字：漏配S1【故障现象】：日常指标监控时发现市区瓜果市场北侧两个站点TL-市区-烟草公司广告牌的3小区和TL-市区-瓜果市场的1小区的同频切换失败率分别高达36.12%和29.48%，其余指标正常。
【告警信息】：查询基站TL-市区-烟草公司广告牌和TL-市区-瓜果市场内均无故障告警，小区状态正常。
【原因分析】：出现此类问题的大致原因：1.外部小区信息配置错误；2.切换参数配置错误；3.干扰4.传输链路异常；具体处理步骤：1.首先核查问题小区外部信息，确认无任何异常。
2.使用PEAC平台进行站点参数对比核查，切换参数与正常站点设置一致。
3.查询站点上行干扰站点无干扰，核查工参信息，站点无明显MOD3干扰对打问题。
4.核查问题站点传输链路，发现站点配置4条S1传输链路，并且传输链路正常。
5.取全网两两小区切换指标，发现这问题站点主要都是往TL-市区-豪邦康-HFTA-449019-55小区切换时失败的。
6.核查TL-市区-豪邦康站点状态，发现该站点S1链路只有1条，漏配一条传输，导致周围站点使用第2条传输切换过来时全部失败。
根因与工程督导联系说明此情况，督导反应前期核心网增加MME时，批量增加过传输链路，该站点断链无法增加传输链路，近期站点恢复未及时增加传输导致周围站点切换失败较高。
【解决方法】：TL-市区-豪邦康站增加一条传输链路后，切换到该站点指标恢复正常。
原问题小区指标也恢复正常，问题得到解决。
【经验教训或建议与总结】：为了避免此情况发生，督导后期会定期核查因断站导致无法及时修改参数的问题，避免因类似问题导致全网指标恶化。
MME地址错误导致S1切换全部失败处理
名称： MME地址错误导致S1切换全部失败
问题描述：
2014年8月28日指标监控时发现，云浮云安西边D-DLH与周边站点的S1切换全部失败，全天各个时段都有一定次数的S1切换失败，影响整体切换指标。
问题分析：
查看多个CDL日志发现，切换失败均发生在云浮云安西边D-DLH与周边站点的切换上，且云浮云安西边D-DLH与其他基站间的所有切换都为S1切换，且切换全部失败。
该基站前几日处于断链状态，到27日晚才恢复，站点起来后指标与其他基站切换指标就出现问题，因此主要核查该基站告警及参数配置情况。
1.查看目标小区状态正常，无告警；
2.核查邻区参数配置无误；
3.查看多个CDL日志，发现和目标小区的所有切换均通过S1链路，且均失败，CDL看，源小区发送S1 Handover Required后，EPC回复S1 Handover Preparation Failure，携带的消息为核心网原因导致S1切换出准备失败，怀疑是否为核心网传输方面出现问题；
4.联想到在这几天进行新MME割接，而云浮云安西边D-DLH前几日均处于基站断链退服状态，因此登录到目标基站查看路由关系，发现云浮云安西边D-DLH站的MME地址仍使用MME割接前的地址100.6
5.254.203/204，而割接完后的新MME应为100.65.254.209/210；
解决措施：
将云浮云安西边D-DLH基站MME地址由原来的100.65.254.203/204修改为割接完后的新地址100.65.254.209/210后，指标恢复正常。
现网仍存在7个传输断连导致无法完成新MME割接的站点，后续将做好跟踪，在故障处理好
后第一时间完成MME割接，避免对全网切换指标造成影响。
中国铁塔动环常见告警处理指导手册
中国铁塔动环常见告警处理指导手册第一篇：中国铁塔动环常见告警处理指导手册中国铁塔动环常见告警处理指导手册一、FSU离线告警告警名称：FSU离线；告警解释：FSU和铁塔集团平台连接通讯中断；原因分析：1）信号差或不稳定；2）FSU设备掉电；3）无线模块硬件故障；4）FSU设备硬件故障；5）天线和无线模块连接中断，或天线丢失；6）VPN服务器连接不上；7）SIM卡被盗、欠费或故障。
平台处理方法：查询历史告警记录，如频繁离线或长时间离线，需现场检查。
现场处理方法：第一步检查供电：1）在运维监控系统检查离线站点是否有停电告警，判断是否现场停电；2）现场检查FSU指示灯不亮设备没有供电。
原因分析：FSU供电异常。
解决方案：1）检查整个基站是否停电，如停电则通知相关人员取电；2）检查FSU供电空开是否跳闸及通电线路是否正常。
第二步检查无线模块：检查无线模块指示灯都不亮或都常亮。
原因分析：无线模块供电异常或无线模块故障。
解决方案：1）无线模块供电故障，则检查给无线模块供电接线是否正常如正常，则用万用表测量给无线模块供电FSU输出端是否有12V，如没有则为FSU供电板问题，更换FSU供电板。
2）确认供电正常，则更换无线模块进行测试。
下站建议：下站时建议随身带上一套可以成功拨号的无线网卡和SIM卡，下站的时候作对比验证，快速确认是SIM卡问题，还是无线模块问题。
第三步FSU检查通过EISUConfig软件登陆FSU设备，点击设备诊断管理。
1）信号强度弱：通过设备软件登录设备，如信号强度小于15。
解决方案：更换运营商无线模块或将天线外延（室内站放到室外，室外柜放到底部隐蔽区域或有外层保护情况下放到机柜顶部）2）铁塔VPN网络连接异常：铁塔VPN网络提示连接异常3）铁塔网管未注册：铁塔网管提示连接异常（正常显示连接正常）解决方案：确认总部平台正常，重启FSU（等待程序连接）。
如重启后未恢复，联系厂家专业人员。
平台恢复确认：告警管理-活动告警监控-当前告警查询该站点，确认告警是否消除。
LTE常见故障总结
故障总结目录故障总结 (1)告警部分 (2)1.System module failure (0010) (2)2.BTS reference clock missing (1898) (3)3.Configuration error: Unit initialization failure (0012) (3)4.Configuration error: Not enough HW for LCR (1868) (3)5.Configuration error: Power level not supported (4008) (4)6.Cell configuration data distribution failed (6253) (4)7.Failure in optical RP3 interface (4064) (4)8.Failure in optical RP3 interface (0010) (5)9.Baseband bus failure (3020,1906) (5)10.RF module failure (6259，1911、1711、1712) (5)11.Cell power failure (4090) (6)12.GPS Receiver alarm: Control Interface not available （4011） (7)13.X2 interface setup failure（6304） (7)14.Transport layer connection failure in X2 interface (7)15.Failure in replaceable baseband unit (7)16.Temperature alarm(0002) (8)17.VSWR（1838） (8)18.Failure in optical RP3 interface (2004) (8)19.GPS时钟盒闪断，时钟信号不正常，无法识别RRU (9)20.Failure in optical RP3 interface（2000） (9)21.光纤交叉连接 (9)22.基站始终无法建立S1连接，只到configed状态 (9)23.某一个小区的RRU无法识别 (10)24.BBU版本无法识别 (11)26.校准初步排查 (11)27.本地IP地址和路由正常，ping不通MME和网关 (12)28.TRS文件始终无法生效 (12)29.远程ping不通基站（断链） (12)31.风扇告警 (13)32.BTSlog有link消息，但是pinger始终不亮 (13)34.pinger正常，但是SM里小区显示橙黄色告警 (13)36.FOSI 和FOSN的光功率范围 (13)38.MAC绑定及载波冲突 (13)39.传输不通 (14)40.升级完成后出现驻波告警 (14)案例部分 (14)特殊操作部分 (20)1、登录RRU 查看RRU光路状态。
网元断链告警处理案例
➢网元断链告警处理案例1.故障现象描述✧在双模站点开通过程中，部分站点在初期会有断链情况。
告警显示“网元断链告警（198099803）”这样的话，后台就无法监控到断链站点的状态。
2.故障分析排查思路1、只有个别基站在所属网管服务器上面断链，可以排查网管服务器故障；2、大批基站集中断链，可以排除基站本身硬件、供电故障；3、如果个别站点在正常运行，排除基站无硬件、供电故障后，出现断链，一般为传输问题，需要联系移动传输室来联合排查定位；3.传输网络结构介绍✧LTE基站OMC维护网络从IP传输网络架构来看，可分为3段，依次是：基站------基站网关------网管服务器网关------网管服务器。
整个传输网络结构如下图所示：4.网元断链故障处理流程5.故障排查总结通过上述的排查总结如下：1、首先确认BBU设备是否运行正常，站点传输设备是否正常，基站供电系统是否正常。
2、然后检查下站点的配置数据，确保站点配置无误，可能由于传输割接导致站点断链。
网管配置参数如下图所示：网元中配置的OMC操作维护地址：基站传输网络→IP传输→IP层配置中的OMC操作维护地址：基站传输网络→IP传输→OMC链路服务器地址：3、关于ping命令，有两种使用情况：a)从后台ping前台基站的话：直接在网管服务器上：ping ip地址。
b)从前台基站上ping后台服务器：需要通过使用LMT工具来，下面简单介绍其使用方法：启动EDMS登录基站---Ping包检测—设置ping的包大小，次数及相应的IP地址---再点击对应的按钮开始测试。
Ping包检测开始后，会在ping包信息区域显示每次ping包的详细信息。
Ping包结束后，会在ping包统计区显示统计信息，包括是否存在丢包、延时等等。
无线网络问题处理
➢GNSS天馈连接线缆异常 ➢GPS天馈方向有建筑物阻挡 ➢周边环境存在干扰
排查思路：
➢检查配置数据GPS配置是否生效 ➢检查GNSS天馈线缆连接正常，且GPS天线安装符合工程规范 ➢通过扫频仪查看周边是否存在GNSS干扰源 ➢采用电压和电阻测量法检查物理链路质量 ➢复位基站CC单板
电压测量法：
4 DHCP服务器回送确认 单播报文DHCP Ack 确认IP地址可用
© ZTE Corporation. All rights reserved
维护通道问题处理步骤2
第二步：检查传输DHCP Relay配置
➢如果基站侧DHCP Discover消息发出， SUSE系统服务器没有收到相应的报文，确定 是传输没有把DHCP Discover消息送达到服务器上
第二步：选择对应网元告警
第三步：双击告警，查看具体信息
第四步：查看告警处理建议
© ZTE Corporation. All rights reserved
传输配置问题处理思路
： 故障现象 S1断链告警（198094420）
原因分析：
➢S1建链失败 ➢下层承载SCTP链路中断
排查思路：按照协议栈逐层排查，协商数据一致性检查
➢天馈驻波比异常（198098465） ➢GNSS天馈链路故障(198096836) ➢GNSS接收机搜星故障(198096837) ➢没有可用的空口时钟源(198092217)
© ZTE Corporation. All rights reserved
课程内容
传输维护问题处理思路 设备硬件问题处理思路 综合业务问题处理思路
故障现象：RRU功率检测异常(198098472) 原因分析：
➢基带处理单板问题 ➢RRU软硬件问题 ➢光纤、跳线附属器件问题
(完整版)TD-LTE故障处理手册及典型案例
批量基站断站或小区不可用
●常见处理方法
序号
处理方法
“是”
“否”
1
联系传输人员，看是否为传输设备故障
4
2
2
联系代维人员确定基站是否断电
5
3
3
联系代维人员确定基站是否为双模基站并确定TD测GPS完好
5
4
通知传输人员处理
6
5
通知代维人员处理
6
6
结束
二.告警预处理告警分类
1.实时告警分类总表
告警等级
5
5
结束
查询GPS情况：
查询GPS问题是否是有单板故障问题引起：
●提示
eNodeB大部分取得时钟为对端（及TD测），现网大部分为GPS，当前时钟状态为不可用时，可判断GPS问题，需上站检查GPS。
●关于License的下发遵守的规则：
TD：
LTE：
典型案例
1、光模块速率问题导致小区服务能力下降告警
现象描述：
9
4
4
DSP BRD，看是否有RRU故障（基站侧可直接查看RRU是否掉电）
9
5
5
DSP SFP查询不可用RRU对应的光路是否OK（基站侧可看指示灯是否正常）
9
6
6
DSP CLKSRC查看当前使用的时钟,如是GPS ,DSP GPS查看当前收星情况（基站侧直接查看GPS是否开路或登录基站查看）
9
7
7
查看是否有系统无License运行告警、
8
6
6
DSP SFP查看光模块型号是否满足LTE需求（基站侧可直接查看）光模块大于6.144G。
7
8
7
S1断链告警处理案例
S1断链告警处理案例S1断链告警处理指导1.故障现象描述告警管理中查看到基站上报“S1断链告警（0）”告警码，如下图所⽰：2.故障分析排查思路根据TD-LTE的⽹络接⼝协议，S1链路是建⽴在物理传输层、数据链路层、IP协议层、SCTP偶联链路之上的传输协议层，如下图所⽰：所以处理S1链路故障，需要从底层开始排查：1、⾸先排查站点是否存在传输告警，排除传输故障；2、其次基站IP地址配置是否正常；3、再次确认SCTP偶联断告警，排除SCTP偶联告警；4、最后排查是否存在S1 AP建⽴失败（协商失败或基站⽆⼩区），与核⼼⽹核对⼩区TAC值是否配置⼀致。
3.故障排查步骤1、查看基站告警，是否存在传输类相关告警，例如“⽹元断链告警”、“SCTP偶联断链”告警，若存在以上告警，需要先按照以上告警排查指导⼿册，先解决以上告警。
2、检查ENODEB------MME或SGW 路由IP地址是否配置正确；通过telnet命令登录到CC板，使⽤ BRS命令对MME及SGW地址进⾏PING包测试，详细登录⽅式如下，红⾊字体均需要输⼊：通过服务器远程登录：$ telnet 前台通过⽹线直连登录地址：正在尝试...连接到（）(none) login: zte（⽤户名）Password: zte（密码）Processing /etc/profile... Done# /ushell-> Please input password!->***（密码zte）-> 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 printfinfo'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 printfinfo------------------------------------------------------------------------------$$ps（查看前台进程）PID 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 1253m S /680 root 9156 S /tftp683 root 1308 S telnetd685 root 1312 S inetd686 root 1312 S -/bin/./ash697 root 0 SWN [jffs2_gcd_mtd0] 1201 root 457m S / 88 91 /1750 root 1316 S -sh1751 root 9216 R /ushell1753 root 1304 R sh -c ps1754 root 1308 R ps$$pad 678（登录到平台进程）[678]ushell enter print modushell enter debug mod$$brsping ""（ping核⼼⽹MME地址）[678][ begin to excel fun:brsping ]value = 0(0x0)[ end to excel fun:brsping ]Ping : find no route for dest, send by default gateway [0xac1e8fc1]. send ping seq: 1...$$[678]PING===>reply from packetsize=36 time=14ms.——正常ping通时返回的时长[678]send ping seq: 2...[678]PING===>reply from packetsize=36 time=4ms.[678]send ping seq: 3...[678]PING===>reply from packetsize=36 time=3ms.[678]send ping seq: 4...[678]PING===>reply from packetsize=36 time=24ms.[678]Ping statistics for Packets: Sent = 4, Received = 4, Lost = 0(0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 24ms, Average = 11ms（ping核⼼⽹MME控制⾯地址结果，丢包率0%，证明基站到MME链路正常。
S1链路故障导致掉线案例--爱立信核心网
问题描述（故障现象）组网环境问题原因分析问题解决方案由于掉线上报的原因为S1链路故障，初步认为是S1链路故障导致，同时这段时间通辽的退服基站、故障基站、传输问题导致的基站退服较多，因此筛选出了由于S1故障导致掉线次数较多的基站进行了检查，基站工程师反馈说这些基站状态正常，并且也从没有发生过告警，包括S1链路故障告警。
同时，联系了爱立信核心网确认是否在指标恶化的6月5日是否进行过什么操作，答复这两天没有对核心网做过任何操作。
然后请其对告警检查，爱立信核心网反馈了同样的信息，没有发现任何告警，包括S1故障告警。
从基站和核心网反馈的情况来看，这应该不是硬件故障之类的告警引起。
鉴于这种情况，提取了一周的小区级别数据进行了分析：几乎由于该原因导致的掉线每个基站都存在，其中有几个TOP小区次数较多，其余都是几十次或者十几次和几次的。
至此，我们开始怀疑是核心网的原因，由于核心网是异厂家，我们要拿出充分的证据才能去理论。
通过TOP小区筛选出几个由于S1故障掉线次数较多的小区进行跟踪，从基站侧跟踪到了掉线情况： UE GID为1127的用户在正常RRC连接态，基站向MME发送了“UE CONTEXT RELEASE QUEST",原因值为传输不可用，见下图：之后收到了核心网下发的“UE CONTEXT release command”，携带的原因值为DETACH。
见下图：由于是传输层原因不可用，我们从网管提取了E-RAB的情况进行分析：可以看出由于传输层问题导致的E-RAB异常释放次数较多，这是导致UE Context异常释放的主要原因。
根据3GPP 23.007协议中，对基站收到GTP error indication的处理定义如下，基站的实现符合协议标准。
因此需要爱立信确认为什么发起GTPU Error indication。
移动公司与核心网厂家爱立信沟通后答复：故障初步分析：由于EPG的U平面存在吊死的TEID导致的。
泰州-海陵西马南LF基站S1链路缺失导致异常切换案例
泰州-海陵西马南LF基站S1链路缺失导致异常切换案例
目录
一、案例背景 (2)
二、案例原因分析 (3)
2.1查询切换对 (3)
2.2查询基站状态 (3)
2.3查询基站指标情况 (3)
2.4查询GPS状态 (4)
2.5邻区一致性核查 (4)
2.6SCTP链路核查（LST SCTPPEER） (4)
三、案例涉及基本概念 (5)
3.1基站间切换方式 (5)
3.2切换基本流程 (5)
四、案例处理步骤 (7)
五、总结 (8)
一、案例背景
2016年3月13号泰州-海陵高校区LF4、泰州-海陵高校区LD1泰州-海陵北马庄LF3等小区切换成功率突发恶化，导致切换成功率陡降，影响小区指标情况。
网优3.0平台集中优化平台上报多条切换差小区任务工单。
泰州-海陵高校区LF4等小区小时级指标
泰州-海陵高校区LF4等小区位置。
LTEeNodeB-FDD基站S1断链告警故障分析和处理案例
LTEeNodeB-FDD基站S1断链告警故障分析和处理案例LTE eNodeB-FDD基站S1断链告警故障分析和处理案例问题描述（故障现象）某局LTE⽹管上新出现⼗⼏个基站有S1断链的告警，查看告警信息时发现，基站配置的两个MME地址中有⼀个地址是不通的，基站能正常建链，但都出现到同⼀MME地址不通⽽告S1断链。
问题原因分析查看告警附加信息，发现基站配置的两个MME地址中有⼀个地址是不通的，只有⼀个地址通，基站能正常建链，但由于绝⼤部分其他基站到2个MME的地址都是通的，排除MME故障原因导致，检查告警基站的配置数据也没有发现问题，于是怀疑烽⽕IPRAN数据是否做了修改。
问题解决⽅案1、通过告警信息初步判断故障原因可能是基站配置数据有过修改、其中⼀套MME故障、IPRAN传输数据有改动。
2、通过查看全⽹基站告警排除MME故障原因导致，检查基站配置数据都正常。
3、基本定位为IPRAN传输数据修改导致，沟通烽⽕IPRAN⼈员了解到，他们在对应的B设备上把⽹关做了修改，让做数据的⼈员检查发现⽹关修改错误导致到⼀套MME的地址不通，从⽽导致我们基站上告S 1链路断的告警，烽⽕把对应⽹关修改后告警恢复。
总结及注意事项利⽤告警信息进⾏故障的初步定位，应⽤排除法逐⼀排查最终定位故障原因，沟通协调传输⼚家完成故障处理。
LTE eNodeB-某地FDD基站搜星故障的分析处理问题描述（故障现象）某局FDD基站近期频繁出现“GNSS接收机搜星故障”告警，维护组⽴即进⾏深⼊分析。
时钟同步是为了让基站和⽹络中的其他设备的时钟频率或者时间差异保持在允许的范围内，避免传输系统中收发信号定时的不准确导致传输性能的恶化。
FDD基站同步是为了后续引起诸如eMBMS、eICIC、M BSFN等降低⼲扰的关键技术。
问题原因分析①由于开站后就出现故障，初步判断硬件问题，更换蘑菇头、跳线等，故障依旧。
②勘察现场，基站所处位置地理条件糟糕，位于两座⼭之间的⼭⾕内。
S1链路故障导致掉线案例--爱立信核心网
问题描述（故障现象）组网环境问题原因分析问题解决方案由于掉线上报的原因为S1链路故障，初步认为是S1链路故障导致，同时这段时间通辽的退服基站、故障基站、传输问题导致的基站退服较多，因此筛选出了由于S1故障导致掉线次数较多的基站进行了检查，基站工程师反馈说这些基站状态正常，并且也从没有发生过告警，包括S1链路故障告警。
同时，联系了爱立信核心网确认是否在指标恶化的6月5日是否进行过什么操作，答复这两天没有对核心网做过任何操作。
然后请其对告警检查，爱立信核心网反馈了同样的信息，没有发现任何告警，包括S1故障告警。
从基站和核心网反馈的情况来看，这应该不是硬件故障之类的告警引起。
鉴于这种情况，提取了一周的小区级别数据进行了分析：几乎由于该原因导致的掉线每个基站都存在，其中有几个TOP小区次数较多，其余都是几十次或者十几次和几次的。
至此，我们开始怀疑是核心网的原因，由于核心网是异厂家，我们要拿出充分的证据才能去理论。
通过TOP小区筛选出几个由于S1故障掉线次数较多的小区进行跟踪，从基站侧跟踪到了掉线情况： UE GID为1127的用户在正常RRC连接态，基站向MME发送了“UE CONTEXT RELEASE QUEST",原因值为传输不可用，见下图：之后收到了核心网下发的“UE CONTEXT release command”，携带的原因值为DETACH。
见下图：由于是传输层原因不可用，我们从网管提取了E-RAB的情况进行分析：可以看出由于传输层问题导致的E-RAB异常释放次数较多，这是导致UE Context异常释放的主要原因。
根据3GPP 23.007协议中，对基站收到GTP error indication的处理定义如下，基站的实现符合协议标准。
因此需要爱立信确认为什么发起GTPU Error indication。
移动公司与核心网厂家爱立信沟通后答复：故障初步分析：由于EPG的U平面存在吊死的TEID导致的。
4G5G共主控分离传输S1控制面传输中断告警
45G共主控分离传输S1控制面传输中断告警
问题描述：
12月02日，咸丰传输的SPN具备条件后，一起开了4个共主控站点，开通后5G正常，4G 传输都不通，且伴随S1控制面传输中断告警。
处理过程：
1.站点S1不通，首先想到的是4G数据问题或者光口问题，传输侧检查光口状态，收发光
正常；
2.基站侧ping测试4G核心网地址不通；
3.传输trace到4G核心网地址正常，说明网关到核心网没问题
4.从基站侧ping网关地址，不通。
再次和现场核查光路，确认收发光正常，现场指示灯正
常。
5.和传输核对VLAN数据，发现两侧VLAN信息不一致，基站侧VLAN是旧的，传输做的
数据用的是新的VLAN；修改基站侧VLAN数据后，告警依旧存在；
6.再次查询VLAN数据，修改成功，但发现端口标识是“0”，共主控4GVLAN的端口标识是
“73”，修改后，ping测正常，告警消失
根因：
基站和传输侧的VLAN数据不一致。
解决方案：
修改VLAN数据
总结和建议：
S1控制面传输中断告警，首先协调传输配合检查光口，再ping测试基站到网关，然后让传输trace到核心网路由，逐段定位
问题找到后，数据修改也要仔细，通常我们修改VLAN数据是端口标识默认选0；但是共主控分类传输场景，4G的VLAN对应端口标识是“73”。
NR侧漏配S1口导致终端无法接入NR小区问题案例
NR侧漏配S1口导致终端无法接入NR小区问题案例NR侧漏配S1口导致终端无法接入NR小区问题案例一、关键词：SCG间隔、邻区、PLMN名单、x2、S1、TAC二、案例分类问题分类：接入类手段分类：参数调整、三、优化背景目前贵阳移动NR网络NSA组网需要LTE锚点定位后接入5G并持续驻留，因此优化过程中要确保LTE锚点接入、切换指标正常，确保5G站点接入、切换、驻留比、速率、覆盖等指标正常。
四、问题现象NR站点测试中，在金华湖站点测试时发现，终端占用锚点1GS-金华湖LHHC一直无法接入到NR站1GS-金华湖NHHC。
五、原因分析1、数据初步分析对Probelog分析：在Main模块界面发现收到锚点1GS-金华湖LHHC信号，未收到本站NR小区信号。
在Signaling模块查看事件窗口，发现终端上报本站NR的B1事件，但一直不执行添加辅载波的操作由本次分析可知：锚点侧NSADC能力开关已开启，但上报B1未回应。
2、查询告警：LSTALMAF:;站点正常，不存在告警。
2、查询PLMN关系：LSTNCELLPLMNLISTPLMN白名单配置正常3、查询4-5G外部：LSTNREXTERNALCELL发现TAC非现网TAC执行操作：修改TAC为现网TAC修改后进行测试验证，发现本站锚点仍然不接入本站NR小区4、查询本站X2：LSTGNBCUX2INTERFACE；X2配置正常5、查询NR站点配置：LST NRDUCELL:;站点配置正常基本参数配置核查无误，进行后台S1、X2信令跟踪在NR侧的X2信令里看到，每次eNB给gNB发起X2AP_SGNB_ADD_REQ（添加辅载波请求）时，gNB都会给eNB回应X2AP_SGNB_ADD_REJ（辅载波添加拒绝）消息。
点开信令观察详细原因，显示为transport-resource-unavailable（传输资源不可用），可大致定位为传输问题。
而前期已核查X2链路无异常，因此需核查NR侧的S1链路7、站点S1口查询：LSTGNBCUS1站点S1接口未配置手动配置S 1口8、配置S1口后测试站点验证，NR正常接入，且速率正常。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
S1断链告警处理指导1.故障现象描述告警管理中查看到基站上报“S1断链告警（0）”告警码，如下图所示：2.故障分析排查思路根据TD-LTE的网络接口协议，S1链路是建立在物理传输层、数据链路层、IP协议层、SCTP偶联链路之上的传输协议层，如下图所示：所以处理S1链路故障，需要从底层开始排查：1、首先排查站点是否存在传输告警，排除传输故障；2、其次基站IP地址配置是否正常；3、再次确认SCTP偶联断告警，排除SCTP偶联告警；4、最后排查是否存在S1 AP建立失败（协商失败或基站无小区），与核心网核对小区TAC值是否配置一致。
3.故障排查步骤1、查看基站告警，是否存在传输类相关告警，例如“网元断链告警”、“SCTP偶联断链”告警，若存在以上告警，需要先按照以上告警排查指导手册，先解决以上告警。
2、检查ENODEB------MME或SGW 路由IP地址是否配置正确；通过telnet命令登录到CC板，使用 BRS命令对MME及SGW地址进行PING包测试，详细登录方式如下，红色字体均需要输入：通过服务器远程登录：$ telnet 前台通过网线直连登录地址：正在尝试...连接到（）(none) login: zte（用户名）Password: zte（密码）Processing /etc/profile... Done# /ushell-> Please input password!->***（密码zte）-> 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 printfinfo'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 printfinfo------------------------------------------------------------------------------$$ps（查看前台进程）PID 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 1253m S /680 root 9156 S /tftp683 root 1308 S telnetd685 root 1312 S inetd686 root 1312 S -/bin/./ash697 root 0 SWN [jffs2_gcd_mtd0]1201 root 457m S / 88 91 /1750 root 1316 S -sh1751 root 9216 R /ushell1753 root 1304 R sh -c ps1754 root 1308 R ps$$pad 678（登录到平台进程）[678]ushell enter print modushell enter debug mod$$brsping ""（ping核心网MME地址）[678][ begin to excel fun:brsping ]value = 0(0x0)[ end to excel fun:brsping ]Ping : find no route for dest, send by default gateway [0xac1e8fc1]. send ping seq: 1...$$[678]PING===>reply from packetsize=36 time=14ms.——正常ping通时返回的时长[678]send ping seq: 2...[678]PING===>reply from packetsize=36 time=4ms.[678]send ping seq: 3...[678]PING===>reply from packetsize=36 time=3ms.[678]send ping seq: 4...[678]PING===>reply from packetsize=36 time=24ms.[678]Ping statistics for Packets: Sent = 4, Received = 4, Lost = 0(0% loss), Approximate round trip times in milli-seconds:Minimum = 3ms, Maximum = 24ms, Average = 11ms（ping核心网MME控制面地址结果，丢包率0%，证明基站到MME链路正常。
）brsping "" （ping核心网SGW地址）[678][ begin to excel fun:brsping ]value = 0(0x0)[ end to excel fun:brsping ]send ping seq: 1...$$[678]PING===>reply from packetsize=36 time < 1ms.[678]send ping seq: 2...[678]PING===>reply from packetsize=36 time < 1ms.[678]send ping seq: 3...[678]PING===>reply from packetsize=36 time=1ms.[678]send ping seq: 4...[678]PING===>reply from packetsize=36 time < 1ms.[678]Ping statistics for Packets: Sent = 4, Received = 4, Lost = 0(0% loss), Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum = 1ms, Average = 0ms（ping核心网SGW用户面地址结果，丢包率0%，证明基站到SGW链路正常。
）通过以上步骤，排查基站到EPC的控制面MME和用户面SGW链路均正常。
3、Pad 到平台进程， showtcb 查看偶联状态，继续在平台进程中输入“showtcb”命令查看，偶联状态是否正常，若偶联异常，按照偶联断链告警指导手册处理。
$$showtcb[678][ begin to excel fun:showtcb ]=====Begin:Show Assoc TCB Info=====TCB info 0:偶联号0ULPID = 0, AssoID = 0, Checksum = 1, InstanceID = 0LocalPort = 6051, SourIP = VpnId = 31PeerPort = 6051, DestIP = VpnId = 31Association State = established（此处显示偶联状态，established标示偶联正常）CulTsnAcked = 24, NextTsnAssign = 25, LastRecvTSN = 61OutStandingSize = 0, PendingChkNum = 261888, MtuSize = 1500 TxReChkNum = 0TxStrmNum = 2, RxStrmNum = 2PeerVerifTag = 57, MyVerifTag = 17TCB info 11:偶联号11ULPID = 11, AssoID = 11, Checksum = 0, InstanceID = 11LocalPort = 36422, SourIP = VpnId = 31PeerPort = 36422, DestIP = VpnId = 31Association State = established（此处显示偶联状态，established标示偶联正常）CulTsnAcked = 01, NextTsnAssign = 02, LastRecvTSN = 0OutStandingSize = 0, PendingChkNum = 261888, MtuSize = 1500 TxReChkNum = 0TxStrmNum = 2, RxStrmNum = 2PeerVerifTag = 2, MyVerifTag = 77TCB info 12:偶连号12ULPID = 12, AssoID = 12, Checksum = 1, InstanceID = 12LocalPort = 36422, SourIP = VpnId = 31PeerPort = 36422, DestIP = VpnId = 31Association State = established（此处显示偶联状态，established标示偶联正常）CulTsnAcked = 01, NextTsnAssign = 02, LastRecvTSN = 40OutStandingSize = 0, PendingChkNum = 261888, MtuSize = 1500 TxReChkNum = 0TxStrmNum = 2, RxStrmNum = 2PeerVerifTag = 12, MyVerifTag = 77TCB info 13:偶连号13ULPID = 13, AssoID = 13, Checksum = 1, InstanceID = 13LocalPort = 36422, SourIP = VpnId = 31PeerPort = 36422, DestIP = VpnId = 31Association State = cookie_wait（此处显示偶联状态，cookie wait标示偶联不正常）CulTsnAcked = 0, NextTsnAssign = 05, LastRecvTSN = 0OutStandingSize = 0, PendingChkNum = 68, MtuSize = 0TxReChkNum = 0TxStrmNum = 2, RxStrmNum = 2PeerVerifTag = 0, MyVerifTag = 05TCB info 14:偶连号14ULPID = 14, AssoID = 14, Checksum = 1, InstanceID = 14LocalPort = 36422, SourIP = VpnId = 31PeerPort = 36422, DestIP = VpnId = 31Association State = cookie_wait（此处显示偶联状态，cookie wait标示偶联不正常）CulTsnAcked = 0, NextTsnAssign = 69, LastRecvTSN = 0OutStandingSize = 0, PendingChkNum = 68, MtuSize = 0TxReChkNum = 0TxStrmNum = 2, RxStrmNum = 2v1.0 可编辑可修改PeerVerifTag = 0, MyVerifTag = 69=====End:Show Assoc TCB Info=====value = 34(0x22)[ end to excel fun:showtcb ]$$exit（退出平台进程）ushell recv signo:0.quit debug and exit ushell!# exit（退出基站CC单板连接）关闭连接。