参数设置不合理导致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不切换
精品资料切换配置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优先级没关系。
电脑无法 正确切换显示器输出的原因分析
电脑无法正确切换显示器输出的原因分析在日常使用电脑的过程中，我们经常会遇到需要切换显示器输出的情况，比如从笔记本电脑的屏幕切换到外接显示器，或者在多台显示器之间进行切换。
然而，有时候电脑却无法正确地完成这个切换过程，给我们带来了不少困扰。
下面，我们就来详细分析一下造成这种情况的原因。
首先，硬件方面的问题是导致电脑无法正确切换显示器输出的常见因素之一。
连接线缆的质量和连接的稳定性是一个关键。
如果使用的是劣质或者损坏的线缆，例如 VGA 线、HDMI 线等，可能会导致信号传输不稳定，从而影响显示器的正常切换。
有时候，线缆没有插紧，或者接口处有灰尘、氧化等情况，也会造成连接不良，使电脑无法识别显示器。
另外，显示器本身的硬件故障也可能引发问题。
显示器的控制板、电源模块等出现故障，都有可能导致无法正常接收和处理来自电脑的输出信号。
显卡方面的问题同样不容忽视。
显卡驱动程序未正确安装或者版本过旧，可能会导致显卡无法正常工作，从而影响显示器的切换。
如果显卡出现硬件故障，比如显存损坏、芯片过热等，也会导致输出异常。
其次，软件设置方面的错误也是造成电脑无法正确切换显示器输出的重要原因。
操作系统的显示设置不正确是较为常见的情况。
在 Windows 系统中，如果没有正确地识别和配置显示器，或者设置了错误的分辨率、刷新率等参数，都可能导致切换失败。
有些应用程序可能会独占显卡资源，导致其他显示器无法正常切换。
例如，某些游戏或者图形设计软件在运行时，可能会锁定显卡的输出模式，使得切换操作无法生效。
多显示器设置中的一些错误也会带来麻烦。
比如，没有正确地设置主显示器和扩展显示器，或者在切换时选择了错误的模式，都可能导致显示输出不正常。
再者，系统冲突和兼容性问题也可能是罪魁祸首。
不同版本的操作系统和显卡驱动之间可能存在兼容性问题。
新的操作系统可能与旧版本的显卡驱动不兼容，或者某些特定的系统更新可能会影响到显卡的正常工作。
电脑中安装的其他软件也可能与显卡驱动或者显示设置产生冲突。
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切换请求数量。
VoLTE优化经验总结及案例
VoLTE优化经验总结及案例分享1优化经验总结1.1日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3.导致NAS的层3消息已经比MR要早，但是因为优先级比MR 和SIP低，未及时发送。
优化措施：降低QCI5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3QCI5PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
卡特eSRVCC切换成功判断标准与华为不一致导致eSRVCC切换成功率较低
卡特eSRVCC切换成功判断标准与华为不一致导致全网eSRVCC切换成功率较低【问题描述】【问题分析】根据calltrace来看，本次eSRVCC失败的原因为UE在切换至2G过程中，MME下发UE CONTEXT RELEASE COMMAND的释放消息中Cause原因值为:normal-release（切换成功的释放消息中Cause 原因值为:successful-handover），卡特NPO定义切换成功的counter如下：The counter is triggered when the S1AP UE CONTEXT RELEASE COMMAND message with cause Successful handover is received from the MME，即MME下发的UE CONTEXT RELEASE COMMAND消息解析原因为successful-handover方为eSRVCC切换成功。
但本次切换信令并没有丢失，只是UE CONTEXT RELEASE COMMAND消息解析原因是normal-release而导致切换失败。
需要协调核心网帮忙定位核心网下发UECONTEXT RELEASE COMMAND消息时所解析原因值normal release的原因。
另外，经与华为厂家人员确认，华为eSRVCC切换成功的判断依据并不是以MME下发的UE CONTEXT RELEASE COMMAND 内解析的Cause原因值successful-handover来定义成功的，而只是以MME下发UE CONTEXT RELEASE COMMAND该条信令来判断eSRVCC切换成功。
由于卡与华为eSRVCC切换成功判断标准不同，导致卡特全网eSRVCC切换成功率略低。
DO150在UeContextReleaseCommand中解析原因为NormalRelease导致ESRVCC失败的信令截图如下：ESRVCC正常切换信令截图如下：【问题解决】（1）需与客户确认eSRVCC切换成功的判断标准（如果只是以MME下发UE CONTEXT RELEASE COMMAND该条消息，则需卡特更换eSRVCC切换成功的counter公式）。
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切换准备失败问题处理
名称：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优化经验的总结及案例
VoLTE优化经验总结及案例分享1 优化经验总结1.1 日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR 和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer 由300ms 修改为无穷大优化效果：VoLTE无线接通率提升明显1.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5 系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
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之间交换切换请求消息及响应消息，以执⾏资源分配。
切换失败的原因及优化方法
切换异常的原因及优化方法（1）硬件故障导致切换异常由于TD采用多通道智能天线系统，而良好的赋形首先需要各个通道之间功率校正保持一致。
如功率校正通不过，将会导致赋形产生偏差，从而可能导致系统切换失败。
优化方法：查看基站设备告警记录，对故障的天线、基站硬件设备进行更换。
（2）同频同扰码小区越区覆盖导致切换异常在专用模式下，UE发送的测量报告，是根据PCCPCH 的使用频点以及扰码为标识来区分不同邻小区的。
如果存在同频同扰码小区越区覆盖，则可能会出现UE上报的测量报告中存在虚假邻小区信息，从而导致系统发出切换指令，使得某些处于专用模式下的UE频频尝试向实际信号并不好的越区覆盖小区发出切换请求，必然造成切换失败（也可能是乒乓切换）。
优化方法：从规划以及优化方面来避免同频同扰码小区越区覆盖现象。
主要是调整频点、扰码或工程参数（天线方位角、俯仰角、天线高度、小区最大发射功率等）。
（3）越区孤岛切换问题在环境比较复杂时，较近小区的信号由于阻挡产生一定损耗，而其他小区可能会从建筑物夹缝中透露出来，形成较强越区孤岛。
由于该区域的小区和越区小区之间不会互配置邻小区，在干扰没有严重到导致下行失步时，UE将不会选择到该小区上，但在服务小区信号较弱时，UE很可能会重选到该越区孤岛上。
当在该小区上通话（建立其他的DPCH也是一样）后，将会导致无法切换从而掉话的现象。
此类问题在切换指标上是无法显示出异常的，主要表现为掉话严重。
优化方法：对发生越区覆盖的小区的天线方向角、俯仰角、小区最大发射功率进行调整，必要时要降低天线高度；如果上述方法均不可行，可添加邻区关系，使切换正常。
（4）目标邻小区负荷过高（或部分传输通道故障），导致切换失败当目标邻小区的负荷过高时，切换将无法完成。
另外，当目标小区的部分传输通道由于误码较高或频繁瞬断时，也会引起切换（选择）失败。
如果是跨RNC，由于源RNC不了解目标RNC的传输故障情况，因此只要有切换请求，就会尝试进行切换执行，而最终导致切换失败，这种情况要持续到源RNC收不到目标小区的测量报告为止。
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配置错误导致切换失败率高问题解决目录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"没有存储的频率质量估计。
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）导致切换流程无法继续。
基于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信令分析，有助于快速进行根因问题定界定位。
共BSC MSC参数设置不当导致小区之间切换困难
共BSC MSC参数设置不当导致小区之间切换困难【现象描述】华为小基站与NT厂家的基站插花组网，某日用户反映在进行路测过程中，发现占用华为的小基站时，向邻区（NT厂家基站）切换困难，在邻区（NT厂家基站）电平已经比服务小区（华为小基站）强很多的情况下，还是不发切换请求。
有时直到掉话也不发生切换。
【处理过程】1、登记切换性能测量，发现该小区有切换请求，同时切换成功率也很高；登记出、入BSC切换性能测量，发现该小区与NT厂家的小区之间能够发生切换。
2、进行路测，发现占用华为小基站，在服务电平达到-80dBm以下时，邻区已经比服务小区强很多，但还是不发生切换。
在服务小区的信号到了-90dBm左右时，有时能够发生切换，并切换成功；但有时由于地形原因，电平下降较快，会一直到最后掉话还不发生切换。
3、经检查，所有相邻小区都做到了小区相邻关系表中，并且 BA1表和BA2表频点设置正确。
4、检查切换相关的参数设置，此小区与其余小区都一样，重点检查影响BSC间小区切换的参数，发现在“切换控制数据表”中的“进行共BSC/MSC调整允许”设置为是，边缘切换和PBGT切换的统计时间和持续时间分别是5秒和4秒。
5、修改“进行共BSC/MSC调整允许”为“否”，调整边缘切换和PBGT的切换统计时间和持续时间为3秒和2秒。
6、再进行路测，发现在手机接收电平较高时就能够发生切换了，路测多次，切换完全正常。
【原因分析】1、这种不发切换请求的问题，首先怀疑是该小区的相邻关系没有做全，或者是BA1表，BA2表中频点不对，检查结果是邻区齐全，频点正确。
2、所有小区都设置为同层同级，共BSC/ MSC调整设为是，层间切换门限为25，层间切换磁滞为3。
3、由于“进行共BSC/MSC调整”设为“是”，在16BIT排序原则中：如果服务小区电平>=层间切换门限-磁滞，即>=－88dBm时，第14位为0，此时的服务小区的第5－10位与邻小区都相同，第12，13，14位全为0；如果服务小区电平< 层间切换门限-磁滞，即<－88dBm时，第14位为1，此时的服务小区的第5－10位与邻小区都相同，第12，13位全为0，第14位为1；如果邻小区电平>=层间切换门限＋磁滞，即>=－82dBm时，第14位为0，此时共BSC的小区的各位情况是第5-10位与服务小区都相同，第12，13，14位为0；不同BSC的情况是5-10位与服务小区都相同，第12位为1，第13，14位为0；如果相邻小区电平< 层间切换门限+磁滞，即<－82dBm时，第14位为1，同时第5-10、12、13位全部置为0，此时共BSC和不共BSC的小区都是第5-10位、12、13位为0，第14位为1。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
故障案
例
参数设置不合理导致ESRVCC切换失败
所属公司
中国移动
贵州省公司
专业网优
设备
类型
ENODEB
设备厂家华为
设备
型号
BTS3900
软件
版本
BTS3900V100R010C10SPC150
编制时间2016年06
月28日
作者
作者
电话
关键字eSRVCC;切换门限
问题现象
在日常KPI 监控发现黔西南LTE小区9WM-黄金大酒店LHB-XD-2 5月27日至5月28日，日均失败236次，影响了黔西南整网ESRVCC切换成功率。
日期小区名称E-UTRAN向GERAN
系统切换切出成
功次数
E-UTRAN向
GERAN系统切换
切出尝试次数
切换成功率失败次数
2016-05-24 9WM-黄金大酒店LHB-XD-2 28 33 0.848484848 5
2016-05-25 9WM-黄金大酒店LHB-XD-2 2 6 0.333333333 4
2016-05-26 9WM-黄金大酒店LHB-XD-2 46 50 0.92 4
2016-05-27 9WM-黄金大酒店LHB-XD-2 41 327 0.125382263 286
2016-05-28 9WM-黄金大酒店LHB-XD-2 62 249 0.248995984 187 问题分析
1.eSRVCC切换信令流程
2、站点故障
3、覆盖问题
4、核心网问题
5、无线侧参数问题
6、终端问题
7、其他
3.干扰排查
从OMCR上面查询LTE小区9WM-黄金大酒店LHB-XD-2 5月23-28日的系统上行每个PRB上检测到的干扰噪声的平均值均在-117左右，不存在干扰情况。
查询相应GSM小区也未发现干扰，故排除干扰原因。
日期小区名称本地小区标识系统上行每个PRB 上检测到的干扰噪声的平均值(毫
瓦分贝)
2016-05-23 9WM-黄金大酒店LHB-XD-2 1 -112.875
2016-05-24 9WM-黄金大酒店LHB-XD-2 1 -112.9583
2016-05-25 9WM-黄金大酒店LHB-XD-2 1 -113
2016-05-26 9WM-黄金大酒店LHB-XD-2 1 -113.1667
2016-05-27 9WM-黄金大酒店LHB-XD-2 1 -113.2917
2016-05-28 9WM-黄金大酒店LHB-XD-2 1 -113.25
4.故障排查
从OMCR上面查询LTE小区以及GSM小区的历史故障告警情况，发现不存在影响业务的告警。
5.覆盖核查
查询5月份MR数据，发现9WM-黄金大酒店LHB-XD-2整体覆盖率在97.24%，不存在大范围弱覆盖，从
mapinfo地图上面查看LTE小区和GSM小区相隔300多米不存在覆盖问题。
小区名参考信号接
收功率采样
点点数
参考信号接
收功率累加
值
大于-110采
样点
MR覆盖率RSRP平均值
9WM-黄金大酒店LHB-XD-2 183479 -16204150 178411 97.24% -88.3161
6.核心网问题核查
将此问题反馈此核心网同事，核心网核查相应参数未发现异常，故排除核心网问题。
7.无线侧参数问题核查
参数中文名现网值
异系统切换触发事件类型EventB2
异系统A1 RSRP触发门限(毫瓦分贝) -100
异系统A2 RSRP触发门限(毫瓦分贝) -105
GERAN切换B2 RSRP门限1(毫瓦分贝) -115
基于覆盖的GERAN触发门限(毫瓦分贝) -100
GERAN CSFB开关开
GERAN外部小区LAC/CI/BCCH/NCC/BCC与现网一致
GERAN相邻频点组开始频点/连接态频率优先级设置正确
最高优先级异系统GERAN异系统
CSFB IDLE态第一优先级目标RAT GERAN异系统
核查参数发现基于覆盖的GERAN触发门限(毫瓦分贝)设置为-100，门限较低，造成9WM-黄金大酒店LHB-XD-2易触发eSRVCC，对GSM侧信号要求低，容易造成切换失败。
参数详解如下：
该参数表示基于覆盖的异系统GERAN切换事件的RSSI触发门限。
当异系统GERAN小区的RSSI测量值达到该门限，且满足其他触发条件时，将触发B1测量报告上报。
参见协议3GPP 36.331。
问题解决情况
将LTE小区9WM-黄金大酒店LHB-XD-2基于覆盖的GERAN触发门限(毫瓦分贝)优化到-88。
优化调整后9WM-黄金大酒店LHB-XD-2 eSRVCC切换成功率提升明显。
总结及优化经验
经过此次的优化可以得出目前eSRVCC的一些切换门限相关的参数设置，还需要现场多番测试，最终得出一个适合当地环境的一个参数值，网管默认值只能作为一个参考。