LTE切换失败问题分析案例

合集下载

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的S1口IP配置错误导致切换全失败

LTE的S1口IP配置错误导致切换全失败现象描述：RIY322站点大量异常释放Cluster测试中发现在RIY322站点周围，所有站间切入和切出的切换都会失败，当UE占用RIY322周围站点如RIY274C小区信号时，当满足A3事件触发条件时不断的上发测量报告想触发切换，但是一直未收到切换命令，过了一段时间就会触发异常释放。

告警信息：无原因分析：无处理过程：1. 查询RIY322以及周围站点的告警，都无任何告警2. 由于路测数据里面的现象为不断的上报测量报告但是一直未触发切换，初步怀疑为缺失邻区关系导致，检查现网邻区关系发现已经添加了RIY322与周围站点的双向邻区关系3. 检查RIY322以及周围站点的外部描述数据里面的PCI、ENODEB ID、TAC等信息，都与实际配置数据一致且与规划数据完全一致，未发现错误4. 到现场路测并同时跟踪了RIY322站点的Uu、X2、S1口以及周围站点RIY274、RIY258站点的S1信令，现场确认每当切入RIY322或者从RIY322切出的时候都会导致异常释放，但是在RIY322站点下能正常附着成功5. 查看路测数据在15:15:03左右发起了切向RIY258C（PCI=170）的切换，在15:15:45左右发起了从RIY258C（PCI=170）切向RIY322B（PCI=196）的切换请求测量报告RIY258切入切出空口路测数据6. 查看RIY258站点的S1口信令在15:16:41时刻收到了切入的切换请求有完整的切换信令流程成功完成切入RIY258的切换，同时在15:17:21时刻发起了切向RIY322站点的切换请求，但是一直反馈切换失败信息RIY258切入切出S1口信令7. 核对路测数据与S1口信令数据的时间差，差不多为1分37秒左右的时间差8. 由于RIY258站点配置了RIY322站点的X2链路，所以从RIY258切入的时候走的都是X2口切换，从RIY322站点的X2口信令可以看出，不断的有切换请求发过来，但是反馈的切换失败消息为：unknown-MME-Code，始终不能完成切换，发送多次以后就导致了异常释放RIY322的X2口信令9、RIY322站点未配置切出的X2链路，所以切出时都是走的S1切换，查看S1口信令发现在RIY322发出了切换请求以后，从MME发回的失败原因为:unknown-targetID，最终切换失败导致异常释放RIY322的S1口信令10. 从上面的分析可以把切换失败的原因与基站配置的MME的相关数据有关系，从现网导出DBS文件转换为MML脚本后，和现网的正常切换基站作了脚本对比发现，RIY322站点配置的MME的IP地址为10.127.218网段，而RIY258配置的MME的IP地址为10.127.72网段，10.127.218网段为达曼区域的MME的网段，10.127.72为利雅得区域的MME的网段，但是MME与MME之间还未做相关的对接配置，导致跨MME的切换都会失败RIY322与RIY258站点脚本对比建议与总结：修改RIY322站点的MME的IP地址为10.127.72网段。

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同频切换失败优化

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上报功能。

切换优化常见问题及案例(中兴)

1 切换优化常见问题及案例1.1 漏配邻区漏配邻区一般可通过无线参数表结合测试数据检查，或者可以在后台直接通过信令跟踪确认收到测量报告后源小区是否向目标小区发生切换请求来确认，但某些场景下我们不易取得无线参数表，且无法进行后台信令跟踪，那么我们可以通过前台信令来分析的到：LTE网络在协议中是一个自优化的网络，终端上报测量报告中会按照a3事件判断原则进行上报，上报的小区不受测量控制中邻区影响，所以只需要将切换异常点的测量报告和当前服务小区的测量控制中的邻区进行对比就可得出是否为漏配邻区1.1.1 前台分析漏配邻区的现象1.1.1.1 多次测量报告正常的流程终端在发送测量报告后基站会很快发送切换命令，但如果有漏配邻区，源小区就无法得知目标小区的基站信息，无法正常完成切换流程介绍中的（见图1-1）中的第三步，故无法发送切换命令消息，此时由于终端仍在行进中，源小区信号越来越差，满足a3事件小区逐渐增加，触发新的测量报告，直到有邻接关系的小区出现，基站才能正常发送切换命令下边选取一个典型问题分析：在某次路测中发现如图4-1情况，前三次测量报告目标PCI都是28（前三次类似图4-2，PCI相同，RSRP测量值略有差异），第四次测量报告（见图4-3）中有PCI28、19两个小区，从测量值上看，28比19高3个dB，接着收到了切换命令，切换命令（见图4-4）中的目标小区不是最高的28而是19。

