LTETDD切换问题定位指导书

1、 LTE TDD 问题定位指导书-切换篇 文档密级：内部公开产品名称Product name密级Confidentiality levelLTE TDD产品版本Product versionKoukou 277764781 LTE TDD问题定位指导书-切换篇目 录1免责说明62概述63切换原理63.1切换相关参数73.1.1切换门限73.2同频切换83.2.1站内切换信令交互103.2.2跨X2的站间切换信令交互103.2.3跨S1的站间切换信令交互113.3异频/异系统切换113.3.1异频切换123.3.2异系统切换123.3.3门限值应用133.4切换用户面交互154切换相关KPI指标

2、164.1切换成功率164.2切换信令面时延174.3切换用户面中断时延174.3.1上行应用层中断时延184.3.2下行应用层中断时延184.3.3网络侧上行RLC层中断时延184.3.4网络侧下行RLC层中断时延184.3.5终端侧上行RLC层中断时延184.3.6终端侧下行RLC层中断时延185切换问题定位方法195.1切换失败问题定位195.1.1UU接口信令异常195.1.2X2接口信令异常215.1.3S1接口信令异常225.2切换时延问题定位245.2.1切换信令时延问题定位245.2.2切换用户面时延问题定位256切换问题定位的相关操作256.1信令观察方法256.1.1网络侧

3、观察方法266.1.2终端侧观察方法266.1.3切换相关信令的确认266.2用户面时延观察方法286.2.1应用层切换时延观察方法286.2.2RLC层切换中断时延观察方法296.3建议的解决措施317案例参考337.1切换失败问题337.1.1UE发多条测量报告仍没有收到切换命令337.1.2切换过程随机接入失败347.1.3加密及完整性配置问题导致消息解析失败367.1.4测量报告丢失367.1.5切换命令丢失397.1.6下行信道质量差导致发送preamble达最大次数仍未收到RAR407.1.7UE DSP切换失败，收到切换命令后不回切换完成427.1.8eNB下发RRC信令等待UE

4、反馈，不处理切换命令437.1.9X2_IPPATH配置错误导致切换失败为例进行分析447.1.10切换点离目的小区较远 超出了Ncs_Index相应的最大理论接入半径467.1.11X2切换，源侧发出切换请求，没有收到切换响应467.1.12X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应477.1.13X2切换准备时间过长错过最佳切换时间477.1.14UE侧处理系统消息及切换命令流程冲突497.1.15核心网功能问题导致的S1切换失败507.1.16S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT（64ms），可以在信号恶化之前及时进行切换527.

5、1.17信号交迭区，快速触发切换容易造成频繁的切入切出，信号陡降造成切换失败557.1.18切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少587.1.19外部小区配置错误导致无法切换587.2切换用户面时延大问题607.2.1X2 IPPATH配置错误导致切换大时延607.2.2切换命令重传导致切换大时延607.2.3源侧数据包CRC连续错导致切换大时延617.2.4随机接入Preamble重传导致切换大时延627.2.5UE未发/晚发PDCP状态报告637.2.6UE侧处理系统消息及切换命令流程冲突648参考文档64 1 概述无线通讯的最大特点在于其移动性控制，对于终

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

7、移动过程中与网络连接交互发生变化的过程，简单的图示如下图： 图1 切换前UE跟左边的基站联系图2 切换后UE跟右边的基站联系LTE系统的整个切换过程完全由网络侧（eNB）控制，所以切换UE的行为需要eNB监控，当发现UE处于切换区且存在比当前无线质量更好的小区时，根据情况适时命令UE切换到目标小区。由于eNB并不知道UE所处的位置和无线质量情况，需要控制UE上报相关的无线质量信息来判断，UE上报无线质量信息的方式有周期上报和事件上报两种方式，当前我司eNB是采用事件测量报告的方式来监控UE所处的无线质量变化临界点，当eNB收到测量或切换的事件上报时，会下发切换命令给UE，UE收到切换命令后，中

8、断与源小区的交互，按切换命令要求切换到新的目标小区，并通过信令交互通知目标小区，以完成整个切换过程。2.1 切换相关参数为了控制切换信令流程的准确和及时，网络侧通过一些参数来控制切换的触发条件，根据我司的切换算法实现，同频切换采用A3事件来触发切换；异频切换采用A1-A2，A3-A4-A5来触发；异系统切换采用A1-A2，B1-B2来实现。当前最常用的参数有3个：切换门限、延迟触发时间、小区偏置CIO。2.1.1 切换门限当前我司LTE系统内同频切换算法通过事件A3触发，且事件上报方式采用事件转周期的上报方式。事件A3的触发，即邻区质量高于服务小区一定偏置值。参照3GPP协议36.331规定事

