RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版 。

28、本： V2.00.200fP003。
【排查方法】1、OMCR RRC KP统方f TOP10显示 ， 多个小区出现 NOREPLY（因的RRC连接失败 ， 没有找 到明显较多的TOP小区 。
2009-05-0112712001002009-05-0210652002422009-05-0214303001012009-05-0311322001442009-05-0310652001182009-05-0410652002042009-05-0414303001392009-05-0414303001082009-05-0511482002142009-05-0515611001732009-05-0 。

29、513593001092009-05-0512253001022、从NodeB侧观察 ， UpIscp、ISCP RTWP功率水平都处于正常范围 。
3、在RNC侧用户面板上观察 FACH传输信道同步帧收发情况 ， 收到的传输信道同步响应帧 数目明显小于发出的请求数目 。
4、从NodeB基带板FACH统计看 ， 不存在 FACH出窗现象 。
【处理建议】可能原因RNC GUIM单板异常处理方法：对问题小区 RUB板经过的GUIM单板发起正常倒换操作 。
【典型案例】S长沙R即连接成功率低问题处理息结日4.6 NOREPLY原因：传输问题导致的RRC接入成功率低【故障现象】北京3-5944站点RRC呼通率低 ， 从统计上看存 。

30、在 FACH较多的FACH出窗 。
（1）分析告警 ， 发现该站点在版本升级后 ， 一直有传输告警未恢复 。
单板类站点名称（局向）型发生位置告警码SUBNET3,TP7205944_,六里桥IIA5944,MODULE1,1/2/15SUBNET3,TP72E1链路电信号丢失(LOS ) (1029)05944_,六里桥IIA5944,MODULE1,1/2/15SUBNET3,TP72E1链路电信号丢失(LOS ) (1029)05944_,六里桥IIA5944,MODULE1,1/2/15SUBNET3,TP72E1链路电信号丢失(LOS ) (1029)05944_,六里桥IIA5944,MODULE 。

31、1,1/2/15E1链路电信号丢失(LOS ) (1029)a当前所有告警SUBNET 3,TP72 =51)(2)分析该站点配置 ， 可以知道：由于该站只有一条 E1是好的 ， 怀疑是IMA带宽 不够 ， 业务数据传输占用带宽较大情况下 ， FACH信道带宽不足导致传输延迟 ， 从而出窗 。
现场在排除传输告警后 ， 性能恢复为正常了 。
【排查方法】略 。
【处理建议】略 。
【典型案例】吴海洋处理北京5944站点 。
4.7 CONGESTION REJ原因：长沙 RNC6接入成功率降低至 90%【故障现象】从7月1日起RRC1接建立成功率下降 6%右 。
7月1日到22日RRCi接建立成功率在90虬 右 。
经确认 ， 6月30日RNC6F 。

32、未做任何相关的操作修改 。
根据RRC!接失败原因值进行分析 ， 发现RRC1接失败原因值为congestion占的比例最大.连续三日对呼通率低 TM占点进行扫频 ， 都未发现有外部干扰 ， 同时最严重的5个小区LMT跟踪在不存在干扰、RRU1度不高、无告警情况下 ， 进行 。
拨测发现RRCI接Reject还存在一定的概率 。
【排查方法】1,抓取信令跟踪和管理日志 ， 发现并没有RRMJ打印 ， 缩小范围为 UCPMC块出错 。
2, 打开DCM康统的UCPMC印 ， 发现是UCPMC wNumOfDchUe过最大值2500而引起的 RRC REJ.(2)2009.07.24 21:05:56模块：RNLC_UCPMC - Reci 。

33、eve arrcConnectionRequest,Start to Check is the UeId already existing in the RNC?in RnlcC2DRrcConnReqMsgHandler(1)2009.07.24 21:05:56模块：RNLC_UCPMC - No SameUe in the RNC,continueRRC connect proceed in RnlcC2DRrcConnReqMsgHandler.(1)2009.07.24 21:05:56模块：RNLC_UCPMC - -UCPMC-gptImsiUeStatusList-wNumOf 。

34、DchUe = RNL_maxNrOfDchUe!(2)2009.07.24 21:05:56 模块：RNLC_UCPMC - -UCIC- The number of NoPchUser reach max count in RnlcC2DRrcConnReqMsgHandler!3, 对于不能才T开全部DCPMT印的采用内存检查方法来确认该值是否异常 。
.查看内存力怯 ， mr【处理建议】目前初步怀疑是该单板RC版的个体问题 。
【典型案例】RRC长沙：经过昨晚前后方排查 ， 已经定位 ， 是 1/2/6槽位RCB2号CP田统 gptImsiUeStatusList 全局变量超出2500最大值引起 ， 当UE5 。

35、择到该RCBI板时 ， 会导致 REJ,其他单板则不会 。
现场已经通过复位 RC规避 ， 经过测试未发现 RRC REJt况 。
外场目前把该单板寄回所内测试内存复现 。
4, 8 NO REPLY原因:沈阳10241小区RRC REQ同时重复上报【故障现象】(1)接入成功率小时平均在80%右10241室外小区0.00%53.85%10241室外小区0.00%26.92%10241室外小区100.00%93.33%10241室外小区100.00%68.75%10241室外小区100.00%100.00%10241室外小区100.00%94.44%10241室外小区100.00%100.00%10241室外小区1 。

36、00.00%100.00%10241室外小区100.00%89.66%10241室外小区93.75%90.91%10241室外小区100.00%95.74%10241室外小区100.00%92.86%(2)无告警 ， 通知 ， FACHB窗也不明显【排查方法】 获取该小区的彳t令 ， 发现 RRC REQ1隔10ms或者同时上来 。
moni t oredtellsFre ent = 0(2Oi(K-O7-20 21 22 53 059In WrrctoTUWicit 口曲电u*tli! Rr cR* qV-d. sTfl5I-78aig?9B10241UufeoOy-07-ZS 21.2 53.069ia。

稿源：(未知)

【傻大方】网址：/a/2021/0905/0024107288.html

标题：RRC|RRC常见问题处理思路( 四 )