TDSCDMA 无线网络指标优化案例集---.看完删除docx

目录
1无线接通率优化案例 (3)
1.1TOP 小区RRC接通率优化 (3)
1.2上行期望功率设置过低导致接通率低 (6)
2无线掉话率优化案例 (6)
2.1CS域掉话率 (6)
2.2PS域掉话率 (8)
3切换成功率优化案例 (12)
3.1CIO配置错误导致切换失败率高问题解决 (12)
3.2“切换惩罚时间设置过大”引起切换不及时的问题解决 (15)
3.3UPPTS时隙干扰影响切换成功率问题解决 (18)
3.4调整切换失败时重发测量控制时间降低切换失败率 (21)
3.5CS和PS业务跨RNC切换失败的问题定位分析 (22)
3.6由于IPPATH及IPRT未配置导致RNC间PS切换无法进行的现象 (23)
43G到2G切换成功率优化案例 (25)
4.12/3G互操作G网无法重选至T网 (25)
4.2GSM小区参数值设置不合理导致测试终端无法重选到TD网络上 (26)
4.32G到3G路由区更新失败处理案例 (27)
4.4终端能力不足导致异系统切换失败 (29)
4.5参数设置不当导致PS业务不能迁移至2G网络 (30)
5H业务优化案例 (31)
5.1SIM卡设置导致下载速率受限 (31)
5.2HSDPA速率较低问题分析 (31)
5.3大唐测试手机HSDPA测试速率过低的处理案例 (32)
5.4业务建立失败 (34)
6邻区配置优化案例 (35)
6.1同一小区的邻区不同频同码字导致邻区无法配置 (35)
6.2外部邻区参数更新不及时导致脱网，重选失败的案例 (37)
6.3异系统邻区测量启动门限设置不当，导致小区乒乓重选 (39)
7RNC侧配置优化案例 (40)
7.1由于RNC侧SAC配置错误导致手机无法注册 (40)
7.2由于RNC侧网络模式配置错误导致多普达手机无法进行CS业务的问题 (42)
8门限优化案例 (44)
重选门限设置不合理，导致重选异常。

(44)
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；（RACH）
✧RNC接收到RRC CONNECTION REQ后，配置L2资源并和NodeB建立IUB接口上的RL链路；
✧RNC向UE发RRC CONNECTION SETUP；（FACH信道）
✧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 SETUP
RRC 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=4
NODEB侧：NINSYNCIND=1, NOUTSYNCIND=20, TRLFAILURE=50
这样大唐的配置为UE侧：4.2秒NODEB侧：8.2秒
这就是CELL UPDATE成功率高的原因。

【解决措施】
现深圳RNC9T已经把小区更新的参数设置如下：
T313=3s，N313=20，N315=1
NINSYNCIND=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 Failure
RL失步的判断机制为处于CELL_DCH状态的UE，NB检测到上行连续接收到来自物理层的NOUTSYNCIND 个连续”our of sync”指示时，启动定时器TRLFAILURE ，在此过程中若连续接收到来自物理层的NINSYNCIND 个连续”in sync”指示，TRLFAILURE停止，否则TRLFAILURE 超时，视为无线链路失败。

NB发起Radio Link Failure Indication过程，RNC等待IUCSRELNORABTMR 超时发起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处于同步状态，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、RLC参数调整
参数参数说明修改前修改后
TIMERRST 该定时器属于发送端，当发送了RESET PDU 后启动该定时器，收到确认后停止该定时器。

D400 D1000
NODISCARDMAXDAT 该参数给出了触发某个重置过程的门限值。

当某个PDU 经过Max_DAT-1 次传输后，都没有成功发送，直接发起一个RLC重置过程。

D20 D40 TIMERPOLLPROHIBIT 该定时器属于发送端，用于禁止在一定的时间中触发轮询。

定时器的值不能大于Timer_poll_periodic 的值，否则会使得周期触发轮询失去意义。

如果只是使用周期轮询的话，该定时器可以不用。

如果除了周期轮询外，还有别的触发方式，该定时器必须使用，此时该定时器的值应该和Timer_poll_periodic 的值有一定的时间差值，否则会使得别的触发机制失去意义。