此时即可初步怀疑28为漏配邻区，图41多次测量报告现象图42第一个测量报告内容图43第四次测量报告内容图44切换命令1：目标小区PCI图45源小区测量控制信息1：邻区列表中带有PCI19小区1.1.1.2 测量报告发送后无响应4.2.1.1介绍了漏配邻区导致的多次测量报告，直到某一次测量报告中上报的目标小区是源小区的邻区则才会收到切换命令，但如果上报的测量报告基站还未响应就失步则会发起重建流程，终端上报掉话事件这种情况的分析方法基本和4.1.1.1一致下边选取一个典型例子：某次路测中发现终端在发送测量报告后未收到切换命令，导致无线链路失败发起了重建过程（如图4-6），首先检查测量报告内容（图4-7，两个测量报告PCI都为30），目标小区PCI为30，检查源小区测量控制（图4-8），发现的确未配置邻区。

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。

TD-LTE切换案例分析

显示eNB在收到测量报告后，判断目标小区为 RetryPenalty Cell。查看IFTS跟踪文件并没有发现RetryPenalty Cell，而且该小区之前
并没有出现非资源准入失败（流程失败），所以排除切换惩罚的原
因。

经核心网确认并没有将服务小区和目的小区配臵进切换限制列表。
目标小区禁止切换开关在同频邻区关系中配臵和显示的，需要进行
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page30
而睡眠小区一般表现为eNodeB的L3收不到UE的RRC建立请求消息。也出问题在图7红色标注部分与此问题站点的现象非常一致。没有告警，没有操作日志，DSP小区状态也正常，没有用户接入和流量，但是有随机接入过程。
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page12
【建议与总结】

切换的问题先从信令入手，再分析信令流程失败点所有可能的原因，采用逐一排除、逐一确认的方法来找问题原因。
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page17
异频测量控制下发
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page18
UE上报异频测量结果：
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.

经典案例_异系统切换失败导致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掉话。

基于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切换失败的原因及优化方法目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (6)LTE切换失败的原因及优化方法【摘要】当正在使用网络服务的用户从一个小区移动到另一个小区，或由于无线传输业务负荷量调整、激活操作维护、设备故障等原因，为了保证通信的连续性和服务的质量，系统要将该用户与原小区的通信链路转移到新的小区上，这个过程就是切换。

【关键字】连续性、服务的质量、通信链路【业务类别】优化方法一、问题描述亳州地市处理DT工单时，发现尾号为290309工单中测试车辆在亳州市涡阳县西环路与站前路交口东附近由东向西行驶中，占用XY-BZ-涡阳-天筑七彩城小区-HFTA-439340-5、XY-BZ-涡阳-涡阳紫金御景-HFTA-439340-1小区（2.1）无法切换到道路上的1.8G小区从而产生覆盖方向异常工单。

二、分析过程首先按照LTE切换种类、切换流程及切换异常问题等三方面进行分析：1、LTE切换种类站内切换、X2切换和S1切换2、切换流程分为测量控制、测量报告、切换命令、目标小区接入等过程A、测量控制测量控制信息是通过重配置消息（RRC Connect Reconfigration）下发的，测量控制一般存在于初始接入时重配置消息和切换命令的重配置消息中。

测量控制信息包括邻区列表、事件判断门限、时延、上报间隔等信息。

B、测量报告终端在服务小区下发的测量控制进行测量，将满足上报条件的小区上报给服务小区。

测量报告中会包括当前小区和测量到的邻小区信息。

