eSRVCC切换失败 - 360文档中心

VoLTE网络的eSRVCC切换优化方法

VoLTE网络的eSRVCC切换优化方法晋晶晶;杨兴红【摘要】As an evolution scheme to solve the voice technology in LTE, VoLTE makes it possible to carry both voice and data service in area covered with LTE. However, in LTE blind coverage area, the voice service is still carried in 2G/3G network, and eSRVCC handover from LTE to 2G/3G must be supported. The eSRVCC handover process involved many units in LTE and GSM network, and the signaling interaction is complicated. Moreover, the user’s experience is affected much by the differe nt types of phone, different home PLMN, and different scenes. So this article conclude a set of ways by optimization experience, about how to locate the issues, and solve them to improve the successful rate of eSRVCC handover.%VoLTE作为LTE网络解决语音技术的演进方案，实现了在LTE覆盖区内语音和数据都承载在LTE网络，但是在非LTE覆盖区，由2G/3G网络为其服务，支持LTE到2G/3G的eSRVCC切换，eSRVCC切换过程涉及LTE/GSM多个网元，信令交互多，用户行为受终端类型、归属地、所处场景影响较大，本文通过现网优化经验，总结出一套快速准确定位、解决问题，提升eSRVCC切换成功率的工作方法。

华为LTE面试题整理

1、注册成功率=?UE成功注册次数/UE注册请求次数2、VoLTE语音网络接通率=VoLTE语音网络接通次数/VoLTE语音呼叫总次数3、eSRVCC切换成功率=?eSRVCC切换成功次数/eSRVCC切换总次数4、eSRVCC切换时延=?eSRVCC切换累计时长/eSRVCC切换成功次数接通率：LTE差小区问题分析与处理方法1、接入类接入失败通常有三大类原因：无线侧参数配置问题、信道环境影响以及核心网侧配置问题。

因此遇到无法接入的情况，可以大致按以下步骤进行排查：1. 确认是否全网指标恶化，如果是全网指标恶化，需要检查操作，告警，是否存在网络变动和升级行为。

2. 如果是部分站点指标恶化，拖累全网指标，需要寻找TOP站点。

3. 查询RRC连接建立和ERAB建立成功率最低的TOP3站点和TOP时间段。

4. 查看TOP站点告警，检查单板状态，RRU状态，小区状态，OM操作，配置是否异常。

5. 提取CHR日志，分析接入时的信道质量和SRS的SINR是否较差（弱覆盖），是否存在TOP用户。

6. 针对TOP站点进行针对性的标准信令跟踪、干扰检测分析。

