LTE切换失败问答题分析案例分析
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-2小区X2切换失败处理案例
名称：通达国际LTE-2小区X2切换失败处理案例
提交人：岳明提交日期：2017-6-19
软件版本：EMB5116_TD-L V6.00.10.50.35.12 硬件版本：EMB5116_TD-L V6.00.10.50.35.12
【问题描述】：在日常X2切换质差问题小区处理中，发现通达国际LTE-2小区连续几天指标较差，切换失败次数每天在8000次以上，如下所示：
其切换对如下：
【问题分析】：提取CDL统计失败原因主要为：切换出失败UE在源侧发起重建立和核心网原因导致切换出失败，如下图所示：
源小区向目标小区切换走高优先级的A4切换，A1/A2/A4等参数无异常。
一般切换重建立回源侧的原因主要有目标小区覆盖不好或目标小区电平陡降，核心网原因导致切换出失败的可能原因为PCI复用度过高。
从CDL切换统计中看出在切换前源小区和目标小区电平均良好，核查同频同PCI情况发现附近新开小区陇商国际3（室分）LTE-1小区和目标小区经五路纬三路十字LTE-5均为D频点PCI是388，如下图所示：
失败过程流程图如下：
故需修改经五路纬三路十字LTE-5小区的PCI 后观察。
【优化建议】：将目标小区经五路纬三路十字LTE-5的PCI 由388修改为268。
【优化效果】：修改PCI 后，通达国际LTE-2小区切换失败次数明显减少，指标如下：
【备注】：附件或日志：
时间 ENBID 小区名 eNB 间X2
切换成功
率 eNB 间X2切
换出请求次数(HO.AttOut
eNB 间X2切换出成功次数(HO.SuccOutI X2。
LTE切换为题处理案例及切换参数总结
切换问题处理及切换参数总结目录：简述： (1)一、案例分析： (1)1.1. 问题描述： (1)1.2. 优化： (3)二：切换参数总结： (3)1.1.UE测量配置基本信道参数表 (4)1.2.A3事件上报参数表 (4)1.3.切换算法参数表 (5)1.4.UE定时器及常量分析 (6)1.5.ENB协议定时器分析 (8)1.6.ENB实现定时器分析 (9)A1~A5，B1~B2事件总结： (10)简述：地铁部分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在切换之前上报服务小区和邻小区的信道质量，便于网络侧合理地判决切换。
经典案例-关于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就不会生成切换命令，导致切换失败。
VOLTE异常事件典型案例分析
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。
此处属于测试软件问题，应该予以剔除。
（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。
2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。
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。
移动LTEVOLTE案例分析汇总
移动L T E V O L T E案例分析汇总Pleasure Group Office【T985AB-B866SYT-B182C-BS682T-STT18】广东移动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，主叫收到网络侧转发的INVITE 580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于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消息，随后呼叫中止，出现未接通事件。
切换优化常见问题及案例(中兴)剖析
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切换问题定位指导一（切换问题分析）目录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优化案例手册-第五章-切换问题
第五章切换问题概述及总结（陈洲）LTE技术中小区间的切换不再像在GSM和3G时代，切换不是在用户的专用信道中发生，而是使用PRACH过程来切换，这就使得切换问题分成了两大类，一是切换请求没触发，二是触发后切换失败。
5.1总结了切换不触发的原因和案例，5.2提出了切换失败的分析和案例，5.3提供了切换问题的其他案例5.1 切换不触发（陈洲）在LTE中，手机不再需要从系统消息中得到邻区的信息，而是完全由手机本身不断检测邻区码。
切换请求没触发是指手机在运动过程中检测到新小区的信号，然后向基站发送measurement report要求切换，但由于基站没有相邻基站的IP地址而不知道切换请求应该发往何处，导致手机保持在现服务小区直到干扰太大而掉话。
切换不触发原因包括：1.在源基站中没有建立邻站的数据。
对每一个邻站要创建一个LNADJ,指明邻站的ENB ID 和IP地址。
通常情况下，要登陆基站手工创建每一个LNADJ.在工具的章节中，我们开发了通过OSS一次为多个基站通过脚本的方式批量创建邻站LNADJ,详见工具章节。
2.在源基站中存在重复的LNADJ每一个邻站只允许建一个LNADJ,但有时会发现在源基站中建了两个LNADJ,一个是CONNECTED 连接方式是OAMCONTROLLED,一个DISCONNECT,连接方式是ENB CONTROLLED, 重复的LNADJ导致切换不触发。
3.邻站的LNADJ数据已经存在，但链路状态是DISCONNECTED.是由于邻站IP地址定义错误，或者源基站和邻站链路连接方式均为ENB CONTROLLED.LTE 基站和邻站是通过SCTP协议连接，连接的两端，一端为SERVER端，一端为CLIENT.在创建LNADJ时，定义为OAM CONTROLLED,表明是SCTP协议的CLIENT,可以主动发起到邻站的SCTP连接，在对端基站收到连接请求后为自己建立一个ENB CONTROLLED LNADJ.如果两端均为ENB CONTROLLED,链路就没办法建立起来。
LTE切换失败问答题分析案例分析
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案例分析
一定要像爱护自己的眼睛一样爱护我们的网络
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;
LTE案例-切换失败问地的题目案例
案例：切换失败问题案例
【问题描述】测试过程中UE占用圳埔新村FE3（PCI=363）小区，车辆在圳埔村宝荷路大门出口行驶时切换失败；
掉话前截图
掉话处截图
【问题分析】从终端侧LOG如上图测量报告前后对比，主用小区圳埔新村FE3上报圳埔新村FE1，系统侧下发重配置消息，终端未对RRC重配置解析，后台侧方面看出终端对核心侧发起了RRC连接重建请求，从测试数据上看,怀疑是流程欠套.测试终端问题，建议复测；
前台测量截图
系统侧截图
【解决方法】1．怀疑为测试终端故障，建议复测。
【优化结果】通过对该位置复测，复测结果未出现任何异常事件；
复测截图
复测截图。
移动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全网切换成功率进行TOP小区处理及分析，发现竹园D3切换成功率一直很低。
见下表：ENB内同频、异频切换正常，ENB间同频切换正常，但ENB间异頻切换率在29%~59%之间，其中按接口类型统计S1口的切换全部失败。
二、切换分析流程三、问题处理过程1）查询小区告警信息，未发现存在影响性能的告警。
2）查询小区相应时间段内的干扰情况，未发现不存在强干扰问题。
3）查询两两小区间的切换对，查看是否由个别邻区的关系影响了小区的切换成功率：查询两两小区间切换对时，发现该基站竹园D2和竹园D3切出到卢屋广场F 基站的三个小区都是全部失败，其他切换对是正常的。
因此问题定位到邻区级和目标基站级。
4）通过跟踪本小区与目标小区的S1口信令，HANDOVER REQUEST及HANDOVERPREPARATON FAIL两条关键信令信息。
其中查询S1AP_HANDOVER_REQUEST的信令解码查询目标小区ENB的消息：关键数据：目标NB-ID为0001,0000,1111,0001,0001B，应对的十六进制为10F11，即十进制为：69393。
5）查看S1AP_HANDOVER_PREPARATON_FAIL的信令解码，查看其失败原因：解码的失败原因为：HO-failure-in-target-EPC-ENB-or-target-system（失败原因为目标EPC或者目标ENB问题）。
根据S1AP_HANDOVER_PREPARATON_FAIL目标小区无法完成切换准备而导致切换失败。
6）查询源小区定义的外部邻区，其中卢屋广场F基站标识为69393共5位的基站NBID，现网配置基站标识的时候一般是6位数，怀疑是基站标识配置错误导致切换失败。
7）查询目标小区的基站标识信息：发现目标小区的基站标识为693937，与竹园D基站定义的源小区的69393不同有错误。
四、优化效果9月10日下午修改源小区错误的邻小区参数，从69393改为693937。
MME互连链路不通导致LTE站点切换失败
MME互连链路不通导致LTE站点切换失败1问题描述X局点新建大量LTE站点，经过前期优化调整，同频切换成功率有明显提升(由94.46%提升至97.81%)，如图1所示。
但仍与验收指标有差距，要进行进一步分析调整。
图1 X局点LTE站点同频切换成功率2问题分析关于切换成功率低的问题首先判断是全网性现象的还是由TOP小区指标差造成的，如果是全网性的，检查近期是否有大面积修改参数，或者核心网是否有割接调整。
在本案例中，LTE站点均为新建，而指标随着前期优化调整已有提升，因此首先考虑TOP小区问题。
根据此思路，对TOP小区分析后可知，大量边界站点同频切换成功率低，如图2所示。
图2 同频切换成功率TOP小区问题分析要寻找共性，首先将站点导入地图中查看，切换成功率低的站点均位于省际边界；其次，提取切换指标成功率，发现切换失败多为切出失败。
如图3所示。
(a)站点分布；(b)切换成功率指标图3 切换成功率低站点分布及切换成功率指标如图4 S1信令，S1AP_HANDOVER_PREPARATION_FAIL的原因是Unknown Target ID。
以下为具体信令消息：HandoverType=intralte;cause=handover-desirable-for-radio-reason,handover-desirable-for-radio-reason; tarENBID=A1 C9 A0 ; tAc=41385; TargetCellid=A1 C9 A1 20; SourceCellid=97 D4 B1 80; sourceUE-Identity=EE BE，切换源小区为A，为X局点基站，目标小区为B，为邻省基站，即该切换问题为向邻省基站切出失败。
(a)S1信令；(b)源小区与目标小区位置图4 S1信令跟踪及两两切换成功率低站点位置而Uu消息中可以看到(如图5所示)，手机上报的MR中测量邻区信号强度满足切换门限(4dB)。
04-14.2LTE切换问题案例分析教案
切换案例1 邻区漏配问题的案例分析为了保证在各种复杂的地形环境下，用户在移动的同时能够获得良好的信号质量，保证业务的畅通进行，切换是必不可少的保障。
良好的切换性能直接关系到小区的吞吐量、用户的通话质量和数据传输速率，因此，对切换问题进行优化，能提升小区的吞吐量、改善用户的通话质量、提高用户的数据传输速率，从而提升用户对LTE网络的感知。
本次课就来学习一下有关LTE无线网络中邻区漏配问题的典型案例。
一、实训目的1.掌握邻区漏配问题的重要特征。
2.加深对邻区漏配问题优化处理思路的理解。
二、实训步骤及注意要求1.启动Pilot Pioneer在安装好的电脑中，启动Pilot Pioneer后台分析软件。
2.导入数据(1)导入基站数据库启动Pilot Pioneer之后，在主菜单“配置”菜单中选择“基站数据库管理”，在弹出的对话框中，选择基站栏目下的LTE选项，再选择导入按钮，将文件名为“实训9基站工程参数.xls”的文件导入到Pilot Pioneer中来。
(2)打开数据文件在Pilot Pioneer软件主菜单“文件”中选择“导入测试数据”子菜单，再选择“常规”在弹出的对话框中，选择文件的路径，将文件名为“实训9数据.RCU”文件导入到Pilot Pioneer中来。
3.解压和解码数据文件在工程窗口中，选择“工程”选项卡，用鼠标双击导入的数据文件(即“实训7数据”文件)下面的Message选项，软件就会对“实训9数据”进行解压和解码，并自动弹出信令窗口。
4.打开常用的窗口Graph窗口、Line chart窗口、事件窗口、LTE Serving+Neighbor Cell List窗口等常用窗口。
9.2 数据分析1.问题描述UE由南往北行驶至图S9-1所示的椭圆区域时，UE接收到RSRP信号强度急剧下降。
图S9-1 UE的RSRP测试轨迹图2.问题分析通过LTE Serving+Neighbor Cell List窗口查看服务小区和邻区的RSRP发现，在15:07:56.036时刻服务小区的RSRP=-105.56dBm，UE检测到距离359.60m 之外开发区盛华心港湾49（PCI=23）的小区RSRP信号较强，其RSRP=-97.75dBm 如图所示：图S9-3 UE检测到信号较强小区RSRP测试图在随后3s多的时间内，UE多次向eNodeB上报测量报告消息，要求进行A3事件切换，即由开发区茂华国际10号楼50（PCI=142）的小区切换到开发区盛华心港湾49（PCI=23）的小区。
LTE信令分析模拟试题-切换失败案例
题1：
请分析下面路测接入，该期间从信令流程上看主要存在什么问题，该问题主要由什么导致，并给出优化建议。
相关的信令为：
上图中标记的1、2、3信令的解码信息分别如下：1.
2.
3.
参考答案要点：
1.信令流程中的问题是切换失败，从PCI为39的源小区向目标小区40的切换失败，以及
PCI为39的源小区没有配置到PCI为272小区的切换关系。
2.造成切换失败的原因主要是弱覆盖，RSRP已经低于-120dBm，SINR为-5dB，并且邻区信
号电平也都很低。
3.优化建议：1. 增加此处的覆盖，2. 修改邻区参数配置，增加从PCI39到272邻区关系，
提高切换成功率。
LTE案例-TAC配置错误导致无法切换
案例一、TAC配置错误导致无法切换【现象描述】人民南路转深南东路处，国贸HE1无法切换至东方FE3，层三信令里连续上发A3测量报告。
根据LTE同频切换触发判决条件:A3事件进行触发，即邻区质量高于服务小区一定偏置: 参照3GPP 36.331规定的A3事件的判决公式为：触发条件：Mn + Ofn + Ocn – Hys>Ms + Ofs + Ocs + Off；取消条件：Mn + Ofn + Ocn + Hys﹤Ms + Ofs + Ocs + Off；其中：Mn是邻区测量结果；Ofn是邻区的特定频率偏置；Ocn是邻区的特定小区偏置，也即CIO。
该值不为0，此参数在测量控制消息中下发。
eNodeB 将根据小区负载情况临时修改邻区与服务小区的CIO，触发基于负载的同频切换；Ms是服务小区的测量结果；Ofs是服务小区的特定频率偏置；Ocs是服务小区的特定小区偏置；Hys是迟滞参数；Off是A3事件的偏置参数，用于调节切换的难易程度，取正值时增加事件触发的难度，延迟切换；取负值时，降低事件触发的难度，提前进行切换；触发A3事件的测量量可以是RSRP或RSRQ；下图给出了A3事件触发过程中的一个示意图。
根据公式，检查国贸HE1同东方FE3的Ocs（邻区的特定小区偏置，也即CIO），即小区偏移量(分贝)：CellIndividualOffset=dB0再检查公式中服务小区国贸HE1的Off是A3事件的偏置参数，即同频切换偏置(0.5分贝)IntraFreqHoA3Offset=2;最后检查邻区东方HE3的Hys是迟滞参数，即同频切换幅度迟滞(0.5分贝)IntraFreqHoA3Hyst=2,A3事件的判决公式为：触发条件：Mn + Ofn + Ocn – Hys>Ms + Ofs + Ocs + Off；即服务小区国贸HE1 Ms=-87,Ofn=Ofs=0Ocn=Ocs=0Off=2*0.5=1邻小区东方HE3 Mn=-80Ocn=0Hys=2*0.5从上面公式可以算出，只要邻小区较服务小区大2db，则触发A3事件，邻小区东方HE3达到A3的判决门限，正常应该切换。
- 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、再分析切换信令流程：根据网络配置，切换应该按下面流程交互：
查看网络侧跟踪的信令，在服务小区Uu跟踪可以看到，收到了UE的测量报告，再查看X2口，源小区向目标小区发送了切换请求，并且收到目标小区的切换请求回应，最后在UU口下发了切换命令，但没有收到UE的切换完成消息（站间切换）：
UU、X2口信令交互
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开关后依然出现此问题，可以根据分析和比较正常信令流程，顺藤摸瓜从而判断问题真正所在而将其解决。