LTE_TDD问题定位指导书-切换篇-2013(案例后面很经典)6633.pdf

《LTE_TDD问题定位指导书-切换篇-2013(案例后面很经典)6633.pdf》由会员分享，可在线阅读，更多相关《LTE_TDD问题定位指导书-切换篇-2013(案例后面很经典)6633.pdf（59页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、修正版 产品名称Product name 密级Confidentiality level LTE TDD 内部公开 产品版本Product version Total 61 pages 共61页 LTE TDD问题定位指导书-切换篇 目 录 1 免责说明.错误!未定义书签。2 概述.4 3 切换原理.4 3.1 切换相关参数.5 3.1.1 切换门限.5 3.2 同频切换.6 3.2.1 站内切换信令交互.7 3.2.2 跨X2的站间切换信令交互.8 3.2.3 跨S1的站间切换信令交互.8 3.3 异频/异系统切换.9 3.3.1 异频切换.9 3.3.2 异系统切换.10 3.3.3 门限

2、值应用.11 3.4 切换用户面交互.13 4 切换相关KPI指标.14 4.1 切换成功率.14 4.2 切换信令面时延.14 4.3 切换用户面中断时延.14 4.3.1 上行应用层中断时延.15 4.3.2 下行应用层中断时延.15 4.3.3 网络侧上行RLC层中断时延.16 4.3.4 网络侧下行RLC层中断时延.16 修正版 4.3.5 终端侧上行RLC层中断时延.16 4.3.6 终端侧下行RLC层中断时延.16 5 切换问题定位方法.16 5.1 切换失败问题定位.16 5.1.1 UU接口信令异常.16 5.1.2 X2接口信令异常.18 5.1.3 S1接口信令异常.20

3、5.2 切换时延问题定位.22 5.2.1 切换信令时延问题定位.22 5.2.2 切换用户面时延问题定位.23 6 切换问题定位的相关操作.23 6.1 信令观察方法.23 6.1.1 网络侧观察方法.24 6.1.2 终端侧观察方法.24 6.1.3 切换相关信令的确认.24 6.2 用户面时延观察方法.26 6.2.1 应用层切换时延观察方法.26 6.2.2 RLC层切换中断时延观察方法.27 6.3 建议的解决措施.29 7 案例参考.31 7.1 切换失败问题.31 7.1.1 UE发多条测量报告仍没有收到切换命令.31 7.1.2 切换过程随机接入失败.错误!未定义书签。7.1.

4、3 加密及完整性配置问题导致消息解析失败.32 7.1.4 测量报告丢失.33 7.1.5 切换命令丢失.36 7.1.6 下行信道质量差导致发送preamble达最大次数仍未收到RAR.36 7.1.7 UE DSP切换失败，收到切换命令后不回切换完成.38 7.1.8 eNB下发RRC信令等待UE反馈，不处理切换命令.40 7.1.9 X2_IPPATH配置错误导致切换失败为例进行分析.41 修正版 7.1.10 切换点离目的小区较远 超出了Ncs_Index相应的最大理论接入半径.42 7.1.11 X2切换，源侧发出切换请求，没有收到切换响应.43 7.1.12 X2切换，目标侧发送S

5、1AP_PATH_SWITCH_REQ未收到响应.43 7.1.13 X2切换准备时间过长错过最佳切换时间.44 7.1.14 UE侧处理系统消息及切换命令流程冲突.错误!未定义书签。7.1.15 核心网功能问题导致的S1切换失败.46 7.1.16 S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT（64ms），可以在信号恶化之前及时进行切换.47 7.1.17 信号交迭区，快速触发切换容易造成频繁的切入切出，信号陡降造成切换失败 50 7.1.18 切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少.错误!未定义书签。7.1.19 外部小区配置错误导致无

6、法切换.53 7.2 切换用户面时延大问题.54 7.2.1 X2 IPPATH配置错误导致切换大时延.54 7.2.2 切换命令重传导致切换大时延.55 7.2.3 源侧数据包CRC连续错导致切换大时延.56 7.2.4 随机接入Preamble重传导致切换大时延.57 7.2.5 UE未发/晚发PDCP状态报告.58 7.2.6 UE侧处理系统消息及切换命令流程冲突.59 8 参考文档.错误!未定义书签。修正版 1 概述 无线通讯的最大特点在于其移动性控制，对于终端在不同小区间的移动，网络侧需要实时监测UE并控制在适当时刻命令UE做跨小区的切换，以保持其业务连续性。在切换的过程中，终端与网

