RRC常见问题处理思路

RRC连接拥塞与无响应处理思路
1.背景
随着TD-SCDMA网络二期工程接近尾场声，全国的网络建设却紧随其后开展起来，在网络建设的初期阶段，由于基站建设问题、基站故障问题等造成优化的困难，本文就在长沙处理RRC相关的部分问题，结合现场实际情况，为现场的网优人员提供此类问题的一种解决思路。

2.RRC 连接过程的信令流程
UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。

每个UE最多只有一个RRC连接。

当RNC接收到UE的RRC CONNECTION REQUEST消息，由其无线资源管理模块RRM根据特定的算法(CAC算法)确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道还是公共信道。

对于RRC连接建立使用不同的信道，则RRC连接建立流程也不一样。

这样一来，对于RRC连接的信令过程可以大致分为以下几个过程：1）呼叫接入控制过程（主要由UE发起请求，RNC来控制）
2）无线链路的建立过程
3）RRC建立完成过程
RRC连接过程的基本信令流程如下图：
相对应在，在信令跟踪工具内看到的过程如下图（此为手动信令跟踪得来，没有打开内部消息跟踪）：
如果对应的TKIT内自动生成的CT数据，则过程如下：
图中：FP为帧协议（Node B与RNC同步使用，此时的同步只是针对于用户的新的无线链路的同步，并不是整个Node B与RNC的同步）
3.RRC 失败分析
RRC连接失败发生RRC连接建立的过程中，RRC连接一般发生在如下情况下：
（1）UE开机
（2）UE关机
（3）位置区更新
（4）UE进行主叫业务
（5）UE进行被叫业务
参考协议25331，RRC连接失败的原因被分成了两类：
（1）Unspecified（未定义）
（2）Congestion（拥塞）
但在我司的RRC连接失败的原因则根据信令过程，同时参考协议被分成了三类：
（1）Unspecified（未定义）
（2）Congestion（拥塞）
（3）NoReply（未响应）
在日常优化的过程中，RRC连接失败则增加了一种情况，变成了一种现象和三种原因，这新增的一种现象就是在路测中UE已经发起了RRC Connection Request 但经过T300超时并且N300超数，从而造成起呼失败。

但这种情况也有可能系统侧已经进行了处理，RNC已经下发了RRC Connection Setup但终端没有收到。

（注：前两种失败的原因在信令表示中均表现为RRC Connection Reject，只是其Cause值不同，需要展开信令来看失败的原因）
下面针对各个阶段的失败，结合相关的信令与硬件组成，逐个分析各种失败的原因。

3.1 RRC Connection Request N300+T300超时（数）--路测
UE一直上报RRC CONNECTION REQ, 但后台信令跟踪上看不到任何信令过程（使用RTV 工具的小区信令跟踪，不要使用IMSI进行信令跟踪，如果使用IMSI进行信令的跟踪，则有可能造成由于Common ID没有下来而不显示相关的信令，本原因针对系统侧根据没有收到任何信令的情况）。

3.1.1 信令流程阶段
发生失败的信令阶段如下图所示（图中标注的○1）：
3.1.2 常见原因
可能是由于UpPch所在位置存在干扰，。

如果是特定终端出现该现象，而其他终端没有问题，则
1）随机接入过程出现问题，可能存在UpPCH的干扰，导致网络侧解错终端上行包，使得RNC看不到任何消息
（1）首先检查NODEB的RACH统计有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCH干扰。

或者是
统计LMT对UpISCP的测量（其测量与在KPI内统计的POS干扰统计一致，但
精度更高，测量为500ms一次统计，取整个测量时段内的平均值，而KPI
统计的测量为15分钟粒度取平均值）
（2）通过CT工具检查UPPCH上的干扰
（3）通过性能统计，查看UPPOS上的UP干扰统计
（4）可以利用扫频仪在特定终端天线口处检测终端上行信号强度是否正常；
如果是普遍现象，则需要检查UpPch所在位置的干扰，如存在干扰则需
要考虑对UpPch位置进行漂移。