9、件A3的判决公式。触发条件： Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off取消条件： Mn+Ofn+Ocn+Hys<Ms+Ofs+Ocs+Off异频切换时，使用A1/A2来触发异频或异系统测量，而用A3、A4或A5进行切换判决的触发。目前切换判决使用哪个事件触发可以在基站侧进行配置。A4判决公式。（A5事件可参考3GPP协议36.331）触发条件：Mn+Ofn+Ocn-Hys>Thresh取消条件：Mn+Ofn+Ocn+Hys<Thresh异系统切换时，使用B1，B2触发切换判决。B1判决公式：触发条件：Mn+Ofn-Hys>Thresh取消条件：M

10、n+Ofn+Hys<ThreshB2判决公式：触发条件：Ms+Hys<Thresh1 且 Mn+Ofn+Ocn-Hys>Thresh2取消条件：Ms-Hys>Thresh1 或 Mn+Ofn+Ocn+Hys<Thresh2公式中的变量有如下定义：Ø Mn是邻区测量结果。Ø Ofn是邻区频率的特定频率偏置，采用默认值0，同频切换可以不考虑。Ø Ocn是邻区的特定小区偏置，由参数CellIndividualOffset决定。当该值不为零，此参数在测量控制消息中下发；否则当该值为零时不下发，该参数较多地用于提前切换或推迟切换。Ø

11、Ms是服务小区的测量结果。Ø Ofs是服务小区的特定频率偏置，采用默认值0，同频切换可以不考虑。Ø Ocs是服务小区的特定小区偏置，该值通常为零。Ø Hys是事件迟滞参数，在测量控制消息中下发。Ø Off是事件偏置参数，该参数针对事件设置，用于调节切换的难易程度，该值与测量值相加用于事件触发和取消的评估。此参数在测量控制消息的测量对象中下发，可取正值或负值，当取正值时，此时增加事件触发的难度，延缓切换；当取负值时，此时降低事件触发的难度，提前进行切换。2.2 同频切换要完成切换过程，UE与eNB需要配合，此配合是通过信令来交互信息的。完整信令交互过程是：

12、Ø 源eNB控制UE测量 =-=-=> 在UU接口体现为RRC CONNECT RECONFIG信令，UE收到此信令后，回复eNB表示收到此消息并已正确处理Ø UE回复eNB收到控制消息=-=-=> 在UU接口体现为RRC CONNECT RECONFIG CMP信令，之后UE将按测量控制要求实时测量，一旦发现满足条件，将触发切换事件测量报告Ø UE把测量报告发给源eNB =-=-=> 在UU接口体现为RRC MEASUREMENT REPORT信令源eNB收到测量报告后，进行相关条件判断，如果决定切换，网络侧将准备的相关切换资源（这个过程对UE

13、侧不可见）Ø 网络侧准备切换相关资源，根据不同的切换场景，有不同的切换信令交互² =-=-=> 站内切换时，没有额外的外部信令交互² =-=-=> 跨X2接口的站间切换时，X2口体现为HANDOVER REQUEST和HANDOVER REQUEST ACK信令² =-=-=> 跨S1接口的站间切换时，源eNB侧S1口体现为HANDOVER REQUIRED 、HANDVER COMMAND，目标eNB侧S1口体现为HANDOVER REQUEST、HANDOVER REQ ACK信令Ø 源eNB下发切换命令 =-=-=>

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

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

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

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

18、于距离的异频测量。基于距离的切换需要配置测量目标类型，当基于距离的切换参数DistBasedMeasObjType配置为EUTRAN时，才可以触发基于距离的异频切换。l 基于业务的异频测量由eNodeB触发。eNodeB识别拥有某种业务（如语音业务）的UE，根据业务配置的异频频点，进行基于业务的异频测量。l 基于上行链路质量的异频测量由eNodeB触发。eNodeB发现UE上行链路质量受限时，进行基于上行链路质量的异频测量。在异频测量过程中，UE发现邻区信号质量大于相应的切换门限时，将触发相应的异频切换。异频切换的流程跟同频切换类似，但在UE执行测量时，需要根据eNB指示的GAP值进行。即在G

