【资料名称】：利用RPP_TRACE功能定位GPRS故障

【资料作者】：seaore

【资料日期】：2012-1-23

【资料语言】：中文

【资料格式】：DOC

【资料目录和简介】：

利用RPP_TRACE功能定位GPRS故障
一、故障发生及影响
近日在话务统计分析中发现NTB6437的PCU丢帧情况比较严重，下行丢帧数在忙时达到4万次以上，如下表所示：

PCU下行丢帧数：DISCDL(OBJTYPE=BSCGPRS)，是下行方向在PCU上统计的丢帧数量。该指标反映了下行方向的数据传输质量，与小区的传输质量、骨干网、接点的传输质量等都有关系，是从整个PCU上去衡量下行方向的数据传输质量。
PCU上行丢帧数：DISCUL(OBJTYPE=BSCGPRS)，是上行方向在PCU上统计的丢帧数量。该指标反映了上行方向的数据传输质量。
结合近期NTB6437区域曾多次出现用户投诉GPRS无法正常使用，初步判断存在GPRS网络故障。
二、故障定位及原因分析
1、TERDI介绍
TERDI是爱立信RPP内部COUNTER TRACE的工具，能够打印出一些小区级的GPRS统计COUNTER，为GPRS网络故障定位提供强有力的工具支持。每块RP都有独立的类似UNIX操作系统，提供一些关于小区的内部统计。小区下行丢包数在正常情况下应该小于100，对于那些成千上万的问题小区，应进一步核查传输或RP；如果发现基本集中于某个基站，则几乎可以肯定此基站传输的某些环节存在问题，应进一步核查。
TERDI:RP=“RP号”；RP入口指令，逐块RP进入，查看内部统计。
每块RP都有独立的类UNIX操作系统。如：进入到RP=304的UNIX系统。
<TERDI:RP=304；
OSmon>ISPLAY PROCESS MP_MAC*；

OSmon>:APT GETCELLSTAT MP_MAC_000；

2、故障定位
运用TERDI对NTB6437下的所有小区进行追踪打印，发现八号滩基站60091A、60091B与60091C小区，都有较为严重的丢帧现象。
八号滩A小区(60091A)从6月6日开始，累计下行掉帧达393484次，如下图：

八号滩B小区(60091B) 从6月6日开始，累计下行丢帧达369384次，如下图：

八号滩C小区(60091C) 从6月6日开始，累计下行丢帧达210405次，如下图：

初步判断该基站存在问题，于是我们查看了该基站传输LAPD的统计，该基站的两条传输225、227的LAPD统计相对异常，LAPD重发数次数比较多，如下表：

注：传输LAPD统计相关计数器:
CTRIFRAME（发送帧数）、CRECIFRAME（接收帧数）、CBADFRAME（接收错误帧数）、CRETRANSM（重发数）。
NTB6437中丢帧严重的三个小区的传输如下：

从统计表可以判断八号滩ABC三个小区丢帧现象由225、227传输问题导致。
三、故障解决方案
基站维护人员对两条传输进行检查后发现这两条传输接头存在松动现象，在调整使接触良好后，取传输LAPD统计，如下表：

基站传输LAPD统计恢复正常，而PCU的丢帧统计也恢复正常。
小结：TERDI是爱立信RPP内部COUNTER TRACE的工具，能够打印出一些小区级的GPRS统计COUNTER，为GPRS网络故障定位提供强有力的工具支持。在日常故障的定位过程中我们可以使用RPP_TRACE功能定位GPRS故障点。