遵义电路域RAB指派失败原因为“IuBear_Operate_TimeOut”分析报告.doc

遵义电路域RAB指派失败原因为“IuBear_Operate_TimeOut”分析报告 一、问题描述： 由于遵义TD网络电路域接通率在全省排名靠后，近期对电路域做了专项问题跟踪和分析。 通过对遵义现网4套RNC指标进行了详细分析，发现电路域RAB接通率为99.80%左右，有一定提升空间，对失败原因进行了统计，发现存在IuBear_Operate_TimeOut（218）的原因，通过对9月13日的统计来看，电路域RAB失败次数726次，该失败原因就有389次，如果消除该原因，RAB成功率将有较大提升，而且该类失败与空口无关。 对典型信令进行了分析如下： 图1 失败场景1 从信令可以，当RNC收到核心网下发的RAB指派后，5s钟后RNC回复了RAB指派失败，原因为IuBear_Operate_TimeOut（218），从以往的经验看，该失败由于RNC收到RAB指派后，准备AAL2链路过程中出现问题，导致超时失败，核心网工程配合我们进行问题排查。 图2 失败场景2 从上图信令可以看出，当在呼叫过程中，CN下发RAB指派下来后，UE发起了挂机流程，导致CN侧不响应AAL2建立过程，出现RAB指派超时现象，出现218原因失败，虽然该场景失败不影响用户感知，但对指标有影响。建议是否核心网可以优化处理流程，避免此类失败。 通过上面两个场景的分析，由于只能看到层三信令，需要无线侧和核心网进行详细信令跟踪，协同分析原因。 遵义4套RNC均存在该类失败，但毕节1套RNC并无此类失败。 二、影响指标分析 针对上面类型的失败，下面说明对指标影响的情况； 下图为RAB建立成功率： 图3 电路域RAB建立成功率 从电路域RAB建立成功率来看，基本上都低于99.80%。 下图从失败的次数来看，IuBear_Operate_TimeOut（218）失败基本上占了所有失败的一半左右，如果能解决该类失败，可以预想到，RAB指标提升将会是很明显的。 图4 失败次数对比情况 三、建议排查手段 现通过省公司协调核心网技术人员与遵义公司技术人员一同对该类失败问题进行排查，双方一同进行信令跟踪，分析典型失败事件，找出了问题根源。需要对卡特核心网软件版本进行升级，将SP10版本升级到SP11版本，解决“IuBear_Operate_TimeOut”使遵义电路域接通率可以有明显提升。 第1页