E-RAB建立成功率低问题分析报告.doc

.1. 分析该异常小区掉话话统。通过话统可知，该小区6月24日E-RAB建立成功率低，共42次（185-143）E-RAB建立失败。其中有25次是无线的原因，12次是MME原因，还有5次从话统分析不出来。其中12次MME的原因需要由MME定位（当eNodeB收到来自核心网的E-RAB SETUP REQUEST消息，eNodeB执行消息合法性检查失败时，统计LE-RAB.FailEst.MME指标，如果E-RAB SETUP REQUEST消息中要求同时建立多个E-RAB，则该指标根据具体数目进行累加。eNodeB消息合法性检查的场景包括：消息错误、E-RAB ID重复或E-RAB建立流程与其它S1AP层流程交叉导致无法处理该消息等场景）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_SECUR_MODE_CMP，收到RRC_CONN_REESTAB_REQ。具体信令流程如下查看L2_SRB_LOG，从RRC_SECUR_MODE_CMD的HARQ反馈为ACK，可知该消息已被UE MAC成功接收，如下查看L2_DRB_LOG如下，可知上行误码率很高，上行基本全都CRC解调失败，怀疑等到UE RLC重传达到最大重传次数，UE进行RRC_CONN_REESTAB_REQ为什么eNB上行全都CRC解调失败呢，从上图可看到上行信道质量，可知上行信道质量比较好，更多怀疑是eNB和UE之间的兼容性问题，需要找到UE进行深层次定位2. 等待UE的RRC_UE_CAP_ENQUIRY响应空口定时器超时，eNB主动发起释放。具体信令流程如下什麼eNB上行全都CRC解調失敗呢，從上圖可看到上行信道質量，可知上行信道質量比較好，更多懷疑是eNB和UE之間的兼容性問題，需要找到UE進行深層次定位查看L2_SRB_LOG，从RRC_UE_CAP_ENQUIRY的HARQ反馈为ACK，可知该消息发送一次即被UE MAC成功接收，如下为什么RRC_UE_CAP_ENQUIRY第一次已经发送成功了，后面还要继续发送呢？怀疑是eNB RLC没有收到RRC_UE_CAP_ENQUIRY该消息的状态报告，导致RLC重传。通过L2RlcReTx字段证实了猜测，如下是上行信道质量不好，导致RLC的状态报告没有被eNB成功解析吗？如下，可知上行信道条件很好为什么上行信道质量这么好，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来看重配置消息一直没有被UE成功接收，HARQ反馈状态全是DTX。从CHR的L2_DRB_LOG来分析，上行误码率和下行误码率均为100%，上行RSRP和SI