《利用CHR定位CDR中RNC INNER FAILURE.docx》由会员分享，可在线阅读，更多相关《利用CHR定位CDR中RNC INNER FAILURE.docx（6页珍藏版）》请在三一办公上搜索。
1、Document TitleSecurity Level: RNC INNER FAILURE1. SRB RESET 12【1】RL失步，SRB复位导致掉话（无线信号覆盖不好，属于正常现象）。=NO. 54=CorrmOlpcItf.cline:3403RLS SYNC STATE: RLS ID = 0, Sync state = 0 (0-unsync; 1-sync)!=NO. 55=RncapRbUpAbnormal.cline:426Trace in RNCAP_RbRlcStatusInd:DSP ID = 1342448650, Cause = 201589007.=NO. 5
2、6=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.2. TIMER EXPIRED 2【1】先发生TRB复位，DCCC从384k重配置到144k，UE没有回应RB重配置响应，RNC进行RRC连接释放（注：RB RECFG D2D失
3、败之后，必定会导致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=RncapRbRecfg.cline:6850Err in RNCAP_RbRecfgDch2
4、DchUeTimeout: 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 = 185468883.185468883：RR_ERR_RNCAP_SHO_WAIT_ASU_
5、CMP_TIMEOUT3. OTHER 12【1】CMB业务，UE主动发起信令连接释放导致掉话。大部分OTHER情况都是如此，占5/12。关于UE主动发起信令连接释放，目前现场遇到了3大类情况：l HLR鉴权bug，导致UE鉴权失败，UE此时发起信令连接释放是正常的。该问题已经通过HLR的补丁解决；l BlackBerry手机周期性的自动检查和接收Email，如果没有Email（大部分情况），UE会为了节约无线资源而主动发起信令连接释放；这是UE正常的行为；l 华为手机在CMB接入的过程中，如果用户按下“END”键终止观看CMB，就会发生该异常掉话。该类情况目前在现场出现的比较多，对于UE来讲
6、这也是正常的行为。=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_RbRlcStatusInd: TRB Reset! Cause:201589
7、007 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 remaining RAB(31)【3】CMB业务，RB重配置（D2F）和小区更
8、新流程交叉，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(),usCcbIndex = 221=NO. 49=RncapMain.clin
9、e: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_INTERFACE Msg: RNCAP_RB_RECFG_FAI
10、L【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处于无线信号变化比较剧烈
11、的区域，导致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, CCB Index is 414=NO. 66=RncapRrcRel.cline:394RNCAP_RrcRelRncap:RRC Abnormal Release! Static Cause = 185798355, ulCause = 185468890.185798355：RNCAP_RRC_REL_FHHO_FAIL_NO_UE。2022-12-25HUAWEI ConfidentialPage6, Total6
