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

重定位和系统间切换非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 failure 29.03% Relocation Reqired后面紧跟着IU Release Command :正常释放 15.27% （2）ＣＳ域系统间切换前失败前三占比原因如下,其中Relocation Preparation Failure: 没有请求的资源和U Release Command: 未定义的原因加起来占总失败的32%，因此严重影响CS系统间切换指标。 失败原因 失败比例 Handover From UTRAN Failure: physicalChannelFailure 61.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