7、络侧相互配合完成切换信令交互，尽快恢复业务，在LTE系统中，此切换过程是硬切换，业务在切换过程中是中断的，为了不影响用户业务，切换过程需要保证切换成功率、切换中断时延、切换吞吐率三个重要指标，其中最重要的是切换成功率，如果切换出现失败，将严重影响用户感受，切换中断时延和切换吞吐率也会不同程度地影响用户感受。最后对于网络中可能出现的切换问题，本文根据当前积累的LTE系统内切换问题定位经验，给出相应的问题隔离定位指导，以优化相应的网络指标。2 切换原理 切换的过程就是终端在移动过程中与网络连接交互发生变化的过程，简单的图示如下图：图1 切换前UE跟左边的基站联系 图2 切换后UE跟右边的基站联系

8、LTE系统的整个切换过程完全由网络侧（eNB）控制，所以切换UE的行为需要eNB监控，当发现UE处于切换区且存在比当前无线质量更好的小区时，根据情况适时命令UE切换到目标小区。由于eNB并不知道UE所处的位置和无线质量情况，需要控制UE上报相关的无线质量信息来判断，UE上报无线质量信息的方式有周期上报和事件上报两种方式，当前我司eNB是采用事件测量报告的方式来监控UE所处的无线质量变化临界点，当eNB收到测量或切换的事件上报时，会下发切换命令给UE，UE收到切换命令后，中断与源小区的交互，按切换命令要求切换到新的目标小区，并通过信修正版 令交互通知目标小区，以完成整个切换过程。2.1 切换相关

9、参数 为了控制切换信令流程的准确和及时，网络侧通过一些参数来控制切换的触发条件，根据我司的切换算法实现，同频切换采用A3事件来触发切换；异频切换采用A1-A2，A3-A4-A5来触发；异系统切换采用A1-A2，B1-B2来实现。当前最常用的参数有3个：切换门限、延迟触发时间、小区偏置CIO。2.1.1 切换门限 当前我司LTE系统内同频切换算法通过事件A3触发，且事件上报方式采用事件转周期的上报方式。事件A3的触发，即邻区质量高于服务小区一定偏置值。参照3GPP协议36.331规定事件A3的判决公式。触发条件：Mn+Ofn+Ocn-HysMs+Ofs+Ocs+Off 取消条件：Mn+Ofn+O

10、cn+HysThresh 取消条件：Mn+Ofn+Ocn+HysThresh 取消条件：Mn+Ofn+HysThresh B2判决公式：触发条件：Ms+HysThresh2 取消条件：Ms-HysThresh1 或 Mn+Ofn+Ocn+Hys 在UU接口体现为RRC CONNECT RECONFIG信令，UE收到此信令后，回复eNB表示收到此消息并已正确处理 UE回复eNB收到控制消息=-=-=在UU接口体现为RRC CONNECT RECONFIG CMP信令，之后UE将按测量控制要求实时测量，一旦发现满足条件，将触发切换事件测量报告 UE把测量报告发给源eNB=-=-=在UU接口体现为R

11、RC MEASUREMENT REPORT信令 源eNB收到测量报告后，进行相关条件判断，如果决定切换，网络侧将准备的相关切换资源（这个过程对UE侧不可见）网络侧准备切换相关资源，根据不同的切换场景，有不同的切换信令交互 =-=-=站内切换时，没有额外的外部信令交互 =-=-=跨X2接口的站间切换时，X2口体现为HANDOVER REQUEST和HANDOVER REQUEST ACK信令 =-=-=跨S1接口的站间切换时，源eNB侧S1口体现为HANDOVER REQUIRED、HANDVER COMMAND，目标eNB侧S1口体现为HANDOVER REQUEST、HANDOVER REQ

12、 ACK信令 源eNB下发切换命令=-=-=在UU接口体现为RRC CONNECT RECONFIG信令 UE收到切换命令后，中断与源eNB（小区）的交互，并尝试接入目标eNB（小区），这个交互过程有3条交互信息，但在标准信令接口仅体现第3条（习惯上称为MSG3）UE在目标小区发MSG3，即切换完成消息=-=-=在UU接口体现为RRC CONNECT RECONFIG CMP信令 后续的网络侧S1接口切换（只涉及站间切换，站内切换不涉及），这个过程不涉及空口，失败的概率较小，通常的切换问题定位关注较少 上面提到的测量控制和切换的交互信令，从消息名称看都相同（均为RRC CONNECT RECO

