TDSCDMA RRC接入问题排查指导书V101.docx

TDSCDMA RRC接入问题排查指导书V101.docx

《TDSCDMA RRC接入问题排查指导书V101.docx》由会员分享，可在线阅读，更多相关《TDSCDMA RRC接入问题排查指导书V101.docx（11页珍藏版）》请在冰豆网上搜索。

TDSCDMARRC接入问题排查指导书V101

TD-SCDMARRC接入问题排查

指导书

版本：

V1.0

中兴通讯工程服务部TD产品支持部发布

TD-SCDMARRC接入问题排查

指导书

版本说明：

版本

日期

作者

审核

修改记录

V1.0

2010-5-10

关键字：

接入问题RRC连接排查

摘要：

接通率是TD-SCDMA无线网络KPI中的一个重要指标，其中RRC连接部分占有很重要的位置。

本文整合了多篇目前存在的RRC接入问题的排查文档，对影响RRC建立成功率的各种原因作了详细地说明，并对各种接入问题进行汇总，并给出分析思路和优化方法。

缩略语：

无

参考资料：

[1]TD-SCDMA无线性能优化思路树

[2]RRC建立成功率低案例分析

[3]RRC问题集及研发答疑

[4]TD-SCDMA接入问题分析指导书

[5]RRC连接成功率低问题处理总结报告V1

目录

1RRC连接建立信令流程1

2RRC建立成功率低的排查与定位4

2.1RNC收不到RRCConnectionRequest4

2.2RRC失败原因Unspecified5

2.3RRC建立失败原因为Congestion5

2.4RRC失败原因NoReply排查6

2.4.1干扰原因7

2.4.22/3G切换8

2.4.3FACH丢包8

2.4.4FACH出窗9

RRC连接建立信令流程

在UE发起呼叫建立时，如果之前UE没有建立RRC连接，则先建立RRC连接，再通过初始直传建立传输NAS消息的信令连接，最后建立RAB。

被叫过程包括了寻呼过程，在接入层内与主叫过程很类似，其它区别主要体现在NAS消息上，完整的起呼流程如图1-1。

图1-1起呼完整的信令流程

下面重点介绍RRC建立过程。

RRC连接是UE与UTRAN的RRC协议层之间建立的一种双向点到点的连接，在UE与UTRAN之间传输无线网络信令。

UE处于空闲模式下，当UE的非接入层要求建立信令连接时，UE将发起RRC建立请求。

每一个UE在尝试建立的过程中，只能建立一次RRC连接。

图1-2是RRC连接建立流程（建立在DCH上）。

图1-2RRC建立连接流程

主要过程介绍如下：

（1）UE在取得下行同步后，向NodeB发送SYNC_UL，接收到NodeB回应的FPACH信息后，UE没有专用信道资源，于是在CCCH（RACH，随机接入信道）上向RNC发送RRCConnectionRequest消息，发起RRC连接建立过程。

通过发送一个RRCConnectionRequest消息，UE从空闲模式转入连接模式。

主要参数：

InitialUEIdentity,Establishmentcause,InitialUECapability.

当RNC收到RRC建立请求以后，RNC根据RRC建立的原因及系统资源状态，判断是否允许接入，如果允许，则为RRC连接分配RNTI和L1、L2资源，分别调用无线链路建立的NBAP过程、ALCAPIub数据传输承载建立过程和上、下行同步过程。

UE被分配了无线网络临时标识（RNTI）后，UTRAN可以使用RNTI来寻呼特定的UE，UE也可以使用RNTI来发起随机接入过程。

（2）RNC准备建立RRC连接，分配建立RRC连接所需要的资源，并发送一条RadioLinkSetupRequest消息给NodeB，请求NodeB分配RRC连接所需的特定无线链路资源，NodeB收到消息后，将保留必要的资源，并根据消息中给出的参数配置新的无线链路。

主要参数：

Cellid,TransportFormatSet,TransportFormatCombinationSet,frequency,TimeSlots,信道码,Powercontrolinformation。

无线链路建立过程用于建立一条承载1个或多个传输信道的无线链路。

