合肥TD-LTE掉线率高案例-孙超20140327

合肥移动LTE掉线率高案例

作者：孙超 徐修伟 刘德贵 【问题描述】：

合肥移动TD-LTE一期从2月25号左右开始掉线率和掉话率一致在2%~3%之间，其中某些TOP小区掉线率达90%以上，掉线次数达到上千次。

【告警信息】：无

【分析过程】： 掉线问题分析思路如下：

1、先分析话统看掉线的趋势，是全网问题还是TOP小区

2、如果是全网问题可以看看操作日志，看近期有没有操作，切割，或者参数改动

3、如果是TOP小区，先看话统分析给出是因为什么原因导致的掉线，切换失败，弱覆盖，邻区错配，PCI的mod3，上行干扰，切换门限不合适等都会导致掉线。跟掉线相关的counter如下：

eNodeB发起的S1 RESET导致的QCI为8的E-RAB异常释放次数 ? MME发起的E-RAB释放总次数

? UE在上行失步状态的E-RAB释放总个数) ? 传输层问题导致的E-RAB异常释放次数 ? 核心网问题导致的激活的E-RAB异常释放次数 ? 上行同步态转换为上行失步态UE的E-RAB总个数 ? 网络拥塞导致的E-RAB异常释放次数 ? 无线层问题导致的E-RAB异常释放次数 ? 小区切换出E-RAB异常释放总次数

4、话统给出的原因很粗，要看进一步原因，可以用omstar或FMA分析CHR日志 5、如果有必要可以在网管跟踪S1,Uu,GTPU信令

6、如果是全网问题，可以用FMA分析DBG或者SIG日志，Omstar核查全网参数看是否和集团要求一致

7、如果是TOP小区问题，OMstar还可以进一步将正常小区和问题小区做参数对比 【处理过程】： 1、查询无告警

2、查询话统发现是（L.E-RAB.AbnormRel.TNL）导致的掉话。没有地域性特点，也没有特定

时间。有几个TOP小区每天都高。挑了一个掉话率高，异常释放总次数也高的HF-维果歌城-HHL这个站点进行分析。

可以看到按照工具提示为传输侧原因或传输资源不可用。见红色圈中所示。

Fig1 HF-维果歌城-HHL掉线分析

3、传输侧同事介入定位，取了掉线高的下面4个站的电路号给传输侧同事定位

HF-维果歌城-HHL HF-建设学校-HHL HF-合肥聚元宾馆-HHL HF-合肥国轩凯旋-HHL

检查前3个站业务均正常，主要包接收LTE基站光功率值、RMON性能，传输链路经过的端口告警、性能等均正常，且这3条业务在传输上归属不同的L2/L3设备。其中HF-合肥国轩凯旋-HHL这个站传输收不到LTE基站的光。传输侧同事建议无线检查LTE基站侧告警，是否有异常。

告警查询，只有HF-合肥国轩凯旋-HHL这个站点出现过一次SCTP链路故障告警。其他三个站都正常。虽然话统提示为传输侧原因，但不一定是完全是因为物理上的传输故障导致的。需要进一步分析CHR日志和信令。

4、跟踪信令如下：显示为UE CONTEXT REQUEST，同样提示为传输侧原因。

Fig2 信令分析

5、分析CHR日志，原因为UEM_UECNT_REL_RECV_GTPU_RESET_BEAR_REQ

可以看出每次都是终端刚入网就被释放了，感觉就像是刚入网发送第一个报文给核心网后，核心网就发送GtpuErrInd了。还可以看出一个现象，就是TMSI都是一样的，这代表是同一个用户导致。

Fig3 CHR日志分析

参考协议3GPP29.060定义：

在数据发送的时候，如果SGW通过GTP-TEID无法索引到这个用户的上下文，也就是相当于找不到用户的信息，就会发error indication给基站。

信令分析来看，在上下文建立完成后，基站收到核心网发送的GTPU error indication后发起了上下文的释放，从信令消息上看，基站的发送的S1AP_INITIAL_CONTEXT_SETUP_RSP消息携带的IE没有问题。

以旺城大厦为例，10:43:57（294）MME给基站发送上下文建立请求。

10:43:57（314）基站发上下文响应给MME。64 50 CB 9B(100.80.203.155)，基站侧用户面地址也没有问题。

MOD USERPLANEHOST:UPHOSTID=0, VRFIDX=0, IPVERSION=IPv4, LOCIPV4=100.80.203.155, IPSECSWITCH=DISABLE, USERLABEL=;

协议对此消息的IE定义：

基站收到10:43:57(330)收到SGW发送的error indication，基站按照协议定义删除承载，发起上下文释放。

至此，无线基站的操作都是正常的。需要爱立信核心网介入进一步定位为什么会发送GTPU error indication。

爱立信定位后的结论是因为在合设的SAE-GW上，SGW的U卡与PGW的U卡是共用的，当一些U面的TEID由于软件原因吊死的时候，SAE-GW还是在认为它们是可用的。因此继续分配给S1-U的接口使用，当enodeB在往这个TEID传上行payload package的时候，SGW不能正常处理这些payload package，因此返还GTP-U的error indication。

解决方案：需软件升级解决，升级到13A，该软件版本上优化了防止TEID软件吊死的机制。

临时解决方案：需要重启重启板卡或者节点重启来清除吊死的TEID。 爱立信26号凌晨重启了MME，指标迅速变好。从之前的3%降低到1.2%.

无线掉线率合肥5.004.003.002.001.000.00无线掉线率合肥 【建议总结】：

无

【参考文档】：

【1】LTE掉话与切换性能优化X板斧V6.0.1

本文来源：https://www.bwwdw.com/article/5elf.html