13、NFIG、和RRC CONNECT RECONFIG CMP），但重配置消息中的内容不同：修正版 图3 切换命令重配置消息 图4 测量控制重配置消息 测量控制的过程在UE接入后配置，即使此UE不在切换区或一直不切换。我们关注的切换问题通常处于触发切换（测量报告）后的过程，所以在进行切换问题定位时通常只关注从触发测量报告开始，即从测量报告消息这条信令开始。信令的交互根据切换的不同类型而不同，LTE系统内的切换类型可分为站内切换和站间切换，站间切换又分为跨X2切换和跨S1切换。各信令流程分别如下：2.2.1 站内切换信令交互 站内切换UE与eNB的交互过程如下：修正版 图5 站内切换信令流程 2.

14、2.2 跨X2的站间切换信令交互 跨X2的站间切换信令交互过程如下：Meas_RPRTHandover_RequestHandover_Request ACKRRC_CONN_RECFG(HO_CMD)SN_STATUS_TRANSFERUES_eNBT_eNBCore NetworkS1AP_PATH_SWITCH_REQS1AP_PATH_SWITCH_REQ_ACKRRC_CONN_RECFG_CMP(HO_CMP)UE_CONTEXT_RELEASERRC_CONN_RECFGRRC_CONN_RECFG_CMPUU_interfaceX2_interfaceS1_interface

15、图6 跨X2的站间切换信令流程 2.2.3 跨S1的站间切换信令交互 修正版 跨S1的站间切换信令交互过程如下：Meas_RPRTS1AP_Handover_RequiredS1AP_Handover_CMDRRC_CONN_RECFG(HO_CMD)S1AP_eNB_Status_TransferUES_eNBT_eNBCore NetworkS1AP_Handover_NotifyS1AP_UE_CONTEXT_REL_CMDRRC_CONN_RECFG_CMP(HO_CMP)RRC_CONN_RECFGRRC_CONN_RECFG_CMPUU_interfaceX2_interfaceS

16、1_interfaceS1AP_Handover_REQ_ACKS1AP_MME_Status_TransferS1AP_UE_CONTEXT_REL_CMPS1AP_Handover_Request 图7 跨S1的站间切换信令流程 2.3 异频/异系统切换 2.3.1 异频切换 异频切换实现LTE系统中不同频点的小区间切换过程。在同一个网络，不同的区域可能使用不同的频点，因此eNodeB需要在系统内支持不同频点间的切换。当服务小区存在异频邻区时：基于覆盖的异频测量由 UE 测量触发。UE 离开服务小区的覆盖范围，到达异频邻区的覆盖范围时，UE 测量到服务小区信号质量小于一定门限将触发基于覆盖

17、的异频测量。基于负载的异频测量由 eNodeB 触发。当服务小区负载达到异频负载平衡门限时，eNodeB 将根据UE 的频点支持能力、ARP（Allocation and Retention Priority）以及占用资源情况选择一定数量的UE 进行异频测量。ARP 的相关内容详细请参见 3GPP TS 23.401。基于频率优先级的异频切换只在 900MHz/2600MHz 同站同覆盖情况下进行，在 900MHz/2600MHz同站同覆盖的条件下，UE 测量到服务小区信号质量大于一定门限将触发基于频率优先级的异频测量。基于距离的异频切换由 eNodeB 根据 UE 上报的 TA 值，来估计

18、UE 相对于 eNodeB 的距离。当发现 UE 上报的 TA 值超过门限时，则认为 UE 已经移动到很远的距离，将触发基于距离的异频测量。基于距离的切换需要配置测量目标类型，当基于距离的切换参数DistBasedMeasObjType配置为EUTRAN 时，才可以触发基于距离的异频切换。基于业务的异频测量由 eNodeB 触发。eNodeB 识别拥有某种业务（如语音业务）的 UE，根据业务配置的异频频点，进行基于业务的异频测量。基于上行链路质量的异频测量由 eNodeB 触发。eNodeB 发现 UE 上行链路质量受限时，进行基于上行链路质量的异频测量。修正版 在异频测量过程中，UE发现邻区

