TDSCDMA RRC接入问题排查指导书V101.docx
《TDSCDMA RRC接入问题排查指导书V101.docx》由会员分享,可在线阅读,更多相关《TDSCDMA RRC接入问题排查指导书V101.docx(11页珍藏版)》请在冰豆网上搜索。
![TDSCDMA RRC接入问题排查指导书V101.docx](https://file1.bdocx.com/fileroot1/2022-12/30/1f11b533-53ae-4a90-995b-cd436345fc45/1f11b533-53ae-4a90-995b-cd436345fc451.gif)
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、传输丢包问题
按照传输问题解决。