重定位和系统间切换非RAN侧问题总结(5到6月期间).doc

重定位和系统间切换非RAN侧问题总结（5到6月期间）（其中国红色标题为正在推动其它实体定位的问题）一、 CS重定位和系统间切换并发拆线问题现象1：CS重定位期间源侧RNC收到核心网发送的Relocation Preparation Failure原因:没有请求的资源问题定位：经过在RNC和核心网进行信令跟踪，确认这种情况都是重定位和用户拆线并发导致。现象2：CS域RNC间重定位请求：Relocation Reqired后面紧跟着IU Release Command :正常释放问题定位：经过在RNC和核心网进行信令跟踪，确认这种情况都是重定位和用户拆线并发导致。现象3：CS域系统间互操作：Relocation Preparation Failure原因:没有请求的资源。现象4：CS域系统间重定位失败 IU Release Command同样对现象3，和现象4进行定位，结论同RNC间重定位的情况，都是在重定位或者系统间切换时并发DISCONNECT导致。问题结论：核心网的实现机制会影响到RNC侧CS重定位和CS系统间切换指标，特别是现象1和现象2占重定位出中总失败的50%以上，现象3现象4导致的CS系统间切换失败占总失败的30%以上，对RNC的重定位出CS系统间指标影响很大，另外重定位期间的DISCONNECT也会影响到重定位入的指标。具体表现为以下现象：现象5：重定位目标侧，RNC已经资源分配完毕，进行RL建立的过程中（RL Setup Response之前）收到CN的Iu释放命令，原因为“No requested resource is available；现象6：问题二：目标侧按正常的信令过程已结束，RNC已经向CN发起了Relocation Complete， CN下发IU释放，原因为正常释放，看源侧的消息，是Relocation Prepare Failure，原因为“No requested resource is available”现象7：目标侧Relocation Request ACK（RL Setup Response也已完成）之后，CN下发IU释放，原因是没有请求的资源：现象8：目标侧收到CN的Relocation Request消息后马上收到了CN的Iu释放消息，原因是没有请求的资源问题分析：CS域RNC间和系统间切换的以上原因失败都和核心网目前重定位和系统间切换与拆线并发时的处理策略有关，在并发场景，核心网目前的解释是并发场景，优先呼叫流程。因此需要核心网对此情况的处理进行修正。影响性：（1）域RNC间重定位失败前三占比原因如下，其中Relocation Preparation Failure原因:没有请求的资源;和Relocation Reqired后面紧跟着IU Release Command :正常释放都是由于重定位并发拆线导致，占总失败的58%，因此严重影响重定位出指标。失败原因失败比例Relocation Preparation Failure原因:没有请求的资源; 43.07%RB Reconfig Failure: Physical channel failure29.03%Relocation Reqired后面紧跟着IU Release Command :正常释放15.27%（2）域系统间切换前失败前三占比原因如下,其中Relocation Preparation Failure: 没有请求的资源和U Release Command: 未定义的原因加起来占总失败的32%，因此严重影响CS系统间切换指标。失败原因失败比例Handover From UTRAN Failure: physicalChannelFailure61.71%Relocation Preparation Failure: 没有请求的资源25.68%IU Release Command: 未定义的原因7.28%（3）这类问题对于CS重定位入的指标也有影响，失败占比未统计。二、 CS或PS重定位最大比特速率无效【问题现象】：使用CDG对重定位失败原因进行分析，发现“无线网络层原因”中的有一项统计为Relocation Preparation Failure原因:请求的最大Bit速率无效”的失败，这种原因的失败的目标小区全部是华为网络下小区，经过定位，失败原因为华为小区出现拥塞，需要华为网络进行扩容和分流处理。目前统计到的失败占比：失败原因失败比例域Relocation Preparation Failure原因:请求的最大Bit速率无效4.93%域Relocation Preparation Failure原因:请求的最大Bit速率无效; 13.85%问题解决方案：使用CDG按照重定位失败原因统计，如果该目标小区作为目标小区，一周下连续5天出现此原因的失败，则该小区需要华为进行标分流或扩容处理。三天或一周统计一次并提交移动推动华为RNC整改。三、 域Relocation Preparation Failure原因:收到的消息与接收状态不匹配;失败原因失败比例Relocation Preparation Failure原因:收到的消息与接收状态不匹配; 11.74%【现象描述】：PS用户向目标SGSN发起relocation required后很快收到SGSN返回的relocation preparation failure，其中携带的原因为“The received message was not compatible with the receiver state”。从大唐提取的cdl分析，这种原因的重定位失败大多发生在上次重定位完成后几十秒内再次发起重定位过程。例：UE首先从源RNC：1289重定位到目标RNC：1288，小区：5763，重定位完成后的8秒，在RNC1288 下再次发起relocation required到SGSN，请求重定位到RNC1289，此时RNC1289的CDL中没有看到SGSN向目标RNC1289发起的Relocation Request消息。SGSN在收到RNC1288发起的Relocation Required消息后很短的时间内给源RNC1288返回了Relocation Preparation Failure，其中携带的原因为“The received message was not compatible with the receiver state”。信令流程如下：【现象分析】：（）由于相同的业务类型从相同的源RNC小区到相同的目标小区有成功也有失败，因此排除数据和消息参数问题问题；（）给源返回Relocation Preparation Failure时并没有向目标发起Relocation Request过程，因此怀疑在SGSN内部发生失败，和目标RNC没有关系；（3）分析一些LOG，发现有在两个RNC下乒乓重定位的情况，因此是否SGSN存在一些限制，比如不能在短时间内在两个RNC下频繁出现重定位，以保证上次资源正常释放？需要SGSN侧研发确认。【后续解决计划】 ：大唐提供出现失败的IMSI和RNC ID，由SGSN侧对这些失败的原因进一步确认。四、 PS系统间切换失败-SCCP故障【现象描述】PS域系统间切换，发起CELL CHANGE FROM UTRAN给终端后收到核心网发送的IU RELEASE COMMAND消息，Cause值为153，RNC解码为: SCCP链路故障（占PS系统间失败的5%），从信令跟踪分析RAN侧未见任何异常。【现象分析】PS域系统间切换，发起CELL CHANGE FROM UTRAN给终端后，后续是终端、BSC以及SGSN之间的信令交互过程，RNC在此过程等待SGSN 发起IU RELEASE COMMAND消息来释放RNC下的用户资源，如果收到IU RELEASE COMMAND消息中携带的原因为“正常释放”，则本次系统间切换成功，如果携带的原因非“正常释放”，记做一次系统间切换失败。因此大唐网络下无法定位SGSN在什么情况下会返回“SCCP故障”的IU RELEASE COMMAND消息,因为PS系统间切换RNC发送CELL CHANGE FROM UTRAN后的信令RNC是不参与的。问题定位和后续思路：（1） 需要联合SGSN分析什么情况会在系统间切换时给RNC返回IU释放中携带原因值为153，153在的定义是什么，对应的含义是什么？（2） 大唐提供出现失败的IMSI和RNC ID，由SGSN侧对这些失败的原因进一步确认。五、 系统间切换Cell Change Order UTRAN Failure: unspecified的失败。失败信息占比Cell Change Order UTRAN Failure: unspecified27.57%现象描述：PS域系统间切换，信令流程为系统间切换阶段，RNC向UE发送系统间切换命令Cell Change Order From UTRAN,4-7s后UE向SGSN发送Cell Change Order From UTRAN Failure，解码为“unspecified”分析针对“unspecified”，协议规定当未出现UE返回的“physicalChannelFailure”、“configurationUnacceptable”、“protocolError”这三种原因时就会使用“unspecified”原因。对出现此类失败终端的IMEI和TAC进行分析，发现有些终端高概率出现unspecified，下面这些的终端unspecified原因的失败一般在本失败的占比超过，经过统计分析这些终端均为Marvell芯片厂家终端。编号TAC号终端厂商终端型号芯片发起次数失败次数失败率286045700中兴ZTE-U880Marvell244687813.19%486118901中兴ZTE-TU880Marvell162905133.15%735675404三星GT-S5820Marvell113204203.71%886141301酷派8150Marvell149874112.74%1186295101中兴U880-V2-90772692.96%1486062600中兴ZTE-TU830Marvell91952432.64%1986041900酷派8810Marvell67782143.16%问题定位和后续思路：需要移动联合终端芯片厂家一起定位。【进展】：安排现场使用Marvell芯片和其它芯片终端进行比对测试，测试结果见插件六、 重定位准备失败-没有请求的资源（PS域出现）【进展】：目前该类问题只在PS域出现，已经定位是由于目标小区电平被虚抬高，小区状态未激活，但是终端在小区附近测量到该小区信号，并在MR中上报该小区为最优小区，触发重定位流程，但是目标小区HSPS查询小区状态未未激活，分配资源失败，失败原因在CDG中为“无可用资源”，已经处理的典型小区有：（1） 科技大厦（W）-1（CI=34051），科技大厦（W）-2(CI=34052)作为目标小区重定位失败。测试情况见插件（2） （2）RNC1285下仙林技师学院-1，-3小区作为目标小区重定位失败。测试情况见插件【后续解决计划】 ：对重定位出现此类问题的目标小区进行实际测试，无线调整。避免同频越区覆盖。七、 系统间切换IU Release Command: 重定位完成定时器超时失败原因失败比例IU Release Command: 重定