19、AP时间内，UE暂停跟源CELL的数据交互，转而进行异频测量。图8 Intra-RAT Handover Procedure2.3.2 异系统切换异系统切换实现LTE到GSM（Global System for Mobile communications）/WCDMA（Wideband Code Division Multiple Access）/TD-SCDMA(Time Division-Synchronous Code Division Multiple Access )/CDMA2000（Code Division Multiple Access）的小区间切换过程。对于不同区域可能使用

20、不同的系统，LTE支持切换到不同系统，保证通信业务的连续性和无中断性。当服务小区存在异系统邻区时：l 基于覆盖的异系统测量由UE测量触发。UE离开LTE系统的覆盖范围，进入其他系统的覆盖范围时，UE测量到服务小区信号质量小于一定门限将触发基于覆盖的异系统测量。l 基于负载的异系统测量由eNodeB触发。当服务小区负载达到异系统负载平衡门限时，eNodeB将根据UE能力、当前所进行的业务以及ARP选择一定数量的UE进行基于负载的异系统测量。l 基于业务的异系统测量由eNodeB触发。eNodeB识别拥有某种业务（如语音业务）的UE，进行基于业务的异系统测量。l 基于上行链路质量的异系统测量由eN

21、odeB触发。eNodeB发现UE上行链路质量受限时，进行基于上行链路质量的异系统测量。l 基于距离的异系统切换首先由eNodeB根据UE上报的TA值，来估计UE相对于eNodeB的距离。当发现UE上报的TA值超过门限时，则认为UE已经移动到很远的距离，将触发基于距离的异系统测量。在异系统测量过程中，UE发现邻区信号质量大于相应门限时，将触发相应的异系统切换图9 Inter RAT HO procedure2.3.3 门限值应用在目前商用现网中异频/异系统切换的应用很少，暂不详细说明。下面以最常用的同频切换为例，说明各个参数的用途：用于事件A3评估判决的Mn和Ms测量量类型，由参数IntraF

22、reqHoA3TrigQuan决定，该值由3GPP协议36.331规定在测量控制中的报告配置中给出，可选类型为RSRP或RSRQ，我司当前实现默认为RSRP。事件A3触发机制原理如下图所示，当事件A3在延迟触发时间TimeToTrig内都满足触发条件，则UE对事件A3进行事件转周期的上报； 图10 A3触发机制图示对于同频切换，服务小区和邻区使用相同的频点，则Ofn和Ofs均为0，服务小区的特定小区偏置，一般情况下都为0（MOD EUTRANINTERFREQNCELL），所以A3事件的触发条件可以简化为：Mn -Hys>Ms +Off 即 Mn > Ms +Off + Hys其中

23、Off即为MML配置命令中的IntraFreqHoA3Offset参数（单位0.5dB），Hys即为MML配置命令中的IntraFreqHoA3Hyst（单位0.5dB）按当前配置：MOD INTRAFREQHOGROUP: LocalCellId=0, IntraFreqHoGroupId=0, IntraFreqHoA3Hyst=2, IntraFreqHoA3Offset=2;Mn > Ms +Off + Hys = Ms + 2* 0.5 + 2 * 0.5 = Ms + 2dB即邻区比当前服务小区的RSRP高2dB则满足测量质量条件。2.3.3.1 延迟触发时间上图中的“Tim

24、e To Trigger”即是延迟触发时间，当满足事件触发条件时，为了防止不必要切换的发生，UE不要立即上报满足事件的小区信息，在延迟触发时间内持续满足相应的事件触发条件，才将满足该事件的小区测量信息向eNodeB上报。根据当前配置：ADD INTRAFREQHOGROUP: LocalCellId=0, IntraFreqHoGroupId=0, IntraFreqHoA3TimeToTrig=320ms;即延迟触发时间为320毫秒，表示在320毫秒内一直满足触发条件才上报A3事件报告。2.3.3.2 小区偏置CIO小区特定偏置CIO（Cell Individual Offset），每个服务

25、小区和目标小区可分别独立配置。当信号波动较大，需要对某个特定小区调节切出或切入的容易程度，根据协议中的对A3触发事件的条件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off根据当前我司的实现，去掉式中固定为0的项，为：Mn +Ocn-Hys>Ms +Off其中Ocn即为小区偏置CIO，CIO在切换中起到移动小区边界的作用。目标小区的CIO越大，切换越容易，反之亦然。我司的MRO算法可以自动调整小区偏置CIO。小区偏置CIO通过测量控制消息中的Neighbour cell list中下发。当CIO不为零时，通过测量控制消息下发该邻区信息；CIO为零时，该值不下发。2.3.3