2）终端问题，重启UE看能否接入
3）Node B 问题：重启基站
3.1.3 解决办法
对各地外场的数据分析后，Up干扰有两大类型：
1) 出现干扰平台（从当地整个网络来说，出现平台的概率并不高），但除去干扰平台
后的干扰曲线基本正常，对于这类干扰通过基带匹配是能判断出干扰信号源构成的，这样基带可以：
（1）匹配出干扰源小区，网优调整（方位角、俯仰角或扰码、频点）
（2）基带做干扰消除，以消除干扰。

2)干扰曲线整体抬高（从当地整个网络来说，出现干扰曲线整体抬高的概率较高）。

对于这种情况可以采集数据看看基带匹配处理后的结果，需要以Upsfifting的方式来克服此问题。

3.2 RRC Connection Reject （Congestion）
UE上报RRC CONNECTION REQ，但很快RNC就回了信令RRE Connection Reject，并且其所带的Cause值为“Congestion”，产生这种原因主要是因为RRM算法的进行判决的结果，呼叫接纳控制（CAC）是无线资源管理（RRM）中的一个重要组成部分。

CACM模块根据小区当前的无线资源和负荷情况以及呼叫的服务质量（QoS），按照一定的算法，对新的呼叫请求可能产生的负荷增加量进行预测，然后依据一定的接入准则，决定对新的呼叫是允许接入还是拒绝接入。

CAC的目的是在防止系统出现负荷过载和保证呼叫的服务质量（QoS）的
前提下，尽可能保证并提高系统的容量。

3.2.1 信令流程阶段
信令发生的阶段如下图所示（图中标注的○2）
具体的信令节点如下：
根据信令流程也就是说当RL Setup Response已经完成后，才会出现这种情况。

重要信令解释
3.2.2 常见原因
⏹小区码道资源不足，没有足够的码道为UE分配（特殊地：UE只支持单载频，而
主载频上已没有剩余的码道资源）；
⏹干扰或功率受限，软资源接纳失败；
⏹传输资源申请或带宽接纳失败；
3.2.3 解决方法
针对两种不同的原因采用不同的措施来解决，下面分别进行描述
1）资源不足造成的失败
查看小区的话务量（PS业务流量），看一下小区是不是真的存在资源不足（码道资
源）；通过LMT查看一下功率资源情况，是否存在TCP资源不足的问题。

如果存在小区的话务量不多，而且TCP占用正常仍会出现拥塞造成的起呼失败，
同时又不存在任何告警信息，则在动态数据库管理中查看服务小区状态，是不是
存在载频资源被闭塞的现象（在此处闭塞是不存在任何告警信息的）。

查看公共测
量值和配置的接纳门限，是否为功率干扰等软资源受限；查看小区剩余的码道资
源数看是否有足够的剩余资源如果是真正存在资源不足的情况，可以建议进行扩
容。

2）小区硬件故障
一般存在两种故障，一种是可以通过告警管理进行显示的故障，一种是小区本身
没有任何告警信息，属于隐性故障。

对于有告警存在的，解决之；如果不存在故障，不得己而为之的方法是对小区或
RRU进行重启，以验证。

3）CAC参数检查：
如下图检查CAC相关参数。

4）传输资源受限
查看Iub口带宽大小是否受限；
3.3 RRC Connection Reject （Unspecified）
一旦RNC通过了CAC的验证，RNC会请滶Node B配置相应的无线链路资源，一般情况下最少建立一条无线链路，在这个过程中，由于各种不同的原因造成的失败，RNC将给UE发送Cause为“Unspecified”的Reject。

3.2.1 信令流程阶段
信令发生的阶段如下图所示（图中标注的○3）
根据信令流程也就是说出现RL Setup Failure的现象，才会出现这种情况。

