LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功
关键字：X2IPPATH 切换
【现象描述】
切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】
对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：
（1）传输资源不够用；
（2）没有配置IPPATH；
（3）IPPATH中的邻居节点配置错误。
页脚内容1
由于切换测试阶段的网络业务负载很小，接入用户数少，通过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口站间切换。
【告警信息】无
页脚内容2
【建议总结】
在网络负荷不大的情况下，X2口切换准备失败的原因通常与IPPATH配置有关，所以在配置 IPPATH时一定要仔细认真，源站与目标站双向配置，预防漏配错配的问题，提高切换成功率。
页脚内容3
切换过晚导致切换失败
关键字：切换小区偏置信道质量陡降
【现象描述】
在切换流程进行中，目标小区信号质量出现抖动，信道质量陡降导致切换失败。
在L3信令的表现为：源小区eNB收到多条测量报告，并且下发切换命令。
而UE未收到切换命令，并且仍然周期上发测量报告，直到发起重建，切换失败。
【原因分析】
1、从最后一个测量报告内容看，服务小区无线质量比邻区差6dB，根据现象看可能是邻区漏配。
但
是从网络侧操作维护台查询服务小区邻区信息，查找到有邻区配置。
如下图：
页脚内容4
页脚内容5
且源小区下发测量报告，因此不会是邻区漏配
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突降之前完成切换交互。
页脚内容6
可以选择两个方法：
1、把切换门限设置为1dB可以达到目的，但可能影响当前服务小区的所有邻区切换。
2、为了减小影响面，可以修改服务小区到当前切换目标小区之间的小区偏置CIO来解决，从eNB操
作维护台执行：MOD EUTRANINTRAFREQNCELL命令，修改服务小区与切换目标小区间的CellIndividualOffset = 1dB，表示把切换门限减小1dB。
之后问题解决，切换正常：
【告警信息】无
【建议总结】
合理规划小区偏置是网规网优的重要工作，对提高覆盖意义重大。
外部邻区配置错误引起下发重配置PCI错误导致切换失败问题
关键字：外部邻区PCI错误切换失败
页脚内容7
【现象描述】
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
页脚内容8
eNB下发PCI为12的重配置消息，见下图3
第二次出现：见下图4
页脚内容9
UE上报PCI为12的测量报告：见下图5
eNB下发PCI为13的重配置消息，见下图6
页脚内容10
切换失败，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:;
页脚内容11
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开关后依然出现此问题，可以根据分析和比较正常信令流程，顺藤摸瓜从而判断问题真正所在而将其解决。
页脚内容12。
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的S1口IP配置错误导致切换全失败
LTE的S1口IP配置错误导致切换全失败现象描述：RIY322站点大量异常释放Cluster测试中发现在RIY322站点周围，所有站间切入和切出的切换都会失败，当UE占用RIY322周围站点如RIY274C小区信号时，当满足A3事件触发条件时不断的上发测量报告想触发切换，但是一直未收到切换命令，过了一段时间就会触发异常释放。
告警信息：无原因分析：无处理过程：1. 查询RIY322以及周围站点的告警，都无任何告警2. 由于路测数据里面的现象为不断的上报测量报告但是一直未触发切换，初步怀疑为缺失邻区关系导致，检查现网邻区关系发现已经添加了RIY322与周围站点的双向邻区关系3. 检查RIY322以及周围站点的外部描述数据里面的PCI、ENODEB ID、TAC等信息，都与实际配置数据一致且与规划数据完全一致，未发现错误4. 到现场路测并同时跟踪了RIY322站点的Uu、X2、S1口以及周围站点RIY274、RIY258站点的S1信令，现场确认每当切入RIY322或者从RIY322切出的时候都会导致异常释放，但是在RIY322站点下能正常附着成功5. 查看路测数据在15:15:03左右发起了切向RIY258C（PCI=170）的切换，在15:15:45左右发起了从RIY258C（PCI=170）切向RIY322B（PCI=196）的切换请求测量报告RIY258切入切出空口路测数据6. 查看RIY258站点的S1口信令在15:16:41时刻收到了切入的切换请求有完整的切换信令流程成功完成切入RIY258的切换，同时在15:17:21时刻发起了切向RIY322站点的切换请求，但是一直反馈切换失败信息RIY258切入切出S1口信令7. 核对路测数据与S1口信令数据的时间差，差不多为1分37秒左右的时间差8. 由于RIY258站点配置了RIY322站点的X2链路，所以从RIY258切入的时候走的都是X2口切换，从RIY322站点的X2口信令可以看出，不断的有切换请求发过来，但是反馈的切换失败消息为：unknown-MME-Code，始终不能完成切换，发送多次以后就导致了异常释放RIY322的X2口信令9、RIY322站点未配置切出的X2链路，所以切出时都是走的S1切换，查看S1口信令发现在RIY322发出了切换请求以后，从MME发回的失败原因为:unknown-targetID，最终切换失败导致异常释放RIY322的S1口信令10. 从上面的分析可以把切换失败的原因与基站配置的MME的相关数据有关系，从现网导出DBS文件转换为MML脚本后，和现网的正常切换基站作了脚本对比发现，RIY322站点配置的MME的IP地址为10.127.218网段，而RIY258配置的MME的IP地址为10.127.72网段，10.127.218网段为达曼区域的MME的网段，10.127.72为利雅得区域的MME的网段，但是MME与MME之间还未做相关的对接配置，导致跨MME的切换都会失败RIY322与RIY258站点脚本对比建议与总结：修改RIY322站点的MME的IP地址为10.127.72网段。
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同频切换失败优化
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上报功能。
切换优化常见问题及案例(中兴)
1 切换优化常见问题及案例1.1 漏配邻区漏配邻区一般可通过无线参数表结合测试数据检查，或者可以在后台直接通过信令跟踪确认收到测量报告后源小区是否向目标小区发生切换请求来确认，但某些场景下我们不易取得无线参数表，且无法进行后台信令跟踪，那么我们可以通过前台信令来分析的到：LTE网络在协议中是一个自优化的网络，终端上报测量报告中会按照a3事件判断原则进行上报，上报的小区不受测量控制中邻区影响，所以只需要将切换异常点的测量报告和当前服务小区的测量控制中的邻区进行对比就可得出是否为漏配邻区1.1.1 前台分析漏配邻区的现象1.1.1.1 多次测量报告正常的流程终端在发送测量报告后基站会很快发送切换命令，但如果有漏配邻区，源小区就无法得知目标小区的基站信息，无法正常完成切换流程介绍中的（见图1-1）中的第三步，故无法发送切换命令消息，此时由于终端仍在行进中，源小区信号越来越差，满足a3事件小区逐渐增加，触发新的测量报告，直到有邻接关系的小区出现，基站才能正常发送切换命令下边选取一个典型问题分析：在某次路测中发现如图4-1情况，前三次测量报告目标PCI都是28（前三次类似图4-2，PCI相同，RSRP测量值略有差异），第四次测量报告（见图4-3）中有PCI28、19两个小区，从测量值上看，28比19高3个dB，接着收到了切换命令，切换命令（见图4-4）中的目标小区不是最高的28而是19。
此时即可初步怀疑28为漏配邻区，图41多次测量报告现象图42第一个测量报告内容图43第四次测量报告内容图44切换命令1：目标小区PCI图45源小区测量控制信息1：邻区列表中带有PCI19小区1.1.1.2 测量报告发送后无响应4.2.1.1介绍了漏配邻区导致的多次测量报告，直到某一次测量报告中上报的目标小区是源小区的邻区则才会收到切换命令，但如果上报的测量报告基站还未响应就失步则会发起重建流程，终端上报掉话事件这种情况的分析方法基本和4.1.1.1一致下边选取一个典型例子：某次路测中发现终端在发送测量报告后未收到切换命令，导致无线链路失败发起了重建过程（如图4-6），首先检查测量报告内容（图4-7，两个测量报告PCI都为30），目标小区PCI为30，检查源小区测量控制（图4-8），发现的确未配置邻区。
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。
TD-LTE切换案例分析
并没有出现非资源准入失败（流程失败），所以排除切换惩罚的原
因。
经核心网确认并没有将服务小区和目的小区配臵进切换限制列表。
目标小区禁止切换开关在同频邻区关系中配臵和显示的，需要进行
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page30
而睡眠小区一般表现为eNodeB的L3收不到UE的RRC建立请求消息。也出 问题在图7红色标注部分 与此问题站点的现象非常一致。 没有告警，没有操作日志，DSP小区状态也正常，没有用户接入和流量，但 是有随机接入过程。
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page12
【建议与总结】
切换的问题先从信令入手，再分析信令流程失败点所有可能 的原因，采用逐一排除、逐一确认的方法来找问题原因。
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page17
异频测量控制下发
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page18
UE上报异频测量结果：
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
经典案例_异系统切换失败导致Volte掉话排查案例
异系统切换失败导致Volte掉话排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (9)异系统切换失败导致Volte掉话排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。
【关键字】VoLTE掉话异系统切换【业务类别】VoLTE一、问题描述2019年3月31日宣城电信RCU设备在市区进行拉网测试时出现VoLTE异常掉话现象，问题点位于宣州区水阳江大道宛陵湖展览馆附近。
测试设备在其他基站可以正常进行VoLTE呼叫，基本可以排除测试设备的问题。
并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。
需要信息分析优化定位故障并解决。
二、分析过程（一）、排查思路分析VoLTE掉话分为UE上下文释放、E-RAB承载释放两类掉话。
端到端信令VoLTE掉话：当eNodeB收到来自MME的E-RAB RELEASE COMMAND（UE CONTEXT RELEASE COMMAND）消息，或eNodeB向MME发送E-RAB RELEASE INDICATION（UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection”，“Successful Handover”时，如果释放的承载包括QCI=1，则判断为VoLTE掉话。
基于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切换失败的原因及优化方法目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (6)LTE切换失败的原因及优化方法【摘要】当正在使用网络服务的用户从一个小区移动到另一个小区，或由于无线传输业务负荷量调整、激活操作维护、设备故障等原因，为了保证通信的连续性和服务的质量，系统要将该用户与原小区的通信链路转移到新的小区上，这个过程就是切换。
【关键字】连续性、服务的质量、通信链路【业务类别】优化方法一、问题描述亳州地市处理DT工单时，发现尾号为290309工单中测试车辆在亳州市涡阳县西环路与站前路交口东附近由东向西行驶中，占用XY-BZ-涡阳-天筑七彩城小区-HFTA-439340-5、XY-BZ-涡阳-涡阳紫金御景-HFTA-439340-1小区（2.1）无法切换到道路上的1.8G小区从而产生覆盖方向异常工单。
二、分析过程首先按照LTE切换种类、切换流程及切换异常问题等三方面进行分析：1、LTE切换种类站内切换、X2切换和S1切换2、切换流程分为测量控制、测量报告、切换命令、目标小区接入等过程A、测量控制测量控制信息是通过重配置消息（RRC Connect Reconfigration）下发的，测量控制一般存在于初始接入时重配置消息和切换命令的重配置消息中。
测量控制信息包括邻区列表、事件判断门限、时延、上报间隔等信息。
B、测量报告终端在服务小区下发的测量控制进行测量，将满足上报条件的小区上报给服务小区。
测量报告中会包括当前小区和测量到的邻小区信息。
C、切换命令这里的切换命令是指带有mobilityControlInfo的重配置命令，mobilityControlInfo包含了目标小区的PCI、T304等其他接入的所有配置。
D、目标小区接入终端在目标小区使用源小区在切换命令中带的接入配置进行接入，终端反馈重配置完成，标志切换结束。
但实际上重配置完成消息在收到切换命令后就已经组包完成并发送，在目标侧的随机接入可认为是由重配置完成消息发起得目标侧随机接入过程。