利用CHR定位CDR中RNC INNER FAILURE.docx
-
资源ID:1904007
资源大小:613.30KB
全文页数:6页
- 资源格式: DOCX
下载积分:16金币
友情提示
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
|
利用CHR定位CDR中RNC INNER FAILURE.docx
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. 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.2. TIMER EXPIRED 2【1】先发生TRB复位,DCCC从384k重配置到144k,UE没有回应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=RncapRbRecfg.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 = 185468883.185468883:RR_ERR_RNCAP_SHO_WAIT_ASU_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来讲这也是正常的行为。=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: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 remaining 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(),usCcbIndex = 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_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=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