TDSCDMA 无线网络指标优化案例集v1.0

TDSCDMA 无线网络指标优化案例集拟制: Prepared by 网络优化组日期：Date2009-4-4审核: Reviewed by 日期：Date审核: Reviewed by 日期：Date批准: Granted by日期：Date华为技术有限公司Huawei Technologies Co., Ltd.版权所有侵权必究All rights reserved修订记录Revision record目录TDSCDMA 无线网络指标优化案例集 (1)1无线接通率优化案例 (6)1.1TOP 小区RRC接通率优化 (6)1.2上行期望功率设置过低导致接通率低 (9)2无线掉话率优化案例 (10)2.1CS域掉话率 (10)2.2PS域掉话率 (12)3切换成功率优化案例 (15)3.1CIO配置错误导致切换失败率高问题解决 (15)3.2“切换惩罚时间设置过大”引起切换不及时的问题解决 (19)3.3UPPTS时隙干扰影响切换成功率问题解决 (22)3.4调整切换失败时重发测量控制时间降低切换失败率 (25)3.5CS和PS业务跨RNC切换失败的问题定位分析 (26)3.6由于IPPATH及IPRT未配置导致RNC间PS切换无法进行的现象 (28)43G到2G切换成功率优化案例 (30)4.12/3G互操作G网无法重选至T网 (30)4.2GSM小区参数值设置不合理导致测试终端无法重选到TD网络上 (31)4.32G到3G路由区更新失败处理案例 (32)4.4终端能力不足导致异系统切换失败 (33)4.5参数设置不当导致PS业务不能迁移至2G网络 (34)5H业务优化案例 (35)5.1SIM卡设置导致下载速率受限 (35)5.2HSDPA速率较低问题分析 (36)5.3大唐测试手机HSDPA测试速率过低的处理案例 (36)5.4业务建立失败 (39)6邻区配置优化案例 (40)6.1同一小区的邻区不同频同码字导致邻区无法配置 (40)6.2外部邻区参数更新不及时导致脱网，重选失败的案例 (42)6.3异系统邻区测量启动门限设置不当，导致小区乒乓重选 (43)7RNC侧配置优化案例 (44)7.1由于RNC侧SAC配置错误导致手机无法注册 (44)7.2由于RNC侧网络模式配置错误导致多普达手机无法进行CS业务的问题 (46)8门限优化案例 (49)重选门限设置不合理，导致重选异常。

(49)TDSCDMA 无线网络指标优化案例集关键词：掉话话统摘要：本文收集了网络优化过程中的典型案例，供优化参考。

缩略语清单：1无线接通率优化案例1.1 TOP 小区RRC接通率优化【问题描述】针对3月10号前几天话统的结果，RRC接通率低的TOP小区进行提取，根据话务统计的结果，调整前，这10个小区的CS RRC接通率仅为86.83%，PS RRC接通率仅为73.58%。

【问题分析】RRC建立是建立业务的前提，如果RRC建立的成功率低，业务建立成功率低的可能性也很大。

RRC 建立主要分为四个部分：✧UE在RACH上发RRC CONNECTION REQ；✧RNC接收到RRC CONNECTION REQ后，配置L2资源并和NodeB建立IUB接口上的RL链路；✧RNC向UE发RRC CONNECTION SETUP；✧UE回复RRC CONNECTION SETUP COMPLETE。

统计RRC接通率的起始点是RNC收到RRC CONNECTION REQ，终止点是RNC收到RRC CONNECTION SETUP COMPLETE。

因此影响RRC接通率的RRC建立失败，主要是后面三步没有成功而导致的。

RRC建立失败的可能原因：1．RNC资源分配失败，或者建立L2实例失败，或者IUB接口RL链路失败按照目前的用户量和话务量，如果出现了前面几种失败原因，一般都是RNC或者NodeB内部出现了问题，需要检查RNC和NodeB的状态或者小区状态。

2．UE收不到RRC CONNECTION SETUPRRC CONNECTION SETUP消息是在FACH上发给UE的。

目前SCCPCH功率配置的值一般是-3db(相对于PCCPCH功率，单码道)。

从覆盖上来说，已经和PCCPCH的覆盖一样了。

如果仍然出现UE收不到RRC CONNECTION SETUP消息，需要调整SCCPCH功率，来满足信号覆盖不好的地方功率需求。

3．RNC收不到RRC CONNECTION SETUP COMPLETE如果UE收到RRC CONNECTION SETUP 消息后，会向网络回复RRC CONNECTION SETUP COMPLETE消息。

此时，如果UE上行同步时失败，或者在向网络侧发RRC CONNECTION SETUP COMPLETE消息时，网络侧无法正确接收，都会导致RRC建立失败。

此时，可以通过提高上行期望接收功率/RL初始发射功率和修改上行同步的参数，来使得UE能够正常进行上行同步和上传消息。

【解决方法】针对RRC接通率比较低的TOP小区，11号针对性的修改下面参数，来提高RRC接通率。

【效果对比】为了验证修改之后，这些小区的RRC接通率性能变化情况，特跟踪这几天TOP小区的CS RRC 和PS RRC接通率的变化趋势，每日把这些TOP小区的RRC接通率次数和成功次数进行累计，作为今天的RRC接通率，为了提高数据的可靠性，在作累计时，抛去当日存在告警信息的小区。