7. 如果标准信令和干扰检测无异常，将一键式日志，标口跟踪，干扰检测结果返回给开发人员分析资源分配失败导致RRC连接建立失败1、将SRS资源配置方式修改为接入增强、收缩功率2、增大T302定时器，增加在RRC连接建立拒绝后延长惩罚的时间（默认4s）UE无应答导致RRC建立失败结合实际无线环境通过工程参数调整、站点补盲解决弱覆盖问题；1、根据干扰在每个PRB上的分布特征，定位干扰类型，排查干扰源；2、极端情况下提升小区最小接入电平控制用户接入；3、调整上行功控参数路径损耗因子（0.7）、PUSCH标称P0值（-67）提升UE发射功率；4、降低RACH最大传输次数，减少边缘用户RRC请求核心网问题1、首先确认问题出现的时间点及涉及范围；2、与核心网确认是否在此期间进行过相关操作；3、根据日志分析是否为TOP终端问题；首先要获取全网的掉话率指标及话统变化趋势，如果全网指标突然恶化，需要执行以下检查工作：1. 确认是否存在传输告警，设备异常告警等；2. 分析是否由于话务量突增导致的掉话率恶化；3. 确认近期是否有过版本升级、打补丁等操作等重大操作；4. 分析小区级掉话指标，按照掉话绝对次数分析TOPN，首先核查小区是否存在RRU、通道、传输、基带板等相关告警；5. 分析小区掉话原因、是否存在TOP用户；6. 针对不同原因进行优化调整；无线层问题导致的异常释放eNodeB发起的原因为无线层问题的UEContext释放次数eNodeB发起的原因为上行弱覆盖的UEContext异常释放次数1. 弱覆盖优化建议：结合实际测试无线环境进行RF调整；1、覆盖空洞区域加站；2、边缘覆盖区域通过调整互操作参数使其尽快切换至异系统；3、极端情况通过调整最小接入电平控制用户接入；4、对于上行弱覆盖，可通过调整上行功控参数提升UE发射功率；切换失败原因主要有以下几个方面：传输、设备内部处理、覆盖（弱覆盖/越区覆盖）、干扰、邻区漏配、切换不及时等；传输问题定位需要在收发端抓取数据确认；设备内部处理出错需要提取工作日志进行分析定位；弱覆盖、越区覆盖、干扰、切换不及时、邻区漏配一般体现在信令丢失导致切换失败，属于空口质量问题，优化方法如下：1. 弱覆盖区域需要通过调整天馈、增加功率、新建站点解决；2. 越区覆盖通过控制下倾（机械下倾、电下倾）来控制覆盖范围；3. 干扰问题需要定位干扰类型，外部干扰可通过扫频确认干扰源；内部干扰可使用相关干扰算法降低影响；4. 添加漏配邻区；5. 切换不及时可通过调整切换门限、CIO、迟滞、触发时间等切换参数控制切换点；高误块MOD PCCHCFG 增大用户寻呼下发次数，可提高寻呼成功率MOD CELLCHPWRCFG 寻呼信道功率、随机响应信号功率（值变大增大覆盖，负值降低覆盖），增大该值可提高寻呼成功率MODCELLDLSCHO 随机接入响应消息和寻呼消息码率越小寻呼成功率越高网络驻留能力类（覆盖）、234G互操作类、终端营销类1、TDS空闲态、业务态参数：最低接入、高优先级E-UTRA小区重选RSRP信号门限、TDS重定向至LTE门限；2、GSM重选至LTE门限:基于EUTRAN的最小接入电平、优先级；3、LTE侧空闲态：最低接收电平（小区选择）、最低接收电平（小区重选）、服务频点低优先级重选门限通过以上四个维度为切入点，建立以下五个步骤提升LTE网络用户感知：网络结构优化：弱覆盖区域优化、重叠覆盖优化、干扰小区、故障小区处理；网络质量提升：SINR提升；关键性能参数：PCI参数优化、LTE邻区优化、2G/3G/4G互操作邻区优化、CSFB参数配置优化；双层网异频优化：梳理切换带、PCI合理优化、邻区优化；网络调度提升：服务器、传输带宽、参数、硬件问题。

参数设置不合理导致ESRVCC切换失败分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LTE-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）。

4G侧所加2G邻区的RAC值配置错误导致eSRVCC切换成功率低案例

榆林公司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切换深入分析及实战解决方案

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之间交换切换请求消息及响应消息，以执⾏资源分配。

信号基站切换流程切换失败的原因

信号基站切换流程切换失败的原因下载提示：该文档是本店铺精心编制而成的，希望大家下载后，能够帮助大家解决实际问题。

文档下载后可定制修改，请根据实际需要进行调整和使用，谢谢！本店铺为大家提供各种类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，想了解不同资料格式和写法，敬请关注！Download tips: This document is carefully compiled by this editor. I hope that after you download it, it can help you solve practical problems. The document can be customized and modified after downloading, please adjust and use it according to actual needs, thank you! In addition, this shop provides you with various types of practical materials, such as educational essays, diary appreciation, sentence excerpts, ancient poems, classic articles, topic composition, work summary, word parsing, copy excerpts, other materials and so on, want to know different data formats and writing methods, please pay attention!信号基站切换流程切换失败的原因在移动通信网络中，信号基站切换是指移动终端从一个基站切换到另一个基站的过程。

eSRVCC切换过程与RRC重建立过程并发导致eSRVCC切换失败案例

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切换失败。

ESRVCC切换成功率指标优化方法集

ESRVCC切换成功率指标优化方法集ESRVCC（Enhanced Single Radio Voice Call Continuity）切换成功率是指在LTE网络中使用ESRVCC技术进行切换时，切换成功的概率。

ESRVCC技术是一种实现LTE到2G/3G网络切换的技术，通过它可以实现在VoLTE通话时从LTE网络切换到2G/3G网络并维持通话的连续性。