D100 D40
TIMERPOLL 该定时器属于发送端，当发送端发送了触发轮询后，如果在定时器期间收不到响应，定时器超时后，再次轮询。

若没有配置该种轮询机制的话，可以不使用该定时器。

D250 D200
POLLPDU 该参数用于基于PDU的轮询机制，其意义为发出POLLPDU个PDU以后发出一个轮
询指示。

D32 D4
4、对于TOP小区抬高最小接入电平，在目前终端性能的现状下，可在接入电平上做合理限制。

（内参）
5、频点、扰码重整
掉话原因：
同扰码邻区对打，可能导致副载波同频同码，容易掉话
通过扰码调整，尽量避免同码组邻区对打，减少干扰。

措施：RNC内小规模调整频点和扰码，规避同扰码问题，尽量避免同码组。

6、邻区漏配错配
掉话原因：
（1）邻区信息错配或漏配
（2）单向邻区
措施：分区域检查邻区错配
7、RF优化调整
掉话原因：
1、覆盖差
2、导频污染
3、越区覆盖，TD系统中需要严格控制越区覆盖
操作：天馈分离/天线方向角/下顷角调整
【效果对比】
通过20多天的努力，目前指标稳定在20％以内，平均15％左右。

网络优化前后PS掉话指标对比
3切换成功率优化案例
3.1 CIO配置错误导致切换失败率高问题解决
【问题描述】
在话务统计报表中，有关于小区邻区级的切换统计。

通过几天的top小区分析，观察到小区17161
向小区17162的切换出失败率较高。

具体数据如下表：
【问题分析】
分析其切换出失败的细分类，观察到由于<物理信道失败>造成的切换出失败占总失败次数的大多数，如下表：
物理信道失败，通常发生于UE上报测量报告，RNC成功判决并下发物理信道重配置后，无法在切换目标小区接收到UE的物理信道重配置完成消息。

这表明在这时刻，切换目标小区的信号质
量虽然满足了切换判决，但其信号质量并不好。

【解决方法】
以下是同频、异频切换的相关定义：
同频切换事件
事件1G
当下列等式在触发时间（Time-to-trigger）内一直成立的时候，UE报告事件1G（最佳小区的改变）
给RNC ：
,
1010__1best previous best previous g O LogM H O LogM i i +⋅>-+⋅
公式中的参数含义如下： Mprevious_best 是前最佳小区的当前P-CCPCH RSCP ，单位mW Oprevious_best 是前最佳小区的单独偏移
Mi 是正在评估的小区i 的当前P-CCPCH RSCP ，单位mW Oi 正在评估小区i 的单独偏移
H1g 是报告事件1G 的滞后参数。

异频切换事件
当下列等式在触发时间（Time-to-trigger ）内一直成立的时候，UE 报告事件2A （最佳频率的更新）给RNC ：
2/2a Best NotBest H Q Q +≥
公式中的参数含义如下：
QNot Best 是变量BEST_FREQUENCY_2A_EVENT 中"best
frequency"没有存储的频率质量估计。

QBest 是参数BEST_FREQUENCY_2A_EVENT 中"best frequency"存储的频率质量估计。

H2a 是事件2A 的滞后参数。

其中估计的质量如下定义：
j
i j frequency i j frequency i O LogM Q ,,,10+⋅=
Qi ,frequency j 是频率j 上的小区i 的估计质量。

Mfrequency j 是频率j 上的小区i 的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日执行）。

【效果对比】
调整后，小区17161向小区17162的切换出失败率明显改善，<物理信道失败>造成的切换出失败基本消除。

调整前后的切换出失败率对比及<物理信道失败>造成的切换出失败对比见下图：
3.2 “切换惩罚时间设置过大”引起切换不及时的问题解
决
【问题描述】
在路测中，发现有切换不及时现象。

具体表现为：从A小区切换到B小区后，UE发现A小区的信号强度又高于B小区，并满足了切换条件，于是上报了测量报告，但RNC收到此测量报告后没有判决切换（即下发物理信道重配置消息），导致UE在较长时间内无法切换回A小区，而一直占用信号强度相对较差的B小区，造成业务质量下降。

