LTE切换成功率分析-中兴20140818

LTE实战技巧之切换成功率优化1 概述LTE切换成功率是运营商重点考核的三大指标之一，作为后台人员，在处理Top坏小区的时候，不可能每次都要求前台去复测重现、分析信令，因此如何在没有前台测试数据支持下，从各种网管统计数据中交叉分析互相印证、判断低切换成功率的原因并加以解决是KPI分析人员必备的技能之一。

本文从切换的统计点、信令流程、数据分析及常见问题环节几个方面对切换成功率进行全方位的分析。

2 切换流程及统计点我们先来看看切换成功率的计算公式，切换成功率有两个公式：不含切换准备的切换成功率：切换成功率（不含切换准备）=切换成功次数/切换尝试次数*100%含切换准备的切换成功率：切换成功率（含切换准备）=切换成功次数/切换请求次数*100%各地运营商的关注指标视各自的情况有所不同。

按照涉及的网元关系，切换可以分为三大类：eNB内切换、eNB 间X2切换及eNB间S1切换。

其中eNB内切换不涉及邻区配置参数，并且站内切换涉及网元少，一般切换成功率较高；eNB间X2切换次数最多，对全网切换成功率影响最大，S1切换次数较少，并且与X2切换信令流程较类似。

因此我们以X2切换为例进行流程分析，考察切换成功率指标的统计点。

eNB间X2切换的信令流程如下：一个完整的切换流程大致分为以下几个步骤：1、eNB发送测量控制，UE根据当前小区的测量控制信息，将符合切换门限的小区进行上报；2、源小区在收到测量报告后通过X2向目标小区发送HO Request申请资源，切换成功率计算公式中的第一个统计项HO_Req 的信令统计点就在这里（也叫切换准备）；3、目标小区准备好相应资源，并将终端的接纳信息以及其它配置信息反馈给源小区；4、源小区将目标小区的接纳信息及配置信息发给终端，告知终端目标小区已准备好终端接入，重配消息里包含目标小区的测量控制；HO_Attempt在此计数；5、终端使用重配消息里的接入信息接入目标小区，核心侧完成路由切换后，目标小区通知源小区释放资源，切换成功，此时源小区的HO_Success统计在此计数。

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切换问题优化案例1 基站不下发切换命令该问题的前提是UE上报了切换的MR，基站侧也收到了MR，但没有收到切换命令，可能的原因有邻区漏配或邻区配错、下发重配置没收到重配置完成和同频邻区中有PCI相等的邻区。

下面以案例形势一一展开。

1.1 邻区漏配&邻区配错1.1.1邻区漏配从基站跟踪看到基站收到了大量的MR，没有下发切换命令，导致掉话，如下图。

从probe上看信道质量不差没到解调门限以下，因为没有下发切换命令而掉话，可以查看是否为邻区漏配。

中兴通讯179向科技园四182发起切换，上报了切换的MR，基站侧也收到了MR，没有下发切换命令，之后读系统消息，发起重建，重新接入到MR中小区，即科技园四182，可以确认为邻区漏配。

Probe和基站侧log如下：图表1邻区漏配UE侧无线环境图表2邻区漏配UE侧LOG图表3邻区漏配基站侧log邻区漏配有2种情况:1、同频邻区和外部小区都没有配置;2、配置了外部邻区,但没配置同频邻区；建议：添加邻区注：也可通过对比SIB4中的邻区信息与MR中的邻区PCI发现是否为邻区漏配，如下图；图表4SIB4消息内容1.1.2邻区配错下面为外部小区和同频邻区均已配置，且同频邻区也配置正确，但外部小区的PCI添加有错，导致的掉话。

如下图，102（科技园三1小区）上报181（科技园四的1小区）的MR，但没下发切换命令，查询同频邻区已配置eNBID为28即科技园四的1小区为邻区，但1小区的PCI被配成了182，且配置了同站的两个PCI相等的外部邻区。

