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。
LTE的掉话原因分析及处理思路(加精,值得收藏)
LTE的掉话原因分析及处理思路LTE“掉话”是指UE异常退出RRC_CONNECTED状态导致的连接中断。
统计节点为“RrcConnctionReconfigurationComplete”消息正确达到网络侧开始，之后进行的各类业务，未正常释放的均计为“掉话”。
正常释放流程如下：一、外场常见掉话原因分析目前LTE常见掉话原因包括弱覆盖、越区覆盖、切换失败、邻区漏配、系统设备异常、干扰、拥塞等。
掉话原因1：弱覆盖现象:由于弱覆盖导致的掉话，通常有以下表现：1.掉话前服务小区的RSRP持续变差（低于弱覆盖标准，如小于-105dBm），同时服务小区的SINR也一起持续变差（小于0dB，甚至小于-3dB）。
2.掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。
解决方案:要解决此类掉话，需要改善覆盖。
具体手段有：1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。
2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区，并加强它的覆盖。
如常用的天馈调整、站点建设等。
具体案例：对呼和浩特市大昭寺前街DT过程中占用到大昭寺华隆小区-FL_3小区，覆盖较差存在掉线风险。
通过调整PA：3→0，RS参考功率：13.4dB→15.2dB，覆盖改善，掉线风险大大降低。
掉话原因2：越区覆盖现象:在支持切换的移动通信网络中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况，导致“孤岛覆盖”无法与周边站点进行正常切换掉话，通常有以下表现：1.越区覆盖导致的“导频污染”。
在覆盖区内，没有稳定的强信号作为主服务小区。
服务小区信号的频繁变化，是导致掉话的一个主要原因。
2.越区覆盖对主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等）。
在某些区域，主服务小区收到越区信号的干扰，最终导致掉话。
解决方案：1.越区覆盖的一般优化原则是：在区域中已有合理的稳定信号覆盖的情况下，尽可能的控制越区覆盖的信号。
切换失败的原因及优化方法
切换失败的原因及优化方法切换异常的原因及优化方法（1）硬件故障导致切换异常由于TD采用多通道智能天线系统，而良好的赋形首先需要各个通道之间功率校正保持一致。
如功率校正通不过，将会导致赋形产生偏差，从而可能导致系统切换失败。
优化方法：查看基站设备告警记录，对故障的天线、基站硬件设备进行更换。
（2）同频同扰码小区越区覆盖导致切换异常在专用模式下，UE发送的测量报告，是根据PCCPCH 的使用频点以及扰码为标识来区分不同邻小区的。
如果存在同频同扰码小区越区覆盖，则可能会出现UE上报的测量报告中存在虚假邻小区信息，从而导致系统发出切换指令，使得某些处于专用模式下的UE频频尝试向实际信号并不好的越区覆盖小区发出切换请求，必然造成切换失败（也可能是乒乓切换）。
优化方法：从规划以及优化方面来避免同频同扰码小区越区覆盖现象。
主要是调整频点、扰码或工程参数（天线方位角、俯仰角、天线高度、小区最大发射功率等）。
（3）越区孤岛切换问题在环境比较复杂时，较近小区的信号由于阻挡产生一定损耗，而其他小区可能会从建筑物夹缝中透露出来，形成较强越区孤岛。
由于该区域的小区和越区小区之间不会互配置邻小区，在干扰没有严重到导致下行失步时，UE将不会选择到该小区上，但在服务小区信号较弱时，UE很可能会重选到该越区孤岛上。
当在该小区上通话（建立其他的DPCH也是一样）后，将会导致无法切换从而掉话的现象。
此类问题在切换指标上是无法显示出异常的，主要表现为掉话严重。
优化方法：对发生越区覆盖的小区的天线方向角、俯仰角、小区最大发射功率进行调整，必要时要降低天线高度；如果上述方法均不可行，可添加邻区关系，使切换正常。
（4）目标邻小区负荷过高（或部分传输通道故障），导致切换失败当目标邻小区的负荷过高时，切换将无法完成。
另外，当目标小区的部分传输通道由于误码较高或频繁瞬断时，也会引起切换（选择）失败。
如果是跨RNC，由于源RNC不了解目标RNC的传输故障情况，因此只要有切换请求，就会尝试进行切换执行，而最终导致切换失败，这种情况要持续到源RNC收不到目标小区的测量报告为止。
核心网异常导致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邻区关系不合理导致切换失败
LTE邻区关系不合理导致切换失败一、现象描述基站分布及路测轨迹图如下：测试车辆在（网格14）绥德路由西向东行驶至万镇路附近，UE占用普职校-HLH第1小区进行下载业务，RSRP为-141dBm，SINR为-5，信号陡降发起切换，随后发起切换但是不成功，从而发起RRC连接重建立，也失败，最后掉线。
二、处理过程分析（1）UE占用普职校-HLH第1小区，RSRP为-141dBm，SINR为-5，下载速率降至580kbps，信号质量差从而发起切换，向eNodeB发送“测量报告”消息（A3事件），携带两个邻区的测量报告：第一个是普绥祁-HLH第3小区（PCI=127），第二个是普职校-HLH第3小区（PCI=23）。
其中，普绥祁-HLH第3小区的RSRP=-140dBm+70=-70dBm，普职校-HLH第3小区的RSRP=-140dBm+28=-112dBm。
（2）普职校-HLH第1小区给UE发送“RRC连接重配置”消息，携带切换命令（MobilityControlInfo标识切换命令），切换目标小区是PCI=23（普职校-HLH第3小区）。
从此前的测量报告看，普绥祁-HLH第3小区（PCI=127）的RSRP更好（-70dBm），但该小区却不是切换目标小区。
因此，怀疑普职校-HLH第1小区的邻区列表中没有添加普绥祁-HLH第3小区（PCI=127）为邻区，故选择向RSRP弱的普职校-HLH第3小区切换，但由于普职校-HLH第3小区RSRP太弱，无线环境差导致切换失败。
（3）UE切换失败后进行小区选择。
从SIB1消息可知，当前选择小区eNodeBID为01959A （16进制）=103834，本地小区号是0D（16进制）=13，对应的是普绥祁-HLH第3小区。
（4）UE完成小区选择后，向普绥祁-HLH第3小区发起RRC连接重建立。
但是，按照3GPP 协议36.331,只有具备UE上下文的prepared cell（prepared cell包括源小区和切换目标小区）才可能实现RRC连接重建立。
TDD-LTE宏站切换失败小区问题分析
TDD-LTE宏站切换失败小区问题分析
作者：李俞瑾
邮箱：liyujin@
所在省：辽宁
关键字：邻区漏配;宏站;弱覆盖;掉线;下载速率低;
专业：无线/TD-LTE
设备类型：ENODEB
设备厂家：无线/华为
设备型号：BTS3900 LTE
软件版本：V100R008C01SPC100
故障描述：
LTE站点1小区在单验过程中，由站内向站外切换成功，但由站外向站内切换失败，并且RSRP差距大于10dB。
该测试小区RSRP相对良好，并无任何告警。
故障诊断：
1、处理流程图：
2、原因分析：
经查看，测试小区无告警，并且与站内邻区切换正常，且事件发生在由站外小区切换到站内小区，初步分析原因为邻区漏配或者切换门限过大
针对问题表象，分析处理步骤如下进行：
（1）、邻区参数核查
（2）、切换门限阀值核查
处理过程：
步骤一：联系后台人员对LTE小区进行切换门限阀值核查，发现该小区并不存在切换门限阀值过大。
步骤二：联系后台人员对LTE小区进行邻区参数核查，发现该站外小区并不
存在测试小区邻区。
预防/监控措施
添加邻区。
认真核查邻区参数，防止因为邻区漏配引起的弱覆盖等
调整后测试结果分析。
LTE-华为-传输模式不一致导致切换失败
传输模式不一致导致切换失败问题现象：荣昌高铁站-HLHA在站台优化添加了与爱立信站点荣昌高铁站-ELW跨厂家邻区后观察指标，切成功率掉至12%左右，切换指标非常差。
下表为邻区添加前后指标：原因分析：1、分析问题可能原因：●站点告警导致切换失败；●邻小区定义数据错误导致切换失败；●同频同PCI导致切失败；●邻小区拥塞导致切换失败；●切换参数配置不当导致切换失败；●站点干扰大导致掉线；●弱覆盖导致掉线；●X2接口配置数据错误导致切换失败；●PRACH配置冲突导致切换失败●其他原因；分析及解决步骤：1.查询站点实时告警及历史告警信息，站点状态正常无告警和历史告警。
查询截图如下：2.邻小区定义数据和同频同PCI情况，检查配置的移动国家码，移动网络码，基站标识，小区标识，下行频点，物理小区标识，跟踪区码均配置正常，且邻区内和5公里范围内无同频同PCI情况。
3.检查邻小区拥塞情况，查询立信站点荣昌高铁站-ELW话务情况，无拥塞情况。
4.切换参数配置情况，参数配置正常。
5.站点干扰和弱覆盖情况，提取上行干扰情况正常，现场测试反馈无下行干扰和弱覆盖情况。
6.X2接口配置数据检查,X2接口配置数据正常。
7.PRACH配置冲突导致切换失败，检查PRACH配置无冲突。
8.提取掉线原因值进行分析，从话统上看，切换失败时，“目标小区回复切换准备失败消息导致模式内切换出准备失败次数”占比非常高，而切换正常时，基本没有这个问题9.X2信令跟踪，有大量的“HandOver_Preparetion+failure”，内部原因值为“no-radio-resources-available-in-target-cell”10.统计信令切换失败的QCI分布，其失败主要由于QCI=7业务下切换时导致切换失败，其他QCI情况下切换成功。
检查QCI=7时RLCPDCP参数组配置为如下图：查询RLCPDCP参数组1时为UM模式，5时AM模式。
LTE切换失败问题分析案例
*2IPPATH配置问题导致切换不成功关键字：*2IPPATH 切换【现象描述】切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下列图所示。
【原因分析】对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：〔1〕传输资源不够用；〔2〕没有配置IPPATH；〔3〕IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过*2口传输的数据不多，一般来说不会出现传输资源不够用的情况。
所以可以先重点疑心IPPATH配置的问题，在处理过程中需要对*2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】每次切换到目标小区完成后，UE会读取目标小区的系统消息〔RRC_SIB_TYPE1〕,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令〔RRC_CONN_RECFG〕可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认*2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下：LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP *2INTERFACE；检查*2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应*2接口的标识*2InterfaceId。
LST IPPATH; 根据*2接口标识*2InterfaceId，查看*2口两端的IP配置是否正确。
TDLTE异频切换门限设置不合理导致切换不及时案例分析新站入网优化
异频切换门限不合理引起切换不及时分析
【现象描述】
在枢纽大楼附近车辆由西向东测试，UE占用青秀区枢纽大楼_HLH_1小区（PCI：295）RSRP：-100.45dbm，未能及时切换到最近F频段凤城大酒店_HLH_1小区（PCI：102）RSRP：-67.63dbm。
；如下图所示：
【告警信息】
无
【原因分析】
1、后台参数配置错误；；
2、青秀区枢纽大楼_HLH_1小区（PCI：295）未与凤城大酒店_HLH_1小区（PCI：102）配
置邻区关系；
3、青秀区枢纽大楼_HLH_1小区（PCI：295）未与凤城大酒店_HLH_1小区（PCI：102）配
置双向邻区关系；；
4、异频切换邻小区定义错误，如小区信息中PCI的更改也会引起定义的错误；
5、异频切换的门限设置得过
【处理过程】
1、联系后台检查后台相关参数配置是否有误；
2、检查量个小区间的邻区关系，看否存在邻区关系或者只存在单向的邻区关系；
3、查看异频切换邻区中的小区定义是否有误，是否存在小区工程参数的修改而定义中并无
修改致使定义错误；
4、查看异频切换的门限设置是否过高；
经过核查发现异频切换的门限设置过高了A1、A4默认-105，A2默认-109；于是异频A1 RSRP触发门限修改为-80，异频A2 RSRP触发门限修改为-84，基于覆盖的异频RSRP触发门限-90。
进过修改后切换正常如下图：
【建议与总】
造成切换失败和不切换的原因很多，遇到此类问题要认真排查仔细求证真确的结果。
LTE核心网鉴权关闭导致切换失败
LTE核心网鉴权关闭导致切换失败现象描述：
在某TDD-LTE实验网，站间小区切完后直接RRC CONNECTION RELEASE，切换失败率增加。
告警信息：
无
原因分析：
LTE核心网鉴权关闭导致切换失败
处理过程：
前台测试信令
1、 UE 在站内小区间切换时，前台测试信令都是正常的未出现异常
2、站间小区切换完成后， UE 在上报 RRC 重配完成信令后，收到基站侧下发的“ RRC CONNECTION RELEASE ”信令，随后 UE 发起接入过程，尝试多个站间切换，该问题始终存在。
但经现场测试人员确定切换过程中 RSRP 良好，无干扰存在。
从以上情况可以得出无线侧是没有问题的，初步怀疑是核心网之间是否存在问题。
如下图：
后台信令跟踪：
1 、通过后台信令跟踪发现 UE 上发切换完成信令“ RRC Connection Reconfiguration
Complete ”后，核心网直接下发“ RRC CONNECTION RELEASE ”给 UE ，导致 UE 重新建立 RRC 连接；
前后台的信令对比分析得出，由于核心网下发了 RRC 拆链的信令，导致切换不成功，故问题可以暂定为核心网存在问题。
后通过与核心网人员确认，核心网将鉴权功能关闭，导致在站间切换时， UE 鉴权被拒，从而导致切换完成后直接 RRC 释放。
后核心网打开鉴权，该切换问题解决。
建议与总结：
核心网将鉴权功能关闭，导致在站间切换时， UE 鉴权被拒，从而导致切换完成后直接 RRC 释放。
后核心网打开鉴权，该切换问题解决。
因目标基站开启MLB达到小区用户数门限导致的LTE切换准备失败
因目标基站开启MLB达到小区用户数门限导致的LTE切换准备失败1问题描述L800M向1.8G/2.1G切换时，出现大量切换准备失败的现象。
信令回复的切换准备失败原因为no radio resource available in target cell。
2问题分析切换准备失败都是基于频率优先级切换失败导致L.HHO.InterFreq.FreqPri.PrepAttOut− L.HHO.InterFreq.FreqPri.ExecAttOut3根因分析源和目标站点的一键日志，确认切换准备成功率低是由于开启频率优先级的切换后，切换到目标站点，由于目标站点开启基于用户的MLB，目标小区用户数已经达到门限，所以回复切换准备失败。
频率优先级切换属于非必要切换，所以目标站点一旦拥塞就会准入失败，如果是基于覆盖的切换入到目标站点不会准入失败，因为这个属于必要切换。
当前目标站点切换入准备失败主要是小区1和16，在用户数忙时会下降，其他小区正常，而小,0、1、2和16的MLB用户数门限是配置的60，其他小区配置的是100分析目标站点都是准入失败。
切换入准备成功率在忙时也不好，主要是小区1和16。
目标站都是MLB准入失败导致，说明是MLB负载高，准入拒绝导致切入准备失败。
分析目标站点的MLB配置，当前部分小区是基于用户数的MLB，部分小区没有开启MLB （CellAlgoSwitch.MlbAlgoSwitch=InterFreqMlbSwitch:1）而问题小区的用户数门限是604解决方案方案1：关闭MLB与其它特性配合方式开关关闭CELLMLBHO: LocalCellId=*，MlbMatchOtherFeatureMode= HoAdmitSwitch-0，关闭后提升切换准备成功率，但是有一个影响就是用户一旦今日后，目标小区发现当前负载高，会基于MLB把用户又切换出去，出现频繁切换。
方案2：调整目标小区MLB的门限，当前基于用户的MLB门限是InterFreqIdleMlbUeNumThd=60，推荐100，当然如果出现高于100的小区还是会出现准入失败。
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报告，通过这个报告可以清楚看到⼩区切出切⼊⼩区，切出切⼊请求次数，切出切⼊成功率；对于切换坏⼩区，可以很⽅便的找出对应切⼊或者切出问题⼩区。
信号基站切换流程切换失败的原因
信号基站切换流程切换失败的原因英文回答：Factors Impacting Handoff Failure in Cellular Networks.Handoff, also known as cell handover or cell reselection, is a critical process in cellular networksthat ensures seamless connectivity for mobile devices as they move across different coverage areas. However, handoff failures can occur due to various reasons, leading to dropped calls, data loss, and poor user experience. Understanding the causes of handoff failures is essentialfor improving network performance and optimizing the user experience.1. Signal Strength and Quality.One of the primary reasons for handoff failure is insufficient signal strength or poor signal quality. When a mobile device moves into an area with weak signal reception,it may not be able to maintain a stable connection with the serving base station. This can trigger a handoff attempt, but if the signal strength from the target base station is also weak, the handoff may fail. Additionally, signal interference from neighboring base stations or obstacles like buildings can deteriorate signal quality and result in handoff failures.2. Network Congestion.Network congestion occurs when a large number of devices are accessing a cellular network simultaneously. During such periods, the network may become overloaded, making it difficult for devices to establish or maintain connections. Handoff attempts may fail if the target base station is congested and cannot accommodate additional devices. Network congestion can be caused by high traffic volume, increased user demand, or insufficient network capacity.3. Mobility Patterns and Speed.The mobility patterns and speed of moving devices can also impact handoff performance. Rapidly moving devices may not have enough time to complete the handoff process before losing connectivity with the serving base station. This can result in handoff failures and subsequent call drops. Additionally, devices moving at high speeds may experience frequent handoffs, increasing the likelihood of failure.4. Base Station Configuration and Parameters.The configuration and parameters of base stations play a vital role in handoff success. Improperly configured base stations or outdated firmware can lead to handoff failures. Additionally, the selection of handoff parameters, such as the hysteresis margin and threshold values, can affect handoff performance. Incorrectly set parameters can result in premature handoffs or missed handoffs, leading to connectivity issues.5. Device-Related Factors.In some cases, handoff failures may be attributed todevice-related factors. Older devices or devices with outdated software may not support advanced handoff features or may have limited capabilities. Additionally, device hardware limitations, such as low signal reception sensitivity or poor antenna performance, can contribute to handoff failures.6. Environmental Factors.Environmental factors, such as terrain, buildings, and vegetation, can affect signal propagation and interfere with handoff processes. Buildings or dense vegetation can block or attenuate signals, leading to poor signal quality and handoff failures. Additionally, mountainous or hilly terrain can create signal shadows and disrupt handoff between base stations.7. Other Factors.Apart from the factors mentioned above, other less common causes of handoff failures include:Radio Frequency Interference: Interference from other radio frequency sources, such as Wi-Fi networks or microwave ovens, can disrupt cellular signals and lead to handoff failures.Synchronization Issues: Synchronization problems between base stations can affect handoff timing and result in failed handoffs.Network Outages or Failures: Planned or unplanned network outages or failures can cause handoff attempts to fail and disrupt connectivity.中文回答：造成基站切换失败的原因。
- 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
释放资源。