ESRVCC切换成功率低处理案例

参数设置不合理导致ESRVCC切换失败分析参数设置合理与否是影响ESRVCC切换成功与否的一个重要因素。

ESRVCC切换失败可能由多种原因引起，包括网络质量不佳、设备兼容性问题、运营商网络配置错误等。

在这些问题之外，参数设置的不合理也可能导致ESRVCC切换失败。

接下来，我将详细分析参数设置不合理导致ESRVCC切换失败的可能原因。

首先，本地设备参数设置不合理可能导致ESRVCC切换失败。

在进行ESRVCC切换时，本地设备参数设置不合理可能导致切换信令的传输失败，从而导致切换失败。

例如，如果终端设备的参数设置中语音编解码器不支持ESRVCC切换所需的编码方式，就无法进行ESRVCC切换。

此外，如果终端设备的参数设置中配置的最大码率与网络允许的最大码率不一致，也可能导致ESRVCC切换失败。

其次，运营商网络参数设置不合理可能导致ESRVCC切换失败。

在进行ESRVCC切换时，运营商网络参数设置不合理可能导致切换信令在传输过程中出现错误或丢失，从而导致切换失败。

例如，运营商配置的切换触发门限值过低或过高，会导致切换过于频繁或无法触发切换。

此外，运营商网络中与ESRVCC切换相关的接口参数设置错误，也可能导致ESRVCC切换失败。

再次，网络质量差可能导致ESRVCC切换失败。

ESRVCC切换需要保证实时传输的语音数据在切换时的连续性和稳定性，而网络质量差会导致实时传输的语音数据在切换过程中出现丢包或延迟，从而导致切换失败。

例如，网络带宽不足、网络拥塞或网络抖动等问题都可能导致ESRVCC切换失败。

最后，设备之间的兼容性问题也可能导致ESRVCC切换失败。

ESRVCC切换是终端设备和运营商网络之间的一项复杂协作过程，如果设备之间的版本或配置兼容性存在问题，就可能导致切换失败。

例如，终端设备的硬件或固件版本过低或过高，无法与运营商网络进行正常的切换协商和协作，就会导致ESRVCC切换失败。

综上所述，参数设置的不合理可能导致ESRVCC切换失败。

目录1概述 (2)2ESRVCC切换成功率指标介绍 (2)2.1ESRVCC指标统计信令节点 (3)2.2ESRVCC失败原因分析 (4)2.2.1LTE到GSM的切换出准备失败次数，目标侧准备失败 (4)2.2.2LTE到GSM的切换出准备失败次数，等待切换响应定时器超时 (6)2.2.3LTE到GSM的切换出准备失败次数，其它原因 (7)2.2.4LTE到GSM的切换出执行失败次数，源侧发生重建立 (8)2.2.5等待UE CONTEXT RELEASE消息超时 (11)2.2.6LTE到GSM的切换出执行失败次数，其他原因 (11)概述SRVCC（Single Radio Voice Call Continuity）是3GPP提出的一种VoLTE语音业务连续性方案，主要是为了解决当单射频UE 在LTE/Pre-LTE 网络和2G CS 网络之间移动时，如何保证语音呼叫连续性的问题，即保证单射频UE 在IMS 控制的VoIP 语音和CS 域语音之间的平滑切换。

LTE 网络建设初期，其覆盖范围有限，当用户在使用LTE 网络进行语音通话过程中，移动到LTE 信号较弱，但GERAN网络信号覆盖较好的区域时，为了保证语音呼叫连续性（Voice Call Continuity，VCC），需要将话路由LTE 切换到GERAN。

由于目前还没有能够在LTE 和GERAN同时附着并收发数据的终端，因此LTE和2G 之前的业务连续性都基于Single Radio 模式，即双模单待方式。