（3）NodeB根据RadioLinkSetupRequest消息的参数，来建立NodeB的上、下行无线链路，配置成功后，在新的物理信道上准备接收UE消息，并给RNC发送一条RadioLinkSetupResponse响应消息。

主要参数：

Signallinglinktermination,Transportlayeraddressinginformation（AAL2address,AAL2BindingIdentity）fortheIubDataTransportBearer.

（4）RNC通过ALCAP协议，建立Iub数据传输承载。

Iub数据传输承载通过AAL2的绑定标识与DCH绑定在一起。

建立Iub数据传输承载需要NodeB确认。

（5）（6）通过DownlinkSynchronisation和UplinkSynchronisation.控制帧，NodeB与RNC为Iub数据传输承载建立同步。

此后NodeB开始DL发送。

（7）虽然Iub上DCH的资源都准备好了，但是此时UE并不知道，所以UE选择一个承载FACH的SCCPCH，用于接收RRCConnectionSetup消息；RNC在CCCH上向NodeB发送RRCConnectionSetup消息给UE，告知UE相关参数。

主要参数：

InitialUEIdentity,RNTI,CapabilityupdateRequirement,TransportFormatSet,TransportFormatCombinationSet,frequency,TimeSlots,信道码,Powercontrolinformation。

当UE收到RRCConnectionSetup消息后，会启用新的空口承载参数来配置在UE侧的RLC,MAC，PHY。

当它使用新的参数与NodeB同步上后，NodeB会向RNC发送RLRestore消息，完成从公共信道转到专用信道上切换的过程。

（8）UE收到RNC发送的RRCConnectionSetup后，根据消息中给定的参数来配置物理层，NodeB成功建立DCH链路，然后在DCCH上发送RRCConnectionSetupComplete消息给RNC。

主要参数：

Integrityinformation,cipheringinformation。

至此RRC连接建立完成。

RRC建立成功率低的排查与定位

RRC连接阶段是接入的主要问题，RRC连接和外界干扰、参数配置、传输配置的关系比较大，外场反馈的接入问题大都和RRC连接有关，本文重点就RRC连接进行分析，对RRC连接成功率的问题进行排查定位。

1、先看UE在RRC连接建立不成功时有没有重发，如果没有重发，可以考虑是不是有同频同扰情况。

2、如果是UE下行收到了FACH下发的RRCConnectionSetup后，将会进行空口同步过程。

判断UE是否收到了FACH上的信息，可以看RRCConnectionRequest的重发时间间隔，如果间隔为2s，表明下行UE没有收到FACH信息。

此时需要看下行是否有FACH出窗情况，如果出窗情况较少，则判断附近是否有主载波同频的情况，导致下行干扰严重。

3、如果间隔为4s，表明UE已经收到FACH信息，如果没有RadioLinkRestore，表明上行同步没有同步上，可以试着提高上行的SIRTarget。

4、如果上行有RadioLinkRestore，则判断上行同步没有问题，看Iub口上有没有FailInd出现，如果有，表明Iub口DCH同步没有同步上，查看E1的配置是否足够，E1的配置在2条以下或者是Iub口上流量指标特别大的建议添加E1。

5、如果是室内小区，看是否下行建立在3时隙，如果一个室内小区中，建立在其他时隙中的业务可以增长进行，而部分下行建立在TS3中的业务无法进行，如果室内小区有干放，可以怀疑干放的时隙配置是否有问题。

去现场复测RRU覆盖区域和干放覆盖区域的差异，或者反馈给室分厂家确认。

6、查看CT文件中的失败是否是同一UE导致的，如果是有限的几个IMSI号导致的，可以进行现场复测，查看是否是UE问题。

目前RRC连接失败后台统计的原因主要有三种：

Congestion、Noreply和Unspecified，下面对这几类问题进行分析定位。

RNC收不到RRCConnectionRequest

RNC收不到的情况，主要有以下原因造成：

1、随机接入过程出现问题，可能存在UpPCH的干扰，处理思路如下

首先检查NODEB的RACH统计有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCH干扰。

