切换异常的几种原因分析及排查共18页Word下载.docx
《切换异常的几种原因分析及排查共18页Word下载.docx》由会员分享,可在线阅读,更多相关《切换异常的几种原因分析及排查共18页Word下载.docx(14页珍藏版)》请在冰豆网上搜索。
1.信令截图:
2.信令分析:
信令消息
过程解释
measurementReport
网络侧收到终端1G/2A测量报告
FpSAddReq
在目标小区建立无线链路及承载,此案例中RL建立过程中夹杂了一条测量报告,该测量报告为2F测量报告,不影响切换过程,可以忽略;
FpSAddRsp
RadioLinkSetupRequest
RadioLinkSetupResponse
FpSInitReq
FpSInitRsp
physicalChannelReconfiguration
网络侧向终端发起物理信道重配过程,终端回应物理信道重配失败,失败原因为物理层同步失败,期间夹杂的测量报告为2F事件,不影响切换过程,可以忽略;
RlmiUciuHelloForward
RlmiUciuHelloFwdAck
physicalChannelReconfigurationFailure
RadioLinkDeletionRequest
网络侧删除目标小区无线链路及承载;
RadioLinkDeletionResponse
FpSRelReq
measurementControl
网络侧重新向终端下发同频及异频测量控制消息或系统间测量;
OlpcParaInfo
原因分析及排查手段:
查看PhysicalChannelReconfigurationFailure中携带的失败原因,比如最常见的Failurecause为physicalchannelfailure,表示UE无法在建立新的物理信道,即UE无法在新的信道配置上完成L1同步(UE在T312时间内,收到N312个同步指示,即认为新的信道建立成功)。
造成这种现象的原因可能为物理信道所在的时隙干扰较大,或目标小区存在UP干扰。
排查方法:
查看各时隙干扰情况,如果发现时隙干扰很大,查看NODEB载扇是否正常,同时查看邻小区是否有大量同频邻区,若在话务量小的情况下,ISCP仍然很高,则干扰可能来自异系统,如:
GSM,PHS等;
查看目标小区UP干扰,若较大,则进行UP位置偏移;
时隙干扰经常性偏大时,可以尝试调低UE的上、下行开环功率;
无效配置、配置不支持等配置错误:
换个手机测试,若各厂家手机测试都有问题,将本小区的重配消息和正常小区的重配消息进行对比,查看配置是否正确;
注:
物理信道/RB重配失败后测量控制下发说明:
切换失败后,RNC会重新下发测量控制消息,测量控制消息中携带邻区列表但不包含频点扰码等具体信息,如图所示,因为之前的测量控制消息中已经携带了邻区的扰码、频点等信息,UE侧已经保存了相关邻区的详细信息,因此网络侧不需要重新携带邻区的详细信息,只需要指示邻区序号。
1.1.2.2物理信道重配超时
measurementReport
FpSAddReq
在目标小区建立无线链路及承载;
FpSAddRsp
RadioLinkSetupRequest
RadioLinkSetupResponse
FpSInitReq
FpSInitRsp
physicalChannelReconfiguration
网络侧向终端发起物理信道重配过程,定时时间内终端未发送物理信道重配完成消息,且在等待时间内未上报小区更新;
UciuHelloForward
UciuHelloForwardAck
SUciuMacMeasReport
RadioLinkDeletionRequest
RadioLinkDeletionResponse
FpSRelReq
IuReleaseRequest
UE收到了RECONFIGURATION消息,并发送了COMPLETE消息,但RNC未收到(上行功率不足或存在干扰等原因);
UE收到了RECONFIGURATION消息,但没发送COMPLETE消息(消息错误或UE内部错误等原因);
若UE未收到重配消息:
调整后台下行最小发送功率,增加UE接收到重配消息的几率,或者调整周围网络的覆盖、频点、功率等,尽量降低下行方向上的干扰;
若网络侧没有收到重配完成消息:
则调整后台DPCH的期望接收功率,同时利用网规网优手段,降低上行方向上的干扰;
1.1.2.3小区更新后物理信道重配超时
网络侧向终端发起物理信道重配过程,定时时间内终端未发送物理信道重配完成消息,则等待终端上报小区更新;
cellUpdate
终端上报小区更新
IuReleaseCommand
rrcConnectionRelease
IuReleaseComplete
RadioLinkFailureIndication
可能原因为:
UE未收到CONFIRM消息(下行功率不足或存在干扰等原因);
UE收到了CONFIRM消息,并发送了COMPLETE消息,但RNC未收到(上行功率不足或存在干扰等原因);
UE收到了CONFIRM消息,但没发送COMPLETE消息(消息错误或UE内部错误等原因);
若UE未收到CONFIRM消息:
调整后台下行最小发送功率,增加UE接收到CONFIRM消息的几率,或者调整周围网络的覆盖、频点、功率等,尽量降低下行方向上的干扰;
1.1.2.4网络侧收到测量报告但未发起切换
终端上报测量报告,在此案例中,测量报告为2A,实际情况中还可能出现1G测量报告的情况,但由于目标小区物理资源不足或目标小区存在异常导致无法分配资源,未发起RL建立及物理信道重配等后续流程;
在此案例中,另一条测量报告为2F,2F事件不会影响切换过程,可以忽略;
measurementControl
网络侧重新下发同频及异频测量控制消息;
3.原因分析及排查手段:
一般为RNC资源申请失败导致,如码道资源不足,软资源(功率、干扰)接纳失败等(此时信令跟踪工具上没有IUB口和空口消息);
可查看目标小区剩余的码道资源数看是否有足够的剩余资源,并查看公共测量值和配置的接纳门限,是否为功率干扰等软资源受限。
1.1.2.5网络侧在RAB指派过程中收到测量报告
2.原因分析及排查手段:
RNC在收到CNRAB指派后,UE上报一个测量报告,但此时RNC在处理CNRAB指派,无法同时处理测量报告,RNC缓存此条测量报告,等RAB指派完成后,在发起切换过程,由于此案例中测量报告中的目标小区来自邻RNC,因此发起了重定位流程。
1.2RNC间切换过程中的异常
1.2.1总体描述
RNC内切换相关的异常主要有如下几种典型场景,
CN侧响应RelocationPrepareFailure:
CN响应超时;
CN响应IuReleaseCommand;
终端RB重配失败;
下面分别详细描述各类异常发生的场景及原因,并给出对应排查手段。
1.2.2典型信令过程及异常分析
1.2.2.1CN侧响应RelocationPrepareFailure
异常描述
当S-RNC向CN发送RelocationRequired消息后,CN向D-RNC发送RelocationRequest,D-RNC侧发起类似于业务接入的流程,分配信令、业务所需的物理资源,并建立无线链路及相应承载,其中任何一个步骤发生异常,则会向CN响应RelocationFailure消息,携带D侧失败的错误码,CN通过RelocationPreparationFailure消息透传该错误码到S-RNC,由于是重定位准备阶段流程发生异常,不会记入跨RNC切换失败,因此不会影响任何KPI指标,但此类异常会导致终端脱离源小区覆盖而又无法切换,最终因覆盖问题导致掉话。
信令过程
由于比较难于搜集同一次跨RNC切换异常过程中S侧和D侧的信令,因此本部分未以截图的形式给出行令流程。
S侧信令:
RNC收到终端1G或2A测量报告,且目标小区不归属于本RNC,向CN发起重定位请求;
RelocationRequired
RelocationPreparationFailure
D侧资源分配失败,D侧RNC向CN发送重定位失败,CN向S侧RNC发送重定位准备失败;
向终端重新发送同频/异频测量建立消息;
D侧信令:
RelocationRequest
D侧RNC收到CN发送的重定位请求,在D侧进行实例创建,承载建立、资源分配等操作,资源分配成功,则发起无线链路建立过程,如果其中某一步执行失败,如无线资源不足、承载建立失败,则没有无线链路建立过程;
RNC发起无线链路建立,NodeB返回失败;
RadioLinkSetupFailure
RelocationFailure
RNC向CN发送重定位失败消息,根据失败的类型填写消息中的错误码;
D侧发起Iu连接释放过程;
原因分析及排查
根据S侧RelocationPreparationFailure消息或RelocationFailure消息中的错误码,参考非标准原因错误码对应表中说明,进行排查;
1.2.2.2CN响应超时
当CNIu口负荷过高或CN存在某种异常时,会不处理S侧发送的RelocationRequired消息,D侧表现为看不到任何信令,S侧在发送RelocationRequired后会设置等待定时器,定时器时长内CN未响应任何消息,则S侧认为对方状态不可知,则发起Iu连接释放过程,记作一次掉话,此类异常影响业务掉话率指标。
IuRelaseRequest
CN在定时时间内(典型配置为10s)未响应,S侧发起Iu连接释放,释放的原因为TRANAP_trelocprep_expiry,表示重定位准备过程超时;
D侧未收到任何CN下发的信令消息。
需要确认和CN的Iu口链路是否存在问题,如故障、拥塞等,重点在CN侧排查问题。
1.2.2.3CN响应IuReleaseCommand
当CN存在某种异常时,收到S侧发送的RelocationRequired消息,立即下发IuReleaseCommand,D侧表现为看不到任何信令,此种异常不会导致任何KPI指标异常,但会影响用户感受。
CN在很短时间内(毫秒级)向S侧下发IuReleaseCommand消息;
需要确认和CN是否存在问题,如故障、拥塞等,重点在CN侧排查问题。
1.2.2.4终端RB重配失败
当S-RNC向CN发送RelocationRequired消息后,D侧完成资源分配及建立过程,S侧下发RB重配消息,由于终端在目标侧同步失败,终端上报RB重配失败消息,记作一次跨RNC切换失败,此类异常影响系统RNC间切换成功率,此外该异常会导致终端脱离源小区覆盖而又无法完成切换,最终因覆盖问题导致掉话。
RelocationCommand
D侧RNC接纳成功,通过RelcationCommand携带D侧分配的物理资源;
radioBearerReconfiguration
RNC通过RB重配消息,将D侧分配的资源信息通知终端;
radioBearerReconfigurationFailure
终端在目标侧物理层同步,或因为配置不支持等原因,向S侧RNC发送RB重配失败消息;
RelocationCancel
S侧RNC收到终端RB重配失败消息后,向CN发送重定位取消,释放D侧分配的资源,并填写对应错误码;
RelocationCancelAcknowledge
CN向RNC发送重定位取消确认消息
RelocationRequest
D侧RNC收到CN重定位请求,分配资源;
资源分配成功后,发起无线链路建立过程;
RelocationRequestAcknowledge
无线链路建立完成后,向CN发送重定位请求确认消息,携带D侧分配的资源,通过CN传递给S侧;
S侧RNC下发RB重配后,终端回应RB重配失败,S侧RNC向CN发送重定位取消,CN向D侧RNC发送的Iu释放命令;
D侧释放已经分配的资源,并删除无线链路;
排查方法参考物理信道重配失败。
1.2.2.5终端RB重配超时
S侧RNC等待CN下发的IuReleaseCommand超时,原因是定时时间内终端未在D侧上报RB重配完成消息,S侧RNC向CN发送Iu连接释放请求,发起Iu连接释放过程。
S侧RNC下发RB重配后,定时时间内终端无响应,S侧RNC向CN发送Iu释放请求,CN向D侧RNC发送的Iu释放命令;
排查方法参考物理信道重配超时。
1.3CS系统间切换过程中的异常
1.3.1总体描述
1.3.2典型信令过程及异常分析
1.3.2.1重定位失败
TRANAP_relocation_failure_in_target_CN_RNC_or_target_system:
在2G网络侧重定位失败,原因不明,可能是GSM侧资源分配问题;
TRANAP_unknown_target_rnc:
可能原因如下:
23GCN对接参数配置错误:
外场初期进行23G测试时都是这个原因,正确配置后问题即可解决;
在Not_BSICVerficationRequired配置,有时UE会上报非要求测量的频点测量事件结果,也会出现此现象;
TRANAP_unspecified_failure:
原因不明;
1.3.2.2UE返回handoverFromUTRANFailure
切换失败的原因都为configurationUnacceptable时,目前认为和UE能力有关,协议上规定,UE返回原因为configurationUnacceptable切换失败的可能为:
UTRAN要求UE在不支持的情况下进行切换;
或UTRAN要求UE使用其不支持的配置;
或HANDOVERFROMUTRANCOMMAND消息中包含了信元“RABinformationList”,并且这个信元不包含任何一个其信元“CNdomainIdentity”被设置为“CSdomain”的信元“RABinfo”。
目前版本中HANDOVERFROMUTRANCOMMAND消息是不携带“RABinformationList”信元的,因此应该是和UE能力相关。
1.3.2.3UE上报CellUpdate
小区更新原因有以下几种:
TRRC_radiolinkFailure:
UE在收到切换请求后,如果无法接入GSM网络,则会尝试使用切换前的物理信道,如果无法同步上DCH则进行原因为radiolinkFailure的小区更新,在出现的CS23G切换失败情况中;
TRRC_re_enteredServiceArea:
此原因比较奇怪,可能是不同厂家的UE实现方式不同,因为如果DCH同步失败,应该回原因radiolinkFailure;
TRRC_rlc_unrecoverableError:
原因不明,怀疑是UE回handoverFromUTRANFailure网络侧没有收到;
1.3.2.4CN以非正常原因释放IU
原因不明,怀疑是3GCN没有收到2GCN的切换结束消息。
1.4PS系统间切换过程中的异常
1.4.1总体描述
1.4.2典型信令过程及异常分析
1.4.2.1CN下发正常释放IU的消息
2G核心网SGSNDNS错误或者没有配置3GSGSN地址解析,导致UE在收到CellChangeOrder切换请求到2G网进行路由更新时失败,失败原因为Implicity_detached,之后UE重新进行附着ATTACH在2G网络接入GPRS业务,成功后HLR向旧的SGSN发送CANCELLOCATION,释放T网中的用户;
表现在3GSGSN信令上为没有收到SRNS请求,收到CANCELLOCATION后正常释放UE;
无线侧信令表现为下发CellChangeOrder后,大概过7~15S收到CN下发的正常释放IU消息;
1.4.2.2RNC主动释放用户
信令过