切换失败原因分析
未接通、掉话及切换失败
未接通、掉话及切换失败分析一、未接通分析正常呼叫主叫起呼和被叫接入过程：主叫起呼信令流程图被叫接入信令流程图由主叫起呼信令流程图可以看出，主叫首先发出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信道消息的回复，导致未接通的发生。
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配置是否正确。
参数设置不合理导致ESRVCC切换失败分析
参数设置不合理导致ESRVCC切换失败分析参数设置合理与否是影响ESRVCC切换成功与否的一个重要因素。
ESRVCC切换失败可能由多种原因引起，包括网络质量不佳、设备兼容性问题、运营商网络配置错误等。
在这些问题之外，参数设置的不合理也可能导致ESRVCC切换失败。
接下来，我将详细分析参数设置不合理导致ESRVCC切换失败的可能原因。
首先，本地设备参数设置不合理可能导致ESRVCC切换失败。
在进行ESRVCC切换时，本地设备参数设置不合理可能导致切换信令的传输失败，从而导致切换失败。
例如，如果终端设备的参数设置中语音编解码器不支持ESRVCC切换所需的编码方式，就无法进行ESRVCC切换。
此外，如果终端设备的参数设置中配置的最大码率与网络允许的最大码率不一致，也可能导致ESRVCC切换失败。
其次，运营商网络参数设置不合理可能导致ESRVCC切换失败。
在进行ESRVCC切换时，运营商网络参数设置不合理可能导致切换信令在传输过程中出现错误或丢失，从而导致切换失败。
例如，运营商配置的切换触发门限值过低或过高，会导致切换过于频繁或无法触发切换。
此外，运营商网络中与ESRVCC切换相关的接口参数设置错误，也可能导致ESRVCC切换失败。
再次，网络质量差可能导致ESRVCC切换失败。
ESRVCC切换需要保证实时传输的语音数据在切换时的连续性和稳定性，而网络质量差会导致实时传输的语音数据在切换过程中出现丢包或延迟，从而导致切换失败。
例如，网络带宽不足、网络拥塞或网络抖动等问题都可能导致ESRVCC切换失败。
最后，设备之间的兼容性问题也可能导致ESRVCC切换失败。
ESRVCC切换是终端设备和运营商网络之间的一项复杂协作过程，如果设备之间的版本或配置兼容性存在问题，就可能导致切换失败。
例如，终端设备的硬件或固件版本过低或过高，无法与运营商网络进行正常的切换协商和协作，就会导致ESRVCC切换失败。
综上所述，参数设置的不合理可能导致ESRVCC切换失败。
切换异常的几种原因分析及排查
FpSAddReq
在目标小区建立无线链路及承载；
FpSAddRsp
RadioLinkSetupRequest
RadioLinkSetupResponse
FpSInitReq
FpSInitRsp
physicalChannelReconfiguration
网络侧向终端发起物理信道重配过程，定时时间内终端未发送物理信道重配完成消息，则等待终端上报小区更新；
1.1.2.5
1.信令截图：
2.原因分析及排查手段：
RNC在收到CN RAB指派后，UE上报一个测量报告，但此时RNC在处理CN RAB指派，无法同时处理测量报告，RNC缓存此条测量报告，等RAB指派完成后，在发起切换过程，由于此案例中测量报告中的目标小区来自邻RNC，因此发起了重定位流程。
1.2
1.2.1
IuReleaseComplete
原因分析及排查
根据S侧Relocation Preparation Failure消息或Relocation Failure消息中的错误码，参考非标准原因错误码对应表中说明，进行排查；
1.2.2.2
异常描述
原因分析及排查手段：
可能原因为：
UE未收到CONFIRM消息（下行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
排查方法：
信令过程
由于比较难于搜集同一次跨RNC切换异常过程中S侧和D侧的信令，因此本部分未以截图的形式给出行令流程。
切换失败原因分析
（2）对OMC的统计信息进行分析来发现不正常的原因。基站切换失败偏高，有时在MSC及BSC中并无告警信息，这时可以通过对OMC中的数据进行分析来发现问题。通过对OMC中的数据进行分析，可以发现某些基站存在的隐性问题（如TRX、RTX等的隐性障碍，天线等硬件问题），从而找出问题之所在，达到网络优化的目的。
当失败率高涉及到切换问题时，应抓住切换及切换失败的原因作为突破点，进而找出解决问题的办法。一般而言，由于切换是在小区及基站之间发生的，因此本小区的失败有可能是因为与相邻小区之间的切换设置不合理造成的。如果是这种原因，则应及时修改切换参数，同时需要检查小区周围是否有盲区存在；如果是由于网络存在漏覆盖区或盲区而导致的切换失败，则可以通过增加新基站或扩大原有基站的覆盖范围予以解决；对于因频率设置不合理而导致的切换失败，可根据实测情况适当修改小区的频率参数；对于那些由于话务量不均衡，使忙时因目标基站无空闲信道而产生的切换失败，可以根据实际话务量的情况，通过修改或增加基站配置或者扩大原有基站的覆盖范围等办法予以解决。???
301946788DL3Physical_InfoTA=114'48"11.91
311946801DL3Physical_InfoTA=114'48"11.97
322364314UL3HO_Failure14'48"11.99
332364323UL2SABM-CMD14'48"12.04
5-4切换成功率低问题分析
5-4切换成功率低问题分析从整网指标看没有明显的TOP小区特征，SA商用早期用户较少，每个小区失败次数都较少，但由于分母切换准备次数也不多，少数的几次失败对指标影响也较大。
对失败次数靠前的TOP小区进行分析，主要存在以下几个问题：(1) 5-4邻区漏配从标口信令跟踪可以看到大量上报MR测量报告但却不切换的情况，根据measId 查到相应的频点，这些4G小区存在邻区漏配的情况，导致不能及时切换，5G信号持续恶化切换到信号更差的4G小区时切换失败。
从日志上看也可以看到大量因无邻区导致无法切换的记录。
对全网的5-4漏配邻区进行核查，减少漏配邻区对切换成功率的影响。
从信令跟踪结果看，在5G覆盖边缘区域有很多距离较远的4G邻区测量报告上报未处理，可以考虑在核查邻区时郊区5G站点增大核查距离。
(2) 4G小区PCI复用距离过短4G PCI复用距离过短会导致在切换的时候由于PCI混淆，导致基站在执行阶段可能会下发错误的小区信息给终端，导致切换失败。
典型信令如下图所示，从抓取到的信令如下图所示，测量上报的小区与最终测量切换命令里的小区不一样。
这种情况下需要先重新规划4G PCI，同步更新5G侧的外部小区数据。
(3) 5-4外部小区参数不一致通过GC核查发现存在部分小区外部小区参数配置错误的情况，多数为PCI或者频点配置错误的情况，在往外部小区参数配置错误的邻区切换时会出现与邻区漏配类似的信令，终端上报测量报告基站却一直没有发起切换。
当前5G ANR还没有终端支持，不能用4G那种添加虚假邻区的方法来识别是否邻区添加错误，当前只能手动核实5G侧配置的邻区信息是否与4G侧一致(4) 4G质差导致切换失败4G信号质差容易导致手机在4G接入阶段出现问题，如下图信令，RSRP为-104，但SINR较差已经到-4了，4G质差容易导致信令不能正确解调导致切换失败。
(5) TOP终端4G随机接入失败除此之外网络中还发现大量4G信号条件很好，邻区也都没有问题但依然失败的情况。
切换异常的几种原因分析及排查
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.原因分析及排查手段：
切换失败原因和越区切换
切换失败原因和越区切换切换失败的原因主要有：1、硬件故障。
这是⾸先要与BSC确认的，检查有⽆告警信息。
2、切换参数设置有误或不合理。
3、切换⽬标⼩区有⼲扰。
4、邻区关系设置不合理，有漏配邻区等情况。
5、切换⽬标⼩区拥塞。
在路测中，我遇到的⼀般都是某⼩区越区覆盖、邻区不全导致的切换失败，和⽬标⼩区频点有⼲扰导致的切换失败。
遇见切换失败问题:1、⾸先查看是否⽤硬件告警，排除硬件问题导致的切换失败。
⽐如载频板故障，会导致⼊切换成率差。
2、查看⼩区数据配置。
⽐如定时器、⼩区切换磁滞和PBGT门限是否合理、邻区关系是否做全、如果是BSC间切换那么还要查看外部邻区数据中LAC CI BCCH BSIC 设置是否正确。
3、查看⼩区⼲扰带测量，排除是否有同频甚⾄同主B同BSIC码的现象。
4、现场环境是否弱覆盖现象，弱覆盖也容易造成切换失败。
5、时钟故障。
会导致MSC间切换失败。
6、孤岛效应导致切换失败。
7、上下⾏不平衡导致切换失败越区覆盖本词条主要介绍越区覆盖越区覆盖：由于基站天线挂⾼过⾼或者俯仰⾓过⼩引起的该⼩区覆盖距离过远，从⽽越区覆盖到其他站点覆盖的区域，并且在该区域⼿机接收到的信号电平较好。
⼀、导致越区覆盖的原因⾸先在⽹络规划过程中，应结合基站站址的间距，周围的地物地形数据进⾏基站的天线挂⾼、⽅向⾓、倾⾓、发射功率等参数的设计。
因对某些基站周围的地形地物的情况⽋了解，⽽盲⽬进⾏⼀些参数的设计，⽐如天线设计不合理，这便会产⽣远端越区覆盖情况。
特别是⼀些沿道路⽅向发射信号的⼩区，⼜或者江河两岸，⽆线传播环境良好，更有可能产⽣这种越区覆盖问题。
其次各地⽹络，建⽹初期存在⼤功率⼤覆盖的基站，天线过⾼，覆盖距离过远，本⾝就会有越区覆盖的情况。
在经过数期扩容后，增加了不少覆盖扇区，初期基站天线的⾼度应该适当降低，否则对周围基站扇区产⽣⼲扰，同时也会产⽣越区覆盖。
还有⼀些是在⽹络优化过程中，调整天线倾⾓时，当机械下倾⾓度达到10度以上时，⽔平⽅向波形严重畸变，也容易产⽣越区覆盖。
G网中切换失败的原因
一、切换的定义及划分所谓切换，就是指当移动台在通话过程中从一个基站覆盖区移动到另一个基站覆盖区，或者由于外界干扰而造成通话质量下降时，必须改变原有的语音信道而转接到一条新的空闲语音信道上去，以继续保持通话的过程。
切换根据手机和基站测出的上下行电平质量和TA 值作为最基本的测量数据，根据切换判断算法和资源分配算法来决定是否应该切换和切向哪个小区。
切换是移动通信系统中一项非常重要的技术，切换失败会导致通话失败，影响网络的运行质量。
因此，切换成功率（包括切入和切出）是网络考核的一项重要指标，如何提高切换成功率、降低切换失败率是网络优化的重点工作之一。
根据不同的切换判决触发条件，切换可以分为紧急切换、负荷切换等5 类。
（1）紧急切换。
包括TA 过大紧急切换、质量差（BQ）紧急切换、快速电平下降紧急切换、干扰切换。
●TA 过大切换条件：服务小区的TA 大于等于紧急切换TA 限制。
●BQ 切换条件：服务小区的上行链路质量在滤波器长度时间内平均值大于等于紧急切换上行链路质量限制；服务小区的下行链路质量在滤波器长度时间内平均值大于等于紧急切换下行链路质量限制。
●快速电平下降切换在呼叫中电平突然下降时触发，触发条件：服务小区如果Value＞B（Value：一个与滤波器参数A1～A8 相关的值，该值表示在一段时间内接收电平的变化趋势；B：滤波器参数）切换最后的MR6 已经低于边缘切换门限，则发生切换。
●干扰切换：也属于紧急切换，当接收电平大于一定值但传输质量又低于干扰切换质量门限时触发。
（2）负荷切换。
负荷切换触发要同时满足三个条件：系统信令流量小于允许负荷切换系统流量级别门限；需要切换的小区负荷高于负荷切换启动门限；接收切换的小区的负荷低于负荷切换接收门限。
（3）正常切换。
包括边缘切换、分层分级切换和PBGT 切换。
●边缘切换条件：服务小区已低于边缘切换门限；在边缘切换统计时间（如5 s）内，服务小区电平持续低于边缘切换门限（如4 s）。
切换失败原因分析
一、切换的定义及划分所谓切换,就是指当移动台在通话过程中从一个基站覆盖区移动到另一个基站覆盖区,或者由于外界干扰而造成通话质量下降时,必须改变原有的语音信道而转接到一条新的空闲语音信道上去,以继续保持通话的过程; 切换根据手机和基站测出的上下行电平质量和TA值作为最基本的测量数据,根据切换判断算法和资源分配算法来决定是否应该切换和切向哪个小区;切换是移动通信系统中一项非常重要的技术,切换失败会导致通话失败,影响网络的运行质量;因此,切换成功率包括切入和切出是网络考核的一项重要指标,如何提高切换成功率、降低切换失败率是网络优化的重点工作之一;根据不同的切换判决触发条件,切换可以分为紧急切换、负荷切换等5类;1紧急切换;包括TA过大紧急切换、质量差BQ紧急切换、电平下降紧急切换、干扰切换;●TA过大切换条件：服务小区的TA大于等于紧急切换TA限制;●BQ切换条件：服务小区的上行链路质量在滤波器长度时间内平均值大于等于紧急切换上行链路质量限制；服务小区的下行链路质量在滤波器长度时间内平均值大于等于紧急切换下行链路质量限制;●快速电平下降切换在呼叫中电平突然下降时触发,触发条件：服务小区如果Value＞BValue：一个与滤波器参数A1～A8相关的值,该值表示在一段时间内接收电平的变化趋势；B：滤波器参数切换最后的MR6已经低于边缘切换门限,则发生切换;●干扰切换：也属于紧急切换,当接收电平大于一定值但传输质量又低于干扰切换质量门限时触发;2负荷切换;负荷切换触发要同时满足三个条件：系统信令流量小于允许负荷切换系统流量级别门限；需要切换的小区负荷高于负荷切换启动门限；接收切换的小区的负荷低于负荷切换接收门限;3正常切换;包括边缘切换、分层分级切换和PBGT切换;●边缘切换条件：服务小区已低于边缘切换门限；在边缘切换统计时间如5 s内,服务小区电平持续低于边缘切换门限如4 s;●分层分级切换：在不同层或同层不同优先级之间才有层间切换,同层同级之间没有层间切换;触发条件是邻小区电平值高于层间切换门限和磁滞之和,对服务小区电平值没有要求；邻区排在服务小区之前,且优先级比服务小区更高,邻区电平值大于等于层间切换门限和层间切换磁滞之和；满足P/N判决,如5 s内有4 s始终处于最好；边缘切换和层间切换只能选一个,它先判断是否触发边缘切换,再判断是否触发层间切换;●PBGT切换算法是基于路径损耗的切换;PBGT切换算法实时地寻找是否存在一个路径损耗更小并且满足一定系统要求的小区,并判断是否需要进行切换;不同层没有PBGT切换;PBGT切换至少带来了如下好处：解决了越区覆盖问题；减少了双频切换的次数；使话务引导和控制有更灵活的手段；始终能为用户提供当前最好的服务质量;PBGT和其他切换算法的最大区别在于它能以路径损耗而不是接收功率作为切换的触发条件;为了避免乒乓切换,PBGT只在同层同级的小区之间进行切换,邻近小区的路径损耗小于服务小区路径损耗一定的门限值;PBGT切换的触发准则：邻区排在服务小区之前,在一定的统计时间内满足P/N准则;4速度敏感性切换快速移动切换;在一定时间门限里达到快速移动小区实际个数时,认为是快速移动,就会切换到宏小区上去第4层,并且对原有小区在惩罚时间里给予电平惩罚;5同心圆切换;可以实现外圆的广覆盖和内圆的频率紧密复用,能够提高系统容量和通话质量;可以根据手机下行接收电平、质量和TA值来区分内圆和外圆;同心圆切换的相关参数如下：●内外圆信号强度差异dB：内圆进行功率补偿的值;●接收电平门限dB m：与接收电平磁滞、TA门限、TA磁滞共同决定内外圆区域,必须大于边缘切换门限值;●接收电平磁滞dB：与接收电平门限、TA门限、TA磁滞共同决定内外圆区域;●TA门限：与接收电平门限、接收电平磁滞、TA磁滞共同决定内外圆区域,必须大于TA紧急切换门限值;●TA磁滞：与接收电平门限、接收电平磁滞、TA门限共同决定内外圆区域;●同心圆切换统计时间s：同心圆切换也需要满足P/N判决,建议取5 s;●同心圆切换持续时间s：P/N判决持续时间,建议取4 s;二、切换失败的原因分析切换失败引起掉话的原因虽然比较复杂,但只要能对整个切换过程有一个完整的、正确的认识,问题就不难解决了;一般,我们可以通过以下三个步骤进行分析：1从MSC、BSC告警中获得网络不正常的信息;在因相邻小区数据配置有误或邻区的BCCH、BCC基站收发台色码、LAC位置区码等设置不对而造成切换失败掉话时,都会在MSC及BSC中产生相应的告警;因此,可以应该经常查看MSC、BSC中的告警记录,找出问题存在的原因;2对OMC的统计信息进行分析来发现不正常的原因;基站切换失败偏高,有时在MSC及BSC中并无告警信息,这时可以通过对OMC中的数据进行分析来发现问题;通过对OMC中的数据进行分析,可以发现某些基站存在的隐性问题如TRX、RTX等的隐性障碍,天线等硬件问题,从而找出问题之所在,达到网络优化的目的;3借助无线场强测试仪的测试来判断切换失败的原因;在一般情况下,应该对目标小区周边进行较大范围的测试,通过实地路测,可获得基站的覆盖情况及切换情况,从而得到某些OMC所不能提供的信息;在实测时,特别要把那些与目标小区有切换拓扑关系而拥塞率又较高的小区作为测试的重点,然后通过对测试结果的分析,判断切换失败的原因,从而找出解决问题的办法;当失败率高涉及到切换问题时,应抓住切换及切换失败的原因作为突破点,进而找出解决问题的办法;一般而言,由于切换是在小区及基站之间发生的,因此本小区的失败有可能是因为与相邻小区之间的切换设置不合理造成的;如果是这种原因,则应及时修改切换参数,同时需要检查小区周围是否有盲区存在；如果是由于网络存在漏覆盖区或盲区而导致的切换失败,则可以通过增加新基站或扩大原有基站的覆盖范围予以解决；对于因频率设置不合理而导致的切换失败,可根据实测情况适当修改小区的频率参数；对于那些由于话务量不均衡,使忙时因目标基站无空闲信道而产生的切换失败,可以根据实际话务量的情况,通过修改或增加基站配置或者扩大原有基站的覆盖范围等办法予以解决;下面从角度来分析日常工作中会遇到的切换失败的现象,并分析造成各种现象的原因以及相应的处理办法;总的来说,在遇到切换失败事件时首先应该从HO_FAILURE消息中查找切换失败的原因解释Cause value,有些切换失败是可以直接查到切换失败原因的可以详查GSM规范;但对于有些Cause value,如Cause value111Protocolerror,unspecified、Cause value 3Abnormal release,timer expired等就无法定位具体原因;对于这些情况,我们就应该再进一步的对信令流程、多种测量参数、统计报告以及测试现场的环境等进行综合的分析,从而进一步确定切换失败原因;下面的大部分篇幅的分析解决办法都是基于这些无法定位具体原因的Cause value;①、连续的切换失败测试中我们有时会遇到这样的情况：接连不断的出现切换失败,当测试工程师继续驱车向前行驶时,就可能导致拖带掉话;从系统下行发送的Handover_Command 消息中我们可以发现,目标小区都是同一个小区或同一个基站的不同小区;此种现象一般都和基站或传输设备的时钟故障有关,但也有可能是同频同BISC的小区造成的;②、单独出现的切换失败如上所述,面对连续的切换失败时,我们的目标比较明确,而且基本上都是与时钟等硬件有关,比较容易发现问题,也比较好解决;而实际工作中,却存在着偶尔单独出现的切换失败现象;出现这种现象的原因却是多种多样,我们在这一节中将针对不同的现象分析不同的原因,值得注意的是,虽然大多数单独出现的切换失败现象很相似,但通过对信令的分析时间、帧号、信令内容等,就会找出切换失败的具体原因;带着这个思路我们来看下面的;1连续多个下行Physical Information,超过系统设置造成失败实例：马家堡DCS1现象：从Handover_Command到系统下行发第一个Physical Information正常,因此认为切换成功,发送HO_Complete消息;但1.05秒后又上行发送HandoverFailure消息;分析：首先看Handover Failure中的Cause Value=111Protocol error,unspecified无法证实具体失败原因;随后再对该地区的频率规划进行了核查,未发现有频率干扰;在OMC端也未发现传输和基站硬件的告警信息;但在2层消息中我们可以看出,从Handover_Access后上行发送的SABM消息一直没有得到UA_RSP消息的响应,造成LAPDm信令重发T200×N200＋1超时,致使切换失败;Layer2&Layer3信令流程如下FrameNO. UL/DL Layer Message Type Info in Message Time1 2364048 DL2 I-CMD HO_Command 14'48"10.942 2364049 DL3 HO_Command 14'48"10.943 1946551 UL 2 RR-RSP 14'48"10.804 1946555 UL 3 HO_Access 14'48"10.835 1946580 DL 3 Physical_Info TA=1 14'48"10.946 1946580 UL 3 HO_Complete 14'48"10.947 1946582 UL 2 SABM-CMD 14'48"10.958 1946593 DL 3 Physical_Info TA=1 14'48"11.009 1946606 DL 3 Physical_Info TA=1 14'48"11.0610 1946619 DL 3 Physical_Info TA=1 14'48"11.1311 1946621 UL 2 SABM-CMD 14'48"11.1312 1946632 DL 3 Physical_Info TA=1 14'48"11.1913 1946645 DL 3 Physical_Info TA=1 14'48"11.2514 1946658 DL 3 Physical_Info TA=1 14'48"11.3115 1946660 UL 2 SABM-CMD 14'48"11.3216 1946671 DL 3 Physical_Info TA=1 14'48"11.3717 1946684 DL 3 Physical_Info TA=1 14'48"11.4318 1946697 DL 3 Physical_Info TA=1 14'48"11.4919 1946699 UL 2 SABM-CMD 14'48"11.5020 1946710 DL 3 Physical_Info TA=1 14'48"11.5521 1946723 DL 3 Physical_Info TA=1 14'48"11.6122 1946729 DL 3 System_Infor_6 14'48"11.6423 1946736 DL 3 Physical_Info TA=1 14'48"11.6724 1946738 UL 2 SABM-CMD 14'48"11.6825 1946739 UL 3 MR null 14'48"11.6826 1946749 DL 3 Physical_Info TA=1 14'48"11.7327 1946762 DL 3 Physical_Info TA=1 14'48"11.7928 1946775 DL 3 Physical_Info TA=1 14'48"11.8529 1946777 UL 2 SABM-CMD 14'48"11.8630 1946788 DL 3 Physical_Info TA=1 14'48"11.9131 1946801 DL 3 Physical_Info TA=1 14'48"11.9732 2364314 UL 3 HO_Failure 14'48"11.9933 2364323 UL 2 SABM-CMD 14'48"12.0434 2364347 DL 2 UA-RSP 14'48"12.1535 2364349 UL 2 I-CMD HO_Failure 14'48"12.16我们发现该小区的呼叫成功率和切换成功率均很低,怀疑为硬件有问题;在对硬件模块和天线的驻波比等参数进行检测未发现问题后,经过更换信道盘后该问题解决;说明是CTU中某些功能模块出现故障; 该案例说明,在实际工作中的任何时候,我们都不能忽略硬件问题,尤其是在没有发现硬件告警的情况下,更需要通过超过常规手段的新办法来发现硬件问题;这样,除了能解决眼前的问题以外,还能为发现网络深层次问题和发现问题的新思路积累经验;2无下行physical informationA．同站不同小区之间将Synchronized Indicator置为True;实例：北太平庄路口DCS现象：测试工程师在北三环自西向东行驶,占用小区31047,随着继续行驶,TA已经达到3,这时服务小区的覆盖电平已经降到－8xdBm,Quality也达到4、5级,但邻区覆盖电平并不高;后系统令手机向同站的31048发出切换命令,但切换失败;分析：首先先看Handover_failure中的CauseValue＝111;再分析信令流程：从HO_Access到HO_Complete之间无任何信令,原因是同站不同小区之间我们在邻区设置时,将默认同步值设为True,因此,在切换时系统不会下行发送Physical Information,而手机在发送HO_Acces后也不会等待下行消息,不会触发T3124;如下表：FrameNO. UL/DL Layer Message Type Info in Message Time 1 1707367 DL 2 I-CMD HO_command 15'39"12.622 1707370 UL 2 RR-RSP 15'39"12.643 1707372 DL 3 HO_Command 15'39"12.654 1707387 UL 3HO_Access 15'39"12.715 1707391 UL 3 HO_Complete 15'39"12.736 1707396 UL 2 SABM-CMD15'39"12.767 1707435 UL 2 SABM-CMD 15'39"12.948 1707474 UL 2 SABM-CMD 15'39"13.129 1707514 UL 2 SABM-CMD 15'39"13.3010 1707544 DL 2 DM-RSP SAPI=3 15'39"13.4411 1707552 UL 2 SABM-CMD 15'39"13.4812 1707593 UL 2 SABM-CMD 15'39"13.6713 1707656 UL 3 HO_Failure 15'39"13.9614 1707663 UL 2 SABM-CMD 15'39"13.9915 1707692 DL 2 UA-RSP 15'39"14.1216 1707694 UL 2 I-CMD HOF 15'39"14.1317 1707718 DL 2 RR-RSP 15'39"14.2418 1708634 DL 2 DM-RSP SAPI=3 15'39"18.47但是为什么最后还是切换失败了呢仔细研究2层消息,手机连续发送6条SABM消息,等待接收UA-RSP的连接确认消息,造成Um接口的LAPDm协议上的T200×N200＋1超时是切换失败的原因;经过核查邻区关系,我们发现小区31047缺少东边一些相邻的邻区,造成只能回切至自己本站的2小区的现象,但由于距离太远,已经无法收到下行或上行的消息,造成了切换失败;故障解决：加上适当邻区后该问题解决;我们在下面的注解中将刚才提到的有关同步/非同步切换所涉及到的计时器介绍一下：注：设置小区同步切换对切换流程的影响在邻区关系设为Non_Synchronized时,手机在发送HO_Access同时会启动T3124,在这个计时器期间未收到下行的Physical Information,便认为切换失败；收到Physical Information后T3124自动停止,这时会上行发送Layer 2 SABM消息,启动LAPDm的T200和N200计时器,在T200×N200＋1时间内未收到下行的UA-RSP的确认消息就会发送切换失败消息;在邻区关系设为Synchronized时,手机不会启动T3124计时器步骤,直接进入Layer2计时器阶段;B．小区之间将Synchronized Indicator置为False;在收到手机上报的HO_ACCESS消息后,从理论上基站是应该发出下行Physical Information的,但造成手机端未收到或未正确解码的原因有很多;这种情况下应当首先考虑硬件问题,比如信道盘、时钟、传输等;另外考虑是否有频率干扰的问题,由于干扰造成的上下行消息不能正确接受的影响范围很广,产生的原因也多种多样,所以有时不能单单从GI分析软件GSM Investigator,Motorola开发的优化工具等方法中发现带内干扰,例如可能由于邻区不全造成拖带,从而造成与远处基站的干扰等等,这就要视具体情况而定;3三层消息中出现HO_Complete后手机再上行发送HO_Failure消息实际上在GSM规范中没有此类的规定,仅在用TEMS测试中中发现此类现象;如果系统收到的手机上报的切换失败的消息后,会通知源小区进行拆线,空出原信道,这样手机切换失败后就不能回到原信道,从而造成切换掉话;但经过大量TEMS的路测文件的分析,并没有出现上述的切换掉话现象,从这个角度说,我们可以认为这是软件问题,实际上系统并没有收到切换成功的消息;至于软件问题的具体原因,Ericsson公司还没有给出正面的答复;实际我们可以参照第一种情况“连续多个下行Physical Information,超过系统设置造成失败”的解决办法;4其它可能出现的切换失败现象除了以上所介绍的几种常见的切换失败的类型外,我们还可能遇到一些其它不常见的切换失败,这些都是GSM规范中定义的切换失败类型,主要是系统设置出现问题,或手机不支持网络设置所致;A．超过目标小区的最大服务距离,Cause: “handover impossible, timing advance out of range”见GSM规范04.08在小区设置时,可以设置小区的最大服务距离,参数以TA为单位,最小可以设到0;该参数的目的有两个：1、控制小区用户起呼的范围,超过设置范围的用户将不能起呼；2、控制该小区的话务量,使得超过该小区设置范围的用户自动切出,另外“阻止”超过改设置范围的用户切入;这样在Handover Failure中的Cause: "handover impossible, timing advance out of range";在GSM 规范中规定在同步切换或预同步切换的时候,下行系统发送的HO_Command消息中包含了目标小区TA设置为多大,由于手机会以源小区的TA为基准向目标小区接入,当发现自己所用的TA值超过目标小区的限制时,便会立即上行发送HO_Falure消息,并且Cause: "handover impossible, timing advance out of range";B．Cause: “frequency not implemented”见GSM规范04.08如果切换失败原因为Cause "frequency not implemented"时,说明有以下两种可能：一种是手机不能调谐到HANDOVER COMMAND消息中所包含的频率上,例如单频手机不能切到其他频段上,但此类现象只有在交换机上设置参数错误或出现故障时才可能发生,因为系统是会根据手机的类别来有针对性的发出切换命令的；另外一种原因是手机在收到的包含有Frenquency List的字节中包含有不同频段的频点;以上两种情况手机就会立即直接发送HANDOVER FAILURE 消息,并保持使用原先的信道不变,返回系统的失败原因就是Cause "frequency not implemented";C．Cause: “channel mode unacceptable” 如果手机不支持HANDOVER COMMAND中提供的信道模式或者根本没有此类信道模式,手机就会立即发送HANDOVER FAILURE消息,并保持现有信道和信道模式;详见GSM规范04.08D．lower layer 信道建立失败造成切换失败此类现象在实际工作中从未遇到过,但是规范中有此类原因的切换失败;详见GSM规范04.08E．目标小区要求加密、VGCS等设置与源小区不同且在HO_Command 中没有提及的；见GSM规范04.085 Cause 3与Cause 111的对比在日常工作中,我们使用的测试设备有两大类,一类是Ericsson公司的TEMS 系列,这其中包括TEMS98,TEMS-Investigation2.0/3.0,TEMS-Automatic等；一类是NEMO公司的NEMO-TOM/SAM系列;由于双方软件设计的一些不同,一些方面需要引起大家注意;最主要的在于信令流程中的差异;TEMS中三层消息较全,另外还有二层消息,对于分析问题更加便利;相比而言TOM的三层消息就比较少,有些重复发送的例如系统消息和测量报告就不会纪录下来,另外还没有二层消息;另外,我们发现在Ho_Failure中的Cause Value中也有这不同的判断,这一般体现在不明原因的切换失败上,在TEMS中均为Cause111Protocol error,unspecified,而在TOM中则多为Cause3timer expired;因此,前文中Cause Value 不明原因的切换失败是基于TEMS的Cause111的,但在用TOM测试的分析中,遇到的Cause Value3也同样适用;。
切换失败事件层三信令详解
切换失败原因手机在通话中为了保证通话质量，经常会切换到能够提供更好服务的小区上去，如果移动的距离较长，则会发生多次切换的现象。
虽然切换失败不等同于掉话，但在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的小区造成的。
二、单独出现的切换失败如上所述，面对连续的切换失败时，我们的目标比较明确，而且基本上都是与时钟等硬件有关，比较容易发现问题，也比较好解决。
而实际工作中，却存在着偶尔单独出现的切换失败现象。
出现这种现象的原因却是多种多样，我们在这一节中将针对不同的现象分析不同的原因，值得注意的是，虽然大多数单独出现的切换失败现象很相似，但通过对信令的分析（时间、帧号、信令内容等），就会找出切换失败的具体原因。
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配置是否正确。
基于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上下⽂，包括承载的信息，安全上下⽂等。
切换异常的几种原因分析及排查共18页
名称：切换异常的几种原因分析及排查提交人：张鑫提交日期：2011-12-24软件版本：硬件版本：1.1 RNC内切换过程中的异常1.1.1 总体描述RNC内切换相关的异常主要有如下几种典型场景：物理信道重配失败：网络侧在下发physicalChannelReconfiguration消息后，终端回physicalChannelReconfigurationFailure消息，导致切换过程失败，此类异常影响RNC内切换成功率，但不会导致掉话；物理信道重配超时：网络侧在下发physicalChannelReconfiguration消息后，终端没有响应，网络侧等待一段时间后，终端仍然未上报cellUpdate，超时后释放，此类异常会同时影响切换成功率；小区更新后物理信道重配超时：网络侧在下发physicalChannelReconfiguration消息后，终端没有响应，网络侧等待一段时间后，终端上报cellUpdate，网络侧下发cellUpdateConfirm消息，终端响应超时后释放，此类异常会同时影响切换成功率；网络侧收到测量报告但未发起切换：网络侧收到终端上报的1G或2A测量报告，但未在目标小区发起无线链路建立过程，也未向终端下发physicalChannelReconfiguration，此类异常不会对KPI指标造成直接影响；1.1.2 典型信令过程1.1.2.1 物理信道重配失败1. 信令截图：第 1 页2. 信令分析：第 3 页原因分析及排查手段：查看PhysicalChannelReconfigurationFailure 中携带的失败原因，比如最常见的Failure cause 为physical channel failure ，表示UE 无法在建立新的物理信道，即UE 无法在新的信道配置上完成L1同步（UE 在T312时间内，收到N312个同步指示，即认为新的信道建立成功）。
切换成功率比较低的原因分析和优化调整
3．1 切换问题定位步骤 (1) 确定故障出现在个别小区还是所有小区；问题小区的特点。 (2) 如果是两小区间出现切换故障，则重点查看两个小区间的数据是否配置正确，
硬件是否有故障。
如果故障出现在某一个小区的所有邻近小区，则重点查看该小区的数据配置是否正 确，以及该小区的硬件是否有故障。
一、切换的基本概念及原因
切换（HANDOVER）是指 MS 在通话过程中，由于用户的移动或其它原因，从占用一 个无线信道到占用另一个无线信道的过程。切换是在 MS 占用 SDCCH 信道以后，也就是 MS 发起呼叫、短消息或通话过程中产生的。
切换过程分为两种，第一种为信令切换。比如手机用户在发送短消息的过程中发生的切 换就为信令切换。第二种为语音切换（语音或数据）。 比如手机用户在打电话的过程中发生 的切换就为语音切换，语音切换是用户使用手机过程中最为常见的一种切换现象。下面的内 容主要介绍语音切换。
一般来说引起切换失败的原因大致有以下几种：邻区数据错误、同频同色码、干扰、邻 区不合理、载频性能差、传输故障、链路不平、CMCF 板故障、硬件连接故障、直放站干扰 等。
3．2．1 邻区数据错误
在杭州项目的日常优化中此类问题也比较常见
临安广电大楼：
小区
日期
切换请求 TCH 话务量
次数
切换成功 次数
切换失败 数
二、切换流程
GSM 系统采用的是 MS 辅助切换方式，即由 MS 监测判决，由交换中心控制完成，在 切换过程中基站和 MS 均参与切换过程。
一般情况下，下面的两个原因将导致小区切换的发生： ¾ 邻小区提供更好的链路。 ¾ 当前的链路质量非常差，或者时间提前量太大，都将导致紧急切换。
2．1 切换失败问题
常见切换问题分析
ｆＥＥｃ术 ＭｓＨ研 Ａ ．Ａ学 ｃｃ Ｒ 究 Ａ 。Ｒ Ｅ
常见切换 问题分析
安 永 红 （ 中国移 动通信 集团河北有 限公 司唐 山分公 司 河北唐 山
０ ３０ ６ ０ ０）
摘要 ：对 日常工作 中切换 问题进 行分类 ，并对 常见的切换失败、乒乓切换及拐 角效应的原 因进行 分析 ，相应给 出优化建议。
来 ，形成较强越区孤岛。由于该 区域的小区和该越区小
区 之 间不 会 互 配 置邻 小 区 ，在 干 扰 没 有严 重 到导 致 下行 失 步 时 ，Ｕ 将 不 会 选 择 到 该 小 区 上 。 但 在 服 务 小 区信 Ｅ
会导致ＵＥ 会导致 源小区无法有效接收到ｕ 上报的测量 Ｅ 报告 ，从而 不进行切换。此时 ，系统侧应该有 “ 物理信
道 重 配 置 超 时 ”消 息 。 而ＵＥ 出 现 失 步 ，并 发 出 “ 会 小
号 较弱时 ，Ｕ 很可 能会重选到该越 区孤 岛上。 当在该 Ｅ 小区上通话 （ 建立其他 的ＤＰ Ｈ也是一样 ） ，将会导 Ｃ 后
致 无法 切 换 从 而掉 话 的现 象。 此 类 问题 在 切 换 指 标 上是 无 法显 示 出异 常 的 ，主 要表 现 为掉 话严 重 。
剧增强 ，会导致和 源小 区链路失步 ，网络侧无法接 收到
Ｕ 的测 量 报 告 ，从 而 存 在 切 换 失败 的现 象 。 Ｅ ４ 优 化 建 议 ． ２ ｆ１ 果 信 号 允 许 ，可 以通 过 调 整 工 程 参 数 （ 大 １如 加
３ 过程 。 哪 一 个 过 程 没 有及 时 执 行 都 会 导 致切 换 比较 个 慢 ，不及 时。
通 道 校 正 进 行 检 查 ，对 于 校 正 无 法 通 过 的需 要 及 时 处 理 ，必要 时 需要 更 换 系 统硬 件 设 备 。
处理切换失败经验总结报告
关于处理切换失败问题的经验总结在通话过程中，切换失败会对手机用户感受产生不良影响，严重时甚至会导致掉话。
在这里，我们通过路测以及对系统统计性能的跟踪，来分析引起切换失败的因素。
产生切换失败，一般有以下几方面原因：1、不合理的邻区关系。
2、基站时钟锁相失败。
3、基站硬件故障。
4、频率干扰产生大量无线链路误码。
5、弱覆盖。
下面将结合示例，分别对几种切换失败情况进行具体分析。
示例一：不合理的邻区关系，相邻小区同BCCH同BSIC。
测试车辆由东向西行驶过程中，手机占用25443小区向其邻区列表里BCCH=18， BSIC=28的小区连续切换失败。
通过检查25443的邻区数据，发现在其邻区列表里小区CI 20113 的BSIC=28，BCCH=18；而通过GI 分析，发现在车行驶的正前方，小区CI 20006与CI 20113有相同的BCCH 和BSIC 。
当车由东向西行驶时，测试手机在检测到BCCH=18并且 BSIC=28的小区为其最强邻区时，就尝试向其邻区列表里符合该条件的小区（CI 20113）切换，然而此时小区CI 20113距通话地点较远，且逆于行驶方向，于是产生连续的切换失败，而此时手机应该向车行使正前方的小区（CI 20006）切换。
因此解决方案为调整CI 20006或CI 20113的BSIC ，并为CI 25443添加邻区CI 20006。
经过调整，25443小区与20006切换正常，在这段道路没有出现切换失败的情况。
同BCCH 同BSIC25443行驶方向示例二：MCU（微控制器Micro Control Unit）故障导致基站时钟锁相失败（Phase Lock Failure），造成与周围小区切换成功率低。
在道路测试中，发现从CI 20323向CI 10350做切换，连续切换失败：在占用CI 10350正常起呼、通话后，向CI 20323尝试切换，也均失败。
从OMC_R上查看CI 10350基站告警，发现该站有时钟锁相失败，需要重新校准时钟。
切换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整个流程的时间，所以也增大了冲突的概率。
路测切换失败的原因分析及解决
目录第一章前言 (2)第二章切换流程分析 (5)一、小区内部切换（INTRA _CELL HANDOVER） (5)二、BSC内部小区间切换（INTRA_BSC HANDOVER） (6)三、MSC内部BSC间切换（INTRA MSC HANDOVER） (8)四、 MSC间切换 (11)第三章切换失败的原因分析 (13)一、连续的切换失败 (13)实例1 731医院的时钟失锁 (14)实例2 化工研究院时钟失锁 (17)实例3 沙沟DCS与东铁家坟DCS的同频同BSIC (18)注: LAPD和LAPDm中使用的帧类型以及它们的结构 (20)二、单独出现的切换失败 (21)1）连续多个下行Physical Information，超过系统设置造成失败 (22)实例：马家堡DCS1 (22)2）无下行physical information (23)A．同站不同小区之间将Synchronized Indicator置为True 23注：设置小区同步切换对切换流程的影响 (25)B．小区之间将Synchronized Indicator置为False (25)3）三层消息中出现HO_Complete后手机再上行发送HO_Failure消息 (25)4）其它可能出现的切换失败现象 (26)A．超过目标小区的最大服务距离，Cause: “handoverimpossible, timing advance out of range” (26)B．Cause: “frequency not implemented” (26)C．Cau se: “channel mode unacceptable” (27)D．lower layer 信道建立失败造成切换失败 (27)E．目标小区要求加密、VGCS等设置与源小区不同且在HO_Command中没有提及的 (27)5） Cause 3与Cause 111的对比 (27)结束语 (28)第一章前言在移动用户通话过程中为了使呼叫建立在最好的小区中以及为了使呼叫不至于掉话，就引入了切换的概念。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
切换失败原因分析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系统间切换应尽量选择在人口密度小的区域，减少切换次数，也避免了因处理能力不足而使信令交互延时或失败，最终导致掉话。
3、3G-2G切换的触发条件:1、如果是CPICH Ec/No触发了压缩模式，那么满足GSM小区RSSI > gsmThresh3a 并且CPICH Ec/No < usedFreqThresh2dEcno+utranRelThresh3aEcno - hysteresis3a/2门限的条件，并保持TimeToTrigger3a，将触发3G/2G切换。
2、如果是CPICH RSCP触发了压缩模式，那么满足GSM 小区RSSI > gsmThresh3a 并且CPICH RSCP < usedFreqThresh2dRscp+utranRelThresh3aRscp - hysteresis3a/2 门限的条件，并保持TimeToTrigger3a，将触发2G/3G切换。
3、如果是Ue Tx power触发了压缩模式，那么满足GSM小区RSSI > gsmThresh3a 并且CPICH RSCP < usedFreqThresh2dRscp+utranRelThresh3aRscp+utranRelThreshRscp附：切换信令流程软切换信令流程步骤：1. SRNC决定建立一条新的无线链路，该无线链路所属的新的小区由另一个RNC（DRNC）控制。
SRNC通过RNSAP向DRNC发送“Radio Link Setup Request”消息，请求DRNC准备相应的无线资源。
由于新的无线链路是UE同DRNC建立的第一条无线链路，于是建立新的Iur信令连接。
该Iur信令连接承载跟UE相关的RNSAP信令。
Radio Link Setup Request”消息包含的参数为：小区ID、TFS、TFCS、频率、上行扰码。
2. DRNC根据无线资源判定是否可以满足请求的无线资源要求，如果可以满足，DRNC 向属于它的Bode B发送NBAP消息——无线链路建立请求“Radio Link Setup Request”。
然后Node B启动上行接收。
“Radio Link Setup Request”消息包含的参数为：小区ID、TFS、TFCS、频率、上行扰码。
3. Node B按照要求分配无线资源，如果配置成功，Node B通过NBAP消息——无线链路建立响应“Radio Link Setup Response”向DRNC上报。
“Radio Link Setup Response”消息包含的参数为：信令终止，传输层寻址信息（AAL2寻址、用于数据传输承载的AAL2捆绑ID）4. DRNC通过RNSAP发送无线链路建立响应消息“Radio Link Setup Response”给SRNC。
“Radio Link Setup Response”消息包含的参数为：传输层寻址信息（AAL2寻址、用于数据传输承载的AAL2捆绑ID），邻近小区信息。
5. SRNC通过ALCAP协议启动Iur/Iub数据传输承载，该请求包含AAL2捆绑ID用于绑定Iub数据传输承载和DCH。
6./7. Node B 和SRNC通过交换相应的DCH FP帧“Downlink Synchronisation”和“Uplink Synchronisation”建立数据传输承载的同步。
Node B启动下行发送。
8. SRNC通过DCCH向UE发送激活集更新消息“Active Set Update”，该消息包含无线链路增加和删除内容。
参数：更新类型、小区ID、下行扰码、功率控制信息、邻近小区信息9. UE根据RRC信令配置相应参数后，去活要删除链路的下行接收，激活要增加链路的下行接收，并向SRNC发送RRC消息“Active Set Update Complete”。
10. SRNC向Node B发送NBAP消息消息无线链路删除请求“Radio Link Deletion Request”。
Node B停止接收和发送。
参数：小区ID、传输层寻址信息11. Node B去活无线资源，并向SRNC发送NBAP消息无线链路删除响应“Radio Link Deletion Response”。
12. SRNC通过ALCAP协议启动释放Iur/Iub数据承载。
硬切换信令流程步骤：1. SRNC向目标RNC发送无线链路建立请求消息“Radio Link Setup Request”。
参数：目标RNC标识符、s-RNTI、小区ID、TFS、TFCS。
2.目标RNC为RRC连接和无线链路分配RNTI和无线资源，并发送NBAP消息“无线链路建立请求（Radio Link Setup Request）”给目标Node B。
参数：小区ID、TFS、TFCS、频率、上行扰码、功率控制信息等。
3.目标Node B分配无线链路资源，启动物理层接收，并发送NBAP消息“无线链路建立响应（Radio Link Setup Response）”给目标RNC。
参数：信令终止、用于Iub数据传输承载的传输层寻址信息。
4.目标RNC用ALCAP协议启动Iub数据传输承载的建立。
该请求包含AAL2捆绑ID 用于绑定Iub数据传输承载和传输信道DCH，同时该请求由Node B确认。
5.当目标RNC完成准备过程，目标RNC发送“无线链路建立响应”给SRNC。
6. SRNC:用ALCAP协议启动Iur数据传输承载的建立。
该请求包含AAL2捆绑ID用于绑定Iur数据传输承载和传输信道DCH，同时该请求由目标RNC确认。
7. SRNC向UE发送RRC消息“物理信道重配置（Physical Channel Reconfiguration）”。
8. 当UE从旧的链路切换到新的链路时，源Node B检测到旧链路同步失败，发送NBAP消息“无线链路失败指示（Radio Link Failure Indication）”给源RNC。
9. 源RNC发RNSAP消息“无线链路失败指示（Radio Link Failure Indication）”给SRNC。
10.当与目标RNC的RRC连接建立并分配相应的无线资源后，UE发送RRC消息“物理信道重配置完成（Physical Channel Reconfiguration Complete）”给SRNC。
11. SRNC给源RNC发送RNSAP信令“无线链路删除请求（Radio Link Deletion Request）”给源RNC，要求源RNC释放相应的旧链路所用资源。
12. 源RNC给源Node B发送NBAP消息“无线链路删除请求”。
13. 源Node B释放旧链路无线资源，并向源RNC发送NBAP信令“无线链路删除响应（Radio Link Deletion Response）”。
14. 源RNC用ALCAP协议启动释放Iur数据传输承载。
15. 当源RNC完成释放Iur数据传输承载，发送RNSAP消息“无线链路删除响应”给SRNC。
用ALCAP协议启动Iur数据传输承载的释放。
该请求包含AAL2捆绑ID用于绑定Iur数据传输承载和传输信道DCH，同时该释放请求由目标RNC确认。
系统间的切换信令流程步骤：1.SRNC发送RANAP消息“重定位请求（Relocation Required）”给CN。
2.UMTS CN通过MAP/E接口将重定位请求转发给GSM MSC。
3.正常GSM信令处理过程，MSC通过BSSMAP给BSC发送消息“切换请求（Handover Request）”。
4.正常GSM信令处理过程，BSC通过BSSMAP给MSC发送消息“切换请求响应（Handover Request Ack）”。
5.GSM MSC/BSS完成初始过程，MSC发送MAP/E消息“准备切换响应（Prepare Handover Response）”给CN。
发送RANP A消息“重定位命令（Relocation Command）”给SRNC。
7.通过已有的RRC连接，SRNC发送RRC消息“HANDOVER FROM UTRAN COMMAND”给UE，实现系统间硬切换。
8.正常GSM信令处理过程，BSC通过BSSMAP给MSC发送消息“切换检测（Handover Detect）”。
9.正常GSM信令处理过程，UE给BSC发送“切换完成(Handover Complete)”消息。
10.正常GSM信令处理过程，BSC通过BSSMAP给MSC发送消息“切换完成（Handover Complete）”。
11.GSM检测到UE，MSC发送MAP/E消息“发送终止信号请求（Send End Signal Request）”给CN。