通过CT工具检查UPPCH上的干扰

通过性能统计，查看UPPOS上的UP干扰统计

2、终端问题，重启UE看能否接入

3、NodeB问题：

重启基站

RRC失败原因Unspecified

Unspecified的主要原因有下面几个：

1、E1不足导致的Unspecified现象，E1承载不足导致的接纳失败，不仅在RAB指派过程中发生，在RRC连接过程中也可能发生，即E1既会影响RRC建立指标，也会影响到RAB指派的指标。

由于E1传输不足导致的RRCRejectUnspecified失败，判定依据是信令上RRC建立过程中RLSetupResponse后10ms左右就删除RL，同时结合基站的E1数量、指标中RAB建立失败Iubbear_Operatefail次数，可共同判定是否由于E1拥塞导致的RRCReject。

2、传输不稳定导致Unspecified现象。

从信令上看，NodeB给RNC回复RLRLSetupResponse后，在5s左右直接进行RL删除。

察看站点是否有传输告警，传输闪断的故障对指标影响较大，传输异常、传输瞬断导致ERQ/ECF协商失败，5S定时器超时后直接删除链路。

3、小区单板故障导致的Unspecified现象，可能会引起板间丢包，需要更换单板。

从信令上看，RNC下发RLSetupResponse后，NodeB直接回复RLSetupFail，可以通过NodeB内部命令统计，确认NodeB控板与基带板之间是否丢包。

目前发现丢包的有TBPE、TBPH、SBMP，如果确认丢包，可以直接更换单板。

RRC建立失败原因为Congestion

1、资源不足导致的拥塞

外场发现由于载波资源导致此原因值，这种情况多发生在单载波的站点，建议通过扩容载波解决，可以通过LMT小区载波测量查看小区码资源配置及使用情况。

如果存在小区的话务量不多，而且TCP占用正常仍会出现拥塞造成的起呼失败，同时又不存在任何告警信息，则在动态数据库管理中查看服务小区状态，是不是存在载频资源被闭塞的现象并检查一下有没有载波（或时隙）被闭塞现象（也可在OMCRNodeB动态数据管理中查看）。

2、上行ISCP过大导致的拥塞

对于载波数较多的站点，有可能由于上行ISCP过大导致拥塞。

如果上报给RNC的ISCP过高，导致RNC在接收到UE的RRCConnectionRequest时，拒绝接纳，这会使得在这个小区内的需要注册的用户反复进行注册，导致大量的拥塞发生。

RRC失败原因NoReply排查

造成NoReply的原因很多，如RNC将发送RRCConnectionSetup信令给UE，在规定的时间内，没有收到UE的RRCConnectionComplete信令，那么系统侧将会判断本次RRC过程失败，并且其原因值为NoReply。

信令的流程来看，RRCConnectionSetup信令首先从RNC的控制面发出，经过内部处理，通过RNC与NodeB之间的接口板，再经过传输线路到NodeB与RNC的接口板，然后在NodeB内部处理，再通过RRU经Uu口到UE，UE收到RRCConnectionSetup后，在DCCH信号上发RRCConnectionComplete消息，如果每个环节出现问题都会出现NoReply的现象。

这种情况需要结合实际情况进行分析，也有两种情况，第一种情况是RRCConnectionSetup信令终端并未收到；第二种情况是终端收到了RRCConnectionSetup但发的RRCConnectionSetup消息系统侧没有收到或是终端没有发RRCConnectionComplete消息。

常见的原因主要有：

1、覆盖弱场问题

如果确认是UE没有收到RRCConnectionSetup消息，请现场测试是否由于信号弱场导致，也可增加SCCPCH的功率，观察效果。

2、RNC硬件存在故障

察看硬件告警，如果RNC内部处理板或对外的接口板存在问题，不能正确地将RRCConnectionSetup信令发送给NodeB

3、传输存在问题

察看传输告警，如果从RNC到NodeB之间的传输存在问题，如果FACH出窗、丢包严重，不能正确将RRCConnectionSetup信令发送给NodeB。

4、NodeB存在问题

