2024年10月21日发(作者：廖星津)
案例1：异频重定向掉话案例
【问题描述】
主叫占用广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）小区通
话时，信号强度为-101dbm左右，出现一次RRC Connection Release，导致承载拆除，引起一
次主叫掉话。
【问题分析】
分析测试数据，发现UE占用服务小区广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100
PCI=83CELLID=135693）在通话的过程中信号越来越差，之后上报测量报告A2事件，eNODEB
收到报告后发起异频重定向判决，下发RRC Connection Release，由异频重定向后，eNodeB
向MME发送ue context release request，mme释放专用承载。当UE被重定向后在新的小区
发起RRC连接，网络只建立了默认承载，UE发送BYE消息，导致掉话。
从地理环境上看，服务小区与UE重定向目标小区相距较远，不需配邻区关系，UE在该路段
仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。
【解决方案】
关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。
【问题总结】
根据拉网统计，目前该类掉话占总掉话次数的80%以上，对测试指标影响非常严重。
异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切
换到邻区，基站会给UE下发系统内重定向。
优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大
优化力度。
后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，
禁止专用承载的业务发生异频重定向。
。
案例2：异系统重定向掉话案例
【问题描述】
VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。而CCO对于
VoLTE语音来说，必然导致掉话。
【问题分析】
具体如下图所示。
1. 对于PSHO、CCO、重定向，优先级为PSHO>CCO>重定向。那么现在的问题就是eSRVCC
过程执行的为什么是CCO而不是PSHO。
2. 重点排查的就是eSRVCC相关配置：
（1）eSRVCC功能开关：未发现问题。
（2）系统间邻区配置：
a. GSM邻区配置：重点查看“PS切换能力”配置的是否为：“是[1]”。PS切换能
力表示GSM邻区的PS HO能力。当GSM邻区支持PS HO能力，服务小区可以
向该邻区发起PS切换。未发现错误。
b. GSM邻区关系: 重点查看“支持切换”配置的是否为“支持[1]”。是否“支持
切换”代表服务小区是否支持向GERAN邻区发起切换的指示。发现配置的是“不
支持”。问题就在这里。如下图所示。
【解决方案】
修改GSM邻区关系中，支持切换为“支持[1]”后，在进行eSRVCC切换，eSRVCC切换
成功，VoLTE未出现掉话。
【问题总结】
对于VoLTE语音来说，无论是系统内还是系统间eSRVCC，只要执行的不是“切换”都
会导致语音的掉话，包括重定向和CCO。因此，需要开通的时候，保持GSM邻区配置和GSM
邻区关系配置正确，严格按照中兴的VoLTE开通指导书来执行。
案例3：切换过程中专载被MME释放
【问题描述】
主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，专载刚刚建立完成又在切
换过程中被释放，终端回复invite580，呼叫未接通。
【问题分析】
1、主叫收到invite183消息并建立专载，但在专载建立前主叫已上报A3测报，所以几
乎在主叫上发承载建立成功的NAS消息的同时（10:19:29.959），主叫收到了基站下发的切换
重配消息，消息中包含释放QCI1的信息：
2、再看基站侧信令，基站收到终端上报的A3测报后，从源小区发给MME的
HandoverRequired里面，有三条承载，分别是QCI9/QCI5/QCI1：
3、从MME发给目标小区的HandoverRequest消息里面e_RABInformationList有三条承
载，但是e_RABToBeSetupListHOReq里面只有两条，少了QCI1的：
4、由于HandoverRequest消息的e_RABToBeSetupListHOReq里面只有两条承载，所以目
标小区回给MME的HandoverRequestAcknowledge消息里面，也只有两条承载：
5、那么，在MME回给源小区的HandoverCommand里面ToAdd两条承载QCI9和QCI5，
Release了QCI1的承载，这就导致专载被释放并导致未接通：
终端专载建立成功后上发NAS消息给MME，但由于切换流程在前，MME收到NAS消
息之前，MME已经发给目标小区的HandoverRequest消息，里面e_RABToBeSetupListHOReq
少了QCI1的承载，所以Release QCI1的承载。
【解决方案】
开启X2接口，使用X2接口减少流程冲突导致的专载丢失。根据外省及深圳的经验，开
启X2后此类问题概率大大减少。
需要对专载建立过程中的切换流程进行优化。
需要检查相关参数配置是否合理。
【问题总结】
VoLTE业务关系RRC层信令、S1信令、X2信令、NAS消息，SIP信令，需要综合考虑问
题。
案例4：eSRVCC至2G掉话
【问题描述】
在集团测试网格9 LOG中，eSRVCC至2G导致掉话的事件，表现为呼叫建立后，由于
达到异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置命令，但在2G侧切入
失败，随后呼叫中止，出现掉话事件。
【问题分析】
1、主叫11:19:48.222正常起呼，流程正常，在11:19:53.241发出SIP ACK，且在11:19:49.931
时刻在小区PCI 373配B2门限 如下图
2、主叫终端在11:20:05.224时刻上报测量，如下图，2G信号约为-94，达到B2门限
3、eNB基站在14:47:05.517下发MoblityFromEUTRACommand，内容如下：
4、eSRVCC至2G后，在11:20:06.527掉话；切换失败原因为：Radio link failure 无线链路失
败，2G的无线环境较差导致。
总的来说，4G流程正常且已正常建立会话，eSRVCC切换至GSM，2G小区信号较差，
切换失败，导致掉话。
【解决方案】
1、eSRVCC配置的B2门限 GSM的RSSI是-95，设置不合理，修改B2门限；
2、检查2G邻区配置是否合理
【问题总结】
开通VoLTE业务的情况，部分4G覆盖不好的地方，需要2G信号来补充，因此，需要
合理正确的配置2G邻区，以及设置合理的4G切换2G的门限。
案例5：无线链路失败的掉话
【问题描述】
主叫RRC重建被拒后，重新发起RRC建立，网络侧下发的RRC重配携带QCI 9和QCI 5，
QCI 1丢失，导致掉话。
【问题分析】
1、主叫11:21:17.428发INVITE，11:21:24.266回ACK，会话建立。
Call Id = 649147781_175370312@2409:8809:8280:99:4e62:643d:cff7:9d9d
主叫11:22:45.670收到网络侧的bye，Reason: SIP;cause=503
2、被叫11:21:24.421 收到ACK，会话建立。
SIP Call ID = p65543t1428981679m222868c482102s4
被叫11:22:39.129上报B2，没有进行eSRVCC，怀疑eNodeB未收到，或者eNodeB收到
了下发切换命令后终端未收到
被叫11:22:40.419 发A3 ，但是没有切换，目标小区未配为服务小区的邻区，上行eNodeB
未收到或eNodeB收到了下发切换命令终端未收到。后服务小区信号质量变差，UE掉线释
放上下文
被叫所在小区的eNodeB ID 173045，TAC 9450，Physical cell ID = 409
3、11:22:44.913 rrcConnectionReestablishmentRequest,重建拒绝之后，由于有数据要上传，
UE重新建立了RRC，但是由于mme上下文被释放，网络侧无法恢复建立QCI=1专载，根据
芯片的实现，终端向网络侧发送SIP BYE发起拆线，判决掉话。
11:22:45.860发bye到网络侧，会话掉话
【解决方案】
1、基础网络优化，减少网络弱覆盖，增强网络信号质量；
2、考虑优化上下文释放机制，尽量重建后能够恢复专用承载。
【问题总结】
VoLTE业务不同于普通的数据业务（默认承载），一旦释放上下文后，专用承载将无法
恢复，导致掉话。需要重点优化网络质量，减少eNB判决掉线。
2024年10月21日发(作者：廖星津)
案例1：异频重定向掉话案例
【问题描述】
主叫占用广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）小区通
话时，信号强度为-101dbm左右，出现一次RRC Connection Release，导致承载拆除，引起一
次主叫掉话。
【问题分析】
分析测试数据，发现UE占用服务小区广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100
PCI=83CELLID=135693）在通话的过程中信号越来越差，之后上报测量报告A2事件，eNODEB
收到报告后发起异频重定向判决，下发RRC Connection Release，由异频重定向后，eNodeB
向MME发送ue context release request，mme释放专用承载。当UE被重定向后在新的小区
发起RRC连接，网络只建立了默认承载，UE发送BYE消息，导致掉话。
从地理环境上看，服务小区与UE重定向目标小区相距较远，不需配邻区关系，UE在该路段
仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。
【解决方案】
关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。
【问题总结】
根据拉网统计，目前该类掉话占总掉话次数的80%以上，对测试指标影响非常严重。
异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切
换到邻区，基站会给UE下发系统内重定向。
优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大
优化力度。
后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，
禁止专用承载的业务发生异频重定向。
。
案例2：异系统重定向掉话案例
【问题描述】
VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。而CCO对于
VoLTE语音来说，必然导致掉话。
【问题分析】
具体如下图所示。
1. 对于PSHO、CCO、重定向，优先级为PSHO>CCO>重定向。那么现在的问题就是eSRVCC
过程执行的为什么是CCO而不是PSHO。
2. 重点排查的就是eSRVCC相关配置：
（1）eSRVCC功能开关：未发现问题。
（2）系统间邻区配置：
a. GSM邻区配置：重点查看“PS切换能力”配置的是否为：“是[1]”。PS切换能
力表示GSM邻区的PS HO能力。当GSM邻区支持PS HO能力，服务小区可以
向该邻区发起PS切换。未发现错误。
b. GSM邻区关系: 重点查看“支持切换”配置的是否为“支持[1]”。是否“支持
切换”代表服务小区是否支持向GERAN邻区发起切换的指示。发现配置的是“不
支持”。问题就在这里。如下图所示。
【解决方案】
修改GSM邻区关系中，支持切换为“支持[1]”后，在进行eSRVCC切换，eSRVCC切换
成功，VoLTE未出现掉话。
【问题总结】
对于VoLTE语音来说，无论是系统内还是系统间eSRVCC，只要执行的不是“切换”都
会导致语音的掉话，包括重定向和CCO。因此，需要开通的时候，保持GSM邻区配置和GSM
邻区关系配置正确，严格按照中兴的VoLTE开通指导书来执行。
案例3：切换过程中专载被MME释放
【问题描述】
主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，专载刚刚建立完成又在切
换过程中被释放，终端回复invite580，呼叫未接通。
【问题分析】
1、主叫收到invite183消息并建立专载，但在专载建立前主叫已上报A3测报，所以几
乎在主叫上发承载建立成功的NAS消息的同时（10:19:29.959），主叫收到了基站下发的切换
重配消息，消息中包含释放QCI1的信息：
2、再看基站侧信令，基站收到终端上报的A3测报后，从源小区发给MME的
HandoverRequired里面，有三条承载，分别是QCI9/QCI5/QCI1：
3、从MME发给目标小区的HandoverRequest消息里面e_RABInformationList有三条承
载，但是e_RABToBeSetupListHOReq里面只有两条，少了QCI1的：
4、由于HandoverRequest消息的e_RABToBeSetupListHOReq里面只有两条承载，所以目
标小区回给MME的HandoverRequestAcknowledge消息里面，也只有两条承载：
5、那么，在MME回给源小区的HandoverCommand里面ToAdd两条承载QCI9和QCI5，
Release了QCI1的承载，这就导致专载被释放并导致未接通：
终端专载建立成功后上发NAS消息给MME，但由于切换流程在前，MME收到NAS消
息之前，MME已经发给目标小区的HandoverRequest消息，里面e_RABToBeSetupListHOReq
少了QCI1的承载，所以Release QCI1的承载。
【解决方案】
开启X2接口，使用X2接口减少流程冲突导致的专载丢失。根据外省及深圳的经验，开
启X2后此类问题概率大大减少。
需要对专载建立过程中的切换流程进行优化。
需要检查相关参数配置是否合理。
【问题总结】
VoLTE业务关系RRC层信令、S1信令、X2信令、NAS消息，SIP信令，需要综合考虑问
题。
案例4：eSRVCC至2G掉话
【问题描述】
在集团测试网格9 LOG中，eSRVCC至2G导致掉话的事件，表现为呼叫建立后，由于
达到异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置命令，但在2G侧切入
失败，随后呼叫中止，出现掉话事件。
【问题分析】
1、主叫11:19:48.222正常起呼，流程正常，在11:19:53.241发出SIP ACK，且在11:19:49.931
时刻在小区PCI 373配B2门限 如下图
2、主叫终端在11:20:05.224时刻上报测量，如下图，2G信号约为-94，达到B2门限
3、eNB基站在14:47:05.517下发MoblityFromEUTRACommand，内容如下：
4、eSRVCC至2G后，在11:20:06.527掉话；切换失败原因为：Radio link failure 无线链路失
败，2G的无线环境较差导致。
总的来说，4G流程正常且已正常建立会话，eSRVCC切换至GSM，2G小区信号较差，
切换失败，导致掉话。
【解决方案】
1、eSRVCC配置的B2门限 GSM的RSSI是-95，设置不合理，修改B2门限；
2、检查2G邻区配置是否合理
【问题总结】
开通VoLTE业务的情况，部分4G覆盖不好的地方，需要2G信号来补充，因此，需要
合理正确的配置2G邻区，以及设置合理的4G切换2G的门限。
案例5：无线链路失败的掉话
【问题描述】
主叫RRC重建被拒后，重新发起RRC建立，网络侧下发的RRC重配携带QCI 9和QCI 5，
QCI 1丢失，导致掉话。
【问题分析】
1、主叫11:21:17.428发INVITE，11:21:24.266回ACK，会话建立。
Call Id = 649147781_175370312@2409:8809:8280:99:4e62:643d:cff7:9d9d
主叫11:22:45.670收到网络侧的bye，Reason: SIP;cause=503
2、被叫11:21:24.421 收到ACK，会话建立。
SIP Call ID = p65543t1428981679m222868c482102s4
被叫11:22:39.129上报B2，没有进行eSRVCC，怀疑eNodeB未收到，或者eNodeB收到
了下发切换命令后终端未收到
被叫11:22:40.419 发A3 ，但是没有切换，目标小区未配为服务小区的邻区，上行eNodeB
未收到或eNodeB收到了下发切换命令终端未收到。后服务小区信号质量变差，UE掉线释
放上下文
被叫所在小区的eNodeB ID 173045，TAC 9450，Physical cell ID = 409
3、11:22:44.913 rrcConnectionReestablishmentRequest,重建拒绝之后，由于有数据要上传，
UE重新建立了RRC，但是由于mme上下文被释放，网络侧无法恢复建立QCI=1专载，根据
芯片的实现，终端向网络侧发送SIP BYE发起拆线，判决掉话。
11:22:45.860发bye到网络侧，会话掉话
【解决方案】
1、基础网络优化，减少网络弱覆盖，增强网络信号质量；
2、考虑优化上下文释放机制，尽量重建后能够恢复专用承载。
【问题总结】
VoLTE业务不同于普通的数据业务（默认承载），一旦释放上下文后，专用承载将无法
恢复，导致掉话。需要重点优化网络质量，减少eNB判决掉线。