LTE切换失败问题分析案例
LTE切换为题处理案例及切换参数总结
LTE切换为题处理案例及切换参数总结切换问题处理及切换参数总结⽬录：简述：地铁部分FDD线路分布问题导致覆盖盲区场景下，FDD切TDD。
由FDD 站点覆盖快速衰落情景下，终端开启A2测量，信令窗⼝中频繁上报MR，⽆响应，切换失败导致重建。
经由本次问题处理，对切换参数进⾏总结。
⼀、案例分析：1.1.问题描述：由芍药居⾄太阳宫段，FDD切TDD终端占⽤1350(PCI=467) ENB=502165，地铁⾏驶过程中，信号快速衰落，终端开启A2测量，信令窗⼝频繁上报MR，⽆响应，切换失败导致RRC重建⾄1350（PCI=496）502163，经由此站切换⾄TDD38950（PCI=87）ENB=82354-42海淀⼗号线海淀黄庄站FDDNLS1.测试结果：1.2.优化：●参数查询：A1:-92，A2 :-100，A5 :-90，-95 CIO:0db TTT: 640ms●调整：由于FDD衰落迅速，⼏次测试均有-92左右迅速衰落⾄-120,导致重建，所以建议将A2门限提⾼，同时为满⾜快衰场景下能够顺利切换，将CIO调为10，使其提前切换，TTT切换切换时间由640ms改为160ms调整后参数：A1:-90，A2 :-92，A5 :-90，-95 CIO:10db TTT: 120ms●调整后测试⼆：切换参数总结：当UE处于连接状态，⽹络通过切换过程实现对UE的移动性管理。
切换过程包含移动性测量、控制⾯流程和⽤户⾯流程。
为了辅助⽹络作切换判决，原eNodeB为UE配置测量，使UE在切换之前上报服务⼩区和邻⼩区的信道质量，便于⽹络侧合理地判决切换。
测量配置基本信道参数表●eueMeasCellSMeasureRsrpSmeasure：服务⼩区RSRP门限启动测量的服务⼩区RSRP门限，取值(-141..-44)，单位为dBm。
此参数仅对针对信道质量的测量配置有效，对于针对CGI上报的测量配置⽆效。
对于针对信道质量的测量配置，当⽹络侧没有配置此参数，或者配置了此参数，且服务⼩区RSRP低于此参数指⽰的门限值时，UE根据测量配置对邻⼩区进⾏测量和上报。
经典案例-关于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就不会生成切换命令，导致切换失败。
LTE同频切换失败优化
LTE同频切换失败优化案例【摘要】ANR邻区自动优化功能开启后，一些新开通4G小区由于实施RF优化前覆盖过远，极易被切换源小区添加为同频邻区关系；同时源小区也添加了相同PCI的另一距离较近的切换目标小区邻区关系，终端由源小区向目标小区切换时，根据PCI遍历邻区关系列表，发现存在两处相同PCI的邻区关系后，基站会要强求终端上报ECGI，若因终端问题或其它因素导致ECGI上报失败，容易产生切换失败问题。
【关键字】ANR 同PCI ECGI【故障现象】：市区优化DT测试期间，终端占用43633-邮政储蓄银行2小区由北往南至436218-天上人间3小区出现一次同频切换失败现象。
DT测试软件截图如下图1图1：同频切换失败【告警信息】：U2000网管查询基站无告警图2：告警查询【原因分析】：同频切换失败原因较多，如基站故障、邻区漏配、切换参数配置不合理等都有可能导致切换失败问题，具体分析处理如下。
核查43633-邮政储蓄银行2与436218-天上人间3小区邻区关系表及同频切换参数配置正常。
图3：邻区核查配置正常436218-天上人间3小区PCI配置PCI85正常图4：目标小区PCI配置查询操作日志核查43633-邮政储蓄银行2与436218-天上人间3小区DT测试期间无任何操作。
图5：操作日志查询回溯切换失败前基站下发的切换配置消息中，基站要求终端上报PCI85的ECGI信息，截图6如下图6：ECGI上报请求根据LTE同频切换流程可知终端由源小区向目标小区切换时，会根据PCI遍历邻区关系列表，若发现存在两处相同PCI的邻区关系后，基站会要强求终端上报ECGI方式来判断最终切换目标小区。
图6信令的出现表明43633-邮政储蓄银行2小区存在两条相同PCI85的邻区关系，核查43633-邮政储蓄银行2的外部小区中PCI为85的存在436670-51/436218-55两个外部小区，查询结果如下图4图7：外部小区核查结果43633-邮政储蓄银行2小区邻区列表中436670-51/436218-55已添加邻区关系，查询如下图8图8：邻区关系核查结果回到DT数据中终端切换流程，基站要求终端上报ECGI信息，根据MSGID找到相应的终端测量报告，打开发现终端上报PCI85的小区ECGI为空值，如下图9图9：ECGI上报失败至此已确定是因终端上报目标小区ECGI信息不成功导致切换失败问题，本次测试终端为华为MATE8：LTER10版本，实际自R9版本及以上终端大部分是支持ECGI上报功能。
LTE-切换优化案例
TD-LTE切换问题优化案例1 基站不下发切换命令该问题的前提是UE上报了切换的MR，基站侧也收到了MR，但没有收到切换命令，可能的原因有邻区漏配或邻区配错、下发重配置没收到重配置完成和同频邻区中有PCI相等的邻区。
下面以案例形势一一展开。
1.1 邻区漏配&邻区配错1.1.1邻区漏配从基站跟踪看到基站收到了大量的MR，没有下发切换命令，导致掉话，如下图。
从probe上看信道质量不差没到解调门限以下，因为没有下发切换命令而掉话，可以查看是否为邻区漏配。
中兴通讯179向科技园四182发起切换，上报了切换的MR，基站侧也收到了MR，没有下发切换命令，之后读系统消息，发起重建，重新接入到MR中小区，即科技园四182，可以确认为邻区漏配。
Probe和基站侧log如下：图表1邻区漏配UE侧无线环境图表2邻区漏配UE侧LOG图表3邻区漏配基站侧log邻区漏配有2种情况:1、同频邻区和外部小区都没有配置;2、配置了外部邻区,但没配置同频邻区；建议：添加邻区注：也可通过对比SIB4中的邻区信息与MR中的邻区PCI发现是否为邻区漏配，如下图；图表4SIB4消息内容1.1.2邻区配错下面为外部小区和同频邻区均已配置，且同频邻区也配置正确，但外部小区的PCI添加有错，导致的掉话。
如下图，102（科技园三1小区）上报181（科技园四的1小区）的MR，但没下发切换命令，查询同频邻区已配置eNBID为28即科技园四的1小区为邻区，但1小区的PCI被配成了182，且配置了同站的两个PCI相等的外部邻区。
图表5邻区错配终端侧LOG图表6科技园三1小区的同频邻区图表7科技园三的外部邻区建议：修正外部小区的PCI，在添加邻区时务必保证外部小区的PCI及同频邻区的eNBID正确，减少优化工作量。
1.2 PCI相等导致不发切换命令现象：基站标识117，67（本地小区1）、68（本地小区0）为同站邻区，68往67切换正常，67往68切则切不过去，表现为上报了MR，不发切换命令，LOG如下：图表8PCI相等终端侧LOG图表9PCI相等基站侧LOG经查询67（本地小区标识为1）的外部邻区中有PCI为68和同站邻区的PCI相等，如下，在ANR关闭情况下，会不发切换命令；图表1067小区的外部邻区图表1167小区的同频邻区措施：首先核查是外部邻区中的PCI配置错误（即该站不存在，或基站存在但PCI配置有错）；核查都无误时需要调整PCI；建议：1、调整完PCI后或新加站后用M2000上的PCI冲突核查工具进行核查邻区中是否存在PCI相等情况。
LTE切换问题分析
1相关Counter介绍1.1 切换相关KPI公式（L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧eNB间切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut)*100% ✧同频切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.IntraFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut)*100% ✧异频切换出成功率（L.HHO.IntereNB.InterFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut+ L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut-L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% 1.2 Counter解释Counter解释：✧切换成功率Counter✧切换失败counter原因：1.3 Counter计数位置及说明1.3.1站内切换图（2）1.3.2 X2切换图（3）2.3.3 S1切换图（4）注明：尝试切换Counter都计数在A点位置，准备切换Counter都计数在B点位置，切换成功Counter都计数在C点位置1.3.4 切换失败Counter说明图（5）a). 在S1接口切换及X2接口切换过程中的切换准备阶段，源小区收到来自MME的UE CONTEXT RELEASE COMMAND消息时，如果切换过程中源小区和目标小区为同频或异频，指标L.HHO.Prep.FailOut.MME加1。
小区半径设置不合理导致切换失败案例
“细耕800M、多频协同、提升感知”专项-小区半径设置不合理导致切换失败案例1概述目前LTE网络正在大范围的开展和建设中，基站大部分集中在城区和人口密集的乡镇对于这些站覆盖和接入的距离都较近,对于北京现网已基本实现LTE网络深度覆盖。
但在路测过程中发现在一个区域内出现频发的切换失败，监控KPI指标切换成率也仅有95%左右。
对此我们对该问题点进一步分析。
2问题描述现网KPI指标分析发现，部分基站同频切换指标异常，具体如下表所示：基站名称小区名称本地小区标识eNodeB间同频切换出成功次数eNodeB间同频切换出尝试次数失败次数HHF_CP北新建材厂北新建材厂_2 2 7477 8943 1466HHF_CY柏瑞安科技大楼柏瑞安科技大楼_2 2 9324 10017 693 HHF_HD科实五金科实五金_3 3 5645 6239 594 HHF_CY柏瑞安科技大楼柏瑞安科技大楼_1 1 13279 13700 421 HHF_CP西三旗西三旗_3 3 6337 6592 255下图是切换区域示意图：上表中，存在切换失败异常的基站通过Mapinfo打点发现，该几个基站都在同一片区域，初步怀疑失败都由一个目标基站引起，具体如下:3问题分析3.1 两两小区切换问题分析。
通过两两小区切换分析发现，几个基站切换失败都由同一个小区东升锅炉厂搬迁1_4引起，具体如下表所示：3.2 NASTAR小区定位分析对小区切换失败的最多的基站进行NASTAR小区定位分析，通过分析发现：系统内同频切换出执行失败占比最高，如图所示（以北新建材厂_2小区定位分析为例）：深入分析同频切换失败，如下图。
从小区间切换RSRP测量来看，切换时RSRP在-90dBm左右，上行切换时上报的TA为7，信号覆盖较好，从信令可以看出，源基站向目标基站通过X2发送HANOVER_REQ信令后，目标基站未响应，具体入下图所示：根据Nastar小区分析发现，引起切换失败的主要原因为目标小区未响应，初步怀疑是目标小区存在底噪、告警、邻区关系不合理、参数设置不合理等问题。
LTE实践案例-切换不及时
异频切换门限设置不合理导致切换不及时
摘要：在对重庆网格16进行测试时发现，兴竹路厕所附近路段SINR较差、下载速率较低。
经过分析log，发现该路段异频切换不及时，通过修改异频切换门限，该路段的SINR和下载速率均得到提升。
关键字：异频切换、切换不及时、SINR差
案例正文：
案例背景
测试在兴竹路厕所附近，UE占用江北聚金花园-HLHA异频小区，由于该小区切换不及时，该路段RSRP拖到-141，切换失败；
问题现状分析
测试在兴竹路厕所附近，UE占用江北聚金花园-HLHA异频小区，由于该小区切换不及时，该路段RSRP拖到-141，切换失败；
图1 优化前测试log分析截图
对策和解决措施
1.解决对策
重庆现网的异频切换为基于覆盖的A4+A2
A2+A4 异频切换
由于A4门限设置过大，导致即使异频邻区的RSRP很好，服务小区因为不满足A4条件而无法切换至异频邻区，导致服务小区电平一直下降，最后掉话。
建议调整江北聚金花园-HLHA小区异频门限，并删除异频切换频点39150。
2.解决措施
将江北聚金花园-HLHA小区异频切换门限，将异频A4门限由-141改为-105，并删除异频切换频点39150
3.解决效果
调整完后，对该路段进行了复测，该路段切换正常，SINR由之前5以下提升到15 以上。
图2 优化后测试log分析截图
实践成果
1.异频门限设置需要根据现场实际覆盖情况差异化设置，设置不合理，将
会导致切换过早、切换不及时、或者乒乓切换等，容易导致掉话。
核心网异常导致pathwtich 切换失败案例
New - OZ_CELLLTE : GLOBAL_CELLLTE (3343) 11/19/2014 00:00 to 11/20/2014 23:00 (Asia/Shanghai) (Working Zone:…
No unit 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 4000.00 2000.00 0.00
VS_HO_IrC_X2_fail_exec_TimeoutS1PathSwitch_tgt_OD(L12713_5)
结合该时间的操作来看，三家设备（大唐，华为，贝尔）相同时段切换成功率均出现较 为明显下降，建议核查此时间内，MME 以及 PTN 是否作过大面积的操作，以尽快解决此问 题。
14760 14954 16543 764 2134 27205 3 7 8 5 11952 13685 13061 16452 9618 9636 9949 8925 7544 7818 11519
16617
15917
13236
14747
166
105
62
97
131
52
53
由以上内容可以看出，造成 X2 切换失败的主要原因为 PathSwitch 失败。 从 L12713_5 的分布比例来看，在一天存在 X2 切换的 3343 个小区来看，11/18/2014 L12713_5 计数的小区有 593 个增加到 11/24/2014 L12713_5 计数的小区有 2688 个，过滤完 切换次数低于 100 次的小区后，可以大致看到 11 月 20 号起，由于 path switch 超时，导致 切换失败率平均增加 3%左右，与全网切换成功率下降幅度大致保持一致。 再从时间来看，大致问题出现时间在 20 号凌晨：
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案例分析
一定要像爱护自己的眼睛一样爱护我们的网络
5
案例6：切换类
• 故障现象：邻区漏配 从基站跟踪看到基站收到了大量的MR，没有下发切换命令，导致掉话，如下图 。从probe上看信道质量不差没到解调门限以下，因为没有下发切换命令而掉话 ，可以查看是否为邻区漏配。 基站179向科技园四182发起切换，上报了切换的MR，基站侧也收到了MR， 没有下发切换命令，之后读系统消息，发起重建，重新接入到MR中小区，即科 技园四182，可以确认为邻区漏配。Probe和基站侧log如下：
• 解决方案：
• 让测试人员在页面修改为ctlte建立连接，这样，就和附着时的默认承载一致，单PDN 链接，终端重启后，可以接入LTE上网。定论为测试人员所在的基站（爱立信TDD基 站）不支持多PDN连接导致。
• 后期建议：
• 为了避免用户在网络连接时，输入的APN与终端底层送的、或用户签约的默认APN不 一致，附着成功后，发起第二个PDN连接时无线拒绝，导致无法上网。建议需要进一 步梳理无线基站的多PDN连接功能。
邻区漏配有2种情况: 1、同频邻区和外部小区都没有配置; 2、配置了外部邻区,但没配置同频邻区 ； 建议：添加邻区
一定要像爱护自己的眼睛一样爱护我们的网络
6
图表邻区漏配基站侧log
谢谢！
一定要像爱护自己的眼睛一样爱护我们的网络
7
优化建议：
增大A2事件切换门限，将A2门限设置高于终端在掉话前显示的RSRP值，这样终端在掉话前即可触 发激活态切换
一定要像爱护自己的眼睛一样爱护我们的网络
3
案例4：MOD3干扰类
• 故障现象
✓ 科技园E，58小区上报了114的MR，181和服务小区58模3相等，下发了切换命令，UE没收到，由 UE侧可看到此时SINR很差为-6.83;
LTE-切换案例
LTE切换失败原因：
1、弱覆盖；（eNB无法正确解调UE上报的测量报告，上行失步）
2、强干扰；（eNB无法正确解调UE上报的测量报告，上行失步）
3、无邻区；
4、有邻区，但配置错误（包括邻区频点、PCI、站号、TAC等）
5、T304配置过小；
6、随机接入功率或信道配置不对；
7、接纳控制失败；
8、目标侧基站故障；
一、弱覆盖导致切换失败案例：
二、强干扰导致切换失败案例；
三、无邻区导致切换失败案例：
四、有邻区，但配置错误导致切换失败案例：
五、T304配置过小导致切换失败案例：
六、随机接入功率或信道配置不对导致切换失败案例：
七、接纳控制失败导致切换失败案例：
八、目标侧基站故障导致切换失败案例：。
LTE案例-切换失败问地的题目案例
案例：切换失败问题案例
【问题描述】测试过程中UE占用圳埔新村FE3（PCI=363）小区，车辆在圳埔村宝荷路大门出口行驶时切换失败；
掉话前截图
掉话处截图
【问题分析】从终端侧LOG如上图测量报告前后对比，主用小区圳埔新村FE3上报圳埔新村FE1，系统侧下发重配置消息，终端未对RRC重配置解析，后台侧方面看出终端对核心侧发起了RRC连接重建请求，从测试数据上看,怀疑是流程欠套.测试终端问题，建议复测；
前台测量截图
系统侧截图
【解决方法】1．怀疑为测试终端故障，建议复测。
【优化结果】通过对该位置复测，复测结果未出现任何异常事件；
复测截图
复测截图。
LTE切换失败简析
LTE切换失败简析LTE切换失败简析坏⼩区定义现在给移动的⽇报中对于切换坏⼩区的定义为切换成功率<90%,切换失败次数>15该指标定义是ENB间的⼩区之间通过X2接⼝进⾏切换的成功率。
切换成功率是系统移动性管理性能的重要指标，并可⽤于分析相邻关系定义是否合理。
此KPI⼀般⼤于95%，处于⽐较良好的⽔平切换过程整个切换过程包括切换测量，切换准备与切换执⾏三个阶段：测量阶段，UE根据下发的测量配置消息进⾏相关测量，并将测量上报给准备阶段：根据UE上报的测量结果进⾏评估，准备切换资源，最终决定是否触发切换。
执⾏阶段：eNode根据切换准备结果，控制UE切换到⽬标⼩区，由UE完成切换。
因此切换成功率指标的分析需分别对切换测量，切换准备与切换执⾏来进⾏分析。
切换指标enb内切换成功率公式：VS_HO_Irc_eNB_succ_src/VS_HO_Irc_eNB_req_srcenb间X2切换成功率公式：VS_HO_IrC_X2_succ_prep_src/ VS_HO_IrC_X2_req_src ----enb间X2切出准备成功率VS_HO_IrC_X2_succ_src/ VS_HO_IrC_X2_succ_prep_src----enb间X2切出执⾏成功率VS_HO_IrC_X2_succ_src/ VS_HO_IrC_X2_req_src------------enb间X2切出成功率enb间S1切换成功率公式：VS_HO_IrC_S1_succ_prep_src / VS_HO_IrC_S1_req_src ----enb间S1切出准备成功率VS_HO_IrC_S1_succ_src/ VS_HO_IrC_S1_succ_prep_src----enb间S1切出执⾏成功率VS_HO_IrC_S1_succ_src/ VS_HO_IrC_S1_req_src------------enb间S1切出成功率Indicator与信令的对应对于源⼩区X2切换来说源⼩区发出Handover request---------VS_HO_IrC_X2_req_src源⼩区收到Handover request ACK---VS_HO_IrC_X2_succ_prep_src源⼩区收到ue context release---------VS_HO_IrC_X2_succ_src对于⽬标⼩区X2切换来说⽬标⼩区收到Handover request---------VS_HO_IrC_X2_req_tgt⽬标⼩区发出Handover request ACK---VS_HO_IrC_X2_succ_prep_tgt⽬标⼩区发出ue conte x t release---------VS_HO_IrC_X2_succ_tgtX2切换信令&counter点切换分析GSM中有180报告，通过这个报告可以清楚看到⼩区切出切⼊⼩区，切出切⼊请求次数，切出切⼊成功率；对于切换坏⼩区，可以很⽅便的找出对应切⼊或者切出问题⼩区。
LTE切换问题定位指导二(切换问题分析)
LTE切换问题定位指导一（切换问题分析）目录1站内切换，随机接入失败导致切换失败 (1)2站内切换，切换完成丢失导致切换失败 (4)3X2切换，源侧等待上下文释放命令超时 (6)4 X2切换，S1PathSwitch失败导致切换失败 (8)5切换随机接入失败触发重建，重建重配失败而掉话 (11)6eNB未响应UE切换测量报告，信道质量恶化而掉话 (12)7切换命令丢失导致切换失败 (14)8X2切换，Preamble丢失导致切换失败 (16)9X2切换，目标侧等待S1PathSwitchAck超时导致切换失败 (18)10X2切换，随机接入失败触发重建，重建完成丢而掉话 (21)11站内切换，随机接入失败触发重建，重建失败而掉话 (22)12站内切换，切换完成丢失触发重建，重建失败而掉话 (25)可以通过CHR分析切换问题，以下举例给出CHR分析切换问题的方法。
1站内切换，随机接入失败导致切换失败CHR中记录的释放原因值为usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT，如下图。
Step1：“掉话前最后10条信令”分析备注：目前Insightsharp不支持解析“掉话前最后10条信令”，需要用内部工具UMAT 解析。
首先在CHR中找到本次掉话的CallID，再在UMAT中过滤出该CallID的相关记录。
从CHR 记录的掉话前最后10条信令可以看到，eNB等待切换完成5s定时器超时后向核心网发起释放请求。
Step2: 分析L2_SRB_LOG，判断UE是否收到切换命令切换命令HARQ反馈为ACK，说明UE收到了切换命令，如下图：Step3：查找L2_L1_DEDI_PREAMBLE ，分析切换随机接入过程是否成功专用Preamble 收到了10条（Preamble 最大重传次数配置为10次），说明UE 没有收到RAR 而进行了Preamble 重传，并且达到最大重传次数10。
FDD-LTE随机接入超时导致切换失败的总结-湖北
随机接入超时导致的切换失败湖北无线网优中心二零一五年十月一、问题描述现场处理切换TOP小区发现，A小区的某一个邻区对（新建站）切换入执行成功率几乎为0%（切换准备为100%）。
二、问题分析1.1 PCI冲突检查出现准备成功率100%，执行成功率接近0%的情况（成功次数很低）。
常见情况可能是由于出现了PCI冲突，问题小区附近有相同PCI小区所导致。
直接更换PCI（附近10km范围内未使用的PCI）更换，观察30分钟指标，问题仍然出现。
排除PCI问题导致的切换失败。
1.2 超级小区问题查看历史指标。
,但是在此过程中发现该小区邻区对指标在本月中旬某个时段，指标突然变差，切换入成功次数几乎为0。
1.3 现场数据分析安排现场人员对该站点进行DT测试：（存在切换的问题邻区对进行切换测试），发现RRC connection reconfiguration complete小区终端有上报。
但是从前面统计的KPI指标来看，大部分问题均是RRC重配置超时，且重配置完成消息之后出现RRC重建立。
那么，RRC层消息有信令上报，在MAC层随机接入的时候是否存在异常？查看diagnose消息，连续发送多条MSG1消息，但UE并未收到MSG2信令：点击消息，发现MAC层对于MSG2消息TA=65535显示不可用：根据协议查询：TA为11字节，65535明显已经超出可用范畴：Timing Advance Command: The Timing Advance Command field indicates the index value T A(0, 1, 2… 1282) used to control the amount of timing adjustment that UE has to apply (see subclause 4.2.3 of [2]). The size of the Timing Advance Command field is 11 bits;怀疑小区MSG2超时导致了切换问题发生。
切换成功率低处理案例
切换成功率低处理案例LTE吉州区人民广场基站S1口少配导致切换成功率低处理案例一、现象描述在LTE网络KPI指标监控过程中发现吉州区人民广场区域的几个站点切换成功率极低，严重影响全网切换类指标，其中吉州区人民广场切换入失败次数每天达到4600多次，吉州区富华宾馆、吉州区红雨宾馆、吉州区附属医院，切换出失败次数和为4500多次。
二、原因分析1.处理流程图2.分析切换成功率低可能原因：对KPI指标及周边环境分，可发现如下问题：1）吉州区人民广场基站的邻区是否存在漏配、错配，外部邻区参数设置是否正确，PCI规划是否合理，切换参数设置是否有问题。
2）吉州区人民广场基站的切换入失败次数的和约等于周边基站切出失败的和，可定位为吉州区人民广场基站的问题导致其切入成功率低及周边基站切出功率低；三、问题排查1、吉州区人民广场及周边站点邻区核查吉州区人民广场及周边站点同频邻区核查根据基站拓扑结构核查吉州区人民广场及周边站点的邻区，确定现网邻区无漏配的问题，确定吉州区人民广场及周边站点的PCI规划合理。
2、吉州区人民广场及周边站点外部邻区定义核查吉州区人民广场及周边站点外部邻区核查核查吉州区人民广场及周边站点外部邻区的定义，主要核对外部邻区PCI及TAC设置,将外部邻区定义的PCI及TAC与现网比对，确定没问题。
3、同频切换参数检查及现场测试吉安LTE网络刚开局，现网所有切换参数均为默认值，核查无问题。
现场测试，吉州区人民广场与吉州区附属医院切换正常，验证了该站的参数设置没问题，可能有其他不常见的问题导致。
4、后台跟踪查询周边站点切换出失败原因全部为目标小区回复切换准备失败消息导致切换出准备失败后台信令跟踪对吉州区人民广场标准X2口进行跟踪，发现切换准备失败，失败原因值：传输不可用。
四、解决过程及方案查询ENODEB X2接口自建链开关状态，结果显示正常查询基站的DEVIP配置信息是否正确，结果显示正常查询基站IPRT是否正确，结果显示正常查询基站VLANID是否正确，结果显示正常查询基站SCTPLNK是否正确，结果显示配置正常查询基站IPPATH,发现S1接口配置为1条，IPPATH资源有限，所以相邻站点切到该站的成功率很低，通过增加到S1接口的IPPATH 到8条（现网标准为8条）后：修改后观察指标，恢复正常，该问题解决。
基于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上下文，包括承载的信息，安全上下文等。
LTE异频切换参数设置不当导致不切换案例
LTE异频切换参数设置不当导致不切换处理案例作者：邮箱：所在省：四川关键字：异频切换专业：无线网设备类型：华为设备型号：软件版本：一、问题描述15年5月11日网格2LTE拉网测试，测试车辆在丹桂路占用南充顺庆区丹桂路-HLH-2小区做下载业务，在自西向东行驶后，CRS RSCP持续衰减，电平在-98dbm左右，下载速率8M，成为弱覆盖，该路段本该切换至南充顺庆区望角山庄-HLH-1小区，但未能切换过去。
二、可能原因1、基站故障：基站故障导致切换失败；2、弱覆盖：当前占用小区及邻区列表电平都很差，导致切换失败；3、邻区漏配：当前占用小区与邻小区只配置了测量频点而未配置邻区关系导致切换失败；4、参数问题：小区后台参数设置错误，导致切换失败。
三、问题排查1、基站状态查询：后台查询基站无告警排除基站故障问题。
2、覆盖综合分析：根据测试数据可知，该路段邻区列表中南充顺庆区望角山庄-HLH-1小区电平值在-75dBm左右，不存在弱覆盖。
3、邻区漏配：后台查询邻区列表，南充顺庆区望角山庄-HLH-1与南充顺庆区丹桂路-HLH-2有邻区关系，不存在邻区漏配问题。
4、参数核查：后台查询邻区切换参数发现，南充顺庆区丹桂路-HLH-2小区异频切换门限为-70dbm,-75dbm，即当前占用小区电平小于-75dbm开始测量，大于-70dbm停止测量，而当前占用小区南充顺庆区丹桂路-HLH-2小区的电平一直在-85dbm左右，导致不能启动异频测量，致使不能向南充顺庆区望角山庄-HLH-1小区切换，可判断为切换参数问题。
四、处理结果修改南充顺庆区丹桂路-HLH-2小区异频切换门限,基于A3的异频A1 RSRP触发门限(毫瓦分贝)为-77，基于A3的异频A2 RSRP触发门限(毫瓦分贝)为-80，修改后验证结果如下：通过测试数据可明显看出，调整后切换正常，无弱覆盖现象，速率提升明显，调整效果良好。
五、总结在移动通信系统中，切换是指从原来所用信道上转移到一个更适合的信道上进行信息传输的过程，通过对切换参数的优化，可提升网络质量，提高用户感知，是无线优化的重要工作之一。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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配置是否正确。
经过以上步骤的核查，发现目标基站B2虽然配置了与源基站B1间的X2接口（从DSP X2INTERFACE命令的显示结果可以看到已配置），但是没有配置相应的IPPATH（通过LST IPPATH命令看不到X2口对应的IPPATH）。
导致站点B1向B2发送X2口切换请求（HANDOVER_REQUEST）后，收到基站B2发回的X2切换准备失败消息（HANDOVER_PREPARATION_FAILURE），导致切换不成功。
用ADD IPPATH命令配置了站点B2到站点B1的IPPATH后（源站点也要有X2口的配置以及从B1到B2的IPPATH），可以进行正常的X2口站间切换。
【告警信息】无
【建议总结】
在网络负荷不大的情况下，X2口切换准备失败的原因通常与IPPATH配置有关，所以在配置IPPATH时一定要仔细认真，源站与目标站双向配置，预防漏配错配的问题，提高切换成功率。
切换过晚导致切换失败
关键字：切换小区偏置信道质量陡降
【现象描述】
在切换流程进行中，目标小区信号质量出现抖动，信道质量陡降导致切换失败。
在L3信令的表现为：源小区eNB收到多条测量报告，并且下发切换命令。
而UE未收到切换命令，并且仍然周期上发测量报告，直到发起重建，切换失败。
【原因分析】
1、从最后一个测量报告内容看，服务小区无线质量比邻区差6dB，根据现象看可能是邻区漏配。
但是从网络侧操作维护台查询服务小区邻区信息，查找到有邻区配置。
如下图：
且源小区下发测量报告，因此不会是邻区漏配
2、再分析切换信令流程：根据网络配置，切换应该按下面流程交互：
Meas_RPRT
Handover_Request Handover_Request ACK
RRC_CONN_RECFG (HO_CMD)
SN_STATUS_TRANSFER
UE
S_eNB T_eNB Core Network
S1AP_PATH_SWITCH_REQ
S1AP_PATH_SWITCH_REQ_ACK
RRC_CONN_RECFG_CMP
(HO_CMP)
UE_CONTEXT_RELEASE
RRC_CONN_RECFG RRC_CONN_RECFG_CMP
UU_interface X2_interface S1_interface
查看网络侧跟踪的信令，在服务小区Uu 跟踪可以看到，收到了UE 的测量报告，再查看X2口，源小区向目标小区发送了切换请求，并且收到目标小区的切换请求回应，最后在UU 口下发了切换命令，但没有收到UE 的切换完成消息（站间切换）：
UU 、X2口信令交互
eNB 下发切换命令，但UE 侧未收到切换命令，由此可以判断可能是空口出现传输质量问题。
3、再看空口无线质量，查看对应时间的RSRP 值，发现在切换时间点附近服务小区的RSRP 值出现
陡降现象如下图：
从上图看，邻区比服务小区RSRP高1dB的情况维持了近两秒钟，但满足切换门限时服务小区突然变差，导致切换失败，如果切换时机可以提前，应该可以完成切换信令交互，这种现象应该属于切换过晚。
【处理过程】
根据前文分析，这次切换失败的原因在于切换过晚，因此可以通过修改切换门限或延迟触发时间来提前切换。
从上面记录的无线质量变化情况看，如果把切换门限设置为1dB（延迟触发时间默认为320毫秒），基本可以保证在服务小区RSRP突降之前完成切换交互。
可以选择两个方法：
1、把切换门限设置为1dB可以达到目的，但可能影响当前服务小区的所有邻区切换。
2、为了减小影响面，可以修改服务小区到当前切换目标小区之间的小区偏置CIO来解决，从eNB
操作维护台执行：MOD EUTRANINTRAFREQNCELL命令，修改服务小区与切换目标小区间的
CellIndividualOffset = 1dB，表示把切换门限减小1dB。
之后问题解决，切换正常：
【告警信息】无
【建议总结】
合理规划小区偏置是网规网优的重要工作，对提高覆盖意义重大。
外部邻区配置错误引起下发重配置PCI错误导致切换失败问题
关键字：外部邻区 PCI错误切换失败
【现象描述】
UE在 Servering CELL PCI为10的小区上，上报PCI为13(或者12)的测量报告，但是eNB下发的RRC重配消息是PCI为12(或者13)的相关信道等配置信息，引起切换失败，业务中断。
【原因分析】
A国S市的LTE Trail项目中，进行全网SIMO优化时发现，上报的测量报告的PCI和eNodeB下发给UE 的RRC重配消息中的PCI不匹配，从而UE未收到重配置完成消息，引起切换失败掉话，业务中断。
具体现象如下：
UE从Servering CELL PCI为10的小区往PCI为13或12的小区切换时，切换失败，查看L3信令，发现UE 上报PCI为13(或者12)的测量报告，但是eNB下发的RRC重配消息是PCI为12(或者13)的相关信道等配置信息，造成切换失败，UE发起重建到目标小区。
如下图1：
UE上报PCI为13的测量报告，见下图2
eNB下发PCI为12的重配置消息，见下图3
第二次出现：见下图4
UE上报PCI为12的测量报告：见下图5
eNB下发PCI为13的重配置消息，见下图6
切换失败，UE重建连接。
见下图7
【处理过程】
1、因为相邻关系和测量报告的小区对不起来，初步怀疑是ANR开关问题，因为前期并未打开ANR
开关且没有出现此问题，于是运行MOD ENODEBALGOSWITCH将全网的ANR开关关闭，发现问题依然存在。
2、分析全网的切换关系，发现只要当服务小区（源小区）为PCI=10时，测量上报PCI=12/13就会
出现问题，只要服务小区（源小区）不是10，就没有问题。
3、重点检查小区PCI=10的环境配置，
LST CELL
LST EUTRANEXTERNALCELL
LST EUTRANINTRAFREQNCELL
LST ENODEBALGOSWITCH:;
LST HOMEASCOMM:;
LST INTRARATHO:;
LST INTRARATHOQCI: QCIBEARERINDEX=9;
LST EUTRANEXTERNALCELL中的结果核查发现，在配置PCI为10的外部邻区关系时把PCI为12和13的对应扇区号恰好弄反，导致UE上报了测量报告后，EnodeB下发给UE的PCI错误，不能收到UE给EnodeB 的重配置完成信令，从而发起目标小区或者源小区重建请求，遭到重建拒绝，切换失败，业务中断。
如下图8
使用MOD EUTRANEXTERNALCELL命令修改目标小区的扇区和PCI的对应关系，问题解决。
【告警信息】无
【建议总结】
配置邻区和修改邻区关系时一定要注意对应关系
ANR功能早已经融入EnodeB版本，确实前期引起过X2口切换失败问题，也有可能引起切换上报PCI 错误或其他问题，但是关闭ANR开关后依然出现此问题，可以根据分析和比较正常信令流程，顺藤摸瓜从而判断问题真正所在而将其解决。