eSRVCC切换失败案例(自写)

合集下载

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最新切换配置QCI优先级设置错误eSRVCC不切换

最新切换配置QCI优先级设置错误eSRVCC不切换

精品资料切换配置Q C I优先级设置错误e S R V C C不切换........................................切换配置QCI优先级设置错误eSRVCC不切换南京华苏科技股份有限公司邵文俊故障现象:测试人员在东胜青铜器广场地下商场测试VOLTE 语音业务达到4-2切换门限时一直上报测量报告未进行切换,后测试人员主动挂机结束本次呼叫原因分析:流程图切换目标GSM小区分析1、硬件故障通过网管查询当前告警以及历史告警信息,发现该基站以及周边基站近期无告警,排除基站告警故障。

2、干扰问题通过网管取该小区上近三天上行干扰情况,统计该区域小区均没有干扰、3、目标GSM指标分析查看东胜区青铜器广场微蜂窝-1近三天无SD与TCH信道拥塞,信道完好率均100%4、邻区漏配、进一步排查,占用小区东胜青铜器广场-HLWE,达到eSRVCC切换门限未能及时切换至GSM小区,核查4-2邻居区结果如下,本小区均已经添加和周边GSM以及同覆盖室分邻区关系。

通过以上分析可以得出切换目标GSM小区涉及到ESRVCC切换各种指标均正常,基本排除问题出在GSM侧切换源LTE小区分析1、日常指标提取近三天东胜青铜器广场-HLWE-1流量与核心指标及其干扰告警情况,可见该小区业务量正常,核心指标良好,无告警与干扰,基本排除LTE无线环境问题。

2、切换门限核查东胜青铜器广场-HLWE-1小区的eSRVCC相关切换开关设置与之配套门限值,核查结果表明相关设置与门限均在合理范围之内,排除参数与门限设置导致不切换。

SRVCC ONInterRatHoA1ThdRsrp -110InterRatHoA2ThdRsrp -115InterRatHoGeranB1Thd -903、配套参数核查esrvcc切换配套参数,发现服务质量等级1与服务质量等级5切换配置QCI优先级出现配置错乱,切换配置优先级是连接态的,DRX特定优先级是空闲态的,能不能进行esrvcc是跟切换配置QCI优先级有关跟DRX的QCI优先级没关系。

基站硬件故障导致切换失败-GPS原因导致

基站硬件故障导致切换失败-GPS原因导致

基站硬件故障导致切换失败1.问题描述在广州实验网升级后测试中发现在广州广园西路广州宇航台基站到广州九龙酒店基站路段,UE多次试图从广州宇航台2小区切换到广州九龙酒店3小区上,但一直切换失败。

RNC发PHYSICAL CHANNEL RECONFIGURA TION(DCCH)后,UE回PHYSICAL CHANNEL RECONFIGURA TION FAILURE,导致切换失败。

此后UE一直试图切换到广州九龙酒店2小区,依旧是物理信道重配失败,直到广州宇航台2小区信号太弱而掉话,掉话后UE重选到广州九龙酒店1小区。

当时手机发射功率较高,但下行ISCP值正常。

如下图所示:2.问题分析为了避免问题的偶然性,我们将手机重启后,对该区域进行复测,情况依旧。

机房检查该基站及周围基站均正常,未发现任何告警,参数检查也未发现任何异常。

为了对问题进一步定位,我们使UE在广州九龙酒店3小区起呼接入,行驶到广州市客运站附近,手机试图从广州九龙酒店3小区切换到广州毛织广场(南站路)1小区,但发生了同样的物理信道重配失败,挂断后手机经过多次重选后,重选到广州毛织广场(南站路)1小区。

在本次测试过程中发现下行ISCP值较高,如下图所示:怀疑该站ISCP存在干扰导致切换失败,于是我们又对周围基站进行测试,在环市西路上UE占用广州环市西路1小区,试图切换到广州九龙酒店2小区,但发生物理信道重配失败,再次切换UE向RNC回了PHYSICAL CHANNEL RECONFIGURA TION COMPLETE,但3秒后拖网,因此也是切换失败。

