华为TDSCDMA 无线网络指标优化案例集.docx

资源描述

华为TDSCDMA 无线网络指标优化案例集.docx

《华为TDSCDMA 无线网络指标优化案例集.docx》由会员分享，可在线阅读，更多相关《华为TDSCDMA 无线网络指标优化案例集.docx（63页珍藏版）》请在冰豆网上搜索。

华为TDSCDMA 无线网络指标优化案例集.docx

华为TDSCDMA无线网络指标优化案例集

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

TDSCDMA无线网络指标优化案例集1

（仅供内部使用）1

Forinternaluseonly1

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

重选门限设置不合理，导致重选异常。

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

关键词：

掉话话统

摘要：

本文收集了网络优化过程中的典型案例，供优化参考。

缩略语清单：

缩略语

英文全名

中文解释

AMR

AdaptiveMultiRate

自适应多速率

CDL

CallDetailLog

呼叫日志

CDR

CallDropRate

掉话率

CHR

CallHistoryRecord

呼叫历史记录

无线接通率优化案例

1.1TOP小区RRC接通率优化

【问题描述】

针对3月10号前几天话统的结果，RRC接通率低的TOP小区进行提取，根据话务统计的结果，调整前，这10个小区的CSRRC接通率仅为86.83%，PSRRC接通率仅为73.58%。

【问题分析】

RRC建立是建立业务的前提，如果RRC建立的成功率低，业务建立成功率低的可能性也很大。

RRC建立主要分为四个部分：

✧UE在RACH上发RRCCONNECTIONREQ；

✧RNC接收到RRCCONNECTIONREQ后，配置L2资源并和NodeB建立IUB接口上的RL链路；

✧RNC向UE发RRCCONNECTIONSETUP；

✧UE回复RRCCONNECTIONSETUPCOMPLETE。

统计RRC接通率的起始点是RNC收到RRCCONNECTIONREQ，终止点是RNC收到RRCCONNECTIONSETUPCOMPLETE。

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

RRC建立失败的可能原因：

1．RNC资源分配失败，或者建立L2实例失败，或者IUB接口RL链路失败

按照目前的用户量和话务量，如果出现了前面几种失败原因，一般都是RNC或者NodeB内部出现了问题，需要检查RNC和NodeB的状态或者小区状态。

2．UE收不到RRCCONNECTIONSETUP

RRCCONNECTIONSETUP消息是在FACH上发给UE的。

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

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

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

3．RNC收不到RRCCONNECTIONSETUPCOMPLETE

如果UE收到RRCCONNECTIONSETUP消息后，会向网络回复RRCCONNECTIONSETUPCOMPLETE消息。

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

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

【解决方法】

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

MML命令

参数名称

修改前

修改后

修改原因

修改范围

MODCELLNBMOLPC

ULINTERFERERSV

-3

提高上行干扰余量，间接提高SRB/RB建立时的上行期望接收功率，针对RRC接通率低的小区

在RRC接通率低的top小区中修改（16772，16401，43482，42532，45681，16193，42133，17512，19061，17501）

MINDLINITPWR

-250

-200

提高下行初始发射功率下限

【效果对比】

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

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

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

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

图1CSRRC接通率TOP小区性能变化

图2CSRRC建立及成功次数

图3PSRRC接通率TOP小区性能变化

图4PSRRC建立及成功次数

1.2上行期望功率设置过低导致接通率低

【问题描述】

A市在做TD手机拨打CS语音业务时，经常出现无法接通的现象。

从后台信令跟踪，发现错误原因提示为：

networkoutoforder。

【问题分析】

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.1CS域掉话率

2.1.1小区更新成功率偏低分析

【问题描述】

XX网络中小区更新成功率低。

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

【问题分析】

NodeB侧配置的RLFailure参数为：

其中,连续同步指示次数相当于UE侧的N315

连续不同步指示次数相当于UE侧的能N313

无线链路失败定时其时长相当于UE侧的T313,

【参数分析】

我们的CELLUPDATE成功率可能出现的问题点。

UE侧：

T313=15sN313=50N315=1

那么下行失步时候进行小区更新的时间是：

N313×160ms+T313=50×160+15=23s，也就是要下行失步满足条件后23秒才能进行CELLUPDATE.

NODEB侧：

NINSYNCIND=1,NOUTSYNCIND=20,TRLFAILURE=50

其中TRLFAILURE=50就是5s

那么上行失步NODEB向RNC发起RADIOLINKFAILURE并且进行IURELEASEREQUEST的时间为：