C、切换命令这里的切换命令是指带有mobilityControlInfo的重配置命令，mobilityControlInfo包含了目标小区的PCI、T304等其他接入的所有配置。

D、目标小区接入终端在目标小区使用源小区在切换命令中带的接入配置进行接入，终端反馈重配置完成，标志切换结束。

但实际上重配置完成消息在收到切换命令后就已经组包完成并发送，在目标侧的随机接入可认为是由重配置完成消息发起得目标侧随机接入过程。

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。

LTE切换失败问题分析案例

由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。

所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和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配置是否正确。

VOLTE案例

立专载请求的RRC 重配消息里QCI=1的RLC设置AM模式 2、建立完专载后，主被叫都发生了从PCI226到同站PCI 227的切换，在切换请求对应的RRC重配消息里都对专载QCI 1进行释放 3、查看PCI 227的VoLTE参数配置，QCI 1的RLC 是UM模式 4、由于两小区QCI=1的RLC 模式设置不同，导致的QCI 1语音切换失败，专载丢失，以至于主叫没有收到被叫的invite 200，就上发 Cancel，呼叫建立失败问题解决：根据协议要求，QCI1的传输模式为UM。对全网VoLTE参数进行核查，确保所有小区的QCI1传输模式为UM。
3
大话务场景下频繁发生未接通
广东公司9月份案例
问题描述：大话务场景下，出现较多的未接通事件。通过分析Log发现，主叫向网络侧发了invite请求，但没有收到网络侧下发的100 trying消息，之后终端直接上报 CANCEL，导致未接通。问题分析： 1、主叫起呼后发起RRC连接请求，但是RRC连接失败，层3信令显示RRC被拒。之后一直发RRC连接请求，RRC连接依然被拒。最后RRC连接释放掉了，释放原因other。 2、由于话务量高，RRC接入成功率只有51.577%，判断是基站侧的问题影响RRC接入。
问题解决：通过指令“MOD CELLUEMEASCONTROLCFG”，将小区异频异系统测量对象最大值将修改为12后，基站除下发LTE异频和TDS异系统测量频点外，还可下发2G频点，成功实现eSRVCC。
6
典型案例介绍（3）
TAU与QCI1建立冲突导致未接通
北京公司10月份案例
问题现象：主叫发生X2切换，收到携带QCI1建立消息的RRC重配置消息后，没有立即回激活QCI1 的上行直传消息给MME，而是先发送了TAU消息，导致在eNB和MME侧QCI1承载建立状态不同， MME认为QCI1没有建立成功，导致未接通。问题分析： 1、主叫X2切换成功后，收到QCI1建立消息，并且答复了RRC重建完成。终端首先发送TAU Request的上行直传消息，显示有3个EPS承载，随后再发送包含QCI1承载建立完成的上行直传消息。 2、eNB收到RRC连接重配置完成消息，并且发送 ERAB Response消息给MME，终端和eNB都认为 QCI1承载已经建立。 3、MME没有收到终端发的激活QCI1承载接收的上行直传消息，认为QCI1没有建立成功，回复的TAU Accept中只包含2个EPS承载。 4、 TAU成功后，MME收到UE发送的QCI1激活消息，在create bearer response里回复成功。由于 eNB已经存在QCI1承载，答复失败，原因： Multiple-E-RAB-ID-instances，产生未接通。问题解决：需要在规范中明确，UE发送QCI1建立的RRC重配置消息后，先发送激活QCI1的上行直传消息给MME，再发送TAU request 。

基于S1接口切换失败分析

基于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案例分析

