LTE切换问题定位和优化指导书(共43页)

1、精选优质文档-倾情为你奉上Huawei Technologies Co. Ltd.华为技术有限公司产品名称Project ID密级Confidentiality level项目组名称Group name日期Date版本VersionLTE 切换问题定位指导(仅供内部使用）For internal use only拟制：LTE 性能专家组日期：审核：日期：审核：日期：批准：日期：华为技术有限公司Huawei Technologies Co., Ltd.版权所有 侵权必究All rights reserved目 录 概述无线通讯的最大特点在于其移动性控制，对于终端在不同小区间的移动，网络侧需要实时

2、监测UE并控制在适当时刻命令UE做跨小区的切换，以保持其业务连续性。在切换的过程中，终端与网络侧相互配合完成切换信令交互，尽快恢复业务，在LTE系统中，此切换过程是硬切换，业务在切换过程中是中断的，为了不影响用户业务，切换过程需要保证切换成功率、切换中断时延、切换吞吐率三个重要指标，其中最重要的是切换成功率，如果切换出现失败，将严重影响用户感受，切换中断时延和切换吞吐率也会不同程度地影响用户感受。对于网络中可能出现的切换问题，本文根据当前积累的LTE系统内切换问题定位经验，给出相应的问题隔离定位指导，以优化相应的网络指标。1 切换问题定位思路下面是从LTE eRAN1.1 切换问题定位和优化指

3、导书 v1.1中摘录的案例，可供切换问题定位参考。切换信令失败和切换用户面中断时延问题的定位思路图分别如下：图1 切换信令失败问题分析思路图图2 切换用户面时延问题分析思路图分析方法对应表切换失败分类定位方法信道质量 1通过Probe观察RSRP、SINR、IBLER、DL/UL_Grant等；LMT用户性能跟踪，分析上/下行信道质量网优问题 2结合网络规划，分析是否有越区覆盖情况，调整电倾角；cluster边界邻区关系配置。配置问题 3MML查看是否有邻区漏配；X2相关配置；随机接入相关配置（Ncs_Index）；鉴权开关传输问题 4查看告警，是否有链路闪断；传输是否稳定。该问题概率性出现，

4、很难抓取log定位产品问题 5无线侧、核心网侧产品Bug可能造成切换概率性失败；功能不完善也可能造成切换性能降低。需要开发协助定位。切换大时延分类解决方案数据包重传源侧数据包CRC错eRAN1.0 B060SPC350版本合入：源侧L3收到切换测量报告后，指示L2对之后的数据采用低阶调度，MCS阶数可配，同时抬升对应的PDCCH功率，固定CCE聚合级别为8目标侧数据包CRC错eRAN1.0 B060SPC350版本合入：目的侧切换完成后启动定时器，定时器时长内对数据采用低阶发送，MCS阶数可配（MML可配）；同时抬升对应的PDCCH功率，固定CCE聚合级别为8（合入版本）。SET HOMCSP

5、ARAM: MCSHOSTATIC=0, HOCQIRPTTIMER=60ms;切换命令重传切换命令HARQ重传进入频选(代码bug)eRAN1.0 B060SPC340版本合入：切换命令HARQ重传时不进入频选切换命令PDCCH/PDSCH受限eRAN 1.0 B060SPC350版本合入：1）抬升切换命令PDCCH功率，同时固定CCE聚合级别为8；2）抬升切换命令PDSCH功率，同时切换命令采用固定MCS1阶发送；3）eNB侧直接将HARQ+ARQ重传（考虑到商用终端能力，该功能默认关闭）；4）合入DTX处理方案，解决初传解到DTX，HARQ重传无增益问题。随机接入流程Preamble重传

6、优化覆盖/调整切换参数，使得切换点具有较好的信道质量，减少重传。X2配置问题检查X2配置（X2_Interface/IPPATH）等。UE处理流程eRAN1.0 B060SPC360 UE版本合入：优化流程，如果在更新系统消息期间收到RRC连接重配置消息，则打断系统消息更新流程，优先处理RRC连接重配消息。1.1 切换失败问题1.1.1 UE发多条测量报告仍没有收到切换命令在ANR开关关闭时，如果不配置邻区关系，不能进行切换。首先确认eNB侧配置是否有问题，是否是邻区漏配。例如，UE要从小区A往小区B切换，发送了切换测量报告；此时，若小区A没有配置小区B为邻区，即使收到切换测量报告也不会处理，

7、不下发切换命令，导致切换失败；此时，如果UE继续往远离服务小区的方向移动，信号越来越差会导致掉话。查看是否邻区漏配，有如下方法：LST EUTRANEXTERNALCELL（查询外部小区）LST EUTRANINTRAFREQNCELL（查询同频邻区）1.1.2 切换过程随机接入失败暂且不考虑信道质量差导致的随机接入失败，我们首先查看相关的参数配置是否合理。随机接入性能与小区半径配置有关系。如果UE在目标小区最大接入半径范围之外的地方发起随机接入，很可能出现preamble与RAR不匹配的问题，导致随机接入失败。随机接入失败的原因是UE侧发送Preamble经过无线信道传输时延后到达eNB较晚

8、，导致eNodeB按照正常的接收窗去解Preamble时解成了上一个Preamble ID，导致发送的RAR和preamble不匹配。出现这种问题时，华为测试终端的OMT上会有如下打印：如果小区覆盖范围较大（比如郊区），切换点离目标小区距离大于目标小区实际配置的小区半径，会出现随机接入失败导致切换失败。可以适当增大目标小区半径，使得用户实际位置在小区半径之内。1.1.3 测量报告丢失首先判断测量报告丢失是否为上行信道质量差导致，可以通过上面4点进行分析。下面给出下行加载场景下下行信道质量差导致切换测量报告发不出去的案例：现网路测一轮出现8次测量报告丢失，每次的S_RSRP均在-115dBm以内

9、，在其它小区上行空载的情况下（即上行没有干扰），-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.296 PCI56->PCI6502：08：11.79

10、6 PCI264->PCI295从UE层间消息分析：发送测量报告时，SR达到最大重传次数触发随机接入ID_RRC_MAC_RA_IND；且SR触发的随机接入失败，启动RRC随机接入。SR达到最大重传次数说明UE在发送测量报告时没有解到上行调度。综合以上分析，eNB未收到测量报告不是因为上行信道质量差导致的上行信令丢失，而是下行加载场景下，下行信道质量恶劣，UE解调PDCCH出错，没有解到上行调度导致测量报告没有发出去；是下行信道质量差导致的上行信令丢失。同时，我们做了相应的测试来验证我们的结论：打开上行预调度后，测量报告发不出去的次数明显减少。1.1.4 切换命令丢失以50%Load_w

11、oICIC路测数据为例：23:45:59.062PCI48->PCI50UE未收到切换命令该切换点邻区信号陡升6dB，对服务小区造成很大的干扰；下行SINR很低（-5dB），UE不能正确解调切换命令。可通过调整天线、两个小区的CIO使提前切换来解决。1.1.5 下行信道质量差导致发送preamble达最大次数仍未收到RAR首先分析切换点的信道情况：从路测数据统计看，100%加载场景出现了12次切换完成eNB没有收到的情况。各切换点S_RSRP都比较高，在上行空载的情况下，不会出现上行受限。分析下行信道质量，SINR比较低（均为负值），且下行IBLER不收敛，说明下行100%加载场景下，下

12、行干扰很大、信道质量较差。从OMT跟踪打印看，UE发送preamble达最大次数仍没有收到RAR，如图：下图为100%Load_woICIC、100%Load_ICIC场景随机接入失败点，与目标站的距离均小于1km。cluster6小区覆盖范围较小，配置的Ncs_Index=2(相应的最大接入半径为2.15km)，不影响随机接入性能。综合以上分析，路测数据下行加载场景下的切换完成eNB未收到，是由于切换随机接入失败导致的。下行信道质量差，导致UE没有解到RAR；当preamble达到最大重传次数时，随机接入失败。1.1.6 eNB下发RRC信令等待UE反馈，不处理切换命令eNB下发了RRC信令

13、（比如MIMO重配消息），因为下行信道质量差，UE没有解调出来。当满足切换条件时，UE上报测量报告，而eNB正在等待上一条RRC信令的反馈，因此，不处理测量报告。当下发RRC信令达到2s后仍然收不到UE反馈，将其释放，发送RRC_CONN_REL消息。如下图：eNB侧跟踪：UE侧跟踪1.1.7 X2_IPPATH配置错误导致切换失败为例进行分析路测过程中，发现站点OSL355连续出现X2切换准备失败，如图：从切换准备失败的原因可以大致看出：传输资源不够 或者 没有配置IPPATH 或者 IPPATH中的邻接点配置错误 导致，由于接入的用户不多，因此应该是IPPATH配置相关。确认方法：1）从e

14、CGI中可以确定基站ID为即OSL123基站，再根据上报的邻区PCI为4的小区确认是否属于123基站，如果是则确定是123基站，如果不是则查看PCI为4小区所在的基站是哪些，逐个排查；2）查看123基站的X2接口对应的IPPATH是否配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。Step1: 查看目标侧基站相应的SCTP链路号（X2SCTPLINKID）；LST SCTPLNKStep2：根据SCTP链路号，查看相应X2接口标识（X2INTERFACEID）LST X2INTERFACE;Step3：根据X2接口标识，查看相应的IP配置是否正确。LST IPPATH经过核

15、查，发现OSL123虽然配置了与OSL355的X2接口，但是没有配置相应的IPPATH。导致OSL355向OSL123发送X2切换请求后，收到X2切换准备失败消息。配置X2_IPPATH后，切换OK。1.1.8 X2切换，源侧发出切换请求，没有收到切换响应左图为源侧基站消息跟踪；右图为目的侧基站消息跟踪。有时还会出现这样的情况：由于源侧收到HANDOVER_REQUEST_ACK较晚（秒级），延误了最佳切换时机，导致切换失败。1.1.9 X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应 目标侧发送S1AP_PATH_SWITCH_REQ未收到响应，导致此次切换失败。同时，

16、eNB不会处理后面上报的切换测量报告，导致新触发的切换也失败。1.1.10 X2切换准备时间过长错过最佳切换时间从Probe的测试数据中看到，UE在上报多次相同测量报告没有收到切换命令。根据eNB侧全网跟踪信息分析发现这种情况下源侧eNB发起X2切换请求。eNB切换X2准备时间过了很长时间才收到切换请求响应；期间，目的侧信号迅速衰减，最终目的侧eNB没有接收到切换完成消息、切换失败。UE重建成功后，eNB发起对DRB的重配置消息时，UE没有收到，eNB侧RLC达到最大重传次数直接释放用户。UE切换失败后发起重建，成功后由于没有接收到DRB的重配置消息，再次发起重建，由于第一次重建eNB侧RLC

17、达到最大重传次数释放了用户上下文，UE第二次重建被拒绝导致异常释放。PCI345小区RSRP覆盖情况良好，在切换X2准备期间，邻区信号迅速衰减，导致UE随机接入失败，目的侧没有收到切换完成，切换失败。X2准备时间过长导致切换不及时错过最佳切换时间，导致后续用户重建掉话等情况。【解决措施】S1链路闪断、传输受限等问题导致的切换失败，通常是概率性出现，难以定位分析；对路测切换性能有一定影响。X2准备时间过长从eNB侧全网跟踪上看X2信令传输浪费了3s的时间。分析站点一键式日志时没有发现X2链路故障的情况：底层SCTP链路发出消息后，如果在1s内没有收到数据包的ACK响应就会发起数据包重传，如果连续

18、10次重传失败就会上报SCTP链路告警断开SCTP。初步定位是由于X2信令重传导致信令传输时延增大。经过与客户确认发现客户在近期调整传输网络，导致传输性能受到影响。出现传输问题需要及时向客户确认，以减少不必要问题定位。1.1.11 S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT（64ms），可以在信号恶化之前及时进行切换Test1 22：55：40.218 PCI48->PCI50 切换命令UE未收到分析：1、这次切换为站内切换，切换点S_RSRP、N_RSRP都比较高；在下行加载场景下，目标小区对原小区有较强的干扰。此时导频SINR<0dB，DL_IBLER&

19、gt;20%，说明切换点下行信道质量较差，导致切换命令丢失。2、切换门限2dB，UE切换测量报告中N_RSRPS_RSRP3dB。这种S_RSRP、N_RSRP都比较高的站内切换，在下行加扰场景下，切换点的下行信道质量恶劣，需要提高切换触发的及时性，在信道质量急剧恶化之前完成切换。3、为了提高切换及时性，将HO_TTT由128ms缩短至64ms。HO_TTT64ms的测试结果，在该点切换成功。提高切换及时性后，上报切换测量报告点的信道质量有所改善，SINR虽然也有显著的减低，但仍然有23dB，大于解调门限；DL_IBLER 约15%，基本收敛于目标值10%。下行信道质量不是很差，保证了切换命令

20、的正确解调。如下图：Test2 23：52：33.140 PCI48>PCI50 切换成功（HO_TTT64ms）Test3 01：06：09.937 PCI48>PCI50 切换成功（HO_TTT64ms）结论：对于S_RSRP、N_RSRP都比较高的站内切换，切换点信道质量急剧恶化，需要提高切换的及时性。建议适当改小切换门限（由3dB缩小为2dB），缩短切换触发时间TTT（由128ms缩小为64ms）。1.1.12 切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少在相同路线上进行不同切换门限对比测试（2dB切换 vs 3dB切换），有如下结果：1、3dB切

21、换的路测数据中，统计的切换次数为103次；而2dB切换时的切换次数明显增大(130次)。2、2dB切换由于切换门限变小，更容易发生乒乓切换，从而切换次数变多。同时，切换门限减少也提高了切换的及时性，使得UE在下行信道质量明显恶化之前就触发切换，提高了切换成功率。1.2 CHR分析切换问题eRAN2.1SPC400B050及以后版本合入了CHR切换维测打点，可以通过CHR分析切换问题，以下举例给出CHR分析切换问题的方法。1.2.1 站内切换，随机接入失败导致切换失败 CHR中记录的释放原因值为usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT

22、，如下图。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最大

23、重传次数配置为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是否收到切换命令切换命令HARQ反馈为ACK，说明UE收到了切换命令，如下

24、图：Step3：查找L2_L1_DEDI_PREAMBLE，分析切换随机接入过程是否成功专用Preamble收到了1条，说明UE发送一次Preamble即收到了RAR。综合以上分析，本次切换失败原因为切换完成丢失。当然，也不能完全排除随机接入失败导致的切换失败（UE没有收到RAR，而重发的Preamble eNB均没有收到）。1.2.3 X2切换，源侧等待上下文释放命令超时CHR中记录的掉话释放原因值为usRelCause: UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILStep1：“掉话前最后10条信令”分析最后10条信令显示：源侧没有收到目标侧的X2上下文释放命

25、令，定时器超时（Timer 15s）释放用户。Step2：切换流程分析1）源侧基站CHR的L2_SRB_LOG显示切换命令HARQ反馈为ACK，说明UE收到了切换命令。2）源侧基站CHR的cell_RR_RSP字段中查找本次呼叫的CRNTI=6303）目标侧基站CHR的Ho In info字段中查找SRS CRNTI=630的话单。由于目标侧站点CHR该时段信息已被冲掉，因此无法继续分析。如果有目标侧的信息，可以分析切换随机接入是否成功，是否收到切换完成，etc。1.2.4 X2切换，S1PathSwitch失败导致切换失败Step1：源侧CHR分析1）切换命令HARQ反馈为ACK，说明UE收

26、到了切换命令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本次切换的目标侧信息。2）“掉话前最后10条信令”分析：目标侧收到了切换完成；由于核心网回复S1_PATH_SWITCH_REQ_FAIL导致切换失败。综合以上分析可知，本次切换失

27、败原因为S1PathSwitch失败，非无线侧原因。1.2.5 切换随机接入失败触发重建，重建重配失败而掉话Step1：“掉话前最后10条信令”分析，切换失败重建回源侧，eNB等待重建重配完成超时（5s）释放用户。Step2：重建原因分析，切换随机接入失败触发重建1.2.6 eNB未响应UE切换测量报告，信道质量恶化而掉话Step1: “掉话前最后10条信令”分析UE不断上报切换测量报告（切换目标小区PCI320），但eNB未下发切换命令（怀疑没有配置邻区关系）；从测量报告信息可知，UE所在服务小区下行信号较弱，RSRP=-122dBm。Step2：掉话原因分析UEM_UECNT_REL_UE

28、_RLC_UNRESTORE_IND /*L2上报RLC重传次数达到最大值时的无法恢复指示消息*/该释放原因包括两种场景：1）SRB RLC达最大重传次数；2）DRB RLC达最大重传次数。L2_SRB_LOG记录了L2检测到异常前（比如，RLC达最大重传次数）最后8条下行SRB的调度情况；DRB_64MS（size=16）记录了L2检测到异常（比如，RLC达最大重传次数）前16*64ms时间内下行DRB的调度情况。下图显示，掉话前SRB正常，随后DRB出现大量NACK/DTX（DRB_64MS416均为NACK/DTX）。综合以上分析可知，eNB未响应UE切换测量报告，导致信道质量恶化，DR

29、B RLC达最大重传次数而掉话（eNB检测到RLC达最大重传次数后约延迟30s释放）。1.2.7 切换命令丢失导致切换失败CHR中记录的掉话释放原因值为5，即UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILStep1：“掉话前10条信令分析”：源测等待上下文释放命令超时而释放用户。Step2：源测CHR分析：切换命令的HARQ重传次数达到最大（ucHarqReTransTimes=4）且HARQ反馈状态为2（DTX），说明UE没有收到切换命令。综合以上分析：本次切换失败的原因为切换命令丢失。1.2.8 X2切换，Preamble丢失导致切换失败CHR中记录的掉话释放原

30、因值为5，即UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILStep1：“掉话前10条信令分析”：源测等待上下文释放命令超时而释放用户。Step2：源测CHR分析：（1）切换命令的HARQ反馈为1（ACK），说明UE收到了切换命令。（2）通过RbCellRrRsp字段的usCrnti，确定源测的CRNTI=524。 Step3：目标侧CHR分析：（1）通过HoInInfo字段，查找usSRSCRnti=524的话单。（2）目标侧CHR无L1上报Preamble字段，L2_L3释放Preamble与分配Preamble的间隔为2s，说明Preamble丢失。 综合以上分

31、析：本次切换失败的原因为Preamble丢失。1.2.9 X2切换，目标侧等待S1PathSwitchAck超时导致切换失败Step1：“掉话前最后10条信令”分析：源侧等待上下文释放命令超时释放用户。 Step2：源测CHR分析：（1）切换命令的HARQ反馈为ACK，说明UE收到了切换命令。（2）RbCellRrRsp字段显示源测的CRNTI=1006 Step3：目标侧CHR分析（1）目标侧CHR的HoInInfo字段，查找usSRSCRNTI=1006（2）目标侧最后10条信令显示：目标侧收到了切换完成消息，等待S1PathSwitchAck超时（15s）释放用户。综上所述：X2切换过程中，核心网未响应目标eNB的S1PathSwitchReq，导致切换失败。1