19、信号质量大于相应的切换门限时，将触发相应的异频切换。异频切换的流程跟同频切换类似，但在UE执行测量时，需要根据eNB指示的GAP值进行。即在GAP时间内，UE暂停跟源CELL的数据交互，转而进行异频测量。图8 Intra-RAT Handover Procedure 2.3.2 异系统切换 异系统切换实现LTE到GSM（Global System for Mobile communications）/WCDMA（Wideband Code Division Multiple Access）/TD-SCDMA(Time Division-Synchronous Code Division Mul

20、tiple Access)/CDMA2000（Code Division Multiple Access）的小区间切换过程。对于不同区域可能使用不同的系统，LTE支持切换到不同系统，保证通信业务的连续性和无中断性。当服务小区存在异系统邻区时：基于覆盖的异系统测量由 UE 测量触发。UE 离开 LTE 系统的覆盖范围，进入其他系统的覆盖范围时，UE 测量到服务小区信号质量小于一定门限将触发基于覆盖的异系统测量。基于负载的异系统测量由 eNodeB 触发。当服务小区负载达到异系统负载平衡门限时，eNodeB 将根据 UE 能力、当前所进行的业务以及 ARP 选择一定数量的 UE 进行基于负载的异系

21、统测量。基于业务的异系统测量由 eNodeB 触发。eNodeB 识别拥有某种业务（如语音业务）的 UE，进行基于业务的异系统测量。基于上行链路质量的异系统测量由 eNodeB 触发。eNodeB 发现 UE 上行链路质量受限时，进行基于上行链路质量的异系统测量。基于距离的异系统切换首先由 eNodeB 根据 UE 上报的 TA 值，来估计 UE 相对于 eNodeB 的距离。当发现 UE 上报的 TA 值超过门限时，则认为 UE 已经移动到很远的距离，将触发基于距离的异系统测量。在异系统测量过程中，UE发现邻区信号质量大于相应门限时，将触发相应的异系统切换 修正版 图9 Inter RAT

22、HO procedure 2.3.3 门限值应用 在目前商用现网中异频/异系统切换的应用很少，暂不详细说明。下面以最常用的同频切换为例，说明各个参数的用途：用于事件A3评估判决的Mn和Ms测量量类型，由参数IntraFreqHoA3TrigQuan决定，该值由3GPP协议36.331规定在测量控制中的报告配置中给出，可选类型为RSRP或RSRQ，我司当前实现默认为RSRP。事件A3触发机制原理如下图所示，当事件A3在延迟触发时间TimeToTrig内都满足触发条件，则UE对事件A3进行事件转周期的上报；修正版 图10 A3触发机制图示 对于同频切换，服务小区和邻区使用相同的频点，则 Ofn 和

23、 Ofs 均为 0，服务小区的特定小区偏置，一般情况下都为 0（MOD EUTRANINTERFREQNCELL），所以 A3 事件的触发条件可以简化为：Mn-HysMs+Off 即 Mn Ms+Off+Hys 其中Off即为MML配置命令中的IntraFreqHoA3Offset参数（单位0.5dB），Hys即为MML配置命令中的IntraFreqHoA3Hyst（单位0.5dB）按当前配置：MOD INTRAFREQHOGROUP:LocalCellId=0,IntraFreqHoGroupId=0,IntraFreqHoA3Hyst=2,IntraFreqHoA3Offset=2;Mn

24、Ms+Off+Hys=Ms+2*0.5+2*0.5=Ms+2dB 即邻区比当前服务小区的RSRP高2dB则满足测量质量条件。2.3.3.1 延迟触发时间 上图中的“Time To Trigger”即是延迟触发时间，当满足事件触发条件时，为了防止不必要切换的发生，UE不要立即上报满足事件的小区信息，在延迟触发时间内持续满足相应的事件触发条件，才将满足该事件的小区测量信息向eNodeB上报。根据当前配置：ADD INTRAFREQHOGROUP:LocalCellId=0,IntraFreqHoGroupId=0,IntraFreqHoA3TimeToTrig=320ms;即延迟触发时间为320毫

25、秒，表示在320毫秒内一直满足触发条件才上报A3事件报告。2.3.3.2 小区偏置CIO 小区特定偏置CIO（Cell Individual Offset），每个服务小区和目标小区可分别独立配置。当信号波动较大，需要对某个特定小区调节切出或切入的容易程度，根据协议中的对A3触发事件的条件：Mn+Ofn+Ocn-HysMs+Ofs+Ocs+Off 修正版 根据当前我司的实现，去掉式中固定为0的项，为：Mn+Ocn-HysMs+Off 其中Ocn即为小区偏置CIO，CIO在切换中起到移动小区边界的作用。目标小区的CIO越大，切换越容易，反之亦然。我司的MRO算法可以自动调整小区偏置CIO。小区偏置

