3版本掉话问题分析

苏州12505_4掉话问题分LTERF2014作者：【产品类别【CASEID【故障级别【关键字：掉话率【故障现象13.312505_4【原因分析RRC重配超时导致对问题进行了现场测试，并了callp和L2信令UELOG功，之后UE又发起了随机接入过程，但是一直失败，导致UE掉话，同时可以注意到，UE并没有收到 功，之后UE又发起了随机接入过程，但是一直失败，导致UE掉话，同时可以注意到，UE并没有收到 CALLPTRACECallp收到了RRCconnectionReconfcompletemsg，handover成功:CallpULDCCH数据 [0x80001010] CNU_EVT_FUNC_ENTRYCallp得到消息RRCconnectionReconf [0x80001010] CNU_EVT_FUNC_ENTRY reconfcomplete消息，导致timer超时。36334216 CNU_EVT_FUNC_ENTRY[s1 CNU_EVT_FUNC_ENTRY CNU_EVT_FUNC_ENTRYL2TRACE有发出去给UE。切换UE在小区做随机接 srs_start_prb=1rach_msg_1_start_prb=3367589: 23640UE(ue_id:382)TransitionfromNOT_SETtoL2检测4CRCnackmsg3msg3msg2UEULgrant上传上来的，位置在PRB69，MCS3，由于切换UE在小区边缘，信道质量比较差，导致3次MAC重传都NACK。 367664: 1240userdatalengthbytes,logged128009A001F0000006400000000 000000020000FFFF00000000 0EA206000000000000540000 010005B500B00100034A0000 006C00001A3280021D8002F4 000000000000000000000000 000000000000000000000000 000200000000000000000000 UESRRLC层的重传，L2会给一gran（PRB63MCS0这时UEmsg3在这grant的位置发上来，由于MCS所以这dRC解对了，L2发给UEACK之后把这个RRCdata发上去给callpcallp解出来就是RRCconnectionreconfcompleteL2msg2grant上检msg3，之前那个RRCdata没有当msg3处理，所L2一直都没检msg3，UE的状态一直没有到active。来的reconf消息L2不会入队发给UE，也就是最开始看到的reconf消息丢失。grantmsg3，L2不会当做msg3ULRRCdata 0x3A3D21090x1F2B00A00x00000C570xCF5765FC BUG由于LR13引入了OOTfeature，会在收到msg3之前检测SR，所以在LR13遇到这个问题CL7.2bug。【解决方法板卡没