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

合肥移动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-维果歌城-HHLHF-建设学校-HHLHF-合肥聚元宾馆-HHLHF-合肥国轩凯旋-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由于软件原因