图表5邻区错配终端侧LOG图表6科技园三1小区的同频邻区图表7科技园三的外部邻区建议：修正外部小区的PCI，在添加邻区时务必保证外部小区的PCI及同频邻区的eNBID正确，减少优化工作量。

1.2 PCI相等导致不发切换命令现象：基站标识117，67（本地小区1）、68（本地小区0）为同站邻区，68往67切换正常，67往68切则切不过去，表现为上报了MR，不发切换命令，LOG如下：图表8PCI相等终端侧LOG图表9PCI相等基站侧LOG经查询67（本地小区标识为1）的外部邻区中有PCI为68和同站邻区的PCI相等，如下，在ANR关闭情况下，会不发切换命令；图表1067小区的外部邻区图表1167小区的同频邻区措施：首先核查是外部邻区中的PCI配置错误（即该站不存在，或基站存在但PCI配置有错）；核查都无误时需要调整PCI；建议：1、调整完PCI后或新加站后用M2000上的PCI冲突核查工具进行核查邻区中是否存在PCI相等情况。

VOLTE切换成功率低专项报告移动公司2015-11-271、VOLTE切换成功率低优化切换优化的目的就是减少切换失败、切换过早或过晚、切错小区和乒乓切换等情况，最终提升系统性能。

1.1切换常见异常场景简介1.1.1过早切换：切换过早，一般是邻区的信号还不够好或不够稳定，eNodeB就发起了切换，主要有以下几种：a)源小区下发切换命令后，由于目标小区信号质量不佳，UE切换到目标小区发生失败，UE发起RRC重建回到源小区。

如下图，这种场景下，UE在切换到新小区随机接入或发送msg3失败导致切换失败，然后UE在源小区发起RRC连接重建。

b)UE虽然成功切换到目标小区但是立即出现下行失步，然后在源小区发起RRC连接重建。

这也是切换过早。

c)UE虽然成功切换到目标小区但在很短时间内（5s）切换到第三方小区，也是切换过早。

1.1.2过晚切换：切换过晚这个在实际外场比较多，主要有以下几种：a)在下行100％加载的场景，源小区服务质量不好（一般SINR低于－3就会概率性出现切换命令发送失败），UE因为服务小区信号不好没有收到切换命令，或收到切换命令，但随机接入过程失败，UE就发生RRC重建，重建到目标小区，此时由于目标小区已建立上下文，重建可以成功。

b)UE还来不及上报测量报告，源小区的信号已经急剧下降导致下行失步，UE直接在目标小区发起RRC连接重建，此时由于目标小区无UE上下文，重建必然被拒绝，信令流程如下图所示。

1.1.3乒乓切换：当UE 进行A—>B—>A 这样的反复来回切换流程，从小区A 切换到小区B 后，在小区B 停留的时间很短，又返回到小区A，这个通过信令流程比较容易分析，就是看上一次切换入到下一次切换出的时间是否太短了（一般认为一秒发生多次切换为乒乓切换）。

1.2 切换优化方法与技巧 1.2.1 切换优化5步法:b) 邻区合理性检查：是否邻区完整、邻区是否合适、是否存在blacklist 邻区、邻区存在同频同PCI 问题、相同邻区重复定义； c) 干扰：内部干扰、外部干扰；d) 覆盖原因：弱覆盖，过覆盖、重叠覆盖；e) 参数设置不合理：TAC 、切换参数（CIO 设置不合理、handoverAllowed 状态核查、异频参数核查：）、MME POOL 核查、ppsTimingOffset 核查； f) 邻区拥塞：指目标小区拥塞导致切出指标差； g) 隐性故障：主小区或者邻区隐性故障；1.2.3切换问题处理流程2. 附录.案例2.1 异频切换问题导致设备异常eSRVCC 到GSM 问题描述：车辆在五四路上由北向南行驶，UE1主叫占用D2频点小区418339-2，在行驶过程中由于车速较快UE1没有及时切换到417870-1、417903-1&2扇区，等到切换条件满足时，但相关小区已和主服小区没有邻区关系了（此时已经是第三圈站点了），从而导致设备异常eSRVCC 到GSM ；2.1.2 解决方法：参数原值 修改值 修改原因threshold2InterFreq -97 -95 使该小区尽量切换至LTE 小区，避免提前开始eSRVCC 切换，影响道路MOS 值。

