TD-RRC连接拥塞与无响应专题处理思路

1、 中国移动江苏公司网络 PAGE 11RRC连接拥塞与无响应处理思路目录 TOC o 1-3 h z u HYPERLINK l _Toc294779718 RRC连接拥塞与无响应处理思路 PAGEREF _Toc294779718 h 1 HYPERLINK l _Toc294779719 1.背景 PAGEREF _Toc294779719 h 1 HYPERLINK l _Toc294779720 2.RRC 连接过程的信令流程 PAGEREF _Toc294779720 h 1 HYPERLINK l _Toc294779721 3.RRC 失败分析 PAGEREF _Toc29477

2、9721 h 3 HYPERLINK l _Toc294779722 3.1 RRC Connection Request N300+T300超时（数）-路测 PAGEREF _Toc294779722 h 4 HYPERLINK l _Toc294779723 3.1.1 信令流程阶段 PAGEREF _Toc294779723 h 4 HYPERLINK l _Toc294779724 3.1.2 常见原因 PAGEREF _Toc294779724 h 5 HYPERLINK l _Toc294779725 3.1.3 解决办法 PAGEREF _Toc294779725 h 5 HYP

3、ERLINK l _Toc294779726 3.2 RRC Connection Reject （Congestion） PAGEREF _Toc294779726 h 5 HYPERLINK l _Toc294779727 3.2.1 信令流程阶段 PAGEREF _Toc294779727 h 5 HYPERLINK l _Toc294779728 3.2.2 常见原因 PAGEREF _Toc294779728 h 6 HYPERLINK l _Toc294779729 3.2.3 解决方法 PAGEREF _Toc294779729 h 7 HYPERLINK l _Toc29477

4、9730 3.3 RRC Connection Reject （Unspecified） PAGEREF _Toc294779730 h 8 HYPERLINK l _Toc294779731 3.2.1 信令流程阶段 PAGEREF _Toc294779731 h 8 HYPERLINK l _Toc294779732 3.2.2 常见原因 PAGEREF _Toc294779732 h 9 HYPERLINK l _Toc294779733 3.2.3 解决方法 PAGEREF _Toc294779733 h 9 HYPERLINK l _Toc294779734 3.4 No Reply

5、原因造成RRC失败 PAGEREF _Toc294779734 h 9 HYPERLINK l _Toc294779735 3.2.1 信令流程阶段 PAGEREF _Toc294779735 h 9 HYPERLINK l _Toc294779736 3.2.2 常见原因 PAGEREF _Toc294779736 h 10 HYPERLINK l _Toc294779737 3.2.3 解决方法 PAGEREF _Toc294779737 h 11 HYPERLINK l _Toc294779738 4.总结 PAGEREF _Toc294779738 h 11背景随着TD-SCDMA网络

6、六期工程接近尾声，目前由于基站建设、基站故障等问题，给网络优化带来了种种困难。本文围绕南通处理RRC相关的部分问题，结合现场实际情况，为现场的网优人员提供了处理RRC相关问题的解决思路。RRC 连接过程的信令流程UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。每个UE最多只有一个RRC连接。当RNC接收到UE的RRC CONNECTION REQUEST消息，由其无线资源管理模块RRM根据特定的算法(CAC算法)确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道还是公共信道。对于RRC连接建立在不同的信道，则RRC连接建立流程也不一

7、样。这样一来，对于RRC连接的信令过程可以大致分为以下几个过程：呼叫接入控制过程（主要由UE发起请求，RNC来控制）无线链路的建立过程RRC建立完成过程RRC连接过程的基本信令流程如下图：相对应在信令跟踪工具内看到的过程如下图（此为手动信令跟踪得来，没有打开内部消息跟踪）：如果对应的TKIT内自动生成的CT数据，则过程如下：图中：FP为帧协议（Node B与RNC同步使用，此时的同步只是针对于用户的新的无线链路的同步，并不是整个Node B与RNC的同步）RRC 失败分析RRC连接失败发生RRC连接建立的过程中，RRC连接一般发生在如下情况下：UE开机UE关机位置区更新UE进行主叫业务UE进行

8、被叫业务参考协议25331，RRC连接失败的原因被分成了两类：Unspecified（未定义）Congestion（拥塞）但在我司的RRC连接失败的原因则根据信令过程，同时参考协议被分成了三类：Unspecified（未定义）Congestion（拥塞）NoReply（未响应）在日常优化的过程中，RRC连接失败则增加了一种情况，变成了一种现象和三种原因，这新增的一种现象就是在路测中UE已经发起了RRC Connection Request 但经过T300超时并且N300超数，从而造成起呼失败。但这种情况也有可能系统侧已经进行了处理，RNC已经下发了RRC Connection Setup但终端

9、没有收到。（注：前两种失败的原因在信令表示中均表现为RRC Connection Reject，只是其Cause值不同，需要展开信令来看失败的原因）下面针对各个阶段的失败，结合相关的信令与硬件组成，逐个分析各种失败的原因。3.1 RRC Connection Request N300+T300超时（数）-路测UE一直上报RRC CONNECTION REQ, 但后台信令跟踪上看不到任何信令过程（使用RTV工具的小区信令跟踪，不要使用IMSI进行信令跟踪，如果使用IMSI进行信令的跟踪，则有可能造成由于Common ID没有下来而不显示相关的信令，本原因针对系统侧没有收到任何信令的情况）。3.1