3.2.2 常见原因
基站小区的故障造成。

3.2.3 解决方法
解决基站小区的故障。

3.4 No Reply原因造成RRC失败
在CAC和RL Setup都已经完成后，RNC将发送RRC Connection Setup 信令给UE，如果
在规定的时间内，没有收到UE的RRC Connection Complete信令，那么系统侧将会判断本次RRC过程失败，并且其原因值为“No Reply”
3.2.1 信令流程阶段
信令发生的阶段如下图所示（图中标注的○3）
信令消息过程解释
rrcConnectionRequest UE发送RRC连接请求，请求接入网络；RadioLinkSetupReqeust
IUB口消息，建立无线链路RadioLinkSetupResponse
rrcConnectionSetup 空口消息，RNC向UE发送RRC建立，建立信令无线承载资源
RadioLinkDeleteReqeust IUB口消息，删除无线链路
根据信令流程也就是说出现在RNC发出了RRC Connection Setup信令后，并且在规定的时间内没有收到UE的回应消息，才会出现这情况。

从整个信令的流程来看，RRC Connection Setup信令首先从RNC的控制面发出，经过内部处理，通过RNC与Node B之间的接口板，再经过传输线路到Node B与RNC的接口板，然后在Node B内部处理，再通过RRU经Uu口到UE。

在这个环节中每一个环节出现问题都会出现没有响应的现象。

从路测终端侧看，终端未收到RRC连接建立消息，由于终端在上报RRC链接请求后，收不到网络侧RRC链接建立，会重发RRC链接请求，据此可以判断网络侧下发的RRC链接建立消息终端未收到，需要在下行方向，排查问题，如Iub口传输丢包、FACH信道配置不正确。

3.2.2 常见原因
1）RNC硬件存在故障
RNC内部处理板或对外的接口板正在问题，不能正确地将RRC Connection Setup信令发送给Node B
2）传输存在问题
从RNC到Node B之间的传输存在问题，传输误码较大，丢包较多，造成不能正确地将RRC Connection Setup信令发送给Node B
3）Node B存在问题
Node B的某个板子存在问题，有可能不能正确地接收RNC传送来的信令，也能可能不能将信令在FACH完整地传送给RRU
4）RRU存在问题
RRU不能正确地接收UE上发的RRC Connection Setup Complete信令，或是不能正确地将RRC Connection Setup信令作传送给UE
5）参数设置存在问题
➢SCCPCH的功率参数设置存在问题，导致UE无法正确接收RRU传来的信令
➢由于下行功率不足或存在下行干扰等原因，UE未收到RNC发送的RRC CONNECTION SETUP消息；
➢UE收到了RRC CONNECTION SETUP消息，也上发了RRC CONNECTION SETUP COMPLETE消息，但由于上行功率不足或存在上行干扰等原因，RNC
未收到该消息；
6）终端问题
UE收到了RRC CONNECTION SETUP消息，但由于消息错误或UE内部错误等原因，UE未发送RRC CONNECTION SETUP COMPLETE消息；
排查方法：
3.2.3 解决方法
查看RRC链接建立的上行时隙干扰情况，如果发现时隙干扰很大，查看NODEB载
扇是否正常，同时查看邻小区是否有大量同频邻区，若在话务量小的情况下，ISCP仍然很高，则干扰可能来自异系统，如：GSM，PHS等；
若网络侧没有收到RRC建立完成消息：则调整后台DPCH的期望接收功率，同时利用网规网优手段，降低上行方向上的干扰；
无效配置、配置不支持等配置错误：换个手机测试，若各厂家手机测试都有问题，将本小区RRC建立消息和正常小区的RRC建立消息进行对比，查看配置是否正确；
若UE未收到RRC建立消息：调整后台下行最小发送功率，增加UE接收到RRC建立消息的几率，或者调整周围网络的覆盖、频点、功率等，尽量降低下行方向上的干扰，或调整小区PCCPCH功率及公共信道、共享信道相关功率，确认Iub口传输无问题；
一般采用逐步判断的方法来定位问题，步骤如下：
1）确定RNC已经收到了RRC Connection Request请求，并且已经发出了RRC Connection Setup 信令
2）确定RNC内部的各个处理板之间数据传输没有出现问题，可以使用系统工具RDS进行各个处理板之间数据包的传输统计，评估其丢包率。