切换成功率低处理案例LTE吉州区人民广场基站S1口少配导致切换成功率低处理案例一、现象描述在LTE网络KPI指标监控过程中发现吉州区人民广场区域的几个站点切换成功率极低，严重影响全网切换类指标，其中吉州区人民广场切换入失败次数每天达到4600多次，吉州区富华宾馆、吉州区红雨宾馆、吉州区附属医院，切换出失败次数和为4500多次。

二、原因分析1.处理流程图2.分析切换成功率低可能原因：对KPI指标及周边环境分，可发现如下问题：1）吉州区人民广场基站的邻区是否存在漏配、错配，外部邻区参数设置是否正确，PCI规划是否合理，切换参数设置是否有问题。

2）吉州区人民广场基站的切换入失败次数的和约等于周边基站切出失败的和，可定位为吉州区人民广场基站的问题导致其切入成功率低及周边基站切出功率低；三、问题排查1、吉州区人民广场及周边站点邻区核查吉州区人民广场及周边站点同频邻区核查根据基站拓扑结构核查吉州区人民广场及周边站点的邻区，确定现网邻区无漏配的问题，确定吉州区人民广场及周边站点的PCI规划合理。

2、吉州区人民广场及周边站点外部邻区定义核查吉州区人民广场及周边站点外部邻区核查核查吉州区人民广场及周边站点外部邻区的定义，主要核对外部邻区PCI及TAC设置,将外部邻区定义的PCI及TAC与现网比对，确定没问题。

3、同频切换参数检查及现场测试吉安LTE网络刚开局，现网所有切换参数均为默认值，核查无问题。

现场测试，吉州区人民广场与吉州区附属医院切换正常，验证了该站的参数设置没问题，可能有其他不常见的问题导致。

4、后台跟踪查询周边站点切换出失败原因全部为目标小区回复切换准备失败消息导致切换出准备失败后台信令跟踪对吉州区人民广场标准X2口进行跟踪，发现切换准备失败，失败原因值：传输不可用。

四、解决过程及方案查询ENODEB X2接口自建链开关状态，结果显示正常查询基站的DEVIP配置信息是否正确，结果显示正常查询基站IPRT是否正确，结果显示正常查询基站VLANID是否正确，结果显示正常查询基站SCTPLNK是否正确，结果显示配置正常查询基站IPPATH,发现S1接口配置为1条，IPPATH资源有限，所以相邻站点切到该站的成功率很低，通过增加到S1接口的IPPATH 到8条（现网标准为8条）后：修改后观察指标，恢复正常，该问题解决。

同MME内S1接口切换成功率优化指标定义S1接口切换成功率=( eNodeB间同频切换出成功次数+eNodeB间异频切换出成功次-eNodeB间X2接口同频切换出成功次数-eNodeB间X2接口异频切换出成功次数)/( eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数-eNodeB间X2接口同频切换出尝试次数-eNodeB间X2接口异频切换出尝试次数)*100%。

即S1接口成功率=（eNodeB间切换成功次数-X2接口切换成功次数）/( eNodeB间切换尝试次数-X2切换尝试次数)。

指标分析:当eNodeB同时配置了X2和S1接口时，UE优先进行X2接口切换。

X2接口切换相对流程简单，时延也更短。

S1接口切换的触发原因有:➢跨MME切换；➢X2接口故障；➢X2接口未配置；➢X2接口黑名单。

目前工程建设阶段，华为网络eNodeB之间的X2接口由系统通过UE测量报告自动添加，由于网络的不稳定，经常出现一些X2接口故障，故障原因主要有：➢X2接口配置错误。

