3版本掉話問題分析

蘇州12505_4掉話問題分LTERF2014作者：【產(chǎn)品類別【CASEID【故障級別【關鍵字：掉話率【故障現(xiàn)象13.312505_4【原因分析RRC重配超時導致對問題進行了現(xiàn)場測試，并了callp和L2信令UELOG功，之后UE又發(fā)起了隨機接入過程，但是一直失敗，導致UE掉話，同時可以注意到，UE并沒有收到 功，之后UE又發(fā)起了隨機接入過程，但是一直失敗，導致UE掉話，同時可以注意到，UE并沒有收到 CALLPTRACECallp收到了RRCconnectionReconfcompletemsg，handover成功:CallpULDCCH數(shù)據(jù) [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有發(fā)出去給UE。切換UE在小區(qū)做隨機接 srs_start_prb=1rach_msg_1_start_prb=3367589: 23640UE(ue_id:382)TransitionfromNOT_SETtoL2檢測4CRCnackmsg3msg3msg2UEULgrant上傳上來的，位置在PRB69，MCS3，由于切換UE在小區(qū)邊緣，信道質(zhì)量比較差，導致3次MAC重傳都NACK。 367664: 1240userdatalengthbytes,logged128009A001F0000006400000000 000000020000FFFF00000000 0EA206000000000000540000 010005B500B00100034A0000 006C00001A3280021D8002F4 000000000000000000000000 000000000000000000000000 000200000000000000000000 UESRRLC層的重傳，L2會給一gran（PRB63MCS0這時UEmsg3在這grant的位置發(fā)上來，由于MCS所以這dRC解對了，L2發(fā)給UEACK之后把這個RRCdata發(fā)上去給callpcallp解出來就是RRCconnectionreconfcompleteL2msg2grant上檢msg3，之前那個RRCdata沒有當msg3處理，所L2一直都沒檢msg3，UE的狀態(tài)一直沒有到active。來的reconf消息L2不會入隊發(fā)給UE，也就是最開始看到的reconf消息丟失。grantmsg3，L2不會當做msg3ULRRCdata 0x3A3D21090x1F2B00A00x00000C570xCF5765FC BUG由于LR13引入了OOTfeature，會在收到msg3之前檢測SR，所以在LR13遇到這個問題CL7.2bug?！窘鉀Q方法板卡沒