LTE切换失败简析
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站内切换失败是什么原因1、你的先看看本站邻区增加了没有，没有增加，只有A3测量，没有成功。
2、增加邻区，在看看邻区数据是否配置正确3、核查下目标小区是否存在告警（影响切换的）4、最后核查下2个小区之间的出或者入切换是否都正常，可以切出，可以切入，都不可以，都的测试验证下5\看看基站有没有告警6\是否拥塞，失败的原因有很多：0，硬件性能问题：终端异常《重启或更换终端》，故障《更换终端》，基站硬件故障《重启基站或更换硬件》1，邻区漏配，外部邻区参数设置错误（邻区优化）2，干扰问题：PCI冲突（换PCI，RS，RF优化），导频污染（换PCI，RS，RF优化），网外干扰（后台要配合处理，通过扫频仪测试定位和排查）3，阻塞4，时钟不同步5，弱覆盖（RS，RF优化或者建议加站）过覆盖（RS，RF优化）6，切换门限配置，迟滞，CIO，不合理（切换参数优化）一.首先跟踪信令看一下，具体那一步出问题了①eNodeB向UE下发测量控制，通过RRCConnectionReconfigration消息对UE的测量类型进行配置；②UE按照eNodeB下发的测量控制在UE的RRC协议端进行测量配置，并向eNodeB发送RRCConnectionReconfigrationComplete消息表示测量配置完成；③UE按照测量配置向eNodeB上报测量报告；④eNodeB根据测量报告进行判决，判决该UE将发生eNodeB 内切换，在新小区内进行资源准入，资源准入成功后为该UE申请新的空口资源；⑤资源申请成功后eNodeB向UE发送RRCConnectionReconfigration消息，指示UE发起切换动作；二、核对参数，看是否配置有邻区，是否有测量报告等；三、查看是否有告警，拥塞，干扰等。
基于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上下文，包括承载的信息，安全上下文等。
无线网络规划-切换失败原因及优化方法
UE侧信令
eNodeB信令
3．切换命令丢失分析
切换命令丢失是指UE侧发出测量报告后，eNodeB收到测量报告，并下发 切换命令，但UE侧没有收到；从UE侧看到的现象与测量报告丢失相同，但在 eNodeB侧可以看到eNodeB下发了RRC重配置消息，UE侧未响应。
切换命令丢失
4．目标小区接入失败分析：参数问题
是
切换门限等修改
终端异常产生的切换失败
时钟问题
是 检查同步、GPS状态等
不属于网络原因造成，而且容易
目标小区拥塞 是
小区扩容
判断，因此在切换问题分析过程 将终端问题产生的切换失败排除 在外。
干扰 覆盖问题
其他
是
处理外部干扰或者无线 环境优化
是
进行天线、功率调整或 者新增基站等
2．测量报告丢失分析
在LTE切换过程中，UE会根据eNodeB下发的测量控制完成相应的测量内容， 并将测量结果上报给eNodeB，但在UE上报测量报告后，并不代表eNodeB就一定 收到或者eNodeB一定会处理，那么这必将产生切换失败。UE不断地上报测量报 告，但在eNodeB并未收到相应的内容，最终导致链路释放。
任务5 切换问题分析
切换失败原因及优化方法
LTE切换失败的原因及优化方法
LTE切换异常主要分为：终端异常、测量报告丢失、切换命令丢失、目 标小区接入失败四种情况。
1．终端异常 在测试过程中，由于终端长时间工作产生过热或者APP过程内存不足都 可能导致终端死机、不影响相应动作等情况发生。在测试过程中表现为一段 时间终端不接收、不发送信令，接收电平强度、电平质量无变化。这种情况 较明显，容易判断，且不属于网络问题，一般重启终端即可恢复，不需要特 别分析。
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超时导致了切换问题发生。
TDD-LTE eNodeB标识配置错误导致入切换失败
TDD-LTE eNodeB标识配置错误导致入切换失败1【问题描述】外场拉网测试过程中发现TDL小区得力纺织入切换异常，该站周围所有小区均无法切入该小区，在UE多次上报测量报告无法正常切换情况下，后台虚用户跟踪信令出现MME回复S1AP_HANDOVER_PREPARATION_FAIL消息，详细原因为MME无法识别目标基站，提示unknown-targetid（未知目标标识）。
图1 连续发送测量报告但无法切换2【处理过程】2.1 告警分析查看当前和历史告警，该站点无任何告警信息。
2.2 话统数据分析提取该站一周话统指标分析，发现eNodeB间入切换尝试次数、执行次数和成功次数均为0。
而该站eNodeB内切换正常、eNodeB间切出正常，所以该站小区状态应该是正常的。
但是周边小区无法切换，可能存在切换参数配置异常导致，所以对小区切换参数进行了全面核查，并未发现参数异常现象。
另外，双模站点GPS故障或收星不足也可能导致入切换异常，故通过TDS系统查询GPS装置工作状态，也并未发现状态异常。
通知外场测试人员对该切换问题复测，并结合信令辅助分析，测试结果显示该站eNodeB间入切换仍然异常。
信令分析结果发现，当占用华新电缆3小区时，UE是可以测量到邻区得力纺织的RSRP 电平值、RSRQ值，但是在满足A3同频切换条件后，源eNodeB往MME发送切换请求时，MME 回复信息内容一直为unknown-targetid，说明源eNodeB上报的邻区信息内容有误或者MME无法识别，即MME接收到eNodeB上报的邻区信息后无法解析或解析后无法找到目标eNodeB。
由于目前华为所有eNodeB均下挂在同一套华为核心网EPC下面，所以不存在多个EPC之间交互的问题，所以只要EPC工作正常，出现MME回复信息内容为unknown-targetid消息，存在两种可能：一、上报的目标eNodeB不存在；二、根据前期优化经验，在同一核心网EPC下如果上报的目标eNodeB ID存在重复现象，核心网在无法辨别的情况下，也是发送unknown-targetid消息的。
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。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
LTE切换失败简析
坏小区定义
现在给移动的日报中对于切换坏小区的定义为切换成功率<90%,切换失败次数>15
该指标定义是ENB间的小区之间通过X2接口进行切换的成功率。
切换成功率是系统移动性管理性能的重要指标，并可用于分析相邻关系定义是否合理。
此KPI一般大于95%，处于比较良好的水平
切换过程
整个切换过程包括切换测量，切换准备与切换执行三个阶段：
测量阶段，UE根据下发的测量配置消息进行相关测量，并将测量上报给
准备阶段：根据UE上报的测量结果进行评估，准备切换资源，最终决定是否触发切换。
执行阶段：eNode根据切换准备结果，控制UE切换到目标小区，由UE完成切换。
因此切换成功率指标的分析需分别对切换测量，切换准备与切换执行来进行分析。
切换指标
enb内切换成功率公式：
VS_HO_Irc_eNB_succ_src/VS_HO_Irc_eNB_req_src
enb间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_tgt
X2切换信令&counter点
切换分析
GSM中有180报告，通过这个报告可以清楚看到小区切出切入小区，切出切入请求次数，切出切入成功率；对于切换坏小区，可以很方便的找出对应切入或者切出问题小区。
然后通过分析切换指标，小区是向某一个小区切换失败还是向多个小区均存在切换失败，然后判断是源小区问题还是目标小区问题。
最后通过分析问题小区指标，判断切换坏小区原因（覆盖，干扰，天馈，传输，时钟，邻区等）
目前在LTE中，在切换这方面可以利用的资源较少，没有类似GSM的180报告。
NPO中分析切换坏小区时，可以方便的找出该小区对应的邻区（目标小区、源小区和邻区小区）如下图所示:
（对于切出坏小区）然后导出该小区所有源小区的enb间切入失败次数和切入失败率，NPO中counter 为
分析切换坏小区的切出失败时间点，然后根据这个时间点去找对应邻区中是否有相同时间特点的切入失败小区。
（由于现网用户不多，切换序列较明显，很容易找到对应的切入失败小区）
对于一些切出准备失败小区，可能handover request发出后，目标小区就没有收到，这样的话通过上边方法就找不到对应的切入失败小区。
（这种情况下对于源小区来说是切换准备失败）在这种情况下，就需要借助call trace 去分析源小区的切换信令，从中可以很清楚的看到切换关系。
如下图所以，根据enb id 和PCI就可以确定向哪个小区进行切换。
案例
nanligongbeiSKL_3小区在12月28日17点开始出现ENB内切换出失败，成功率从100%降到10%左右。
由于是enb内切换失败，则只需查看该基站其他两个小区的切入，即可确定3小区向哪个小区切换失败的。
取nanligongbeiSKL_1、2小区的enb切入失败次数（vs_ho_irc_enb_fail_tgt)，发现2小区从17点开始出现ENB内切入失败，1小区没有切入失败。
从而就可以判断3小区向2小区切换失败。
进一步查看2小区切入失败原因，为VS_HO_IrC_eNB_fail_InternalFail_tgt_OD，即为2小区内部问题导致的切入失败。
查看nanligongbeiSKL_2小区接入指标，发现从18点开始出现MSG5问题（无失败原因统计）。
小区无法接入导致切入失败。
该问题研发一直在抓trace。
目前解决方法重启即可，解决了小区的接入问题，切入也就随之正常了。
X2切换信令流程图&信令详解
信令详解：
1.UE按照测量配置上报measurement report，源eNB根据报告进行判决，判决发生eNB间切
换。
2.源eNB发送handover request消息给目标eNB，请求目标eNB进行切换准备。
3.目标小区资源准备成功后，向源eNB发送handover request ACK消息，指示目标eNB切换
准备工作已经完成。
4.源eNB发送携带了IE mobilityControlInfo的RRC 连接重配消息给UE，命令UE执行切换。
5.源eNB发送SN Status Transfer给目标eNB，对于PDCP SN 和HFN状态被保存的每一个
eRAB，传递上行PDCP-SN和HFN 的接收状态，下行PDCP-SN和HFN的发送状态。
6.当UE接入到目标小区时，向目标小区发送RRCConnectionReconfigurationComplete。
向目
标eNB指示UE切换已经成功。
7.目标eNB发送Path switch request消息给MME，通知MME UE的接入小区已经改变。
请求
更新业务数据通道的节点地址。
8.MME发送MODIFY BEARER REQUEST消息给源S-GW
9.源S-GW返回MODIFY BEARER RESPONSE消息给MME
10.MME返回Path switch request的确认消息Path switch request ACK给目标eNB。
表示可
以在新的SAE承载上进行业务通信。
11.目标eNB发送UE context release 消息给源eNB，通知源eNB已经切换成功，触发源eNB
释放资源。