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连接过程的基本信令流程如下图：

UE1Node B随机接入过程（UpPCH SYNC）RNCRRCRRC Connection Request（RACH）RRCAllocate RNTISeclect L1 and L2 ParameterNBAPRadio Link Setup RequestNBAPStart RXNBAPRadio Link Setup ResponeNBAPACAP Iu Data Transport Bearer Setup2DCH-FPDL SyncDCH-FPDCH-FPUL SyncDCH-FP3Start TXRRCRRC Connection Setup（FACH）4RRCRRCRRC Connection Setup Complete （DCCH）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已经完成后，才会出现这种情况。

重要信令解释

信令消息 rrcConnectionRequest rrcConnectionReject 3.2.2 常见原因

过程解释 UE发送RRC连接请求，请求接入网络； RNC可能因一些原因无法为UE建立RRC资源，因此发送RRC连接拒绝，拒绝UE的接入请求； ? 小区码道资源不足，没有足够的码道为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 RadioLinkSetupReqeust RadioLinkSetupResponse rrcConnectionSetup RadioLinkDeleteReqeust 过程解释 UE发送RRC连接请求，请求接入网络； IUB口消息，建立无线链路 空口消息，RNC向UE发送RRC建立，建立信令无线承载资源 IUB口消息，删除无线链路

RadioLinkDeleteResponse 根据信令流程也就是说出现在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

次数高的时段，PS流量很大，很有可能是码资源不够。 按原因分NODEB 开始时间 时间粒度 RNC ID 服务小区 ID 小区类别 RRC连接请求次数 RRC连接失败计数器，分组域业务流量congestion (KByte) 19:00:00 1小时 20:00:00 1小时 21:00:00 1小时 22:00:00 1小时 23:00:00 1小时 1 1 1 1 1 9711 9711 9711 9711 9711 9713 室外小区 9713 室外小区 9713 室外小区 9713 室外小区 9713 室外小区 214 489 566 602 301 201 473 501 557 291 124865.2 194474.9 171392 168818.3 165699.8

（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更新

【典型案例】

石家庄市电炉厂.doc

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小区。

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或者同时上来。

本文来源：https://www.bwwdw.com/article/e3p3.html