NOUTSYNCIND×160ms+TRLFAILURE=8.2s，也就是要上行失步满足条件后8.2秒就进行无线链路释放。

所以：

UE侧无线链路失败时间远远大于NODEB侧无线链路失败时间

注意：

假如，在下行失步的时候上行已经失步了，那么上行到8.2秒后就已经把无线链路（包括信令面的链路）释放了，下行再怎么CELLUPDATE也不会有CELLUPDATECONFIRM的回复。

造成我们的CELLUPDATED的成功率非常的低。

查询了其他厂家的此参数发现

UE侧：

T313=1N313=20N315=4

NODEB侧：

NINSYNCIND=1,NOUTSYNCIND=20,TRLFAILURE=50

这样大唐的配置为UE侧：

4.2秒NODEB侧：

8.2秒

这就是CELLUPDATE成功率高的原因。

【解决措施】

现深圳RNC9T已经把小区更新的参数设置如下：

T313=3s，N313=20，N315=1

NINSYNCIND=1,NOUTSYNCIND=20,TRLFAILURE=200

以上设置可以留给UE发起小区更新足够的时间

【效果对比】

优化前小区更新成功率KPI指标统计如下：

起始时间

小区更新次数<小区>

小区更新确认次数<小区>

小区更新成功次数<小区>

小区更新成功率

优化前

235

123

11.49%

优化后

633

497

490

77.41%

2.2PS域掉话率

2.2.1XX网络PS掉话率优化

【问题描述】

XX区域网络在建网以后，PS掉话率一致处于30％左右的水平，距离现网目前20％的PS掉话率平均水平有比较大的差距。

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

【问题分析】

首先从话统上从掉话原因上来看，TopN的掉话原因集中在RB复位、RL失步等原因上，如下表：

RNC请求释放的按原因分类的分组域RAB数目

RNC请求释放的按原因分类的分组域RAB数目<用户无响应>

CellName=12086142,CellID=16142

CellName=12097502,CellID=17502

CellName=12087713,CellID=17713

CellName=12087712,CellID=17712

CellName=12087622,CellID=17622

CellName=12086472,CellID=16472

CellName=12086602,CellID=16602

CellName=12087553,CellID=17553

CellName=12087621,CellID=17621

CellName=12087243,CellID=17243

RNC请求释放分组域Iu连接对应的RAB数目

CellName=12096641,CellID=16641

CellName=12092723,CellID=42723

CellName=12097161,CellID=17161

CellName=12097502,CellID=17502

CellName=12086142,CellID=16142

CellName=12086602,CellID=16602

CellName=12098041,CellID=18041

CellName=12087142,CellID=17142

CellName=12087553,CellID=17553

CellName=12097501,CellID=17501

RB复位是指在RLCAM模式下，当某个PDU经过Max_DAT-1次重传后，都没有成功发送，发送端直接发起一个RLC重置过程。

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

如果TIMERRST定时器，重新发起RLC重置过程，经过MAXRST后尝试后，如果不能接收到对端响应，则上报“RLC不可恢复错误”，RNC发起RAB释放，原因为“RB复位”

RL失步是指RNC收到NodeB上报的RLFailure

RL失步的判断机制为处于CELL_DCH状态的UE，NB检测到上行连续接收到来自物理层的NOUTSYNCIND个连续”ourofsync”指示时，启动定时器TRLFAILURE，在此过程中若连续接收到来自物理层的NINSYNCIND个连续”insync”指示，TRLFAILURE停止，否则TRLFAILURE超时，视为无线链路失败。

NB发起RadioLinkFailureIndication过程，RNC等待IUCSRELNORABTMR超时发起Iureleaserequest，请求释放Iu连接

【解决方法】

1、提高13.6、3.4K信令的SIRTARGET，并且打开SRB的外环功控开关。

提高SRB的信号接收质量。

2、修改RLfailure定时器

T313是连接模式下UE检测无线链路失败的定时器，当UE从L1检测到连续N313个失步指示后启动T313定时器。

当UE从L1检测到连续N315个同步指示后停止T313定时器。

一旦T313超时，UE上报原因值为RLFAILURE的CELLUPDATE消息通知RNC空中接口下行失步。

T_RLFAILURE定时器是NodeB用于检测UU接口上行是否失步，当CCTRCH处于同步状态，NodeB在连续收到“N_OUTSYNC_IND”个失步指示后会启动T_RLFAILURE定时器；在连续收到“N_INSYNC_IND”个同步指示后会停止和复位T_RLFAILURE定时器。

