欢迎来到三一办公! | 帮助中心 三一办公31ppt.com(应用文档模板下载平台)
三一办公
全部分类
  • 办公文档>
  • PPT模板>
  • 建筑/施工/环境>
  • 毕业设计>
  • 工程图纸>
  • 教育教学>
  • 素材源码>
  • 生活休闲>
  • 临时分类>
  • ImageVerifierCode 换一换
    首页 三一办公 > 资源分类 > DOCX文档下载  

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

    • 资源ID:1896002       资源大小:857.91KB        全文页数:20页
    • 资源格式: DOCX        下载积分:16金币
    快捷下载 游客一键下载
    会员登录下载
    三方登录下载: 微信开放平台登录 QQ登录  
    下载资源需要16金币
    邮箱/手机:
    温馨提示:
    用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP免费专享
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    中兴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。因此确定该区域存在下行干扰。具体情况见下图。 由于附近没有室内的站点,因此把南山钜建 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 业务演示场所,用户发起业务次数较多、话务量占全网比重较大,对整体网络指标影响很大。初步判断号码为 15710750265 的终端掉线频繁,该号码占用 52082 小区(主频点 10096、扰码 93)。 问题分析: 深圳移动 TD-SCDMA 南山展示厅建设了室内分析系统, 配置 2 个小区、 2 个小区配置5M 异频频点;室外周边小区没有和南山展示厅室内系统 5M 同频的小区;在南山展示厅室内进行测试,室外小区信号相对室内信号很弱,相差 20dB 左右,室内覆盖良好。测试结果见下图。 为了解决南山展示厅 PS 业务掉线的问题,在展示厅进行观察和测试。找到号码为15710750265 的终端,该终端为做流媒体演示的酷派手机。通过了解,流媒体演示由工作人员自己操作, 用户不能直接操作。 直接对号码为 15710750265 的酷派手机进行反复操作,发现该手机掉线问题比较明显,从后台跟踪信令发现该终端经常会发起小区更新;继续操作发现该手机经常在重开机后还是做不了业务, 现场工作人员也反映该终端掉线比较频繁;多次操作后,该终端出现搜不到卡和没有网络的情况,宇龙酷派工作人员也反馈可能终端长时间工作过热导致终端主板线路故障而使手机收不到网络,因此判断掉线可能是由该终端问题造成的。 为了验证该酷派终端问题,在演示厅内除 15710750265 终端外其他终端业务正常展示的情况下,更换终端进行测试。采用凯明测试手机连接 RNT 路测软件,占用 52082 小区进行流媒体业务测试,测试 40 分钟没有掉线;之后每 5 分钟一次断开重新拨号测试,在第 6次时一段时间后速率会明显下降,但并不影响流媒体业务。采用商用终端 ZTE U980、ZTEU85 在同一小区进行流媒体业务,演示厅内其他终端业务正常展示,测试 5 次共 90 分钟左右,没有掉线情况发生。 由上判断 15710750265 号码使用的酷派终端性能问题导致了 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 个小区之间的同频干扰,提升无线接通率、掉话率和切换成功率指标。 优化结果: 朗山北 T_1、朗山二 T_3 的频点是 2008-8-25 调整为 5M 异频的,下面是后台汇总的2008-8-92008-8-16 和 2008-9-72008-9-11 每天 2 个小区的无线掉话率指标。 时间时间 CellID ID 分组域业分组域业务流量务流量 分组域分组域RAB 指配指配建立成功建立成功的的RAB数数目目 RNC 请求请求释放的分释放的分组域掉话组域掉话的的RAB数数目目 小区分组小区分组域掉线率域掉线率 2008-08-09 50291+51003 76983.44 176 29 16.48% 2008-08-10 50291+51003 6600.12 35 0 0.00% 2008-08-11 50291+51003 107013.06 340 59 17.35% 2008-08-12 50291+51003 94752.65 256 44 17.19% 2008-08-13 50291+51003 151578.49 240 52 21.67% 2008-08-14 50291+51003 41790.16 231 65 28.14% 2008-08-15 50291+51003 55688.49 272 45 16.54% 2008-08-16 50291+51003 88802.94 69 15 21.74% 2008-09-07 50291+51003 1808.92 14 0 0.00% 2008-09-08 50291+51003 30272.33 190 11 5.79% 2008-09-09 50291+51003 47062.94 166 10 6.02% 2008-09-10 50291+51003 30375.62 189 12 6.35% 2008-09-11 50291+51003 30726.9 137 5 3.65% 51003+50291PS域掉话率0.00%5.00%10.00%15.00%20.00%25.00%30.00%0809 0810 0811 0812 0813 0814 0815 0816 0907 0908 0909 0910 0911 朗山北 T_1、朗山二 T_3 的频点调整为 5M 异频后,从 2 个小区的无线掉话率的对比情况来看,其无线掉话率改善明显。

    注意事项

    本文(中兴TD-SCDMA深圳无线网络KPI提升优化案例.docx)为本站会员(牧羊曲112)主动上传,三一办公仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三一办公(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    备案号:宁ICP备20000045号-2

    经营许可证:宁B2-20210002

    宁公网安备 64010402000987号

    三一办公
    收起
    展开