RSSI处理案例总结.docx

RSSI处理案例总结.docx

《RSSI处理案例总结.docx》由会员分享，可在线阅读，更多相关《RSSI处理案例总结.docx（12页珍藏版）》请在冰豆网上搜索。

RSSI处理案例总结

RSSI处理案例总结

郑晗（69772）

这一段时间一直处理RSSI问题，积累了一些心得体会写出来和大家共享。

【引子】

在我处的地区很多基站在开通后为了防止对现网相邻未割接其他厂家基站造成干扰都暂时将其闭塞，由此在用Nastar分析RSSI数据时，有发现如下情况：

某基站处于闭塞状态但是从Nastar和操作维护台上来看该基站RSSI正常起伏，即全天RSSI值随着闲忙时而起伏，如下图所示：

该27号站一直都是闭塞状态，下面是跟踪出来的RSSI数据：

图：

27号站各扇区RSSI全天走势图

图：

操作维护台跟踪RSSI数据

当时很奇怪闭塞了的基站不可能有用户感觉RSSI应该全天无变化才对。

于是又用M2000对RSSI进行查询结果和Nastar统计结果相同，分析原因应该是当基站闭塞后，基站基本上变成了“接收机”，其覆盖范围内的手机无法接收到该站点的信号，将会在周边的基站上接入进行业务。

由于该站点附近的手机相对于周边的基站距离较远，在接入到周边基站进行业务时就会以相对比较大的功率发射，以保持与周边基站的通讯，对于该站点的RSSI就会造成影响所致。

同时再次对Nastar指标进行核查发现在Nastar软件中实际有两个地方可以统计RSSI，如下图所示：

图：

Nastar统计RSSI方法1

图：

Nastar统计RSSI方法2

可以看出这两个方法一个来自导频功率测量选项，单位为（dBm），一个来自RSSI性能测量选项，单位为（0.1dBm），这两种统计结果不仅是单位的不同而且在统计计算方法上有本质的不同。

在前图的“27号站各扇区RSSI全天走势图”中我所取的数据来自RSSI性能测量（0.1dBm）中，对比两组数据如下图所示：

（由于数据较多仅以410频点为例）

图：

来自RSSI性能测量数据

图：

来自导频功率测量RSSI数据

对比两组数据可以发现其结果的不同，第一组值全天一直在变化而第二组来自导频功率测量选项的RSSI数据统计值全天都是一个恒定值。

事实上在导频功率测量项里面统计的RSSI值是RRM5分钟对之前的所有上报值累计求得平均值，由OM性能统计计数器设定。

每次用平均值设定OM性能统计计数器时，上一次的设定值会被覆盖，OM每30分钟将性能统计计数器上报后台，即是说当你按30分钟统计时实际上统计的是最后5分钟的平均值，当你按60分钟统计时实际上统计的两个30分钟最后两个5分钟累计值的平均值。

正常来讲两种方法得到的统计结果相差不大，该基站现象是由基站闭塞造成。

个人建议暂时不要对闭塞基站进行RSSI核查，对正常工作基站进行RSSI核查时建议使用RSSI性能测量项中的RSSI数据。

【RSSI统计方法】

总结几种RSSI统计方法：

1.通过M2000统计RSSI，新建一个统计模版，指标路径：

”CarrierPowerControlMeasurement------PerformanceStatofLinkInformationMeasurement”,详见下图：

图：

M2000统计RSSI路径

2.通过M2000统计RSSI，新建一个统计模版，指标路径：

“RSSIPerformanceMeasurement------RSSIPerformanceStat”,详见下图：

图：

M2000统计RSSI路径

3.通过Airbrige操作维护台跟踪，路径为”选择xxx基站-------ResourceMonitor------RSSIMonitor”,该统计是以每载频每分钟为单位统计RSSI值。

4.从操作维护台上打开BTS端口，（命令：

STRBTSTELPROXY输入BTSID和端口号，端口号随便指定一个即可，一般以5000起）

Telnet到BTS，（格式：

telnetBSCIP端口号）

输入用户名：

system；用户密码：

system

连接成功后，出现提示符：

HWCBTS>

打开命令自动联想功能。

输入：

