搜索
RNC边界优化专题TD网规网优部乔晓峰1608042009年1月主要内容•日常优化中RNC边界存在主要问题•跨RNC切换优化•跨LAC接通优化日常优化中RNC边界存在主要问题内部公开▲日常优化中RNC边界存在主要问题前提覆盖优化完毕，PCCPCHRSCP及C/I满足网络要求主要问题1、跨RNC切换成功率较低2、跨LAC呼叫接通接通率较低内部公开▲Iub协议、主要功能NBAP：（Iub控制面协议）NBAP协议的功能主要包括NodeB逻辑操作维护功能以及专用NBAP功能。NodeB逻辑操作维护功能主要包括小区、公共信道的建立、重配置和释放以及小区和NodeB相关的一些测量控制，还有一些故障管理功能，例如资源的闭塞、解闭塞、复位等。专用NBAP功能主要包括无线链路的增加、删除和重配置、无线链路相关测量的初始化和报告、无线链路故障管理等功能。FP：（Iub用户面协议）维护Iub口传输承载的同步Iub口用户面数据帧的转送Iub口用户面控制帧的传送•跨RNC切换优化内部公开▲跨RNC切换正常流程跨RNC切换是重定位过程，以硬切换方式实现。内部公开▲跨RNC切换正常流程源RNC后台重定位正常信令流程。目标RNC后台重定位正常信令流程。内部公开▲跨RNC切换问题分析通过对沈阳跨RNC切换失败问题进行跟踪与分析，现场对问题的原因进行了总结，具体分为以下三种原因：终端问题原因目标小区同步失败原因邻区参数设置原因内部公开▲终端问题原因典型信令如下所示：内部公开▲终端问题原因现象：该IMSI刚刚进行完成一次重定位，仅仅间隔40ms该IMSI又发起一次切换请求，但是当时网络中无论1G还是2A事件的触发参数Time_to_Trigger均为1280ms，且测量报告中的内容也并非新小区测量控制所规定的，由此看来终端并没有按照新下发的测量控制上报测量报告。协议：25.331协议上明确指出“8.3.5HardhandoverWhenperforminghardhandoverwithchangeoffrequency,theUE：1stopallintrafrequencyandinterfrequencymeasurementreportingCELL_INFO_LIST.Eachstoppedmeasurementisrestartedreceivedwiththecorrespondingmeasurementidentity.”根据协议和现场采集的信令有理由相信终端处理有误。与协议不符。内部公开▲终端问题原因在这种情况下，系统侧当时的处理方式：核心网（华为）的处理策略：无线侧给核心网侧上报RelocationComplete消息后，核心网需要调整并进行释放资源，存在一段系统保护时间，在此时间内对于同一终端用户上报的切换请求，核心网不予处理。同时由于目前网络处理能力，在核心网收到RANAP：Iu-ReleaseComplete消息之后的0.17秒内，对于同一终端用户上报的重定位请求，核心网同样不予处理。RNC的处理策略：RNC侧在上报RelocationComplete消息后，认为前一次流程结束，可再次进行重定位。终端完成上次切换后仅间隔几十毫秒上发测量报告，CN处理能力有限，此时尚未将IU资源释放完毕，导致CN对重定位请求无响应，RNC等待定时器（10s）超时后发起IU释放流程，导致掉话。内部公开▲终端问题原因解决方法：解决终端问题。需要协调各个终端厂家确定终端能否正确理解系统下发的测量控制消息，对于不能按照协议理解测量控制消息的终端确定如何解决处理。核心网进行策略调整。结合2G核心网对类似事件处理的方法和流程，目前核心网简单丢弃消息不做处理的策略是需要商榷的。如果核心网考虑需要保护避免Iu口拥塞，应该给RNC返回RelocationPreparationFailure消息，或者可以缓存处理等待资源释放后处理。接入网进行策略调整。如果无线侧能够对终端上报的非法测量报告进行控制，不仅仅对切换条件进行判断，就能够避免该问题发生。内部公开▲目标小区同步失败原因硬切换时与目标小区同步过程硬切换过程中在收到RB重配消息后，UE需要同目标小区建立同步，在此期间容易由于UP时隙干扰或UE没有收到FPACH，导致RB重配失败。内部公开▲目标小区同步失败原因现场分析的主要原因分类为：UP时隙干扰。当用户处于弱场区域、小区边缘时此问题会更加明显。在信号较强区域不会太明显，这就是路测时切换指标良好，而后台指标较差的原因之一。可以通过UP时隙偏移解决。无线环境差导致UE没有收到FPACH。主要是一些无室内分布的楼宇（住宅所占比重较大）及覆盖弱区。用户在弱场进行切换，导致RB重配失败。基站帧同步问题。SFN帧不同步，当该问题发生时站间切换掉话率100%。通过运行GPS脚本，并进行系统帧号同步后，UE可以和其他站点正常切换。内部公开▲邻区参数设置原因主要有以下两种情况：网络中存在邻小区关系的漏配或单边邻区的情况。存在邻区同频同扰码情况，导致虚假的邻小区关系造成切换失败。解决方法：此类问题要通过对全网扰码与邻区关系的检查、梳理后，调整解决。内部公开▲工作建议由于终端测量问题引起的，需要移动推动核心网与终端厂商协同解决，同时我司无线网络系统侧也应该考虑规避的手段与措施。由于UE和目标小区不能上行同步问题导致的需要区别对待。对UP时隙有干扰的小区进行UPShifting，规避UP时隙干扰；检查目标NodeB是否正常工作，系统帧是否同步，排除NodeB故障。由于新建站点、无线环境变化等因素，需要及时对邻区参数设置进行相应修改。•跨LAC接通优化内部公开▲跨LAC接通问题现象背景：目前我司TD-SCDMA网络规划按照每RNC设置为一个位置区和路由区。现象：通过对日常测试路测数据的分析发现存在由于主叫起呼时被叫UE正在进行位置更新，导致被叫未被寻呼到的现象。影响：该过程对起呼成功率指标影响较大。内部公开▲跨LAC接通问题定位核心网的寻呼策略为：核心网寻呼2次，第一次寻呼下发后计时6秒，超过6秒没有收到寻呼响应下发第二次寻呼。第二次寻呼时会从VLR中取新的数据，如果被叫UE在第一次寻呼时正在做位置更新(第一次寻呼失败)，那么第二次寻呼将在新的LAC区下发寻呼消息，寻呼到被叫UE。经过测试验证，核心网下发消息如策略所述，具体信令见下图：内部公开▲跨LAC接通问题分析对问题区域进行复测，发现主要由于UE在跨LAC区发生乒乓重选，导致被叫UE两次均无法被寻呼到。举例：由于被叫从RNC1惠工2（频点10088，扰码66）重选至RNC5大明集团3（频点10120，扰码108），并在10:06:13.671于RNC5完成位置更新，因此在主叫10:06:15.593收到网络回应CallProceeding时，网络向被叫所在LAC（RNC5）发第一次寻呼。内部公开▲跨LAC接通问题分析内部公开▲跨LAC接通问题分析但是被叫在10:06:15.406又重选回RNC1惠工2小区，因此无法收到第一次寻呼消息。并且被叫在10:06:17.843才开始在RNC1发起位置更新，至10:06:22:578完成，此时已经超出第一次寻呼消息等待（6秒）时间，第二次寻呼仍然发送在RNC5。被叫UE仍然无法收到寻呼消息，造成主叫起呼失败。内部公开▲跨LAC接通问题分析内部公开▲跨LAC接通问题解决方法要解决该问题最重要的是消除跨LAC区乒乓重选。消除跨LAC区乒乓重选主要方法有：调整覆盖，控制重选区域。调整重选参数。对LAC区进行调整，避免分解出现在用户密集区域。