➢对端基站没有配置X2接口。

➢本端基站在对端基站黑名单中。

➢本端基站S1接口闭塞。

➢对端基站S1接口闭塞。

➢在X2接口建链过程中本端或者对端基站没有状态正常的小区同MME内引起S1接口切换性能变差的主要原因是主要是X2接口配置错误问题，可能流程有两种：1、目标基站X2故障，系统重新开始尝试S1切换，但此时切换计时器T304超时，切换失败；2、目标基站故障，无法进行X2接口切换，尝试进行S1接口切换，由于基站故障也切换失败。

以4月份XX市LTE指标为例，4月13日在对139条故障X2链路进行删除后，LTE 的切换性能指标、呼叫保持类指标都有了明显改善。

切换成功率低处理方法研究周明平【摘要】切换成功率是考核网络性能的一个重要指标，通常全网切换成功率应保持在95%以上。

切换失败主要分为两部分：切换准备失败和切换执行失败。

对于切换准备失败，BSC内的原因主要有目标小区拥塞、硬件问题等。

对于跨MSC的切换，涉及E口信令转换，交换切换数据，编码方式沟通等原因，需要信令跟踪分析定位。

而切换执行失败，原因主要有无线环境、参数设置、小区硬件故障等。

%Success rate of switching is an important index to evaluate the network performance, usually the success rate of whole network handover should be maintained at more than 95%. Switching failure is mainly divided into two parts:switching preparation failure and switching execution failure. To failure for switching preparation, there are two reasons in BSCas the target cell is crowed and the hardware problems, etc. For reasons of switching cross MSC, involving the E port signaling switching, exchange switching and communication of encoding method, it needs signal to track, analyze positioning.As for failure to switching execution, it mainly dues to the wireless environment, parameter setting, small hardware failure and so on.【期刊名称】《无线互联科技》【年(卷),期】2016(000)024【总页数】3页(P20-22)【关键词】切换成功率;GSM问题小区;网络性能【作者】周明平【作者单位】南京欣网通信科技股份有限公司，江苏南京 210019【正文语种】中文1.1 小区故障1.1.1 时钟板硬件故障如果某小区的切入切出成功率均低于70%以下，同时本小区的分配失败正常，掉话率高的话，通常是由于BTS时钟偏移造成，使得手机无法与邻小区同步，造成切换成功率低，甚至引起掉话.这种情况更换SUMP板或者调整时钟即可解决。

LTE网络S1接口切换成功率低分析V1LTE网络S1接口切换成功率低分析【原理说明】S1接口切换成功率=S1接口切换成功次数/ S1接口切换请求次数；S1切换失败原因：目标小区回复切换准备失败消息导致模式内切换出准备失败，目标小区无响应导致模式内切换出准备失败，源小区发送切换取消导致模式内切换出准备失败和核心网原因导致模式内切换出准备失败这些原因导致。

1 问题描述4月26日凌晨，**市核心网增加一条S1链路，在原有三条链路的基础上变成了四条，核心网修改后，对比4月25日与4月26日KPI 指标，发现S1接口切换成功率有小幅下降，之后继续观察，并发现该项指标持续降低。

2 问题定位首先我们先通过后台对全网S1切换失败站点查询，对失败次数按照TOP 10统计，如下表，其中前7个小区S1切换成功率为0 ，核查以上站点，均无告警。

将以上站点制作为Mapinfo 图层，问题站点集中分布区域如下所示，对Top10站点中抽取LF_H_黄岩移动新前牟村和LF_H_黄岩西城岙岸两基站进行两两小区切换，指标按小时提取T op10，切换失败的站点均为LF_H_黄岩移动黄岩中学。

