WRTWP相关问题定位分析处理指导书0221A10.docx
《WRTWP相关问题定位分析处理指导书0221A10.docx》由会员分享，可在线阅读，更多相关《WRTWP相关问题定位分析处理指导书0221A10.docx（83页珍藏版）》请在冰豆网上搜索。
WRTWP相关问题定位分析处理指导书0221A10
W-RTWP相关问题定位分析处理指导书-20120221-A-1.0
Preparedby
刘琼，张俊杰，张琼，邹容
Date
2011-10-27
Reviewedby
Date
Reviewedby
Date
Approvedby
Date
图表
修订记录
日期
修订版本
描述
作者
20111027
1.0
完成文档
张俊杰
1RTWP问题概述
RTWP：
ReceivedTotalWidebandPower，即接收总带宽功率，常用来度量基站的干扰水平，在基站空载的情况下，RTWP等于基站的底噪。
话务的提高，系统外的干扰、天馈射频故障、或任何系统实现bug、异常终端等异常原因都有可能导致RTWP的抬升（如下图），对于不同原因造成的RTWP抬升应有不同的处置方式。
本文旨在给出一套系统的分析方法，定位RTWP抬升的原因，对于正常的RTWP抬升，能给出合情合理的解释；对于异常的RTWP抬升，能给出对应的处置方案。
Figure1RTWP问题分布图
根据全球多个局点的反馈，目前亟待解决的RTWP问题包括：
1、RTWP抬升导致的KPI指标异常；
2、实际RTWP的均值不符合话务评估所预计的RTWP抬升；
3、对于5~20s的RTWP持续抬升，能找出原因解决；
4、对于1s左右的尖峰，能定位抬升的根因，给出合理解释。
本文文档结构如下：
第二章开始，介绍RTWP在W系统中应用的相关基本原理及数据采集方法。
第三章开始，介绍如何进行RTWP系统问题定位，如何判定可能原因，如果要进行问题定位，可直接跳过第二章。
第四章介绍各种引起RTWP问题的可能原因的具体排查方法。
第五章介绍一些可用的改进措施。
2RTWP基础知识及信息采集
2.1RTWP定义
RTWP：
ReceivedTotalWidebandPower，即接收总带宽功率，常用来度量基站的干扰水平，反映射频模块天线接收口接收到的信号强度。
RTWP检测方法如下：
Figure2底噪开关关时RNC底噪查询结果示例RTWP检测方法
天线接收到的信号P_in，通过塔放（选用）和NodeB（RRU）的放大，然后通过数模转换，统计计算得到P_out，RTWP即代表了天线口接收到的信号功率：
RTWP=P_in=P_out-G
其中，G为接收通路总增益，是塔放增益（选用）和NodeB增益之和，是一个恒定值。
RTWP在NodeB测量，并上报给RNC，作为准入、拥塞控制等使用。
NodeB测量每个小区每个接收通道上的RTWP，而RNC上跟踪到的小区RTWP一般为NodeB上小区所有通道的RTWP平均值（线性域的平均）。
2.2基站底噪
在接收机无信号输入的情况下，即在无外界和系统内干扰、系统内无用户的情况下，基站测量到的RTWP即为底噪。
基站底噪计算方式如下：
PN＝KTB＋NF，其中：
✓K=波尔兹曼常数
✓T=290K（室温）
✓B=射频载波带宽（Hz）=3.84MHz。
✓NF表示射频系统的噪声系数。
可以计算得到在室温条件下，基站底噪≈-106dBm。
由于射频系统的模拟电路特性（器件性能受到频率/温度等外界环境因素的影响），以及室温T引入的变化，底噪在-108～-104dBm之间，属于正常范围。
在某些组网配置下，基站的底噪会有所抬升，主要包括下面两种情况：
（1）.使用塔放或干放,但是未配置接收通道衰减量时，基站底噪会抬升；抬升量X＝塔放增益－馈线/跳线衰减量。
基线配置见4.4.2接收通道衰减量配置。
（2）.使用分布式RRU共小区配置（注：
RAN13.0以后多RRU共小区不再带来底噪抬升）；底噪抬升量与共小区RRU数目相关，假设N台RRU共小区，计算方法为△N=10log（N）dB。
2.2.1底噪的查询和设置
底噪的大小可以在RNC上用LST（MOD）UCELLCAC来查询和设置，一般来说底噪的设置有两种可能：
1、底噪（背景噪声）自动更新关
若底噪自动更新算法是关，以这个固定值为准，默认是61。
Figure3底噪自动更新开关关时RNC底噪查询结果示例
这个61应该根据小区空载时刻的测量值来设置，根据小区空载时刻RTWP值为-106dBm，与-112dBm的协议规定RTWP最小值相减得到的，计算方法如下：
（RTWP-（-112））*10+1=BackgroundNoise
（-106-（-112））*10+1=61
当然-106dBm不可能是所有场景和环境都适用的，比如某站点的空载RTWP就是稳定的-106.3dBm，属于正常值，我们根据这个值，计算出来的底噪值就应该是58。
2、底噪自动更新开
若底噪自动更新算法（开关1）是开，则是以下的生效方式：
（1）.在底噪自动更新开始时间（开关4）和底噪自动更新停止时间（开关5）的时间段内，底噪自动更新算法才可能被触发。
（2）.如果在生效时间段内，等效用户数小于设置值（开关3）并持续底噪自动更新触发持续时长（开关2），变化大于底噪更新触发门限（开关6）。
Figure4底噪开关开时配置实例
2.3底噪抬升
噪声抬升（RiseOfNoise，简称RoT）是指基站噪声相对底噪的抬升的倍数，即：
其中
为总干扰，其dB域一般写为RTWP。
在dB域，可以表示为：
RoT（dB）= RTWP（dBm）–PN（dBm）
基站的总噪声包括：
✓基站底噪PN；
✓系统内干扰，包括本小区UE发射的上行信号Ior和来自邻区UE发射的上行信号Ioc；
✓射频干扰，包括来系统外射频干扰（比如异系统干扰，非通信系统干扰等），也包括系统内的射频干扰（主要是系统内器件产生的互调干扰）。
在不存在射频干扰的情况下，RoT全部由系统内干扰产生，此时RoT可以作为上行负荷的衡量标准。
上行负荷因子与RoT的关系如下：
二者的关系曲线如下：
Figure5上行负荷因子与RoT的关系曲线
负荷因子用于准入和拥塞控制。
负荷因子的基线为75%负荷，对应的RoT为6dB。
因此在现网的话务状况下，RoT在6dB以下为正常水平。
如果RoT超过6dB，则可以认为RTWP异常，需要定位。
2.4RTWP相关信息跟踪及采集指导
现网小区的RTWP可以通过获得三种粒度的数据，其一为RNC话统（粒度：
半小时），其二为实时跟踪包括例行跟踪（粒度：
1s），其三为CDT跟踪（粒度：
2ms）。
三种方式各有优缺点，有的可以跟踪主分集的RTWP，部分跟踪只能跟踪主分集RTWP的平均值（如Figure6）。
问题定位时可以结合三类数据，从粗到细的逐步进行问题筛查（参见第3章）。
Figure6RTWP数据采集节点图
2.4.1RNC话统（粒度：
半小时）
RNC话统一般可以给出每个小区统计周期（最小为半小时，一般为一小时）内的最大、最小和平均RTWP。
2.4.2RNC/NodeB实时跟踪（粒度：
1s）
实时跟踪RTWP可以在RNC跟踪，也可以在NodeB跟踪每根接收天线上的RTWP。
实时跟踪RTWP可以在更细的时间粒度上观察上行干扰的状况，更精细地判断RTWP是否异常及异常原因。
对于用户可观测到的RTWP值，根据来源，分为单板RTWP和小区RTWP。
RNCLMT实时RTWP跟踪（主分集平均RTWP）
RNC跟踪的RTWP是NodeB对主分集进行平均后的值（粒度：
s），然后由NodeB通过公共测量消息上报给RNC，如果小区的主分集RTWP基本一致，可以选择在RNC上跟踪。
RNC上RTWP跟踪基本上不会中断，但是无法区分主分集的差异，可以定性的判断当前是否由干扰存在。
可选择同步跟踪小区用户数统计，用于观察RTWP和业务的关系。
Figure7RNCLMT实时跟踪示意图
下图为RNC上跟踪的实时RTWP示例（跟踪周期为1秒，时间为10:
00-17:
00，7个小时）。
Figure8RNC上跟踪的实时RTWP示例
下图为RNC上跟踪小区用户数统计（跟踪周期为1s）的方法：
Figure9RNC上小区用户数跟踪
NodeBLMT单板RTWP跟踪（主分集RTWP）
如果需要实时查看某个小区主分集RTWP变化情况，可以在NodeB的LMT上根据RRU进行跟踪，优点是可以实时查看每个接收通道的RTWP，缺点是由于传输原因，NodeB上的实时跟踪经常会中断（如果需要采集数据进行后台批量主分集RTWP数据分析，则可采用2.4.4的方法获取到同样的信息）。
1）根据LSTLOCELL得到本小区的RRUID
Figure10单板RTWP跟踪NodeBLMT跟踪设置（步骤一）
2）跟踪指定RRU的单板RTWP：
Figure11单板RTWP跟踪NodeBLMT设置（步骤二）
Figure12NodeBLMT跟踪结果示意图
NodeBLMT小区RTWP跟踪（主分集平均RTWP）
Figure13NodeB小区级RTWP跟踪项
注：
该选项R13版本起可用。
2.4.3NodeBCDT
NodeBCDT可以跟踪用户接入过程中链路更改、功控和误码等情况，同时可以跟踪2ms级别的RTWP（主分集平均）信息，可直接对应物理层用户行为，也可部分识别外界干扰。
主要包括用户跟踪和小区跟踪，跟踪指导如下：
1.启动用户跟踪
Figure14NodeBCDT用户跟踪设置界面示意图
2.启动小区跟踪（2msRTWP）
小区ID一栏中输入本地小区ID。
Figure15NodeBCDT小区跟踪设置界面（R13版本）
Figure16NodeBCDT小区跟踪设置界面（R12版本）
由于分析2msRTWP数据使用的UMAT工具和PreStar工具目前仅在研发内部使用，不开放给一线人员，所以对于2msRTWP数据的提取分析工作建议由研发人员完成，现场将小区CDT文件发给研发人员即可。
2.4.4RTWP例行测试（主分集RTWP跟踪）与分析工具。
这个数据采集内容本质上和单板RTWP跟踪是一样的，好处在于可以全网收集。
在M2000上可以批量选择NodeB进行例行跟踪，这个例行跟踪数据只存在NodeB的高端内存中，设定了一定的存储容量，超过该容量后RTWP会循环写入。
数据存储比较安全，除了基站掉电或者基站升级，数据都不会丢失，即使在基站重启的情况下也不会丢失。
可以选择部分NodeB跟踪，建议在M2000上选择所有的NodeB进行跟踪，以便需要分析某个NodeB的RTWP数据可以随时获取。
1.RTWP例行测试数据跟踪、数据获取与数据处理方法
RTWP例行测试数据跟踪、数据获取与数据处理方法见：
《附件1RTWP例行上报采集方法及分析工具RTWPAnalysis使用指导.docx》
2.RTWP例行跟踪数据分析与天馈线接反检查工具RTWPAnalysis
目前RTWPAnalysis工具提供4个功能项
（1）.保存小区RTWP数据到Txt文档
（2）.生成小区RTWP数据为Png图片文件
（3）.检查站点射频天馈线接反问题
（4）.天馈线互调检查
（5）.小区主分集RTWP差异分析
RTWP例行跟踪数据分析与天馈线接反检查工具RTWPAnalysis，见：
《附件2RTWPAnalisysTool.rar》
3RTWP问题排查流程
3.1RTWP异常判断的入口条件
一般来讲，出现以下几类问题，需要排查RTWP是否正常。
而RTWP问题可能的引发原因也如图显示：
Figure17RTWP类问题表现现象及可能原因
3.1.1射频相关告警
通过M2000排查基站告警，获取与射频及天馈系统相关的告警信息。
这些告警都将直接或间接影响RTWP表现，需第一时间进行排除。
具体处理方法参见章节4.2
序号
告警名称（RAN12版本）
1
ALM-26522射频单元接收通道RTWP/RSSI不平衡告警
2
ALM-26521射频单元接收通道RTWP/RSSI过低
3
ALM-26532射频单元硬件故障告警
4
ALM-26752天线设备硬件故障告警
5
ALM-26758塔放运行数据异常告警
6
ALM-26755塔放旁路告警
7
ALM-26757电调天线运行数据异常告警
8
ALM-26541天线设备维护链路异常告警
9
ALM-26529射频单元驻波告警
3.1.2M2000阈值告警
通过M2000的阈值管理功能，监控RNC小区的RTWP话统数据，根据话统指标VS.MeanRTWP和VS.HSUPA.UE.Mean.Cell来判断小区RTWP是否存在异常的情况（阈值设置方法见附录6.1）。
具体的判断方法和话统排查方法3.2.2一致。
3.1.3KPI异常及业务投诉
如果出现掉话率等KPI指标异常或收到UPA吞吐率低等业务投诉，需要考虑是否RTWP异常导致。
小区在正常的运行过程中，突然出现KPI指标明显变差，比如出现掉话率升高，HSPA速率下降的问题，有可能是由于小区的受到外部干扰，互调干扰造成上行容量下降导致的，需要对RTWP问题进行排查。
特别是在实施搬迁、扩载频、新建站点等工程施工后，更需要考虑是否可能存在互调干扰、外部干扰、业务容量等问题导致的RTWP高，建议按照3.2描述方法进行排查。
而如果升级后KPI指标变差，则可能是业务软件问题导致，不需要重点关注RTWP，建议按照正常的问题定位流程处理。
一般可以参考以下这些Counter值进行判断:
Counter
VS.MeanRTWP
VS.MinRTWP
Cell.RRC.Att.Fail.Rate
VS.PS.Call.Drop.Cell.Rate
VS.CS.AMR.Call.Drop.Cell.Rate
VS.CS.VP.Call.Drop.Cell.Rate
Cell.Call.Drop.Rate
VS.CellDCHUEs
VS.HSUPA.MeanChThroughput
所需要关注的counter不仅限于上面这些，重点需要关注涉及小区的掉话率，HSPA吞吐率等方面的指标。
3.2RTWP异常判断及定位分析
3.2.1问题排查流程
对于小区RTWP异常的问题，总体按照以下处理流程进行判断：
Figure18RTWP问题分析总体流程
流程说明：
1、通过对话统中RTWP数据的分析，可以大致判断小区RTWP抬升是由于系统本身造成的还是外部干扰导致的。
2、通过对单站点小区RTWP分析，可以判断小区RTWP抬升的可能原因
3、当对RTWP抬升的原因分析无法有效确定干扰来源的情况下，通过采集小区CDT数据中的2msRTWP数据，可以通过信号特征，来判断干扰的来源。
分别根据话统和实时跟踪的底噪、闲时/忙时RTWP话统数据分析，对RTWP异常现象进行分类如下，作为RTWP问题排查流程的输入。
RTWP偏高判断门限：
闲时大于-100dBm，忙时大于-90dBm。
3.2.2方法一：
通过话统指标进行问题判断：
分析如Fiture19所示的话统指标，根据RTWP和小区用户数的相关关系判断是系统外部原因还是系统内部原因。
VS.MinRTWP
VS.MeanRTWP
VS.CellDCHUEs
Figure19典型RTWP相关RNC话统指标
异常类别
异常子类别
现象描述
底噪
话统
持续过高
闲时MinRTWP过高，不同时间段的MinRTWP一致
间歇过高
闲时MinRTWP过高，不同时间段的MinRTWP不一致
闲时RTWP
话统
持续过高
闲时MeanRTWP过高，不同时间段MeanRTWP基本一致
间歇过高
闲时MeanRTWP过高，不同时间段MeanRTWP不一致
忙时RTWP
话统
持续过高
MeanRTWP过高，MeanRTWP与话务量基本保持一致
间歇过高
MeanRTWP过高，MeanRTWP与话务量无明显关联，在不同时间段差别较大
1.无用户时底噪抬升
无用户时底噪抬升超出3dB以上，按照优先级高级可能存在以下几类问题：
A、是否为RRU分布式小区组网方式：
RRU分布式小区组网方式会固定带来△N=10log（N）dB的底噪抬升。
B、射频通道配置问题：
如果无用户时RTWP底噪抬升相对稳定的值，有用户时RTWP抬升和用户个数增加成正比，则可能是射频通道的相关射频参数配置错误，导致底噪偏高。
C、外部持续干扰：
稳定的外部干扰，导致底噪偏高（如Figure21）。
Figure20RNC话统指标图（夜间干扰）
注：
如Figure20（4天的话统数据），绿线是MeanRTWP，黄线是MinRTWP，蓝线是CellDCHUEs小区用户数，从图中可以看出，在夜间，用户数为0的情况下，RTWP持续抬升超过5dB，说明这个小区存在持续外部干扰。
肯定不是通道配置和分布式RRU问题，因为白天底噪MinRtwp下降至正常值。
注：
坐标说明：
上图的纵坐标，小区用户数取的是绝对值，RTWP数据是相对值，取的是与-106的差值，横坐标是数据的序列号。
后面的图都按照此标准处理。
Figure21RNC话统指标图（持续干扰）
注：
如图Figure21（4天的话统数据），绿线是MeanRTWP，黄线是MinRTWP，蓝线是CellDCHUEs小区用户数，从图中可以看出，在用户数很少的情况下，RTWP持续抬升超过15dB，说明这个小区很可能存在持续外部干扰。
那么，由于用户数很少，无法判断RTWP和用户数的联动关系，因此是否可能存在射频通道配置异常问题？
从上图看，不大可能，因为底噪MinRTWP还有恢复正常的时刻。
D、软件上报RTWP值异常：
是否做过升级操作，如果升级后出现，则可能是软件问题导致RTWP值底噪异常。
E、互调问题：
互调特性较差的天馈系统，即使发射源功率较小的情况下，仍然会产生明显的互调。
U900/U850频段多发，U2100互调问题概率很低。
2.底噪正常，RTWP的抬升和用户数不存在明显的关联性
MeanRtwp（绿线）抬升和小区用户数（蓝线）没有关联关系（参见figure22、figure23、figure24），可结合临小区或同覆盖小区数据进行联合分析。
一般来讲，该小区的RTWP异常问题可能是由以下几点造成的：
A、外部干扰：
包括外部持续干扰、间歇干扰；
Figure22RNC话统指标图（间歇干扰）
Figure23RNC话统指标图（间歇干扰）
Figure24同一时段两个邻小区的话统数据
注：
如图Figure24（4天的话统数据），绿线是MeanRTWP，黄线是MinRTWP，蓝线是CellDCHUEs小区用户数，从图中可以看出，RTWP持续抬升10dB以上，和邻小区的抬升情况类似，说明这片区域很可能存在间歇性随机干扰。
B、天馈连接错误：
可能小区RTWP波动反映的是邻区用户数的变化情况。
这个判断一般需要结合3.2.3方法二进行判断。
C、RRU故障：
请参考3.2.3方法二进行详细数据分析。
D、业务存在问题：
请参考3.2.3方法二进行详细数据分析。
3.如果RTWP随着用户数的变化而变化，用户数越多，RTWP越高
RTWP和用户行为基本一致，某些时段异常高，则该小区RTWP异常问题可能是由以下几点造成的：
A、互调干扰：
小区的发射功率越大，则产生的互调信号干扰越明显。
B、邻区干扰：
由于邻区配置参数错误，导致用户切换时抬升本小区RTWP。
Figure25RNC话统指标图（邻区干扰）
注：
如图Figure25（三个小区4天的话统），绿线是MeanRTWP，黄线是MinRTWP，蓝线是CellDCHUEs小区用户数，从图中可以看出：
小区2和小区3由于用户数很多，RTWP抬升10dB以上，有可能确实是空口容量受限导致，但是小区1在用户数很少的情况下，RTWP抬升也超出10dB，则很有可能是由于邻区干扰引入。
C、用户容量受限：
小区覆盖的用户数超出了原先设计的容量，造成用户接入次数增加，而导致小区整体RTWP增加。
D、切换问题：
由于切换问题导致产生业务邻区干扰。
已知问题参见附录，可一一核对是否存在已知问题。
E、业务问题：
可在忙时段采集1s级RTWP跟踪和2msRTWP跟踪，通过方法二,方法三进行详细确认。
Figure26RNC话统指标图（容量受限）
注：
如图Figure26（4天的话统），绿线是MeanRTWP，黄线是MinRTWP，蓝线是CellDCHUEs小区用户数，从图中可以看出：
用户数多时，RTWP抬升高，15个dB左右，用户少时，RTWP降至正常。
从这个小区来看，用户数也比较多，50个左右，很有可能确实存在空口容量受限的情况。
但是由于互调现象和邻区干扰以及业务类bug（或性能算法缺陷）往往也遵循相同的原则，因此在此不能下定结论，就是容量受限导致。
如果这样的小区是迫切需要解决的TOP站点，则需要依次排查：
是否有无源互调->是否存在邻区漏配->是否容量受限，并且根据更细粒度的分析，判断是否可能存在算法或实现缺陷。
如果只是需要给出解释，则进一步做容量评估，基本确认是否是容量受限即可。
Figure27RNC话统指标图（T国问题）
注：
如图Figure27（三小区4天的话统数据），虽然RTWP抬升和用户数关系明显，用户数越多，RTWP抬升越剧烈，按照详细的容量评估方法（见4.5章）进行推算，该小区确实可能存在空口容量受限的情况，但是不能排除系统内部算法仍然有不合理的地方，存在优化空间。
这张图采集自T国，经过一轮攻关，最后发现IPHONE终端删链问题、RACH信道UE开环发射功率过大问题等多个问题。
经过网络侧优化，该站点RTWP抬升得到了很大改善。
因此，实际现网中如果碰到这样的话统图形，不能轻易下结论，最好经过细致分析判断后（方法二、方法三），再通过解决方案的闭环情况来观察是否找到了引起RTWP抬升的真实原因。
4.从RNC话统指标无法直接判断是系统外部干扰还是系统内部原因
如下图（figure28）所示，该图用户数多时RTWP高，用户数少时RTWP低，虽然RTWP表现和用户数没有绝对的关系，但是不能排除内部异常业务的可能。
对于不能明确下定结论的数据，如果经过最基本的干扰检测后，仍不能给出定论的，可通过方法二、方法三进行详细分析。
Figure28RNC话统指标图（无法判断）
5.基于话统全网干扰分布图制作分析
如果RTWP抬升站点成片出现，可借助于MapInfo工具，制作全网干扰分布图，从地域的角度分析RTWP异常小区的分布特征与规律，有利于快速过滤外部干扰原因造成的RTWP异常小区。
将全网小区基于话统的RTWP异常分析结果（即标记出RTWP异常的小区），小区的经纬度、方向角等工参数据，在MapInfo上绘制出全网干扰（RTWP异常）分布图层，如下图：
Figure29窄带干扰信号示例图
一般来说，地理上连片分布的RTWP异常小区其原因极大可能是由系统外干扰所造成；
上图红色标识的站点/小区为RTWP异常的小区，从上图可以看出，大部分RTWP高的小区在地理分布上呈长条形分布，
升级会员 