LTE切换失败问题分析案例
案例-目标小区回复切换准备失败案例
目标小区回复切换准备失败案例摘要：LTE系统内切换包括三种类型：eNodeB内切换、X2接口切换、S1接口切换。
本文主要针对现网中存在最多的一类原因目标小区回复切换准备失败TOP区域分析，并进行全网推广核查和总结经验。
关键字：eNodeB内切换 X2接口切换 S1接口切换目标小区回复切换准备失败【故障现象】：统计6月10日至6月16日一周指标发现，阜阳全网日均切换失败次数约17万次，切换准备阶段出现的切换出准备失败次数约1.5万次。
华为网管报表目前仅能统计到切换准备阶段的失败原因分类，执行阶段的失败原因分类暂无法统计。
切换准备阶段4类失败原因：核心网原因、源小区发送切换取消、目标小区回复切换准备失败、目标小区无响应。
阜阳现网切换准备阶段的失败原因类型主要是目标小区回复切换准备失败。
颍上县的谢桥矿区、汤店、周楼区域部分站点目标小区回复切换准备失败次数较多，且主要集中在X2接口切换失败。
【告警信息】：无【原因分析】：Handover Request消息中可以看到切换的目标基站号、小区号、SGW 的IP地址。
Handover Request Acknowledge消息携带目标基站的ip地址。
实际分析，可以通过X2接口信令跟踪或是两两小区切换，查到切换失败的目标小区，进一步分析判断原因。
【解决方法】：1.FY-颍上-谢桥矿区-HFTA-436935-50通过两两小区切换指标发现谢桥矿区50小区向目标小区436943-52切换失败较多，且主要为目标小区回复切换准备失败。
网管查询 436943为迪沟路口基站，小区号为53、54、55。
而网管配置的谢桥矿区50小区同频邻区列表里为436943-52小区。
查询其定义的外部小区，发现定义了436943的50-55小区均为迪沟路口。
怀疑迪沟路口初始规划挂在前3个端口，而实际施工挂在了后3口。
邻区并没有同步更新，导致配置了不存在的小区，从而发生目标小区回复切换准备失败。
LTE切换为题处理案例及切换参数总结
LTE切换为题处理案例及切换参数总结切换问题处理及切换参数总结⽬录：简述：地铁部分FDD线路分布问题导致覆盖盲区场景下，FDD切TDD。
由FDD 站点覆盖快速衰落情景下，终端开启A2测量，信令窗⼝中频繁上报MR，⽆响应，切换失败导致重建。
经由本次问题处理，对切换参数进⾏总结。
⼀、案例分析：1.1.问题描述：由芍药居⾄太阳宫段，FDD切TDD终端占⽤1350(PCI=467) ENB=502165，地铁⾏驶过程中，信号快速衰落，终端开启A2测量，信令窗⼝频繁上报MR，⽆响应，切换失败导致RRC重建⾄1350（PCI=496）502163，经由此站切换⾄TDD38950（PCI=87）ENB=82354-42海淀⼗号线海淀黄庄站FDDNLS1.测试结果：1.2.优化：●参数查询：A1:-92，A2 :-100，A5 :-90，-95 CIO:0db TTT: 640ms●调整：由于FDD衰落迅速，⼏次测试均有-92左右迅速衰落⾄-120,导致重建，所以建议将A2门限提⾼，同时为满⾜快衰场景下能够顺利切换，将CIO调为10，使其提前切换，TTT切换切换时间由640ms改为160ms调整后参数：A1:-90，A2 :-92，A5 :-90，-95 CIO:10db TTT: 120ms●调整后测试⼆：切换参数总结：当UE处于连接状态，⽹络通过切换过程实现对UE的移动性管理。
切换过程包含移动性测量、控制⾯流程和⽤户⾯流程。
为了辅助⽹络作切换判决，原eNodeB为UE配置测量，使UE在切换之前上报服务⼩区和邻⼩区的信道质量，便于⽹络侧合理地判决切换。
测量配置基本信道参数表●eueMeasCellSMeasureRsrpSmeasure：服务⼩区RSRP门限启动测量的服务⼩区RSRP门限，取值(-141..-44)，单位为dBm。
此参数仅对针对信道质量的测量配置有效，对于针对CGI上报的测量配置⽆效。
对于针对信道质量的测量配置，当⽹络侧没有配置此参数，或者配置了此参数，且服务⼩区RSRP低于此参数指⽰的门限值时，UE根据测量配置对邻⼩区进⾏测量和上报。
LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功关键字：X2IPPATH 切换【现象描述】切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：（1）传输资源不够用；（2）没有配置IPPATH；（3）IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令（RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下：LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId，查看X2口两端的IP配置是否正确。
TDD-LTE宏站切换失败小区问题分析
TDD-LTE宏站切换失败小区问题分析
作者：李俞瑾
邮箱：liyujin@
所在省：辽宁
关键字：邻区漏配;宏站;弱覆盖;掉线;下载速率低;
专业：无线/TD-LTE
设备类型：ENODEB
设备厂家：无线/华为
设备型号：BTS3900 LTE
软件版本：V100R008C01SPC100
故障描述：
LTE站点1小区在单验过程中，由站内向站外切换成功，但由站外向站内切换失败，并且RSRP差距大于10dB。
该测试小区RSRP相对良好，并无任何告警。
故障诊断：
1、处理流程图：
2、原因分析：
经查看，测试小区无告警，并且与站内邻区切换正常，且事件发生在由站外小区切换到站内小区，初步分析原因为邻区漏配或者切换门限过大
针对问题表象，分析处理步骤如下进行：
（1）、邻区参数核查
（2）、切换门限阀值核查
处理过程：
步骤一：联系后台人员对LTE小区进行切换门限阀值核查，发现该小区并不存在切换门限阀值过大。
步骤二：联系后台人员对LTE小区进行邻区参数核查，发现该站外小区并不
存在测试小区邻区。
预防/监控措施
添加邻区。
认真核查邻区参数，防止因为邻区漏配引起的弱覆盖等
调整后测试结果分析。
经典案例-关于LTE终端异常导致厂家边界切换失败问题处理最佳实践总结
宁波FDD-LTE异常终端切换失败处理案例1、概述随着L800站点大规模入网，室外L800M已经实现连续覆盖，优化问题也接踵而来，最近在处理厂家边界（华为&中兴）切换问题时，发现一对小区切换成功率极低，需紧急处理。
图表12、问题描述近期华为区域全网切换指标持续下降，查询TOP小区是发现位于华为与中兴边界处一对L800小区切换成功率较低，影响全网指标，下表为问题站点切换指标统计：图表23、问题分析定位3.1 问题分析分析TOP小区分析切换失败原因值、两两切换统计值，以”LF_H_JD甬波波城北_25为例，切换失败原因是“目标小区回复切换准备失败消息导致同频切换出准备失败”，两两切换统计，失败次数都集中目标小区都是中兴：图表3根据Top小区指标初步分析，主要是由于中兴侧基站回复切换拒绝导致切换失败，下一步通过标口信令分析深一步分析失败原因，筛选出切换失败的消息，该消息是目标基站返回给源基站，携带有切换失败的原因值。
如下图所示，携带的原因值为no-radio-resources-available-in-target-cell(12)图表4原因值解释：目标小区无足够资源可用，最终导致切换阶段失败。
本次切换准备失败TOP小区都是此类原因，但实际目标小区负荷不高。
3.2 问题定位由于该基站有切换成功的情况，华为侧选取切换失败与切换成功信令进行分析对比，结果如下：1)当华为L800M基站X2口切换请求消息中携带终端支持BAND5字段，无论800M目标小区是否为中兴切换都会成功；图表5 携带band52)当华为L800M基站X2口切换请求中未携带终端支持BAND5字段，若L800M目标小区为中兴，则会回复切换失败消息，原因值就是”no-radio-resources-available-in-target-cell”图表6 不携带band5中兴侧信令回复分析：针对回复切换失败消息，原因值就是”no-radio-resources-available-in-target-cell”问题，当中兴L800M小区作为目标小区，需要核实源侧发送的“HANDOVER_REQUEST”消息中RRC_UE_CAP_INFO信息是否携带支持band5，如未携带支持band5，中兴侧eNB就不会生成切换命令，导致切换失败。
基于S1接口切换失败-分析
.教育资料基于S1接口切换失败分析2014-09-25一、概述广州LTE网络的S1切换性能从9月18日开始，出现HO Prepare Fail “切换出准备失败_目前侧准备失败”次数增加明显，总体切换成功率从98.9%恶化到98.5%左右。
失败切换的邻区关系，在小区和TAC维度存在聚类。
二、S1-Based Handover信令流程LTE网络S1接口的切换流程：➢源eNodeB决定进行基于S1的切换。
S1切换的原因可能是源eNodeB和目标eNodeB之间不存在X2连接，或者源eNodeB根据其他情况作出的判断。
➢源eNodeB向源MME发送Handover Required消息，其中Handover Type 在此时是intra-LTE，TargetID包含Target Cell ID和Target TAI两部分，源MME可以根据目标TAI来选定合适的目标MME。
Direct Forwarding Path Avaliability用来指示在源和eNodeB之间是否存在存在直接转发的路径还是需要进行Indirect Tunnel Forwarding。
➢源MME选定合适的目标MME，通过S10接口发送Forward Relocation Request消息给目标MME。
➢目标MME选定相应的目标SGW，发送Create Session Request消息给目标SGW，消息中包含每个承载的上下文。
目标SGW为数据承载分配上行GTP －U的地址和TEID值，返回Create Session Response消息给源MME。
➢目标MME发送Handover Request消息给目标eNodeB，其中包括要建立的EPS承载的列表等内容，每个EPS承载的信息包括SGW的地址，上行GTP －U的在SGW侧的TEID值，EPS 承载的QoS等。
目标eNodeB收到上述消息后会建立UE上下文，包括承载的信息，安全上下文等。
LTE同频切换失败优化
LTE同频切换失败优化案例【摘要】ANR邻区自动优化功能开启后，一些新开通4G小区由于实施RF优化前覆盖过远，极易被切换源小区添加为同频邻区关系；同时源小区也添加了相同PCI的另一距离较近的切换目标小区邻区关系，终端由源小区向目标小区切换时，根据PCI遍历邻区关系列表，发现存在两处相同PCI的邻区关系后，基站会要强求终端上报ECGI，若因终端问题或其它因素导致ECGI上报失败，容易产生切换失败问题。
【关键字】ANR 同PCI ECGI【故障现象】：市区优化DT测试期间，终端占用43633-邮政储蓄银行2小区由北往南至436218-天上人间3小区出现一次同频切换失败现象。
DT测试软件截图如下图1图1：同频切换失败【告警信息】：U2000网管查询基站无告警图2：告警查询【原因分析】：同频切换失败原因较多，如基站故障、邻区漏配、切换参数配置不合理等都有可能导致切换失败问题，具体分析处理如下。
核查43633-邮政储蓄银行2与436218-天上人间3小区邻区关系表及同频切换参数配置正常。
图3：邻区核查配置正常436218-天上人间3小区PCI配置PCI85正常图4：目标小区PCI配置查询操作日志核查43633-邮政储蓄银行2与436218-天上人间3小区DT测试期间无任何操作。
图5：操作日志查询回溯切换失败前基站下发的切换配置消息中，基站要求终端上报PCI85的ECGI信息，截图6如下图6：ECGI上报请求根据LTE同频切换流程可知终端由源小区向目标小区切换时，会根据PCI遍历邻区关系列表，若发现存在两处相同PCI的邻区关系后，基站会要强求终端上报ECGI方式来判断最终切换目标小区。
图6信令的出现表明43633-邮政储蓄银行2小区存在两条相同PCI85的邻区关系，核查43633-邮政储蓄银行2的外部小区中PCI为85的存在436670-51/436218-55两个外部小区，查询结果如下图4图7：外部小区核查结果43633-邮政储蓄银行2小区邻区列表中436670-51/436218-55已添加邻区关系，查询如下图8图8：邻区关系核查结果回到DT数据中终端切换流程，基站要求终端上报ECGI信息，根据MSGID找到相应的终端测量报告，打开发现终端上报PCI85的小区ECGI为空值，如下图9图9：ECGI上报失败至此已确定是因终端上报目标小区ECGI信息不成功导致切换失败问题，本次测试终端为华为MATE8：LTER10版本，实际自R9版本及以上终端大部分是支持ECGI上报功能。
LTE切换问题分析
1相关Counter介绍1.1 切换相关KPI公式（L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧eNB间切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut)*100% ✧同频切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.IntraFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut)*100% ✧异频切换出成功率（L.HHO.IntereNB.InterFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧切换出成功率（L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut+ L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut-L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% 1.2 Counter解释Counter解释：✧切换成功率Counter✧切换失败counter原因：1.3 Counter计数位置及说明1.3.1站内切换图（2）1.3.2 X2切换图（3）2.3.3 S1切换图（4）注明：尝试切换Counter都计数在A点位置，准备切换Counter都计数在B点位置，切换成功Counter都计数在C点位置1.3.4 切换失败Counter说明图（5）a). 在S1接口切换及X2接口切换过程中的切换准备阶段，源小区收到来自MME的UE CONTEXT RELEASE COMMAND消息时，如果切换过程中源小区和目标小区为同频或异频，指标L.HHO.Prep.FailOut.MME加1。
经典案例_异系统切换失败导致Volte掉话排查案例
异系统切换失败导致Volte掉话排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (9)异系统切换失败导致Volte掉话排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。
【关键字】VoLTE掉话异系统切换【业务类别】VoLTE一、问题描述2019年3月31日宣城电信RCU设备在市区进行拉网测试时出现VoLTE异常掉话现象，问题点位于宣州区水阳江大道宛陵湖展览馆附近。
测试设备在其他基站可以正常进行VoLTE呼叫，基本可以排除测试设备的问题。
并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。
需要信息分析优化定位故障并解决。
二、分析过程（一）、排查思路分析VoLTE掉话分为UE上下文释放、E-RAB承载释放两类掉话。
端到端信令VoLTE掉话：当eNodeB收到来自MME的E-RAB RELEASE COMMAND（UE CONTEXT RELEASE COMMAND）消息，或eNodeB向MME发送E-RAB RELEASE INDICATION（UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection”，“Successful Handover”时，如果释放的承载包括QCI=1，则判断为VoLTE掉话。
核心网异常导致pathwtich 切换失败案例
New - OZ_CELLLTE : GLOBAL_CELLLTE (3343) 11/19/2014 00:00 to 11/20/2014 23:00 (Asia/Shanghai) (Working Zone:…
No unit 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 11-… 4000.00 2000.00 0.00
VS_HO_IrC_X2_fail_exec_TimeoutS1PathSwitch_tgt_OD(L12713_5)
结合该时间的操作来看，三家设备（大唐，华为，贝尔）相同时段切换成功率均出现较 为明显下降，建议核查此时间内，MME 以及 PTN 是否作过大面积的操作，以尽快解决此问 题。
14760 14954 16543 764 2134 27205 3 7 8 5 11952 13685 13061 16452 9618 9636 9949 8925 7544 7818 11519
16617
15917
13236
14747
166
105
62
97
131
52
53
由以上内容可以看出，造成 X2 切换失败的主要原因为 PathSwitch 失败。 从 L12713_5 的分布比例来看，在一天存在 X2 切换的 3343 个小区来看，11/18/2014 L12713_5 计数的小区有 593 个增加到 11/24/2014 L12713_5 计数的小区有 2688 个，过滤完 切换次数低于 100 次的小区后，可以大致看到 11 月 20 号起，由于 path switch 超时，导致 切换失败率平均增加 3%左右，与全网切换成功率下降幅度大致保持一致。 再从时间来看，大致问题出现时间在 20 号凌晨：
LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功关键字：X2IPPATH 切换【现象描述】切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：（1）传输资源不够用；（2）没有配置IPPATH；（3）IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID 确认目标基站B2的ID。
从该次切换的切换命令（RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下：LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId，查看X2口两端的IP配置是否正确。
LTE-华为-传输模式不一致导致切换失败
传输模式不一致导致切换失败问题现象：荣昌高铁站-HLHA在站台优化添加了与爱立信站点荣昌高铁站-ELW跨厂家邻区后观察指标，切成功率掉至12%左右，切换指标非常差。
下表为邻区添加前后指标：原因分析：1、分析问题可能原因：●站点告警导致切换失败；●邻小区定义数据错误导致切换失败；●同频同PCI导致切失败；●邻小区拥塞导致切换失败；●切换参数配置不当导致切换失败；●站点干扰大导致掉线；●弱覆盖导致掉线；●X2接口配置数据错误导致切换失败；●PRACH配置冲突导致切换失败●其他原因；分析及解决步骤：1.查询站点实时告警及历史告警信息，站点状态正常无告警和历史告警。
查询截图如下：2.邻小区定义数据和同频同PCI情况，检查配置的移动国家码，移动网络码，基站标识，小区标识，下行频点，物理小区标识，跟踪区码均配置正常，且邻区内和5公里范围内无同频同PCI情况。
3.检查邻小区拥塞情况，查询立信站点荣昌高铁站-ELW话务情况，无拥塞情况。
4.切换参数配置情况，参数配置正常。
5.站点干扰和弱覆盖情况，提取上行干扰情况正常，现场测试反馈无下行干扰和弱覆盖情况。
6.X2接口配置数据检查,X2接口配置数据正常。
7.PRACH配置冲突导致切换失败，检查PRACH配置无冲突。
8.提取掉线原因值进行分析，从话统上看，切换失败时，“目标小区回复切换准备失败消息导致模式内切换出准备失败次数”占比非常高，而切换正常时，基本没有这个问题9.X2信令跟踪，有大量的“HandOver_Preparetion+failure”，内部原因值为“no-radio-resources-available-in-target-cell”10.统计信令切换失败的QCI分布，其失败主要由于QCI=7业务下切换时导致切换失败，其他QCI情况下切换成功。
检查QCI=7时RLCPDCP参数组配置为如下图：查询RLCPDCP参数组1时为UM模式，5时AM模式。
中国移动LTEVOLTE案例分析汇总
广东移动4GTD-LTE详细案例分析案例1：580 Precondition Failure导致的未接通;问题描述在集团测试LOG中,存在Precondition Failure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580 Precondition Failure消息,随后呼叫中止,出现未接通事件;Log文件名：MO UE:MT UE:时间：10：16：1、呼叫过程中,被叫发送Ringing 180后,收到网络下发的专载去激活命令,QCI 1被释放,被叫随后上报580 Precondition Failure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通;2、从信令中可以看到,被叫回复Ringing 180且主叫也已经收到Ringing 180,被叫随后收到网络侧下发的RRC重配,携带有QCI 1被释放的信息,被叫去激活专有承载;由于专载已被释放,业务资源已不存在,所以被叫上发580 Precondition Failure 失败消息;主叫收到网络侧下发的580,接续被中止,导致了会话未接通;3、从MME下发到Node B的E-RAB RELEASE COMMAND,原因上看是Nas层nomal_release,导致专载QCI 1被释放;4、专载QCI 1被释放,去激活后,被叫发送INVITE 580,主叫收到网络侧转发的INVITE580,会话流程中断,导致未接通在正常的会话流程中,由于MME下发E-RAB RELEASE COMMAND,使得QCI 1被释放,导致未接通;解决措施需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND;测试验证案例2：Server Internal Error 500导致的未接通问题描述在集团测试LOG中,存在Server Internal Error 导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的Server Internal Error 500消息,随后呼叫中止,出现未接通事件;Log文件名：MO UE:MT UE:时间：10：19：问题分析1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE 200,随后被叫发送Ringing 180,主叫同时收到UPDATE 200和Ringing 180;按照正常的信令流程应该是先收到UPDATE 200,再收到Ringing 180;2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放,去激活,导致会话未接通;问题定位主叫收到网络侧下发的INVITE 500,然后网络侧又下发RRC重配,释放掉QCI 1,然后去激活,会话流程终止,导致未接通解决措施需要核心网确认,为什么会下发INVITE 500,什么情况下会导致网络侧下发INVITE 500,随后的专载释放是否由INVITE 500导致的测试验证案例3：软件对失败事件的误判导致统计错误问题描述在集团测试LOG中,存在软件的误判而错误统计的失败事件;如在某个特定时间点上,信令显示主被叫正常通话,软件却统计出掉话或未接通事件;Log文件名：MO UE:MT UE:时间：09：44：问题分析1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功,在通话过程中信令流程正常,中间出现一次RRC重建被拒,导致RRC释放,事件表现为掉话,软件统计为掉话;2、在09：44：主叫收到网络侧下发的RRC重建被拒,主叫随后发起RRC建立请求,在09：44：15：004,然后因为TAU,在09：44：15：128 RRC Connection Release了,软件统计为掉话;随后主叫又发起RRC连接,且在09：44：重建完成,从RRC重建被拒到RRC连接成功不到1s,且默认承载和专有承载均保持,未被释放,证明会话保持正常;3、到最后结束通话正常挂机都没有出现失败事件问题定位主叫接通后,在没有收到通话结束的情况下,中间出现RRC Connection Release,软件判断为掉线,此次是在会话建立后出现,软件统计为掉话解决措施需要鼎利修改判断事件失败的机制测试验证案例4：软件对失败事件的重复统计问题描述软件对于失败事件存在重复统计的问题,在集团测试问题统计表中,多次出现同一次失败事件,软件却作了多次统计,导致失败事件的增多;Log文件名：MO UE:MT UE:时间：10：04：问题分析1、主叫在10：04：发出INVITE会话请求,被叫在10：04：收到网络侧下发的BYE Request,软件统计为掉话;查看BYE Request中的CALL-ID,发现是上次会话的BYE Request2、被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100,又在10：04：收到网络侧下发的INVITE Request同时发送Trying 100,并在同时发送INVITE 486,软件统计为未接通;3、主叫在收到网络侧下发的UPDATE 200后,在10：04：上报Cancel,主叫的整个会话流程到这里被终止,事件上表现为未接通;且承载都存在问题定位通话期间,被叫收到网络下发的BYE Request会被软件统计为掉话;被叫连续两次收到网络下发的INVITE Request,回复INVITE 486 Busy Here,由于第一次INVITE Request未释放,故第二次INVITE Request网络侧才会下发INVITE 486,流程停止,软件统计为未接通;此时主叫在进行正常的会话接续,信令流程正常,事件中未出现失败事件;直到主叫上报Cancel,主叫会话流程停止,事件表现为未接通,之前的两次失败事件统计是重复统计;解决措施需要鼎利确认对失败事件的统计机制;测试验证案例5：LTE到2G eSRVCC切换失败导致的掉话问题描述呼叫会话建立后,由于到达异系统B2门限,终端上报B2事件,网络下发eSRVCC切换配置命令,但在2G侧切入失败,导致掉话;Log文件名：MO UE:MT UE:时间：11：16：42：311问题分析1、被叫上报B2事件,满足切换门限系统下发mobility切换命令,此时4G的流程已完成,接下来切入2G网络,2G网络下发TMSI Reallocation Command,被叫回复TMSI Reallocation Complete,此后流程中断,eSRVCC切换失败;3、信令上看,4G流程正常走完且建立会话,被叫切换到2G,但是网络下发TMSIReallocation Command导致流程终止,eSRVCC切换失败,会话流程结束,怀疑是2G问题;问题定位4G流程正常且已正常建立会话,由于2G网络侧下发TMSI Reallocation Command导致eSRVCC 切换失败,会话流程结束,导致掉话,怀疑是2G的问题;解决措施下周准备复侧,准备定位;测试验证案例6：TAU过程中RRC Connection Release 导致的未接通问题描述在越秀区网格10的测试LOG中,出现如下的未接通事件：主叫起呼发出Invite消息后,在收到网络效应Trying 100之前,先收到了网络下发的RRC Connection Release消息,RRC连接释放后,接续被终止,出现了Blocked Call事件;问题分析1、通过信令详细分析主叫起呼的过程,可以发现,起呼前,主叫刚完成重选过程,从PCI216小区重选至PCI103小区,由于源小区与目标小区处在不同的TAC,主叫发起了TAU请求：2、在主叫上发TAU请求后,未等网络回复ATU Accept,主叫已开始了起呼,上发Invite消息;然而Invite上发后,主叫同时收到了网络下发的ATU Accept和RRC Connection Release 消息因此时主叫处在非业务态,ATU更新会伴随RRC连接的释放,主叫被叫释放,从而导致了Blocked Call事件的发生：3、进一步分析信令可以发现,主叫在该测试路段内连续在3个TAC9437、10315、10014间进行TAU更新,其中从11:42:53至11:43:04就发生了4次,可能在存在TAC规划不合理的问题;问题定位解决措施测试验证案例7：Alerting中eSRVCC失败导致未接通问题描述主叫起呼后,流程正常,达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180,主叫未摘机,由于切换失败导致未接通;Log文件名：MO UE:MT UE:时间：11：25：28：189问题分析1、主叫在11：25：起呼,到11：25：收到网络侧转发的Ringing 180,整个信令流程正常2、在主叫几乎收到网络侧转发的Ringing 180的同时,主叫达到eSRVCC切换门限,网络侧在11：25：下发eSRVCC切换命令,在切换过程中主叫处于振铃中,并未摘话,而切换失败,导致了未接通;问题定位主叫已经收到Ringing 180,处于振铃状态还未摘话,由于在Alerting中发生了eSRVCC 切换失败导致了未接通解决措施需要核心网方面帮忙定位测试验证案例8：CSFB失败导致未接通问题描述主叫起呼后,被叫CSFB失败,主叫直接Cancel导致未接通Log文件名：MO UE:MT UE:时间：15：42：53：063问题分析1、主叫于15:42:22发起invite,被叫未收到网络侧转发的INVITE Request,但是主叫能一直收到网络侧下发的INVITE 183 、PRACK、UPDATE消息,这些消息被叫并没有收到也没有回复;被叫在15:42:24收到网络侧下发的CSFB request,但CSFB到2G后从信令看没有呼叫相关的信令交互过程2、直到15:42:35 CSFB失败,由于收不到被叫的响应,主叫主动于15:42:53发起CANCLE;导致会话未接通;问题定位主叫发起会话后,被叫没有收到会话请求,直接CSFB,CSFB失败,主叫一直未收到被叫的响应,直接Cancel,导致会话未接通;解决措施需要核心网查看为什么被叫没有收到主叫的会话请求,且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息;测试验证案例9：被叫Detach导致会话未接通问题描述主叫发起会话,被叫驻留在2G未返回4G,没有响应主叫的会话请求,主叫收不到被叫相应,直接Cancel导致未接通;Log文件名：MO UE:MT UE:时间：15：43：37：999问题分析1、主叫在15：43：起呼,此时被叫任然驻留在2G,由于上一次会话中CSFB失败,并没有返回4G;2、起呼后,被叫一直无响应,没有与主叫进行信令交互,然而主叫能一直收到网络侧下发的PRACK、UPDATE消息;3、主叫一直收不到被叫的回复,被叫在15:43:被叫上发Detach Request,主叫在15：43：上发Cancel,取消会话,导致未接通问题定位被叫停留在2G未返回4G,然后上发Detach Request,主叫收不到被叫的回复,直接Cancel,导致未接通解决措施需要核心网查看为什么主叫会话信令流程正常,被叫却无法收到主叫的会话请求;同时查看2G无线侧,为什么被叫会上发Detach Request;测试验证案例10：承载未建立导致未接通问题描述主叫收到100 Trying 后未建立承载,使得 RRC直接释放,导致未接通Log文件名：MO UE:MT UE:时间：15：46：36：271问题分析1、主叫在15：46：发起会话,收到网络侧下发的100 Trying后,专有承载一直未建立,10s后RRC释放,主叫在15：46：上发Cancel,导致会话未接通问题定位专有承载未建立,10s后RRC释放,导致未接通解决措施需要核心网查看为什么没有建立专有承载测试验证案例11：承载异常释放导致掉话问题描述被叫重建立成功后,专有承载突然被释放,导致掉话Log文件名：MO UE:MT UE:时间：10：35：41：981问题分析1、主叫在10：28：起呼,流程正常,收到网络侧转发的Ringing 180,UPDATE 200,主被叫会话正常建立;2、被叫在10：35：发送重建立,重建立成功,且流程正常,但是在10：35：承载被释放,导致掉话问题定位会话建立后,被叫重建立完成,但是专有承载被释放,导致掉话解决措施需要核心网确认承载释放的原因测试验证案例12：信令转发失败导致未接通问题描述主叫发起会话请求,网络侧未转发,被叫未收到,主叫Cancel,导致未接通Log文件名：MO UE:MT UE:时间：10：03：48：952问题分析主叫在10：03：发起会话,被叫未收到,直到10：03：主叫Cancel,会话接续无法继续,导致未接通;整个过程无线环境良好,网络侧未转发信令;问题定位网络侧未转发主叫会话请求,使得会话接续无法继续,主叫Cancel,导致未接通;解决措施需要核心网确认会话信令是否成功转发测试验证案例13：终端上报Cancel导致会话未接通问题描述会话流程正常接续,终端上报Cancel,导致会话未接通Log文件名：MO UE:MT UE:时间：14：53：06：510问题分析1、主叫在14：53：起呼,信令流程正常,且被叫上发Ringing 180,主叫收到网络侧转发的Ringing 180,主被叫都已经振铃;但是主叫突然在14：53：上发Cancel,被叫也收到网络侧转发的Cancel,会话接续停止,导致未接通;问题定位主被叫会话流程正常,无线环境良好,信令转发正常;主叫上报Cancel,导致会话未接通,定位为终端问题解决措施需要终端确认或者更换终端测试再查看结果测试验证。
MME Pool内MME配置缺失导致TD-LTE切换失败案例分析
连接． 如 果 、 ； 与 ｌ ｌ 内 某 个 ＭＭＩ ： 之 间 的连 接 中断 ， 该 Ｍ Ｍ 上的用户会重新附着到 Ｐ Ｉ 内 其 它 ＭＭ 上， 但 其 他 站 点 附着 到 该 ＭＭ Ｊ ： 的 用 户切 换 到该 小 区时 会 发 生切 换 失败 。 本 文 从 实际 应 用 ｍ 发 ， 对Ｔ １ ） 一 ｌ ： 中 因 Ｍ￣ １ Ｉ 配 置 缺 失 导 致 切 换 问题 进 行 深 入 分 析 和 总 结 ， 希 单 对 同 类 网络 优 化 问题 起 到 指 导 借 豁作 用。
曲
ｍ
崮 １
２ ． １ 检
站 艇什 故障
核 查安 居 楼 房 沟 村一 Ｉ １ ． 安 居 高速 縻 溪 登 高 村一 １ Ｉ 两 个站 点 其 他 关 键 ＫＩ ， ｌ 性能指标情况 ． 经 核 壹 分析 发 现 ， 该 站 除 了切 换 成 功 率 差 ，其 他 各 项 指 标 均 正常 （ Ｒ ｝ ｛ 【 ： 接 八成功 率 、 ｛ ＡＩ ；接 入 成 功 率 均 为 ｌ （ ） ０ ％）
安 屠高进 ５ ３ ２ ３＾ 登 高村
一
口
２ 原１ 人 １ 分析
如 闫 ！所 示 ． 蚤居 楼 房 沟 村一 Ｉ ¨， 安 居 高 速 唐溪 登 高 村一
： Ｉ ¨ 两 个站 点 均 为渝 遂 高速 覆 盖小 区 ． 遂 用 户 流 动性 较 强 ． 归
属 ＭＭ｝ ｃ下 一 致 的 用 户 量 较 大
TD-LTE异频切换不及时类问题解优化思考.doc
TD-LTE异频切换不及时类问题解优化思考1.概述切换是移动性管理的重要功能之一，自LTE商用以来，网络覆盖的提升，LTE用户数量逐步加大，LTE的切换重要性就显得更加的突出，它不仅影响着小区边界处的呼叫服务质量，还与网络的负载情况有着紧密的联系。
随着后期VOLTE的部署，VOLTE对业务实时性具有更高的要求，合理的切换就更具有举足轻重的作用了。
如果切换过程进行得不好的话，很可能造成小区的过载和移动台的“掉话”，使网络服务质量大大下降，严重影响用户感知。
而如何让用户更好的享用4G,体验高速上网和高质量语音业务，成为研究课题。
2.发现问题通过现网后台指标提取、现场测试、数据分析、用户投诉等方式发现问题，具体影响切换的因素如下图：3.优化思路所有的异常流程都首先需要检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。
整个切换过程异常情况我们分为几个阶段：1、测量报告发送后是否收到切换命令。
2、收到重配命令后是否成功在目标测发送MSG1。
3、成功发送MSG1之后是否正常收到MSG2。
图3-1为切换问题整体过程流程图，在某一环节出现问题我们可查询相应处理流程进行排查。
测量报告是否收到切换命令MSG1是否发送成功流程1否是是否收到RAR是流程2否流程3否结束发送重配完成（MSG3）是图 错误!文档中没有指定样式的文字。
-1 切换问题分析整体思路3.1测量报告发送后未收到切换命令这个情况是我们外场最常见问题，处理定位也比较复杂，分析流程见图3-2： 基站未收到测量报告（可通过后台信令跟踪检查）：1、检查覆盖点是否合理，主要是检查测量报告点的RSRP,SINR 等覆盖情况，确认终端是否在小区边缘，或存在上行功率受限情况（根据下行终端估计的路损判断）。
如果是该情况，按照现场情况调整覆盖，及切换参数，解决异常情况2、检查是否存在上行干扰，可通过后台查询，如：在20M 带宽下，基站接收无终端接入时接收的底噪约为-98dBm ，如果在无用户时底噪过高则肯定存在上行干扰，上行干扰优先检查是否为邻近其他小区GPS 失锁导致，当前版本暂不支持后台工具定位干扰源位置，只能将通过关闭干扰源附近站点，使用Scanner 进行CW 测试来排查。
参数配置导致切换失败优化案例
芜湖LTE参数配置导致切换失败优化案例网优中心李晓刚【摘要】测试中UE由LTE_鹤毛2小区（PCI:49)向LTE_鹤毛1小区(PCI:50)切换失败。
重新核查参数，发现邻区配置参数存在问题。
【关键字】LTE邻区配置参数【故障现象】一、LOG分析，UE在四号大街由东向西行驶，占用LTE_鹤毛2（PCI:49）UE上发测量报告，目标小区为LTE_鹤毛1（PCI:50），当RSRP相差10db仍未发生切换，1秒后出现“HandOver Failed”。
图1：前台标示（初测）【告警信息】网管上检查周边基站，无告警且工作正常。
【原因分析】1、核查切换参数：配置正确无问题；2、核查邻区配置：均已配置；3、怀疑设备问题，重启设备，复测问题依旧；4、尝试重新配置邻区：删除原邻区配置，重新添加双向邻区，进行复测，切换关系正常，如下图所示图2：前台标示（复测）【解决方法】1、重新核查参数，发现邻区配置参数存在问题。
正常邻区配置参数如下：eNodeB IP，eNB id，MCC，MNC，MNC length in PLMN，如172.27.0.121 442820 460 11 2存在问题的邻区配置参数如下：172.27.0.19 0 0 0 2 172.27.0.99 172.27.0.105 2 172.27.0.106 172.27.0.121 442820 460 8 2 172.27.0.123 442820 460 11 2172.27.0.139由于前期工程部门配置邻区参数存在问题，需要重新正确配置。
【结论与推广】通过对邻区配置参数优化调整，有效的改善了邻区切换问题，对小区邻区切换情况有了一定程度上的改善和提升。
在小区邻区切换主要有以下几种优化调整方法思路：思路一：核查切换参数。
思路二：核查邻区配置。
LTE切换问题定位指导二(切换问题分析)
LTE切换问题定位指导一（切换问题分析）目录1站内切换，随机接入失败导致切换失败 (1)2站内切换，切换完成丢失导致切换失败 (4)3X2切换，源侧等待上下文释放命令超时 (6)4 X2切换，S1PathSwitch失败导致切换失败 (8)5切换随机接入失败触发重建，重建重配失败而掉话 (11)6eNB未响应UE切换测量报告，信道质量恶化而掉话 (12)7切换命令丢失导致切换失败 (14)8X2切换，Preamble丢失导致切换失败 (16)9X2切换，目标侧等待S1PathSwitchAck超时导致切换失败 (18)10X2切换，随机接入失败触发重建，重建完成丢而掉话 (21)11站内切换，随机接入失败触发重建，重建失败而掉话 (22)12站内切换，切换完成丢失触发重建，重建失败而掉话 (25)可以通过CHR分析切换问题，以下举例给出CHR分析切换问题的方法。
1站内切换，随机接入失败导致切换失败CHR中记录的释放原因值为usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT，如下图。
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 最大重传次数配置为10次），说明UE 没有收到RAR 而进行了Preamble 重传，并且达到最大重传次数10。
移动LTEVOLTE案例分析汇总
移动L T E V O L T E案例分析汇总Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】广东移动4GTD-LTE详细案例分析案例1：580PreconditionFailure导致的未接通。
【问题描述】在集团测试LOG中，存在PreconditionFailure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580PreconditionFailure消息，随后呼叫中止，出现未接通事件。
Log文件名：MOUE:MTUE:时间：10：16：【问题分析】1、呼叫过程中，被叫发送Ringing180后，收到网络下发的专载去激活命令，QCI1被释放，被叫随后上报580PreconditionFailure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。
2、从信令中可以看到，被叫回复Ringing180且主叫也已经收到Ringing180，被叫随后收到网络侧下发的RRC重配，携带有QCI1被释放的信息，被叫去激活专有承载。
由于专载已被释放，业务资源已不存在，所以被叫上发580PreconditionFailure失败消息。
主叫收到网络侧下发的580，接续被中止，导致了会话未接通。
3、从MME下发到NodeB的E-RABRELEASECOMMAND，原因上看是Nas层nomal_release，导致专载QCI1被释放。
4、专载QCI1被释放，去激活后，被叫发送INVITE580，主叫收到网络侧转发的INVITE580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RABRELEASECOMMAND，使得QCI1被释放，导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RABRELEASECOMMAND。
【测试验证】案例2：ServerInternalError500导致的未接通【问题描述】在集团测试LOG中，存在ServerInternalError导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的ServerInternalError500消息，随后呼叫中止，出现未接通事件。
LTE核心网鉴权关闭导致切换失败
LTE核心网鉴权关闭导致切换失败现象描述：
在某TDD-LTE实验网，站间小区切完后直接RRC CONNECTION RELEASE，切换失败率增加。
告警信息：
无
原因分析：
LTE核心网鉴权关闭导致切换失败
处理过程：
前台测试信令
1、 UE 在站内小区间切换时，前台测试信令都是正常的未出现异常
2、站间小区切换完成后， UE 在上报 RRC 重配完成信令后，收到基站侧下发的“ RRC CONNECTION RELEASE ”信令，随后 UE 发起接入过程，尝试多个站间切换，该问题始终存在。
但经现场测试人员确定切换过程中 RSRP 良好，无干扰存在。
从以上情况可以得出无线侧是没有问题的，初步怀疑是核心网之间是否存在问题。
如下图：
后台信令跟踪：
1 、通过后台信令跟踪发现 UE 上发切换完成信令“ RRC Connection Reconfiguration
Complete ”后，核心网直接下发“ RRC CONNECTION RELEASE ”给 UE ，导致 UE 重新建立 RRC 连接；
前后台的信令对比分析得出，由于核心网下发了 RRC 拆链的信令，导致切换不成功，故问题可以暂定为核心网存在问题。
后通过与核心网人员确认，核心网将鉴权功能关闭，导致在站间切换时， UE 鉴权被拒，从而导致切换完成后直接 RRC 释放。
后核心网打开鉴权，该切换问题解决。
建议与总结：
核心网将鉴权功能关闭，导致在站间切换时， UE 鉴权被拒，从而导致切换完成后直接 RRC 释放。
后核心网打开鉴权，该切换问题解决。
LTE切换失败简析
LTE切换失败简析LTE切换失败简析坏⼩区定义现在给移动的⽇报中对于切换坏⼩区的定义为切换成功率<90%,切换失败次数>15该指标定义是ENB间的⼩区之间通过X2接⼝进⾏切换的成功率。
切换成功率是系统移动性管理性能的重要指标，并可⽤于分析相邻关系定义是否合理。
此KPI⼀般⼤于95%，处于⽐较良好的⽔平切换过程整个切换过程包括切换测量，切换准备与切换执⾏三个阶段：测量阶段，UE根据下发的测量配置消息进⾏相关测量，并将测量上报给准备阶段：根据UE上报的测量结果进⾏评估，准备切换资源，最终决定是否触发切换。
执⾏阶段：eNode根据切换准备结果，控制UE切换到⽬标⼩区，由UE完成切换。
因此切换成功率指标的分析需分别对切换测量，切换准备与切换执⾏来进⾏分析。
切换指标enb内切换成功率公式：VS_HO_Irc_eNB_succ_src/VS_HO_Irc_eNB_req_srcenb间X2切换成功率公式：VS_HO_IrC_X2_succ_prep_src/ VS_HO_IrC_X2_req_src ----enb间X2切出准备成功率VS_HO_IrC_X2_succ_src/ VS_HO_IrC_X2_succ_prep_src----enb间X2切出执⾏成功率VS_HO_IrC_X2_succ_src/ VS_HO_IrC_X2_req_src------------enb间X2切出成功率enb间S1切换成功率公式：VS_HO_IrC_S1_succ_prep_src / VS_HO_IrC_S1_req_src ----enb间S1切出准备成功率VS_HO_IrC_S1_succ_src/ VS_HO_IrC_S1_succ_prep_src----enb间S1切出执⾏成功率VS_HO_IrC_S1_succ_src/ VS_HO_IrC_S1_req_src------------enb间S1切出成功率Indicator与信令的对应对于源⼩区X2切换来说源⼩区发出Handover request---------VS_HO_IrC_X2_req_src源⼩区收到Handover request ACK---VS_HO_IrC_X2_succ_prep_src源⼩区收到ue context release---------VS_HO_IrC_X2_succ_src对于⽬标⼩区X2切换来说⽬标⼩区收到Handover request---------VS_HO_IrC_X2_req_tgt⽬标⼩区发出Handover request ACK---VS_HO_IrC_X2_succ_prep_tgt⽬标⼩区发出ue conte x t release---------VS_HO_IrC_X2_succ_tgtX2切换信令&counter点切换分析GSM中有180报告，通过这个报告可以清楚看到⼩区切出切⼊⼩区，切出切⼊请求次数，切出切⼊成功率；对于切换坏⼩区，可以很⽅便的找出对应切⼊或者切出问题⼩区。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
X2IPPATH配置问题导致切换不成功
关键字：X2IPPATH 切换
【现象描述】
切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】
对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：
（1）传输资源不够用；
（2）没有配置IPPATH；
（3）IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】
每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令
（RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下：
LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP
Link No。
DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId，查看X2口两端的IP配置是否正确。
经过以上步骤的核查，发现目标基站B2虽然配置了与源基站B1间的X2接口（从DSP X2INTERFACE命令的显示结果可以看到已配置），但是没有配置相应的IPPATH（通过LST IPPATH命令看不到X2口对应的IPPATH）。
导致站点B1向B2发送X2口切换请求（HANDOVER_REQUEST）后，收到基站B2发回的X2切换准备失败消息（HANDOVER_PREPARATION_FAILURE），导致切换不成功。
用ADD IPPATH命令配置了站点B2到站点B1的IPPATH后（源站点也要有X2口的配置以及从B1到B2的IPPATH），可以进行正常的X2口站间切换。
【告警信息】无
【建议总结】
在网络负荷不大的情况下，X2口切换准备失败的原因通常与IPPATH配置有关，所以在配置IPPATH时一定要仔细认真，源站与目标站双向配置，预防漏配错配的问题，提高切换成功率。
切换过晚导致切换失败
关键字：切换小区偏置信道质量陡降
【现象描述】
在切换流程进行中，目标小区信号质量出现抖动，信道质量陡降导致切换失败。
在L3信令的表现为：源小区eNB收到多条测量报告，并且下发切换命令。
而UE未收到切换命令，并且仍然周期上发测量报告，直到发起重建，切换失败。
【原因分析】
1、从最后一个测量报告内容看，服务小区无线质量比邻区差6dB，根据现象看可能是邻区漏配。
但是从网络侧操作维护台查询服务小区邻区信息，查找到有邻区配置。
如下图：
且源小区下发测量报告，因此不会是邻区漏配
2、再分析切换信令流程：根据网络配置，切换应该按下面流程交互：
Meas_RPRT
Handover_Request
Handover_Request ACK
RRC_CONN_RECFG
(HO_CMD)SN_STATUS_TRANSFER
UE S_eNB T_eNB Core Network
S1AP_PATH_SWITCH_REQ
S1AP_PATH_SWITCH_REQ_ACK
RRC_CONN_RECFG_CMP
(HO_CMP)
UE_CONTEXT_RELEASE
RRC_CONN_RECFG
RRC_CONN_RECFG_CMP
UU_interface X2_interface S1_interface 查看网络侧跟踪的信令，在服务小区Uu跟踪可以看到，收到了UE的测量报告，再查看X2口，源小区向目标小区发送了切换请求，并且收到目标小区的切换请求回应，最后在UU口下发了切换命令，
eNB下发切换命令，但UE侧未收到切换命令，由此可以判断可能是空口出现传输质量问题。
3、再看空口无线质量，查看对应时间的RSRP值，发现在切换时间点附近服务小区的RSRP值出现
陡降现象如下图：
从上图看，邻区比服务小区RSRP高1dB的情况维持了近两秒钟，但满足切换门限时服务小区突然变差，导致切换失败，如果切换时机可以提前，应该可以完成切换信令交互，这种现象应该属于切换过晚。
【处理过程】
根据前文分析，这次切换失败的原因在于切换过晚，因此可以通过修改切换门限或延迟触发时间来提前切换。
从上面记录的无线质量变化情况看，如果把切换门限设置为1dB（延迟触发时间默认为320毫秒），基本可以保证在服务小区RSRP突降之前完成切换交互。
可以选择两个方法：
1、把切换门限设置为1dB可以达到目的，但可能影响当前服务小区的所有邻区切换。
2、为了减小影响面，可以修改服务小区到当前切换目标小区之间的小区偏置CIO来解决，从eNB
操作维护台执行：MOD EUTRANINTRAFREQNCELL命令，修改服务小区与切换目标小区间的CellIndividualOffset = 1dB，表示把切换门限减小1dB。
【告警信息】无
【建议总结】
合理规划小区偏置是网规网优的重要工作，对提高覆盖意义重大。
外部邻区配置错误引起下发重配置PCI错误导致切换失败问题
关键字：外部邻区PCI错误切换失败
【现象描述】
UE在Servering CELL PCI为10的小区上，上报PCI为13(或者12)的测量报告，但是eNB下发的RRC重配消息是PCI为12(或者13)的相关信道等配置信息，引起切换失败，业务中断。
【原因分析】
A国S市的LTE Trail项目中，进行全网SIMO优化时发现，上报的测量报告的PCI和eNodeB下发给UE 的RRC重配消息中的PCI不匹配，从而UE未收到重配置完成消息，引起切换失败掉话，业务中断。
具体现象如下：
UE从Servering CELL PCI为10的小区往PCI为13或12的小区切换时，切换失败，查看L3信令，发现UE上报PCI为13(或者12)的测量报告，但是eNB下发的RRC重配消息是PCI为12(或者13)的相关信道等配置信息，造成切换失败，UE发起重建到目标小区。
如下图1：
UE上报PCI为13的测量报告，见下图2
eNB下发PCI为12的重配置消息，见下图3
第二次出现：见下图4
UE上报PCI为12的测量报告：见下图5
eNB下发PCI为13的重配置消息，见下图6
切换失败，UE重建连接。
见下图7
【处理过程】
1、因为相邻关系和测量报告的小区对不起来，初步怀疑是ANR开关问题，因为前期并未打开ANR
开关且没有出现此问题，于是运行MOD ENODEBALGOSWITCH将全网的ANR开关关闭，发现问题依然存在。
2、分析全网的切换关系，发现只要当服务小区（源小区）为PCI=10时，测量上报PCI=12/13就会
出现问题，只要服务小区（源小区）不是10，就没有问题。
3、重点检查小区PCI=10的环境配置，
LST CELL
LST EUTRANEXTERNALCELL
LST EUTRANINTRAFREQNCELL
LST ENODEBALGOSWITCH:;
LST HOMEASCOMM:;
LST INTRARATHO:;
LST INTRARATHOQCI: QCIBEARERINDEX=9;
LST EUTRANEXTERNALCELL中的结果核查发现，在配置PCI为10的外部邻区关系时把PCI为12和13的对应扇区号恰好弄反，导致UE上报了测量报告后，EnodeB下发给UE的PCI错误，不能收到UE 给EnodeB的重配置完成信令，从而发起目标小区或者源小区重建请求，遭到重建拒绝，切换失败，业务中断。
如下图8
使用MOD EUTRANEXTERNALCELL命令修改目标小区的扇区和PCI的对应关系，问题解决。
【告警信息】无
【建议总结】
配置邻区和修改邻区关系时一定要注意对应关系
ANR功能早已经融入EnodeB版本，确实前期引起过X2口切换失败问题，也有可能引起切换上报PCI错误或其他问题，但是关闭ANR开关后依然出现此问题，可以根据分析和比较正常信令流程，顺藤摸瓜从而判断问题真正所在而将其解决。