26、.3 事件转周期上报间隔切换事件上报后转周期上报的周期配置IntraFreqHoRprtInterval参数，当前3.0版本配置为320毫秒，表示UE在上报A3事件测量报告后，如果满足上报A3事件条件，会每隔IntraFreqHoRprtInterval毫秒后上报A3事件测量报告，直到收到切换命令或不满足A3事件条件。此参数配置越小，A3测量报告在空口的发送越快，当前此参数配置较小的320ms是为了加快L3在处理流程中，如果出现丢弃A3测量报告的情况下，尽快处理后续的A3切换测量报告，通常情况下并不会发生L3丢弃A3测量报告的情况，所以此参数对切换的KPI指标影响很小。2.4 切换用户面交互从

27、切换的过程可以看到，LTE系统切换是硬切换，即，UE在收到切换命令后中断与源小区的交互，在UE与目标小区建立交互之前，这段时间UE与网络是没有业务数据交互的，体现为切换用户面中断，这段时间通常为几十毫秒，对业务影响比较小，但过长的中断时延将影响用户感受。切换过程中，用户面交互过程如下：图11 用户面切换过程图根据我司当前eNodeB实现：1 源小区的下行数据在eNodeB下发切换命令的同时停止PDCP、RLC的传输，但MAC的HARQ队列中可能仍有重传的数据在空口传输2 UE在收到切换命令之后停止在源小区的上行数据发送、接收3 UE在目标小区回复切换完成消息之后可以在目标小区发送上行数据，也可

28、以收到目标小区的下行数据由于跨eNodeB的切换在计时上存在偏差，不能准确定义，所以下面涉及eNodeB侧的定义均为eNodeB内切换时延定义3 切换相关KPI指标跟切换相关的KPI指标有切换成功率、切换信令面时延、切换用户面中断时延。3.1 切换成功率切换成功率是从信令流程来定义的：切换成功率 = 切换成功次数 / 切换尝试次数 * 100%对切换成功率的统计也有不同的定义，主要差别在于切换尝试的定义，有的以测量报告为切换尝试统计点，有的以切换命令为切换尝试统计点。切换成功率还可根据是在终端侧统计还是在网络侧统计，也会有不同的结果，在终端侧统计通常以路测跟踪的UE侧数据来统计，在网络侧统计则

29、是以消息跟踪或话统数据来统计。3.2 切换信令面时延切换信令面时延通常为从切换命令到切换完成两条消息的间隔：切换信令面时延通常以网络侧的信令跟踪来统计时延，也可以从终端侧跟踪记录的信令来统计时延，而且网络侧统计的信令时延比终端侧统计的时延要大。3.3 切换用户面中断时延真正影响用户感受的是用户面的中断时延，所以用户面中断时延也十分重要。用户面时延在统计时分上行时延和下行时延。对上行和下行时延在实际统计时，又由于计时点选择的不同，有不同的统计方法，其中应用层中断时延最接近用户感受，涉及各传输环节的还有PDCP、RLC、MAC层中断时延。上图中是终端侧和网络侧的数据传输经历的各协议层，上行数据传输

30、路线为带箭头的黑色线，下行数据传输路线为带箭头的红线，在PDCP、IP之间有一粉红色虚线，表示这中间还存在其它传输环节，例如，用便携插数据卡终端使用时，应用层（如QQ程序）可能安装在便携机上，网络侧的QQ服务器在Internet的WebServer上。数据传输一旦出现中断（一定的时延），将在传输路线的各协议层产生相应的时延，这也就是可以在不同协议层测试时延的原因。在时延测试时，需要在相应的方向满速率灌包，以避免由于应用层数据中断的原因导致测试各时延不准确。用户面中断时延的定义，通常为某协议层实体，在切换前收发的最后一个数据包到切换后收发的第一个数据包之间的间隔。根据不同的统计点，又分为终端侧统

