LTE_TDD问题定位指导书-切换篇-2013
LTE eRAN 3.1 切换问题定位和优化指导书 文档密级:内部公开
产品名称Product name 密级Confidentiality level
LTE TDD 内部公开
产品版本Product version Total 61 pages 共61页
LTE TDD问题定位指导书-切换篇
目 录
1 免责说明 .....................................................................................错误～未定义书签。6 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 门限值应用 ................................................................................................. 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 2013-8-31 版权所有，侵权必究 第1页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
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 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 切换过程随机接入失败 ........................................... 错误～未定义书签。34
7.1.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
2013-8-31 版权所有，侵权必究 第2页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 7.1.9 X2_IPPATH配置错误导致切换失败为例进行分析 .................................. 41 7.1.10 切换点离目的小区较远 超出了Ncs_Index相应的最大理论接入半径 ... 42 7.1.11 X2切换，源侧发出切换请求，没有收到切换响应 ................................. 43 7.1.12 X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应 ............ 43 7.1.13 X2切换准备时间过长错过最佳切换时间 ................................................ 44 7.1.14 UE侧处理系统消息及切换命令
流程
快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计
冲突.............. 错误～未定义书签。49 7.1.15 核心网功能问题导致的S1切换失败 ........................................................ 46 7.1.16 S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT(64ms)，可以在信号恶化之前及时进行切换 .................................................................... 47 7.1.17 信号交迭区，快速触发切换容易造成频繁的切入切出，信号陡降造成切换失败 50
7.1.18 切换门限改小后乒乓切换次数增多，但是由于切换更加及时，切换失败次数减少 ............................................................................. 错误～未定义书签。58 7.1.19 外部小区配置错误导致无法切换 ............................................................ 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 参考文档 ................................................................................... 错误～未定义书签。64
2013-8-31 版权所有，侵权必究 第3页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
1 概述
无线通讯的最大特点在于其移动性控制，对于终端在不同小区间的移动，网络侧需要实时监测UE并控制在适当时刻命令UE做跨小区的切换，以保持其业务连续性。在切换的过程中，终端与网络侧相互配合完成切换信令交互，尽快恢复业务，在LTE系统中，此切换过程是硬切换，业务在切换过程中是中断的，为了不影响用户业务，切换过程需要保证切换成功率、切换中断时延、切换吞吐率三个重要指标，其中最重要的是切换成功率，如果切换出现失败，将严重影响用户感受，切换中断时延和切换吞吐率也会不同程度地影响用户感受。最后对于网络中可能出现的切换问题，本文根据当前积累的LTE系统内切换问题定位经验，给出相应的问题隔离定位指导，以优化相应的网络指标。
2 切换原理
切换的过程就是终端在移动过程中与网络连接交互发生变化的过程，简单的图示如下图:
图1 切换前UE跟左边的基站联系
图2 切换后UE跟右边的基站联系
LTE系统的整个切换过程完全由网络侧(eNB)控制，所以切换UE的行为需要eNB监控，当发现UE处于切换区且存在比当前无线质量更好的小区时，根据情况适时命令UE切换到目标小区。由于eNB并不知道UE所处的位置和无线质量情况，需要控制UE上报相关的无线质量信息来判断，UE上报无线质量信息的方式有周期上报和事件上报两种方式，当前我司eNB是采用事件测量报告的方式来监控UE所处的无线质量变化临界点，当eNB收到测量或切换的事件上报时，会下发切换命令给UE，UE收到切换命令后，中断与源小区的交互，按切换命令要求切换到新的目标小区，并通过信2013-8-31 版权所有，侵权必究 第4页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 令交互通知目标小区，以完成整个切换过程。
2.1 切换相关参数
为了控制切换信令流程的准确和及时，网络侧通过一些参数来控制切换的触发条件，根据我司的切换算法实现，同频切换采用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-Hys>Ms+Ofs+Ocs+Off
取消条件: Mn+Ofn+Ocn+Hys
Thresh
取消条件:Mn+Ofn+Ocn+HysThresh
取消条件:Mn+Ofn+HysThresh2
取消条件:Ms-Hys>Thresh1 或 Mn+Ofn+Ocn+Hys 在UU接口体现为RRC CONNECT RECONFIG信令，UE收到此
信令后，回复eNB表示收到此消息并已正确处理
, UE回复eNB收到控制消息=-=-=> 在UU接口体现为RRC CONNECT RECONFIG CMP信
令，之后UE将按测量控制要求实时测量，一旦发现满足条件，将触发切换事件测量报告 , UE把测量报告发给源eNB =-=-=> 在UU接口体现为RRC MEASUREMENT REPORT信令
源eNB收到测量报告后，进行相关条件判断，如果决定切换，网络侧将准备的相关切换资
源(这个过程对UE侧不可见)
, 网络侧准备切换相关资源，根据不同的切换场景，有不同的切换信令交互 , =-=-=> 站内切换时，没有额外的外部信令交互
, =-=-=> 跨X2接口的站间切换时，X2口体现为HANDOVER REQUEST和HANDOVER
REQUEST ACK信令
, =-=-=> 跨S1接口的站间切换时，源eNB侧S1口体现为HANDOVER REQUIRED 、
HANDVER COMMAND，目标eNB侧S1口体现为HANDOVER REQUEST、HANDOVER
REQ ACK信令
, 源eNB下发切换命令 =-=-=>在UU接口体现为RRC CONNECT RECONFIG信令
UE收到切换命令后，中断与源eNB(小区)的交互，并尝试接入目标eNB(小区)，这个
交互过程有3条交互信息，但在标准信令接口仅体现第3条(习惯上称为MSG3) , UE在目标小区发MSG3，即切换完成消息 =-=-=>在UU接口体现为RRC CONNECT
RECONFIG CMP信令
, 后续的网络侧S1接口切换(只涉及站间切换，站内切换不涉及)，这个过程不涉及空口，
失败的概率较小，通常的切换问题定位关注较少
上面提到的测量控制和切换的交互信令，从消息名称看都相同(均为RRC CONNECT
RECONFIG、和RRC CONNECT RECONFIG CMP)，但重配置消息中的
内容
财务内部控制制度的内容财务内部控制制度的内容人员招聘与配置的内容项目成本控制的内容消防安全演练内容
不同:
2013-8-31 版权所有，侵权必究 第6页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图3 切换命令重配置消息
图4 测量控制重配置消息
测量控制的过程在UE接入后配置，即使此UE不在切换区或一直不切换。我们关注的切换问题通常处于触发切换(测量报告)后的过程，所以在进行切换问题定位时通常只关注从触发测量报告开始，即从测量报告消息这条信令开始。
信令的交互根据切换的不同类型而不同，LTE系统内的切换类型可分为站内切换和站间切换，站间切换又分为跨X2切换和跨S1切换。各信令流程分别如下:
2.2.1 站内切换信令交互
站内切换UE与eNB的交互过程如下:
2013-8-31 版权所有，侵权必究 第7页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图5 站内切换信令流程
2.2.2 跨X2的站间切换信令交互
跨X2的站间切换信令交互过程如下:
UES_eNBT_eNBCore Network
Meas_RPRT
Handover_Request
Handover_Request ACK
RRC_CONN_RECFG
(HO_CMD)SN_STATUS_TRANSFER
RRC_CONN_RECFG_CMP
S1AP_PATH_SWITCH_REQ(HO_CMP)
S1AP_PATH_SWITCH_REQ_ACK
UE_CONTEXT_RELEASE
RRC_CONN_RECFG
RRC_CONN_RECFG_CMP
UU_interfaceX2_interfaceS1_interface
图6 跨X2的站间切换信令流程
2.2.3 跨S1的站间切换信令交互
2013-8-31 版权所有，侵权必究 第8页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
跨S1的站间切换信令交互过程如下:
UES_eNBT_eNBCore Network
Meas_RPRT
S1AP_Handover_Required
S1AP_Handover_Request
S1AP_Handover_REQ_ACK
S1AP_Handover_CMD
RRC_CONN_RECFG
(HO_CMD)S1AP_eNB_Status_Transfer
S1AP_MME_Status_Transfer
RRC_CONN_RECFG_CMP
S1AP_Handover_Notify(HO_CMP)
S1AP_UE_CONTEXT_REL_CMD
S1AP_UE_CONTEXT_REL_CMP
RRC_CONN_RECFG
RRC_CONN_RECFG_CMP
UU_interfaceX2_interfaceS1_interface
图7 跨S1的站间切换信令流程 2.3 异频/异系统切换
2.3.1 异频切换
异频切换实现LTE系统中不同频点的小区间切换过程。在同一个网络，不同的区域可能使用不同的频点，因此eNodeB需要在系统内支持不同频点间的切换。
当服务小区存在异频邻区时:
, 基于覆盖的异频测量由UE测量触发。UE离开服务小区的覆盖范围，到达异频邻区的覆盖范围时，UE测量到服务小区信号质量小于一定门限将触发基于覆盖的异频测量。
, 基于负载的异频测量由eNodeB触发。当服务小区负载达到异频负载平衡门限时，eNodeB将根据UE的频点支持能力、ARP(Allocation and Retention Priority)以及占用资源情况选择一定数量的UE进行异频测量。ARP的相关内容详细请参见3GPP TS 23.401。
, 基于频率优先级的异频切换只在900MHz/2600MHz同站同覆盖情况下进行，在900MHz/2600MHz同站同覆盖的条件下，UE测量到服务小区信号质量大于一定门限将触发基于频率优先级的异频测量。
, 基于距离的异频切换由eNodeB根据UE上报的TA值，来估计UE相对于eNodeB的距离。当发现UE上报的TA值超过门限时，则认为UE已经移动到很远的距离，将触发基于距离的异频测量。基于距离的切换需要配置测量目标类型，当基于距离的切换参数DistBasedMeasObjType配置为EUTRAN时，才可以触发基于距离的异频切换。
, 基于业务的异频测量由eNodeB触发。eNodeB识别拥有某种业务(如语音业务)的UE，根据业务配置的异频频点，进行基于业务的异频测量。
, 基于上行链路质量的异频测量由eNodeB触发。eNodeB发现UE上行链路质量受限时，进行基于上行链路质量的异频测量。
2013-8-31 版权所有，侵权必究 第9页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 在异频测量过程中，UE发现邻区信号质量大于相应的切换门限时，将触发相应的异频切换。异频切换的流程跟同频切换类似，但在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 Multiple
Access )/CDMA2000(Code Division Multiple Access)的小区间切换过程。对于不同区域可能使用不同的系统，LTE支持切换到不同系统，保证通信业务的连续性和无中断性。
当服务小区存在异系统邻区时:
, 基于覆盖的异系统测量由UE测量触发。UE离开LTE系统的覆盖范围，进入其他系统的覆盖范围时，UE测量到服务小区信号质量小于一定门限将触发基于覆盖的异系统测量。 , 基于负载的异系统测量由eNodeB触发。当服务小区负载达到异系统负载平衡门限时，eNodeB将根据UE能力、当前所进行的业务以及ARP选择一定数量的UE进行基于负载的异系统测量。 , 基于业务的异系统测量由eNodeB触发。eNodeB识别拥有某种业务(如语音业务)的UE，进行基于业务的异系统测量。
, 基于上行链路质量的异系统测量由eNodeB触发。eNodeB发现UE上行链路质量受限时，进行基于上行链路质量的异系统测量。
, 基于距离的异系统切换首先由eNodeB根据UE上报的TA值，来估计UE相对于eNodeB的距离。当发现UE上报的TA值超过门限时，则认为UE已经移动到很远的距离，将触发基于距离的异系统测量。
在异系统测量过程中，UE发现邻区信号质量大于相应门限时，将触发相应的异系统切换 2013-8-31 版权所有，侵权必究 第10页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图9 Inter RAT HO procedure 2.3.3 门限值应用
在目前商用现网中异频/异系统切换的应用很少，暂不详细说明。下面以最常用的同频切换为例，说明各个参数的用途:
用于事件A3评估判决的Mn和Ms测量量类型，由参数IntraFreqHoA3TrigQuan决定，该值由3GPP协议36.331规定在测量控制中的报告配置中给出，可选类型为RSRP或RSRQ，我司当前实现默认为RSRP。
事件A3触发机制原理如下图所示，当事件A3在延迟触发时间TimeToTrig内都满足触发条件，则UE对事件A3进行事件转周期的上报;
2013-8-31 版权所有，侵权必究 第11页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图10 A3触发机制图示
对于同频切换，服务小区和邻区使用相同的频点，则Ofn和Ofs均为0，服务小区的特定小区偏置，一般情况下都为0(MOD EUTRANINTERFREQNCELL)，所以A3事件的触发条件可以简化为:
Mn -Hys>Ms +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 > 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毫秒，表示在320毫秒内一直满足触发条件才上报A3事件报告。 2.3.3.2 小区偏置CIO
小区特定偏置CIO(Cell Individual Offset)，每个服务小区和目标小区可分别独立配置。当信号波动较大，需要对某个特定小区调节切出或切入的容易程度，根据协议中的对A3触发事件的条件:
Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off
2013-8-31 版权所有，侵权必究 第12页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
根据当前我司的实现，去掉式中固定为0的项，为:
Mn +Ocn-Hys>Ms +Off
其中Ocn即为小区偏置CIO，CIO在切换中起到移动小区边界的作用。目标小区的CIO越大，切换越容易，反之亦然。我司的MRO算法可以自动调整小区偏置CIO。
小区偏置CIO通过测量控制消息中的Neighbour cell list中下发。当CIO不为零时，通过测量控制消息下发该邻区信息;CIO为零时，该值不下发。
2.3.3.3 事件转周期上报间隔
切换事件上报后转周期上报的周期配置IntraFreqHoRprtInterval参数，当前3.0版本配置为320毫秒，表示UE在上报A3事件测量报告后，如果满足上报A3事件条件，会每隔IntraFreqHoRprtInterval
毫秒后上报A3事件测量报告，直到收到切换命令或不满足A3事件条件。此参数配置越小，A3测量报告在空口的发送越快，当前此参数配置较小的320ms是为了加快L3在处理流程中，如果出现丢弃A3测量报告的情况下，尽快处理后续的A3切换测量报告，通常情况下并不会发生L3丢弃A3测量报告的情况，所以此参数对切换的KPI指标影响很小。
2.4 切换用户面交互
从切换的过程可以看到，LTE系统切换是硬切换，即，UE在收到切换命令后中断与源小区的交互，在UE与目标小区建立交互之前，这段时间UE与网络是没有业务数据交互的，体现为切换用户面中断，这段时间通常为几十毫秒，对业务影响比较小，但过长的中断时延将影响用户感受。
切换过程中，用户面交互过程如下:
图11 用户面切换过程图
根据我司当前eNodeB实现:
2013-8-31 版权所有，侵权必究 第13页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
1( 源小区的下行数据在eNodeB下发切换命令的同时停止PDCP、RLC的传输，但MAC的HARQ
队列中可能仍有重传的数据在空口传输
2( UE在收到切换命令之后停止在源小区的上行数据发送、接收
3( UE在目标小区回复切换完成消息之后可以在目标小区发送上行数据，也可以收到目标小区
的下行数据
由于跨eNodeB的切换在计时上存在偏差，不能准确定义，所以下面涉及eNodeB侧的定义均为eNodeB内切换时延定义
3 切换相关KPI指标
跟切换相关的KPI指标有切换成功率、切换信令面时延、切换用户面中断时延。 3.1 切换成功率
切换成功率是从信令流程来定义的:
切换成功率 = 切换成功次数 / 切换尝试次数 * 100%
对切换成功率的统计也有不同的定义，主要差别在于切换尝试的定义，有的以测量报告为切换尝试统计点，有的以切换命令为切换尝试统计点。切换成功率还可根据是在终端侧统计还是在网络侧统计，也会有不同的结果，在终端侧统计通常以路测跟踪的UE侧数据来统计，在网络侧统计则是以消息跟踪或话统数据来统计。
3.2 切换信令面时延
切换信令面时延通常为从切换命令到切换完成两条消息的间隔:
切换信令面时延通常以网络侧的信令跟踪来统计时延，也可以从终端侧跟踪记录的信令来统计时延，而且网络侧统计的信令时延比终端侧统计的时延要大。
3.3 切换用户面中断时延
真正影响用户感受的是用户面的中断时延，所以用户面中断时延也十分重要。用户面时延在统计时分上行时延和下行时延。对上行和下行时延在实际统计时，又由于计时点选择的不同，有不同的统计方法，其中应用层中断时延最接近用户感受，涉及各传输环节的还有PDCP、RLC、MAC层中断时延。
2013-8-31 版权所有，侵权必究 第14页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
上图中是终端侧和网络侧的数据传输经历的各协议层，上行数据传输路线为带箭头的黑色线，下行数据传输路线为带箭头的红线，在PDCP、IP之间有一粉红色虚线，表示这中间还存在其它传输环节，例如，用便携插数据卡终端使用时，应用层(如QQ程序)可能安装在便携机上，网络侧的QQ服务器在Internet的WebServer上。数据传输一旦出现中断(一定的时延)，将在传输路线的各协议层产生相应的时延，这也就是可以在不同协议层测试时延的原因。在时延测试时，需要在相应的方向满速率灌包，以避免由于应用层数据中断的原因导致测试各时延不准确。
用户面中断时延的定义，通常为某协议层实体，在切换前收发的最后一个数据包到切换后收发的第一个数据包之间的间隔。根据不同的统计点，又分为终端侧统计和网络侧统计。在实际测试中，通常关注应用层和RLC层的上下行中断时延:
3.3.1 上行应用层中断时延
从服务器用IP抓包软件连续捕获服务器接收到的来自UE的上行数据包，对切换期间受切换影响的、出现的最大时间间隔定义为应用层上行用户面中断时延。此定义只是比较模糊的定义，实际操作时，无法对齐“切换期间”这个时间窗，即使能严格对齐时间，也会由于应用层时延相对切换时刻会有一些滞后的时延;另外由于从服务器用IP抓包获得的时间间隔抖动较大，受影响的因素包括核心网、外网、应用层数据包大小等多方面因素，“最大时间间隔”为用户面中断时延的定义不一定科学。当前的实际测试，在时延选择上，主观因素较多，暂不能给出清楚、严格的定义。测试时可通过灌UDP小包(每个包较小，通过单位时间包的个数来调整流量)的方式减小测试时延结果。 3.3.2 下行应用层中断时延
2013-8-31 版权所有，侵权必究 第15页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
从UE侧用IP抓包软件连续捕获UE接收到的来自服务器的下行数据包，对切换期间受切换影响的、出现的最大时间间隔定义为应用层上行用户面中断时延。此定义只是比较模糊的定义，实际操作时，无法对齐“切换期间”这个时间窗，即使能严格对齐时间，也会由于应用层时延相对切换时刻会有一些滞后的时延;另外由于用IP抓包获得的时间间隔抖动较大，受影响的因素包括核心网、外网、、应用层数据包大小、UE侧便携等多方面因素，“最大时间间隔”为用户面中断时延的定义不一定科学。当前的实际测试，在时延选择上，主观因素较多，暂不能给出清楚、严格的定义。测试时可通过灌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在源小区上行发的最后一个PDU时刻到UE侧RLC在目标小区上行发的第一个PDU的时延。
3.3.6 终端侧下行RLC层中断时延
定义为从UE RLC在源小区收到的最后一个PDU时刻到UE RLC在目标小区收到第一个PDU的时延。
4 切换问题定位方法
4.1 切换失败问题定位
切换失败通常是指切换的信令流程交互失败，关注点在信令的交互，只有在信令交互出现丢失或信令处理结果失败才会失败。其中信令丢失是指信令在传输过程中出错或不能到达对端，信令处理结果失败是指终端或网络侧在处理信令时出现异常导致流程不能正常进行(例如切换时资源不足)。信令传输失败又可根据信令传输媒介的不同可分为无线传输失败和有线传输失败，其中X2、S1接口的传输通常为有线传输，UU口为无线传输。其中有线传输失败的概率较小，无线传输失败的概率较大，特别是信号质量较差的切换区。
4.1.1 UU接口信令异常
2013-8-31 版权所有，侵权必究 第16页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
对于切换流程，在UU接口只有三条信令:测量报告(MEASUREMENT REPORT)、切换命令(RRC CONN RECFG)、切换完成(RRC RECFG CMP)。但有时在定位切换后立即掉话或重建问题时，也关注切换后的第一次重配置信令(RRC CONN RECFG)交互，严格说，切换后的重配置消息已经与切换流程没有关系，且此消息不可预期。
图12 切换信令流程中UU口消息交互
UU接口信令异常的常见原因有:
1) 测量报告丢失，可能的原因主要有
, UE上发测量报告的UL GRANT没有收到，下行PDCCH受限
, UE上发的测量报告，eNB没有收到(或收到但CRC错)，上行PUSCH受限
, UE内部层间丢失，例如L3把测量报告给L2发送时，L2处理失败
2) 切换命令丢失，可能的原因主要有
, eNB因为在切换内部流程处理(如邻区漏配、资源不够等)出错，没有下发切换命令
, UE下行PDCCH解析失败，下行PDCCH受限
, UE下行PDSCH解析失败，下行PDSCH受限
3) 切换完成信令丢失，可能的原因主要有
, UE在目标小区的PREAMBLE，eNB没有收到，上行PRACH受限
, UE下行接收RAR失败，下行PDSCH受限
, UE上发切换完成，eNB没有收到，上行PUSCH受限
UU口的传输为无线传输，其信道质量可以分为上、下行来分析。如果终端侧能够捕获RSRP、2013-8-31 版权所有，侵权必究 第17页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 SINR、IBLER、DL/UL_Grant等信息，并配合网络侧的信令跟踪，大多情况都可以判断上、下行的问题。信道质量的观察量通常有下面几个:
, RSRP:RSRP为下行导频接收功率。尽管导频与数据域的信道质量有一定差异，通过导频
RSRP、SINR可以大致了解数据信道状况。一般RSRP>-85dBm，用户位于近点;
RSRP=-95dBm，用户位于中点;RSRP<-105dBm，用户位于远点。判断用户近、中、远点
并不能完全判断用户的信道质量，尤其在加载场景下，有可能中点、近点用户的信道质量
仍然不理想(当邻区RSRP与服务小区RSRP较接近时，干扰较大)，需要依据其它指标来
判断信道质量。
, SINR:SINR为下行导频SINR。通过导频SINR可以大致了解数据信道状况。如果SINR<0dB
说明下行信道质量较差，当SINR<-3dB说明下行信道质量恶劣，处于解调门限附近，容易
造成切换信令丢失，导致切换失败。上行SINR可以通过LMT用户性能跟踪获得。
, IBLER:正常情况下，IBLER应该收敛到目标值(目标值为10%，当信道质量很好时IBLER
接近或等于0%);如果IBLER偏高说明信道质量较差，数据误码较多，很容易造成掉话、
切换失败、或者切换大时延。下行IBLER可以从probe中获得，而上行IBLER通过LMT用户
性能跟踪获得的数据较之probe准确。
, PDCCH DL:从DL_Grant可以得知UE正确解调PDCCH的个数。当上/下行数据源足够(如
上/下行UDP最大能力灌包)时，eNB每个TTI均调度用户，PDCCH个数为800(sa 3:1下)。
若DL_Grant,800，说明PDCCH解调正常，信道质量正常;若DL _Grant偏低，说明PDCCH
解调有错，信道质量可能比较差。
在判断上、下行信道质量时，有时不能完成任L3上下行信令是否丢失来判断。例如，下行信道质量差不仅会影响下行信令的解调，下行PDCCH解调错误也会影响上行调度，造成上行信令丢失。信道质量问题通常是因为弱覆盖或干扰引起。
对于空口问题定位，需要把问题定位到覆盖(弱覆盖、越区覆盖等)、干扰、邻区漏配、切换不及时等几类，再采用相应的解决措施解决问题。
4.1.2 X2接口信令异常
对于切换流程，只有经过X2的站间切换在X2口有切换流程的信令:在X2接口通常情况下有如下4条信令:切换请求(HANDOVER REQUEST)、切换响应(HANDOVER REQUEST ACK)、SN状态转发(SN STATUS TRANSFER)、UE上下文释放(UE CONTEST RELEASE)，如下图中红色信令:
2013-8-31 版权所有，侵权必究 第18页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图13 切换信令流程中X2口消息交互 X2接口信令异常的常见原因有:
1) 切换请求丢失，可能的原因主要有
, eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败
, X2口传输异常，如传输丢包
2) 切换响应丢失，可能的原因主要有
, 源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发
HANDOVER CANCEL信令
, 目标小区切换准备异常，这时通常会在X2口出现 HANDOVER PREPARATION
FAILURE信令
, X2口传输异常，如传输丢包
3) SN状态前转信令丢失，可能的原因主要有
, X2口传输异常，如传输丢包
, 源小区内部错
4) UE上下文释放信令丢失，可能的原因主要有
, X2口传输异常，如传输丢包
, 目标小区收到切换完成后内部处理错，导致没有进行S1 PATH切换
, S1 PATH切换失败
对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概
2013-8-31 版权所有，侵权必究 第19页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
4.1.3 S1接口信令异常
对于切换流程，只要是跨eNB切换，不管是经S1切换还是经X2切换，在S1口均有信令交互:在经X2接口切换时，S1接口仅有两条信令:S1AP PATH SWITCH REQ、S1AP PATH SWITCH REQ ACK;在经S1接口切换时，S1接口信令会在源eNB和目标eNB有较多的交互。如下图绿色信令所示:
图14 切换信令流程中S1口消息交互 2013-8-31 版权所有，侵权必究 第20页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
UES_eNBT_eNBCore Network
Meas_RPRT
S1AP_Handover_Required
S1AP_Handover_Request
S1AP_Handover_REQ_ACK
S1AP_Handover_CMD
RRC_CONN_RECFG
(HO_CMD)S1AP_eNB_Status_Transfer
S1AP_MME_Status_Transfer
RRC_CONN_RECFG_CMP
S1AP_Handover_Notify(HO_CMP)
S1AP_UE_CONTEXT_REL_CMD
S1AP_UE_CONTEXT_REL_CMP
RRC_CONN_RECFG
RRC_CONN_RECFG_CMP
UU_interfaceX2_interfaceS1_interface
图15 切换信令流程中S1口消息交互 X2接口信令异常的常见原因有:
1) 跨X2切换的S1AP PATH SWITCH REQ丢失，可能的原因主要有
, 目标eNB内部处理切换完成信令失败
, S1口传输异常，如传输丢包
2) 跨X2切换的S1AP PATH SWITCH REQ ACK丢失，可能的原因主要有
, 核心网收到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 REQUEST ACK信令丢失，可能的原因主要有
, 目标小区收到S1AP HANDOVER REQUEST后，内部处理出错(如资源不足等)
, S1口传输异常，传输过程中丢失
2013-8-31 版权所有，侵权必究 第21页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
6) 跨S1切换的S1 HANDOVER CMD信令丢失，可能的原因主要有
, 核心网收到S1AP HANDOVER REQUEST ACK后，内部处理出错
, S1口传输异常，传输过程中丢失
7) 跨S1切换的S1AP ENB STATUS TRANSFER信令丢失，可能的原因主要有
, 源小区处理收到S1 HANDOVER CMD后，内部处理出错
, S1口传输异常，传输过程中丢失
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后，内部处理出错
, S1口传输异常，传输过程中丢失
11) 跨S1切换的S1AP UE CONTEST REL CMP信令丢失，可能的原因主要有
, 源小区收到S1AP UE CONTEST REL CMD后，内部处理出错
, S1口传输异常，传输过程中丢失
对于S1口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
4.2 切换时延问题定位
切换时延包括信令面时延和用户面时延。
4.2.1 切换信令时延问题定位
切换信令时延根据观察点的不同，可以定义终端侧切换信令时延、网络侧切换信令时延，统计方法均为从切换命令到切换完成消息之间的时延，由于网络侧的切换信令时延包括两次空口传输时延，所以通常网络侧的切换信令时延大于终端侧的切换信令时延。而网络侧在统计切换时延时涉及跨ENB的时钟不能准确对齐，所以通常只能统计站内切换的网络侧切换信令时延。以三星UE为例，终端侧的切换信令时延约31ms(华为UE约8ms)，网络侧的(站内)切换信令时延约38ms。
切换信令时延为切换命令到切换完成两条信令之间的时延，从终端侧看，切换信令时延主要包括切换信令处理时延、目标小区同步时延、目标小区接入时延三部分，其中目标小区接入时延占主要部分。从网络侧看，切换信令时延包括终端侧的切换信令时延之外，还包括两条切换信令在空口的传输时延。通常情况下，如果信令时延出现过大的问题，主要原因有:
2013-8-31 版权所有，侵权必究 第22页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
, 切换命令出现空口重传，此时延体现在网络侧切换信令中断时延
, 目标小区接入尝试多次，此时延体现在终端、网络侧
, PRACH调度周期大时，信令时延稍有增大
要定位切换信令时延的问题，需要从终端侧结合网络侧跟踪比较详细的内部消息来定位。当前主要依靠网络侧、终端侧的TTI数据跟踪来定位。
4.2.2 切换用户面时延问题定位
切换用户面时延根据不同的测量点，有不同的时延定义。其中跟用户感受最相关的是应用层数据时延，测试时通常以服务器侧或终端应用层侧的IP层数据为测量点来观察应用层切换时延。由于应用层的时延跨接入网和核心网及公网，其时延的影响范围较大，不能仅从接入网来定位，所以为了观测接入网侧的切换用户面中断时延，通常在接入网侧的RLC设置观测点，即RLC切换用户面中断时延。从数据的流向，切换时延还分上行和下行时延。当前由于时间对齐问题，对接入网的时延观测仅只能从终端内部输出RLC层的上下行时延(后续可提需求在eNB实现站内切换的RLC观测点)。以华为UE为例，当前切换的下行RLC层切换用户面中断时延约34ms，IP应用层的切换用户面中断时延波动较大，上行约120ms，下行约60ms。
在接入网侧影响切换用户面中断时延的主要原因有:
, eNB下发的切换命令出现重传，导致下行用户面挂起时延较长
, 切换区空口质量不好，导致上行或下行的用户面数据重传，直接影响用户面切换中断时延
, 目标小区接入时延大，导致用户面数据恢复较慢
, X2或S1接口传输时延大，主要影响应用层时延
, PRACH调度周期大时，信令时延稍有增大
要定位切换用户面时延问题，需要从终端侧结合网络侧跟踪比较详细的信息来定位。当前主要依靠网络侧、终端侧的TTI数据跟踪来定位。
5 切换问题定位的相关操作
对于单个的切换问题在定位之前，先要确定是信令还是用户面的问题。通常的切换失败和切换的信令时延问题都需要从信令的交互去分析;切换的用户面时延问题则要从用户面的数据调度交互去定位。
5.1 信令观察方法
信令既可以在网络侧跟踪也可以在终端侧跟踪。在定位切换失败问题和切换信令时延问题时需要跟踪信令进行定位。
2013-8-31 版权所有，侵权必究 第23页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 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 终端侧观察方法
信令在终端侧需要通过相应的终端软件来配合跟踪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还可承载其它的测量控制及信令控制信息;切换测量报告MeasurementReport也不只是切换的测量报告，还可承载其它(如ICIC、异频、异系统)测量报告信2013-8-31 版权所有，侵权必究 第24页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 息。所以在问题定位时，有必要区分这些消息是否切换相关的信令。
在测量控制消息中，打开RRCConnectionReconfiguration消息，如果存在measConfig信元，则是测量控制消息，如果存在eventA3且其a3-offse与hysteresis为非负值，则说明此事件是切换测量控制(按当前产品实现的通常配置)，其ReportConfigIdg对应的measId即是切换测量ID，如下图所示:
图18 切换测量控制消息确认
打开measurementReport消息，其中的measId与切换测量控制中的切换测量Id相同，则此测量报告是切换的A3测量报告，如下图所示:
2013-8-31 版权所有，侵权必究 第25页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图19 切换测量报告消息确认
打开MeasurementReport后面的RRCConnectionReconfiguration消息，存在targetPhysCellId信元的RRCConnectionReconfiguration消息即是切换命令，如下图所示:
图20 切换命令消息确认
5.2 用户面时延观察方法
用户面时延实际测试通常测试应用层(IP)用户面时延，即通过在终端侧(便携)或服务器SERVER)侧安装IP抓包工具软件来测试。如果要关注接入网侧的时延，通常测试RLC层时延。 (
5.2.1 应用层切换时延观察方法
2013-8-31 版权所有，侵权必究 第26页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
应用层的切换中断时延是通过捕获IP层的包的时间点来计算的，所以不管是上行还是下行，其方法相同，不同的只是下行在终端侧(如便携)抓包，上行在服务器(SERVER)侧抓包，常用的抓包工具有Ethereal和Wireshark。
图21 IP层抓包图
在确定IP层切换中断时延时，按前面的定义，由于实际切换时间点与抓包软件记录的时间点无法精确到毫秒级，仍需要主观判断来确定，使测试出现一定的主观偏差。
下行应用层中断时延也可以用三星UE的X-CAL工具测试IP层时延:打开Message——Packet Capture View，再点击FileMenu——Manual Capture，选中Ue跟踪到数据包:
图22 X-CAL软件抓包图
5.2.2 RLC层切换中断时延观察方法
2013-8-31 版权所有，侵权必究 第27页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
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对用户面跟踪:
2013-8-31 版权所有，侵权必究 第28页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图24 LMT跟踪L2切换用户面数据选项图
勾选项如上图以获取切换的上下行用户面调度的详细数据，从而可以获取用户面的切换时延，具体方法需要深入理解研发输出的TTI数据，发回研发分析。
5.3 建议的解决措施
通过前面的定位方法，基本可以把切换问题定位到:传输、设备内部处理、覆盖(弱覆盖、越区覆盖等)、时延、干扰、邻区漏配、切换不及时等几类，再采用相应的解决措施解决问题。 2013-8-31 版权所有，侵权必究 第29页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
图25 切换信令失败问题分析思路图
图26 切换用户面时延问题分析思路图
分析方法对应表
切换失败分类 定位方法
信道质量 1 通过Probe观察RSRP、SINR、IBLER、DL/UL_Grant等;LMT用户性能跟踪，分析上/下行信道质量 网优问题 2 结合网络规划，分析是否有越区覆盖情况，调整电倾角;cluster边界邻区关系配置。 配置问题 3 MML查看是否有邻区漏配;X2相关配置;随机接入相关配置(Ncs_Index);鉴权开关 传输问题 4 查看告警，是否有链路闪断;传输是否稳定。该问题概率性出现，很难抓取log定位
无线侧、核心网侧产品Bug可能造成切换概率性失败;功能不完善也可能造成切换性能降低。需要产品问题 5 开发协助定位。
切换大时延分类 解决
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
eRAN1.0 B060SPC350版本合入:源侧L3收到切换测量报数据包重传 源侧数据包CRC错 告后，指示L2对之后的数据采用低阶调度，MCS阶数可
配，同时抬升对应的PDCCH功率，固定CCE聚合级别为8 2013-8-31 版权所有，侵权必究 第30页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
eRAN1.0 B060SPC350版本合入:目的侧切换完成后启动
定时器，定时器时长内对数据采用低阶发送，MCS阶数可
目标侧数据包CRC错 配(MML可配);同时抬升对应的PDCCH功率，固定CCE
聚合级别为8(合入版本)。SET HOMCSPARAM:
MCSHOSTATIC=0, HOCQIRPTTIMER=60ms;
eRAN1.0 B060SPC340版本合入:切换命令HARQ重传时不切换命令HARQ重传进入频选(代码bug) 进入频选
eRAN 1.0 B060SPC350版本合入:1)抬升切换命令PDCCH
功率，同时固定CCE聚合级别为8;2)抬升切换命令PDSCH切换命令重传 功率，同时切换命令采用固定MCS1阶发送;3)eNB侧直切换命令PDCCH/PDSCH受限 接将HARQ+ARQ重传(考虑到商用终端能力，该功能默认
关闭);4)合入DTX处理方案，解决初传解到DTX，HARQ
重传无增益问题。
优化覆盖/调整切换参数，使得切换点具有较好的信道质随机接入流程Preamble重传 量，减少重传。
X2配置问题 检查X2配置(X2_Interface/IPPATH)等。
eRAN1.0 B060SPC360 UE版本合入:优化流程，如果在更
UE处理流程 新系统消息期间收到RRC连接重配置消息，则打断系统
消息更新流程，优先处理RRC连接重配消息。
传输问题涉及面较大，特别是跨城市的传输，出问题的概率更大，需要在最靠近无线网络设备的收发端抓取数据进行确认;设备内部处理出错的问题则需要各网络设备的日志来定位;弱覆盖、越区覆盖、干扰、邻区漏配、切换不及时通常体现在信令丢失导致切换失败，为空口信道质量问题，有相应的解决措施:
, 对于弱覆盖需要通过调整天线、调整功率或增加站点覆盖来解决
, 越区覆盖区域较小时，也容易导致切换失败或掉话，需要通过天线调整控制越区覆盖
, 干扰问题在排除外界干扰的情况下，通常是多用户场景或加载场景下出现，根据不同的场
景，可以选择打开频选调度等干扰控制算法开关，进行干扰协调
, 邻区漏配问题可通过操作维护台增加邻区配置来解决
, 切换不及时可通过调整切换的相关参数:切换门限、迟滞、切换延迟触发时间、CIO等，
以控制切换时机
6 案例参考
6.1 切换失败问题
6.1.1 UE发多条测量报告仍没有收到切换命令
2013-8-31 版权所有，侵权必究 第31页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
在ANR开关关闭时，如果不配置邻区关系，不能进行切换。
首先确认eNB侧配置是否有问题，是否是邻区漏配。例如，UE要从小区A往小区B切换，发送了切换测量报告;此时，若小区A没有配置小区B为邻区，即使收到切换测量报告也不会处理，不下发切换命令，导致切换失败;此时，如果UE继续往远离服务小区的方向移动，信号越来越差会导致掉话。
查看是否邻区漏配方法:
LMT查询命令
LST EUTRANEXTERNALCELL(查询外部小区)
LST EUTRANINTRAFREQNCELL(查询同频邻区)
eRAN1.0:如果是站内切换，需要配置同频邻区后才能进行切换;如果是站间切换，需要配置外部小区、同频邻区后才能进行切换。一般，小区A与小区B的外部小区、同频邻区要相互配置，使得UE可以双向切换。
eRAN1.1:站内切换不需要配置同频邻区，站间切换只要配置外部小区即可正常切换。 注1:测量控制、测量控制完成不属于切换流程;但是，切换流程结束后一般总伴随着测量控制、测量控制完成。
注2:
同站切换时，邻区关系(eNB级)不变时，不下发测量控制。
异站切换时，
CIO=0时，如果邻区关系不变化，不下发测量控制。邻区关系变化，则下发测量控制;CI0不为0时，一定会下发测量控制。
如果检查后发现没有邻区漏配，那么需要提取eNB侧信令跟踪，查看是eNB没有收到测量报告，还是eNB收到测量报告后发送的切换命令UE没有收到。这两种情况可能和上/下行的信道质量有关，下面章节详细分析。
6.1.2 加密及完整性配置问题导致消息解析失败
现网基站数目较多，通常一个网络下面有若干个TAL，每个TAL下面有n个TAC，每个TAC下有若干个小区。当UE在移动过程中发生跨TAC的切换时，会进行TAU更新。
如果路测过程中发现，TAU更新后的切换总是失败，现象为目标侧eNB未收到UE的切换完成消息，请检查核心网参数配置:
2013-8-31 版权所有，侵权必究 第32页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
将红框处的两个鉴权开关关闭，USN1.1版本中还没有实现这两个TAU场景的鉴权功能。
若将TAU强制鉴权打开，核心网会通知eNB更新密钥，UE也要相应的更新密钥;而目前核心网、
、UE版本均不支持TAU鉴权，导致UE TAU更新后的切换失败，原因是:UE没有更新密钥，仍用旧eNB
的密钥发切换完成消息，目标侧eNB用新密钥解切换完成消息，发生完整性校验失败，造成切换失败。
如果源侧与目标侧安全加密算法开关设置不一致，会导致目的侧小区L2对切换完成消息的完整性校验失败，上报L3将UE释放。目的侧基带收到切换完成消息，但上层由于完整性校验失败没有解出来;从信令跟踪看，UE发出了切换完成消息，但是eNB没有收到，如果看到这样的现象，可以检查如下配置:
DSP ENODEBSECCAP
源侧与目标侧配置的算法要一致。
6.1.3 测量报告丢失
首先判断测量报告丢失是否为上行信道质量差导致，可以通过前面案例进行分析。
下面给出下行加载场景下下行信道质量差导致切换测量报告发不出去的案例:
下图所示为测量报告eNB未收到各点的信道状况:
各点的S_RSRP均在-115dBm以内，在其它小区上行空载的情况下(即上行没有干扰)，-115dBm以内不会出现上行受限。因此，不应该是上行信道质量差导致的测量报告丢失。
各点下行信道质量较差，SINR为负值，处于解调门限附近、IBLER不收敛;DL_Grant偏低，下行最大能力灌包的情况下，UE解到的DL_Grant应该为1000(999)，DL_Grant偏低说明PDCCH解调有2013-8-31 版权所有，侵权必究 第33页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 问题;同时，UL_Grant偏低说明很可能是PDCCH解调问题导致UE解到的UL_Grant减少、上行调度不足。
分析相应点的UL_Grant:
01:45:06.296 PCI56->PCI65
02:08:11.796 PCI264->PCI295
2013-8-31 版权所有，侵权必究 第34页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
从UE层间消息分析:发送测量报告时，SR达到最大重传次数触发随机接入ID_RRC_MAC_RA_IND;且SR触发的随机接入失败，启动RRC随机接入。SR达到最大重传次数说明UE在发送测量报告时没有解到上行调度。
综合以上分析，eNB未收到测量报告不是因为上行信道质量差导致的上行信令丢失，而是下行加载场景下，下行信道质量恶劣，UE解调PDCCH出错，没有解到上行调度导致测量报告没有发出去;是下行信道质量差导致的上行信令丢失。
同时，我们做了相应的测试来验证我们的结论:打开上行预调度后，测量报告发不出去的次数明显减少。见下表:
2013-8-31 版权所有，侵权必究 第35页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
6.1.4 切换命令丢失
以50%Load_woICIC路测数据为例:
23:45:59.062 PCI48->PCI50 UE未收到切换命令
该切换点邻区信号陡升6dB，对服务小区造成很大的干扰;下行SINR很低(-5dB)，UE不能正确解调切换命令。
可通过调整天线、两个小区的CIO使提前切换来解决。
6.1.5 下行信道质量差导致发送preamble达最大次数仍未收到RAR 2013-8-31 版权所有，侵权必究 第36页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
首先分析切换点的信道情况:
从路测数据统计看， 100%加载场景出现了切换完成eNB没有收到的情况。各切换点S_RSRP都比较高，在上行空载的情况下，不会出现上行受限。分析下行信道质量，SINR比较低(均为负值)，且下行IBLER不收敛，说明下行100%加载场景下，下行干扰很大、信道质量较差。
从OMT跟踪看，UE发送preamble达最大次数仍没有收到RAR，如图:
下图为100%Load_woICIC、100%Load_ICIC场景随机接入失败点，与目标站的距离均小于1km。cluster6小区覆盖范围较小，配置的Ncs_Index=2(相应的最大接入半径为2.15km)，不影响随机接入性能。
2013-8-31 版权所有，侵权必究 第37页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
综合以上分析，路测数据下行加载场景下的切换完成eNB未收到，是由于切换随机接入失败导致的。下行信道质量差，导致UE没有解到RAR;当preamble达到最大重传次数时，随机接入失败。 6.1.6 UE DSP切换失败，收到切换命令后不回切换完成
现象:UE收到切换完成后，没有回切换完成
分析:
Omt层间消息分析没有回切换完成的原因:DSP切换失败。
2013-8-31 版权所有，侵权必究 第38页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
从OMT消息来看，L1 DSP1 回复HO失败的原因是:切换小区PCI10未在当前L1的邻区搜索列表中找到。LI DSP1反馈Ho失败的原因只有一个:L3下发的HO_REQ切换原语里指定的小区ID，L1在自己维护的邻区列表中没有找到该小区，无法提取TA值发给F1调整，所以上报失败FAIL。
分析该切换失败点的信号情况:
2013-8-31 版权所有，侵权必究 第39页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
该点应该是PCI48与PCI50的切换区，但是在这个地方发生了PCI48,》PCI10的切换。观察路测线路上的RSRP情况，PCI10的RSRP基本都为,140dBm，可以认为PCI10在路测线路上没有覆盖。此次切换PCI48,>PCI10可能是PCI10偶然泄漏过来的信号导致的，信号转瞬即逝，切换时L1已将PCI10删除。
6.1.7 eNB下发RRC信令等待UE反馈，不处理切换命令
eNB下发了RRC信令(比如MIMO重配消息)，因为下行信道质量差，UE没有解调出来。当满足切换条件时，UE上报测量报告，而eNB正在等待上一条RRC信令的反馈，因此，不处理测量报告。当下发RRC信令达到2s后仍然收不到UE反馈，将其释放，发送RRC_CONN_REL消息。如下图:
eNB侧跟踪:
UE侧跟踪
2013-8-31 版权所有，侵权必究 第40页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
6.1.8 X2_IPPATH配置错误导致切换失败为例进行分析
路测过程中，发现站点OSL355连续出现X2切换准备失败，如图:
从切换准备失败的原因可以大致看出:传输资源不够 或者 没有配置IPPATH 或者 IPPATH中的邻接点配置错误 导致，由于接入的用户不多，因此应该是IPPATH配置相关。
确认方法:
2013-8-31 版权所有，侵权必究 第41页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
1)从eCGI中可以确定基站ID为100123即OSL123基站，再根据上报的邻区PCI为4的小区确认是否属于123基站，如果是则确定是123基站，如果不是则查看PCI为4小区所在的基站是哪些，逐个排查;
2)查看123基站的X2接口对应的IPPATH是否配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
Step1: 查看目标侧基站相应的SCTP链路号(X2SCTPLINKID);
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。而现网存在各种覆盖情况，密集城区基站较多，小区覆盖范围较小;而郊区基站稀疏，小区覆盖范围普遍较大。如果整网使用同一个Ncs_Index，会出现适用性问题。比如，当Ncs_Index,2，在密集城区、市区的接入性能正常、切换正常;当在郊区，很可能出现由于切换点、接入点离站较远，超过了相应的理论接入半径，导致接入失败、切花失败。下面截图是Norway LTE商用网，全网配置Ncs_Index,2时，郊区出现随机接入失败导致的切换失败:
2013-8-31 版权所有，侵权必究 第42页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
6.1.10 X2切换，源侧发出切换请求，没有收到切换响应
左图为源侧基站消息跟踪;右图为目的侧基站消息跟踪。
有时还会出现这样的情况:由于源侧收到HANDOVER_REQUEST_ACK较晚(秒级)，延误了最佳切换时机，导致切换失败。
6.1.11 X2切换，目标侧发送S1AP_PATH_SWITCH_REQ未收到响应
目标侧发送S1AP_PATH_SWITCH_REQ未收到响应，导致此次切换失败。同时，eNB不会处理后面上报的切换测量报告，导致新触发的切换也失败。
2013-8-31 版权所有，侵权必究 第43页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
6.1.12 X2切换准备时间过长错过最佳切换时间
从Probe的测试数据中看到，UE在上报多次相同测量报告没有收到切换命令。根据eNB侧全网跟踪信息分析发现这种情况下源侧eNB发起X2切换请求。eNB切换X2准备时间过了很长时间才收到切换请求响应;期间，目的侧信号迅速衰减，最终目的侧eNB没有接收到切换完成消息、切换失败。UE重建成功后，eNB发起对DRB的重配置消息时，UE没有收到，eNB侧RLC达到最大重传次数直接释放用户。
2013-8-31 版权所有，侵权必究 第44页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
UE切换失败后发起重建，成功后由于没有接收到DRB的重配置消息，再次发起重建，由于第一次重建eNB侧RLC达到最大重传次数释放了用户上下文，UE第二次重建被拒绝导致异常释放。
PCI345小区RSRP覆盖情况良好，在切换X2准备期间，邻区信号迅速衰减，导致UE随机接入失败，目的侧没有收到切换完成，切换失败。X2准备时间过长导致切换不及时错过最佳切换时间，导致后续用户重建掉话等情况。
2013-8-31 版权所有，侵权必究 第45页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
【解决措施】
S1链路闪断、传输受限等问题导致的切换失败，通常是概率性出现，难以定位分析;对路测切换性能有一定影响。
X2准备时间过长从eNB侧全网跟踪上看X2信令传输浪费了3s的时间。分析站点一键式日志时没有发现X2链路故障的情况:底层SCTP链路发出消息后，如果在1s内没有收到数据包的ACK响应就会发起数据包重传，如果连续10次重传失败就会上报SCTP链路告警断开SCTP。初步定位是由于X2信令重传导致信令传输时延增大。经过与客户确认发现客户在近期调整传输网络，导致传输性能受到影响。
出现传输问题需要及时向客户确认，以减少不必要问题定位。
6.1.13 核心网功能问题导致的S1切换失败
时间点:00:55:51.468 PCI228(OSL131),》PCI124(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切换到228时，目标侧发送了切换完成通知用户释放消息，原则没有收到，导致核心网认为切换2013-8-31 版权所有，侵权必究 第46页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 失败分别向原侧和目标侧发送了释放用户消息。
在OSL182站点发现几次这样类似的情况均是等待Notify消息超时。再来看一下OSL182站点CHR的日志记录发现，在这个时间段内用户接入也存在问题，现象表现为核心网没有回复初始化上下文响应。初步怀疑是核心网处理流程冲突导致消息无法正常发送。
当然也不排除传输问题。从S1链路信息来看，这段时间S1链路应该没有断过。因为没有看到因小区Down掉而被异常释放的用户。
【结论】
本次切换属于切换准备失败，从UE侧来看，UE并不知道发生了切换，所以UE侧来讲整个切换是成功的。
在00:55~00:57二分钟的时间段内，UE在228和124之间乒乓切换多次，其中有两次Notify消息原侧没有接收到，一次切换请求目标侧没有接收到。
从用户接入的情况来看，核心网在这一时间段时对于用户的初始上下文请求均没有回复响应，一共有四次。
另外，频繁发生S1乒乓切换也是不正常的现象，应该优化覆盖并在OSL182和OSL131之间添加X2链路，尽量避免S1切换。
6.1.14 S_RSRP、N_RSRP都比较高的站内切换，用较小的HO_TTT(64ms)，可以在
信号恶化之前及时进行切换
Test1 20100504 22:55:40.218 PCI48->PCI50 切换命令UE未收到
2013-8-31 版权所有，侵权必究 第47页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
分析:
1、这次切换为站内切换，切换点S_RSRP、N_RSRP都比较高;在下行加载场景下，目标小区对原小区有较强的干扰。此时导频SINR<0dB，DL_IBLER>20%，说明切换点下行信道质量较差，导致切换命令丢失。
2、切换门限2dB，UE切换测量报告中N_RSRP,S_RSRP,3dB。这种S_RSRP、N_RSRP都比较高的站内切换，在下行加扰场景下，切换点的下行信道质量恶劣，需要提高切换触发的及时性，在信道质量急剧恶化之前完成切换。
3、为了提高切换及时性，将HO_TTT由128ms缩短至64ms。HO_TTT64ms的测试结果，在该点切换成功。
2013-8-31 版权所有，侵权必究 第48页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
提高切换及时性后，上报切换测量报告点的信道质量有所改善，SINR虽然也有显著的减低，但仍然有2~3dB，大于解调门限;DL_IBLER 约15%，基本收敛于目标值10%。下行信道质量不是很差，保证了切换命令的正确解调。如下图:
Test2 20100505 23:52:33.140 PCI48,>PCI50 切换成功(HO_TTT64ms)
Test3 20100505 01:06:09.937 PCI48,>PCI50 切换成功(HO_TTT64ms) 2013-8-31 版权所有，侵权必究 第49页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
结论:
对于S_RSRP、N_RSRP都比较高的站内切换，切换点信道质量急剧恶化，需要提高切换
的及时性。建议适当改小切换门限(由3dB缩小为2dB)，缩短切换触发时间TTT(由128ms
缩小为64ms)。
6.1.15 信号交迭区，快速触发切换容易造成频繁的切入切出，信号陡降造成切换失败
从6.1的分析可以看到，对于S_RSRP、N_RSRP都比较高的站内切换，HO_TTT64ms可以提高切换成功率;然而，HO_TTT64ms不具有普遍适用性，test2将全网HO_TTT配置为64ms，造成了新的切换失败点，HO_TTT设置为128ms后切换成功。
2013-8-31 版权所有，侵权必究 第50页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
【案例1】
Test2 20100504 23:47:14.812 PCI9,>PCI56 目标侧未收到切换完成(随机接入失败) 分析:
1、由于HO_TTT64ms，快速触发切换。PCI56信号一冒出来就触发了切换，然而PCI56信号很快又衰弱下去(目标的RSRP比原侧的还要低)，导致切换随机接入失败(未收到RAR)。
2、Test1、3(HO_TTT128ms)在该地点的切换，切换均成功，没有出现目标侧RSRP陡降到低于原侧的情况。
2013-8-31 版权所有，侵权必究 第51页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
【案例2】
Test2 20100505 00:02:17.328 PCI50,>PCI266 UE未收到切换命令
分析:
1、HO_TTT64ms较之128ms更易触发切换，在信号交迭区频繁发生切换。在该切换点附近，PCI50信号冒了出来，于是发生了(PCI264,>)PCI266,>PCI50切换，切换成功;PCI50信号陡降，触发PCI50,>PCI266，然而下行信道质量太差，导致切换命令丢失。如果PCI50冒尖时不发生PCI266,>PCI50切换，那么就不会出现PCI50,>PCI266，也就避免了切换失败。
2013-8-31 版权所有，侵权必究 第52页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
、HO_TTT128ms时，该区域的切换关系为PCI264,>PCI266,>PCI50，避免了PCI50频繁的切入切2
出。
6.1.16 外部小区配置错误导致无法切换
深圳百站网现场路测中出现同站的两个小区，PCI分别为67和68，PCI68向PCI67可以正常切换，但是PCI67向PCI68切换异常。现象为源小区收到UE上报的A3测量报告以后不下发切换命令，最后UE由于信号质量过差，发生重建。现场反馈邻区关系已配置，ANR关闭。首先找到对应的IFTS跟踪，查看源侧收到A3测量报告之后的处理，从内部打印看，提示“Current Cell is Conflict:PCI is 68～”。怀疑现场的外部小区配置有问题，导致PCI冲突，在ANR关闭的情况下，无法切换。 2013-8-31 版权所有，侵权必究 第53页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
现场检查外部小区配置，发现错配了eNodeBID134的0号小区(PCI为68)为外部小区，导致与本站的PCI68的小区PCI冲突，因此不下发切换命令。
外部小区关系:
同频邻区关系:
现场删除多余的外部小区关系以后，可以正常切换。
6.2 切换用户面时延大问题
6.2.1 X2 IPPATH配置错误导致切换大时延
2013-8-31 版权所有，侵权必究 第54页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
挪威cluster验收中出现站间切换(OSL071和OSL186两站点之间)RLC时延偏大的情况，一般在60ms以上，甚至达到1s。
经过UE出临时版本抓取各个节点的时间戳，RLC层切换时延大的原因为:目标侧发送数据包延迟，在随机接入完成后100多ms才发送第一个数据包。此时有两种原因:1)源侧数据转发到目标侧的时延太大;2)源侧已将数据转发给目的侧，但是目的侧eNB没有及时发送。
经过家里验证测试，eNB收到UE的切换完成消息之前的20ms左右就已经收到了X2的转发包;但是现场的数据，跟踪文件中没有X2口的转发数据。并在切换时延正常的两个站点之间进行对比测试，发现是有X2口转发的数据包的。因此，问题聚焦到OSL071和OSL186两站点之间的X2传输上。
检查OSL071和OSL186两站点的X2_IPPATH，并将配置的IP地址与工参表进行比较，发现X2_IPPATH的地址配置成了OM IP。修改IP后，再进行站间X2切换，中断时延正常(30ms左右)。
【解决措施】
如果出现秒级的切换大时延，需要确认传输是否有问题，首先要检查X2相关配置(接口号、本端IP、对端IP)是否正确。
6.2.2 切换命令重传导致切换大时延
挪威路测中出现70ms左右的切换大时延。从UE侧时间戳看，源侧最后一个数据包与切换命令之间时间差偏大，切换命令收到较晚。
受切换区信道条件影响，会出现切换命令对应的PDCCH或PDSCH受限的情况，导致切换命令HARQ重传或ARQ重传。
切换命令初传不成功，HARQ重传进入频选，分配的RB数减少，导致重传无增益，进入ARQ重传，使得增大了切换时延。
从probe上看，MacRxLastSrb与MacRxLastDrb的时间差比较大。可能有两种情况:1)源小区收到最后一个SRB上的数据包(切换命令)比较晚;2)DRB上的数据包有重传。 2013-8-31 版权所有，侵权必究 第55页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
MacRxLastSrb与MacRxLastDrb的时间差比较大有可能是由切换命令重传导致的。
【解决措施】
该问题的解决方案是HARQ重传时不进入频选，合入eRAN1.0 B060SPC340版本。
在eNB侧提高切换信令传输的可靠性，尽管保证切换命令的正确下发，已合入eRAN 1.0 B060SPC350版本:
1)抬升切换命令PDCCH功率，同时固定CCE聚合级别为8;
2)抬升切换命令PDSCH功率，同时切换命令采用固定MCS1阶发送;
3)eNB侧直接将HARQ+ARQ重传(考虑到商用终端能力，该功能默认关闭);
4)合入DTX处理方案，解决初传解到DTX，HARQ重传无增益问题。
6.2.3 源侧数据包CRC连续错导致切换大时延
当切换区信号波动较大时，CQI调整算法不及时，会导致切换前源小区有连续的CRC错包，导致中断时延偏大。从Probe上看，源侧收到的最后一个DRB上的包时间戳较早。 2013-8-31 版权所有，侵权必究 第56页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
【解决措施】
eRAN1.0 B060SPC350版本合入以下优化措施，保证源侧数据的可靠下发:源侧L3收到切换测量报告后，指示L2对之后的数据采用低阶调度，MCS阶数可配，同时抬升对应的PDCCH功率，固定CCE聚合级别为8。
6.2.4 随机接入Preamble重传导致切换大时延
切换随机接入过程，Pramble多次重传导致切换时延偏大。
Preamble重传周期为20ms，最大重传次数为5次(初传加重传共5次)。Preamble重传次数越多，切换中断时延越大，重传一次中断时延增大20ms。
案例1:该次切换，随机接入流程Preamble发送了4次。由于Preamble重传，MacRxLastSrbTime(切换命令)与MacSendMsg3Time(切换完成)之间的时间差较大;加之该次切换，最后一个数据包和切换命令之间的间隔偏大(15.786ms);切换完成到收到第一个数据包之间的间隔大(28.482ms)。因此，该次切换中断时延超过了100ms。
2013-8-31 版权所有，侵权必究 第57页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开
案例2:发送两次Preamble，切换中断时延51.739ms。
【解决措施】
Preamble重传可能有两种原因:1)上行信道质量差;2)下行信道质量差，没有收到RAR，导致Preamble重传。调整覆盖或者切换参数，使得切换到目标侧瞬间具有较好的信道质量，减少重传次数。
6.2.5 UE未发/晚发PDCP状态报告
UE未发/晚发PDCP状态报告，导致目的侧eNB定时器超时后下发重复包，切换时延偏大。
用命令:LST TYPDRBRLCPDCP
查看PDCP状态报告指示是否为FALSE，PDCPSTATUSREPORTREQUIRE=FALSE;
如果PDCP状态报告置为FALSE，UE切换完成不发送状态报告;目标eNB收到切换完成后，立即将源侧eNB转发的数据下发给UE。这些数据中带有UE已接收到的数据包，即eNB下发了重复包，2013-8-31 版权所有，侵权必究 第58页，共59页
LTE TDD 问题定位指导书-切换篇 文档密级:内部公开 导致PDCP中断时延偏大(由于eNB立即下发了数据包，RLC层中断时延正常)。
因此，建议将PDCP状态报告设置为TRUE，以减少PDCP层切换中断时延。
当PDCP状态报告指示为TRUE时，UE发送切换完成并把状态报告在切换完成消息中发送给目标eNB。目标侧eNB在收到源侧转发的数据包endmarker后启动定时器，等待UE状态报告。如果由于信道质量差等原因，切换完成消息(状态报告)重传，目标侧eNB收到状态报告较晚，导致目标侧eNB给UE下发数据较晚，增大了RLC、PDCP中断时延。
6.2.6 UE侧处理系统消息及切换命令流程冲突
UE在更新系统消息同时收到切换命令，切换中断时延偏大。
受产品架构限制，UE只支持串行处理机制。对于切换的影响是:在更新系统消息的同时，如果收到切换命令，UE L3会先将切换命令缓存，等到系统消息流程完成之后，再处理切换命令。由于切换命令没有及时处理，会导致切换中断时延偏大。
【解决措施】
eRAN1.0 B060SPC360 UE版本合入:优化流程，如果在更新系统消息期间收到RRC连接重配置消息，则打断系统消息更新流程，优先处理RRC连接重配消息。
2013-8-31 版权所有，侵权必究 第59页，共59页
浙公网安备 33021202002483