中兴TD-SCDMA深圳无线网络KPI提升优化案例.doc

中兴TD-SCDMA深圳无线网络KPI提升优化报告第1章 TOPN重点小区分析和优化针对重点小区跟踪其信令，通过信令分析查找PS业务无线接入失败和掉线的原因，提出解决方案进行优化，以及进行优化验证；并对失败原因进行分类统计，提取共性问题解决无线网络同样的问题。下面针对造成PS域呼通率、掉线率差的问题的主要原因进行分析。1.1 PS域呼通率低通过对各重点小区的信令进行分析，对造成PS域接入失败的原因进行规类统计得到，影响PS域无线接通率较差的主要原因是：SIM卡上下行签约速率为2.24Mbps，目前TD-SCDMA系统不支持该上下行速率导致接入失败；网络中的终端厂家测试量非常大、话务量大，导致终端厂家所在的几个小区系统无线资源紧张，引起RAB建立排队等待超时而接入失败；RAB建立过程中无线链路失败导致的接入失败，这主要是由于用户在室内进行呼叫，而室内信号强度弱引起的。1.1.1 SIM卡签约问题SIM卡签约过大，系统没有卡所需的资源，从而被RNC发出RabAssignmentFail造成的接入失败。1.1.1.1 采取的措施和计划该问题的解决需要协调移动，更改SIM的签约，避免因签约过大造成大量的接入失败。1.1.1.2 案例分析IMSI：460077107501317用户在50992小区接入失败，具体信令如下：从上面信令可以看出（RabAssignmentRequest），用户申请的上下行速率均为2.24Mbps速率，因此RNC直接给CN返回 RabAssignmentFail信令。从目前TD-SCDMA系统支持的上行速率来看，2.24Mbps的速率是肯定不支持的；而且从系统资源来看，在不支持HSUPA的情况下，系统无法提供下行2.24Mbps所需的资源。从而导致接入失败。根据上图RabAssignmentFail的解码消息，可以看出RabAssignmentFail的原因是radioNetwork = TRANAP_requested_maximum_bit_rate_for_ul_not_available，也可以说明主要是因为无法满足要求的上行最大速率导致的接入失败。1.1.2 系统资源问题系统资源问题主要表现在无线资源不足，引起RAB排队等待超时，从而导致RAB指配失败。具体表现为：CN向RNC发起RabAssignmentRequest 后，由于无线资源不足导致RNC很快回RabAssignmentQueued消息；当等待8秒钟后，达到最大的等待时间而无线资源仍然不足时，RNC回消息RabAssignmentFail给CN，最终导致接入失败。1.1.2.1 采取的措施和计划对于系统资源不足的问题，可以通过扩容解决；也可以打开RBC算法，这样系统会在无线资源紧张的时候根据用户的实际情况进行资源调整，降低用户速率空出资源以接纳新的用户，提高PS域的无线接通率。1.1.2.2 案例分析问题描述：IMSI：460077107700719用户在50992小区接入失败。问题分析：跟踪该小区的接入失败信令，具体信令如下：从上面信令中RabAssignmentRequest的解码消息可以看出，用户申请的上下行速率为128K/384Kbps速率，目前TD-SCDMA系统满足该上下行速率的业务接纳。对上面小区信令分析发现，在11：14：49秒RNC收到CN的RabAssignmentRequest消息后，RNC很快会回RabAssignmentQueued消息；表明由于系统无线资源不足，RAB请求进入队列等待；当等待8秒钟后，达到最大的等待延时而无线资源仍然不足时，RNC即回消息RabAssignmentFail给CN，导致接入失败；并且由于接入失败导致网络侧释放IU连接。在现场进行验证测试时，发现IMSI：460077107502074在50922小区进行PS384业务后，始终无法切换到50992小区（主频点10088、扰码63），此时50992小区的PCCPCH RSCP已经比50922信号强20dB了，具体见下图。从下图信令中RabAssignmentRequest的解码消息可以看出，用户申请的上下行速率为64K/384Kbps速率，从下面后台跟踪的信令上看，11：02：47秒RNC收到测量报告后接着又重新下发了测量控制消息。检查相关配置无误，因此判断目标小区50992存在资源不足从而造成RNC没有判决切换，从之前的信令分析当中也可以看到50992小区资源不足。为此，通过后台查看码道分配情况。从码道分配情况可以看出，已经没有足够的资源接纳1个PS384业务，因为10080为HSDPA的频点，下行大部分码道分配给了PDSCH使用；10096频点已经被1个PS384K的业务占用了；10088频点已经有1个PS128K的业务使用，也没有足够的资源分配给新的PS384K业务。码道分配情况具体见下图：因此，即使RNC收到了切换测量报告，但是由于目标小区50992没有足够的资源，所以RNC没有判决切换，从而没有发起切换操作，而是接着RNC又重新下发了测量控制消息。同时，从上图IMSI：460077107502074进行切换的时间看，测试手机到11：17：43秒还在发出切换请求，但RNC始终没有判决切换。结合50992小区的码道分配情况，可以看出IMSI：460077107700719用户的确是因为50992小区系统无线资源不足导致了接入失败。如上图所示，在9月18日3个小时内总共有12次RabAssignmentQueued、由于系统资源不足导致了接入失败，其中IMSI：460077107700719用户就达10次，从而直接导致了PS域无线接通降差。解决方案：由于通过扩容来解决系统资源不足的问题不能马上实现，以及避免其他小区相同接入失败的问题，快速的提升PS域的无线接通率指标，因此通过打开RBC算法来解决RAB排队超时导致接入失败的问题。优化结果：RBC算法开关是2008-9-19打开，下面是后台汇总的2008-9-12008-9-7和2008-9-202008-9-22每天PS域的无线接通率指标。时间分组域业务流量PS域RAB指派建立成功RAB数目PS域RAB建立请求的RAB数目PS域RAB建立成功率PS域RRC连接建立成功次数PS域RRC连接建立尝试次数（业务相关）PS域RRC连接建立成功率（呼叫相关）PS域无线接通率KBYTE%2008-9-12165678.26 1686176195.74 1181119099.24 95.02 2008-9-23742936.27 3551392490.49 2910296498.18 88.85 2008-9-33982711.80 5768633990.99 4016406098.92 90.01 2008-9-44896351.13 5328569393.59 4119417698.64 92.31 2008-9-53575283.35 5329588790.52 4076413998.48 89.14 2008-9-64887054.18 5986647892.41 3868413693.52 86.42 2008-9-73816851.32 5110538894.84 3553370295.98 91.02 2008-9-204692675.28 6010622696.53 4191425598.50 95.08 2008-9-216589536.37 6892712496.74 4852489899.06 95.83 2008-9-226584091.93 8390859997.57 6193622299.53 97.11 从RBC算法开关打开前后PS域无线接通率的对比情况来看，RBC算法开关打开后，PS域无线接通率明显的改善了。1.1.3 参数配置问题可能由于部分系统参数设置存在问题或前后台配置不一致，可以导致PS域无线接入失败。1.1.3.1 采取的措施和计划定期进行后台参数的核查，保证参数配置的准确和合理性，避免由于参数配置导致的无线接入失败现象。1.1.3.2 案例分析问题描述：由后台KPI发现南园村2扇和3扇PS域的无线接通率很差。无线接通率较低的原因主要是在用户进行PS业务时RAB建立成功率很低。问题分析：对该问题进行定点和DT现场复现。测试数据如下：通过路测数据和现场的情况来看，定点测试位置的PCCPCH RSCP和PCCPCH C/I良好。从路测采集的信令来看，南园村2扇和3扇在进行PDP激活时被拒绝了，从而导致了接入失败。具体的信令如下：从Activate PDP ContextReject的解码消息来看，拒绝的原因Protocol error, unspecified 。Activate PDP ContextReject具体的解码消息图如下：从后台跟踪的信令来看，UE在发起Activate PDP ContextRequest后的RAB建立过程中，NodeB向RNC上报RadioLinkReconfigurationReady后，RNC立即向NodeB下发了一条RadioLinkReconfigurationCancel，从而导致了RAB建立失败和PDP激活失败。具体的后台信令如下图所示：RadioLinkReconfigurationCancel信令的下发是RNC和NodeB之间的事情，涉及Iub口。通过查看后台的参数配置，发现RNC和NodeB的ALL2配置不一致。解决方案：在后台进行整表同步，保证RNC和NodeB的ALL2配置一致。优化结果：这2个小区PDP激活正常和PS业务接入正常。1.1.4 网络中存在的干扰问题来自系统内或系统外的干扰能导致接入失败和掉话现象。1.1.4.1 采取的措施和计划通过路测和后台测量确定是否存在干扰，排查干扰产生的原因和干扰源，并进行针对性的优化。1.1.4.2 案例分析问题描述：后台KPI表明南山钜建2扇PS域的无线接通率很差。无线接通率较低的原因主要是在用户进行PS业务时RAB建立成功率很低。问题分析：对该问题进行定点和DT现场复现。测试数据如下：通过路测数据和现场的情况来看，在上图的红色圆圈内PCCPCH C/I部分区域较差，并且掉线一次。在该区域还出现PS域下载速率下降和不稳定的现象。而南山钜建2扇覆盖的其他区域的下载速率能达到业务的要求速率、并且速率稳定。从路测现场数据来看，在上述区域的BLER比较高，下行SIR很差，下行时隙的ISCP也比较高、并且大于同时隙的RSCP。因此确定该区域存在下行干扰。具体情况见下图。由于附近没有室内的站点，因此把南山钜建2扇的频点修改为10071，并进行验证测试。从路测数据和现场情况来看，BLER和下行时隙的ISCP已经正常了，下载速率也稳定和达到业务的要求了。具体情况见下图。因此分析确定该区域的下行干扰是系统内部产生的干扰。解决方案：结合周边区域站点使用的频点情况，最终修改南山钜建2扇的频点为10096，并进行验证测试。优化结果：从路测数据和现场情况来看，BLER和下行时隙的ISCP同样正常，下载速率同样满足业务的要求。具体情况见下图。1.2 PS域掉线率高PS域无线掉线率指标普遍偏高，其原因首先与PS业务的特点相符合，PS用户相对于CS用户来说保持时间较长，并且呼叫的次数比较少，这样一来会造成PS业务的掉话率相对于CS业务的掉话率来说要高些；其次，PS用户一般分布在室内或车内，而这些地方覆盖较差，这也是影响到PS业务掉话率较高的一个主要原因；第三，目前终端不成熟，长时间的PS业务会由于终端原因造成掉话；第四，无线链路失败导致PS业务掉线。1.2.1 终端问题终端的性能是影响到PS业务掉话率较高的一个重要原因，特别是长时间的PS业务会由于终端异常引起掉话。1.2.1.1 采取的措施和计划更换南山展示厅因终端原因造成大量掉话的宇龙酷派演示终端；有待终端厂家改善商用终端的性能；对引起大量掉话现象的个别终端或个别类型终端进行处理，以改善其性能。1.2.1.2 案例分析问题描述：从后台KPI指标发现深圳移动TD-SCDMA南山展示厅PS业务的无线掉话率较差。该处为TD业务演示场所，用户发起业务次数较多、话务量占全网比重较大，对整体网络指标影响很大。初步判断号码终端掉线频繁，该号码占用52082小区（主频点10096、扰码93）。问题分析：深圳移动TD-SCDMA南山展示厅建设了室内分析系统，配置2个小区、2个小区配置5M异频频点；室外周边小区没有和南山展示厅室内系统5M同频的小区；在南山展示厅室内进行测试，室外小区信号相对室内信号很弱，相差20dB左右，室内覆盖良好。测试结果见下图。为了解决南山展示厅PS业务掉线的问题，在展示厅进行观察和测试。找到号码终端，该终端为做流媒体演示的酷派手机。通过了解，流媒体演示由工作人员自己操作，用户不能直接操作。直接对号码酷派手机进行反复操作，发现该手机掉线问题比较明显，从后台跟踪信令发现该终端经常会发起小区更新；继续操作发现该手机经常在重开机后还是做不了业务，现场工作人员也反映该终端掉线比较频繁；多次操作后，该终端出现搜不到卡和没有网络的情况，宇龙酷派工作人员也反馈可能终端长时间工作过热导致终端主板线路故障而使手机收不到网络，因此判断掉线可能是由该终端问题造成的。为了验证该酷派终端问题，在演示厅内端外其他终端业务正常展示的情况下，更换终端进行测试。采用凯明测试手机连接RNT路测软件，占用52082小区进行流媒体业务测试，测试40分钟没有掉线；之后每5分钟一次断开重新拨号测试，在第6次时一段时间后速率会明显下降，但并不影响流媒体业务。采用商用终端ZTE U980、ZTEU85在同一小区进行流媒体业务，演示厅内其他终端业务正常展示，测试5次共90分钟左右，没有掉线情况发生。由上判码使用的酷派终端性能问题导致了PS业务掉线频繁。因此建议更换该号码使用终端，避免因终端问题引起的掉线。1.2.2 无线链路失败问题弱覆盖和网络中存在的干扰都可以引起无线链路失败，从而导致PS业务掉线。1.2.2.1 采取的措施和计划对于室外弱覆盖区域进行覆盖优化调整或增补站点改善覆盖；对于室内弱覆盖区域通过建设室内分布系统改善覆盖；对于网络中存在的干扰，通过路测和后台测量确定是否存在干扰，排查干扰产生的原因和干扰源，并进行针对性的优化。1.2.2.2 案例分析问题描述：从后台KPI指标发现朗山北T_1、朗山二T_3小区的PS业务的无线掉话率较差。问题分析：通过现场DT测试数据来看，朗山北T_1、朗山二T_3覆盖区域的PCCPCH RSCP和PCCPCH C/I良好。下面是测试的PCCPCH RSCP和PCCPCH C/I结果图。从这2个小区跟踪的信令分析来看，发生PS业务掉话的呼叫主要集中在5个号码上，分别是IMSI:460077107900285、460077107902711、460077107902713、460077107902841、460077107903318。通过用户回访得知这几个用户是宇龙酷派的测试号码，宇龙酷派终端测试主要是在办公室内进行的，由于宇龙酷派信息港所在楼宇没有建设室内分布系统，从而只能采用室外站点信号进行覆盖。同时，从下面的宇龙酷派信息港位置示意图可以看出，其所在位置处于多个小区的边缘中心（通过宇龙酷派信息港室内测试，主要由朗山北T_1、朗山二T_3这2个小区进行覆盖）。由于室内墙体穿透损耗的影响，覆盖宇龙酷派信息港办公大楼的室外信号较弱，没有较强的主服务小区，切换频繁；由于宇龙酷派测试量大、话务量大，所以这2个小区的每个载波负荷重，而朗山北T_1主频点是10080、朗山二T_3主频点是10096，属于5M同频，在没有主服务小区的情况下业务信道有一定的同频干扰。这都容易导致无线链路失败的情况，从而引起掉话。宇龙酷派信息港的位置示意图：解决方案：在宇龙酷派信息港办公楼建设室内分部系统，彻底解决因室内覆盖信号弱、小区容量不足导致的接入失败和掉话问题。在室内分布系统建设开通之前，可以通过调整朗山北T_1、朗山二T_3的频点使其为5M异频，避免2个小区之间的同