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

TD系统内重定位成功率低问题分析一、概述TD-SCDMA系统中系统内重定位成功率低的问题一直是网络指标提升的难题之一，在网络测试过程中发现由于UE或网络侧存在不合理因素等原因，导致系统内重定位成功率低，用户感知受到影响。下面针对此问题给出了一些问题定位及解决方法，优化人员在日常工作中可根据此说明对遇到的此类问题进行处理，加快工作效率。二、问题分析和解决方法通过查看RNC CDL软件保存的IU口信令发现大部分的Relocation Required失败都是SGSN在收到请求后给RNC立刻回了Relocation Reparation Failure，原因是：1) 收到的消息与接受状态不匹配；2) 未知的Target RNC；3) 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。1. “未知的Target RNC”原因的重定位失败“未知的Target RNC”原因的重定位失败一般是由于核心网侧SGSN或者MSC数据配置错误而导致，因此通过全面核查SGSN或者MSC数据配置，排查错误数据，就可以排除此类问题。2. 原因值为“收到的消息与接受状态不匹配”的重定位失败对于原因值为“收到的消息与接受状态不匹配”的重定位失败，我们研究发现，在终端做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系统内重定位，就不会出现15s后才能收到RAU REQ消息。如下图：3、在定位该问题中对比兰州TD网络（华为核心网，大唐无线接入网）的测试数据，采用同样的终端进行测试，发现CN下发了security modem command消息，消息中携带有完整性保护IE。所以在进行PS系统内重定位时不存在15s的现象。数据如下：最终联芯终端已经确认存在问题，联芯答复如下：RB重配的消息里没有携带完保信息，终端切换完成后，虽然是立即发起的RAU req（pos43596和pos57137），但是在确认消息（pos43610和pos57156）里带的status ind指示的都是0，从原语中查看P_RLC_ULR_DATA_CNF 里面携带的status指示的是0表示没有发送出去，原因是RRC在收到rbReconfigComplete后, 给RLC发了重建命令, 导致RAU的数据包直接丢了,后续RRC也没有重发该消息, 直到NAS重做RAU才成功了。根据此类情况，联芯科技已经开发出了8130测试机的更新版本，解决了此类问题。但目前商用终端（也存在15s现象）大部分采用联芯芯片，升级商用终端存在一定困难，可以从网络侧进行调整，打开完整性保护IE，解决此类问题。但是终端的问题还需要厂家安排尽快升级才能从更本解决这类问题。3. 原因值为“trellocalloc-expiry”的重定位失败对于原因值为“trellocalloc-expiry（重定位超时）”的重定位失败，我们研究发现对于CS+PS并发业务，MSC和SGSN一方给RNC回了失败，RNC就会给另一方发起重定位取消，这在MSC或者SGSN上就可以看到1S内同时收到了Relocation Required和Relocation Cancel消息，对于MSC和SGSN来说有个定时器说明10S内如果MSC或者SGSN收到两条重定位请求，执行第一条请求，这就导致10S内发起的第二个请求MSC或者SGSN不处理，如下所示:可以看到第一个Relocation Required和Relocation Cancel消息同时上报SGSN，进而导致SGSN没有处理第二个Relocation Required，10S后给RNC回了Relocation Reparation Failure，原因值为“trellocalloc-expiry（重定位超时）”。此类问题交换侧可以通过修改定时器解决，无线侧可以通过计数器控制此类想象发生后