26、CIO通过测量控制消息中的Neighbour cell list中下发。当CIO不为零时，通过测量控制消息下发该邻区信息；CIO为零时，该值不下发。2.3.3.3 事件转周期上报间隔 切换事件上报后转周期上报的周期配置IntraFreqHoRprtInterval参数，当前3.0版本配置为320毫秒，表示UE在上报A3事件测量报告后，如果满足上报A3事件条件，会每隔IntraFreqHoRprtInterval毫秒后上报A3事件测量报告，直到收到切换命令或不满足A3事件条件。此参数配置越小，A3测量报告在空口的发送越快，当前此参数配置较小的320ms是为了加快L3在处理流程中，如果出现丢弃A3

27、测量报告的情况下，尽快处理后续的A3切换测量报告，通常情况下并不会发生L3丢弃A3测量报告的情况，所以此参数对切换的KPI指标影响很小。2.4 切换用户面交互 从切换的过程可以看到，LTE系统切换是硬切换，即，UE在收到切换命令后中断与源小区的交互，在UE与目标小区建立交互之前，这段时间UE与网络是没有业务数据交互的，体现为切换用户面中断，这段时间通常为几十毫秒，对业务影响比较小，但过长的中断时延将影响用户感受。切换过程中，用户面交互过程如下：图11 用户面切换过程图 根据我司当前eNodeB实现：修正版 1 源小区的下行数据在eNodeB下发切换命令的同时停止PDCP、RLC的传输，但MAC

28、的HARQ队列中可能仍有重传的数据在空口传输 2 UE在收到切换命令之后停止在源小区的上行数据发送、接收 3 UE在目标小区回复切换完成消息之后可以在目标小区发送上行数据，也可以收到目标小区的下行数据 由于跨eNodeB的切换在计时上存在偏差，不能准确定义，所以下面涉及eNodeB侧的定义均为eNodeB内切换时延定义 3 切换相关KPI指标 跟切换相关的KPI指标有切换成功率、切换信令面时延、切换用户面中断时延。3.1 切换成功率 切换成功率是从信令流程来定义的：切换成功率=切换成功次数/切换尝试次数*100%对切换成功率的统计也有不同的定义，主要差别在于切换尝试的定义，有的以测量报告为切换

29、尝试统计点，有的以切换命令为切换尝试统计点。切换成功率还可根据是在终端侧统计还是在网络侧统计，也会有不同的结果，在终端侧统计通常以路测跟踪的UE侧数据来统计，在网络侧统计则是以消息跟踪或话统数据来统计。3.2 切换信令面时延 切换信令面时延通常为从切换命令到切换完成两条消息的间隔：切换信令面时延通常以网络侧的信令跟踪来统计时延，也可以从终端侧跟踪记录的信令来统计时延，而且网络侧统计的信令时延比终端侧统计的时延要大。3.3 切换用户面中断时延 真正影响用户感受的是用户面的中断时延，所以用户面中断时延也十分重要。用户面时延在统计时分上行时延和下行时延。对上行和下行时延在实际统计时，又由于计时点选择

30、的不同，有不同的统计方法，其中应用层中断时延最接近用户感受，涉及各传输环节的还有PDCP、RLC、MAC层中断时延。修正版 上图中是终端侧和网络侧的数据传输经历的各协议层，上行数据传输路线为带箭头的黑色线，下行数据传输路线为带箭头的红线，在PDCP、IP之间有一粉红色虚线，表示这中间还存在其它传输环节，例如，用便携插数据卡终端使用时，应用层（如QQ程序）可能安装在便携机上，网络侧的QQ服务器在Internet的WebServer上。数据传输一旦出现中断（一定的时延），将在传输路线的各协议层产生相应的时延，这也就是可以在不同协议层测试时延的原因。在时延测试时，需要在相应的方向满速率灌包，以避免由

