RRC连接拥塞与无响应处理思路.doc

内部公开▲

RRC连接拥塞与无响应处理思路

目录
RRC连接拥塞与无响应处理思路 1
1. 背景 1
2. RRC 连接过程的信令流程 1
3. RRC 失败分析 3
3.1 RRC Connection Request N300+T300超时（数）--路测 4
3.1.1 信令流程阶段 4
3.1.2 常见原因 5
3.1.3 解决办法 5
3.2 RRC Connection Reject （Congestion） 5
3.2.1 信令流程阶段 5
3.2.2 常见原因 6
3.2.3 解决方法 7
3.3 RRC Connection Reject （Unspecified） 8
3.2.1 信令流程阶段 8
3.2.2 常见原因 9
3.2.3 解决方法 9
3.4 No Reply原因造成RRC失败 9
3.2.1 信令流程阶段 9
3.2.2 常见原因 10
3.2.3 解决方法 11
4. 总结（专家点评） 11

11
1. 背景
随着TD-SCDMA网络二期工程接近尾声，全国的网络建设即将紧随其后开展起来。在网络建设的初期阶段，由于基站建设、基站故障等问题，给网络优化带来了种种困难。本文就在长沙处理RRC相关的部分问题，结合现场实际情况，为现场的网优人员提供了处理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 信令流程阶段
发生失败的信令阶段如下图所示（图中标注的）：

3.1.2 常见原因
1） 随机接入过程出现问题，可能存在UpPCH的干扰，
（1） 首先检查NODEB的RACH统计有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCH干扰。或者是统计LMT对UpISCP的测量（其测量与在KPI内统计的POS干扰统计一致，但精度更高，测量为500ms一次统计，取整个测量时段内的平均值，而KPI统计的测量为15分钟粒度取平均值）
（2） 通过CT工具检查UPPCH上的干扰
（3） 通过性能统计，查看UPPOS上的UP干扰统计
2） 终端问题，重启UE看能否接入
3） Node B 问题：重启基站
3.1.3 解决办法
对各地外场的数据分析后，Up干扰有两大类型：
1) 出现干扰平台（从当地整个网络来说，出现平台的概率并不高），但除去干扰平台后的干扰曲线基本正常，对于这类干扰通过基带匹配是能判断出干扰信号源构成的，这样基带可以：
（1）匹配出干扰源小区，网优调整（方位角、俯仰角或扰码、频点）
（2）基带做干扰消除，以消除干扰。
2) 干扰曲线整体抬高（从当地整个网络来说，出现干扰曲线整体抬高的概率较高）。对于这种情况可以采集数据看看基带匹配处理后的结果，需要以Upshifting的方式来克服此问题。
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 信令流程阶段
信令发生的阶段如下图所示（图中标注的）

具体的信令节点如下：

根据信令流程也就是说当RL Setup Response已经完成后，才会出现这种情况。
3.2.2 常见原因
1）资源不足：
主要是信道资源、码资源、功率资源等不足造成
2）小区硬件故障：
目前常见的RRU故障造成。
3）CAC参数设置问题
3.2.3 解决方法
针对两种不同的原因采用不同的措施来解决，下面分别进行描述
1） 资源不足造成的失败
查看小区的话务量（PS业务流量），看一下小区是不是真的存在资源不足（码道资源）；通过LMT查看一下功率资源情况，是否存在TCP资源不足的问题。
如果存在小区的话务量不多，而且TCP占用正常仍会出现拥塞造成的起呼失败，同时又不存在任何告警信息，则在动态数据库管理中查看服务小区状态，是不是存在载频资源被闭塞的现象（在此处闭塞是不存在任何告警信息的）。
如果是真正存在资源不足的情况，可以建议进行扩容。
2） 小区硬件故障
一般存在两种故障，一种是可以通过告警管理进行显示的故障，一种是小区本身没有任何告警信息，属于隐性故障。
对于有告警存在的，解决之；如果不存在故障，不得己而为之的方法是对小区或RRU进行重启，以验证。
3） CAC参数检查：
如下图检查CAC相关参数。

3.3 RRC Connection Reject （Unspecified）
一旦RNC通过了CAC的验证，RNC会请滶Node B配置相应的无线链路资源，一般情况下最少建立一条无线链路，在这个过程中，由于各种不同的原因造成的失败，RNC将给UE发送Cause为“Unspecified”的Reject。
3.2.1 信令流程阶段
信令发生的阶段如下图所示（图中标注的）

根据信令流程也就是说出现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 信令流程阶段
信令发生的阶段如下图所示（图中标注的④）

根据信令流程也就是说出现在RNC发出了RRC Connection Setup信令后，并且在规定的时间内没有收到UE的回应消息，才会出现这情况。
从整个信令的流程来看，RRC Connection Setup信令首先从RNC的控制面发出，经过内部处理，通过RNC与Node B之间的接口板，再经过传输线路到Node B与RNC的接口板，然后在Node B内部处理，再通过RRU经Uu口到UE。在这个环节中每一个环节出现问题都会出现没有响应的现象。
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传来的信令。
6）终端问题
3.2.3 解决方法
一般采用逐步判断的方法来定位问题
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. 总结（专家点评）
RRC连接成功率直接影响到了无线接通率，本文仅是排查其成功率低的一个思路，希望各位专家进一步指正。