OPNDAY

启动反向RSSI接口跟踪，测试命令如下：

HWCBTS>strinfotrace

<

bckm_omu/bckm_sig/bckm_clk/bcim/crdm/pmu/ccpm/trm>,mandatory>trm

<

>,mandatory>0（单载波为0，多载波为1、2、3）

<

>,optional>"rssi"

ok

此时开始启动RSSI跟踪，如下图：

停止前向功率接口跟踪，测试命令如下：

HWCBTS>stpinfotrace：

brdtp=trm,brdid=0,item=”rssi”

Ok

统计停止。

*注：

以上命令黄色为需要输入部分。

在统计结束后切勿忘记关闭该端口（命令命令：

STPBTSTELPROXY输入BTSID即可）

该统计方法是按秒对RSSI值进行统计较之上一种方法更为快捷。

另外在上图中可以看到统计值中每行有Avg和Peak两个值，我们一般只看Avg，但事实上Peak值和Avg值得差值反映了一个RSSI稳定性能的问题，如果两值相差过大说明此时的RSSI是不稳定的，最好是两值相差越小越好。

5.从Nastar统计，新建一个指标模版，指标路径：

”CarrierPowerControlMeasurement------PerformanceStatofLinkInformationMeasurement”,如前图。

6.从Nastar统计，新建一个指标模版，指标路径：

“RSSIPerformanceMeasurement------RSSIPerformanceStat”,如前图。

跟踪STRCBTSITFLOGTHD

7.在操作维护台上跟踪CBTSITFLOGTHD数据导入Nastar进行分析，启动命令

STRCBTSITFLOGTHD，数据默认保存在…\Airbridge\Services\BTSITFLOG，

以BTSXXX_ITF_LOG.LOG和BTSXXX_ITF_LOG.BAK来区别每个基站的记录。

以上几种方法个人认为用Nastar和M2000统计RSSI时可按一天天每小时统计，观察该载扇一天的走势情况比较直观也容易发现问题，在开站或整改天馈时在操作维护台统计RSSI可事实的看到RSSI整改前后的变化情况方便判断其整改后比较正常，特别是第4种方法可按秒进行统计更为方便。

需要对RSSI进行详细分析时可采用最后一种方法。

【处理的一些RSSI问题和心得体会】

通常我们对RSSI的要求是在-110dBm至-95dBm之间，主分集相差不超过6dB，个人认为在用户非常多的情况下忙时RSSI值超过-95dBm但小于-90dBm仍算正常。

下面是我遇到过的一些RSSI问题：

1）主集或分集差异过大

这里分为几种情况，一种情况如下图所示：

图：

扇区没接RSSI示意图

可以看到该扇区分集全天没有一点变化且持续偏低一直保持在-110dBm以下，分析原因为分集没接检查确实。

一种情况如下图所示：

图：

某集没接好RSSI示意图

主集和分集全天差异过大，但RSSI值正常，察看该扇区话务量，有话务量但不多，分析该原因应是主集跳线没有接好造成功率泄露到整个带宽造成整个底噪的抬升使RSSI升高检查确实，不过不是所有的此类问题都是由某一集没有接好造成，还包括IDFU故障，馈线损坏等原因，所以当重新连接好馈线后仍没有解决的情况下要能从多方面考虑解决问题。

2）主集或分集持续偏高

扇区某一分集或所有分集全天偏高，例如下面该扇区：

图：

扇区某分集RSSI全天偏高图

该扇区对比主分集，主集RSSI全天明显偏高，主要原因应是馈线没有连接好造成背景噪声大幅抬升引起。

3）扇区间主分集接错

图：

扇区主分集接错示意图

对于同一扇区的正常RSSI趋势图来讲主分集的变化趋势应该是一致的，如上图所示，该站的0扇区的主集RSSI和2扇区的分集的RSSI变化趋势相同而0扇区的分集RSSI和2扇区的主集RSSI变化趋势相同是不正常的，分析很有可能是0扇区的分集和2扇区的分集接反了。

此方法可以用来分析某扇区某一集和其他扇区是否接反，但并不可完全确认仅做参考。

4）外界干扰导致RSSI升高

该问题仍分几种情况，一种情况如下图：