3）查看传输告警，以及传输的内部告警，确保传输没有问题
4）查看Node B的收包情况与RNC的送包数量一致，同时确定Node B在FACH上正确完整地将数据传出。

（使用工具LOGVIW和LMT）
5）如果上以都不存在问题，重启RRU或更换RRU进行指标观察
6）确定终端是否收到Node B传来的信令
7）增加SCCPCH的功率，观察指标
4.案例集锦
本文汇总了TD外场出现过的RRC建立成功率低的部分案例，并按照原因进行分类整理，以期对外场问题排查提供借鉴。

本文所选案例中，部分参考了各地用服网优整理的RRC建立成功率低问题处理总结。

4.1 CONGESTION原因：码资源不足
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC收到rrcConnectionRequest请求之后，直接下发了rrcConnectionReject消息。

RRC建立KPI统计失败原因为CONGESTION.
RNC版本：V2.00.200e2，基站版本：V2.00.200fP003。

【排查方法】
（1）在OMCR性能管理中，筛选CONGESTION高的小区；
（2）提取KPI综合分析（CS/PS流量），初步分析是否和码资源相关；如下表CONGESTION
（3）通过LMT小区载波测量查看小区码资源配置及使用情况，并检查一下有没有载波（或时隙）被闭塞现象（也可在OMCR NodeB动态数据管理中查看）。

【处理建议】
●如有载波（或时隙）被闭塞，则解开。

●小区扩容
【典型案例】
东水西调3扇区.doc
4.2 NOREPLY原因：BBU TBPH FPGA异常
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC发出rrcConnectionSetup请求之后，但没有收到基站上报的RadioLinkRestoreIndication消息。

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

【排查方法】
1、在LMT上开启本地小区载波测量，看在小区空载情况下，同时存在以下情况
a)UPISCP值全为127
注：UpIscp值在50以下属于正常，前四个值不使用。

b)上行时隙ISCP（底噪）值很大
注：空载时，Iscp值在-110左右属于正常
c)上行时隙RTWP后四天线值很大
注：空载时，BBU RTWP值在-110左右属于正常）
2、在OMCB上查询基站通知消息，可以看到TBPH单板有大量“上行IQ Link链路误码
(198081164)”通知上报。

3、采集RRU命令日志，看到testRTWP命令输出值正常
注：正常情况无UE接入时，RRU Shell显示的RTWP是底躁，应该在-69左右（此时DSP 监控工具显示的底躁应该在-110dB左右），若低于-80dBm，则基本可认为RRU无上行信号；若大于-60dBm，则底躁过高，存在干扰。

【处理建议】
规避方法：复位小区所在TBPH单板。

具体原因仍在定位。