1.网络容量增强：通过增加基站、扩大覆盖范围、优化邻区配置等方式，增加网络容量，减少切换时的网络拥塞现象，从而提高切换成功率。

2.优化切换参数设置：调整ESRVCC切换相关的参数设置，如ESRVCC 门限、切换优先级、切换触发条件等，使得切换时更加准确，提高切换成功率。

3.优化切换策略：根据不同区域和网络情况，制定合理的切换策略，例如切换禁止区域的划定、优化切换优先级等，以提高切换成功率。

4.加强干扰管理：通过优化频率规划、减少邻频干扰、限制各种无线干扰源等方式，减少切换时的干扰，提高切换成功率。

5.邻区优化：通过邻区规划、优化邻区配置以及邻区间干扰管理等方式，减少切换时的邻区干扰，从而提高切换成功率。

6.强化信令链路：优化信令链路的建设和网络配置，减少信令延迟和丢包率，确保切换过程中的信令传输稳定，提高切换成功率。

7.强化切换演算：通过优化切换演算算法，提高切换时的准确性和效率，减少切换失败的情况，提高切换成功率。

8.加强网络监控和优化：建立完善的网络监控系统，对切换成功率进行实时监测和分析，及时发现问题并采取相应措施进行优化，从而提高切换成功率。

总之，提高ESRVCC切换成功率需要综合考虑网络容量、切换参数设置、切换策略、干扰管理、邻区优化、信令链路质量、切换演算算法以及网络监控和优化等多个方面的因素，并根据具体情况采取相应的优化方法。

只有在各方面工作都得到合理的改进和优化后，才能提高ESRVCC切换成功率，提升VoLTE通话的质量和用户体验。

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 。

利用SEQ提升eSRVCC手段说明

利用SEQ提升eSRVCC手段说明改善eSRVCC切换成功率，更好的实现VoLTE用户语音业务的连续性，提高客户对VoLTE的良好感知，特别对eSRVCC进行了专题提升。

eSRVCC切换流程eSRVCC切换由eNodeB发起handover required在OMC记请求一次，在收到handover command后开始执行，在MME给eNodeB发上下文释放记切换成功。

eSRVCC原因定位eSRVCC主要由以下原因导致切换成功率低案例讲解-4G配置GSM小区参数错误在3月11日现网存在E-UTRAN向GERAN切换出SRVCC的未执行次数较多，通过SEQ发现4G配置2G参数错误导致。

MME发起向GSM小区16066切换2G侧发SRVCC PS TO CS RESPONSE(Cause:73)携带Cause :（No resources available(73)无可用资源）MME立即发HANDOVER PREPARATION FAILURE(Cause:0)携带radioNetwork: unspecified (0)导致ESRVCC切换失败。

核查现网4G侧GSM小区16066发现配置的LAC错误导致，通过核查修改现网配置2G参数后E-UTRAN向GERAN切换出SRVCC的未执行次数明显较少。

案例讲解-核心网DNS侧漏配GSM侧LAC导致执行失败提取0303-0313日高铁站点e SRVCC切换情况，观察发现高铁站点小区eSRVCC切换均失败，而执行次数均为0次在后台跟踪朝阳京哈动车主站二HL-2小区的S1\UU\X2口发现在11:04:08基站向mme发起切换请求，MME响应切换准备失败，失败原因为：unknown-targetid 。

切换请求中携带的切换目标小区为：lac：0x11cf ci：0x3837 解析后为LAC:4559 CI：14391，核查现网配置GSM邻区的LAC、NCC\BCC均和GSM网络公参一致。

eSRVCC失败原因值

故障大类故障场景失败描述4G无线取消资源准备前，MME收到ENODEB的HANDOVER CANCEL消息携带原因值为failure-in-radio-interface-procedure后，转发SRVCC PS TO CS CANCEL NOTIFICATION给EMSC，携带原因为Handover/Relocation cancelled by source system4G无线取消资源准备后MME收到ENODEB的HANDOVER CANCEL消息携带原因值为failure-in-radio-interface-procedure后，转发SRVCC PS TO CS CANCEL NOTIFICATION给EMSC，携带原因为Handover/Relocation cancelled by source system4G无线取消资源准备前，ENODEB取消，携带原因为Unspecified。