直到过了较长时间后，UE重新上报测量报告（其中包含非A的目标小区），RNC判决切换下发“物理信道重配置”消息，UE切换到新的非A 目标小区，业务质量得到改善。

【问题分析】
在信号复杂的区域，几个小区的信号强度差不多并交替变强，这时会发生乒乓切换问题。

在路测中就会遇到此类现象。

因此，为了避免过多的乒乓切换可能引起的掉话及用户感受差的问题，在网络中，一般会设置一个切换惩罚时间。

切换惩罚时间于RNC成功收到UE上报的上一次切换成功（A B）的“物理信道重配置完成”消息开始计时。

当UE检测到已切出的原服务小区（A）的信号强度高于当前服务小区（B）且满足切换条件后，UE会上报测量报告，RNC在进行判决时会首先考量惩罚时间，若惩罚时间已过，则按照正常流程进行判决，否则判决为不满足，不会下发“物理信道重配置”消息。

本问题可细分为2个问题：
1、切换惩罚时间过长
2、UE在上报测量报告后，一直等RNC的判决，直到过了较长时间才再发一次包含非原目标小区的测量报告。

【解决方法】
将切换惩罚时间减小（从5s改为0s），使UE能及时的切换回信号质量较好的小区，以保证业务服务质量。

【效果对比】
1、RSCP覆盖图对比
调整前
调整后
2、C/I覆盖图对比
调整前
调整后
3、BLER覆盖图对比调整前
调整后
可以看到的，切换惩罚时间调整后，UE能及时的切换到信号质量最好的小区，保证了业务的质量。

3.3 UPPTS时隙干扰影响切换成功率问题解决
【问题描述】
深圳TD网络龙华区域中，原来普遍使用硬切换，没有打开接力切换。

硬切换成功率偏低。

【问题分析】
通过话统小区级UPPCHISCP测量检查发现，大量的小区的UPPTS时隙干扰偏高。

以3月20日为例（RNC687、688，部分为0的小区没有统计），统计分布如下：
硬切换的过程中，首先要进行上行同步，如果同步时间过长，导致HOPHYCHRECFGTMR超时，或者同步失败，则UE在原小区上报物理信道失败。

硬切换失败原因分布如下（统计时间为1天）：
议错误>
接力切换的预同步过程属于开环预同步，在UE对本小区基站和相邻小区基站的导频信号强度进行测量的同时记录来自各邻近小区基站的信号与来自本小区基站信号的时延差，预先取得与目标小区的同步参数，并通过开环方式保持与目标小区的同步。

在切换接入的过程中，到了信道激活时间以后，直接在目标小区发送special burst，建立专用信道。

因此，接力切换可以规避UP干扰导致的硬切换失败问题。

改为接力切换后，切换失败原因统计（统计时间为1天）发现，物理信道失败的次数大大减少：
RRC接入过程中，同样要进行上行同步，为什么话统指标中RRC建立成功率不受影响？这是因为RNC侧统计RRC尝试次数是以接收到RRC CON REQ的次数计算的，如果没有同步上，则不会计为一次尝试。

因此在话统中没有看出对RRC成功率的影响。

但对于用户而言，在接收电平较弱的地方，可能会出现按下拨号键以后，很长时间都拨不出去，感受可能变差。

需要注意的是，UP干扰问题可能会影响路测指标中RRC建立成功率，因在路测工具侧，软件先统计到RRC CON REQ，然后才进行下行同步。

所以会影响到路测指标。

【解决方法】
打开RNC内接力切换，规避UPPTS带来的影响，提高切换成功率。

【效果对比】
从下表可以看出，同频切换成功率提高近25个百分点，异频提高约10个百分点。

【遗留问题】
接力切换只是一定程度上规避了UPPTS 时隙干扰带来的影响，但UPPTS 时隙干扰来源需要进一步查明并彻底排除，以提高用户接入体验。

RNC 间接力切换功能支持情况需要进一步验证。

3.4 调整切换失败时重发测量控制时间降低切换失败率
【问题描述】
在跟踪一些切换失败率高的小区的Trace 中，经常看到同一个UE 不停的往一个小区切换，但每次切换都失败。

