RRC常见问题处理思路(4)

4、 确认基带板上只有目标小区，没有其它小区（注：上图中，还有另一个小区20289驻留）

之后，输入FpmShowFachInfo（注意大小写）查询该基带板的收发包情况：

5、 如果该图显示红色区域值数值相差很少，说明FACH几乎没有出窗；否则，说明FACH出

窗严重（即dwFachDLFrameTooEarlyNum, dwFachDLFrameTooLateNum两个值比较大）。由于rrcConnectionSetup消息是走FACH信道的，这可能导致rrcConnectionSetup消息发不到UE，从而导致RRC建立成功率降低。

6、 如果该基带板上同时存在其它小区，可以先闭塞其它小区相应载波，使得该基带板上只

有目标小区，然后输入FpmClear（注意大小写）将基带板原来保存的数据清空，过一定时间之后重新统计基带板FACH收发包情况。 注：上述方法只能排查FACH是否存在出窗。若要检查FACH从RNC到NodeB有没有丢失，需要与RNC侧该小区FACH收发情况进行比对。 【处理建议】 FACH包出窗有几种原因

? RNC侧老的用户面处理板RUB板晶振有问题，按附件排查。

VTCD的DSP时钟手动检测方法.doc

典型案例：秦皇岛升级V2.00.200版本之后，有一块RUB单板晶振异常，导致该RUB板上一块DSP芯片上所有小区RRC建立成功率降低。

? RNC的控制面发给NodeB的TOWS和TOWE跟发给用户面的不一致，导致NodeB

这边FACH出窗。按附件排查。

备注: 现场修改后证明对出窗没有改善，建议出现出窗问题时在目前非卫星传输配置下不必修改。

? 传输丢包问题

按照传输问题解决。

4.5 NOREPLY原因：RNC GUIM单板异常

【故障现象】

RRC呼通率低，从信令跟踪上看，RNC已经下发了rrcConnectionSetup请求，但没有收到基站上报的RadioLinkRestoreIndication消息。RRC建立KPI统计失败原因为NOREPLY.

RNC版本：V2.00.200e2，基站版本：V2.00.200fP003。

【排查方法】

1、 OMCR RRC KPI统计TOP10显示，多个小区出现NOREPLY原因的RRC连接失败，没有找

到明显较多的TOP小区。

RRC连接失败RRC连接失服务小开始时间 2009-05-01 2009-05-02 2009-05-02 2009-05-03 2009-05-03 2009-05-04 2009-05-04 2009-05-04 2009-05-05 2009-05-05 2009-05-05 2009-05-05 区 ID 12712 10652 14303 11322 10652 10652 14303 14303 11482 15611 13593 12253 败计数器，RRC连接失败计数器，计数器，NO 100 242 101 144 118 204 139 108 214 173 109 102 congestion unspecified REPLY 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

2、 从NodeB侧观察，UpIscp、ISCP、RTWP功率水平都处于正常范围。

3、 在RNC侧用户面板上观察FACH传输信道同步帧收发情况，收到的传输信道同步响应帧

数目明显小于发出的请求数目。

4、 从NodeB基带板FACH统计看，不存在FACH出窗现象。

【处理建议】 可能原因

? RNC GUIM单板异常

处理方法：对问题小区RUB板经过的GUIM单板发起正常倒换操作。

【典型案例】

4.6 NOREPLY原因：传输问题导致的RRC接入成功率低

【故障现象】 北京3-5944站点RRC呼通率低，从统计上看存在FACH较多的FACH出窗。 (1) 分析告警，发现该站点在版本升级后，一直有传输告警未恢复。

单板类

站点名称(局向) 05944_六里桥

型 IIA

发生位置 SUBNET3,TP72 5944,MODULE1,1/2/15

E1 链路电信号丢失（LOS）(1029) 告警码

SUBNET3,TP72

05944_六里桥 05944_六里桥 05944_六里桥

IIA IIA IIA

5944,MODULE1,1/2/15 SUBNET3,TP72 5944,MODULE1,1/2/15 SUBNET3,TP72 5944,MODULE1,1/2/15

E1 链路电信号丢失（LOS）(1029) E1 链路电信号丢失（LOS）(1029) E1 链路电信号丢失（LOS）(1029)

(2) 分析该站点配置，可以知道: 由于该站只有一条E1是好的，怀疑是IMA带宽

不够，业务数据传输占用带宽较大情况下，FACH信道带宽不足导致传输延迟，从而出窗。现场在排除传输告警后，性能恢复为正常了。 【排查方法】 略。 【处理建议】

略。 【典型案例】 吴海洋处理北京5944站点。

4.7 CONGESTION REJ原因：长沙RNC6接入成功率降低至90%

【故障现象】

从7月1日起RRC连接建立成功率下降6%左右。7月1日到22日RRC连接建立成功率在90%左右。经确认，6月30日RNC6下未做任何相关的操作修改。

根据RRC连接失败原因值进行分析，发现RRC连接失败原因值为congestion占的比例最大.

连续三日对呼通率低TD站点进行扫频，都未发现有外部干扰，同时最严重的5个小区LMT跟踪在不存在干扰、RRU温度不高、无告警情况下，进行。 拨测发现RRC连接Reject还存在一定的概率。 【排查方法】

1， 抓取信令跟踪和管理日志，发现并没有RRM的打印，缩小范围为UCPMC模块出错。 2， 打开DCMP系统的UCPMC打印，发现是UCPMC的wNumOfDchUe超过最大值2500而引起的RRC REJ.

(2)[2009.07.24 21:05:56] 模块:RNLC_UCPMC - Recieve a rrcConnectionRequest,Start to Check is the UeId already existing in the RNC ? in RnlcC2DRrcConnReqMsgHandler

(1)[2009.07.24 21:05:56] 模块:RNLC_UCPMC - No Same Ue in the RNC,continue RRC connect proceed in RnlcC2DRrcConnReqMsgHandler. (1)[2009.07.24 21:05:56] 模块:RNLC_UCPMC - --UCPMC-- gptImsiUeStatusList->wNumOfDchUe >= RNL_maxNrOfDchUe!

(2)[2009.07.24 21:05:56] 模块:RNLC_UCPMC - --UCIC-- The number of

NoPchUser reach max count in RnlcC2DRrcConnReqMsgHandler!

3,对于不能打开全部DCPM打印的采用内存检查方法来确认该值是否异常。

【处理建议】

目前初步怀疑是该单板RCB板的个体问题。

【典型案例】

长沙: 经过昨晚前后方排查，已经定位，是1/2/6槽位RCB的2号CPU系统

gptImsiUeStatusList全局变量超出2500最大值引起，当UE选择到该RCB单板时，会导致RRC REJ，其他单板则不会。

现场已经通过复位RCB规避，经过测试未发现RRC REJ情况。

外场目前把该单板寄回所内测试内存复现。

4.8 NO REPLY原因:沈阳 10241小区 RRC REQ同时重复上报

【故障现象】

(1) 接入成功率小时平均在80%左右 RRC连接建立本地小区识别码 小区类别 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区 10241 室外小区

成功率(业务相关) 0.00% 0.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 93.75% 100.00% 100.00% RRC连接建立成功率 53.85% 26.92% 93.33% 68.75% 100.00% 94.44% 100.00% 100.00% 89.66% 90.91% 95.74% 92.86%

(2)无告警，通知, FACH出窗也不明显

【排查方法】

(1) 获取该小区的信令，发现RRC REQ相隔10ms或者同时上来。

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库RRC常见问题处理思路(4)在线全文阅读。