31、于应用层数据中断的原因导致测试各时延不准确。用户面中断时延的定义，通常为某协议层实体，在切换前收发的最后一个数据包到切换后收发的第一个数据包之间的间隔。根据不同的统计点，又分为终端侧统计和网络侧统计。在实际测试中，通常关注应用层和RLC层的上下行中断时延：3.3.1 上行应用层中断时延 从服务器用IP抓包软件连续捕获服务器接收到的来自UE的上行数据包，对切换期间受切换影响的、出现的最大时间间隔定义为应用层上行用户面中断时延。此定义只是比较模糊的定义，实际操作时，无法对齐“切换期间”这个时间窗，即使能严格对齐时间，也会由于应用层时延相对切换时刻会有一些滞后的时延；另外由于从服务器用IP抓包获得的

32、时间间隔抖动较大，受影响的因素包括核心网、外网、应用层数据包大小等多方面因素，“最大时间间隔”为用户面中断时延的定义不一定科学。当前的实际测试，在时延选择上，主观因素较多，暂不能给出清楚、严格的定义。测试时可通过灌UDP小包（每个包较小，通过单位时间包的个数来调整流量）的方式减小测试时延结果。3.3.2 下行应用层中断时延 修正版 从UE侧用IP抓包软件连续捕获UE接收到的来自服务器的下行数据包，对切换期间受切换影响的、出现的最大时间间隔定义为应用层上行用户面中断时延。此定义只是比较模糊的定义，实际操作时，无法对齐“切换期间”这个时间窗，即使能严格对齐时间，也会由于应用层时延相对切换时刻会有一

33、些滞后的时延；另外由于用IP抓包获得的时间间隔抖动较大，受影响的因素包括核心网、外网、应用层数据包大小、UE侧便携等多方面因素，“最大时间间隔”为用户面中断时延的定义不一定科学。当前的实际测试，在时延选择上，主观因素较多，暂不能给出清楚、严格的定义。测试时可通过灌UDP小包（每个包较小，通过单位时间包的个数来调整流量）的方式减小测试时延结果。3.3.3 网络侧上行RLC层中断时延 定义为从源侧RLC收到的最后一个PDU到目标侧RLC收到的第一个PDU时延。对于eNB内的切换可以统计此时延，但跨eNB切换时由于时钟不同步，当前无法统计。3.3.4 网络侧下行RLC层中断时延 定义为从源侧RLC下

34、发的最后一个PDU时刻到目标侧RLC下发的第一个PDU的时延，对于eNB内的切换可以统计此时延，但跨eNB切换时由于时钟不同步，当前无法统计。3.3.5 终端侧上行RLC层中断时延 定义为从UE侧RLC在源小区上行发的最后一个PDU时刻到UE侧RLC在目标小区上行发的第一个PDU的时延。3.3.6 终端侧下行RLC层中断时延 定义为从UE RLC在源小区收到的最后一个PDU时刻到UE RLC在目标小区收到第一个PDU的时延。4 切换问题定位方法 4.1 切换失败问题定位 切换失败通常是指切换的信令流程交互失败，关注点在信令的交互，只有在信令交互出现丢失或信令处理结果失败才会失败。其中信令丢失是

35、指信令在传输过程中出错或不能到达对端，信令处理结果失败是指终端或网络侧在处理信令时出现异常导致流程不能正常进行（例如切换时资源不足）。信令传输失败又可根据信令传输媒介的不同可分为无线传输失败和有线传输失败，其中X2、S1接口的传输通常为有线传输，UU口为无线传输。其中有线传输失败的概率较小，无线传输失败的概率较大，特别是信号质量较差的切换区。4.1.1 UU接口信令异常 修正版 对于切换流程，在UU接口只有三条信令：测量报告（MEASUREMENT REPORT）、切换命令(RRC CONN RECFG)、切换完成(RRC RECFG CMP)。但有时在定位切换后立即掉话或重建问题时，也关注切

36、换后的第一次重配置信令（RRC CONN RECFG）交互，严格说，切换后的重配置消息已经与切换流程没有关系，且此消息不可预期。图12 切换信令流程中UU口消息交互 UU接口信令异常的常见原因有：1)测量报告丢失，可能的原因主要有 UE上发测量报告的UL GRANT没有收到，下行PDCCH受限 UE上发的测量报告，eNB没有收到（或收到但CRC错），上行PUSCH受限 UE内部层间丢失，例如L3把测量报告给L2发送时，L2处理失败 2)切换命令丢失，可能的原因主要有 eNB因为在切换内部流程处理（如邻区漏配、资源不够等）出错，没有下发切换命令 UE下行PDCCH解析失败，下行PDCCH受限 U