基站名称小区名称本地小区标识LTE 系统内切换成功率-jtS1接口切换成功率-jt(%)S1接口切换请求次数-jt S1接口切换成功次数-jt S1接口切换失败次数-jtLF_H_黄岩移动新前牟村LF_H_黄岩移动新前牟村_50295.34702590259LF_H_黄岩西城岙岸LF_H_黄岩西城岙岸_51394.5502020202LF_H_黄岩新前支局BBU9LF_H_黄岩联通新前七里浮桥_49193.385401810181LF_H_黄岩新前支局BBU12LF_H_黄岩新前消防队_50297.881901800180LF_H_黄岩新前支局BBU13LF_H_黄岩移动七里_49195.646601660166LF_H_黄岩头陀孙东村LF_H_黄岩头陀孙东村_49186.857801160116LF_H_黄岩柑橘研究所LF_H_黄岩柑橘研究所_49189.9802074074LF_H_黄岩新前支局BBU12LF_H_黄岩新前消防队_49199.4117 1.538565164LF_H_黄岩头陀孙东村LF_H_黄岩头陀孙东村_50298.33737.2549511932LF_H_玉环城关岭头村LF_H_玉环城关岭头村_49196.94692.507234732126同时通过对S1切换失败次数最多站点LF_H_黄岩移动新前牟村进行S1链路信令跟踪，发现切换失败命令中，失败原因值为，Unknow-Target ID，目标小区丢失。

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切换失败简析坏小区定义现在给移动的日报中对于切换坏小区的定义为切换成功率<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报告，通过这个报告可以清楚看到小区切出切入小区，切出切入请求次数，切出切入成功率；对于切换坏小区，可以很方便的找出对应切入或者切出问题小区。

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配置是否正确。

TD-LTE网络性能KPI（切换成功率）优化手册1切换成功率定义说明1.1指标公式1.2COUNTER定义1.2.1集团规范定义1、eNB间S1切换出请求次数：源eNB向MME发送的“切换请求”消息（HANDOVER REQUIRED）（3GPP TS 36.413），指示eNB间通过S1接口的切换出准备请求。

向不同小区发送的同一切换准备请求，需要重复统计。

2、eNB间S1切换出成功次数：源eNB收到MME发送的“UE上下文释放命令”消息（UE CONTEXT RELEASE COMMAND）（3GPP TS 36.413），指示eNB间通过S1接口的切换出执行成功。

3、eNB间X2切换出请求次数：源eNB向目标eNB发送的“切换请求”消息（HANDOVER REQUEST）（3GPP TS 36.423），指示eNB间通过X2接口的切换出准备请求。

向不同小区发送的同一切换准备请求，重复统计。

4、eNB间X2切换出成功次数：源eNB收到目标eNB发送的“UE上下文释放”消息（UE CONTEXT RELEASE）（3GPP TS 36.423），指示eNB间通过X2接口的切换出执行成功。

5、eNB内切换出请求次数：eNB向UE发送携带mobilityControlInfo 的“RRC连接重配置”消息（RRCConnectionReconfiguration），指示eNB内小区间切换出请求。

（3GPP TS 36.331）6、eNB内切换出成功次数：eNB收到UE发送的“RRC连接重配置完成”消息（RRCConnectionReconfigurationComplete），指示eNB内小区间切换出成功。

