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

RRC连接拥塞与无响应处理思路 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连接成功率直接影响到了无线接通率，本文仅是排查其成功率低的一个思路，希望各位专家进一步指正。