S1链路故障导致掉线案例--爱立信核心网.docx

TDD-LTE网规网优解决方案-S1链路故障导致掉线案例 产品 TDD-LTE网规网优解决方案/TD-LTE无线子系统/TDD 网管版本 设备硬件版本 设备软件版本 单板硬件版本 单板软件版本 故障错误代码 浏览量 64 作者 牛银山 知识序号 WHD20140717306926 问题描述（故障现象） 掉线率突然由0.2%以下上升到2%左右。提取指标发现ENB由于S1链路故障导致的Context释放次数大幅增加，由每天的500次左右增加到1万次以上。 组网环境 无线侧为我司设备，本地传输为我司设备，省干网为F7设备，核心网侧为爱立信设备。 问题原因分析 从基站和核心网反馈没有硬件故障之类的告警。鉴于这种情况，提取了一周的小区级别数据进行了分析：几乎由于该原因导致的掉线每个基站都存在，其中有几个TOP小区次数较多，其余都是几十次或者十几次和几次的。对于这种全网出现的问题，结合信令和KPI指标发现，都是由于传输层问题GTP error indication导致的E-RAB异常释放次数较多，这是导致UE Context异常释放的主要原因。我们开始怀疑是核心网的原因导致。 问题解决方案 首先提取了指标进行观察，发现在6月6日，掉线次数由之前的几百次突然增加到1万次以上。见下表所示： 由于掉线上报的原因为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导致的。详细信息如下： 因为在合设的SAE-GW上，SGW的U卡与PGW的U卡是共用的，当一些U面的TEID由于软件原因吊死的时候，SAE-GW还是在认为它们是可用的。因此继续分配给S1-U的接口使用，当enodeB在往这个TEID传上行payload package的时候，SGW不能正常处理这些payload package，因此返还GTP-U的error indication。 临时解决方案：需要重启重启板卡或者节点重启来清除吊死的TEID。 解决方案：需软件升级解决，升级到13A，该软件版本上优化了防止TEID软件吊死的机制。 总结及注意事项 由于掉线原因为S1链路故障导致，在处理该问题之初，一直从S1链路着手处理，一直督促让产品侧和核心网产品侧对S1链路故障处理，很长时间才答复没有告警等问题，耽搁了很长时间。 对于S1链路问题，涉及基站接口、传输和核心网接口，需要多单元协调处理。