本次测试发现广州九龙酒店2小区和广州九龙酒店1小区切换正常通过以上测试结果可以确认:广州九龙酒店3个扇区之间切换正常,但与其它基站的切入切出均出现异常,各小区接入均正常。

PCCPCH RSCP值及下行ISCP值均正常,手机功率较高。

正常切换的整个过程可分为四个阶段,分别为测量过程、预同步过程、判决过程和执行过程。

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

eSRVCC切换失败

eSRVCC切换失败

全网eSRVCC切换失败信令携带的主要原因码
(1)2 Handover/Relocation cancelled by source system
原因:1)MME存在处理流程冲突,如Service Request和Handover流程冲突。

基站发生切换请求后,未等到核心网的切换相应消息,定时器超时后基站取消切换
2)基站内部处理流程异常,发送切换取消
(2)3 Handover /Relocation Failure with Target system
原因:2G接入失败,导致切换不成功
(3)8 Failure in Radio Interface Procedure
原因:4G无线原因导致切换失败
(4)7 No Radio Resources Available in Target Cell
原因:2G系统拥塞等原因导致切换失败
(5)6 Target Cell not available
原因:2G邻区配置错误等
解决措施
针对2G系统拥塞:严格按照集团要配置空闲态4G驻留门限等参数,提升4G数据业务驻留比,降低2G网络负荷;加强2G网络拆闲补忙,合理规划2G退频节奏,确保热点地区2G资源不受限。

2G网络质差:加强2G小区干扰排查,对于无法降低干扰的小区将其从邻区中删除;开展精细优化,建立2-4G邻区修改联动机制,减少邻区漏配、错配等导致的空口质差;对于暂时无法解决的2G质差区域,通过提高eSRVCC切换的2G门限、增加触发时间等参数调整措施,减少这类小区的eSRVCC切换请求数量。

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

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

12-RAC设置问题导致核eSRVCC切换准备失败问题处理

12-RAC设置问题导致核eSRVCC切换准备失败问题处理

名称:RAC设置问题导致核eSRVCC切换准备失败问题描述:eSRVCC切换用例测试中,发现终端上报B2 MR后基站未有下发MobilityFromEutraCommand 的问题,导致无法切换。

为了验证ESRVCC的功能是否可以正常切换,特修如下参数:A2\B2\异系统互操作,如下表标黄区域参数修改后:测试过程终端上报B2的MR后、网络侧未响应终端,终端始终未收到ENB下发MobilityFromEUTRACommand消息,导致终端无法eSRVCC的切换。

问题分析:提取对应时间段内的CDL-log进行分析发现异常如下:终端上报B2-MR后,ENB经过S1口向EPC上报了Handover Requied切换准备消息后(上报LAC\CI\RAC),EPC直接回复了Handover Preparation Failure导致切换失败(失败原因为:radioNetwork : unknown-targetID)一般失败需要分析目标GSM邻小区配置是否异常从切换流程上,我们接入网是没有问题的、而MME需要到目标MSC/SGSN做切换请求,有可能是这一步出问题。

下一步需要与核心网人员确认下相关数据和功能是否正常通过MME侧的抓包,发现异常。

核心网答复原因:eSRVCC切换构造的域名为:RAC配置异常,需要我们核对RAC配置是否正确、通过检查我们配置的RAC都是"0"如下图:而基站所在DNS eSRVCC切换构造的域名为:cxxxx.rac.epc.mnc000.mcc460.3gppnetwork.or中RACXXXX为0000导致查询DNS失败,RACXXXX应该固定为RAC0001解决措施:通过修改外部GSM邻区RAC区设置,由0设置为1。

处理效果由0设置为1后验证切换正常。

VOLTE的SRVCC切换失败案例

VOLTE的SRVCC切换失败案例

VOLTE的SRVCC切换失败案例2G的BSC入切换未打开导致SRVCC切换失败1.问题描述全网volte功能开启后ESRVCC切换成功率一直处于20%-30%较低的水平。