因为业务量不能达到一定的规模，数据的可靠性不能完全可信，特别PS RRC尝试次数比较少，但总体上能反映出一定的问题。

修改完参数，这两个指标总体来讲，有一定的提高，虽然每日指标有一定的波动。

因为3月12日存在大量告警，指标的可信度不是很大，故没有加以考虑。

图 1 CS RRC接通率TOP小区性能变化图 2 CS RRC建立及成功次数图 3 PS RRC接通率TOP小区性能变化图 4 PS RRC建立及成功次数1.2 上行期望功率设置过低导致接通率低【问题描述】A市在做TD手机拨打CS语音业务时，经常出现无法接通的现象。

从后台信令跟踪，发现错误原因提示为：network out of order。

【问题分析】1、网络覆盖场强值过低。

2、干扰导致。

3、参数设置问题。

4、终端问题。

【解决方法】1、用其他TD手机拨打，未接通现象也会出现。

排除终端问题2、用大唐8120测试，从覆盖场强值来看，排除覆盖场强值过低导致掉话的可能。

3、从信令流程上看，UE发送RRC_CONNECT_SETUP_COM，但RNC没有收到。

很可能是上行同步失败导致手机无法接通。

4、检测后台UPPCH的ISCP值过高，存在干扰。

可以提高UPPTS的期望接受功率或进行UP偏移来解决。

检查后台参数发现上行干扰余量ULINTERFERERSVP配置为-3，指导书中参数应设置为3，将其改为3后，复测发现问题基本解决。

【建议与总结】在后台参数设置过程中，一定要了解各参数，并按照指导书进行设置。

2无线掉话率优化案例2.1 CS域掉话率2.1.1小区更新成功率偏低分析【问题描述】XX网络中小区更新成功率低。

作为无线链路异常时的一种补救手段，解决小区更新成功率问题可降低掉话率。

【问题分析】NodeB侧配置的RL Failure参数为：其中,连续同步指示次数相当于UE侧的N315连续不同步指示次数相当于UE侧的能N313无线链路失败定时其时长相当于UE侧的T313,【参数分析】我们的CELL UPDATE成功率可能出现的问题点。

UE侧：T313=15s N313=50 N315=1那么下行失步时候进行小区更新的时间是：N313×160ms+T313=50×160+15=23s，也就是要下行失步满足条件后23秒才能进行CELL UPDATE.NODEB侧：NINSYNCIND=1, NOUTSYNCIND=20, TRLFAILURE=50其中TRLFAILURE=50就是5s那么上行失步NODEB向RNC发起RADIO LINK FAILURE并且进行IU RELEASE REQUEST的时间为：NOUTSYNCIND×160ms+ TRLFAILURE=8.2s，也就是要上行失步满足条件后8.2秒就进行无线链路释放。

所以：UE侧无线链路失败时间远远大于NODEB侧无线链路失败时间注意：假如，在下行失步的时候上行已经失步了，那么上行到8.2秒后就已经把无线链路（包括信令面的链路）释放了，下行再怎么CELL UPDATE也不会有CELL UPDATE CONFIRM的回复。

造成我们的CELL UPDATED的成功率非常的低。

查询了其他厂家的此参数发现UE侧：T313=1 N313=20 N315=4NODEB侧：NINSYNCIND=1, NOUTSYNCIND=20, TRLFAILURE=50这样大唐的配置为UE侧：4.2秒NODEB侧：8.2秒这就是CELL UPDATE成功率高的原因。

【解决措施】现深圳RNC9T已经把小区更新的参数设置如下：T313=3s，N313=20，N315=1NINSYNCIND=1, NOUTSYNCIND=20, TRLFAILURE=200以上设置可以留给UE发起小区更新足够的时间【效果对比】优化前小区更新成功率KPI指标统计如下：2.2 PS域掉话率2.2.1XX网络PS掉话率优化【问题描述】XX区域网络在建网以后，PS掉话率一致处于30％左右的水平，距离现网目前20％的PS掉话率平均水平有比较大的差距。

优化的目标是要将PS掉话率指标控制在20％以内。

【问题分析】首先从话统上从掉话原因上来看，TopN的掉话原因集中在RB复位、RL失步等原因上，如下表：RB复位是指在RLC AM模式下，当某个PDU 经过Max_DAT-1 次重传后，都没有成功发送，发送端直接发起一个RLC重置过程。

在TIMERRST时间内接收到对端响应，则停止TIMERRST 超时定时器。

如果TIMERRST定时器，重新发起RLC重置过程，经过MAXRST后尝试后，如果不能接收到对端响应，则上报“RLC不可恢复错误”，RNC发起RAB释放，原因为“RB复位”RL失步是指RNC收到NodeB上报的RL FailureRL失步的判断机制为处于CELL_DCH状态的UE，NB检测到上行连续接收到来自物理层的NOUTSYNCIND 个连续”our of sync”指示时，启动定时器TRLFAILURE ，在此过程中若连续接收到来自物理层的NINSYNCIND 个连续”in sync”指示，TRLFAILURE停止，否则TRLFAILURE 超时，视为无线链路失败。