例如：
这三次都是向同一个小区发起切换，并且间隔大概都在2秒左右。

【问题分析】
从话统角度来说，这样频繁的发生切换并且每次都失败，对于话统指标是一个很大的隐患：由于一个点的切换不好，导致切换指标恶化的很明显。

根据目前的算法和代码实现，不支持对切换失败小区的惩罚，即如果向一个小区切换失败了，如果UE 再次上报测量报告，网络仍然会向该小区发起切换。

这样就会造成短时间内往一个小区发起多次切换的场景。

【解决方法】
如果出现了这种情况，可以通过降低切换发生频率来减少切换失败次数，从而能够避免发生不必要的切换失败。

在目前的实现中，有一个切换失败后重试的机制。

即如果UE 上报某个小区的信号质量符合切换要
求，此时网络会发起向该小区切换的流程。

当切换失败，网络间隔一段时间后，会再次尝试往该小区切换，直到达到一定的重试次数为止。

切换重试的周期和次数可以后台设置。

一旦启动切换重试功能，测量控制消息将不会重发。

降低切换发生频率可以通过修改重试次数和重试周期来完成。

协议上规定了1G和2A,3A等事件都是穿越事件,即一但信号满足了测量的条件，UE会上报相应的测量报告。

如果后续信号一直满足测量条件，UE也不会重发测量报告。

此时如果网络想让UE再次上报某一个类型的测量报告，就必须再重发一次测量控制给UE，UE才会再次上报（有的UE作的不规范，会不停的上报测量报告，上面的trace中就出现了这种现象）。

因此网络可以通过重发测量控制的时间间隔，来避免频繁向同一个小区发起切换。

重发测量控制的时间间隔和切换失败重试周期定时器是同一个定时器。

如果要启用测量控制重发的功能，必须要把切换失败重试次数设为0.
【风险评估】
当采用通过重发测量控制的时间间隔来减少切换次数的方法时，会有一些不利的因素：
如果重发测量控制的时间间隔过长，UE在这段时间内无法发测量报告，就无法触发切换，会导致掉话率上升。

另外，间隔过长，等到下次触发切换时，由于信道环境已经变的比较差，切换失败的概率会增大。

重发测量控制的方法和失败重试方法是互斥的，采用重发测量控制方法后，会对切换的一些处理有影响，比如网络在防乒乓切换时，UE又上报了往原小区切换的测量报告，此时网络会忽略这个报告。

如果采用重发测量控制的方法，此时不会发起测量控制。

但是如果采用切换失败重试的方法，就可以在重试周期超时后，发起切换尝试。

3.5 CS和PS业务跨RNC切换失败的问题定位分析
【问题描述】
跨RNC切向友商基站时，CS和PS业务均不能正常切换，返回失败消息为：RANAP_RELOCATION_CANCEL （RNC—CN），且异频切换多次出现2B。

【问题分析】
切换不成功多由如下几类原因导致：
1、切换开关设置有误；
2、RNC涉及切换的参数配置不当；
3、核心网参数配置不当或不匹配；
4、终端原因导致；
【解决方法】
Step1：
1）从现场提供的Trace信令分析，返回失败消息为：RANAP_RELOCATION_CANCEL，其中失败的原因为：trelocprep-expiry。

2）trelocprep-expiry即为relocation preparation expiry,RANAP_RELOCATION_CANCEL消息由RNC 发给CN，可推断为原因2）：RNC涉及切换的参数配置不当，并初步推断为相关的定时器配置值较小导致。

3）查看现有RNC脚本配置，原有SET STATETIMER中：
RELOCCMDTMR=5000,RELOCPHYCHRECFGTMR=5000，RELOCUTRANHOCMPTMR=5000；将上述值修改为：
RELOCCMDTMR=15000,RELOCPHYCHRECFGTMR=8000, RELOCUTRANHOCMPTMR=10000。

Step2：
1）从现场提供的Trace信令流程中发现异频切换多次出现2B生效，同时也有2A在生效，按照目前的参考配置应该是2A生效2B不生效；
2）针对2A等切换生效的条件主要在RNC一侧，因此推断为原因2）：RNC涉及切换的参数配置不当。

