切换失败的信令分析
未接通、掉话及切换失败
未接通、掉话及切换失败分析一、未接通分析正常呼叫主叫起呼和被叫接入过程：主叫起呼信令流程图被叫接入信令流程图由主叫起呼信令流程图可以看出，主叫首先发出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口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
- 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的切换失败过程，很可能与手机内部有关。