（3GPP TS 36.331）1.2.2NSN映射1、eNB间S1切换出请求次数：M8014C14：INTER_ENB_S1_HO_PREP，The number of Inter eNB S1-based Handover preparations；2、eNB间S1切换出成功次数：M8014C19：INTER_ENB_S1_HO_SUCC，The number of successful Inter eNB S1-based Handover completions；3、eNB间X2切换出请求次数：M8014C0：INTER_ENB_HO_PREP，The number of Inter-eNB X2-based Handover preparations. The Mobility management (MM) receives a list with target cells from the RRM and decides to start an Inter-eNB X2-based Handover；4、eNB间X2切换出成功次数：M8014C7：SUCC_INTER_ENB_HO，The number of successful Inter-eNB X2-based Handover completions；5、eNB内切换出请求次数：M8009C6：ATT_INTRA_ENB_HO，The number of Intra-eNB Handover attempts；6、eNB内切换出成功次数：M8009C7：SUCC_INTRA_ENB_HO，The number of successful Intra-eNB Handover completions；1.3信令统计点1.3.1eNB间S1切换统计点关系：M8014C14 = M8014C15 + M8014C16 + M8014C17 + M8014C18M8014C18 = M8014C19 + M8014C20（注：现网实际数据对不上）1、M8014C14：INTER_ENB_S1_HO_PREPUpdated: This counter is updated following the transmission of an S1AP:HANDOVER REQUIRED message from the source eNB to the MME if this message prepares an Inter eNB Handover.2、M8014C15：INTER_S1_HO_PREP_FAIL_TIMEUpdated: This counter is updated at the expiry of the guarding timer TS1RELOCprep if the timer was started because of the preparation of an Inter eNB Handover.3、M8014C16：INTER_S1_HO_PREP_FAIL_NORRUpdated: This counter is updated following the reception of an S1AP: HANDOVER PREPARATION FAILURE message from MME to source eNB with cause "No Radio Resources Available in Target Cell" if this message is received in response to the preparation of an Inter eNB Handover.4、M8014C17：INTER_S1_HO_PREP_FAIL_OTHERUpdated: The number of failed Inter eNB S1-based Handover preparations due to the reception of an S1AP: HANDOVER PREPARATION FAILURE message with a cause other than "No Radio Resources Available in Target Cell."5、M8014C18：INTER_ENB_S1_HO_ATTUpdated: This counter is updated following the reception of an S1AP: HANDOVER COMMAND message from the MME to the source eNB in case that this message is received in response to the preparation of an Inter eNB Handover.6、M8014C19：INTER_ENB_S1_HO_SUCCUpdated: This counter is updated following the reception of an S1AP: UE CONTEXT RELEASE COMMAND message from the MME to the source eNB with the cause value Radio Network Layer (Successful Handover) in case that this message is received for an Inter eNB Handover.7、M8014C20：INTER_ENB_S1_HO_FAILUpdated: This counter is updated following the expiry of the guarding timer TS1RELOCoverall in case that this timer was started because of an Inter eNB Handover.1.3.2eNB间X2切换统计点关系：M8014C0 = M8014C2 + M8014C3 + M8014C5 + M8014C6M8014C6 = M8014C7 + M8014C8（注：现网实际数据对不上）1、M8014C0：INTER_ENB_HO_PREPUpdated: This counter is updated following the transmission of an X2AP: Handover Request to the target eNB.2、M8014C2：FAIL_ENB_HO_PREP_TIMEUpdated: This counter is updated following the expiry of the guarding timer TX2RELOCprep.3、M8014C3：FAIL_ENB_HO_PREP_ACUpdated: This counter is updated following the reception of an X2AP: Handover Preparation Failure message from the target eNB.4、M8014C5：FAIL_ENB_HO_PREP_OTHERUpdated: The counter is updated if the failure detected does not match any other failure counter.5、M8014C6：ATT_INTER_ENB_HOUpdated: This counter is updated following the reception of an X2AP: Handover Request Acknowledge message from the target eNB.6、M8014C7 ：SUCC_INTER_ENB_HOUpdated: This counter is updated following the reception of an X2AP:ReleaseResource message sent by the target eNB.7、M8014C8：INTER_ENB_HO_FAILUpdated: This counter is updated following the expiry of the guarding timer TX2RELOCoverall.1.3.3eNB内切换统计点关系：M8009C1 > M8014C2M8014C2 = M8014C3 + M8014C5 + M8014C6M8014C6 = M8014C7 + M8014C8（注：现网实际数据对不上）1、M8009C0: TOT_NOT_START_HO_PREPUpdated: The reception of an RRC Measurement Report message sent by the UE to eNB and of the RRM decision not to execute a handover. Updated to the source cell.2、M8009C1: TOT_HO_DECISIONUpdated: The reception of an RRC Measurement Report message sent by the UE to eNB and of an RRM decision to execute a handover. Updated to the source cell.3、M8009C2: INTRA_ENB_HO_PREPUpdated: An internal eNB trigger. The eNB MM receives a list with the target cells from RRM and decides on an Intra-eNB Handover. Updated to the source cell.4、M8009C6: ATT_INTRA_ENB_HOUpdated: The transmission of an RRC Connection Reconfiguration message sent by the eNB to UE, which indicates a Handover Command to the UE. Updated to the source cell.5、M8009C7: SUCC_INTRA_ENB_HOUpdated: The reception of an internal UE Context Release Request for the handover on the source side. Updated to the source cell.6、M8009C3: FAIL_ENB_HO_PREP_ACUpdated: An internal eNB trigger. The eNB MM receives a list with the target cells from the RRM. The MM or RRM AC decides not to execute an Intra-eNB Handover. Updated to the source cell.7、M8009C5: FAIL_ENB_HO_PREP_OTHUpdated: An internal eNB trigger. The eNB MM receives a list with the target cells from RRM. The MM or RRM AC decides not to execute an Intra-eNB Handover. The counter is updated if the failure detected does not match any other failure counter. Updated to the source cell.8、M8009C8: ENB_INTRA_HO_FAILUpdated: The counter is updated to the source cell when timer THOoverall expires.2影响切换成功率的因素2.1从信令流程角度分析（注：个别流程可以会有不同，但大致相当，此处仅以X2切换为例。