一定要像爱护自己的眼睛一样爱护我们的网络
5
案例6：切换类
• 故障现象：邻区漏配从基站跟踪看到基站收到了大量的MR，没有下发切换命令，导致掉话，如下图。从probe上看信道质量不差没到解调门限以下，因为没有下发切换命令而掉话，可以查看是否为邻区漏配。基站179向科技园四182发起切换，上报了切换的MR，基站侧也收到了MR，没有下发切换命令，之后读系统消息，发起重建，重新接入到MR中小区，即科技园四182，可以确认为邻区漏配。Probe和基站侧log如下：
• 解决方案：
• 让测试人员在页面修改为ctlte建立连接，这样，就和附着时的默认承载一致，单PDN 链接，终端重启后，可以接入LTE上网。定论为测试人员所在的基站（爱立信TDD基站）不支持多PDN连接导致。
• 后期建议：
• 为了避免用户在网络连接时，输入的APN与终端底层送的、或用户签约的默认APN不一致，附着成功后，发起第二个PDN连接时无线拒绝，导致无法上网。建议需要进一步梳理无线基站的多PDN连接功能。
邻区漏配有2种情况: 1、同频邻区和外部小区都没有配置; 2、配置了外部邻区,但没配置同频邻区；建议：添加邻区
一定要像爱护自己的眼睛一样爱护我们的网络
6
图表邻区漏配基站侧log
谢谢！
一定要像爱护自己的眼睛一样爱护我们的网络
7
优化建议：
增大A2事件切换门限，将A2门限设置高于终端在掉话前显示的RSRP值，这样终端在掉话前即可触发激活态切换
一定要像爱护自己的眼睛一样爱护我们的网络
3
案例4：MOD3干扰类
• 故障现象
✓ 科技园E，58小区上报了114的MR，181和服务小区58模3相等，下发了切换命令，UE没收到，由 UE侧可看到此时SINR很差为-6.83;

移动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消息，随后呼叫中止，出现未接通事件。

切换优化常见问题及案例(中兴)

1 切换优化常见问题及案例1.1 漏配邻区漏配邻区一般可通过无线参数表结合测试数据检查，或者可以在后台直接通过信令跟踪确认收到测量报告后源小区是否向目标小区发生切换请求来确认，但某些场景下我们不易取得无线参数表，且无法进行后台信令跟踪，那么我们可以通过前台信令来分析的到：LTE网络在协议中是一个自优化的网络，终端上报测量报告中会按照a3事件判断原则进行上报，上报的小区不受测量控制中邻区影响，所以只需要将切换异常点的测量报告和当前服务小区的测量控制中的邻区进行对比就可得出是否为漏配邻区1.1.1 前台分析漏配邻区的现象1.1.1.1多次测量报告正常的流程终端在发送测量报告后基站会很快发送切换命令，但如果有漏配邻区，源小区就无法得知目标小区的基站信息，无法正常完成切换流程介绍中的（见图1-1）中的第三步，故无法发送切换命令消息，此时由于终端仍在行进中，源小区信号越来越差，满足a3事件小区逐渐增加，触发新的测量报告，直到有邻接关系的小区出现，基站才能正常发送切换命令下边选取一个典型问题分析：在某次路测中发现如图4-1情况，前三次测量报告目标PCI都是28（前三次类似图4-2，PCI相同，RSRP测量值略有差异），第四次测量报告（见图4-3）中有PCI28、19两个小区，从测量值上看，28比19高3个dB，接着收到了切换命令，切换命令（见图4-4）中的目标小区不是最高的28而是19。

此时即可初步怀疑28为漏配邻区，图1-1多次测量报告现象图1-2第一个测量报告内容图1-3第四次测量报告内容图1-4切换命令1：目标小区PCI图1-5源小区测量控制信息1：邻区列表中带有PCI19小区1.1.1.2测量报告发送后无响应4.2.1.1介绍了漏配邻区导致的多次测量报告，直到某一次测量报告中上报的目标小区是源小区的邻区则才会收到切换命令，但如果上报的测量报告基站还未响应就失步则会发起重建流程，终端上报掉话事件这种情况的分析方法基本和4.1.1.1一致下边选取一个典型例子：某次路测中发现终端在发送测量报告后未收到切换命令，导致无线链路失败发起了重建过程（如图4-6），首先检查测量报告内容（图4-7，两个测量报告PCI都为30），目标小区PCI为30，检查源小区测量控制（图4-8），发现的确未配置邻区。

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报告，通过这个报告可以清楚看到⼩区切出切⼊⼩区，切出切⼊请求次数，切出切⼊成功率；对于切换坏⼩区，可以很⽅便的找出对应切⼊或者切出问题⼩区。