切换出准备失败问题分析
案例-目标小区回复切换准备失败案例
目标小区回复切换准备失败案例摘要：LTE系统内切换包括三种类型：eNodeB内切换、X2接口切换、S1接口切换。
本文主要针对现网中存在最多的一类原因目标小区回复切换准备失败TOP区域分析，并进行全网推广核查和总结经验。
关键字：eNodeB内切换 X2接口切换 S1接口切换目标小区回复切换准备失败【故障现象】：统计6月10日至6月16日一周指标发现，阜阳全网日均切换失败次数约17万次，切换准备阶段出现的切换出准备失败次数约1.5万次。
华为网管报表目前仅能统计到切换准备阶段的失败原因分类，执行阶段的失败原因分类暂无法统计。
切换准备阶段4类失败原因：核心网原因、源小区发送切换取消、目标小区回复切换准备失败、目标小区无响应。
阜阳现网切换准备阶段的失败原因类型主要是目标小区回复切换准备失败。
颍上县的谢桥矿区、汤店、周楼区域部分站点目标小区回复切换准备失败次数较多，且主要集中在X2接口切换失败。
【告警信息】：无【原因分析】：Handover Request消息中可以看到切换的目标基站号、小区号、SGW 的IP地址。
Handover Request Acknowledge消息携带目标基站的ip地址。
实际分析，可以通过X2接口信令跟踪或是两两小区切换，查到切换失败的目标小区，进一步分析判断原因。
【解决方法】：1.FY-颍上-谢桥矿区-HFTA-436935-50通过两两小区切换指标发现谢桥矿区50小区向目标小区436943-52切换失败较多，且主要为目标小区回复切换准备失败。
网管查询 436943为迪沟路口基站，小区号为53、54、55。
而网管配置的谢桥矿区50小区同频邻区列表里为436943-52小区。
查询其定义的外部小区，发现定义了436943的50-55小区均为迪沟路口。
怀疑迪沟路口初始规划挂在前3个端口，而实际施工挂在了后3口。
邻区并没有同步更新，导致配置了不存在的小区，从而发生目标小区回复切换准备失败。
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终端异常导致厂家边界切换失败问题处理最佳实践总结
宁波FDD-LTE异常终端切换失败处理案例1、概述随着L800站点大规模入网，室外L800M已经实现连续覆盖，优化问题也接踵而来，最近在处理厂家边界（华为&中兴）切换问题时，发现一对小区切换成功率极低，需紧急处理。
图表12、问题描述近期华为区域全网切换指标持续下降，查询TOP小区是发现位于华为与中兴边界处一对L800小区切换成功率较低，影响全网指标，下表为问题站点切换指标统计：图表23、问题分析定位3.1 问题分析分析TOP小区分析切换失败原因值、两两切换统计值，以”LF_H_JD甬波波城北_25为例，切换失败原因是“目标小区回复切换准备失败消息导致同频切换出准备失败”，两两切换统计，失败次数都集中目标小区都是中兴：图表3根据Top小区指标初步分析，主要是由于中兴侧基站回复切换拒绝导致切换失败，下一步通过标口信令分析深一步分析失败原因，筛选出切换失败的消息，该消息是目标基站返回给源基站，携带有切换失败的原因值。
如下图所示，携带的原因值为no-radio-resources-available-in-target-cell(12)图表4原因值解释：目标小区无足够资源可用，最终导致切换阶段失败。
本次切换准备失败TOP小区都是此类原因，但实际目标小区负荷不高。
3.2 问题定位由于该基站有切换成功的情况，华为侧选取切换失败与切换成功信令进行分析对比，结果如下：1)当华为L800M基站X2口切换请求消息中携带终端支持BAND5字段，无论800M目标小区是否为中兴切换都会成功；图表5 携带band52)当华为L800M基站X2口切换请求中未携带终端支持BAND5字段，若L800M目标小区为中兴，则会回复切换失败消息，原因值就是”no-radio-resources-available-in-target-cell”图表6 不携带band5中兴侧信令回复分析：针对回复切换失败消息，原因值就是”no-radio-resources-available-in-target-cell”问题，当中兴L800M小区作为目标小区，需要核实源侧发送的“HANDOVER_REQUEST”消息中RRC_UE_CAP_INFO信息是否携带支持band5，如未携带支持band5，中兴侧eNB就不会生成切换命令，导致切换失败。
基于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上下文，包括承载的信息，安全上下文等。
电脑无法 正确切换显示器输出的原因分析
电脑无法正确切换显示器输出的原因分析在日常使用电脑的过程中，我们经常会遇到需要切换显示器输出的情况，比如从笔记本电脑的屏幕切换到外接显示器，或者在多台显示器之间进行切换。
然而，有时候电脑却无法正确地完成这个切换过程，给我们带来了不少困扰。
下面，我们就来详细分析一下造成这种情况的原因。
首先，硬件方面的问题是导致电脑无法正确切换显示器输出的常见因素之一。
连接线缆的质量和连接的稳定性是一个关键。
如果使用的是劣质或者损坏的线缆，例如 VGA 线、HDMI 线等，可能会导致信号传输不稳定，从而影响显示器的正常切换。
有时候，线缆没有插紧，或者接口处有灰尘、氧化等情况，也会造成连接不良，使电脑无法识别显示器。
另外，显示器本身的硬件故障也可能引发问题。
显示器的控制板、电源模块等出现故障，都有可能导致无法正常接收和处理来自电脑的输出信号。
显卡方面的问题同样不容忽视。
显卡驱动程序未正确安装或者版本过旧，可能会导致显卡无法正常工作，从而影响显示器的切换。
如果显卡出现硬件故障，比如显存损坏、芯片过热等，也会导致输出异常。
其次，软件设置方面的错误也是造成电脑无法正确切换显示器输出的重要原因。
操作系统的显示设置不正确是较为常见的情况。
在 Windows 系统中，如果没有正确地识别和配置显示器，或者设置了错误的分辨率、刷新率等参数，都可能导致切换失败。
有些应用程序可能会独占显卡资源，导致其他显示器无法正常切换。
例如，某些游戏或者图形设计软件在运行时，可能会锁定显卡的输出模式，使得切换操作无法生效。
多显示器设置中的一些错误也会带来麻烦。
比如，没有正确地设置主显示器和扩展显示器，或者在切换时选择了错误的模式，都可能导致显示输出不正常。
再者，系统冲突和兼容性问题也可能是罪魁祸首。
不同版本的操作系统和显卡驱动之间可能存在兼容性问题。
新的操作系统可能与旧版本的显卡驱动不兼容，或者某些特定的系统更新可能会影响到显卡的正常工作。
电脑中安装的其他软件也可能与显卡驱动或者显示设置产生冲突。
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信号条件很好，邻区也都没有问题但依然失败的情况。
基于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上下文，包括承载的信息，安全上下文等。
切换失败原因和越区切换
切换失败原因和越区切换切换失败的原因主要有：1、硬件故障。
这是⾸先要与BSC确认的，检查有⽆告警信息。
2、切换参数设置有误或不合理。
3、切换⽬标⼩区有⼲扰。
4、邻区关系设置不合理，有漏配邻区等情况。
5、切换⽬标⼩区拥塞。
在路测中，我遇到的⼀般都是某⼩区越区覆盖、邻区不全导致的切换失败，和⽬标⼩区频点有⼲扰导致的切换失败。
遇见切换失败问题:1、⾸先查看是否⽤硬件告警，排除硬件问题导致的切换失败。
⽐如载频板故障，会导致⼊切换成率差。
2、查看⼩区数据配置。
⽐如定时器、⼩区切换磁滞和PBGT门限是否合理、邻区关系是否做全、如果是BSC间切换那么还要查看外部邻区数据中LAC CI BCCH BSIC 设置是否正确。
3、查看⼩区⼲扰带测量，排除是否有同频甚⾄同主B同BSIC码的现象。
4、现场环境是否弱覆盖现象，弱覆盖也容易造成切换失败。
5、时钟故障。
会导致MSC间切换失败。
6、孤岛效应导致切换失败。
7、上下⾏不平衡导致切换失败越区覆盖本词条主要介绍越区覆盖越区覆盖：由于基站天线挂⾼过⾼或者俯仰⾓过⼩引起的该⼩区覆盖距离过远，从⽽越区覆盖到其他站点覆盖的区域，并且在该区域⼿机接收到的信号电平较好。
⼀、导致越区覆盖的原因⾸先在⽹络规划过程中，应结合基站站址的间距，周围的地物地形数据进⾏基站的天线挂⾼、⽅向⾓、倾⾓、发射功率等参数的设计。
因对某些基站周围的地形地物的情况⽋了解，⽽盲⽬进⾏⼀些参数的设计，⽐如天线设计不合理，这便会产⽣远端越区覆盖情况。
特别是⼀些沿道路⽅向发射信号的⼩区，⼜或者江河两岸，⽆线传播环境良好，更有可能产⽣这种越区覆盖问题。
其次各地⽹络，建⽹初期存在⼤功率⼤覆盖的基站，天线过⾼，覆盖距离过远，本⾝就会有越区覆盖的情况。
在经过数期扩容后，增加了不少覆盖扇区，初期基站天线的⾼度应该适当降低，否则对周围基站扇区产⽣⼲扰，同时也会产⽣越区覆盖。
还有⼀些是在⽹络优化过程中，调整天线倾⾓时，当机械下倾⾓度达到10度以上时，⽔平⽅向波形严重畸变，也容易产⽣越区覆盖。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
切换出准备失败问题分析
【摘要】已开通站点站号变更，如果变更前邻区关系数据未完全清除会产生冗余数据，即邻区信息中既存在变更前站点数据又存在变更后数据，而本次CL共模站点只变
更ENODEBID，其余信息不变。
切换是根据终端检测到的PCI进行测量切换的，由
于邻区存在冗余数据，邻区信息中存在2个站点同PCI情况，PCI混淆导致切换
失败。
【关键字】ENODEBID变更 PCI混淆冗余数据
【故障现象】：
已站点446483的eNB间S1口同频切换出成功率较低，失败原因主要是目标侧准备失败。
图1 S1切换成功率低指标
【原因分析】：
查询该站点的切换出的邻接小区对，发现目标侧准备失败的站点为446482，涉及到其站点下的所有小区。
但是从eNB间S1口小区同频切换出准备请求次数，切换出准备成功次数和目标侧准备失败次数看，存在成功的情况，而非所有切换出准备请求次数全部失败。
图2 切换对指标统计
虽然知道是由于目标侧准备失败导致，但是最终原因还没有得到定位。
为此，进行了UE级小区信令跟踪来进一步确认问题原因。
通过跟踪信令查看msgname==handover preparation failure，发现其准备失败只有一个原因，其原因值为：unknown_targetID。
图3 UE级小区跟踪信令图
详细查看gid==11130的信令流程，当源侧基站通过S1链路发Handover Required请求给核心网时，在短短20ms的时间里，核心网给基站回复Handover preparation Failure，失败原因是目标侧ID未知。
后面再次发起切换请求时，核心网10ms的时间里给基站回复Handover preparation Failure，失败原因依然是目标侧ID未知
图4软件跟踪信令图
分析“unknown_targetID”切换失败的原因，有以下几种可能情况：用户请求的targetID（eNodeBID、TAI、CELLID）在现网中出现重复配置，冗余数据。
目标小区在源小区的邻区信息表，与现网小区的信息不一致，导致上报的targetID无法被网络识别。
用户切换请求中的targetID（eNodeBID、TAI、CELLID）目标小区不存在（可能存在基站断链，基站板卡硬件故障）。
因446483向446482切换时，切换出准备请求次数有一部分成功，一部分失败，所以邻接小区表中引用的目标小区与现网信息不一致的可能性就不存在了，如果存在，那应该是所有切换出准备请求全部失败。
每个站点与MME配置了2条S1链路，因此怀疑切换的目标站点446482的某条S1链路故障，导致当源站446483下通过该条S1链路向MME 发起切换请求时，MME通过该条S1链路对应的MME_code未能获取目标站点446482的站点信息，从而引起切换出准备失败。
而通过另外1条正常的S1链路发起请求时，切换准备成功。
动态管理里查询目标站点446482的S1AP状态，发现其中一条S1链路运行状态故障。
图5 S1AP状态图
再次回看信令，发现当ue在MME_code=26（HEX）发起S1切换（切换目标站点为446482），几次切换准备均失败。
图6 软件切换信令图
查看S1链路配置，SCTP列表和S1AP列表如下所示：
图7 S1AP截图
图8 SCTP截图
SCTP列表中的2条链路号分别为0、1，而S1AP列表中，引用的SCTP 确是0、1，很明显S1AP中引用的0是有问题的。
那么可以确认目标站点因S1AP引用错误，从而导致发生在该链路上的S1切换出准备失败，即源站点446483通过该S1链路发起MME的切换准备请求时，因446483对应的S1链路引用错误，导致MME侧给源站点446483回复了原因值为unknown_targetID的handover preparation failure。
【解决方法】：
将S1AP列表中引用的0修改为1后，接下来的小时级KPI指标中，目标侧准备失败导致的eNB间S1口同频切换出准备失败次数最后锐减至0，eNB间S1口同频切换出成功率恢复。
【结论与推广】
对于目标侧准备失败引起的切换出准备失败，如果是全部失败，通常需要优先确认源站邻接小区信息里配置的目标站点参数（如PLMN、MCC、MNC、TAC等）是否有问题，如果非全部失败，就需要考虑S1链路配置是否部分存在有问题，当然优先查看确认告警信息，
排除告警导致的问题，再结合UE级小区信令跟踪来进一步确认准备失败的具体原因值，深入分析从而找到问题的根本原因。