欢迎来到天天文库
浏览记录
ID:48315171
大小:875.45 KB
页数:6页
时间:2020-01-13
《E-RAB建立成功率低问题分析报告》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、1.分析该异常小区掉话话统。通过话统可知,该小区6月24日E-RAB建立成功率低,共42次(185-143)E-RAB建立失败。其中有25次是无线的原因,12次是MME原因,还有5次从话统分析不出来。其中12次MME的原因需要由MME定位(当eNodeB收到来自核心网的E-RABSETUPREQUEST消息,eNodeB执行消息合法性检查失败时,统计LE-RAB.FailEst.MME指标,如果E-RABSETUPREQUEST消息中要求同时建立多个E-RAB,则该指标根据具体数目进行累加。eNodeB消息合法性检查的场景包括:消息错误、E-RABID重复或E-RAB建立流程与其它S1AP层流
2、程交叉导致无法处理该消息等场景)1.分析问题站点的CHR日志,查看内部异常释放原因。上述释放原因中只有UEM_UECNT_REL_INIT_CTXT_SETUP_FAIL和UEM_UECNT_REL_RRC_REEST_SRB1_FAIL的释放原因与E-RAB建立失败有关2."UEM_UECNT_REL_INIT_CTXT_SETUP_FAIL"原因分析。"UEM_UECNT_REL_INIT_CTXT_SETUP_FAIL"在6月24日230169_WTWTX_09598_2小区(ulCellId=1)共发生了27次,如下所示该原因值对应的信令流程有如下几种。1. 没有收到UE的RRC_SE
3、CUR_MODE_CMP,收到RRC_CONN_REESTAB_REQ。具体信令流程如下查看L2_SRB_LOG,从RRC_SECUR_MODE_CMD的HARQ反馈为ACK,可知该消息已被UEMAC成功接收,如下查看L2_DRB_LOG如下,可知上行误码率很高,上行基本全都CRC解调失败,怀疑等到UERLC重传达到最大重传次数,UE进行RRC_CONN_REESTAB_REQ为什么eNB上行全都CRC解调失败呢,从上图可看到上行信道质量,可知上行信道质量比较好,更多怀疑是eNB和UE之间的兼容性问题,需要找到UE进行深层次定位2.等待UE的RRC_UE_CAP_ENQUIRY响应空口定时器超
4、时,eNB主动发起释放。具体信令流程如下什麼eNB上行全都CRC解調失敗呢,從上圖可看到上行信道質量,可知上行信道質量比較好,更多懷疑是eNB和UE之間的兼容性問題,需要找到UE進行深層次定位查看L2_SRB_LOG,从RRC_UE_CAP_ENQUIRY的HARQ反馈为ACK,可知该消息发送一次即被UEMAC成功接收,如下为什么RRC_UE_CAP_ENQUIRY第一次已经发送成功了,后面还要继续发送呢?怀疑是eNBRLC没有收到RRC_UE_CAP_ENQUIRY该消息的状态报告,导致RLC重传。通过L2RlcReTx字段证实了猜测,如下是上行信道质量不好,导致RLC的状态报告没有被eNB
5、成功解析吗?如下,可知上行信道条件很好为什么上行信道质量这么好,eNB上行几乎全都CRC解调失败呢,更多怀疑是eNB和UE之间的兼容性问题,需要找到UE进行深层次定位。1."UEM_UECNT_REL_RRC_REEST_SRB1_FAIL"原因分析该原因对应的信令如下所示,eNB下发第一个重配置消息,UE没有回复重配完成。等到UE检测到RLF后发起了重建请求,eNB回复了重建响应,但是等待5s空口定时器超时一直没有收到UE的重建完成消息,eNB又发送了重建拒绝(CHR中重建拒绝记录两次,实际下发一次)。如下:为什么UE没有回复重配完成呢?从CHR的L2_SRB_LOG来看重配置消息一直没有被
6、UE成功接收,HARQ反馈状态全是DTX。从CHR的L2_DRB_LOG来分析,上行误码率和下行误码率均为100%,上行RSRP和SINR都很差,说明UE处在弱覆盖区域。处在弱覆盖区域的UE发现下行链路失败后,进行了RRC连接重建,但是由于UE一直未回复重建完成,造成了此次ERAB的建立失败。
此文档下载收益归作者所有