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

内部公开RRC连接拥塞与无响应处理思路目录RRC连接拥塞与无响应处理思路11.背景12.RRC 连接过程的信令流程13.RRC 失败分析33.1 RRC Connection Request N300+T300超时（数）-路测43.1.1 信令流程阶段43.1.2 常见原因53.1.3 解决办法53.2 RRC Connection Reject （Congestion）53.2.1 信令流程阶段53.2.2 常见原因63.2.3 解决方法73.3 RRC Connection Reject （Unspecified）83.2.1 信令流程阶段83.2.2 常见原因93.2.3 解决方法93.4 No Reply原因造成RRC失败93.2.1 信令流程阶段93.2.2 常见原因103.2.3 解决方法114.总结（专家点评）11111. 背景随着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 B2）传输存在问题从RNC到Node B之间的传输存在问题，传输误码较大，丢包较多，造成不能正确地将RRC Connection Setup信令发送给Node B3）Node B存在问题Node B的某个板子存在问题，有可能不能正确地接收RNC传送来的信令，也可能不能将信令在FACH完整地传送给RRU4）RRU存在问题RRU不能正确地接收UE上发的RRC Connection Setup Complete信令，或是不能正确地将RRC Connection Setup信令传送给UE5）参数设置存在问题 主要是SCCPCH的功率参数设置存在问题，导致UE无法正确接收RRU传来的信令。6）终端问题3.2.3 解决方法一般采用逐步判断的方法来定位问题1） 确定RNC已经收到了RRC Connection Request请求，并且已经发出了RRC Connection Setup 信令2） 确定RNC内部的各个处理板之间数据传输没有出现问题，可以使用系统工具RDS进行各个处理板之间数据包的传输统计，评估其丢包率。3） 查看