图：

干扰RSSI趋势图1

该图中可以看到该扇区某一载频全天高于其它载频，这种情况建议首先还是要检查一下馈线连接及馈线有没有问题，当检查后还不行时就可以考虑是干扰造成，带扫频仪到站点附近进行清频测试，由于该现象全天都存在可能在任何时间进行该测试。

一种情况如下图：

图：

干扰RSSI趋势图2

该图中可以看到该扇区某一载频只在某一时段高于其它载频而其它时段正常，察看该时间段为早上6：

到10点从图上看并非忙时，该情况判断应为阶段性干扰造成，建议对于该情况多观察几天，看是否每天在这个时间段都有该现象出现，当确认干扰源在该时段每天都会出现后可带扫频仪在该时段到基站附近进行清频测试。

由于干扰源可能不是时刻存在且范围较大不宜察在查干扰源前一定要做好充足准备，防止人为原因错过时间浪费资源机会。

5）其它情况

一种情况如下图所示：

图：

其它情况RSSI示意图1

该扇区忙时RSSI表现正常，但是闲时某一载频RSSI偏高，同时看到该集同有该现象，所以由接口原因？

引起的可能性较小，这种情况建议多观察两天，如果持续存在有可能是馈线问题也有可能是干扰。

可到站点重点对这两项进行检查。

一种情况如下图所示：

图：

其它情况RSSI示意图2

可以看到该扇区主集全天处于不稳定得状态全天持续波动，该现象引起原因较复杂，遇到这种情况建议先看一下该站点话务量情况，RSSI变化趋势是否和话务量分布相符，然后对其持续观察，个人感觉如果其波动一直保持正常范围值内可以暂时不管它。

如果上站检查时要带上馈线，先对IDFU与TRX连线进行检查，然后对机顶出馈线接口进行检查，都没有问题的话对馈线进行更换，之后用前面提到的第四种方法在机房或现场用网线连到单板上跟踪RSSI观察，需要注意的是去现场时一定要带上驻波比测试仪，在换馈线前一定要先检查一下所换馈线的VSWR是否正常，特别是分集，因为分集的VSWR现阶段在机房操作维护台上是跟踪不到的，保证所换的馈线驻波比没有问题后再更换馈线，再次说明一下，VSWR正常的馈线不代表其没有问题，馈线接头的制作对RSSI同样有影响，所以一定要保证馈线接头完好特别是要注意没有铁屑或其它尘粒在里面，所以接头的检查和馈线同样重要！

【RSSI分析检查方法总结】

Ø我在分析RSSI时是按每天为单位每小时对载扇进行统计列表，察看每扇区的变化趋势，每天对检查结果做一列表详细记录基站信息，RSSI现象，整改状态等，发现问题基站当时就在操作维护台上进行跟踪，情况相符的话当时就通知B侧工程师去现场整改，整改后要持续对整改结果进行跟踪。

当时不能判断的基站先做一记录并对其持续跟踪，待确定问题后通知B侧工程师进行整改并对结果进行跟踪。

Ø上站检查时根据问题情况提前准备好工具，建议都要带上2到3根跳线、驻波比测试仪、扳手等。

到站点先对设备检查确认没有问题，检查IDFU到TRX连线确认没有问题，检查机顶出馈线接口同时开始跟踪RSSI（从机房或现场）确认没有问题，更换跳线先确认更换后的跳线VSWR正常（包括主分集），跳线接头没有问题，更换后确认RSSI状况。

对于存在干扰的基站可专门选取时间用扫频仪排查干扰。

RSSI问题在整个项目的初期由为明显特别是对割接基站要重点检查，RSSI的问题现象也很多样化，处理该类问题要靠不断的经验积累，虽然问题原因大多数是馈线、接头、干扰等造成但是不同的原因处理手段确不同，但是当我们告诉B侧工程师整改前要能够准备判断其问题原因让B侧准备好相应的工具因为很多情况下工具并不充足，而错误的判断可能会导致这一趟白跑了任何问题都解决不了，而在地市一个站的距离往往是非常远的，所以准确地判断能使问题迅速有效的解决节省了人力和时间使我们的工作更加的高效快捷！