SV接口转成SRVCC PS TO CS CANCEL NOTIFICATION4G无线取消资源准备后，ENODEB取消，携带原因为Unspecified。

SV接口转成SRVCC PS TO CS CANCEL NOTIFICATION2/3G无线无资源可用SRVCC PS to CS Response消息中携带CAUSE为73 No resources available 携带SRVCC CAUSE 为3Handover /Relocation Failure with Target system2/3G无线无资源可用SRVCC PS to CS Response消息中携带CAUSE为73 No resources available 携带SRVCC CAUSE为 7 No Radio Resources Available in Target Cell2/3G无线无资源可用SRVCC PS to CS Response消息中携带CAUSE为73 No resources available 携带SRVCC CAUSE 为1Handover /Relocation Failure with Target system2/3G无线目标小区问题SRVCC PS to CS Response消息中携带SRVCC CAUSE为 3 Handover /RelocationFailure with Target system2/3G无线无资源可用SRVCC PS to CS Response携带SRVCC CAUSE 为 7 No Radio Resources Available in Target Cell对应字段srvcc_ps2cs_failure_cancel_before_timessrvcc_ps2cs_failure_cancel_after_timessrvcc_ps2cs_failure_cancel_before_unspecified_times srvcc_ps2cs_failure_cancel_after_unspecified_times srvcc_ps2cs_failure_73_3_timessrvcc_ps2cs_failure_73_7_timessrvcc_ps2cs_failure_73_1_timessrvcc_ps2cs_failure_16_3_timessrvcc_ps2cs_failure_16_7_times。

tS1relocoverall-expiry导致ESRVCC切换失败

tS1relocoverall-expiry导致ESRVCC切换失败tS1relocoverall-expiry导致ESRVCC切换失败【问题描述】YLAO715_2在5月10日15：45至16:00之间统计到1次S1超时导致eSRVCC切换失败，YLAO715_2在异常时段指标统计如下：【问题分析】S1RLOCoveral ，S1切换保护定时器。

当源eNB第一次收到HANDOVER COMMAND消息时将启动定时器TS1RELOCOverall。

如果在源eNB收到UE CONTEXT RELEASE COMMAND消息（必然在定时器超时前收到）或定时器TS1RELOCOverall超时前UE返回到此eNB，则源eNB停止此定时器并继续向此UE提供服务。

在定时器TS1RELOCOverall超时时，如果源eNB之前未收到UE CONTEXT RELEASE COMMAND消息，则源eNB向MME发送UE CONTEXT RELEASE REQUEST消息请求释放UE上下文，并通过切换取消过程指示准备集中的所有小区释放UE上下文。

在收到UE CONTEXT RELEASE COMMAND消息时不会停止定时器TS1RELOCOverall。

通过分析YLAO715_2在异常时段的calltrace可知，ENB在收到MME下发的Handover Command 消息后，未及时收到MME下发的Ue Context Release Command导致切换超时。

ENB收到Handover Command消息的时间为7：48：24：346，在7：48：34：347，ENB向MME上发Ue Context Release Command Request消息请求核心网释放。

查看现网参数配置，现网ENB相应参数tS1RelocOverallForSrvccHandoverToGeran设置为10000ms,所以可以确认为ENB在收到MME下发的Handover Command消息10秒后未收到由MME下发的Ue Context Release Command消息，S1切换超时导致ESRVCC切换失败。

4G侧所加2G邻区的RAC值配置错误导致eSRVCC切换成功率低案例

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

榆林卡特全网连续一周eSRVCC切换指标统计如下：榆林区域总_0 (3512) eSRVCC切换请求次数eSRVCC切换成功次数eSRVCC切换成功率03/20/2016 219 21 9.59%03/21/2016 271 26 9.59%03/22/2016 97 18 18.56%03/23/2016 302 21 6.95%03/24/2016 281 29 10.32%03/25/2016 404 20 4.95%03/26/2016 22421 9.38%03/27/2016 354 25 7.06% 典型站点ao751连续一周eSRVCC切换指标统计如下：日期eSRVCC切换请求次数eSRVCC切换成功次数eSRVCC切换成功率03/20/2016 9 3 33.33% 03/21/2016 33 1 3.03% 03/22/2016 13 1 7.69% 03/23/2016 77 0 0.00% 03/24/2016 36 0 0.00% 03/25/2016 83 0 0.00% 03/26/2016 69 2 2.90% 03/27/2016 0 0 Nerr【问题分析】现场跟踪典型站点ao751的calltrace发现：ao751向2G侧发起了切换请求后，但很快MME向基站侧回复了切换准备失败的消息，失败的原因为未知的目标小区（unknown-targetID），发起请求的信令截图如下：MME回复切换准备失败的信令截图如下：现场进行CDS验证时，也只上报B2事件，但是没有执行切换的Handover Command消息，导致无法切换至2G。

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

