【資料名稱】：利用CHR定位CDR中RNC_INNER_FAILURE

【資料作者】：-

【資料日期】：-

【資料語言】：中文

【資料格式】：PDF

【資料目錄和簡介】：

【3】CMB業(yè)務(wù)，RB重配置（D2F）和小區(qū)更新流程交叉，UE一直沒有響應(yīng)RB重
配置完成，導(dǎo)致掉話。出現(xiàn)較多，占4/12。是RNC的已知問題，可通過RNC V16 071 SP01
（解決交叉流程中RNC在小區(qū)更新確認(rèn)消息中多帶了RB ID的問題）和SP02補丁（解
決RB重配置消息如果重發(fā)的情況下，RNC隨后的完整性保護算法中的SN值始終為1、
不符合協(xié)議的問題）解決。
====NO. 48====
RncapHoCuFach.c
line:2282
Wait UE rsp
timeout:RNCAP_HoCuFach2FachNewCellWaitUeRspTimerExpire(),usCcbIndex =
221

====NO. 49====
RncapMain.c
line:1134
Interface: RNCAP_INTRA_INTERFACE
Msg: RNCAP_HO_CU_TRIG_FAIL
Document Title Security Level:

2012-04-09 HUAWEI Confidential Page5, Total6
====NO. 50====
RncapRbComm.c
line:16030
Err in RNCAP_RbCtrlCuOverlapFailProc: enCause = 185468888, CCB Index is
221
185468888：RR_ERR_RNCAP_CU_WAIT_UE_RSP_TIMEOUT

====NO. 51====
RncapMain.c
line:1134
Interface: RNCAP_INTRA_INTERFACE
Msg: RNCAP_RB_RECFG_FAIL
【4】CMB業(yè)務(wù)，從CHR日志中也可以看到小區(qū)更新和RB重配置流程的交叉，但
是打印信息與之前不一樣：T305 or Wait UE Redo Timer Expire。這是否是UE響應(yīng)RB
重配置完成，但是不再繼續(xù)進行小區(qū)更新嗎？僅出現(xiàn)1/12次。時間點為：16:15:50(80)
該問題后續(xù)通過對網(wǎng)規(guī)CMB路測的單用戶跟蹤消息中，找到了一次這樣的流程。
經(jīng)過家里段忠毅的分析，問題的根本原因是：UE進行小區(qū)更新過程沒有成功，UE重發(fā)
了三次小區(qū)更新消息，RNC發(fā)送了三個CELL UPDATE CONFIRM，但是都沒有收到
UE的響應(yīng)消息，RNC因此進行RRC連接釋放。這是UE處于無線信號變化比較劇烈的
區(qū)域，導(dǎo)致UE收不到RNC回應(yīng)的小區(qū)更新響應(yīng)，在這里RNC的處理是正常的。后續(xù)需
要通過網(wǎng)規(guī)解決信號連續(xù)覆蓋的問題。
====NO. 63====