查看NodeB的收包情况与RNC的送包数量一致，同时确定NodeB在FACH上正确完整地将数据传出。

如果NodeB的某个板子存在问题，则可能无法正确接收RNC传送来的信令，也能可能无法将信令在FACH完整地传送给RRU。

5、RRU存在问题

RRU不能正确地接收UE上发的RRCConnectionSetupComplete信令，或是不能正确地将RRCConnectionSetup信令作传送给UE

6、参数设置存在问题

主要是SCCPCH的功率参数设置存在问题，导致UE无法正确接收RRU传来的信令。

7、外部干扰问题

上行干扰大，会导致RNC收不到RRCConnectionComplete消息。

8、终端问题

处理思路如下：

干扰原因

RNC已经下发了RRCConnectionSetup请求，且能收到基站上报的RadioLinkRestoreIndication消息,但收不到UE上报的RRCConnectionComplete消息。

1、从LMT小区载波测量观察，UpIscp和上行时隙ISCP功率正常，如下图2-1：

图2-1LMT小区载波测量

其中换算方式为-120+测量值*0.5可以看到测量正常，换算后如果大于-100dBm，就认为干扰过大。

2）干放的干扰影响：

在有干放组网的楼宇，可以使用手机分别在RRU、干放覆盖区域现场测试，如果RRU覆盖区域各业务连接正常，但在干放覆盖区域，手机一直无法接通，说明干放存在问题，推动干放厂家排查解决。

2/3G切换

2/3G切换情况情况下较容易出现NoReply。

如果系统间小区重选导致此问题占一定比例，这说明弱覆盖的比例较高，可能主要集中在室内，重点检查信号覆盖情况。

FACH丢包

RRCConnectionSetup消息就是在FACH信道上发送的，如果FACH信道上确实存在丢包的现象，可能会导致RRC连接不成功。

可以通过RDS工具，统计RNC上用户面处理板RUB收发包情况，见图2-2。

图2-2检查FACH是否丢包

从图2-2可以看出FACH信道上确实存在丢包的现象，由于RRCConnectionSetup消息就是在FACH信道上发送的，所以怀疑这就是RRC连接不成功的根本原因。

再统计NodeB上TBPH单板收发包的情况，如下图2-3所示：

图2-3TBPH单板收发包情况

可以看出NODEB并不存在FACH丢包的情况，那么数据包应该是在RNC内部交换的时候就丢掉了，而不是在IUB口传输过程中丢掉的。

FACH出窗

FACH出窗可能引起NodeB丢数据，导致UE无法收全RRCConnectionSetup消息，UE就不会回RRCConnectionComplete。

少量的出窗对于指标影响非常小。

对于出窗严重的站点，建议重点检查一下E1的时延和抖动，

现场先确定下，RRC连接成功率低是普遍现象还是只有部分小区。

如果是普遍现象，则可能是TOWS、TOWE在RNC和NodeB配置不一致引起的；如果是部分小区，请确定一下这些小区是否在同一个DSP上，在RUB上用ShowCciuInfo可以查看该RUB上有哪些小区；另外需要看看这部分小区在传输上有没有什么共性。

利用LMT的判断方法如图2-4：

图2-4检查FACH是否出窗

使用LMT，看到FACH信道时间调整数目有增长，说明当前Iub口时延有抖动，如果时间调整的数目占FACH信道数据帧数5%以上，说明IUB时延抖动较大，RNC发来的数据就不是落在FACH的TOAWS/TOAWE的传输窗口内。

而窗口外收到的FACH帧将不做处理，这样可能导致承载RRCConnectionSetup消息的FACH被丢弃，从而导致RRC建立成功率降低。

一般来说，稳定的传输网络上时间调整帧占相应传输数据帧的比例应非常低。

FACH包出窗有几种原因：

1、RNC侧老的用户面处理板RUB板晶振有问题，按附件排查。

2、RNC的控制面发给NodeB的TOWS和TOWE跟发给用户面的不一致，导致NodeB这边FACH出窗。

按附件排查。

3、传输丢包问题

按照传输问题解决。