37、E下行PDSCH解析失败，下行PDSCH受限 3)切换完成信令丢失，可能的原因主要有 UE在目标小区的PREAMBLE，eNB没有收到，上行PRACH受限 UE下行接收RAR失败，下行PDSCH受限 UE上发切换完成，eNB没有收到，上行PUSCH受限 UU口的传输为无线传输，其信道质量可以分为上、下行来分析。如果终端侧能够捕获RSRP、修正版 SINR、IBLER、DL/UL_Grant等信息，并配合网络侧的信令跟踪，大多情况都可以判断上、下行的问题。信道质量的观察量通常有下面几个：RSRP：RSRP为下行导频接收功率。尽管导频与数据域的信道质量有一定差异，通过导频RSRP、SINR可以大致

38、了解数据信道状况。一般RSRP-85dBm，用户位于近点；RSRP=-95dBm，用户位于中点；RSRP-105dBm，用户位于远点。判断用户近、中、远点并不能完全判断用户的信道质量，尤其在加载场景下，有可能中点、近点用户的信道质量仍然不理想（当邻区RSRP与服务小区RSRP较接近时，干扰较大），需要依据其它指标来判断信道质量。SINR：SINR为下行导频SINR。通过导频SINR可以大致了解数据信道状况。如果SINR0dB说明下行信道质量较差，当SINRPCI65 02：08：11.796 PCI264-PCI295 修正版 从 UE 层 间 消 息 分 析：发 送 测 量 报 告 时，SR

39、 达 到 最 大 重 传 次 数 触 发 随 机 接 入ID_RRC_MAC_RA_IND；且SR触发的随机接入失败，启动RRC随机接入。SR达到最大重传次数说明UE在发送测量报告时没有解到上行调度。综合以上分析，eNB未收到测量报告不是因为上行信道质量差导致的上行信令丢失，而是下行加载场景下，下行信道质量恶劣，UE解调PDCCH出错，没有解到上行调度导致测量报告没有发出去；是下行信道质量差导致的上行信令丢失。同时，我们做了相应的测试来验证我们的结论：打开上行预调度后，测量报告发不出去的次数明显减少。见下表：修正版 6.1.4 切换命令丢失 以50%Load_woICIC路测数据为例：23:4

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

41、MT跟踪看，UE发送preamble达最大次数仍没有收到RAR，如图：下图为100%Load_woICIC、100%Load_ICIC场景随机接入失败点，与目标站的距离均小于1km。cluster6小区覆盖范围较小，配置的Ncs_Index=2(相应的最大接入半径为2.15km)，不影响随机接入性能。修正版 综合以上分析，路测数据下行加载场景下的切换完成eNB未收到，是由于切换随机接入失败导致的。下行信道质量差，导致UE没有解到RAR；当preamble达到最大重传次数时，随机接入失败。6.1.6 UE DSP切换失败，收到切换命令后不回切换完成 现象：UE收到切换完成后，没有回切换完成 分析

42、：Omt层间消息分析没有回切换完成的原因：DSP切换失败。修正版 从OMT消息来看，L1 DSP1 回复HO失败的原因是：切换小区PCI10未在当前L1的邻区搜索列表中找到。LI DSP1反馈Ho失败的原因只有一个：L3下发的HO_REQ切换原语里指定的小区ID，L1在自己维护的邻区列表中没有找到该小区，无法提取TA值发给F1调整，所以上报失败FAIL。分析该切换失败点的信号情况：修正版 该点应该是PCI48与PCI50的切换区，但是在这个地方发生了PCI48PCI10的切换。观察路测线路上的RSRP情况，PCI10的RSRP基本都为140dBm，可以认为PCI10在路测线路上没有覆盖。此次切

43、换PCI48PCI10可能是PCI10偶然泄漏过来的信号导致的，信号转瞬即逝，切换时L1已将PCI10删除。6.1.7 eNB下发RRC信令等待UE反馈，不处理切换命令 eNB下发了RRC信令（比如MIMO重配消息），因为下行信道质量差，UE没有解调出来。当满足切换条件时，UE上报测量报告，而eNB正在等待上一条RRC信令的反馈，因此，不处理测量报告。当下发RRC信令达到2s后仍然收不到UE反馈，将其释放，发送RRC_CONN_REL消息。如下图：eNB侧跟踪：UE侧跟踪 修正版 6.1.8 X2_IPPATH配置错误导致切换失败为例进行分析 路测过程中，发现站点OSL355连续出现X2切换准

44、备失败，如图：从切换准备失败的原因可以大致看出：传输资源不够 或者 没有配置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）