目前3GPP 已经制定出双模单待方式的语音业务连续性方案，即3GPP TS 23.216 R9中提出的双模单待无线语音呼叫连续性(Single Radio Voice Call Continuity，SRVCC）方案。

1 eSRVCC切换成功率指标介绍eSRVCC切换成功率=切换至2G的切换成功次数（C373333312）/切换至2G的切换请求次数（C373333330）。

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 值。

榆林公司4G侧所加2G邻区的RAC值配置错误导致eSRVCC切换成功率低案例【问题描述】榆林现卡特区域eSRVCC切换成功率指标较低，只有10%左右，主要原因为部分站点eSRVCC切换成功率较低导致。

榆林卡特全网连续一周eSRVCC切换指标统计如下：典型站点ao751连续一周eSRVCC切换指标统计如下：【问题分析】现场跟踪典型站点ao751的calltrace发现：ao751向2G侧发起了切换请求后，但很快MME向基站侧回复了切换准备失败的消息，失败的原因为未知的目标小区（unknown-targetID），发起请求的信令截图如下：MME回复切换准备失败的信令截图如下：现场进行CDS验证时，也只上报B2事件，但是没有执行切换的Handover Command消息，导致无法切换至2G。

现场CDS信令截图如下：eSRVCC完整信令流程如下：根据空口的信令流程来看，只是说明无线环境质量达到了B2门限，也就是说上述流程中的第一步满足条件，从空口信令以及以上eSRVCC流程来看，不切换有如下可能原因：1、由于基站未开启eSRVCC测量开关等原因，eNB 没有收到MeasurementReport（B2）导致切换流程无法继续。

2、4-2G邻区问题，通过UE上报的频点信息以及eNB内部的2G邻区信息（LAC RAC CI），MME或者MSC无法找到对应2G小区导致失败。

3、eNB收到MeasurementReport（B2）后，没有向MME发起handover Required消息。

4、MME收到handover Required之后，没有向MSC交互后续信息。

5、MME和MSC之间信息交互失败。

所以，不切换的原因可能是基站eSRVCC相关的开关测量未正确配置导致，或者是上端核心网参数配置错误导致。

后台对该站的eSRVCC相关参数再次核查，开关都已打开，测量也已配置，但在核查2G邻区信息时发现，部分2G邻区里的RAC值与2G现网的RAC值不一致（榆林卡特区域2G的RAC值为3，华为区域的2GRAC值为0）。

srvcc切换深⼊分析及实战解决⽅案eSRVCC切换成功率指标优化1、eSRVCC概述1.1实现原理SRVCC(Single Radio Voice Call Continuity)，解决语⾳控制和移动到CS⽹络切换时的语⾳连续性问题。

为基于IMS的VOIP呼叫解决⽅案，利⽤IMS核⼼⽹络提供LTE VoIP语⾳业务的路由、控制和业务触发，并提供LTE向2G/3G切换时的语⾳连续性保证。

SRVCC的实现过程实质上就是⼀个切换过程，在LTE⽹络中终端是通过IMS来实现语⾳功能的，当终端离开LTE⽹络后，则通过MSC server(Mobile Switching Center server)切换到2G/3G ⽹络中从⽽实现在2G/3G⽹络中的语⾳功能。

eSRVCC：相⽐于SRVCC，媒体切换点改为更靠近本端的设备。

具体⽅案就是增加ATCF/ATGW功能实体作为媒体锚定点，⽆论是切换前还是切换后的会话消息都要经过ATCF/ATGW转发。

后续在发⽣eSRVCC切换时，只需要创建UE与ATGW之间的承载通道，对端设备与ATGW之间的媒体流还是通过原承载通道传输。

这样其创建新承载通道的消息交互路径明显短于SRVCC⽅案，减少了切换时长。

eSRVCC⽅案相对于SRVCC⽅案的增强在于减少了切换时长（切换时长⼩于300ms），使⽤户获得更好的通话体验。

1.2信令流程当⽹络或者终端不⽀持DTM，那么⽹络只可以使⽤普通的切换命令HANDOVER COMMAND，仅进⾏cs域切换，Ps业务和流程挂起，切换完成后终端将请求挂起GPRS。

流程分析如下：(6)MSC Server通过发送Prepare Handover Request消息给⽬标MSC，让Ps—cs 切换请求和cs—inter—MSC切换请求相互作⽤。

MSC Server对⽬标BSS在接⼝上分配⼀个默认SAI作为源ID，且对Prepare Handover Request使⽤BSSMAP encapsulatedo(7)⽬标MSC和⽬标BSS之间交换切换请求消息及响应消息，以执⾏资源分配。

工业学校站点切换过早造成切换成功率低问题分析报告————————————————————————————————作者：————————————————————————————————日期：*＊工业学校站点切换成功率低问题分析报告ﻬ1、现象描述8月17日以来３CYCCX**工业学校站点切换成功率低。

时间RRC连接成功率(％）ＥRＡB建立成功率(％)无线接通率(%)无线掉线率(%)ERAB掉线率(%)RRC连接重建比率(%)eNodｅB间切换成功率(%)eNodeB内切换成功率（％）同频切换成功率(%)异频切换成功率(%)切换成功率(%)0８/17/２016９9.98% 99.98%99.96%０.０2% 0.02%６.１7%8５.89%９9.45% 98.9４%86.６5％88.20%0８／1８/2０1６99.96% ９9．9４%99.89%0.０７%０.0７%６.05% 87.32%９9．57%９8．9９%８8.06%89．56%08／19/2016９9．98%99.９７%99.95％0.02%０．02%3．1７％９0.８９%99.５3% 99.03％91.４３％９2.６9%图1日常KPＩ截图2、原因分析与问题解决观察周边站点指标,未发现切换类指标恶化情况。

告警及通道故障排查,未发现有如下影响业务的告警：观察小区接通率、掉话类、干扰和覆盖指标均正常。

仅仅切换指标恶化。

查看两两小区切换指标,通过该统计项可以发现具体哪两个小区的切换成功率差。

发现问题站点与目标站点(基站标识=65０144）切换异常,切换失败次数较多,且主要表现为特定两小区间切换过早次数较多。

切换过早的定义为切换过程中，源小区切换至目标小区，但一段时间后,又切换回至源小区。

由于重建的引入,通常过早切换能通过重建回原小区,故不会引发掉话。

过晚切换是指UE在一个小区很长时间后发生RLF,随后向另一小区发起重建请求。

该次切换因为是无效的切换,会被统计为切换失败。

eSRVCC切换过程与RRC重建立过程并发导致eSRVCC切换失败案例【问题描述】Co352_1在发生eSRVCC的切换过程中，突发出现RRC重建立请求，随后基站向MME上发HandoverCancel消息导致一次eSRVCC切换失败，基站向MME上发HandoverCancel信令截图如下：【问题分析】从信令来看，基站向UE发送Mobility From EUTRA Command后，核心网应该向基站侧下发Ue Context Release Command的消息，但基站一直没收到这样的消息，导致后面基站向MME回复Handover Cancel消息(Cause: interaction-with-other-procedure，)出现切换失败。

基站没收到核心网下发的Ue Context Release Command消息的主要原因为基站在那时也收到了由UE上发的RRC重建立请求消息，由于RRC重建立消息与eSRVCC切换消息并发导致了此次切换失败，Handover Cancel解析出的原因为interaction-with-other-procedure，表示有其它程序干扰导致切换失败。

且从ENB收到MME 下发的Handover Command消息到ENB上发给MMEHandover Cancel消息之间的时间差为164ms, 现网参数TS1RLOCoveral S1切换保护定时器设置为10000ms，并没有超时。

正常的eSRVCC切换信令截图如下：基站向MME上发HandoverCancel信令失败原因截图如下：【问题解决】该问题是过程冲突问题，需基站侧改进判决机制解决（例如在TS1RLOCoveral超时前遇到RRC重建立时，ENB可不直接向核心网发送Handover Cancel消息，在TS1RLOCoveral范围内若RRC重建立成功可继续进行eSRVCC信令流程）。

另外，可对一些特殊场景进行eSRVCC门限优化，避免在eSRVCC切换过程中由于RSRP骤降导致eSRVCC切换失败。