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

RRC连接拥塞与无响应处理思路 作者：原学军 中兴通讯工程服务部TD网规网优部 发布 背景 随着TD-SCDMA网络二期工程接近尾声，全国的网络建设即将紧随其后开展起来。在网络建设的初期阶段，由于基站建设、基站故障等问题，给网络优化带来了种种困难。本文就在长沙处理RRC相关的部分问题，结合现场实际情况，为现场的网优人员提供了处理RRC相关问题的解决思路。 RRC 连接过程的信令流程 UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。每个UE最多只有一个RRC连接。 当RNC接收到UE的RRC CONNECTION REQUEST消息，由其无线资源管理模块RRM根据特定的算法(CAC算法)确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道还是公共信道。对于RRC连接建立在不同的信道，则RRC连接建立流程也不一样。这样一来，对于RRC连接的信令过程可以大致分为以下几个过程： 呼叫接入控制过程（主要由UE发起请求，RNC来控制） 无线链路的建立过程 RRC建立完成过程 RRC连接过程的基本信令流程如下图： 相对应在信令跟踪工具内看到的过程如下图（此为手动信令跟踪得来，没有打开内部消息跟踪）： 如果对应的TKIT内自动生成的CT数据，则过程如下： 图中：FP为帧协议（Node B与RNC同步使用，此时的同步只是针对于用户的新的无线链路的同步，并不是整个Node B与RNC的同步） RRC 失败分析 RRC连接失败发生RRC连接建立的过程中，RRC连接一般发生在如下情况下： UE开机 UE关机 位置区更新 UE进行主叫业务 UE进行被叫业务 参考协议25331，RRC连接失败的原因被分成了两类： Unspecified（未定义） Congestion（拥塞） 但在我司的RRC连接失败的原因则根据信令过程，同时参考协议被分成了三类： Unspecified（未定义） Congestion（拥塞） 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 常见原因 随机接入过程出现问题，可能存在UpPCH的干扰， 首先检查NODEB的RACH统计有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCH干扰。或者是统计LMT对UpISCP的测量（其测量与在KPI内统计的POS干扰统计一致，但精度更高，测量为500ms一次统计，取整个测量时段内的平均值，而KPI统计的测量为15分钟粒度取平均值） 通过CT工具检查UPPCH上的干扰 通过性能统计，查看UPPOS上的UP干扰统计 终端问题，重启UE看能否接入 Node B 问题：重启基站 3.1.3 解决办法 对各地外场的数据分析后，Up干扰有两大类型： 出现干扰平台（从当地整个网络来说，出现平台的概率并不高），但除去干扰平台后的干扰曲线基本正常，对于这类干扰通过基带匹配是能判断出干扰信号源构成的，这样基带可以： ，网优调整 （2）基带做干扰消除，以消除干扰。 干扰曲线整体抬高（从当地整个网络来说，出现干扰曲线整体抬高的概率较高）。可以采集数据看看基带匹配处理后的结果，需要以Upsfifting的方式来克服此问题。QoS），按照一定的算法，对新的呼叫请求可能产生的负荷增加量进行预测，然后依据一定的接入准则，决定对新的呼叫是允许接入还是拒绝接入。CAC的目的是在防止系统出现负荷过载和保证呼叫的服务质量（QoS）的前提下，尽可能保证并提高系统的容量。 3.2.1 信令流程阶段 信令发生的阶段如下图所示（图中标注的） 具体的信令节点如下： 根