【资料名称】：利用CHR定位CDR中RNC_INNER_FAILURE

【资料作者】：-

【资料日期】：-

【资料语言】：中文

【资料格式】：PDF

【资料目录和简介】：

【3】CMB业务，RB重配置（D2F）和小区更新流程交叉，UE一直没有响应RB重
配置完成，导致掉话。出现较多，占4/12。是RNC的已知问题，可通过RNC V16 071 SP01
（解决交叉流程中RNC在小区更新确认消息中多带了RB ID的问题）和SP02补丁（解
决RB重配置消息如果重发的情况下，RNC随后的完整性保护算法中的SN值始终为1、
不符合协议的问题）解决。
====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业务，从CHR日志中也可以看到小区更新和RB重配置流程的交叉，但
是打印信息与之前不一样：T305 or Wait UE Redo Timer Expire。这是否是UE响应RB
重配置完成，但是不再继续进行小区更新吗？仅出现1/12次。时间点为：16:15:50(80)
该问题后续通过对网规CMB路测的单用户跟踪消息中，找到了一次这样的流程。
经过家里段忠毅的分析，问题的根本原因是：UE进行小区更新过程没有成功，UE重发
了三次小区更新消息，RNC发送了三个CELL UPDATE CONFIRM，但是都没有收到
UE的响应消息，RNC因此进行RRC连接释放。这是UE处于无线信号变化比较剧烈的
区域，导致UE收不到RNC回应的小区更新响应，在这里RNC的处理是正常的。后续需
要通过网规解决信号连续覆盖的问题。
====NO. 63====