切换失败的信令分析
未接通、掉话及切换失败
未接通、掉话及切换失败分析一、未接通分析正常呼叫主叫起呼和被叫接入过程：主叫起呼信令流程图被叫接入信令流程图由主叫起呼信令流程图可以看出，主叫首先发出channel request report-→immediate assignment-→CM service request-→setup-→call proceeding-→assignment command-→assignment complete-→alerting-→connect-→完成一次起呼。
在主叫assignment complete 完成后2－3秒左右被叫开始信道请求流程Channel request report→immediate assignment-→setup→call confirmed→assignment command→assignment complete-→alerting→connect-→完成一次被叫接入。
1、未接通原因分析（1）RACH冲突或者AGCH拥塞建议：查看与RACH相关的参数――最大重发次数和发送分布时隙数以及与AGCH相关的参数――接入准许保留块数（2）SDCCH拥塞建议：检查SDCCH配置，查看相关小区SDCCH话务量（3）SDCCH掉话或者TCH拥塞建议：查看是否启用SDCCH信道上的切换，查看相关小区话务量和TCH配置，在排除无线方面原因后，应跟踪Abis接口、A接口信令从交换侧寻找问题原因（4）位置更新引起未接通建议：查看位置更新定时器和位置区设置（5）小区重选过程引起未接通建议：查看相关小区的小区重选参数2、未接通实例分析（1）SDCCH拥塞导致未接通在主叫完成起呼（assignment complete ）后2秒左右，此时被叫发起信道请求channel request report,由于SDCCH拥塞溢出，被叫手机无法获得SDCCH，重复2次发送信道请求后仍然无法获得SDCCH信道消息的回复，导致未接通的发生。
切换失败原因分析
切换失败原因分析1、软切换失败原因根据信令流程，导致切换失败的情形有以下几种1）、ASU消息过多问题切换参数不合理的导致乒乓切换例如切换参数reporting range 1A和reporting range 1B的差别很小，那么小区刚进入AS 又马上移出AS；如果Hysteresis 1C设置太小，那么一个刚被替换进AS的小区又马上移出AS。
导频污染UE不断上报测量消息，RNC不断下发ASU消息，容易导致切换失败。
2）、软切换优化注意问题控制软切换比例网络建设初期，容量不受限制，以提升覆盖为目标。
软切换比例可容许在40%甚至更高。
这样可以保证上行良好覆盖并且可以减少掉话，由于软切换带来分集增益，从而降低了UE发射功率。
当网络不断发展，由于容量问题凸现，由于软切换带来上下行系统硬件开销以及消耗下行码资源。
综合考虑容量和覆盖问题，将软切换控制在一个合理的比例，通常为30-40%。
保证软切换成功率和低掉话绝对值以合理的网络规划和合理的软切换参数为前提，保证切换的及时性。
减少乒乓切换减少乒乓切换，以减少信令交互和资源消耗，从而降低掉话率。
乒乓切换调整有几个方面，控制导频污染，通过切换参数克服。
例如调整1A和1B的迟滞，增大Time to trigger 参数。
根据不同的场景设置不同的小区参数。
2、ISHO失败原因上行链路质量差事件2D门限（CM START）设置不合理时间3A参数（ISHO）设置不合理当前W小区漏配GSM邻区当前W小区配置GSM邻区过多目标GSM小区无可用无线资源当前ISHO优化主要针对W覆盖边界与GSM覆盖区的优化。
若W边界GSM小区覆盖较好，则有利于向GSM切换。
若GSM信号强度不够，则增大了异系统测量失败或者信令交互失败的可能，从而导致掉话。
所以W覆盖内部应尽量达到信号的连续覆盖，减少弱覆盖和盲区。
使得ISHO发生在W覆盖区域的边缘，减少ISHO的次数。
另外W系统间切换应尽量选择在人口密度小的区域，减少切换次数，也避免了因处理能力不足而使信令交互延时或失败，最终导致掉话。
LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功关键字：X2IPPATH 切换【现象描述】切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：（1）传输资源不够用；（2）没有配置IPPATH；（3）IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令（RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下：LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId，查看X2口两端的IP配置是否正确。
LTE信令-切换失败
Computer Timestam p: 17:21:50. 546 ULDCCHMessage
message
tterns :
si-
ssp7
WindowL
ength :
ms20 systemInf
oValueTa
g : 19
rsrpResult : 39 rsrqResult :6
measRes ultListEUT RA
MeasRes ultEUTRA
physCellId : 94 measRes ult
12 00 00
RRC: RRCConn ectionRec onfigurati on
Message type: DCCH_D L Direction: Downlink Frame No: 490 Subframe No: 4
Computer Timestam p: 17:21:50. 765 DLDCCHMessage
message c1
rrcConnec tionRecon figuration
rrcTransacti onIdentifie r:1 criticalExt ensions
c1
rrcConnec tionRecon figurationr8
mobilityC ontrolInfo
targetPhy sCellId : 94 t304 : ms1000
measIdTo RemoveLi st
measIdTo AddModLi st
GSM关于切换失败的问题分析(DOC)
关于切换失败的问题分析问题描述从信令上来说切换失败可以划分为两方面的问题：切换选择失败和切换执行失败。
切换选择失败是从BSC到BTS的HO COMMAND数与BSC收到的HO INDICA TION 数之差。
切换选择失败的原因往往是由于目标小区信道资源不足或系统存在参数或硬件问题（即难以建立BSC与BTS之间的L2连接）。
切换执行失败是BSC发向BTS的HO COMMAND数与BSC收到的HO COMPLETE之差。
主要反映了空中无线接口的质量。
当切换成功后，MS将向目标小区发出HO COMPLETE的报文，目标BSC收到该报文后将计一次切入成功；若该切换属于INTRA MSC切换时，当发起BSC收到CLEAR COMMAND（该报文中含有清出的原因为切换成功）将计切出成功一次。
当MS由于无线原因，导致无法占用目标小区的信道而引起切换失败后，将向原小区发出切换失败的报文，此后MSC向目标BSC发出清除请求（CLEAR REQUEST），该报文中带有清除的原因是切换失败，于是该BSC就计切入失败一次。
1．切换失败的情况。
（未考虑双频情况和基于SDCCH切换的情况）下图列出了BSC内切换的信令流程：********************************************************************解决方案：（1）硬件故障。
如载频或主控板或传输问题。
还有可能是天线方位错误；天线端口对应错误或机柜上的载频发射连线接错，被耦合到其它小区去发射了。
现象如下图所示：（硬件问题在上下性的质量切换上体现的尤其明显）（2）孤岛效应（同频同BSIC）。
如果两个小区有相同的(BSIC，BCCH)，在正常的情况下这样的两个小区的相距距离应该足够大，他们之间不应该有什么关系。
但由于孤岛现象的存在，一旦孤岛覆盖周围的小区的邻小区表上定义了与孤岛小区同BSIC、BCCH的邻小区)位于的通话手机将会收到孤岛小区的BCCH信号并上报BSC，这个虚假的邻小区测试报告将会误导切换控制程序发出切换指令，这样就使得这些小区内的通话频频尝试向实际信号并不好的小区发出切换请求。
经典案例_切换失败典型优化案例
切换失败典型案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (5)切换失败典型案例【摘要】近期处理top小区时发现，在入网基站开通ANR功能的情况下部分小区仍然会出现切换失败高的现象。
本文以一类切换失败率高的典型案例进行分析，同时总结从信令角度快速定位切换失败的原因，从而准确有效处理切换失败类问题，提升用户感知和降低用户投诉率。
【关键字】ANR切换失败【业务类别】切换信令、参数优化一、问题描述二、分析过程1、查询邻区关系对查询可见BB-怀远-怀远工业园-HFTA-440465-51同频切换失败主要目标小区是站号为440378的51小区，且切换失败的主要原因为eNB间S1口小区间同频切换出准备失败次数，目标侧准备失败。
2、信令分析根据切换出失败原因为S1口小区间同频切换出准备失败可知，信令问题出现在下图红色方框区域，第一部分为源小区经过MME向目标小区发起切换请求，申请资源；第二部分为目标小区经过MME向源小区应答请求3、告警查询查询相关两个基站告警情况，均不存在告警。
4、查询邻区关系查询邻区关系发现BB-怀远-怀远工业园-HFTA-440465-51邻小区中BB-怀远-怀远县碧桂园小区北-HFTA-440378-51和BB-禹会区-禹会区杜郢-ZFTA-155959-189同频且同PCI 142。
此时UE上报测量到的PCI=142给eNodeB后，eNodeB不能分辨UE测量到的邻区对象是哪个小区（BB-怀远-怀远县碧桂园小区北-HFTA-440378-51和BB-禹会区-禹会区杜郢-ZFTA-155959-189），从而导致BB-怀远-怀远工业园-HFTA-440465-51不发起切换，即图3中信令S1AP_Handover_Required消息不发送，导致切换失败。
三、解决措施由于开启ANR功能，删除邻区并不一定能解决邻区同PCI问题，所以建议将不合理邻区关系“允许切换”修改为“禁止切换”，参数修改后BB-怀远-怀远工业园-HFTA-440465-51切换成功率回复正常水平：四、经验总结切换失败通常是指切换的信令流程交互失败，关注点在信令的交互，只有在信令交互出现丢失或信令处理结果失败才会失败。
切换异常的几种原因分析及排查
RNC发起无线链路建立，NodeB返回失败；
RadioLinkSetupFailure
RelocationFailure
RNC向CN发送重定位失败消息，根据失败的类型填写消息中的错误码；
IuReleaseRequest
D侧发起Iu连接释放过程；
IuReleaseCommand
原因分析及排查手段：
可能原因为：
UE未收到CONFIRM消息（下行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
排查方法：
网络侧向终端发起物理信道重配过程，定时时间内终端未发送物理信道重配完成消息，且在等待时间内未上报小区更新；
measurementReport
UciuHelloForward
UciuHelloForwardAck
SUciuMacMeasReport
RadioLinkDeletionRequest
网络侧删除目标小区无线链路及承载；
RadioLinkDeletionResponse
FpSRelReq
IuReleaseRequest
原因分析及排查手段：
UE收到了RECONFIGURATION消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了RECONFIGURATION消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
1.1.2.5
1.信令截图：
2.原因分析及排查手段：
切换失败信令处理(中兴)
切换失败信令处理(中兴)切换失败信令处理UU接口信令异常的常见原因有：1)测量报告丢失，可能的原因主要有➢UE上发测量报告的UL GRANT没有收到，下行PDCCH受限➢UE上发的测量报告，eNB没有收到（或收到但CRC错），上行PUSCH受限➢UE内部层间丢失，例如L3把测量报告给L2发送时，L2处理失败2)切换命令丢失，可能的原因主要有➢eNB因为在切换内部流程处理（如邻区漏配、资源不够等）出错，没有下发切换命令➢UE下行PDCCH解析失败，下行PDCCH受限➢UE下行PDSCH解析失败，下行PDSCH受限3)切换完成信令丢失，可能的原因主要有➢UE在目标小区的PREAMBLE，eNB没有收到，上行PRACH受限➢UE下行接收RAR失败，下行PDSCH受限➢UE上发切换完成，eNB没有收到，上行PUSCH受限4)11111切换请求丢失，可能的原因主要有➢eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败➢X2口传输异常，如传输丢包5)切换响应丢失，可能的原因主要有➢源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVER CANCEL信令➢目标小区切换准备异常，这时通常会在X2口出现 HANDOVER PREPARATION FAILURE信令➢X2口传输异常，如传输丢包6)SN状态前转信令丢失，可能的原因主要有➢X2口传输异常，如传输丢包➢源小区内部错7)UE上下文释放信令丢失，可能的原因主要有➢X2口传输异常，如传输丢包➢目标小区收到切换完成后内部处理错，导致没有进行S1 PATH切换➢S1 PATH切换失败对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
X2接口信令异常的常见原因有：8)跨X2切换的S1AP PATH SWITCH REQ丢失，可能的原因主要有➢目标eNB内部处理切换完成信令失败➢S1口传输异常，如传输丢包9)跨X2切换的S1AP PATH SWITCH REQ ACK丢失，可能的原因主要有➢核心网收到S1AP PATH SWITCH REQ消息后，内部处理失败10)跨S1切换的S1AP HANDOVER REQUIRTED信令丢失，可能的原因主要有➢源小区因为在切换内部流程处理出错（如邻区漏配、资源不够等），没有发切换请求消息S1AP HANDOVER REQUIRTED➢S1口传输异常，传输过程中丢失11)跨S1切换的S1AP HANDOVER REQUEST信令丢失，可能的原因主要有➢核心网收到S1AP HANDOVER REQUIRTED后，内部处理出错➢S1口传输异常，传输过程中丢失12)跨S1切换的S1AP HANDOVER REQUEST ACK信令丢失，可能的原因主要有➢目标小区收到S1AP HANDOVER REQUEST后，内部处理出错（如资源不足等）➢S1口传输异常，传输过程中丢失13)跨S1切换的S1 HANDOVER CMD信令丢失，可能的原因主要有➢核心网收到S1AP HANDOVER REQUEST ACK后，内部处理出错➢S1口传输异常，传输过程中丢失14)跨S1切换的S1AP ENB STATUS TRANSFER信令丢失，可能的原因主要有➢源小区处理收到S1 HANDOVER CMD后，内部处理出错➢S1口传输异常，传输过程中丢失15)跨S1切换的S1AP MME STATUS TRANSFER信令丢失，可能的原因主要有➢核心网收到S1AP ENB STATUS TRANSFER后，内部处理出错➢S1口传输异常，传输过程中丢失16)跨S1切换的S1AP HANDOVER NOTIFY信令丢失，可能的原因主要有➢目标小区收到切换完成消息后，内部处理出错➢S1口传输异常，传输过程中丢失17)跨S1切换的S1AP UE CONTEST REL CMD信令丢失，可能的原因主要有➢核心网收到S1AP HANDOVER NOTIFY后，内部处理出错➢S1口传输异常，传输过程中丢失18)跨S1切换的S1AP UE CONTEST REL CMP信令丢失，可能的原因主要有➢源小区收到S1AP UE CONTEST REL CMD后，内部处理出错➢S1口传输异常，传输过程中丢失对于S1口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
从那些信令里面判断CDMA软切换失败？
1.手机发送PSMM后，BS收不到导致没有下发UHDM，导致MS根本不能进入软切换的下一步。这可以称为PSMM阶段的失败。
2.手机发送PSMM后，基站下发UHDM，MS无法收到该消息导致无法进入下一步，切换失败。可以成为UHDM的失败。
3.手机发送PSMM后，基站下发UHDM，MS收到该消息后，不能及时进入执行HCM完成软切换导致失败，再次同步搜索网络。这个可以成为HCM失败1。
4.不排除另外一种情况，手机无法执行UHDM的切换指令，比如临区配置问题导致。这个可以成为CAI消息上严格的判断切换失败事件，应该不是个容易的事情，关键是严谨很难，我也考虑这个问题很久了，一直没有好办法。
通过A口信令分析排查核心网侧切换失败原因的思路和方法
通过A口信令分析排查核心网侧切换失败原因的思路和方法文章先介绍基本局间切换的信令流程，再通过对A口信令追踪，对由于核心网侧问题引起的切换失败的原因进行了分析和判断，并提出解决方案，从而达到提高移动通信网络服务质量和用户感知的目的。
【摘要】【关键词】A口信令核心网侧切换源网元目标网元张 惠 广东宜通世纪科技股份有限公司1 引言切换是移动用户业务接入过程中或业务进行过程中，由于用户的移动性而发生的改变位置小区选择的行为。
通话中的手机需要靠切换来保持良好的上下行信号强度和质量。
切换主要包括BSC内的小区间切换、MSC内的BSC间切换以及MSC间切换。
本文通过对A口信令追踪，针对MSC内的BSC间切换、MSC间切换两种切换类型，对切换失败案例进行分析，确定引起切换失败的原因，并排查导致此类问题的原因和隐患，对提高移动通信网络的服务质量具有现实意义。
2 基本局间切换的信令流程基本局间切换的信令流程如图1所示。
具体如下：（1）BSS-A向MSC-A发送Handover Required。
（2）M S C-A给M S C-B发送M A P_P r e p a r e_ Handover消息。
（3）MSC-B向VLR-B申请切换号码。
（4）VLR-B分配一个切换号码给MSC-B。
（5）MSC-B回复VLR-B确认收到切换号码。
（6）M S C-B向B S S-B接口发送H a n d o v e r Request消息。
（7）BSS-B向MSC-B 发送Handover Request Ack消息。
（8）MSC-B局间通过MAP_Prepare_Handover_ Ack消息发送给MSC-A。
（9）MSC-A发送IAM消息给MSC-B。
（10）MSC-B向MSC-A发送ACM消息。
（11）M S C-A给B S S-A发切换命令H a n d o v e r Command。
（12）手机发送Handover Access消息。
切换失败事件层三信令详解
切换失败原因手机在通话中为了保证通话质量，经常会切换到能够提供更好服务的小区上去，如果移动的距离较长，则会发生多次切换的现象。
虽然切换失败不等同于掉话，但在GSM网络中切换失败就意味着增加了网络的信令流量，并且也是掉话的隐患。
因此处理好切换关系，减少切换失败的任务是优化工作非常重要的一项环节。
在这一章里我们将从路测角度结合实例来分析日常工作中会遇到的切换失败的现象，并分析造成各种现象的原因以及相应的处理办法。
总的来说，在遇到切换失败事件时首先应该从HO_FAILURE消息中查找切换失败的原因解释（Causevalue）,有些切换失败是可以直接查到切换失败原因的（可以详查GSM规范）。
但对于有些Cause value，如Cause value111（Protocol error，unspecified）、Cause value 3（Abnormal release，timer expired）等就无法定位具体原因。
对于这些情况，我们就应该再进一步的对信令流程、多种测量参数、统计报告以及测试现场的环境等进行综合的分析，从而进一步确定切换失败原因。
下面的大部分篇幅的分析解决办法都是基于这些无法定位具体原因的Cause value。
一、连续的切换失败测试中我们有时会遇到这样的情况：如图7所示，接连不断的出现切换失败，当测试工程师继续驱车向前行驶时，就可能导致拖带掉话。
从系统下行发送的Handover_Command消息中我们可以发现，目标小区都是同一个小区（或同一个基站的不同小区）。
此种现象一般都和基站或传输设备的时钟故障有关，但也有可能是同频同BISC的小区造成的。
二、单独出现的切换失败如上所述，面对连续的切换失败时，我们的目标比较明确，而且基本上都是与时钟等硬件有关，比较容易发现问题，也比较好解决。
而实际工作中，却存在着偶尔单独出现的切换失败现象。
出现这种现象的原因却是多种多样，我们在这一节中将针对不同的现象分析不同的原因，值得注意的是，虽然大多数单独出现的切换失败现象很相似，但通过对信令的分析（时间、帧号、信令内容等），就会找出切换失败的具体原因。
基于S1接口切换失败分析
基于S1接⼝切换失败分析基于S1接⼝切换失败分析2014-09-25⼀、概述⼴州LTE⽹络的S1切换性能从9⽉18⽇开始，出现HO Prepare Fail “切换出准备失败_⽬前侧准备失败”次数增加明显，总体切换成功率从98.9%恶化到98.5%左右。
失败切换的邻区关系，在⼩区和TAC维度存在聚类。
⼆、S1-Based Handover信令流程LTE⽹络S1接⼝的切换流程：源eNodeB决定进⾏基于S1的切换。
S1切换的原因可能是源eNodeB和⽬标eNodeB之间不存在X2连接，或者源eNodeB根据其他情况作出的判断。
源eNodeB向源MME发送Handover Required消息，其中Handover Type在此时是intra-LTE，TargetID 包含Target Cell ID和Target TAI两部分，源MME 可以根据⽬标TAI来选定合适的⽬标MME。
Direct Forwarding Path Avaliability ⽤来指⽰在源和eNodeB之间是否存在存在直接转发的路径还是需要进⾏Indirect Tunnel Forwarding。
源MME选定合适的⽬标MME，通过S10接⼝发送Forward Relocation Request 消息给⽬标MME。
⽬标MME选定相应的⽬标SGW，发送Create Session Request消息给⽬标SGW，消息中包含每个承载的上下⽂。
⽬标SGW 为数据承载分配上⾏GTP －U的地址和TEID值，返回Create Session Response消息给源MME。
⽬标MME发送Handover Request消息给⽬标eNodeB，其中包括要建⽴的EPS承载的列表等内容，每个EPS承载的信息包括SGW的地址，上⾏GTP－U的在SGW侧的TEID值，EPS 承载的QoS等。
⽬标eNodeB收到上述消息后会建⽴UE上下⽂，包括承载的信息，安全上下⽂等。
切换失败的信令分析
切换失败的信令分析在DT切换事件的分析过程中，对于切换失败的分析比较困难。
特别是1种失败原因为Unspecified的切换。
如图1中，在一次DT测试中，使用Nokia 6720手机测试，MS从900M小区切换到1800M小区，失败，原因值为Unspecified。
此次失败后1秒，再次向另外一个1800M小区切换成功。
图 1 DT中连续2次切换，1次成功、1次失败图仔细观察DT的信令过程，在信令时间上，MS在收到Handover Command后立刻发出了Handover Failure。
感觉上MS在收到切换命令后并没有做出任何切换动作而直接回复切换失败。
如图2所示。
图 2 切换命令和切换失败的信令及原因观察切换点周边频率的分配，并未发现明显的干扰。
这两次切换的切换命令中，除了频点的差异外，无其他差异。
如图3所示。
图 3 左边为失败的切换命令，右边为切换成功的切换命令从网络侧跟踪到的信令上，我们也能看出这种切换失败原因与其他切换失败原因之间的差异。
如图4。
图 4 Timer expired切换失败原因的信令流程（异步切换，服务小区和目标小区都在本BSC内）图 5 Unspecified切换失败原因的信令流程（异步切换，服务小区和目标小区都在本BSC内）图 6 正常的信令流程图比较图4、图5和图6的流程，可以发现：在图4Timer Expired切换失败流程中，可以判断UE有发起接入的动作，因为检测到上行的RA消息（有上行的Handover Detection消息），且UE有收到Physical Message（有上行的Establish Indication）。
在图5Unspecified切换失败流程中，小区没有收到Handover Detection消息。
在信令流程上判断是否有接入过程。
但从信令时间上看，下发切换命令时间在720，收到Handover Failure在890，间隔仅仅170ms，折算为TDMA复帧，仅为36.8个。
GSM路测中连续切换失败的案例分析
表 1 切换失败/成功的Layer2&Layer3的信令流程
案例3 案例 由于断站造成服务小区的相邻基站同 频同BSIC
故障原因:由于断站造成相邻基站同频 故障原因: 同BSIC的切换失败,断站恢复工作后, BSIC 状况消失.
结束语
道路测试中切换失败是比较复杂的问题,若切换 失败发生较频繁会影响用户的感受,在日常的测试优 化中,要引起优化人员的足够重视.造成道路测试中 出现连续切换失败的原因还很多,本文只是从几个具 体的案例角度来介绍了可能的原因,与大家讨论.
案例2 化工研究院时钟失锁
现象:无法切入该站任何一个小区,经空闲状态下重选到该站后, 又无法切出至周围任何一个小区.
案例2 化工研究院时钟失锁
案例2 化工研究院时钟失锁
案例2 化工研究院时钟失锁
原因分析:先查看HO_Failure的Cause Value=111.再根据切换失败现象怀疑为 时钟硬件问题,查看硬件告警发现该站 时钟失锁.经过更换硬件,问题解决.
�
可能的原因
传输设备或基站的时钟故障 也有可能是由于存在同频同BISC的相邻 小区造成的.
案例 1 目的小区的时钟失锁
案例 1 目的小区的时钟失锁
案例 1 目的小区的时钟失锁
故障原因:先从Handover Failure的Cause 故障原因: Value入手(图4),在发现是无法具体定位原 因的Cause111后,再通过对目标小区'731医 院'的告警分析,发现该站的时钟失锁,需更 换时钟硬件. 更换时钟后,手机能够正常切换到基站'731 医院'上,原来的连续切换失败的情况得到了 解决.
案例3 案例 由于断站造成服务小区的相邻基站同 频同BSIC 现象:在路测过程中,主被叫手机突 现象: 然出现莫名其妙的连续的切换失败. 从现象上看很像是时钟问题,但经检 查并无基站有时钟告警.
系统间切换失败分析思路
系统间切换失败分析思路目录一、T网状况清查 (3)二、双网参数设置 (3)三、G网问题清查 (4)四、切换信令的分析 (4)五、终端问题排查 (6)系统间切换涉及到TD和GSM两个网络，所以考虑的因素很多,更容易因为参数的变动出现问题，需要有清晰的思路和全面的筛查。
首先理论上说，应该尽量保证用户占用T网，减少系统间切换的次数，按照系统间切换的“三新”标准，发起系统间切换请求，在通常情况下都必定是T网弱场。
因此思路大体上应该是，首先清查T网状况，其次清查涉及到双网的参数配置，然后清查G网问题，仍然无法定位查看信令，最后根据情况排查终端问题。
一、T网状况清查1.TD侧设备告警及故障查看当小区被监控为系统间切换最差小区及异常话务工单后，首先，要查看源小区是否存在设备故障、告警、干扰等情况，如存在告警等情况，并确认是否对业务造成影响，如：小区退服、小区闪断、公共信道建立异常、NCP链路不可用或所有CCP 链路不可用、E1链路不可用等告警信息。
2.TD网络无线环境(1）根据之前对该地无线环境的了解，也可以咨询片区的前台测试人员，判断该弱场是可修复、暂时未修复、不可修复的。
可修复：可以通过调整天线解决的；暂时未修复：覆盖空洞，已经提交补点申请，尚未完工。
不可修复：由于地形复杂造成的居民区无法深入覆盖或者高建筑阻挡。
（2）通过后台查看小区配置的PCCPCH功率，是否功率设置过小导致小区内存在弱场。
二、双网参数设置在TD侧、GSM侧小区都正常的情况下，可以从以下几个方面考虑：1、2/3G切换开关检查首先检查2/3切换功能开关是否打开，避免因切换开关未打开造成切换失败；2、2G外部小区参数核查对GSM邻区进行参数核查，查看邻区中是否存在同频同色现象，因为UE对GSM 区测量是以小区BCCH频点+NCC+BCC标识小区的，亦会有同频同色码造成错误选择目标小区的可能；3、3A事件参数调整对TD侧3A事件相关测量参数进行适当的调整（如：本RA T频率质量门限（ThresholdOwnSystem）、异RAT频率质量门限（ThresholdOthSys）、值迟滞（Hysteresis）、时间迟滞（TimeToTrigger）），然后通过前台复测观察，调整后效果有没有好转。
Iurg切换失败流程排查
Iurg切换失败流程排查————————————————————————————————作者：————————————————————————————————日期：双方对采集信令分析如下：1、RNC侧向CN发送的RelocationRequired消息中，根据协议规定在Old BSS to New BSS信息中包含了D-RNTI字段，与BSC发给ＲＮＣ的Enhanced Relocation ResourceRespond消息中携带的D-RNTI值一致（过程中涉及十进制和十六进制转换），如下：2、查看CN侧与RNC侧的交互信息，可看到CN侧收到RNC中的字段信息无误，如下图：3、查看CN与BSC信息交互过程中，CN接收到Relocation Required消息后向BSC 发送Handover Request，按协议要求该“Handover Request”消息中同样必须携带Old BSS to New BSS信息，并在该信息中包含该D-RNTI字段。
但是目前看到的所有切换流程中CN发给BSC的Handover Request消息中都缺少该条字段，导致BSC一直处于等待状态（BSC会一直等待包含该字段的Handover Request消息），超过2 S后BSC释放资源，导致切换失败。
1）BSC A接口采集的收到CN的handover Request信令如下图（缺少该字段）。
2）CN侧采集到的CN发出的Handover Request消息（同样缺少该字段）如下附件是RNC与CN交互信令、BSC与CN交互的信令。
4、下文为集团Iur-g规范中关于切换流程的说明：引入Iur-g接口后，在标准2/3G语音切换流程基础上新增无线资源预留流程，由RNC与BSC直接交互，提前完成原本需要核心网转发的资源预留过程。
Iur-g+流程只适用于CS切换，PS切换还是传统切换流程。
•Iur-g+流程SRNC BSCUE CN 1：MEASUREMENT REPORT 2：ENHANCED RELOCATION RESOURCE REQUEST3：ENHANCED RELOCATION RESOURCE RESPONSE5： RELOCATION REQUIRED4：HANDOVER FROM UTRAN COMMAND 6：HANDOVER REQUEST7：HANDOVER REQUEST ACKNOWLEDGE 8：RELOCATION COMMAND 12： HANDOVER COMPLETE11：HANDOVER DETECT13：HANDOVER COMPLETE 14：IU RELEASE COMMAND15：IU RELEASE COMPLETE NODE B16：RADIO LINK DELETION REQUEST17：RADIO LINK DELETION REPONSE10： HANDOVER ACCESS9：RELOCATION COMMIT空口缓发定时器T图2-3 基于Iur-g+接口的切换流程1） RNC 收到UE 的测量报告，结合GSM 邻区的小区容量和负荷信息，确定向某个邻接的GSM 小区进行切换。
切换Path switch和TAU流程冲突导致切换失败问题分析
切换Path switch和TAU流程冲突导致切换失败问题分析问题描述：C国Z省，一线反馈TE站点新桥阳岙向西岙底站点切换经常出现失败。
分析定位过程：1、分析该新桥阳岙站点的CHR日志，通过专家系统分析，发现切换失败的原因全是UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL；2、根据CHR日志分析具体的切换信令流程，找到切换失败的具体点；1）找到失败原因在CHR中记录失败的时间点2）分析SigInfoLst最后记录的消息流程，发现X2切换流程在源侧已经全部执行完毕，可推测出应该是在目标侧西岙底发起随机接入或者path switch失败导致切换失败。
3、因path switch流程涉及到和MME的交互，因此建议一线复测，并做目标侧S1口和UU口信令跟踪。
通过一线反馈的S1口信令跟踪发现Path Switch失败。
同时，分析目标侧的Debug日志也确认到目标侧等待path switch超时。
对于目标侧eNodeB来说，不论MME回path switch fail还是没有响应path switch req，eNodeB都统一按照path switch ack超时处理。
4、联合MME同时分析path switch fail原因从path switch fail的原因值handover cancel分析，是由于X2切换流程与其他流程冲突导致。
5、MME侧做随机用户跟踪，并进一步分析冲突原因从跟踪上可以看到path switch和TAU流程冲突。
MME目前的实现是：当MME正处在处理终端的TAU流程的中间状态时收到了eNodeB发来的path switch req消息，除了正在等待TAU Complete消息状态下会处理path switch流程，其他状态下均直接返回path switch fail。
另外，可以看到冲突的TAU流程发起了鉴权流程。
TAU流程中发起鉴权，增加了TAU流程的中间状态，也增加了TAU整个流程的时间，所以也增大了冲突的概率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
切换失败的信令分析
在DT切换事件的分析过程中，对于切换失败的分析比较困难。
特别是1种失败原因为Unspecified的切换。
如图1中，在一次DT测试中，使用Nokia 6720手机测试，MS从900M小区切换到1800M小区，失败，原因值为Unspecified。
此次失败后1秒，再次向另外一个1800M小区切换成功。
图 1 DT中连续2次切换，1次成功、1次失败图
仔细观察DT的信令过程，在信令时间上，MS在收到Handover Command后立刻发出了Handover Failure。
感觉上MS在收到切换命令后并没有做出任何切换动作而直接回复切换失败。
如图2所示。
图 2 切换命令和切换失败的信令及原因
观察切换点周边频率的分配，并未发现明显的干扰。
这两次切换的切换命令中，除了频点的差异外，无其他差异。
如图3所示。
图 3 左边为失败的切换命令，右边为切换成功的切换命令从网络侧跟踪到的信令上，我们也能看出这种切换失败原因与其他切换失败原因之间的差异。
如图4。
图 4 Timer expired切换失败原因的信令流程（异步切换，服务小区和目标小区都在本BSC内）
图 5 Unspecified切换失败原因的信令流程（异步切换，服务小区和目标小区都在本BSC内）
图 6 正常的信令流程图
比较图4、图5和图6的流程，可以发现：
在图4Timer Expired切换失败流程中，可以判断UE有发起接入的动作，因为检测到上行的RA消息（有上行的Handover Detection消息），且UE有收到Physical Message（有上行的Establish Indication）。
在图5Unspecified切换失败流程中，小区没有收到Handover Detection消息。
在信令流程上判断是否有接入过程。
但从信令时间上看，下发切换命令时间在720，收到Handover Failure在890，间隔仅仅170ms，折算为TDMA复帧，仅为36.8个。
这段时间根本无法在切换目标信道上有动作。
是收、发的时间间隔而已。
根据以上分析，原因值为Unspecified的切换失败过程，很可能与手机内部有关。