31、计和网络侧统计。在实际测试中，通常关注应用层和RLC层的上下行中断时延：3.3.1 上行应用层中断时延从服务器用IP抓包软件连续捕获服务器接收到的来自UE的上行数据包，对切换期间受切换影响的、出现的最大时间间隔定义为应用层上行用户面中断时延。此定义只是比较模糊的定义，实际操作时，无法对齐“切换期间”这个时间窗，即使能严格对齐时间，也会由于应用层时延相对切换时刻会有一些滞后的时延；另外由于从服务器用IP抓包获得的时间间隔抖动较大，受影响的因素包括核心网、外网、应用层数据包大小等多方面因素，“最大时间间隔”为用户面中断时延的定义不一定科学。当前的实际测试，在时延选择上，主观因素较多，暂不能给出清楚

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

33、时延选择上，主观因素较多，暂不能给出清楚、严格的定义。测试时可通过灌UDP小包（每个包较小，通过单位时间包的个数来调整流量）的方式减小测试时延结果。3.3.3 网络侧上行RLC层中断时延定义为从源侧RLC收到的最后一个PDU到目标侧RLC收到的第一个PDU时延。对于eNB内的切换可以统计此时延，但跨eNB切换时由于时钟不同步，当前无法统计。3.3.4 网络侧下行RLC层中断时延定义为从源侧RLC下发的最后一个PDU时刻到目标侧RLC下发的第一个PDU的时延，对于eNB内的切换可以统计此时延，但跨eNB切换时由于时钟不同步，当前无法统计。3.3.5 终端侧上行RLC层中断时延定义为从UE侧RLC

34、在源小区上行发的最后一个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)。但有时在定位切换后立即掉话或重建问题时，也关注切换后的第一次重配置信令（RRC CONN RECFG）交互，严格说，切换后的重配置消息已经与切换流程没有关系，且此消息不可预期。图12 切换信令流程中UU口消息交互UU接口信令异常的常见原因有：1) 测量报告丢失，可能

36、的原因主要有Ø UE上发测量报告的UL GRANT没有收到，下行PDCCH受限Ø UE上发的测量报告，eNB没有收到（或收到但CRC错），上行PUSCH受限Ø UE内部层间丢失，例如L3把测量报告给L2发送时，L2处理失败2) 切换命令丢失，可能的原因主要有Ø eNB因为在切换内部流程处理（如邻区漏配、资源不够等）出错，没有下发切换命令Ø UE下行PDCCH解析失败，下行PDCCH受限Ø UE下行PDSCH解析失败，下行PDSCH受限3) 切换完成信令丢失，可能的原因主要有Ø UE在目标小区的PREAMBLE，eNB没有收到

37、，上行PRACH受限Ø UE下行接收RAR失败，下行PDSCH受限Ø UE上发切换完成，eNB没有收到，上行PUSCH受限UU口的传输为无线传输，其信道质量可以分为上、下行来分析。如果终端侧能够捕获RSRP、SINR、IBLER、DL/UL_Grant等信息，并配合网络侧的信令跟踪，大多情况都可以判断上、下行的问题。信道质量的观察量通常有下面几个：Ø RSRP：RSRP为下行导频接收功率。尽管导频与数据域的信道质量有一定差异，通过导频RSRP、SINR可以大致了解数据信道状况。一般RSRP>-85dBm，用户位于近点；RSRP=-95dBm，用户位于中点；R

38、SRP<-105dBm，用户位于远点。判断用户近、中、远点并不能完全判断用户的信道质量，尤其在加载场景下，有可能中点、近点用户的信道质量仍然不理想（当邻区RSRP与服务小区RSRP较接近时，干扰较大），需要依据其它指标来判断信道质量。Ø SINR：SINR为下行导频SINR。通过导频SINR可以大致了解数据信道状况。如果SINR<0dB说明下行信道质量较差，当SINR<-3dB说明下行信道质量恶劣，处于解调门限附近，容易造成切换信令丢失，导致切换失败。上行SINR可以通过LMT用户性能跟踪获得。Ø IBLER：正常情况下，IBLER应该收敛到目标值（目标值

39、为10%，当信道质量很好时IBLER接近或等于0%）；如果IBLER偏高说明信道质量较差，数据误码较多，很容易造成掉话、切换失败、或者切换大时延。下行IBLER可以从probe中获得，而上行IBLER通过LMT用户性能跟踪获得的数据较之probe准确。Ø PDCCH DL：从DL_Grant可以得知UE正确解调PDCCH的个数。当上/下行数据源足够（如上/下行UDP最大能力灌包）时，eNB每个TTI均调度用户，PDCCH个数为800(sa 3:1下)。若DL_Grant800，说明PDCCH解调正常，信道质量正常；若DL _Grant偏低，说明PDCCH解调有错，信道质量可能比较差。

