华为后台KPI处理.docx
《华为后台KPI处理.docx》由会员分享，可在线阅读，更多相关《华为后台KPI处理.docx（21页珍藏版）》请在冰豆网上搜索。
接 入类问题分析
一、RRC连接建立&RRCFail分析
1、RRC建立过程的主要步骤为：
1）UE通过RACH信道发送RRCConnectionRequest消息；
2）RNC通过FACH信道发送RRCConnectionSetup消息；
3）UE在家里下行专用信道并同步后通过上行专用信道发送RRCConnectionSetupCMP消息；
2、RRC建立失败的主要原因有：
1）上行RACH问题；
2）下行FACH功率问题；
3）小区重选参数设置问题；
4）下行专用信道初始发射功率偏低；
5）上行初始功控问题；
6）拥塞问题；
7）设备问题。
3、在分析不同原因造成RRC建立成功率低时结合一下指标原因：
指标
含义
原因
VS.RRC.Rej.RL.Fail
小区中RL建立失败导致的RRC连接建立拒绝的次数（不包含CE拥塞的RL建立失败）
设备问题
VS.RRC.Rej.AAL2.Fail
小区中AAL2建立失败导致的RRC建立拒绝
传输问题
VS.RRC.Rej.POWER.Cong
功率资源申请失败
VS.RRC.Rej.UL.CE.Cong
上行资源申请失败
VS.RRC.Rej.DL.CE.Cong
下行资源申请失败
VS.RRC.Rej.CODE.Cong
码资源申请失败
RRC.FAIL.ConnEstab.NoReply
RNC向UE发送RRCConnectionSETUP消息后没有收到UE发送的RRCConnectionSETUPCMP消息次数
可能由于覆盖问题或终端异常问题导致
在这些问题中，上行RACH和下行功率配比问题、小区重选参数问题以及设备异常问题
出现的概率较高。
4、RRC连接建立问题分析流程及分析过程：
RRC连接建立问题分析流程
UE是否发出请求消息
----------------N-------------→
手机异常问题
↓Y
RNC是否收到请求消息
----------------N-------------→
调整PRACH或AICH信道参数
↓Y
RNC是否发出建立消息
-N→
RNC是否发出RRCRej消息
-Y→
进行拥塞和准入检查
↓Y
↓N
其他问题
UE是否收到建立消息
-N→
是否发生小区重选
-N→
调整FACH功率
↓Y
↓（Y）
优化重选参数
UE是否发出建立完成消息
----------------N-------------→
调整下行初始发射功率
↓Y
RNC是否收到建立完成消息
----------------N-------------→
调整上行专用信道开环功控参数
↓Y
结束
具体分析过程如下：
1）UE发出RRCConnectionREQ消息，RNC没有收到。
如果此时下行CPICH的ECIO较低，则是覆盖问题；
如果此时下行CPICH的ECIO不是太低（-14dB左右），一般都是RACH问题
2）RNC收到RRC建立请求消息后，下发了RRCConnectionSetup消息，而UE没有收到
可能原因：
（1）覆盖差；
（2）小区选择与重选参数设置不合理；
3）RNC收到RRC建立请求消息后，下发了RRCConnectionSetup消息，当出现RRCConnectionReject消息时，需要检查具体的拒绝原因值，包括：
congestion和unspecified。
Congestion：
说明网络发生了拥塞，需要检查负载，包括功率、码、CE资源等，确定是哪种拥塞后再对相应的资源进行扩容操作；
Unspecified：
需要结合其它信息，确定故障原因。
4）UE收到RRCConnectionSetup消息而没有发出SetupCMP消息
若下行信号正常，可能是手机问题；否则是下行信道初始发射功率过低，导致下行不能同步，可以通过调整业务下行Eb/No解决。
5）UE发出RRCConnectionSetup消息而RNC没有收到
上行初始功控会让手机发射功率攀升，可以适当提高UE上行DPCCH初始发射功率，此为小概率事件，且该参数为RNC级参数，需要谨慎操作。
5、RRCFail案例分析
1）、TCELL参数配置错误导致RRC建立失败率高
现阶段因为接入参数配置错误而导致RRC建立失败在项目现场占多数情况，一般情况下，对于RRC建立失败需要首先检查参数，主要包括：
CELLID、PSC、LAC、RAC、TCELL等。
例如：
某站开通过后单站验证已通过，后因覆盖需要，增加第四小区。
对第四小区进行单站验证的过程中发现该小区无法接入，进行参数核查发现该第四小区TCELL参数和三小区TCELL参数配置相同，修改该小区TCELL参数为CHIP768后问题消除。
2）、如下图为某天杏坛景泰W1小区的RRC建立情况：
RNCId
CellId
CellName
Date
RRC建立失败次数
RRC建立请求次数
小区中RL建立失败导致RRC连接建立拒绝的次数（不含CE拥塞导致的失败）
391
32731
杏坛景泰W1
2009-7-28
2266
2271
521
杏坛景泰W1小区RRC建立成功率非常低，导致RNC7的RRC建立成功率也拉低到94%。
分析一共有2266次失败，其中521次为RL建立失败致RRC连接建立拒绝，这些失败原因中有80%是因为用户处于3G和2G覆盖交叉区域，且2G和3G信号都较差，反复进行异系统重选但是都失败，调整异系统小区重选门限为1（2db）。
同时其它1500多次失败是因为OTHER原因导致的，原因不明，暂时无法解决。
第二天观察发现依然有很多的RRC建立失败，经过昨天的调整效果并不明显。
经华为同意对该小区进行复位后问题消除，经核实为信令吊死导致的RRC建立失败。
【注】RRC建立失败可以参考接入问题分析，如下：
二、RRC.FAIL.ConnEstab.NoReply
RNC侧：
MML命令：
MODUFACH
Ø功率拥塞
WCDMA系统中功率拥塞的原因:
1.用户多，业务量大；
2.覆盖远（覆盖差）；
3.环境质量差，导频污染，干扰等；
4.功率参数设置不合理；
解决办法：
1.扩容，加站；
2.缩小覆盖范围；
3.净化导频，排除干扰；
4.提升功率，合理配置功率参数
上行功率拥塞：
将上行功率拥塞小区的上行准入控制算法开关关掉
MML命令：
ADDUCELLALGOSWITCH
下行功率拥塞
功控调整
减少HSDPA最大用户数
ØXPU负荷过高处理方法：
1、查询现网XPU利用率（性能-结果查询-XPU查询）
2、拿现网XPU槽框子系统号跟工参进行VLOOKUP，不匹配的就是现在不用的
3、将负荷过高的小区，挪到利用率低或不用的XPU槽上（MOVUCELL）
ØIUB拥塞
修改激活因子
改之前先看是否有告警
1在RNC侧，先查邻节点信息：
LSTADJNODE
2在RNC侧：
MODADJMAP（邻节点标识及基站ID从RAN报表基站报表里提取）
改之后再次确认是否存在告警，小区健康状态！
DSPUCELLCHK（按小区查询，看有无用户接入）
ØCE拥塞处理
1、CE资源介绍
CE（ChannelElements）就是基站的基带的资源，俗称信道板,CE是一种硬件资源，通过增加信道板就可以扩容，CE是基站的所有扇区共享的，公平竞争。
CE资源可以分为上行CE资源与下行CE资源，CE资源的容量大小由两个方面来限制，硬件能力与License限制，一般采用“硬件一步到位，软件逐步升级”的方式来配置。
CE是物理信道，TCH是逻辑信道，1个CE可以承载一个典型的12.2K语音业务。
其他业务占用的资源都按照CE进行折算。
在CE消耗方面，主要为PS384以及HSUPA所需要的CE资源最多，HSDPA下行业务只消耗Code，不消耗CE，下行伴随信令，每用户消耗1个CE。
HSUPA业务按照上传速率消耗CE,上传速率越高，消耗CE资源越多。
上行HSUPA用DSP来处理基带信号，业务信道只消耗上行的CE资源。
根据每户数据流量查表的每户CE消耗（每HSUPA用户在考虑0.3的信令消耗CE），再乘以并发用户数即为单载扇HSUPA所需CE数，即：
CE_HSUPA;HSUPA上行伴随信令，每个用户消耗1个CE。
HSDPA业务使用FPGA专用芯片处理的，不占用基带处理板下行CE资源，只消耗Code，不消耗CE。
码道和HS-SCCH与CE计算无关。
只有信令处理和上行业务用到少量的CE，其他的下行业务DSP处理。
R99数据业务对CE资源消耗较高。
基带处理板又称BPC板，不同厂家的不同规格的基带处理板可支持的最大CE数是不同的，BPC单板处理的各种业务资源消耗如下表所示：
业务类型
上行业务类型
上行CE消耗数
下行业务类型
下行CE消耗数
3.4KSF256
1
3.5kSF256
1
R99
AMR12.2kSF64
1
AMR12.2kSF128
1
PS32kSF32
1.5
PS32kSF64
1
CS64kSF16
3
CS64kSF32
2
PS64kSF16
3
PS64kSF32
2
PS144kSF8
5
PS144kSF16
4
PS384kSF4
10
PS384kSF8
8
HSUPAPhase1
1.44MbpsTTI=10ms
HSUPA
SF64
2
SF32
2.5
SF16
4
SF8
6
SF4
11
2xSF4
21
2xSF2
NoSupport
2Xsf2+2Xsf4
NoSupport
HSUPAPhase2
5.76MbpsTTI=2ms/10ms
SF64
1
SF32
1.5
SF16
2
SF8
4
SF4
8
2xSF4
16
2xSF2
32
2Xsf2+2Xsf4
48
2、CE拥塞处理
对于存在CE拥塞的小区处理思路为：
1、话务模型分析：
分析是否出现异常的话务模型转变，存在突发的大规模业务；
2、软License扩容：
对于实际业务量较高区域，软License开通CE数未达到基带板最大能力的小区，通过软License扩容实现；
3：
基带板硬件扩容：
如果软License扩容已达最大数目，需要通过增加硬件单板来实现扩容，增加单板硬件需要将小区重新配置，合理分配基带资源；
4、特殊手段处理：
对于业务量大但短时间无法硬件扩容的小区，可通过调整2msTTI与10msTTI上行TTI切换信用度预留扩频因子门限，2msTTI速率门限，或者关闭2msTTI功能来降低CE消耗。
（1）打开基于准入CE的TTI动态调整算法开关（现网默认打开），缓解2msTTI打开后引起的准入CE拥塞问题。
SETUCORRMALGOSWITCH:
DraSwitch=DRA_BASE_ADM_CE_BE_TTI_RECFG_SWITCH-1;
（2）设置上行TTI切换信用度预留扩频因子门限（现网默认为SF8
升级会员 