一旦T_RLFAILURE定时器超时，NodeB会上报RADIOLINKFAILUREINDICATION消息通知RNC空中接口上行失步，并将当前CCTRCH状态置为失步状态。

增大这两个定时器，可以提高UE检测到无线链路失步后的容忍时间，减少RadioLinkfailure错误。

增加由于无数据传输导致链路释放的触发时间，避免频繁触发由于无数据传输而导致的网络侧发起链路释放，减少PS掉话率。

3、RLC参数调整

参数参数说明修改前修改后

TIMERRST该定时器属于发送端，当发送了RESETPDU后启动该定时器，收到确认后停止该定时器。

D400D1000

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

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

D20D40

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

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

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

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

D100D40

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

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

D250D200

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

D32D4

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

（内参）

5、频点、扰码重整

掉话原因：

l同扰码邻区对打，可能导致副载波同频同码，容易掉话

l通过扰码调整，尽量避免同码组邻区对打，减少干扰。

措施：

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

6、邻区漏配错配

掉话原因：

（1）邻区信息错配或漏配

（2）单向邻区

措施：

分区域检查邻区错配

7、RF优化调整

掉话原因：

1、覆盖差

2、导频污染

3、越区覆盖，TD系统中需要严格控制越区覆盖

操作：

天馈分离/天线方向角/下顷角调整

【效果对比】

通过20多天的努力，目前指标稳定在20％以内，平均15％左右。

优化后

网络替换及优化调整

优化前

网络优化前后PS掉话指标对比

3切换成功率优化案例

3.1CIO配置错误导致切换失败率高问题解决

【问题描述】

在话务统计报表中，有关于小区邻区级的切换统计。

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

具体数据如下表：

日期

对象名称

RNC内小区间同频异频硬切换出成功次数

RNC内小区间同频异频硬切换出请求次数

RNC内小区间同频异频硬切换出失败次数

RNC内小区间同频异频硬切换出成功率

11/3/2009

17161-->17162

22%

12/3/2009

17161-->17162

13/03/2009

17161-->17162

13%

14/03/2009

17161-->17162

13%

【问题分析】

分析其切换出失败的细分类，观察到由于<物理信道失败>造成的切换出失败占总失败次数的大多数，如下表：

日期

对象名称

RNC内小区间同频异频硬切换出失败次数

RNC内小区间同频异频硬切换出失败次数<配置不同步>

RNC内小区间同频异频硬切换出失败次数<配置不完整>

RNC内小区间同频异频硬切换出失败次数<配置不支持>

RNC内小区间同频异频硬切换出失败次数<无效配置>

RNC内小区间同频异频硬切换出失败次数<物理信道失败>

RNC内小区间同频异频硬切换出失败次数<小区更新>

RNC内小区间同频异频硬切换出失败次数<协议错误>

11/3/2009

17161-->17162

12/3/2009

17161-->17162

13/03/2009

17161-->17162

14/03/2009

17161-->17162

物理信道失败，通常发生于UE上报测量报告，RNC成功判决并下发物理信道重配置后，无法在切换目标小区接收到UE的物理信道重配置完成消息。

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

【解决方法】

以下是同频、异频切换的相关定义：

同频切换事件

事件1G

当下列等式在触发时间（Time-to-trigger）内一直成立的时候，UE报告事件1G（最佳小区的改变）给RNC：

公式中的参数含义如下：

Mprevious_best是前最佳小区的当前P-CCPCHRSCP，单位mW

Oprevious_best是前最佳小区的单独偏移

Mi是正在评估的小区i的当前P-CCPCHRSCP，单位mW

Oi正在评估小区i的单独偏移

H1g是报告事件1G的滞后参数。

异频切换事件

当下列等式在触发时间（Time-to-trigger）内一直成立的时候，UE报告事件2A（最佳频率的更新）给RNC：

公式中的参数含义如下：

QNotBest是变量BEST_FREQUENCY_2A_EVENT中"bestfrequency"没有存储的频率质量估计。

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

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

其中估计的质量如下定义：

Qi,frequencyj是频率j上的小区i的估计质量。

Mfrequencyj是频率j上的小区i的P-CCPCHRSCP的测量结果，单位mW.

Oi,j是当前频率j上的小区i的小区单独偏移，Oi,j由IE"Cellindividualoffset"设置。

查询了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日执行）。

【效果对比】

展开阅读全文