40、在判断上、下行信道质量时，有时不能完成任L3上下行信令是否丢失来判断。例如，下行信道质量差不仅会影响下行信令的解调，下行PDCCH解调错误也会影响上行调度，造成上行信令丢失。信道质量问题通常是因为弱覆盖或干扰引起。对于空口问题定位，需要把问题定位到覆盖（弱覆盖、越区覆盖等）、干扰、邻区漏配、切换不及时等几类，再采用相应的解决措施解决问题。4.1.2 X2接口信令异常对于切换流程，只有经过X2的站间切换在X2口有切换流程的信令：在X2接口通常情况下有如下4条信令：切换请求（HANDOVER REQUEST）、切换响应(HANDOVER REQUEST ACK)、SN状态转发(SN STATUS

41、TRANSFER)、UE上下文释放（UE CONTEST RELEASE），如下图中红色信令：图13 切换信令流程中X2口消息交互X2接口信令异常的常见原因有：1) 切换请求丢失，可能的原因主要有Ø eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败Ø X2口传输异常，如传输丢包2) 切换响应丢失，可能的原因主要有Ø 源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVER CANCEL信令Ø 目标小区切换准备异常，这时通常会在X2口出现 HANDOVER PREPARATION FAILURE信令Ø X2口传

42、输异常，如传输丢包3) SN状态前转信令丢失，可能的原因主要有Ø X2口传输异常，如传输丢包Ø 源小区内部错4) UE上下文释放信令丢失，可能的原因主要有Ø X2口传输异常，如传输丢包Ø 目标小区收到切换完成后内部处理错，导致没有进行S1 PATH切换Ø S1 PATH切换失败对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。4.1.3 S1接口信令异常对于切换流程，只要是跨eNB切换，不管是经S1切换还是经X2切换，在S1口均有信令交互：

43、在经X2接口切换时，S1接口仅有两条信令：S1AP PATH SWITCH REQ、S1AP PATH SWITCH REQ ACK；在经S1接口切换时，S1接口信令会在源eNB和目标eNB有较多的交互。如下图绿色信令所示：图14 切换信令流程中S1口消息交互图15 切换信令流程中S1口消息交互X2接口信令异常的常见原因有：1) 跨X2切换的S1AP PATH SWITCH REQ丢失，可能的原因主要有Ø 目标eNB内部处理切换完成信令失败Ø S1口传输异常，如传输丢包2) 跨X2切换的S1AP PATH SWITCH REQ ACK丢失，可能的原因主要有Ø 核心

44、网收到S1AP PATH SWITCH REQ消息后，内部处理失败3) 跨S1切换的S1AP HANDOVER REQUIRTED信令丢失，可能的原因主要有Ø 源小区因为在切换内部流程处理出错（如邻区漏配、资源不够等），没有发切换请求消息S1AP HANDOVER REQUIRTEDØ S1口传输异常，传输过程中丢失4) 跨S1切换的S1AP HANDOVER REQUEST信令丢失，可能的原因主要有Ø 核心网收到S1AP HANDOVER REQUIRTED后，内部处理出错Ø S1口传输异常，传输过程中丢失5) 跨S1切换的S1AP HANDOVER

45、REQUEST ACK信令丢失，可能的原因主要有Ø 目标小区收到S1AP HANDOVER REQUEST后，内部处理出错（如资源不足等）Ø S1口传输异常，传输过程中丢失6) 跨S1切换的S1 HANDOVER CMD信令丢失，可能的原因主要有Ø 核心网收到S1AP HANDOVER REQUEST ACK后，内部处理出错Ø S1口传输异常，传输过程中丢失7) 跨S1切换的S1AP ENB STATUS TRANSFER信令丢失，可能的原因主要有Ø 源小区处理收到S1 HANDOVER CMD后，内部处理出错Ø S1口传输异常，传输

46、过程中丢失8) 跨S1切换的S1AP MME STATUS TRANSFER信令丢失，可能的原因主要有Ø 核心网收到S1AP ENB STATUS TRANSFER后，内部处理出错Ø S1口传输异常，传输过程中丢失9) 跨S1切换的S1AP HANDOVER NOTIFY信令丢失，可能的原因主要有Ø 目标小区收到切换完成消息后，内部处理出错Ø S1口传输异常，传输过程中丢失10) 跨S1切换的S1AP UE CONTEST REL CMD信令丢失，可能的原因主要有Ø 核心网收到S1AP HANDOVER NOTIFY后，内部处理出错Ø

