L T E切换问题定位和优化指导书SANY GROUP system office room 【SANYUA16H-LTE切换问题定位指导(仅供内部使用）Forinternaluseonly拟制：LTE性能专家组日期：审核：日期：审核：日期：批准：日期：华为技术有限公司HuaweiTechnologiesCo.,Ltd.版权所有侵权必究Allrightsreserved目录概述 (3)1切换问题定位思路 (3)1.1切换失败问题 (5)1.1.1UE发多条测量报告仍没有收到切换命令 (5)1.1.2切换过程随机接入失败 (5)1.1.3测量报告丢失 (6)1.1.4切换命令丢失 (9)1.1.5下行信道质量差导致发送preamble达最大次数仍未收到RAR (9)1.1.6eNB下发RRC信令等待UE反馈，不处理切换命令 (11)1.1.7X2_IPPATH配置错误导致切换失败为例进行分析 (11)1.1.8X2切换，源侧发出切换请求，没有收到切换响应 (13)1.1.9X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应 (13)X2切换准备时间过长错过最佳切换时间 (14)S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT（64ms），可以在信号恶化之前及时进行切换 (15)切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少181.2CHR分析切换问题 (19)1.2.1站内切换，随机接入失败导致切换失败 (19)1.2.2站内切换，切换完成丢失导致切换失败 (21)1.2.3X2切换，源侧等待上下文释放命令超时 (23)1.2.4X2切换，S1PathSwitch失败导致切换失败 (25)1.2.5切换随机接入失败触发重建，重建重配失败而掉话 (28)1.2.6eNB未响应UE切换测量报告，信道质量恶化而掉话 (29)1.2.7切换命令丢失导致切换失败 (31)1.2.8X2切换，Preamble丢失导致切换失败 (32)1.2.9X2切换，目标侧等待S1PathSwitchAck超时导致切换失败 (34)X2切换，随机接入失败触发重建，重建完成丢而掉话 (37)站内切换，随机接入失败触发重建，重建失败而掉话 (38)站内切换，切换完成丢失触发重建，重建失败而掉话 (41)概述无线通讯的最大特点在于其移动性控制，对于终端在不同小区间的移动，网络侧需要实时监测UE并控制在适当时刻命令UE做跨小区的切换，以保持其业务连续性。
在切换的过程中，终端与网络侧相互配合完成切换信令交互，尽快恢复业务，在LTE系统中，此切换过程是硬切换，业务在切换过程中是中断的，为了不影响用户业务，切换过程需要保证切换成功率、切换中断时延、切换吞吐率三个重要指标，其中最重要的是切换成功率，如果切换出现失败，将严重影响用户感受，切换中断时延和切换吞吐率也会不同程度地影响用户感受。
对于网络中可能出现的切换问题，本文根据当前积累的LTE系统内切换问题定位经验，给出相应的问题隔离定位指导，以优化相应的网络指标。
1 切换问题定位思路下面是从《LTEeRAN1.1切换问题定位和优化指导书v1.1》中摘录的案例，可供切换问题定位参考。
切换信令失败和切换用户面中断时延问题的定位思路图分别如下：图1 切换信令失败问题分析思路图图2 切换用户面时延问题分析思路图1.1 切换失败问题1.1.1UE发多条测量报告仍没有收到切换命令在ANR开关关闭时，如果不配置邻区关系，不能进行切换。
首先确认eNB侧配置是否有问题，是否是邻区漏配。
例如，UE要从小区A往小区B切换，发送了切换测量报告；此时，若小区A没有配置小区B为邻区，即使收到切换测量报告也不会处理，不下发切换命令，导致切换失败；此时，如果UE继续往远离服务小区的方向移动，信号越来越差会导致掉话。
查看是否邻区漏配，有如下方法：LSTEUTRANEXTERNALCELL（查询外部小区）LSTEUTRANINTRAFREQNCELL（查询同频邻区）1.1.2切换过程随机接入失败暂且不考虑信道质量差导致的随机接入失败，我们首先查看相关的参数配置是否合理。
随机接入性能与小区半径配置有关系。
如果UE在目标小区最大接入半径范围之外的地方发起随机接入，很可能出现preamble与RAR不匹配的问题，导致随机接入失败。
随机接入失败的原因是UE侧发送Preamble经过无线信道传输时延后到达eNB较晚，导致eNodeB按照正常的接收窗去解Preamble时解成了上一个PreambleID，导致发送的RAR和preamble不匹配。
出现这种问题时，华为测试终端的OMT上会有如下打印：如果小区覆盖范围较大（比如郊区），切换点离目标小区距离大于目标小区实际配置的小区半径，会出现随机接入失败导致切换失败。
可以适当增大目标小区半径，使得用户实际位置在小区半径之内。
1.1.3测量报告丢失首先判断测量报告丢失是否为上行信道质量差导致，可以通过上面4点进行分析。
下面给出下行加载场景下下行信道质量差导致切换测量报告发不出去的案例：现网路测一轮出现8次测量报告丢失，每次的S_RSRP均在-115dBm以内，在其它小区上行空载的情况下（即上行没有干扰），-115dBm以内不会出现上行受限。
因此，不应该是上行信道质量差导致的测量报告丢失。
现网路测一轮出现8次测量报告丢失，每次下行信道质量较差，SINR为负值，处于解调门限附近、IBLER不收敛；DL_Grant偏低，下行最大能力灌包的情况下，UE 解到的DL_Grant应该为1000(999)，DL_Grant偏低说明PDCCH解调有问题；同时，UL_Grant偏低说明很可能是PDCCH解调问题导致UE解到的UL_Grant减少、上行调度不足。
分析相应点的UL_Grant：01：45：06.296PCI56->PCI6502：08：11.796PCI264->PCI295从UE层间消息分析：发送测量报告时，SR达到最大重传次数触发随机接入ID_RRC_MAC_RA_IND；且SR触发的随机接入失败，启动RRC随机接入。
SR达到最大重传次数说明UE在发送测量报告时没有解到上行调度。
综合以上分析，eNB未收到测量报告不是因为上行信道质量差导致的上行信令丢失，而是下行加载场景下，下行信道质量恶劣，UE解调PDCCH出错，没有解到上行调度导致测量报告没有发出去；是下行信道质量差导致的上行信令丢失。
同时，我们做了相应的测试来验证我们的结论：打开上行预调度后，测量报告发不出去的次数明显减少。
1.1.4切换命令丢失以50%Load_woICIC路测数据为例：23:45:59.062 PCI48->PCI50 UE未收到切换命令该切换点邻区信号陡升6dB，对服务小区造成很大的干扰；下行SINR很低（-5dB），UE不能正确解调切换命令。
可通过调整天线、两个小区的CIO使提前切换来解决。
1.1.5下行信道质量差导致发送preamble达最大次数仍未收到RAR首先分析切换点的信道情况：从路测数据统计看，100%加载场景出现了12次切换完成eNB没有收到的情况。
各切换点S_RSRP都比较高，在上行空载的情况下，不会出现上行受限。
分析下行信道质量，SINR比较低（均为负值），且下行IBLER不收敛，说明下行100%加载场景下，下行干扰很大、信道质量较差。
从OMT跟踪打印看，UE发送preamble达最大次数仍没有收到RAR，如图：下图为100%Load_woICIC、100%Load_ICIC场景随机接入失败点，与目标站的距离均小于1km。
cluster6小区覆盖范围较小，配置的Ncs_Index=2(相应的最大接入半径为2.15km)，不影响随机接入性能。
综合以上分析，路测数据下行加载场景下的切换完成eNB未收到，是由于切换随机接入失败导致的。
下行信道质量差，导致UE没有解到RAR；当preamble达到最大重传次数时，随机接入失败。
1.1.6eNB下发RRC信令等待UE反馈，不处理切换命令eNB下发了RRC信令（比如MIMO重配消息），因为下行信道质量差，UE没有解调出来。
当满足切换条件时，UE上报测量报告，而eNB正在等待上一条RRC信令的反馈，因此，不处理测量报告。
当下发RRC信令达到2s后仍然收不到UE反馈，将其释放，发送RRC_CONN_REL消息。
如下图：eNB侧跟踪：UE侧跟踪1.1.7X2_IPPATH配置错误导致切换失败为例进行分析路测过程中，发现站点OSL355连续出现X2切换准备失败，如图：从切换准备失败的原因可以大致看出：传输资源不够或者没有配置IPPATH或者IPPATH中的邻接点配置错误导致，由于接入的用户不多，因此应该是IPPATH配置相关。
确认方法：1）从eCGI中可以确定基站ID为100123即OSL123基站，再根据上报的邻区PCI 为4的小区确认是否属于123基站，如果是则确定是123基站，如果不是则查看PCI 为4小区所在的基站是哪些，逐个排查；2）查看123基站的X2接口对应的IPPATH是否配置，如果配置则确认X2接口ID 与IPPATH的邻接点ID是否一致。
Step1:查看目标侧基站相应的SCTP链路号（X2SCTPLINKID）；LSTSCTPLNKStep2：根据SCTP链路号，查看相应X2接口标识（X2INTERFACEID）LSTX2INTERFACE;Step3：根据X2接口标识，查看相应的IP配置是否正确。
LSTIPPATH经过核查，发现OSL123虽然配置了与OSL355的X2接口，但是没有配置相应的IPPATH。
导致OSL355向OSL123发送X2切换请求后，收到X2切换准备失败消息。
配置X2_IPPATH后，切换OK。
1.1.8X2切换，源侧发出切换请求，没有收到切换响应左图为源侧基站消息跟踪；右图为目的侧基站消息跟踪。
有时还会出现这样的情况：由于源侧收到HANDOVER_REQUEST_ACK较晚（秒级），延误了最佳切换时机，导致切换失败。
1.1.9X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应目标侧发送S1AP_PATH_SWITCH_REQ未收到响应，导致此次切换失败。
同时，eNB不会处理后面上报的切换测量报告，导致新触发的切换也失败。
1.1.10X2切换准备时间过长错过最佳切换时间从Probe的测试数据中看到，UE在上报多次相同测量报告没有收到切换命令。
根据eNB侧全网跟踪信息分析发现这种情况下源侧eNB发起X2切换请求。
eNB切换X2准备时间过了很长时间才收到切换请求响应；期间，目的侧信号迅速衰减，最终目的侧eNB没有接收到切换完成消息、切换失败。