LTE网络系统内异频切换出成功率优化目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (4)四、经验总结 (4)LTE网络系统内异频切换出成功率优化【摘要】随着电信4G网络的建设，切换成为多频组网中的一个重要环节，解决好切换问题不仅可以增强网络覆盖质量，提高用户体验，更能增加用户对天翼产品的认可和支持，继而提高用户对天翼品牌的满意度。

日常优化处理中，切换作为主要的处理方面，能够体现4G网络的连续性覆盖的情况。

【关键字】切换用户体验一、问题描述现网指标监控日报中系统内切换成功率指标下降，分析发现TL-市区-联盟村-HFTA-449071-50向看守所的3个小区切换失败次数较多，达到11945次/天。

需要定位处理，提升整体指标。

二、分析过程分析数据，可以发现失败原因基本为“eNB间S1口小区间同频切换出”，占到总次数的11945次，且切换无成功次数，参数核查没有发现问题。

在google earth 上定位基站查看基站分布发现，目标基站TL-市区-看守所至源基站TL-市区-联盟村的距离大约为780M，在正常的切换范围内。

但780M的正常切换范围内的邻区，在无故障无干扰参数无问题的情况下不可能每天11945多次的请求次数全部失败。

进一步核查目标基站是否经历过搬迁等操作发现，TL-市区-看守所该站点此eNodeBID已由449002变更为449071,但是在449071这个BBU下原先添加的外部定义和邻区关系数据依然存在，属于冗余邻区。

至此问题得以定位，源小区TL-市区-联盟村-HFTA-449071-50与目标基站TL-市区-看守所切换时，实际是已经被调整了eNodeBID的目标小区，但因为源eNodeBID的外部定义与邻接关系依然存在，所以源小区依然不断向目标小区发送切换请求，最终导致切换指标恶化。

三、解决措施问题定位后，删除冗余邻区和外部小区，优化后TL-市区-联盟村-HFTA-449071-50切换出成功率由27%左右提升至100%四、经验总结对于现网冗余邻区导致的切换失败问题，应当对全网邻区关系进行核查，及时发现冗余邻区进行删除，防止类似问题再次出现。

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），发现的确未配置邻区。

切换成功率分析与优化方法作者：李性南来源：《科学导报·学术》2020年第47期摘; 要：本文通过切换原因结合案例对切换问题进行分析，列出加强日常优化预防和提高切换成功率的方法。