类似问题如果需要采集数据，请按以下文档采集:
RRC建立成功率低数
据采集要求(0703更新
【典型案例】
石家庄市电炉厂.do
c
4.3 NOREPLY原因：干放干扰
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC已经下发了rrcConnectionSetup请求，且能收到基站上报的RadioLinkRestoreIndication消息,但收不到UE上报的rrcConnectionComplete消息。

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

【排查方法】
2、从LMT小区载波测量观察，UpIscp和上行时隙ISCP功率正常。

3、测试终端为凯明，测试时发现在R01覆盖区域，各业务连接正常，但在干放覆盖区域，
手机一直无法接通。

【处理建议】
形成书面报告递交移动，推动干放厂家积极解决。

【典型案例】
崇文区新世界家园
二期TDM.doc
4.4 NOREPLY原因：FACH出窗
【故障现象】
RRC呼通率低，从信令跟踪上看，RNC已经下发了rrcConnectionSetup请求，但没有收到基站上报的RadioLinkRestoreIndication消息。

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

【排查方法】
1、打开LMT本地小区载波管理，如下图；
2、选中RRC建立失败的小区载波，点击资源分配查询，查询载波所在基带板，如下图，载
波0在TBPE2上；
3、在Logview中打开相应的基带板，待界面左上角的指示由红色变成蓝色之后，输入
TbpaInfoShow（注意大小写）命令，确认目标小区是否在该基带板上处理。

如图：
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小区。

开始时间服务小
区ID
RRC连接失
败计数器，
congestion
RRC连接失
败计数器，
unspecified
RRC连
接失败
计数器，
NO
REPLY
2009-05-01 12712 0 0 100
2009-05-02 10652 0 0 242
2009-05-02 14303 0 0 101
2009-05-03 11322 0 0 144
2009-05-03 10652 0 0 118
2009-05-04 10652 0 0 204
2009-05-04 14303 0 0 139
2009-05-04 14303 0 0 108
2009-05-05 11482 0 0 214
2009-05-05 15611 0 0 173
2009-05-05 13593 0 0 109
2009-05-05 12253 0 0 102
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)
05944_六里桥IIA SUBNET3,TP72
5944,MODULE1,1/2/15 E1 链路电信号丢失（LOS）(1029)
05944_六里桥IIA SUBNET3,TP72
5944,MODULE1,1/2/15 E1 链路电信号丢失（LOS）(1029)
05944_六里桥IIA SUBNET3,TP72
5944,MODULE1,1/2/15 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同时重复上报
【故障现象】
本地
小区识别
码小区类别
RRC
连接建立
成功率
(业务相
关)
RRC
连接建立
成功率
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 室外小区100.00% 100.00% 10241 室外小区100.00% 89.66% 10241 室外小区93.75% 90.91% 10241 室外小区100.00% 95.74% 10241 室外小区100.00% 92.86%
(2)无告警，通知, FACH出窗也不明显
【排查方法】
(1)获取该小区的信令，发现RRC REQ相隔10ms或者同时上来。

(2)使用Message Trace跟踪该小区所在CCMP系统的RNLC-AGENT的板间消息
发现在149ms时同一个UE的RRC REQ从10241和10161小区上来。

Message Trace工具暂时未发布给外场，出现类似问题时向家里要。

(3)分析10241和10161小区配置的异同点
10241小区主频2022.4，扰码90；
10161小区主频2022.4，扰码90；
两者相同。

站点距离相隔1.6KM。

这两个小区建立在同一个RUB板和CCMP系统中，所以能通过小区基本的信令跟踪跟上，如果小区建立在不同的CCMP系统，则信令跟踪无法跟到重复现象。

【处理建议】
(1) 临时手段是修改RACH的时隙或者码道，避免了同时解调的可能。

(2)网优优化处理，需要修改扰码频点规划, 把其中一个站点的小区扰码改掉。