45、；LST SCTPLNK Step2：根据SCTP链路号，查看相应X2接口标识（X2INTERFACEID）LST X2INTERFACE;Step3：根据X2接口标识，查看相应的IP配置是否正确。LST IPPATH 经过核查，发现OSL123虽然配置了与OSL355的X2接口，但是没有配置相应的IPPATH。导致OSL355向OSL123发送X2切换请求后，收到X2切换准备失败消息。配置X2_IPPATH后，切换OK。6.1.9 切换点离目的小区较远 超出了Ncs_Index相应的最大理论接入半径 eRAN1.0 Ncs_Index默认值为2，相应的最大理论接入半径为2.15km。而现网存

46、在各种覆盖情况，密集城区基站较多，小区覆盖范围较小；而郊区基站稀疏，小区覆盖范围普遍较大。如果整网使用同一个Ncs_Index，会出现适用性问题。比如，当Ncs_Index2，在密集城区、市区的接入性能正常、切换正常；当在郊区，很可能出现由于切换点、接入点离站较远，超过了相应的理论接入半径，导致接入失败、切花失败。下面截图是Norway LTE商用网，全网配置Ncs_Index2时，郊区出现随机接入失败导致的切换失败：修正版 6.1.10 X2切换，源侧发出切换请求，没有收到切换响应 左图为源侧基站消息跟踪；右图为目的侧基站消息跟踪。有时还会出现这样的情况：由于源侧收到HANDOVER_REQ

47、UEST_ACK较晚（秒级），延误了最佳切换时机，导致切换失败。6.1.11 X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应 目标侧发送S1AP_PATH_SWITCH_REQ未收到响应，导致此次切换失败。同时，eNB不会处理后面上报的切换测量报告，导致新触发的切换也失败。修正版 6.1.12 X2切换准备时间过长错过最佳切换时间 从Probe的测试数据中看到，UE在上报多次相同测量报告没有收到切换命令。根据eNB侧全网跟踪信息分析发现这种情况下源侧eNB发起X2切换请求。eNB切换X2准备时间过了很长时间才收到切换请求响应；期间，目的侧信号迅速衰减，最终目的侧eNB没

48、有接收到切换完成消息、切换失败。UE重建成功后，eNB发起对DRB的重配置消息时，UE没有收到，eNB侧RLC达到最大重传次数直接释放用户。修正版 UE切换失败后发起重建，成功后由于没有接收到DRB的重配置消息，再次发起重建，由于第一次重建eNB侧RLC达到最大重传次数释放了用户上下文，UE第二次重建被拒绝导致异常释放。PCI345小区RSRP覆盖情况良好，在切换X2准备期间，邻区信号迅速衰减，导致UE随机接入失败，目的侧没有收到切换完成，切换失败。X2准备时间过长导致切换不及时错过最佳切换时间，导致后续用户重建掉话等情况。修正版【解决措施】S1链路闪断、传输受限等问题导致的切换失败，通常是概

49、率性出现，难以定位分析；对路测切换性能有一定影响。X2准备时间过长从eNB侧全网跟踪上看X2信令传输浪费了3s的时间。分析站点一键式日志时没有发现X2链路故障的情况：底层SCTP链路发出消息后，如果在1s内没有收到数据包的ACK响应就会发起数据包重传，如果连续10次重传失败就会上报SCTP链路告警断开SCTP。初步定位是由于X2信令重传导致信令传输时延增大。经过与客户确认发现客户在近期调整传输网络，导致传输性能受到影响。出现传输问题需要及时向客户确认，以减少不必要问题定位。6.1.13 核心网功能问题导致的S1切换失败 时间点：00：55：51.468 PCI228(OSL131)PCI124

50、(OSL182)现象：原侧发S1AP_HANDOVER_REQUEST，目的侧没有收到。UE接收系统消息与切换命令流程冲突的问题，eRAN1.0 360 UE版本进行了优化。下面主要对S1切换进行分析。eNB侧数据分析：OSL131站点PCI228与OSL182站点PCI124在00:55:44收到UE上报的124小区测量报告，发起S1切换。10秒后才收到切换取消响应；15秒后原侧因为没有收到切换请求响应而取消切换流程。整个切换准备没有完成，UE本身并不知道开始切换，所以一直在上报测量报告。值得注意的是在等待切换准备响应的过程中eNB一直收到S1AP的释放消息，原因是之前的一次124切换到22