通过分析发现XXYINSIGOU_ALH_2、XXGANGOU_ALH_3成功率一直为0%,请求次数还比较多,比较典型。

详细指标如下:XXYINSIGOU_ALH_2 _Esrvcc_HO_to_GREN_req _Esrvcc_HO_to_GREN_SUC_Esrvcc_HO_to_GREN_SUC_rat 03/05/2021 126 0 0 03/06/2021 201 0 0 03/07/2021377 0 0 Nerr 03/08/2021 0 0 Nerr 03/09/2021 0 0 03/10/2021 38 0 0XXGANGOU_ALH_3 _Esrvcc_HO_to_GREN_req _Esrvcc_HO_to_GREN_SUC_Esrvcc_HO_to_GREN_SUC_rat 03/02/2021 4 0 0 Nerr 03/03/2021 0 0 Nerr03/04/2021 0 0 Nerr 03/05/2021 0 0 Nerr 03/06/2021 0 0 03/07/2021 7 0 02.问题分析首先核对参数和邻区配置,通过对两个站点volte开启参数以及ESRVCC切换先关参数核查发现全部配置正确。

然后对两个站点所加的2G邻区配置进行核查(频点、NCC、BCC是否和2G现网一致,4G添加的2G邻区是否有同频同BISC),结果均为发现问题。

通过对XXYINSIGOU_ALH_2小区进行calltrace跟踪发现向LAC:14160,CI:19019发生切换请求并失败,测量报告中为BCCH:78和BCCH:71。

测量报告测量报告切换请求 LAC 14160 CI 19019 BCCH 78 71 NCC 6 2 BCC 6 7 GSM信号强度大于-90dBM 大于-90dBM 从以上trace分析可以看出eNB向MME发送了Handover Required,切换类型为ltetogeran,随后MME向eNB发送切换准备失败,这样就有两种可能:核心网的问题和GSM站点的问题。

srvcc切换深入分析及实战解决方案

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

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

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

CIO配置错误导致切换失败率高

CIO配置错误导致切换失败率高

CIO配置错误导致切换失败率高问题解决目录1 目的 (3)2 适用对象 (3)3案例分析 (3)3.1、【问题描述】 (3)3.2、【问题分析】 (3)3.3、【解决方法】 (4)3.4、【效果对比】 (5)关键词:CIO配置摘要:后台参数配置会对无线环境的影响是很大的,参数的修改的依据是对无线指标分析和拉网LOG分析的结果,盲目的修改将影响无线指标。

缩略语清单:无参考资料清单:无1 目的CIO配置错误导致切换失败率高问题解决。

2 适用对象全体工程师3案例分析3.1、【问题描述】在话务统计报表中,有关于小区邻区级的切换统计。

通过几天的top小区分析,观察到小区17161向小区17162的切换出失败率较高。

具体数据如下表:3.2、【问题分析】分析其切换出失败的细分类,观察到由于<物理信道失败>造成的切换出失败占总失败次数的大多数,如下表:物理信道失败,通常发生于UE 上报测量报告,RNC 成功判决并下发物理信道重配置后,无法在切换目标小区接收到UE 的物理信道重配置完成消息。

这表明在这时刻,切换目标小区的信号质量虽然满足了切换判决,但其信号质量并不好。

3.3、【解决方法】以下是同频、异频切换的相关定义: 同频切换事件事件1G当下列等式在触发时间(Time-to-trigger )内一直成立的时候,UE 报告事件1G (最佳小区的改变)给RNC :,1010__1best previous best previous g O LogM H O LogM i i +⋅>-+⋅公式中的参数含义如下: Mprevious_best 是前最佳小区的当前P-CCPCH RSCP ,单位mW Oprevious_best 是前最佳小区的单独偏移Mi 是正在评估的小区i 的当前P-CCPCH RSCP ,单位mW Oi 正在评估小区i 的单独偏移H1g 是报告事件1G 的滞后参数。

