《LTE切换问题定位和优化指导书.pdf》由会员分享，可在线阅读，更多相关《LTE切换问题定位和优化指导书.pdf（12页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、L LT TE E 切切换换问问题题定定位位和和优优化化指指导导书书 SANY GROUP system office room【SANYUA16H-产品名称产品名称 ProjectIDProjectIDHuaweiTechnologiesCo.LHuaweiTechnologiesCo.Lt td d华为技术有限公司华为技术有限公司.项目组名称项目组名称 GroupnameGroupname密级密级ConfidentialitylevelConfidentialitylevel日期日期 DateDate版本版本VersionVersionLTE切换问题定位指导拟拟制：制：审审核：核：审审核：
2、核：批批准：准：(仅供内部使用）仅供内部使用）ForinternaluseonlyForinternaluseonlyLTE性能专家组日日期：期：日日期：期：日日期：期：日日期：期：华为技术有限公司HuaweiTechnologiesCo.,Ltd.版权所有侵权必究版权所有侵权必究AllrightsreservedAllrightsreserved目录目录概述.31切换问题定位思路.31.1切换失败问题.51.1.1 UE发多条测量报告仍没有收到切换命令.51.1.2 切换过程随机接入失败.51.1.3 测量报告丢失.61.1.4 切换命令丢失.91.1.5 下行信道质量差导致发送preamb
3、le达最大次数仍未收到RAR.91.1.6 eNB下发RRC信令等待UE反馈，不处理切换命令.111.1.7 X2_IPPATH配置错误导致切换失败为例进行分析.111.1.8 X2切换，源侧发出切换请求，没有收到切换响应.131.1.9 X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应.13X2切换准备时间过长错过最佳切换时间.14S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT（64ms），可以在信号恶化之前及时进行切换.151.2切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少18CHR分析切换问题.191.2.1 站内切换，
4、随机接入失败导致切换失败.191.2.2 站内切换，切换完成丢失导致切换失败.211.2.3 X2切换，源侧等待上下文释放命令超时.231.2.4 X2切换，S1PathSwitch失败导致切换失败.251.2.5 切换随机接入失败触发重建，重建重配失败而掉话.281.2.6 eNB未响应UE切换测量报告，信道质量恶化而掉话.291.2.7 切换命令丢失导致切换失败.311.2.8 X2切换，Preamble丢失导致切换失败.321.2.9 X2切换，目标侧等待S1PathSwitchAck超时导致切换失败.34X2切换，随机接入失败触发重建，重建完成丢而掉话.37站内切换，随机接入失败触发重
5、建，重建失败而掉话.38站内切换，切换完成丢失触发重建，重建失败而掉话.41概述无线通讯的最大特点在于其移动性控制，对于终端在不同小区间的移动，网络侧需要实时监测UE并控制在适当时刻命令UE做跨小区的切换，以保持其业务连续性。在切换的过程中，终端与网络侧相互配合完成切换信令交互，尽快恢复业务，在LTE系统中，此切换过程是硬切换，业务在切换过程中是中断的，为了不影响用户业务，切换过程需要保证切换成功率、切换中断时延、切换吞吐率三个重要指标，其中最重要的是切换成功率，如果切换出现失败，将严重影响用户感受，切换中断时延和切换吞吐率也会不同程度地影响用户感受。对于网络中可能出现的切换问题，本文根据当前
6、积累的LTELTE 系统内系统内切换问题定位经验，给出相应的问题隔离定位指导，以优化相应的网络指标。1 1 切换问题定位思路切换问题定位思路下面是从LTEeRAN1.1切换问题定位和优化指导书 v1.1中摘录的案例，可供切换问题定位参考。切换信令失败和切换用户面中断时延问题的定位思路图分别如下：图1图2切换信令失败问题分析思路图切换用户面时延问题分析思路图分析方法对应表切换失败分类定位方法信道质量 1网优问题 2配置问题 3传输问题 4产品问题 5通过 Probe 观察 RSRP、SINR、IBLER、DL/UL_Grant 等；LMT 用户性能跟踪，分析上/下行信道质量结合网络规划，分析是否
7、有越区覆盖情况，调整电倾角；cluster 边界邻区关系配置。MML 查看是否有邻区漏配；X2 相关配置；随机接入相关配置（Ncs_Index）；鉴权开关查看告警，是否有链路闪断；传输是否稳定。该问题概率性出现，很难抓取 log 定位无线侧、核心网侧产品 Bug 可能造成切换概率性失败；功能不完善也可能造成切换性能降低。需要开发协助定位。切换大时延分类源侧数据包 CRC 错数据包重传目标侧数据包 CRC 错解决方案eRAN1.0B060SPC350 版本合入：源侧 L3 收到切换测量报告后，指示 L2 对之后的数据采用低阶调度，MCS 阶数可配，同时抬升对应的 PDCCH 功率，固定 CCE
8、聚合级别为 8eRAN1.0B060SPC350 版本合入：目的侧切换完成后启动定时器，定时器时长内对数据采用低阶发送，MCS 阶数可配（MML 可配）；同时抬升对应的 PDCCH 功率，固定 CCE 聚合级别为 8（合入版本）。SETHOMCSPARAM:MCSHOSTATIC=0,HOCQIRPTTIMER=60ms;eRAN1.0B060SPC340 版本合入：切换命令 HARQ 重传时不进入频选eRAN1.0B060SPC350 版本合入：1）抬升切换命令 PDCCH 功率，同时固定 CCE 聚合级别为 8；2）抬升切换命令 PDSCH 功率，同时切换命令采用固定 MCS1 阶发送；3
9、）eNB 侧直接将 HARQ+ARQ 重传（考虑到商用终端能力，该功能默认关闭）；4）合入 DTX 处理方案，解决初传解到 DTX，HARQ 重传无增益问题。切换命令 HARQ 重传进入频选(代码 bug)切换命令重传切换命令 PDCCH/PDSCH 受限随机接入流程 Preamble 重传X2 配置问题UE 处理流程优化覆盖/调整切换参数，使得切换点具有较好的信道质量，减少重传。检查 X2 配置（X2_Interface/IPPATH）等。eRAN1.0B060SPC360UE 版本合入：优化流程，如果在更新系统消息期间收到 RRC 连接重配置消息，则打断系统消息更新流程，优先处理 RRC
10、连接重配消息。1.11.1 切换失败问题切换失败问题1.1.1UE发多条测量报告仍没有收到切换命令在 ANR开关关闭时，如果不配置邻区关系，不能进行切换。首先确认 eNB侧配置是否有问题，是否是邻区漏配。例如，UE要从小区 A往小区 B切换，发送了切换测量报告；此时，若小区 A没有配置小区 B 为邻区，即使收到切换测量报告也不会处理，不下发切换命令，导致切换失败；此时，如果 UE继续往远离服务小区的方向移动，信号越来越差会导致掉话。查看是否邻区漏配，有如下方法：LSTEUTRANEXTERNALCELL（查询外部小区）LSTEUTRANINTRAFREQNCELL（查询同频邻区）1.1.2切换
11、过程随机接入失败暂且不考虑信道质量差导致的随机接入失败，我们首先查看相关的参数配置是否合理。随机接入性能与小区半径配置有关系。如果 UE在目标小区最大接入半径范围之外的地方发起随机接入，很可能出现 preamble 与 RAR 不匹配的问题，导致随机接入失败。随机接入失败的原因是 UE侧发送 Preamble经过无线信道传输时延后到达eNB较晚，导致 eNodeB按照正常的接收窗去解 Preamble时解成了上一个PreambleID，导致发送的 RAR 和 preamble不匹配。出现这种问题时，华为测试终端的 OMT上会有如下打印：如果小区覆盖范围较大（比如郊区），切换点离目标小区距离大于
12、目标小区实际配置的小区半径，会出现随机接入失败导致切换失败。可以适当增大目标小区半径，使得用户实际位置在小区半径之内。1.1.3测量报告丢失首先判断测量报告丢失是否为上行信道质量差导致，可以通过上面4点进行分析。下面给出下行加载场景下下行信道质量差导致切换测量报告发不出去的案例：现网路测一轮出现 8次测量报告丢失，每次的 S_RSRP 均在-115dBm以内，在其它小区上行空载的情况下（即上行没有干扰），-115dBm以内不会出现上行受限。因此，不应该是上行信道质量差导致的测量报告丢失。现网路测一轮出现 8次测量报告丢失，每次下行信道质量较差，SINR 为负值，处于解调门限附近、IBLER不收
13、敛；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在发送
14、测量报告时没有解到上行调度。综合以上分析，eNB未收到测量报告不是因为上行信道质量差导致的上行信令丢失，而是下行加载场景下，下行信道质量恶劣，UE解调 PDCCH 出错，没有解到上行调度导致测量报告没有发出去；是下行信道质量差导致的上行信令丢失。同时，我们做了相应的测试来验证我们的结论：打开上行预调度后，测量报告发不出去的次数明显减少。1.1.4切换命令丢失以 50%Load_woICIC路测数据为例：23:45:59.062PCI48-PCI50UE未收到切换命令该切换点邻区信号陡升 6dB，对服务小区造成很大的干扰；下行 SINR 很低（-5dB），UE不能正确解调切换命令。可通过调整天线
15、、两个小区的 CIO使提前切换来解决。1.1.5下行信道质量差导致发送preamble达最大次数仍未收到RAR首先分析切换点的信道情况：从路测数据统计看，100%加载场景出现了 12 次切换完成 eNB没有收到的情况。各切换点 S_RSRP 都比较高，在上行空载的情况下，不会出现上行受限。分析下行信道质量，SINR比较低（均为负值），且下行 IBLER不收敛，说明下行 100%加载场景下，下行干扰很大、信道质量较差。从 OMT跟踪打印看，UE发送 preamble达最大次数仍没有收到 RAR，如图：下图为 100%Load_woICIC、100%Load_ICIC 场景随机接入失败点，与目标站
16、的距离均小于 1km。cluster6小区覆盖范围较小，配置的 Ncs_Index=2(相应的最大接入半径为 2.15km)，不影响随机接入性能。综合以上分析，路测数据下行加载场景下的切换完成 eNB未收到，是由于切换随机接入失败导致的。下行信道质量差，导致 UE没有解到 RAR；当 preamble达到最大重传次数时，随机接入失败。1.1.6eNB下发RRC信令等待UE反馈，不处理切换命令eNB下发了 RRC 信令（比如 MIMO重配消息），因为下行信道质量差，UE没有解调出来。当满足切换条件时，UE上报测量报告，而 eNB正在等待上一条 RRC 信令的反馈，因此，不处理测量报告。当下发 R
17、RC 信令达到 2s 后仍然收不到 UE反馈，将其释放，发送 RRC_CONN_REL消息。如下图：eNB侧跟踪：UE侧跟踪1.1.7X2_IPPATH配置错误导致切换失败为例进行分析路测过程中，发现站点 OSL355连续出现 X2 切换准备失败，如图：从切换准备失败的原因可以大致看出：传输资源不够或者没有配置 IPPATH 或者IPPATH 中的邻接点配置错误导致，由于接入的用户不多，因此应该是 IPPATH 配置相关。确认方法：1）从 eCGI 中可以确定基站 ID 为 100123 即 OSL123 基站，再根据上报的邻区 PCI为 4 的小区确认是否属于 123 基站，如果是则确定是
18、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 接口，但
19、是没有配置相应的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不会处理后面上报的切换测量报告
20、，导致新触发的切换也失败。1.1.10 X2切换准备时间过长错过最佳切换时间从Probe的测试数据中看到，UE在上报多次相同测量报告没有收到切换命令。根据eNB侧全网跟踪信息分析发现这种情况下源侧 eNB发起X2切换请求。eNB切换X2准备时间过了很长时间才收到切换请求响应；期间，目的侧信号迅速衰减，最终目的侧eNB没有接收到切换完成消息、切换失败。UE重建成功后，eNB发起对DRB的重配置消息时，UE没有收到，eNB侧RLC达到最大重传次数直接释放用户。UE切换失败后发起重建，成功后由于没有接收到DRB的重配置消息，再次发起重建，由于第一次重建eNB侧RLC达到最大重传次数释放了用户上下文，
21、UE第二次重建被拒绝导致异常释放。PCI345小区RSRP覆盖情况良好，在切换X2准备期间，邻区信号迅速衰减，导致 UE随机接入失败，目的侧没有收到切换完成，切换失败。X2准备时间过长导致切换不及时错过最佳切换时间，导致后续用户重建掉话等情况。【解决措施】S1 链路闪断、传输受限等问题导致的切换失败，通常是概率性出现，难以定位分析；对路测切换性能有一定影响。X2准备时间过长从 eNB侧全网跟踪上看 X2 信令传输浪费了 3s 的时间。分析站点一键式日志时没有发现 X2链路故障的情况：底层 SCTP 链路发出消息后，如果在1s 内没有收到数据包的 ACK响应就会发起数据包重传，如果连续 10 次
22、重传失败就会上报 SCTP 链路告警断开 SCTP。初步定位是由于 X2信令重传导致信令传输时延增大。经过与客户确认发现客户在近期调整传输网络，导致传输性能受到影响。出现传输问题需要及时向客户确认，以减少不必要问题定位。1.1.11 S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT（64ms），可以在信号恶化之前及时进行切换Test122：55：40.218PCI48-PCI50 切换命令 UE 未收到分析：1、这次切换为站内切换，切换点 S_RSRP、N_RSRP 都比较高；在下行加载场景下，目标小区对原小区有较强的干扰。此时导频 SINR20%，说明切换点下行信道质量较差
23、，导致切换命令丢失。2、切换门限 2dB，UE 切换测量报告中 N_RSRPS_RSRP3dB。这种S_RSRP、N_RSRP 都比较高的站内切换，在下行加扰场景下，切换点的下行信道质量恶劣，需要提高切换触发的及时性，在信道质量急剧恶化之前完成切换。3、为了提高切换及时性，将 HO_TTT由 128ms 缩短至 64ms。HO_TTT64ms的测试结果，在该点切换成功。提高切换及时性后，上报切换测量报告点的信道质量有所改善，SINR 虽然也有显着的减低，但仍然有 23dB，大于解调门限；DL_IBLER约 15%，基本收敛于目标值10%。下行信道质量不是很差，保证了切换命令的正确解调。如下图：
24、Test223：52：33.140PCI48PCI50切换成功（HO_TTT64ms）Test301：06：09.937PCI48PCI50切换成功（HO_TTT64ms）结论：对于 S_RSRP、N_RSRP都比较高的站内切换，切换点信道质量急剧恶化，需要提高切换的及时性。建议适当改小切换门限（由3dB缩小为 2dB），缩短切换触发时间TTT（由128ms缩小为 64ms）。1.1.12 切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少在相同路线上进行不同切换门限对比测试（2dB切换 vs3dB切换），有如下结果：1、3dB切换的路测数据中，统计的切换次数为 103次；
25、而 2dB切换时的切换次数明显增大(130次)。2、2dB切换由于切换门限变小，更容易发生乒乓切换，从而切换次数变多。同时，切换门限减少也提高了切换的及时性，使得 UE在下行信道质量明显恶化之前就触发切换，提高了切换成功率。1.21.2CHRCHR分析切换问题分析切换问题eRAN2.1SPC400B050 及以后版本合入了 CHR 切换维测打点，可以通过 CHR 分析切换问题，以下举例给出 CHR 分析切换问题的方法。1.2.1站内切换，随机接入失败导致切换失败CHR 中记录的释放原因值为usRelCause:UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT，如下
26、图。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，分析切换随机接入过程是否成功专用 Preamb
27、le收到了 10 条（Preamble最大重传次数配置为 10 次），说明 UE没有收到 RAR 而进行了 Preamble重传，并且达到最大重传次数 10。综合以上分析可知，本次站内切换失败原因为随机接入失败。1.2.2站内切换，切换完成丢失导致切换失败CHR 中记录的释放原因值为usRelCause:UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT，如下图。Step1：“掉话前最后 10 条信令”分析eNB发切换命令后未收到切换完成。（CHR 获取 CallID，在 UMAT 中过滤出该CallID信息）Step2:分析 L2_SRB_LOG，判断 UE是否收
28、到切换命令切换命令 HARQ反馈为 ACK，说明 UE收到了切换命令，如下图：Step3：查找 L2_L1_DEDI_PREAMBLE，分析切换随机接入过程是否成功专用 Preamble收到了 1 条，说明 UE发送一次 Preamble即收到了 RAR。综合以上分析，本次切换失败原因为切换完成丢失。当然，也不能完全排除随机接入失败导致的切换失败（UE没有收到 RAR，而重发的 PreambleeNB均没有收到）。1.2.3X2切换，源侧等待上下文释放命令超时CHR 中记录的掉话释放原因值为usRelCause:UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILStep
29、1：“掉话前最后 10 条信令”分析最后 10 条信令显示：源侧没有收到目标侧的 X2上下文释放命令，定时器超时（Timer15s）释放用户。Step2：切换流程分析1）源侧基站 CHR 的 L2_SRB_LOG显示切换命令 HARQ反馈为 ACK，说明 UE收到了切换命令。2）源侧基站 CHR 的 cell_RR_RSP 字段中查找本次呼叫的 CRNTI=6303）目标侧基站 CHR 的 HoIninfo字段中查找 SRSCRNTI=630的话单。由于目标侧站点 CHR 该时段信息已被冲掉，因此无法继续分析。如果有目标侧的信息，可以分析切换随机接入是否成功，是否收到切换完成，etc。1.2.
30、4X2切换，S1PathSwitch失败导致切换失败Step1：源侧 CHR 分析1）切换命令 HARQ反馈为 ACK，说明 UE收到了切换命令2）该 UE在切换源侧的 CRNTI=1457；3）切换测量报告中的 RSRP：S_RSRP=-112dBm；N_RSRP=-108dBm4）“掉话前最后 10 条信令”分析：等待 X2_Context_Rel_CMD 超时释放用户，切换失败。需要通过目标侧 CHR 进一步分析切换失败原因。Step2：目标侧 CHR 分析1）过滤 HoInInfo的 usSrsCrnti 字段，找到 usSrsCrnti=1457的记录，即为该 UE本次切换的目标侧信
31、息。2）“掉话前最后 10 条信令”分析：目标侧收到了切换完成；由于核心网回复S1_PATH_SWITCH_REQ_FAIL导致切换失败。综合以上分析可知，本次切换失败原因为 S1PathSwitch失败，非无线侧原因。1.2.5切换随机接入失败触发重建，重建重配失败而掉话Step1：“掉话前最后 10 条信令”分析，切换失败重建回源侧，eNB等待重建重配完成超时（5s）释放用户。Step2：重建原因分析，切换随机接入失败触发重建1.2.6eNB未响应UE切换测量报告，信道质量恶化而掉话Step1:“掉话前最后 10条信令”分析UE不断上报切换测量报告（切换目标小区 PCI320），但 eNB
32、未下发切换命令（怀疑没有配置邻区关系）；从测量报告信息可知，UE所在服务小区下行信号较弱，RSRP=-122dBm。Step2：掉话原因分析UEM_UECNT_REL_UE_RLC_UNRESTORE_IND/*L2 上报 RLC重传次数达到最大值时的无法恢复指示消息*/该释放原因包括两种场景：1）SRBRLC达最大重传次数；2）DRBRLC达最大重传次数。L2_SRB_LOG记录了 L2检测到异常前（比如，RLC达最大重传次数）最后 8 条下行 SRB的调度情况；DRB_64MS（size=16）记录了 L2检测到异常（比如，RLC达最大重传次数）前16*64ms 时间内下行 DRB的调度情
33、况。下图显示，掉话前 SRB正常，随后 DRB出现大量 NACK/DTX（DRB_64MS416均为 NACK/DTX）。综合以上分析可知，eNB未响应 UE切换测量报告，导致信道质量恶化，DRBRLC达最大重传次数而掉话（eNB检测到 RLC达最大重传次数后约延迟 30s 释放）。1.2.7切换命令丢失导致切换失败CHR 中记录的掉话释放原因值为 5，即UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILStep1：“掉话前 10 条信令分析”：源测等待上下文释放命令超时而释放用户。Step2：源测 CHR 分析：切换命令的 HARQ重传次数达到最大（ucHarqReT
34、ransTimes=4）且 HARQ反馈状态为 2（DTX），说明 UE没有收到切换命令。综合以上分析：本次切换失败的原因为切换命令丢失。1.2.8X2切换，Preamble丢失导致切换失败CHR 中记录的掉话释放原因值为 5，即UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILStep1：“掉话前 10 条信令分析”：源测等待上下文释放命令超时而释放用户。Step2：源测 CHR 分析：（1）切换命令的 HARQ反馈为 1（ACK），说明 UE收到了切换命令。（2）通过 RbCellRrRsp 字段的 usCrnti，确定源测的 CRNTI=524。Step3：目标侧
35、 CHR 分析：（1）通过 HoInInfo字段，查找 usSRSCRnti=524的话单。（2）目标侧 CHR 无 L1上报 Preamble字段，L2_L3释放 Preamble 与分配Preamble的间隔为 2s，说明 Preamble丢失。综合以上分析：本次切换失败的原因为 Preamble 丢失。1.2.9X2切换，目标侧等待S1PathSwitchAck超时导致切换失败Step1：“掉话前最后 10 条信令”分析：源侧等待上下文释放命令超时释放用户。Step2：源测 CHR 分析：（1）切换命令的 HARQ反馈为 ACK，说明 UE收到了切换命令。（2）RbCellRrRsp 字
36、段显示源测的 CRNTI=1006Step3：目标侧 CHR 分析（1）目标侧 CHR 的 HoInInfo字段，查找 usSRSCRNTI=1006（2）目标侧最后 10条信令显示：目标侧收到了切换完成消息，等待S1PathSwitchAck 超时（15s）释放用户。综上所述：X2切换过程中，核心网未响应目标 eNB的 S1PathSwitchReq，导致切换失败。1.2.10 X2切换，随机接入失败触发重建，重建完成丢而掉话CHR 中记录的重建原因值ucRestCause：1 即 HandoverFailure。说明重建是切换失败触发的。Step1：“掉话前 10 条信令分析”：切换失败后
37、，重建回源测，eNB等待重建完成消息超时（5s）下发重建拒绝，释放用户。Step2：重建原因分析：随机接入失败触发重建。1.2.11 站内切换，随机接入失败触发重建，重建失败而掉话Step1：“掉话前 10 条信令”分析（1）测量报告中 S_RSRP=-112dBm，N_RSRP=-110dBm（2）源小区 PCI=198，目标小区 PCI=200，查找工参，发现源小区和目标小区在一个eNB内，说明是站内切换。（3）UE切换失败后触发重建，重建失败；UE可能接入其他小区，导致 MME主动发起释放。Step2：重建原因分析：随机接入失败触发重建，重建到目标侧。Step3：源测 CHR 分析：切换
38、命令的 HARQ反馈为 ACK，说明 UE 收到了切换命令。Step4：目标 CHR 分析：L1上报 Preamble 次数为 24 次，说明 UE没有收到 RAR，不断上报 Preamble。综合以上分析：本次切换失败触发重建的原因是 RAR 丢，重建失败而掉话。1.2.12 站内切换，切换完成丢失触发重建，重建失败而掉话Step1：“掉话前 10 条信令”分析（1）测量报告中 S_RSRP=-103dBm，N_RSRP=-101dBm（2）源小区 PCI=314，目标小区 PCI=313，查找工参，发现源小区和目标小区在一个eNB内，说明是站内切换。（3）UE切换失败后触发重建，重建失败；
39、UE可能接入其他小区，导致 MME主动发起释放。Step2：重建原因值分析：重建请求中 ulCellId=1（PCI=313），说明重建到目标侧。重建请求中携带的重建原因 ucReestablishmentCause=2，即 OtherFailure。说明不是切换随机接入失败触发的重建。Step3：源测 CHR 分析：切换命令的 HARQ反馈为 ACK，说明 UE 收到了切换命令。Step4：目标侧 CHR 分析：L1上报收到 Preamble 次数为 1，说明 UE 发送一次专用Preamble就收到了 RAR，随机接入成功。综合以上分析：本次切换失败触发重建的原因为切换完成丢，切换失败后 UE重建到目标侧，重建失败而掉话。1)参考文档LTEeRAN1.1切换问题定位和优化指导书