华为TD-SCDMA-无线网络指标优化案例集.doc

《华为TD-SCDMA-无线网络指标优化案例集.doc》由会员分享，可在线阅读，更多相关《华为TD-SCDMA-无线网络指标优化案例集.doc（48页珍藏版）》请在沃文网上搜索。

1、产品名称Product name密级Confidentiality levelTDSCDMA内部公开产品版本Product versionTotal 48pages 共55页V400R000C01B161NodeB B260TDSCDMA 无线网络指标优化案例集(仅供内部使用）For internal use only拟制:Prepared by网络优化组日期：Date2009-4-4审核:Reviewed by日期：Date审核:Reviewed by日期：Date批准:Granted by日期：Date华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权

2、必究All rights reserved修订记录Revision record日期Date修订版本Revision version修改描述Change Description作者Author2009-4-6V1.0第一版网络优化组2009-7-27.V1.0第二版目录 TDSCDMA 无线网络指标优化案例集1(仅供内部使用）1For internal use only11无线接通率优化案例61.1TOP 小区RRC接通率优化61.2上行期望功率设置过低导致接通率低92无线掉话率优化案例102.1CS域掉话率102.2PS域掉话率123切换成功率优化案例153.1CIO配置错误导致切换失败率高

3、问题解决153.2“切换惩罚时间设置过大”引起切换不及时的问题解决193.3UPPTS时隙干扰影响切换成功率问题解决223.4调整切换失败时重发测量控制时间降低切换失败率253.5CS和PS业务跨RNC切换失败的问题定位分析263.6由于IPPATH及IPRT未配置导致RNC间PS切换无法进行的现象2843G到2G切换成功率优化案例304.12/3G互操作G网无法重选至T网304.2GSM小区参数值设置不合理导致测试终端无法重选到TD网络上314.32G到3G路由区更新失败处理案例324.4终端能力不足导致异系统切换失败334.5参数设置不当导致PS业务不能迁移至2G网络345H业务优化案例3

4、55.1SIM卡设置导致下载速率受限355.2HSDPA速率较低问题分析365.3大唐测试手机HSDPA测试速率过低的处理案例365.4业务建立失败396邻区配置优化案例406.1同一小区的邻区不同频同码字导致邻区无法配置406.2外部邻区参数更新不及时导致脱网，重选失败的案例426.3异系统邻区测量启动门限设置不当，导致小区乒乓重选437RNC侧配置优化案例447.1由于RNC侧SAC配置错误导致手机无法注册447.2由于RNC侧网络模式配置错误导致多普达手机无法进行CS业务的问题468门限优化案例49重选门限设置不合理，导致重选异常。49TDSCDMA 无线网络指标优化案例集关键词：掉话

5、话统 摘 要：本文收集了网络优化过程中的典型案例，供优化参考。缩略语清单：缩略语英文全名中文解释AMRAdaptive MultiRate自适应多速率CDLCall Detail Log呼叫日志CDRCall Drop Rate掉话率CHRCall History Record呼叫历史记录1 无线接通率优化案例1.1 TOP 小区RRC接通率优化【问题描述】针对3月10号前几天话统的结果，RRC接通率低的TOP小区进行提取，根据话务统计的结果，调整前，这10个小区的CS RRC接通率仅为86.83%，PS RRC接通率仅为73.58%。【问题分析】RRC建立是建立业务的前提，如果RRC建立的成

6、功率低，业务建立成功率低的可能性也很大。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建立失败的

7、可能原因：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功率，来满足信号覆盖不好的地方功率需

8、求。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接通率。MML命令参数名

9、称修改前修改后修改原因修改范围MOD CELLNBMOLPCULINTERFERERSV-33提高上行干扰余量，间接提高SRB/RB建立时的上行期望接收功率，针对RRC接通率低的小区在RRC接通率低的top小区中修改（16772，16401，43482，42532，45681，16193，42133，17512，19061，17501）MINDLINITPWR-250-200提高下行初始发射功率下限【效果对比】为了验证修改之后，这些小区的RRC接通率性能变化情况，特跟踪这几天TOP小区的CS RRC和PS RRC接通率的变化趋势，每日把这些TOP小区的RRC接通率次数和成功次数进行累计，作为今

10、天的RRC接通率，为了提高数据的可靠性，在作累计时，抛去当日存在告警信息的小区。因为业务量不能达到一定的规模，数据的可靠性不能完全可信，特别PS RRC尝试次数比较少，但总体上能反映出一定的问题。修改完参数，这两个指标总体来讲，有一定的提高，虽然每日指标有一定的波动。因为3月12日存在大量告警，指标的可信度不是很大，故没有加以考虑。图 1 CS RRC接通率TOP小区性能变化图 2 CS RRC建立及成功次数图 3 PS RRC接通率TOP小区性能变化图 4 PS RRC建立及成功次数1.2 上行期望功率设置过低导致接通率低【问题描述】A市在做TD手机拨打CS语音业务时，经常出现无法接通的现象

11、。从后台信令跟踪，发现错误原因提示为：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配置

12、为-3，指导书中参数应设置为3，将其改为3后，复测发现问题基本解决。【建议与总结】在后台参数设置过程中，一定要了解各参数，并按照指导书进行设置。2 无线掉话率优化案例2.1 CS域掉话率2.1.1 小区更新成功率偏低分析【问题描述】XX网络中小区更新成功率低。作为无线链路异常时的一种补救手段，解决小区更新成功率问题可降低掉话率。【问题分析】NodeB侧配置的RL Failure参数为：其中,连续同步指示次数相当于UE侧的N315连续不同步指示次数相当于UE侧的能N313无线链路失败定时其时长相当于UE侧的T313,【参数分析】我们的CELL UPDATE成功率可能出现的问题点。UE侧：T313

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

14、路失败时间远远大于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

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

16、制在20以内。【问题分析】首先从话统上从掉话原因上来看，TopN的掉话原因集中在RB复位、RL失步等原因上，如下表：RNC请求释放的按原因分类的分组域RAB 数目RNC请求释放的按原因分类的分组域RAB 数目RNC请求释放的按原因分类的分组域RAB 数目RNC请求释放的按原因分类的分组域RAB 数目RNC请求释放的按原因分类的分组域RAB 数目RNC请求释放的按原因分类的分组域RAB 数目CellName=12086142, CellID=1614251000510CellName=12097502, CellID=1750237000370CellName=12087713, CellID=

17、1771336000360CellName=12087712, CellID=1771213000130CellName=12087622, CellID=17622900090CellName=12086472, CellID=16472800080CellName=12086602, CellID=16602700070CellName=12087553, CellID=17553700070CellName=12087621, CellID=17621700070CellName=12087243, CellID=17243600060RNC请求释放分组域Iu连接对应的RAB 数目RNC

18、请求释放分组域Iu连接对应的RAB 数目RNC请求释放分组域Iu连接对应的RAB 数目RNC请求释放分组域Iu连接对应的RAB 数目RNC请求释放分组域Iu连接对应的RAB 数目CellName=12096641, CellID=166414904900CellName=12092723, CellID=42723320200CellName=12097161, CellID=17161100400CellName=12097502, CellID=1750280600CellName=12086142, CellID=1614270003CellName=12086602, CellID=1

19、660270005CellName=12098041, CellID=1804170100CellName=12087142, CellID=1714270000CellName=12087553, CellID=1755360100CellName=12097501, CellID=1750160200RB复位是指在RLC AM模式下，当某个 PDU 经过 Max_DAT-1 次重传后，都没有成功发送，发送端直接发起一个RLC重置过程。在TIMERRST时间内接收到对端响应，则停止TIMERRST超时定时器。如果TIMERRST定时器，重新发起RLC重置过程，经过MAXRST后尝试后，如果不

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

21、MR超时发起Iu release request，请求释放Iu连接【解决方法】1、提高13.6、3.4K信令的SIRTARGET，并且打开SRB的外环功控开关。提高SRB的信号接收质量。2、修改RL failure定时器T313是连接模式下UE检测无线链路失败的定时器，当UE从L1检测到连续N313个失步指示后启动T313定时器。当UE从L1检测到连续N315个同步指示后停止T313定时器。一旦T313超时，UE上报原因值为RL FAILURE的CELL UPDATE消息通知RNC空中接口下行失步。T_RLFAILURE定时器是NodeB用于检测UU接口上行是否失步，当CCTRCH处于同步状态

22、，NodeB在连续收到“N_OUTSYNC_IND”个失步指示后会启动T_RLFAILURE定时器；在连续收到“N_INSYNC_IND”个同步指示后会停止和复位T_RLFAILURE定时器。一旦T_RLFAILURE定时器超时，NodeB会上报RADIO LINK FAILURE INDICATION消息通知RNC空中接口上行失步，并将当前CCTRCH状态置为失步状态。增大这两个定时器，可以提高UE检测到无线链路失步后的容忍时间，减少Radio Link failure错误。增加由于无数据传输导致链路释放的触发时间，避免频繁触发由于无数据传输而导致的网络侧发起链路释放，减少PS掉话率。3、R

23、LC参数调整参数参数说明修改前修改后TIMERRST该定时器属于发送端，当发送了 RESET PDU 后启动该定时器，收到确认后停止该定时器。D400D1000NODISCARDMAXDAT该参数给出了触发某个重置过程的门限值。当某个 PDU 经过 Max_DAT-1 次传输后，都没有成功发送，直接发起一个RLC重置过程。D20D40TIMERPOLLPROHIBIT该定时器属于发送端，用于禁止在一定的时间中触发轮询。定时器的值不能大于 Timer_poll_periodic 的值，否则会使得周期触发轮询失去意义。如果只是使用周期轮询的话，该定时器可以不用。如果除了周期轮询外，还有别的触发方式

24、，该定时器必须使用，此时该定时器的值应该和 Timer_poll_periodic 的值有一定的时间差值，否则会使得别的触发机制失去意义。D100D40TIMERPOLL该定时器属于发送端，当发送端发送了触发轮询后，如果在定时器期间收不到响应，定时器超时后，再次轮询。若没有配置该种轮询机制的话，可以不使用该定时器。D250D200POLLPDU该参数用于基于PDU的轮询机制，其意义为发出POLLPDU个PDU以后发出一个轮询指示。D32D44、对于TOP小区抬高最小接入电平，在目前终端性能的现状下，可在接入电平上做合理限制。（内参）5、频点、扰码重整掉话原因：l同扰码邻区对打，可能导致副载波同

25、频同码，容易掉话l通过扰码调整，尽量避免同码组邻区对打，减少干扰。措施：RNC内小规模调整频点和扰码，规避同扰码问题，尽量避免同码组。6、邻区漏配错配掉话原因：（1）邻区信息错配或漏配（2）单向邻区措施：分区域检查邻区错配7、RF优化调整掉话原因： 1、覆盖差 2、导频污染3、越区覆盖，TD系统中需要严格控制越区覆盖操作：天馈分离/天线方向角/下顷角调整【效果对比】通过20多天的努力，目前指标稳定在20以内，平均15左右。优化后网络替换及优化调整优化前网络优化前后PS掉话指标对比3 切换成功率优化案例3.1 CIO配置错误导致切换失败率高问题解决【问题描述】在话务统计报表中，有关于小区邻区级的

26、切换统计。通过几天的top小区分析， 观察到小区17161向小区17162的切换出失败率较高。具体数据如下表：日期对象名称RNC 内小区间同频异频硬切换出成功次数RNC 内小区间同频异频硬切换出请求次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出成功率11/3/200917161-1716229722%12/3/200917161-171620330%13/03/200917161-1716218713%14/03/200917161-1716218713%【问题分析】分析其切换出失败的细分类，观察到由于造成的切换出失败占总失败次数的大多数，如下表：日期对象名称RN

27、C 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数11/3/200917161-1716273100030012/3/200917161-1716232000010013/03/200917161-1716272000050014/03/200917161-17162720000500物理信道

28、失败，通常发生于UE上报测量报告，RNC成功判决并下发物理信道重配置后，无法在切换目标小区接收到UE的物理信道重配置完成消息。这表明在这时刻，切换目标小区的信号质量虽然满足了切换判决，但其信号质量并不好。【解决方法】以下是同频、异频切换的相关定义：同频切换事件事件1G当下列等式在触发时间（Time-to-trigger）内一直成立的时候，UE报告事件1G（最佳小区的改变）给RNC：公式中的参数含义如下：Mprevious_best是前最佳小区的当前P-CCPCH RSCP，单位mWOprevious_best是前最佳小区的单独偏移Mi是正在评估的小区i的当前P-CCPCH RSCP，单位mWO

29、i正在评估小区i的单独偏移H1g是报告事件1G的滞后参数。异频切换事件当下列等式在触发时间（Time-to-trigger）内一直成立的时候，UE报告事件2A（最佳频率的更新）给RNC：公式中的参数含义如下：QNot Best 是变量BEST_FREQUENCY_2A_EVENT中best frequency没有存储的频率质量估计。QBest是参数BEST_FREQUENCY_2A_EVENT中best frequency存储的频率质量估计。H2a是事件2A的滞后参数。其中估计的质量如下定义：Qi ,frequency j是频率j上的小区i的估计质量。Mfrequency j是频率j上的小区i

30、的P-CCPCH RSCP的测量结果，单位mW.Oi,j是当前频率j上的小区i的小区单独偏移，Oi,j由IE Cell individual offset设置。查询了17161向小区17162切换的同频、异频切换参数设置，H1g、H2a为3.5dB，17161的CIO为0dB，而17162的CIO为7.5dB。由此，可以看到，由于小区17162的CIO设置过高，造成17161向比自己弱的17162切换，导致最后的切换失败。正常情况下，需避免向比原服务小区信号质量差的小区切换出。因此，决定将17162的CIO为7.5dB调整为0dB（于2009年3月14日执行）。【效果对比】调整后，小区1716

31、1向小区17162的切换出失败率明显改善，造成的切换出失败基本消除。调整前后的切换出失败率对比及造成的切换出失败对比见下图：日期对象名称RNC 内小区间同频异频硬切换出成功次数RNC 内小区间同频异频硬切换出请求次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出成功率11/3/200917161-1716229722%12/3/200917161-171620330%13/03/200917161-1716218713%14/03/200917161-1716218713%15/03/200917161-17162110100%16/03/200917161-1716

32、2110100%17/03/200917161-1716267186%18/03/200917161-17162660100%日期对象名称RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数RNC 内小区间同频异频硬切换出失败次数11/3/200917161-1716273100030012/3/200917161-1716232

33、000010013/03/200917161-1716272000050014/03/200917161-1716272000050015/03/200917161-1716200000000016/03/200917161-1716200000000017/03/200917161-1716211000000018/03/200917161-171620000000003.2 “切换惩罚时间设置过大”引起切换不及时的问题解决【问题描述】在路测中，发现有切换不及时现象。具体表现为：从A小区切换到B小区后，UE发现A小区的信号强度又高于B小区，并满足了切换条件，于是上报了测量报告，但RNC收到此

34、测量报告后没有判决切换（即下发物理信道重配置消息），导致UE在较长时间内无法切换回A小区，而一直占用信号强度相对较差的B小区，造成业务质量下降。直到过了较长时间后，UE重新上报测量报告（其中包含非A的目标小区），RNC判决切换下发“物理信道重配置”消息，UE切换到新的非A目标小区，业务质量得到改善。【问题分析】在信号复杂的区域，几个小区的信号强度差不多并交替变强，这时会发生乒乓切换问题。在路测中就会遇到此类现象。因此，为了避免过多的乒乓切换可能引起的掉话及用户感受差的问题，在网络中，一般会设置一个切换惩罚时间。切换惩罚时间于RNC成功收到UE上报的上一次切换成功（AB）的“物理信道重配置完成”

35、消息开始计时。当UE检测到已切出的原服务小区（A）的信号强度高于当前服务小区（B）且满足切换条件后，UE会上报测量报告，RNC在进行判决时会首先考量惩罚时间，若惩罚时间已过，则按照正常流程进行判决，否则判决为不满足，不会下发“物理信道重配置”消息。本问题可细分为2个问题：1、 切换惩罚时间过长2、 UE在上报测量报告后，一直等RNC的判决，直到过了较长时间才再发一次包含非原目标小区的测量报告。【解决方法】将切换惩罚时间减小（从5s改为0s），使UE能及时的切换回信号质量较好的小区，以保证业务服务质量。【效果对比】1、RSCP覆盖图对比调整前调整后2、C/I覆盖图对比调整前调整后3、BLER覆盖

36、图对比调整前调整后可以看到的，切换惩罚时间调整后，UE能及时的切换到信号质量最好的小区，保证了业务的质量。3.3 UPPTS时隙干扰影响切换成功率问题解决【问题描述】深圳TD网络龙华区域中，原来普遍使用硬切换，没有打开接力切换。硬切换成功率偏低。【问题分析】通过话统小区级UPPCHISCP测量检查发现，大量的小区的UPPTS时隙干扰偏高。以3月20日为例（RNC687、688，部分为0的小区没有统计），统计分布如下：硬切换的过程中，首先要进行上行同步，如果同步时间过长，导致HOPHYCHRECFGTMR超时，或者同步失败，则UE在原小区上报物理信道失败。硬切换失败原因分布如下（统计时间为1天）

37、：接力切换的预同步过程属于开环预同步，在UE对本小区基站和相邻小区基站的导频信号强度进行测量的同时记录来自各邻近小区基站的信号与来自本小区基站信号的时延差，预先取得与目标小区的同步参数，并通过开环方式保持与目标小区的同步。在切换接入的过程中，到了信道激活时间以后，直接在目标小区发送special burst，建立专用信道。因此，接力切换可以规避UP干扰导致的硬切换失败问题。改为接力切换后，切换失败原因统计（统计时间为1天）发现，物理信道失败的次数大大减少：RRC接入过程中，同样要进行上行同步，为什么话统指标中RRC建立成功率不受影响？这是因为RNC侧统计RRC尝试次数是以接收到RRC CON

38、REQ的次数计算的，如果没有同步上，则不会计为一次尝试。因此在话统中没有看出对RRC成功率的影响。但对于用户而言，在接收电平较弱的地方，可能会出现按下拨号键以后，很长时间都拨不出去，感受可能变差。需要注意的是，UP干扰问题可能会影响路测指标中RRC建立成功率，因在路测工具侧，软件先统计到RRC CON REQ，然后才进行下行同步。所以会影响到路测指标。【解决方法】打开RNC内接力切换，规避UPPTS带来的影响，提高切换成功率。【效果对比】从下表可以看出，同频切换成功率提高近25个百分点，异频提高约10个百分点。起始时间对象名称RNC 内同频切换尝试次数RNC 内同频切换成功次数RNC 内同频切

39、换成功率RNC 内异频切换尝试次数RNC 内异频切换成功次数RNC 内异频切换成功率06/03/2009RNC9T/RNC功能:RNC9T31426183.1212597227987.75507/03/2009RNC9T/RNC功能:RNC9T22516673.7771585137486.68710/03/2009RNC9T/RNC功能:RNC9T897179.7751348122490.80113/03/2009RNC9T/RNC功能:RNC9T30715851.4651502136290.67914/03/2009RNC9T/RNC功能:RNC9T48121244.074173715809

40、0.96116/03/2009RNC9T/RNC功能:RNC9T24911044.1762316204088.08219/03/2009RNC9T/RNC功能:RNC9T24118476.3482680247392.27620/03/2009RNC9T/RNC功能:RNC9T483368.7549934068.136硬切换平均65.1857586.92213起始时间对象名称同频接力切换尝试次数同频接力切换成功次数同频接力切换成功率异频接力切换尝试次数异频接力切换成功次数异频接力切换成功率25/03/2009RNC9T/RNC功能:RNC9T21418586.4482861278197.2032

41、6/03/2009RNC9T/RNC功能:RNC9T17816291.0113433337098.16428/03/2009RNC9T/RNC功能:RNC9T15814289.8733209309596.44829/03/2009RNC9T/RNC功能:RNC9T363494.4443927382597.40231/03/2009RNC9T/RNC功能:RNC9T383489.474 3105299096.296接力切换平均90.2499497.1026【遗留问题】接力切换只是一定程度上规避了UPPTS时隙干扰带来的影响，但UPPTS时隙干扰来源需要进一步查明并彻底排除，以提高用户接入体验。R

42、NC间接力切换功能支持情况需要进一步验证。3.4 调整切换失败时重发测量控制时间降低切换失败率【问题描述】在跟踪一些切换失败率高的小区的Trace中，经常看到同一个UE不停的往一个小区切换，但每次切换都失败。例如：这三次都是向同一个小区发起切换，并且间隔大概都在2秒左右。【问题分析】从话统角度来说，这样频繁的发生切换并且每次都失败，对于话统指标是一个很大的隐患：由于一个点的切换不好，导致切换指标恶化的很明显。根据目前的算法和代码实现，不支持对切换失败小区的惩罚，即如果向一个小区切换失败了，如果UE再次上报测量报告，网络仍然会向该小区发起切换。这样就会造成短时间内往一个小区发起多次切换的场景。【解决方法】如果出现了这种情况，可以通过降低切换发生频率来减少切换失败次数，从而