eSRVCC失败原因值

eSRVCC失败原因值故障大类故障场景失败描述4G无线取消资源准备前，MME收到ENODEB的HANDOVER CANCEL消息携带原因值为failure-in-radio-interface-procedure后，转发SRVCC PS TO CS CANCEL NOTIFICATION给EMSC，携带原因为Handover/Relocation cancelled by source system4G无线取消资源准备后MME收到ENODEB的HANDOVER CANCEL消息携带原因值为failure-in-radio-interface-procedure后，转发SRVCC PS TO CS CANCEL NOTIFICATION给EMSC，携带原因为Handover/Relocation cancelled by source system4G无线取消资源准备前，ENODEB取消，携带原因为Unspecified。

SV接口转成SRVCC PS TO CS CANCEL NOTIFICATION4G无线取消资源准备后，ENODEB取消，携带原因为Unspecified。

SV接口转成SRVCC PS TO CS CANCEL NOTIFICATION2/3G无线无资源可用SRVCC PS to CS Response消息中携带CAUSE为73 No resources available 携带SRVCC CAUSE 为3Handover /Relocation Failure with T arget system2/3G无线无资源可用SRVCC PS to CS Response消息中携带CAUSE为73 No resources available 携带SRVCC CAUSE为 7 No Radio Resources Available in Target Cell2/3G无线无资源可用SRVCC PS to CS Response消息中携带CAUSE为73 No resources available 携带SRVCC CAUSE 为1Handover /Relocation Failure with T arget system2/3G无线目标小区问题SRVCC PS to CS Response消息中携带SRVCC CAUSE为3 Handover /RelocationFailure with Target system2/3G无线无资源可用SRVCC PS to CS Response携带SRVCC CAUSE 为 7 No Radio Resources Available in Target Cell 对应字段srvcc_ps2cs_failure_cancel_before_timessrvcc_ps2cs_failure_cancel_after_timessrvcc_ps2cs_failure_cancel_before_unspecified_timessrvcc_ps2cs_failure_cancel_after_unspecified_timessrvcc_ps2cs_failure_73_3_timessrvcc_ps2cs_failure_73_7_timessrvcc_ps2cs_failure_73_1_timessrvcc_ps2cs_failure_16_3_timessrvcc_ps2cs_failure_16_7_times。

基于SEQ平台异常话单VoLTE eSRVCC切换失败问题分析

基于SEQ平台异常话单VoLTE eSRVCC切换失败问题分析
一、问题描述
C国C运营商eSRVCC切换成功率恶化，需要对TOP切换失败小区进行问题分析和定位。

（注：该运营商是LTE到2G的CS Only的SRVCC切换策略，无LTE到3G的SRVCC。

）
二、告警信息
无。

三、版本信息
NA
四、原因分析
1.以双流黄龙溪水厂为例，eSRVCC向GERAN小区间切换失败，主要集中2G目标小区
32805上，如下图所示：
五、处理过程
1.通过SEQ平台eSRVCC异常SIP信令分析，发现Handover Preparation Failure中携带有
“unknown-targetID”信息。

2. 在Handover Required消息中找到切换目标小区Target ID如下：
2.对比eNodeB外部邻区配置数据和GSM工参，发现现网LAC和CI配置错误。

eNodeB现网外部邻区配置数据：
GSM工参数据：
3.处理结果
邻区配置修改正确后，问题解决。

4.根因
VoLTE的GERAN外部邻区LAC和CI配置错误，导致eSRVCC切换失败。

5.总结和建议
外部邻区数据核查是处理eSRVCC切换失败的一个重要动作之一，在无线侧要定期执行核查。

SEQ平台的eSRVCC异常话单SIP信令分析，有助于快速进行根因问题定界定位。

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