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

第第1 1章章 TOPNTOPN 重点小区分析和优化重点小区分析和优化 针对重点小区跟踪其信令，通过信令分析查找 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-1 2165678.26 1686 1761 95.74 1181 1190 99.24 95.02 2008-9-2 3742936.27 3551 3924 90.49 2910 2964 98.18 88.85 2008-9-3 3982711.80 5768 6339 90.99 4016 4060 98.92 90.01 2008-9-4 4896351.13 5328 5693 93.59 4119 4176 98.64 92.31 2008-9-5 3575283.35 5329 5887 90.52 4076 4139 98.48 89.14 2008-9-6 4887054.18 5986 6478 92.41 3868 4136 93.52 86.42 2008-9-7 3816851.32 5110 5388 94.84 3553 3702 95.98 91.02 2008-9-20 4692675.28 6010 6226 96.53 4191 4255 98.50 95.08 2008-9-21 6589536.37 6892 7124 96.74 4852 4898 99.06 95.83 2008-9-22 6584091.93 8390 8599 97.57 6193 6222 99.53 97.11 PS域无线接通率80.0082.0084.0086.0088.0090.0092.0094.0096.0098.000901090209030904090509060907092009210922 从 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因此确定该区域存在下行干扰具体情况。