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）的