人力资源利用CHR定位CDR中RNC INNER FAILURE

1、Document TitleSecurity Level: DATE yyyy-MM-dd 2022-09-10HUAWEI ConfidentialPageRNC INNER FAILURESRB RESET 12【1】RL失步，SRB复位导致掉话（无线信号覆盖不好，属于正常现象）。=NO. 54=CorrmOlpcItf.cline:3403RLSSYNCSTATE: RLS ID = 0, Sync state = 0 (0-unsync; 1-sync)!=NO. 55=RncapRbUpAbnormal.cline:426Trace in RNCAP_RbRlcStatusInd:D

2、SP ID = 1342448650, Cause = 201589007.=NO. 56=RncapRbUpAbnormal.cline:530Err in RNCAP_RbRlcStatusInd: SRB Reset! Cause:201589007 , RB ID:2.=NO. 57=RncapRrcRel.cline:394RNCAP_RrcRelRncap:RRC Abnormal Release! Static Cause = 185796832, ulCause = 185141212.TIMER EXPIRED 2【1】先发生TRB复位，DCCC从384k重配置到144k，U

3、E没有回应RB重配置响应，RNC进行RRC连接释放（注：RB RECFG D2D失败之后，必定会导致RRC释放，其他RB RECFG不一定会导致掉话）。时间点为：16:37:47(34)=NO. 6=RncapRbUpAbnormal.cline:458Trace in RNCAP_RbRlcStatusInd:TRB RESET by UE!RLC INST:71.=NO. 15=CorrmFrcPcComm.cline:17902RAB current DL bit rate: 384000 bps, target DL bit rate: 144000 bps=NO. 46=RncapR

4、bRecfg.cline:6850Err in RNCAP_RbRecfgDch2DchUeTimeout: Wait UU_RB_RECFG_CMP message timeout.【2】UE没有及时回应活动集更新响应导致RRC异常释放、掉话（RNC没有收到活动集更新响应必然导致RRC连接释放，设计就是如此）。估计也是与无线信号覆盖较差有关。时间点为：16:07:01(29)=NO. 43=RncapRrcRel.cline:394RNCAP_RrcRelRncap:RRC Abnormal Release! Static Cause = 185798369, ulCause = 18546

5、8883.185468883：RR_ERR_RNCAP_SHO_WAIT_ASU_CMP_TIMEOUTOTHER 12【1】CMB业务，UE主动发起信令连接释放导致掉话。大部分OTHER情况都是如此，占5/12。关于UE主动发起信令连接释放，目前现场遇到了3大类情况：HLR鉴权bug，导致UE鉴权失败，UE此时发起信令连接释放是正常的。该问题已经通过HLR的补丁解决；BlackBerry手机周期性的自动检查和接收Email，如果没有Email（大部分情况），UE会为了节约无线资源而主动发起信令连接释放；这是UE正常的行为；华为手机在CMB接入的过程中，如果用户按下“END”键终止观看CMB，

6、就会发生该异常掉话。该类情况目前在现场出现的比较多，对于UE来讲这也是正常的行为。=NO. 55=RncapRrcIuRel.cline:200RNCAP_RrcSigConnRelInd : Send IU Rel Req for PS, ulCause = 185206758.185206758：RR_ERR_RNCAP_RRC_UE_SIG_REL_IND【2】TRB复位，RNC释放PS业务，因没有其他RAB导致IU释放，占1/12。仅发生一次，时间点为：13:59:45(21)=NO. 79=RncapRbUpAbnormal.cline:541Err in RNCAP_RbRlcSt

7、atusInd: TRB Reset! Cause:201589007 RlcInst DSP ID:1342456838.=NO. 80=RncapRabAbnormal.cline:880Enter in RNCAP_RabRelReq for PS: Cause = 185141213, enRabRelReqType = 4.=NO. 1=RncapRelocEntry.cline:1351Info in RNCAP_RelocIuRelCmdPre: Received IU REL CMD MSG,Abnormal ulIuRelCmdCause = 3131：No remainin

8、g RAB(31)【3】CMB业务，RB重配置（D2F）和小区更新流程交叉，UE一直没有响应RB重配置完成，导致掉话。出现较多，占4/12。是RNC的已知问题，可通过RNC V16 071 SP01（解决交叉流程中RNC在小区更新确认消息中多带了RB ID的问题）和SP02补丁（解决RB重配置消息如果重发的情况下，RNC随后的完整性保护算法中的SN值始终为1、不符合协议的问题）解决。=NO. 48=RncapHoCuFach.cline:2282Wait UE rsp timeout:RNCAP_HoCuFach2FachNewCellWaitUeRspTimerExpire(),usCcbI

9、ndex = 221=NO. 49=RncapMain.cline:1134Interface: RNCAP_INTRA_INTERFACE Msg: RNCAP_HO_CU_TRIG_FAIL=NO. 50=RncapRbComm.cline:16030Err in RNCAP_RbCtrlCuOverlapFailProc: enCause = 185468888, CCB Index is 221185468888：RR_ERR_RNCAP_CU_WAIT_UE_RSP_TIMEOUT=NO. 51=RncapMain.cline:1134Interface: RNCAP_INTRA_I

10、NTERFACE 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=RncapMain.cline:1134Interface: RNCAP_RNCAP_RRC_INTERFACE Msg: RRC_RB_RECFG_CMP=NO. 65=RncapHoFhhoOthers.cline:142Err in RNCAP_HoFhhoTimerExpirePreproc, T305 or Wait UE Redo Timer Expire, Release RNCAP