10、.1 信令流程阶段发生失败的信令阶段如下图所示（图中标注的 eq oac(,1)）：3.1.2 常见原因随机接入过程出现问题，可能存在UpPCH的干扰，首先检查NODEB的RACH统计有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCH干扰。或者是统计LMT对UpISCP的测量（其测量与在KPI内统计的POS干扰统计一致，但精度更高，测量为500ms一次统计，取整个测量时段内的平均值，而KPI统计的测量为15分钟粒度取平均值）通过CT工具检查UPPCH上的干扰通过性能统计，查看UPPOS上的UP干扰统计终端问题，重启UE看能否接入Node B 问题：重启

11、基站3.1.3 解决办法对各地外场的数据分析后，Up干扰有两大类型：出现干扰平台（从当地整个网络来说，出现平台的概率并不高），但除去干扰平台后的干扰曲线基本正常，对于这类干扰通过基带匹配是能判断出干扰信号源构成的，这样基带可以：（1）匹配出干扰源小区，网优调整（方位角、俯仰角或扰码、频点）（2）基带做干扰消除，以消除干扰。干扰曲线整体抬高（从当地整个网络来说，出现干扰曲线整体抬高的概率较高）。对于这种情况可以采集数据看看基带匹配处理后的结果，需要以Upshifting的方式来克服此问题。6月6日南通二桥村，出现RRC建立失败较多，经监测主要为存在上行UP干扰导致，由于二桥村站点在开通时UP初始

12、位置与其它站点不一致，经Upshifting处理后恢复正常，RRC建立成功率为99.4%。3.2 RRC Connection Reject （Congestion）UE上报RRC CONNECTION REQ，但很快RNC就回了信令RRE Connection Reject，并且其所带的Cause值为“Congestion”，产生这种原因主要是因为RRM算法的进行判决的结果，呼叫接纳控制（CAC）是无线资源管理（RRM）中的一个重要组成部分。CACM模块根据小区当前的无线资源和负荷情况以及呼叫的服务质量（QoS），按照一定的算法，对新的呼叫请求可能产生的负荷增加量进行预测，然后依据一定的接入

13、准则，决定对新的呼叫是允许接入还是拒绝接入。CAC的目的是在防止系统出现负荷过载和保证呼叫的服务质量（QoS）的前提下，尽可能保证并提高系统的容量。3.2.1 信令流程阶段信令发生的阶段如下图所示（图中标注的 eq oac(,2)）具体的信令节点如下：根据信令流程也就是说当RL Setup Response已经完成后，才会出现这种情况。3.2.2 常见原因1）资源不足：主要是信道资源、码资源、功率资源等不足造成2）小区硬件故障：目前常见的RRU故障造成。3）CAC参数设置问题3.2.3 解决方法针对两种不同的原因采用不同的措施来解决，下面分别进行描述资源不足造成的失败查看小区的话务量（PS业务

14、流量），看一下小区是不是真的存在资源不足（码道资源）；通过LMT查看一下功率资源情况，是否存在TCP资源不足的问题。如果存在小区的话务量不多，而且TCP占用正常仍会出现拥塞造成的起呼失败，同时又不存在任何告警信息，则在动态数据库管理中查看服务小区状态，是不是存在载频资源被闭塞的现象（在此处闭塞是不存在任何告警信息的）。如果是真正存在资源不足的情况，可以建议进行扩容。小区硬件故障一般存在两种故障，一种是可以通过告警管理进行显示的故障，一种是小区本身没有任何告警信息，属于隐性故障。对于有告警存在的，解决之；如果不存在故障，不得己而为之的方法是对小区或RRU进行重启，以验证。海安明珠城有用户反映，打

15、电话接通较差，经核查此站存在射频单元接口异常告警，后经基站复位后告警消失，起呼正常。3.3 RRC Connection Reject （Unspecified）一旦RNC通过了CAC的验证，RNC会请求Node B配置相应的无线链路资源，一般情况下最少建立一条无线链路，在这个过程中，由于各种不同的原因造成的失败，RNC将给UE发送Cause为“Unspecified”的Reject。3.2.1 信令流程阶段信令发生的阶段如下图所示（图中标注的 eq oac(,3)）根据信令流程也就是说出现RL Setup Failure的现象，才会出现这种情况。3.2.2 常见原因基站小区的故障造成。3.2

16、.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的回应消息，才会出现这情况。从整个信令的流程来看，R

17、RC 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）No

18、de B存在问题Node B的某个板子存在问题，有可能不能正确地接收RNC传送来的信令，也可能不能将信令在FACH完整地传送给RRU4）RRU存在问题RRU不能正确地接收UE上发的RRC Connection Setup Complete信令，或是不能正确地将RRC Connection Setup信令传送给UE5）参数设置存在问题 主要是SCCPCH的功率参数设置存在问题，导致UE无法正确接收RRU传来的信令。6）终端问题3.2.3 解决方法一般采用逐步判断的方法来定位问题确定RNC已经收到了RRC Connection Request请求，并且已经发出了RRC Connection Setup 信令确定RNC内部的各个处理板之间数据传输没有出现问题，可以使用系统工具RDS进行各个处理板之间数据包的传输统计，评估其丢包率。查看传输告