WCDMA日常优化中TOP小区处理指导Word文档格式.docx
《WCDMA日常优化中TOP小区处理指导Word文档格式.docx》由会员分享，可在线阅读，更多相关《WCDMA日常优化中TOP小区处理指导Word文档格式.docx（27页珍藏版）》请在冰豆网上搜索。
问题小区分析、干扰排查、工单处理跟踪、测试验证。
2工作范围描述
2.1工作范围
（1）问题小区筛选
1）问题小区生成：
每日对日常投诉、指标和告警监控和DT、CQT测试和MR数据分析等发现的网络问题进行详细分析和分类，形成问题小区列表。
2）TOP小区生成：
在每日的指标监控中发现某些小区或者基站存在隐性故障，导致该小区或者基站出现性能下降现象时，应从该小区或基站的接入性能、保持性能、资源性能、覆盖性能入手进行相关的分析，找出综合指标最差的前N个小区，形成每日TOPN小区列表。
（2）问题小区处理
1）制定解决方案。
通过对日常投诉、指标和告警监控以及MR等数据信息进行汇总分析,对问题小区与TOP小区制定解决方案，以工单形式提交相关人员实施调整。
需要时可以进行现场测试。
2）跟踪问题小区的处理。
跟踪调整工单的执行进程和结果反馈，对已处理完成的小区观察其指标、告警信息的变化情况，需要时进行现场测试验证，确认问题解决情况。
对于连续出现5日以上的TOPN小区要重点关注及早优先解决。
3）对问题小区分析中发现的网络干扰问题进行分析、排查和处理。
对于无法处理的干扰，需及时提交分析报告给局方，由局方协调处理。
（3）周期性总结：
每周、月对问题小区处理情况进行汇总总结，对于现阶段暂无法解决的问题应形成说明。
（4）输出结果
1）问题小区分析处理记录；
2）每周、月问题小区分析和处理总结报告。
2.2工具准备
●Probe路测数据采集软件及Assistant后处理软件；
●Nastar性能统计分析工具；
●Insightsharp性能定位分析工具；
●UMAT工具；
2.3信息收集
●网络配置数据
●RNC的话统数据
●RNC的CHR数据
●RNC的告警信息
●日常DT/CQT数据
2.4操作步骤
图1问题小区处理流程图
根据日常的投诉，性能监控，告警以及DT/CQT等数据，发现需要处理的问题小区，制定相应的调整方案，按照计划实施调整内容，实施完成后，确认调整效果，输出问题小区分析总结报告。
2.4.1关键/风险点
1.对于网络出现的外部干扰源，应由局方为主导，由其协调相关的资源，进行处理。
2.对于因规划等原因无法解决的问题小区，比如覆盖问题，容量，license等问题，需要提出解决建议，提交给客户。
2.4.2Timelines
下面列出了1个问题小区的时间安排：
Process：
问题小区处理
WeeklyProgress
任务名称
任务描述
Duration
1st
2nd
3rd
4th
5th
T1/问题小区筛选
对日常投诉、指标和告警监控和DT、CQT测试和MR数据分析等发现的网络问题进行详细分析和分类，形成问题小区列表（包括TOPN小区）
每天
T2/制定解决方案
针对问题小区，制定解决方案
1个工作日
T3/问题小区的处理
根据调整方案，对问题小区进行处理.
1个工作日
T4/调整效果反馈和确认
根据性能统计或现场测试，验证调整方案的有效性
T5/输出周问题小区分析表
输出周问题小区分析表
2.4.3Checklist
表1问题小区处理checklist
TopN小区分析报告
CheckDate:
Name:
Item
Checkby
日常投诉问题处理建议
DT/CQT问题处理建议
性能数据的分析
告警问题小区的处理建议
T2/制定解决方案
输出问题小区处理建议
执行调整方案
审核调整效果，评估调整结果.
确认调整效果
T6/输出月问题小区分析总结报告
输出月问题小区分析总结报告
3问题小区筛选
利用NASTAR生成KPI日报时，将IncludeTOPNPage选项勾选上，生成的KPI日报将附带各项指标的TOP10小区。
如下所示：
NASTAR自动生成TOP10小区的指标共包括12项，如下所示：
指标名称
CSCallDropCells
PSRABFAIL
PSDropCells
SHOFAIL
HSDPAFAIL
InterFreqHHOFail
HSUPAFAIL
CSInterRATHHOFAIL
RRCFail
PSInterRATHHOFAIL
CSRABFAIL
HotTrafficCell
3.2利用insightsharp进行问题小区预过滤
3.2.1日志类型介绍
当前常用CHR日志分析工具insightsharp进行问题小区分析。
在利用insightsharp进行CHR日志分析时，需要对CHR日志先进行预过滤。
每项不同的指标有不同的过滤方法。
RAN12版本主要包括三类CHR日志。
每类日志记录内容与作用如下所示：
日志类型
记录内容
用于分析指标类型
CHR
记录切换失败信息
软切换失败、硬切换失败、异系统切换失败
CALLFAULT
记录接入失败信息
RRC接入失败、RAB建立失败、掉话
UPCHR
记录所有呼叫信息
所有类型指标（偏向于RF分析）
其中CHR和CALLFAULT日志主要记录CHR打点信息，UPCHR日志主要记录RF信息。
从各类日志类型的记录内容可看出，CHR日志类型只能用于切析切换问题，CALLFAULT只能用于分析接入和掉话问题。
3.2.2预过滤功能介绍
利用insightsharp软件的预过滤功能对日志文件进行预过滤，可避免因导入过多的日志文件而导致耗时长或软件卡住的现象。
通过预过滤可提高问题小区处理效率。
预过滤功能设置界面如下所示：
3.2.3各类指标预过滤方法
对CHR日志和CALLFAULT日志进行预过滤，在软件中自定义过滤器时都选择SPU_Single_User_Log日志类型，利用该日志结构树中的FAULTTYPE对不同的KPI问题进行过滤。
CHRMSGTYPECHOICESTRU下的8类FAULTTYPE分别对应不同问题指标的详细选项。
SPU_Single_User_Log日志类型日志结构树如下所示：
FAULTTYPE内容代表的问题指标如下所示：
FAULTTYPE内容
问题指标
RRCCONNECTIONREQFAULT
RRC连接失败
RABASSIGNMENTREQFAULT
RAB建立失败
SOFTHANDOVERFAULT
软切换失败
HARDHANDOVERFAULT
硬切换失败
INTERRATHO3G2GFAULT
3G2g切换失败
DROPCALLFAULT
掉话
CHRMSGTYPECHOICESTRU下8类FAULTTYPE对应的问题指标：
FAULTTYPE序号
FAULTTYPE1
RRC接入失败
FAULTTYPE2
FAULTTYPE3
SHO失败
FAULTTYPE4
HHO失败
FAULTTYPE5
interRAT切换失败
FAULTTYPE6
未知
FAULTTYPE7
FAULTTYPE8
3.2.4指标过滤方法举例
1、RRC接入失败
预过滤小区36473的RRC接入失败日志方法如下：
选择FAULTTYPE字段填写RRCCONNECTIONREQFAULT，选择FAULTTYPE1下的BESTCELLID字段填写36473，如下图所示：
2、RAB建立失败
预过滤小区36473下的RAB建立失败方法如下：
选择FAULTTYPE字段填写填写RABASSIGNMENTREQFAULT，选择FAULTTYPE2下的BESTCELLID字段填写36473，选择FAILEDCS字段填写包含”CS”
3、异系统切换失败
过滤小区31041、31044和31246三个小区的异系统异系统切换失败方法如下：
选择FAULTTYPE字段填写填写INTERRATHO3G2GFAULT，选择FAULTTYPE5下的BESTCELLID字段填写31041、31044和31246（选择三次该字段）。
4、掉话过滤
过滤小区36473下的掉话方法如下：
选择FAULTTYPE字段填写填写DROPCALLFAULT，选择FAULTTYPE7下的BESTCELLID字段填写36473。
如下图所示：
4问题小区处理思路
4.1接入问题分析
4.1.1RRC建立失败
1.上行RACH的问题
2.下行FACH功率配比问题
3.小区重选参数问题
4.下行专用初始发射功率偏低
5.上行初始功控问题
6.拥塞问题
7.设备异常问题等
造成RAB成功率低的原因有：
1无线环境原因，需RF调整，或者推动工程建设；
2小区资源拥塞：
包括功率资源、码资源、CE资源、Iub口带宽，用户设备设置导致；
3.上行干扰RTWP值异常；
4.排查基站或传输硬件故障。
从RNC侧来看，RRC连接建立失败包括两种情形：
一种是当RNC收到UE发送的RRCConnectionRequest消息后，向UE发送了RRCConnectionReject消息。
这种情况对应着“因Iub接口失败而拒绝RRC连接请求”和“因网络拥塞而拒绝RRC连接请求”这两类指标。
具体计数器打点位置如下图A点所示：
另外一种是RNC下发RRCCONNECTIONSETUP消息后，始终没有收到UE的响应（RRCCONNECTIONSETUPCOMPLETE或者RRCCONNECTIONSETUPFAILED）。
这种情况对应着“因无应答而导致RRC连接失败”这类指标。
导致RRC连接建立失败的常见原因如下：
1、因Iub接口失败而拒绝RRC连接请求
因Iub接口失败而拒绝RRC连接请求可以细分为以下几类原因：
RL建立失败导致RRC连接建立拒绝
RL建立失败一般情况下较少出现，可能原因包括：
●NodeB设备硬件问题，如功放过热（偶尔出现）
●NodeBCE数受限。
当NodeBcredits估计不准，不能真实反映NodeBCE数的使用状况时，有可能出现RNC认为NodeB的CE数足够，向NodeB下发RL建立消息，NodeB由于CE数受限返回RL建立失败。
发现RL建立失败导致RRC连接拒绝的次数不为零后，需要检查小区的负载情况，排除CE数受限的可能；
检查有无设备告警，排除空调、功放等问题引起的失败；
AAL2建立失败导致RRC连接建立拒绝
AAL2建立失败问题很少发生，当AAL2资源受限，或者小区出现故障的时候，才有可能出现。
2、因网络拥塞而拒绝RRC连接请求
对于网络拥塞而导致RRC连接失败，需要检查是哪种资源不足导致的。
其中无线资源的拥塞通常有如下几类：
功率资源申请失败
出现功率资源申请失败的时候，应该检查准入参数设置是否与默认参数一致。
如果参数设置合理，则需要通过话务量、等效用户数等计数器检查当前网络负荷。
如果网络负荷以及阻塞率确实达到扩容要求，则需要启动扩容。
上/下行CE资源申请失败
说明NodeBCE资源不足，需要结合当前实际话务负荷，检查NodeBCE资源配置情况。
码资源申请失败
说明码资源不足，需要结合实际的话务负荷给出合理的扩容手段。
3、因无应答而导致RRC连接失败
造成这种问题的主要原因包括以下两种：
UE没有收到RNC下发的RRCCONNECTIONSETUP消息
造成这种问题的原因可能是覆盖或者小区选择与重选参数配置不合理。
UE发出了RRCCONNECTIONSETUPCOMPLETE消息，但是RNC没有收到
可能是因为上行专用信道初始发射功率设置偏低。
4、因重定向而拒绝RRC连接请求
UE发起RRC链接建立请求，如果小区拥塞或资源分配（主要指准入、码资源分配）失败，且RRC直接重试算法全部失败，则触发重定向算法。
如果UE发起接入的主小区存在异频邻近小区或者GSM小区，则通过RRCconnectionreject信令的Redirectioninfo信元指示UE重定向到异频邻近小区的频点或者GSM小区。
如果不存在异频或GSM小区，则不配置RRCconnectionreject信令的Redirectioninfo信元。
4.1.2RAB指配失败
在RNC话统中，RAB指配失败计数器打点位置如下图所示：
如上图中B点所示，当RNC向CN发送失败的RAB指配响应RABASSIGNMENTRESPONSE消息时，根据具体失败原因，对相关计数器进行计数。
图中RB建立过程使用虚线标出，为可选流程。
RAB指配建立失败的原因如下：
1、无线网络原因
由于迁移导致RAB建立失败
因迁移导致RAB建立失败是指：
当RNC正在执行迁移，如果再收到来自CN的RABASSIGNMENTREQUEST消息，RNC不会处理此消息，直接向CN应答RAB指配失败RABASSIGNMENTREPONSE消息（失败原因为RelocationTriggered。
该指标一般出现机会较少，无需处理。
由于空口失败导致RAB建立失败
由于空口失败导致RAB建立失败是指：
当RNC收到UE回的RBSetupFailure消息后，会给CN回RABAssignmentResponse，携带的原因为“FailureintheRadioInterfaceProcedure”。
分析由于空口失败导致RAB建立失败，需要对RB建立失败原因进行分析，具体分析方法参见4.3.5中RB建立失败相关内容。
由于能力不足导致RAB建立失败
小区中因能力不支持导致的RAB指配建立失败具体原因包括：
●RequestedTrafficClassnotAvailable（18）
●RequestedMaximumBitRatenotAvailable（20）
●RequestedMaximumBitRateforDLnotAvailable（33）
●RequestedMaximumBitRateforULnotAvailable（34）
●RequestedGuaranteedBitRatenotAvailable（21）
●RequestedGuaranteedBitRateforDLnotAvailable（35）
●RequestedGuaranteedBitRateforULnotAvailable（36）
●RequestedTransferDelaynotAchievable（22）
该指标一般出现在小区拥塞时，如RequestedMaximumBitRatenotAvailable等。
需要注意的是，这个指标的触发原因包含了下面的几种“无线资源拥塞导致失败”指标的原因；
●功率不足导致CSRAB拒绝
●上行CE资源不足导致CSRAB拒绝
●下行CE资源不足导致CSRAB拒绝
●码资源不足导致CSRAB拒绝
●IUB带宽不够导致CSRAB拒绝
可以通过查询相关指标，确定具体是什么资源不足导致失败，并作相应扩容处理。
其他无线网络原因导致RAB建立失败
除了上述原因外还有一些其他原因导致CSRAB指配建立失败，如RB建立无响应等。
。
其他无线网络原因造成的RAB建立失败，一般来说无法从话统上直接获得原因，通常需要通过DT或者其他测试方法及分析手段定位。
2、传输网络原因
CS域因传输承载建立失败导致的RAB指配建立失败的具体原因包括：
●SignallingTransportResourceFailure（65）
●IuTransportConnectionFailedtoEstablish（66）
该指标出现一般表示传输出现问题，需要检查Iu口的传输是否异常。
4.2切换问题分析
4.2.1软切换失败
从流程上看，软切换可以分为软切换准备过程和软切换空口过程，其中准备过程是从切换判决到RL建立完成，空口过程是激活集更新过程：
1、首先查看忙时全网和小区的软切换成功率是否达标，如果没有达标，则需要找到主要的问题小区进行详细分析。
2、对小区的（更）软切换失败次数进行TOPN排序，找出几个失败次数最高的小区，并列出具体的失败原因指标，如果不能直接从话统上找到具体的失败原因，还要分析对应的CHR。
下表列出了（更）软切换失败的详细话统指标和分析思路：
失败原因
分析思路
配置不支持
UE认为RNC增加/删除链路的激活集更新的内容不支持。
这种场景在商用网络中基本不会出现
同步重配置不支持
UE反馈RNC增加/删除链路的更软/软切换过程与其他并发过程不兼容。
RNC在流程处理的时候已经保证了串行处理，出现这种情况主要是一些手机自身处理出现问题
非法配置
UE认为RNC增加/删除链路的激活集更新的内容非法。
UE无响应
RNC没有收到增加/删除链路的激活集更新命令响应。
这个在网络中是更软/软切换失败的主要原因，主要是发生在覆盖比较差或者切换区比较小的区域，需要RF优化
4、进行路测重现问题。
由于话统给出了趋势，并给出了可能的问题，具体问题的定位和分析还需要结合路测或者针对小区的CHR分析来进行。
对于问题小区，一般都需要安排针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。
4.2.2硬切换失败
整个硬切换阶段失败，重点关注以下指标，包括NODEB内、NODEB间和RNC间的指标，下表同时给出了具体的分析思路。
硬切换准备失败
无线链路建立失败
为RL建立过程中的失败，具体见IUB接口RL建立过程分析
其他原因
需结合CHR日志进行进一步的分析
NODEB内/NODEB间/RNC间硬切换出失败
UE认为硬切换出小区的命令不支持，一般为手机兼容性问题
物理信道失败
可能为覆盖较差或者干扰较严重
UE反馈硬切换过程与其他并发过程不兼容，可能为手机自身兼容性问题
小区更新
在硬切换出小区的过程中，发生了小区更新，这种流程嵌套导致了硬切换出小区失败
UE认为硬切换出小区的命令非法，一般为手机兼容性问题
4.2.3系统间切换失败
1.UMTS服务小区上行链路质量较差
2.事件2D、3A门限设置不合理,参数设置不合理
3.当前UMTS小区邻区配置漏配GSM小区
4.当前UMTS小区的GSM邻区配置过多
5.目标GSM小区无可用无线资源、目标GSM小区干扰严重。
1、CS系统间切换失败
CS系统间切换出过程分为切换准备过程和执行过程。
切换出准备过程如下所示：
在CS域系统间切换出过程中，当RNC向CN发送RELOCATIONREQUIRED消息时，如果当前CS的业务为AMR语音业务，则统计为一次系统间切换准备。
当RNC收到CN返回的IURELEASECOMMAND消息时，按UE当前使用的SRNC的小区统计为系统间切换出成功。
如果发生CS系统间失败，需要查看以下失败统计指标：
RNC级异系统切换出准备失败
等待迁移命令超时
核心网没有返回切换准备请求的相应命令。
这种情况往往是核心网参数配置或者相关链路连接有问题，需要根据核心网与BSS的信令跟踪进行原因分析
迁移取消
RNC请求切换准备后，收到核心网的释放命令。
这种情况往往是两种情况，一是位置更新等信令过程发生系统间切换请求，流程还没有完成前已经完成了位置更新流程，核心网发起释放；
二是建立呼叫的用户在切换准备时就挂机，核心网发起释放。
这两种情况虽然切换没有完成，但都是正常的流程嵌套
迁移超时
一般对应着核心网配置错误，需要根据核心网与BSS的信令跟踪进行原因分析
在目标CN/RNC或系统中迁移失败
一般对应着核心网配置错误或者BSS系统不支持，需要根据核心网与BSS的信令跟踪进行原因分析
未知目标RNC
这种情况往往是MSC参数配置错误，没有配置目标小区的LAC等信息，需要核心网检查参数配置
升级会员 