异频切换事件当下列等式在触发时间(Time-to-trigger )内一直成立的时候,UE 报告事件2A (最佳频率的更新)给RNC :2/2a Best NotBest H Q Q +≥公式中的参数含义如下: QNot Best 是变量BEST_FREQUENCY_2A_EVENT 中"bestfrequency"没有存储的频率质量估计。

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

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

问题现象在日常KPI监控发现黔西南LTE小区9WMI黄金大酒店LHB-XD-2 5月27日至5月28日,日均失败236次,影响了黔西南整网ESRVC切换成功率。

问题分析1. eSRVC切换信令流程1. eNodeB向UE下发异系统测量控制。

2. UE回复eNodeB响应消息。

3. UE测量到邻区满足门限后触发测量上报。

4. eNodeB作出切换判决后,向MM/送handover required 消息,并标识这是个SRVCC勺切换。

5. MME各语音承载和其他承载分离后,向MSC以及目标SGSN分别发送relocation request 消息。

6. SRVCC MS收到relocation request 后,向RNC/BSC发送切换准备指示,RNC/BSC准备好资源后返回4. 故障排查从OMC 上面查询LTE 小区以及GSM 」、区的历史故障告警情况,发现不存在影响业务的告警。

级别告嚳ID 八网元类型SO定位信息29204 工接口故睦告粵 BTS3900 LTE 9WM 召針乳9WM-黄金帰, 訳巩已日容称旳灿1-黄全 重要 29204 X2接口故障告警 BTS39OOLTE黄金丸酒… 9'/.ia-黄金大酒… 寸巾比B 容称国叫M-黄金. 重要 25952 用户面蘇锥路… BTS3900 LTE 9WM”黄金大酒… 9WM 養金牆… 用户面本端遜标识=0,^ 重要 25952 用户面険载磁路… BTS39OOLTE 9WM 養金毎 9W*黄金大酒… 用户面本曲标识=0,21 重要25888SCTP^S 故障...BTS3&00LTE 9WM-黄金炯協齬号=22 蹴号述信息=酮…重要25888scTPgagttpt... BTS3900LTE樋路号北S®aS=eNo...5. 覆盖核查查询5月份MR 数据,发现9WM 黄金大酒店LHB-XD-2整体覆盖率在97.24%,不存在大范围弱覆盖,从 map info地图上面查看LTE 小区和GSM 小区相隔300多米不存在覆盖问题。

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 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切换失败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切换成功率低案例

榆林公司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失败原因值

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切换失败问题分析

基于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信令分析,有助于快速进行根因问题定界定位。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

eSRVCC切换失败案例
1、北方塑编源侧重建立切换失败(2G故障导致)
【问题描述】
提取1月份eSRVCC切换指标发现,SPLS_北方塑编_ZLH_32F_129小区1月1日存在切换失败较严重问题,所有切换失败均为源侧发生重建立,目标小区为共站址2G北方塑编G1小区(卡特)。

【问题分析】
经查询源小区切换失败当天无故障告警:
经查询1月1日卡特2G北方塑编基站存在硬件故障,严重影响切换成功率,导致无法切入:
【解决方案】
2G基站故障已恢复,SPLS_北方塑编_ZLH_32F_129小区eSRVCC切换成功
率恢复正常。

2、伊通冀家切换失败(突发)
【问题描述】
提取1月份前半月eSRVCC切换指标发现,SPYT_冀家_ZLH_31F_1小区1月5日存在切换失败较严重问题,切换出准备请求次数65次,切换出执行失败次数64次,所有切换失败均统计为源侧发生重建立,目标小区为共站址2G冀家G1小区(卡特)。

【问题分析】
经查询2G冀家基站5日故障告警情况由于系统未保存,已无从查询历史告警。

查询4G冀家基站5日无故障告警。

对比10天此小区切换数据发现,仅有5日切换请求次数大于3,差异较大。

通过参数核查发现参数配置无异常。

由此判断此小区切换失败原因可能:1、2G侧基站故障导致;2、网管统计异常,或为单用户突发行为导致。

近10天该小区切换数据统计:
4G站点告警情况(5日无故障):
【解决方案】
目前该问题已恢复。

相关文档
最新文档