【典型案例】
沈阳RRC连接成功率低
4.9 NOREPLY原因：北京3015小区(未定位) 【故障现象】
开始时间结束时间本地小区
识别码小区类别
RRC连接建
立成功率
RRC连接建立成
功率(业务相关)
2009-07-15 00:00:00 2009-07-15 01:00:00 3014 室外小区100.00% 100.00% 2009-07-15 01:00:00 2009-07-15 02:00:00 3014 室外小区12.50% 100.00% 2009-07-15 02:00:00 2009-07-15 03:00:00 3014 室外小区100.00% 100.00% 2009-07-15 03:00:00 2009-07-15 04:00:00 3014 室外小区20.00% 100.00% 2009-07-15 04:00:00 2009-07-15 05:00:00 3014 室外小区28.57% 100.00% 2009-07-15 05:00:00 2009-07-15 06:00:00 3014 室外小区11.11% 100.00% 2009-07-15 06:00:00 2009-07-15 07:00:00 3014 室外小区25.00% 100.00%
1
2、对该站点告警信息进行统计，在7月份该站点无任何告警；
3、对后台LMT进行跟踪：
3015扇区：
主载波UPISCP基本正常，干扰功率在-110左右，但观察一段时间发现UPISCP和干扰功率会在某一时间会有突发性的较大波动，
UpIscp测量值干扰功率
42:119:118:113:111:109:103:101:95:96:94:89:85:84:82:78: 0.0:-103.2:-109.1:0.0:0.0:0.0:0.0: 49:119:118:112:111:108:103:101:96:96:94:87:84:84:83:76: 0.0:-102.5:-107.2:0.0:0.0:0.0:0.0: 53:119:119:114:112:109:104:101:96:95:93:88:83:83:82:76: 0.0:-103.7:-107.9:0.0:0.0:0.0:0.0: 52:119:118:112:110:107:103:100:97:96:94:88:83:85:80:78: 0.0:-102.9:-108.4:0.0:0.0:0.0:0.0: 45:119:118:112:108:108:103:100:96:95:93:88:84:82:79:78: 0.0:-104.7:-108.6:0.0:0.0:0.0:0.0: 41:119:119:113:108:108:103:101:97:96:93:86:85:83:81:75: 0.0:-102.3:-108.0:0.0:0.0:0.0:0.0: 47:118:119:112:109:109:103:100:96:94:94:88:84:85:81:77: 0.0:-105.5:-108.7:0.0:0.0:0.0:0.0: 41:118:119:113:112:108:103:101:96:96:95:86:84:83:82:78: 0.0:-103.4:-108.9:0.0:0.0:0.0:0.0:
4、对站点的TBPE板出窗情况进行查询，出窗现象不明显。

小区3014、3016也同有3的现象。

但RecvBfnErr数目较多。

* dwRecvBfnErrNum = 62193
【排查方法】[庄荣海]
从KPI统计看，该站RRC建立成功率很低，失败原因为NOREPLY
从历史告警看，RRC建立失败期间，没有历史告警。

但是，通知查询中可以看到，存在大量的“锁相环源时钟瞬时抖动过大(4101)”
怀疑是这个原因导致TBPE上出现大量的BFN Err。

--未有结论，版本升级后继续观察。

【处理建议】
【典型案例】
4.10 NOREPLY原因：手机侧由于DPCH同步失败而重发RRC ConnectionRequest时间间隔同协议不符
【故障现象】
系统设置的T300为2秒，T312为3秒。

根据331协议，如果手机收到RRC Setup
消息，但DPCH同步失败，则间隔T312时间后重发，RNC系统建立无线链路等待同步的时
间也和T312相同为3秒。

但是，通过对于大量CT的分析，以及针对几种不同芯片的终端测
试发现，手机由于DPCH同步失败重发RRC ConnectionRequest的时间是T300+T312，按照目
前的设置就是5秒。

如下图：
此时由于RNC DPCH早已经删除，每次重发都分配新的GID，按照新发统计，因此在进行KPI统计的时候，对于连续多次的重发，每次都算作一次失败，导致了个别用户在短时间内贡献大量的RRC连接失败。

【排查方法】
抓信令确认。

【处理建议】
1、RNC侧同步定时器从3秒延长为5秒。

TIMER: tRrcConnSetup 3s ->5s;
2、T312修改为2秒，这样RRC重发的时间可以缩短为4秒，不会超过5秒。

3、N300由原来的3次修改为2次。

因为RNC还有其他的定时器，限定了GID最长时间为15秒，因此，重传时间相加最长不能超过15秒，重发两次，则一共时间为12秒，可以满足要求。

【典型案例】
厦门RRC 接入成功率提升。