47、 S1口传输异常，传输过程中丢失11) 跨S1切换的S1AP UE CONTEST REL CMP信令丢失，可能的原因主要有Ø 源小区收到S1AP UE CONTEST REL CMD后，内部处理出错Ø S1口传输异常，传输过程中丢失对于S1口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。4.2 切换时延问题定位切换时延包括信令面时延和用户面时延。4.2.1 切换信令时延问题定位切换信令时延根据观察点的不同，可以定义终端侧切换信令时延、网络侧切换信令时延，统计方法均为从切换

48、命令到切换完成消息之间的时延，由于网络侧的切换信令时延包括两次空口传输时延，所以通常网络侧的切换信令时延大于终端侧的切换信令时延。而网络侧在统计切换时延时涉及跨ENB的时钟不能准确对齐，所以通常只能统计站内切换的网络侧切换信令时延。以三星UE为例，终端侧的切换信令时延约31ms（华为UE约8ms），网络侧的（站内）切换信令时延约38ms。切换信令时延为切换命令到切换完成两条信令之间的时延，从终端侧看，切换信令时延主要包括切换信令处理时延、目标小区同步时延、目标小区接入时延三部分，其中目标小区接入时延占主要部分。从网络侧看，切换信令时延包括终端侧的切换信令时延之外，还包括两条切换信令在空口的传输

49、时延。通常情况下，如果信令时延出现过大的问题，主要原因有：Ø 切换命令出现空口重传，此时延体现在网络侧切换信令中断时延Ø 目标小区接入尝试多次，此时延体现在终端、网络侧Ø PRACH调度周期大时，信令时延稍有增大要定位切换信令时延的问题，需要从终端侧结合网络侧跟踪比较详细的内部消息来定位。当前主要依靠网络侧、终端侧的TTI数据跟踪来定位。4.2.2 切换用户面时延问题定位切换用户面时延根据不同的测量点，有不同的时延定义。其中跟用户感受最相关的是应用层数据时延，测试时通常以服务器侧或终端应用层侧的IP层数据为测量点来观察应用层切换时延。由于应用层的时延跨接入网和核心

50、网及公网，其时延的影响范围较大，不能仅从接入网来定位，所以为了观测接入网侧的切换用户面中断时延，通常在接入网侧的RLC设置观测点，即RLC切换用户面中断时延。从数据的流向，切换时延还分上行和下行时延。当前由于时间对齐问题，对接入网的时延观测仅只能从终端内部输出RLC层的上下行时延（后续可提需求在eNB实现站内切换的RLC观测点）。以华为UE为例，当前切换的下行RLC层切换用户面中断时延约34ms，IP应用层的切换用户面中断时延波动较大，上行约120ms，下行约60ms。在接入网侧影响切换用户面中断时延的主要原因有：Ø eNB下发的切换命令出现重传，导致下行用户面挂起时延较长Ø

51、; 切换区空口质量不好，导致上行或下行的用户面数据重传，直接影响用户面切换中断时延Ø 目标小区接入时延大，导致用户面数据恢复较慢Ø X2或S1接口传输时延大，主要影响应用层时延Ø PRACH调度周期大时，信令时延稍有增大要定位切换用户面时延问题，需要从终端侧结合网络侧跟踪比较详细的信息来定位。当前主要依靠网络侧、终端侧的TTI数据跟踪来定位。5 切换问题定位的相关操作对于单个的切换问题在定位之前，先要确定是信令还是用户面的问题。通常的切换失败和切换的信令时延问题都需要从信令的交互去分析；切换的用户面时延问题则要从用户面的数据调度交互去定位。5.1 信令观察方法信令

52、既可以在网络侧跟踪也可以在终端侧跟踪。在定位切换失败问题和切换信令时延问题时需要跟踪信令进行定位。5.1.1 网络侧观察方法在eNB侧可以用LMT软件跟踪网络侧UU、X2、S1接口的信令，也可以在M2000启动单用户跟踪。再根据上一章描述的信令交互流程来判断失败点。信令时延在跨eNB切换时由于两个eNB的时钟难以对齐，不便获取，同一eNB内的切换可以通过LMT跟踪UU口的消息来计算时延，如下图的切换时延为：7568473 7530630 = 37843 us，即37.843 ms图16 网络侧信令跟踪的切换信令交互（UU口）5.1.2 终端侧观察方法信令在终端侧需要通过相应的终端软件来配合跟踪