关键词：切换成功率;信令流程;日常优化1、引言切换（Handover）是移动通信系统的一个非常重要的功能。

作为无线链路控制的一种手段，切换能够使用户在穿越不同的小区时保持连续的通话。

切换成功率是指所有原因引起的切换成功次数与所有原因引起的切换请求次数的比值。

切换主要的目的是保障通话的连续，提高通话质量，减小网内越区干扰，为MS用户提供更好的服务。

2、常见故障分析和解决措施2.1硬件故障当切换执行失败率非常高时，硬件故障可能性最大。

这时我们应通过话务分析来将所出故障的设备定位，并及时处理。

一般包括载频、合路器、天馈线、传输板等问题。

2.2相邻小区关系问题由于在专用模式下，MS在SACCH信道上向系统发送的测量报告，是根据BCCH和BSCIC为标识来区分不同小区的电平情况的。

如果两个小区有相同的（BSIC、BCCH），在正常的情况下这样的两个小区的相距距离应该足够大，因而它们之间不应该有什么关系。

但由于孤岛现象的存在，常常会导致移动台将所测得的虚假报告上报给系统，这个虚假的邻小区测试报告将会误导切换控制程序发出切换指令，这样就使得这些小区内的通话频频尝试向实际信号并不好的小区发出切换请求。

其结果往往造成乒乓切换，并导致孤岛覆盖周边小区的切出切换失败率大幅提高。

而与孤岛小区具有相同BSIC、BCCH的小区的切入切换失败率也将大幅提高。

2.3邻小区信道资源短缺或传输故障如果切换选择失败率（HO SELECTION FAILURE RATE）很高，原因可能是由于要切入的目标小区负荷过高，而且已经没有可用的TCH。

此时，BSC虽然收到HO INDICATION信息，但无法进行切换。

对于一对邻小区上的高切换选择失败率，可查看目标小区的负荷以确认是否为负荷问题。

LTE附着成功率异常说明一、概述 (2)二、维度分析 (4)1、终端维度分析： (4)2、S_GW_IP维度分析 (4)3、小区和用户维度综合分析 (5)三、后续跟进 (7)2014-08-12一、概述广州全网目前主要有3个MME，一个中兴MEE，两个爱立信MME，但近期统计MME附着成功率，发现中兴MME的附着成功率比爱立信的MME的成功率低。

以下统计8月5日到8日11日一周全天的附着成功率，（9号统计数据异常，暂剔除）。

中兴的MME，GZMME401BZx均比其它两个MME附着成功率低，在8月11日附着成功率比爱立信MME附着成功率低5%左右。

全天24小时不同时段，MME附着成功率也呈现异常的规律，从8月6日开始，GZMME401BZx在凌晨1:00至7:00时段成功率相比其它MME低，在4:00至5:00时段为全天附着成功率最低，如以下折线图所示：GZMME401BZx附着成功率在凌晨时段，附着成功率较低和附着尝试次数有一定关系，尝试次数越少，成功率越低（在凌晨时段，部分异常用户仍然一直附着失败），以下为GZMME401BZx附着成功率的折线图：二、维度分析1、终端维度分析：对中兴GZMME401BZx的附着成功率按终端类型维度分析，筛选8月11日全天数据统计，对全网终端分析没有明显的聚中性，以下为TOP20终端的附着成功率。

2、S_GW_IP维度分析对中兴GZMME401BZx的附着成功率按S_GW_IP维度分析，筛选8月11日全天数据统计，对S_GW_IP分析没有明显的聚中性。

3、小区和用户维度综合分析对中兴GZMME401BZx的附着成功率按小区CI维度和用户IMSI分析，筛选8月11日全天数据统计，ATTACH失败有一定的集中性，其中EMM_CAUSE：ESM failure的原因码为用户导致，另外EMM_CAUSE：transport-resource-unavailable 的原因值在小区表现集中性明显。