3）检查RNC脚本，发现ADD CELLINTERFREQHONCOV命令中关于2A的迟滞、触发时延和切换门限值设置较大，从而使2B更容易生效；
4）将ADD CELLINTERFREQHONCOV值进行修改，使2A优先生效，修改如下：
ADD CELLINTERFREQHONCOV:CELLID=x, INTERFREQFILTERCOEF=D3, TARGETFREQTHD=-85, HYSTFOR2A=3, TIMETOTRIG2A=D320, WEIGHTFORUSEDFREQ=0, HYSTFORINTERCELL=6, TRIGTIMEFORINTERCELL=D320, RPTPERIODFORINTERCELL=D1000, THDFORINTERHO=-80, CELLHONOISETHRESHOLD=-90;
（注：上述值是参考现场2B值进行修改的，包括HYSTFOR2A、TIMETOTRIG2A、TRIGTIMEFORINTERCELL和THDFORINTERHO等，各项目值不一定完全一样）
Step3：
现场修改上述参数后，切换正常。

【建议与总结】
切换类问题可根据TRACE或路测数据等，先确定问题原因，及时找到问题源，结合MML等逐步查找定位。

3.6 由于IPPATH及IPRT未配置导致RNC间PS切换无法
进行的现象
【现象描述】
在RNC间测试业务切换的过程中发现，CS业务正常而PS业务迁移失败。

在发往CN的消息“RANAP_RELOCATION_CANCEL”中显示的原因值为“iu-transport-connection-failed-to-establish”
【原因分析】
PS业务跨RNC切换失败的原因一般有以下一些原因：
待切换的两个不同RNC的基站状态异常；无线环境问题；跨RNC邻区配置问题；各网元数据配置问题；
【处理过程】
1、从RNC机房查询得两基站及其待切换小区状态都正常，显示为“setup and enabled”；查看两基站也无告警；
2、从路测软件中查看无线环境的RSCP和C/I等，均正常；
3、查看跨RNC邻区配置，通过命令“LST NCELL”,显示待切换测试的两小区分别在各自的邻区列表里；
4、抓取现场PS跨RNC切换测试的TRACE，从发往CN的消息“RANAP_RELOCATION_CANCEL”中显示的原因值为“iu-transport-connection-failed-to-establish”
图1 RANAP_RELOCATION_CANCEL信令
据此推测，RNC的PS域IPPATH和路由配置有问题。

5、经查询RNC的PS域数据尚未配置：源RNC与目标RCN之间没有配置路由（IPPATH及IPRT）；通过ADD IPPATH和ADD IPRT命令，配置两相邻RNC之间的路由数据。

建议为每块配置了Iu-PS接口用户面数据的IP接口板配置到达DRNC的IP路由和IP Path。

迁移的轨迹是：当前RNC->SGSN->邻近RNC，因此配置迁移通路的前提条件是本RNC和SGSN之间、邻近RNC 和SGSN之间的IP Path已配置完毕。

通过ADD IPPATH配置服务RNC（SRNC）到目标RNC（DRNC）间用于迁移的IP Path；
通过ADD IPRT，增加到达DRNC的IP路由。

下一跳为源RNC对应的CE IP，（CE以太网）。

再通过ADD IPRT命令配置一条DRNC的备用路由，下一跳为源RNC对应的CE IP;
相应地，在目标RNC侧应对相邻RNC增加路由（IPPATH、IPRT）。

具体配置示例如下：
源RNC侧：
源RNC的用户面IP：10.74.61.17/30
目标RNC的用户面IP：10.74.53.17/30
源RNC对应的CE IP：10.74.56.17/30和10.74.57.17/30
ADD IPPATH:ANI=1994, PATHID=2, PATHT=HQ_QOSPATH, IPADDR="10.74.61.17", PEERIPADDR="10.74.53.17", PEERMASK="255.255.255.255", TXBW=10000, RXBW=10000, CARRYFLAG=NULL, FPMUX=NO, FWDHORSVBW=0, BWDHORSVBW=0, FWDCONGBW=0,。