53、UE的信令，如三星UE可用X-CAL软件，华为UE可用PROBE软件来跟踪UE侧信令交互。再根据上一章描述的信令交互流程来判断失败点。信令时延可以通过跟踪的UU口的消息来计算，以下图中华为UE记录的PROBE数据为例，切换信令时延为：597054419 - 597047103 597054419 = 7316 us，即7.316 ms图17 PROBE跟踪华为UE的切换信令交互图5.1.3 切换相关信令的确认由于切换信令过程中的切换测量控制、切换命令都是用RRCConnextionReconfiguration消息承载下发的，而RRCConnextionReconfiguration还可承载其

54、它的测量控制及信令控制信息；切换测量报告MeasurementReport也不只是切换的测量报告，还可承载其它（如ICIC、异频、异系统）测量报告信息。所以在问题定位时，有必要区分这些消息是否切换相关的信令。在测量控制消息中，打开RRCConnectionReconfiguration消息，如果存在measConfig信元，则是测量控制消息，如果存在eventA3且其a3-offse与hysteresis为非负值，则说明此事件是切换测量控制（按当前产品实现的通常配置），其ReportConfigIdg对应的measId即是切换测量ID，如下图所示：图18 切换测量控制消息确认打开measure

55、mentReport消息，其中的measId与切换测量控制中的切换测量Id相同，则此测量报告是切换的A3测量报告，如下图所示：图19 切换测量报告消息确认打开MeasurementReport后面的RRCConnectionReconfiguration消息，存在targetPhysCellId信元的RRCConnectionReconfiguration消息即是切换命令，如下图所示：图20 切换命令消息确认5.2 用户面时延观察方法用户面时延实际测试通常测试应用层（IP）用户面时延，即通过在终端侧（便携）或服务器（SERVER）侧安装IP抓包工具软件来测试。如果要关注接入网侧的时延，通常测试

56、RLC层时延。5.2.1 应用层切换时延观察方法应用层的切换中断时延是通过捕获IP层的包的时间点来计算的，所以不管是上行还是下行，其方法相同，不同的只是下行在终端侧（如便携）抓包，上行在服务器（SERVER）侧抓包，常用的抓包工具有Ethereal和Wireshark。图21 IP层抓包图在确定IP层切换中断时延时，按前面的定义，由于实际切换时间点与抓包软件记录的时间点无法精确到毫秒级，仍需要主观判断来确定，使测试出现一定的主观偏差。下行应用层中断时延也可以用三星UE的X-CAL工具测试IP层时延：打开MessagePacket Capture View，再点击FileMenuManual C

57、apture，选中Ue跟踪到数据包：图22 X-CAL软件抓包图5.2.2 RLC层切换中断时延观察方法RLC层的切换中断时延既可在UE侧也可在网络侧通过数据输出来观察其上、下行切换中断时延，下面分别从终端侧和网络侧说明如何操作。5.2.2.1 终端侧观察方法以PROBE与华为UE为例，在华为UE的控制软件OMT上设置中断时延上报（由于切换中断时延的上报会对峰值测试产生影响，中断时延的上报开关默认关闭）：打开OMT开关后，Probe中会有切换中断时延统计，可直接显示RLC层的上、下行切换用户面中断时延，如下图中，RLC层下行中断时延为29197us，即29.197ms，RLC层上行中断时延为17181us，即17.181ms。图23 PROBE显示的L2切换用户面中断时延图5.2.2.2 网络侧观察方法对于跨eNB的切换，目前在没有对齐两个eNB时间的情况下，暂无法观察跨eNB的切换用户面中断时延的方法。eNB内的切换可通过LMT对用户面跟踪：图24 LMT跟踪L2切换用户面数据选项图勾选项如上图以获取切换的上下行用户面调度的详细数据，从而可以获取用户面的切换时延，具体方法需要深入理解研发输出的TTI数据，发回研发分析。5.3 建议的解决措施通过前面的定位方法，基本可以把切换问题定位到：传输、设备内部处理、覆盖（弱覆盖、越区覆盖等）、时延、干扰、邻区漏配、切换不及