TD系统内重定位成功率低问题分析.doc

TD系统内重定位成功率低问题分析 一、概述 TD-SCDMA系统中系统内重定位成功率低的问题一直是网络指标提升的难题之一，在网络测试过程中发现由于UE或网络侧存在不合理因素等原因，导致系统内重定位成功率低，用户感知受到影响。下面针对此问题给出了一些问题定位及解决方法，优化人员在日常工作中可根据此说明对遇到的此类问题进行处理，加快工作效率。 二、问题分析和解决方法 通过查看RNC CDL软件保存的IU口信令发现大部分的Relocation Required失败都是SGSN在收到请求后给RNC立刻回了Relocation Reparation Failure，原因是： 收到的消息与接受状态不匹配； 未知的Target RNC； trellocalloc-expiry（重定位超时）。 交换侧发现MSC收到很多的Relocation Required的消息后，极短时间内就又收到了原RNC发的Relocation Cancel消息，导致重定位失败，通过信令我们发现这类情况大部分发生在CS和PS业务并发的情况下，RNC向MSC和SGSN同时发起重定位请求，然后SGSN立刻给RNC回了Relocation Reparation Failure，完后RNC对MSC发起了Relocation Cancel，导致重定位失败，根据集团公司CS+PS并发业务重定位原则，重定位请求一方失败RNC就会取消全部请求。在SGSN侧也发现了此类现象，原因是MSC给RNC回了Relocation Reparation Failure而导致RNC对SGSN发起了Relocation Cancel。 “未知的Target RNC”原因的重定位失败 “未知的Target RNC”原因的重定位失败一般是由于核心网侧SGSN或者MSC数据配置错误而导致，因此通过全面核查SGSN或者MSC数据配置，排查错误数据，就可以排除此类问题。 原因值为“收到的消息与接受状态不匹配”的重定位失败 对于原因值为“收到的消息与接受状态不匹配”的重定位失败，我们研究发现，在终端做PS业务从RNCA重选到RNCB的过程中，RNCA收到终端的测量报告，发起重定位请求，终端重选到RNCB，并且完成在RNCA的IU口释放。由于目前商务终端的原因，造成手机开机第一次做PS业务后，虽然最后会释放IU口，进而释放资源，但是会一直保持PDP激活状态。目前终端重选到RNCB后从完成在RNCA的IU口释放计时，15S后终端才会发起路由区更新请求。如下图所示： 而2G中PS业务发生跨路由区的重选，完成重选后会很快上报路由区更新请求。T网CS域业务在发生RNC间切换时，在新的RNC电话挂机后也会很快上报位置区更新请求。目前T网PS业务发生RNC间重选，重选成功后在新的RNC15S后才上报路由区更新请求，这就导致在RNC交界区，这15S内新的RNC会给终端下发测量控制，然后终端满足切换条件上报测量报告，新的RNC就会给SGSN上报重定位请求，由于终端没有完成在新的RNC路由区更新，这时SGSN会很快回复Relocation Reparation Failure，原因值为“收到的消息与接受状态不匹配”。 测试中发现在使用联芯芯片手机测试PS系统内重定位问题时出现relocation complete后15s才能收到UE上报的RAU REQ消息，从空口分析relocation complete后UE已经上报了RAU REQ消息，RNC侧却没有收到。但使用T3G芯片手机进行PS系统内重定位测试时就不存在该问题，relocation complete完成后1s内就能上报RAU REQ消息。 测试中发现从CN侧收不到security modem command消息，该消息中携带有完整性保护IE。安全模式控制过程主要用来在移动通信网络中数据的安全性和完整性，是用户设备和UTRAN之间的接口的协议处理过程。核心网用该过程通知RNC应该采用的加密模式和完整性保护模式。 （1）、对于联芯芯片终端：在SRNS relocation过程中，如果CN下发完整性保护IE，RNC发送的RB reconfiguration消息中也携带了完整性保护IE，在RRC收到RAU消息后，要等SRB3重建结束之后才将RAU消息发送给RLC，此时就不存在RNC收不到RAU REQ消息的情况；如果CN没有下发完整性保护IE，RNC发送的RB reconfiguration消息中没有携带完整性保护IE，则RRC收到RAU消息，会立刻发给RLC。之后再次重建RLC，就会造成RAU一直不能发送给RNC，出现15s后才能收到RAU REQ消息。空口和后台跟踪如下： （2）、T3G芯片终端：在CN没有下发security modem command消息的情况下，进行PS系