《《精编》中兴TD-SCDMA深圳无线网络KPI提升优化案例》由会员分享，可在线阅读，更多相关《《精编》中兴TD-SCDMA深圳无线网络KPI提升优化案例（20页珍藏版）》请在金锄头文库上搜索。
1、第1章 TOPN重点小区分析和优化针对重点小区跟踪其信令，通过信令分析查找PS业务无线接入失败和掉线的原因，提出解决方案进行优化，以及进行优化验证；并对失败原因进行分类统计，提取共性问题解决无线网络同样的问题。下面针对造成PS域呼通率、掉线率差的问题的主要原因进行分析。1.1 PS域呼通率低通过对各重点小区的信令进行分析，对造成PS域接入失败的原因进行规类统计得到，影响PS域无线接通率较差的主要原因是：SIM卡上下行签约速率为2.24Mbps，目前TD-SCDMA系统不支持该上下行速率导致接入失败；网络中的终端厂家测试量非常大、话务量大，导致终端厂家所在的几个小区系统无线资源紧张，引起RAB建
2、立排队等待超时而接入失败；RAB建立过程中无线链路失败导致的接入失败，这主要是由于用户在室内进行呼叫，而室内信号强度弱引起的。1.1.1 SIM卡签约问题SIM卡签约过大，系统没有卡所需的资源，从而被RNC发出RabAssignmentFail造成的接入失败。1.1.1.1 采取的措施和计划该问题的解决需要协调移动，更改SIM的签约，避免因签约过大造成大量的接入失败。1.1.1.2 案例分析IMSI：460077107501317用户在50992小区接入失败，具体信令如下：从上面信令可以看出（RabAssignmentRequest），用户申请的上下行速率均为2.24Mbps速率，因此RNC直
3、接给CN返回 RabAssignmentFail信令。从目前TD-SCDMA系统支持的上行速率来看，2.24Mbps的速率是肯定不支持的；而且从系统资源来看，在不支持HSUPA的情况下，系统无法提供下行2.24Mbps所需的资源。从而导致接入失败。根据上图RabAssignmentFail的解码消息，可以看出RabAssignmentFail的原因是radioNetwork = TRANAP_requested_maximum_bit_rate_for_ul_not_available，也可以说明主要是因为无法满足要求的上行最大速率导致的接入失败。1.1.2 系统资源问题系统资源问题主要表现在
4、无线资源不足，引起RAB排队等待超时，从而导致RAB指配失败。具体表现为：CN向RNC发起RabAssignmentRequest 后，由于无线资源不足导致RNC很快回RabAssignmentQueued消息；当等待8秒钟后，达到最大的等待时间而无线资源仍然不足时，RNC回消息RabAssignmentFail给CN，最终导致接入失败。1.1.2.1 采取的措施和计划对于系统资源不足的问题，可以通过扩容解决；也可以打开RBC算法，这样系统会在无线资源紧张的时候根据用户的实际情况进行资源调整，降低用户速率空出资源以接纳新的用户，提高PS域的无线接通率。1.1.2.2 案例分析问题描述：IMSI
5、：460077107700719用户在50992小区接入失败。问题分析：跟踪该小区的接入失败信令，具体信令如下：从上面信令中RabAssignmentRequest的解码消息可以看出，用户申请的上下行速率为128K/384Kbps速率，目前TD-SCDMA系统满足该上下行速率的业务接纳。对上面小区信令分析发现，在11：14：49秒RNC收到CN的RabAssignmentRequest消息后，RNC很快会回RabAssignmentQueued消息；表明由于系统无线资源不足，RAB请求进入队列等待；当等待8秒钟后，达到最大的等待延时而无线资源仍然不足时，RNC即回消息RabAssignment
6、Fail给CN，导致接入失败；并且由于接入失败导致网络侧释放IU连接。在现场进行验证测试时，发现IMSI：460077107502074在50922小区进行PS384业务后，始终无法切换到50992小区（主频点10088、扰码63），此时50992小区的PCCPCH RSCP已经比50922信号强20dB了，具体见下图。从下图信令中RabAssignmentRequest的解码消息可以看出，用户申请的上下行速率为64K/384Kbps速率，从下面后台跟踪的信令上看，11：02：47秒RNC收到测量报告后接着又重新下发了测量控制消息。检查相关配置无误，因此判断目标小区50992存在资源不足从而造
7、成RNC没有判决切换，从之前的信令分析当中也可以看到50992小区资源不足。为此，通过后台查看码道分配情况。从码道分配情况可以看出，已经没有足够的资源接纳1个PS384业务，因为10080为HSDPA的频点，下行大部分码道分配给了PDSCH使用；10096频点已经被1个PS384K的业务占用了；10088频点已经有1个PS128K的业务使用，也没有足够的资源分配给新的PS384K业务。码道分配情况具体见下图：因此，即使RNC收到了切换测量报告，但是由于目标小区50992没有足够的资源，所以RNC没有判决切换，从而没有发起切换操作，而是接着RNC又重新下发了测量控制消息。同时，从上图IMSI：4
8、60077107502074进行切换的时间看，测试手机到11：17：43秒还在发出切换请求，但RNC始终没有判决切换。结合50992小区的码道分配情况，可以看出IMSI：460077107700719用户的确是因为50992小区系统无线资源不足导致了接入失败。如上图所示，在9月18日3个小时内总共有12次RabAssignmentQueued、由于系统资源不足导致了接入失败，其中IMSI：460077107700719用户就达10次，从而直接导致了PS域无线接通降差。解决方案：由于通过扩容来解决系统资源不足的问题不能马上实现，以及避免其他小区相同接入失败的问题，快速的提升PS域的无线接通率指标
9、，因此通过打开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-237429
10、36.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 9
11、1.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 采取的措施和计划定期进行后台参数的核查
12、，保证参数配置的准确和合理性，避免由于参数配置导致的无线接入失败现象。1.1.3.2 案例分析问题描述：由后台KPI发现南园村2扇和3扇PS域的无线接通率很差。无线接通率较低的原因主要是在用户进行PS业务时RAB建立成功率很低。问题分析：对该问题进行定点和DT现场复现。测试数据如下：通过路测数据和现场的情况来看，定点测试位置的PCCPCH RSCP和PCCPCH C/I良好。从路测采集的信令来看，南园村2扇和3扇在进行PDP激活时被拒绝了，从而导致了接入失败。具体的信令如下：从Activate PDP ContextReject的解码消息来看，拒绝的原因Protocol error, unsp
13、ecified 。Activate PDP ContextReject具体的解码消息图如下：从后台跟踪的信令来看，UE在发起Activate PDP ContextRequest后的RAB建立过程中，NodeB向RNC上报RadioLinkReconfigurationReady后，RNC立即向NodeB下发了一条RadioLinkReconfigurationCancel，从而导致了RAB建立失败和PDP激活失败。具体的后台信令如下图所示：RadioLinkReconfigurationCancel信令的下发是RNC和NodeB之间的事情，涉及Iub口。通过查看后台的参数配置，发现RNC和N
14、odeB的ALL2配置不一致。解决方案：在后台进行整表同步，保证RNC和NodeB的ALL2配置一致。优化结果：这2个小区PDP激活正常和PS业务接入正常。1.1.4 网络中存在的干扰问题来自系统内或系统外的干扰能导致接入失败和掉话现象。1.1.4.1 采取的措施和计划通过路测和后台测量确定是否存在干扰，排查干扰产生的原因和干扰源，并进行针对性的优化。1.1.4.2 案例分析问题描述：后台KPI表明南山钜建2扇PS域的无线接通率很差。无线接通率较低的原因主要是在用户进行PS业务时RAB建立成功率很低。问题分析：对该问题进行定点和DT现场复现。测试数据如下：通过路测数据和现场的情况来看，在上图的
15、红色圆圈内PCCPCH C/I部分区域较差，并且掉线一次。在该区域还出现PS域下载速率下降和不稳定的现象。而南山钜建2扇覆盖的其他区域的下载速率能达到业务的要求速率、并且速率稳定。从路测现场数据来看，在上述区域的BLER比较高，下行SIR很差，下行时隙的ISCP也比较高、并且大于同时隙的RSCP。因此确定该区域存在下行干扰。具体情况见下图。由于附近没有室内的站点，因此把南山钜建2扇的频点修改为10071，并进行验证测试。从路测数据和现场情况来看，BLER和下行时隙的ISCP已经正常了，下载速率也稳定和达到业务的要求了。具体情况见下图。因此分析确定该区域的下行干扰是系统内部产生的干扰。解决方案：结合周边区域站点使用的频点情况，最终修改南山钜建2扇的频点为10096，并进行验证测试。优化结果：从路测数据和现场情况来看，BLER和下行时隙的ISCP同样正常，下载速率同样满足业务的要求。具
