5G SA语音异常掉落4G：EPS Fallback定位与优化实践

简介：这是一份5G SA语音通话异常掉落到4G问题的处理案例文档，适合5G无线网络优化、核心网维护及通信技术学习者参考。文档以真实外场问题为背景，完整记录了从前台测试LOG、后台NG/UU口信令分析到联合定位的全过程，重点涉及Fast Return流程、随机接入、NR RRC正常释放事件以及核心网UDM信令异常等关键环节，能帮助读者建立前后台联合排查思路。其中呈现了nRMM-cause、normal-release等具体原因值，并给出了核心网修复前后的对比结论。资源为1个docx文件，压缩包大小959KB，内容结构清晰，包含问题现象、信令取证、原因推断与解决措施，适合作为5G SA网络故障分析与优化案例的学习材料。已有206人学习，这类实战案例对处理同类核心网异常释放问题具有直接参考价值。

1. 5G SA语音通话异常掉落到4G：不是所有回落都是故障，但要分清主动与被迫

一个用户在5G SA网络下打着VoNR电话，通话到一半手机右上角的“5G”图标变成了“4G”，网络侧语音承载跟着掉到LTE。很多人第一反应是覆盖不好、基站没信号，但真正做过5G SA网络优化的工程师都知道，这叫EPS Fallback，5G语音呼叫在无VoNR覆盖或业务受限时主动降级到4G用VoLTE续传。问题是，主动回落是设计好的保底策略，异常回落才叫人头疼。本文从信令入手，分清“该回落”和“被迫回落”，给出可复现的图层排查思路、参数核查表和避坑记录，适合刚接手5G SA互操作优化的工程师、以及终端侧的测试人员。

2. 为什么5G SA通话会掉到4G：VoNR回落不是黑匣子

2.1 回落机制的三种形态：呼叫建立回落、通话中掉落、结束后回不来

5G SA网络下，语音呼叫首选的承载是VoNR，走的是5G NR信令面和媒体面。但VoNR并不是在所有场景都能成立，网络侧判断“当前小区不支持VoNR”或“终端能力不满足”，就会触发EPS Fallback，把一个本来应该在5G上建立的IP多媒体子系统语音呼叫，回落到4G上用VoLTE继续。这是3GPP标准里明确设计的机制，不是故障，但它的触发条件和异常触发条件之间只有一线之隔。

我一般把“掉到4G”分成三种形态。第一种是呼叫建立时的EPS Fallback：终端发起VoNR INVITE，核心网在SIP会话建立过程中发现无线侧没有VoNR能力，或者gNB下的5QI=1承载没法建立，于是在呼叫未接通前把终端快速重定向到4G，再由LTE完成VoLTE呼叫。这种回落是“为了保住通话”的主动保底，属于正常流程。第二种是通话进行中的异常掉落：VoNR话还未挂断，终端突然重选或切换到了LTE，语音承载被打断，表现为掉话或通话质量骤降，这是真正的“异常”。第三种则是通话结束之后回不来：被回落到了4G的单卡终端在通话结束后迟迟不返回5G，或者返回失败，导致用户体验是一整天都停在4G上，用户感知是“手机坏了”。

区分这三种形态的关键点在于时间轴：回落发生在呼叫建立之前、正在通话中、还是通话结束之后。标题里说的“异常掉落”，大多数情况下指的是第二种，少数情况下也包含第三种。这也是整个问题处理案例的核心：先判断你的现象属于哪一种，再去翻信令才有意义。

2.2 谁来决定回落：gNB的测量控制、核心网的QoS Flow与终端能力三方博弈

异常回落发生的时候，第一反应通常是“是不是4G信号比5G好”。这有一定道理，但不完整。EPS Fallback的判断不是一个环节说了算，它是gNB、核心网、终端三方共同决定的结果。

先看gNB侧。5G小区上配置了VoNR开关和测量配置。gNB通过RRC重配消息下发测量控制，让终端测量邻区LTE的参考信号接收功率和参考信号接收质量。当终端上报的LTE测量值满足B1事件门限，且当前NR信号进入A2事件（服务小区变差），gNB才会触发重定向或基于测量的切换。注意，这里有一个常被忽略的点：EPS Fallback触发的前提是gNB知道这条语音业务需要走5QI=1的GBR QoS Flow。核心网在NG接口上通过PDU会话修改流程把QoS流信息发给gNB，gNB看到5QI=1才启动整套回落逻辑。如果核心网没下发这个QoS Flow，或者下发成了非GBR的QoS流，gNB根本不会针对语音做任何特殊处理，终端就会自己乱跑。

再来看终端侧。终端内部有VoNR能力标记、5G网络能力、IMS注册状态。如果终端没有成功注册到IMS网络，它发起呼叫时直接选择在4G上起呼，根本不会先走到5G。另一个容易被误判的场景是终端在5G上发起呼叫，但RRC连接里上报的“语音域选择”能力是CS Voice only，终端认为NR不能承载语音，网络侧也会选择回落到4G。所以排查异常掉落时，先查终端是否注册了VoNR，再查网络下发的QoS Flow，最后才查无线测量配置。顺序反了，很容易把一个终端侧的“不愿意用VoNR”问题，当成无线侧“覆盖差导致回落”，白白调几天天线。

3. 定位异常掉落：三层证据一条链路

3.1 第一层：终端信令看RRC重配、RRC Release与EMM Cause

做EPS Fallback问题处理，我第一件事是抓终端侧的信令，不是看网管指标。商用终端可以用工程模式输出日志，测试终端则直接抓路测日志。这个案例的核心证据在两条信令里：一条是NR侧的RRC释放或RRC重配，另一条是切换到4G后终端发起的跟踪区更新和承载建立请求。

终端在5G上被重定向到4G，常见路径是gNB给终端下发“RRC Release with redirectedCarrierInfo”，里面携带LTE频点。这个信令本身是正常的EPS Fallback路径，但你需要看它携带的原因值。如果原因是“voiceServiceNotSupported”，说明gNB判断当前5G小区不支持语音业务，触发回落。如果原因是“loadBalancingTAURequired”或者“otherCause”，就需要确认是不是负荷均衡或者参数配置错误触发了错误回落。

如果异常发生在通话过程中，终端在NR侧会先收到“RRCReconfiguration”消息，里面包含LTE测量配置；随后终端上报测量报告，gNB下发“MobilityFromNRCommand”，执行NR到LTE的切换。这条信令链路上最容易出问题的是切换准备阶段的“HandoverPreparationFailure”——gNB向目标LTE基站发起切换请求，LTE侧回失败，终端按配置执行不了切换，只能在原小区保持直到无线链路失败，最终掉话。判断异常掉落到4G是不是无线链路失败导致的，重点看终端日志里有没有NR侧的“RLF”标志和“SCGFailureInformation”。这两个标志经常被当作普通切换失败忽略，其实它们是掉话的直接原因。

上面这段逻辑可以用一段简单脚本来验证：解析终端导出的信令日志文本，按时间顺序筛选出与EPS Fallback相关的消息类型，定位关键事件的时间点和原因值。

import re log_file = "ue_signal_log.txt" # 终端导出的信令文本日志 patterns = { "rrc_release": r"RRCRelease.*?redirectedCarrierInfo.*?(\d+)", "rrc_reconfig": r"RRCReconfiguration.*?MeasConfig.*?(\d+)", "mobility": r"MobilityFromNRCommand.*?(targetCarrierFreq|targetPhysCellId).*?(\d+)", "ta_u": r"TAU.*?(ACCEPT|REJECT).*?(EPS attach type|IMSI)", "bearer": r"Activate.*?Dedicated.*?EPS bearer.*?QCI[=: ](\d+)" } for msg_type, pattern in patterns.items(): matches = re.findall(pattern, log_file, re.DOTALL) print(f"{msg_type}: {len(matches)} 次触发") for m in matches[:5]: print(" ->", m)

这段脚本只是演示解析逻辑，实战中我更推荐直接把日志导入Wireshark或厂商自带的信令分析工具，按LTE RRC、NR RRC、NAS消息三个协议分层过滤。核心参数是QCI值——从4G侧看到专用承载建立时QCI=1，说明语音承载成功建立；如果只建立了QCI=5，说明IMS信令走了但媒体承载没建立，问题在核心网侧。

3.2 第二层：gNB网管看A2事件、B1事件和切换失败计数器

终端侧信令能看出“发生了什么”，但要看“为什么发生”，还得回到gNB网管上核对测量配置和切换执行结果。

每个gNB厂商的网管里都有一张EPS Fallback统计表，字段包括：触发回落次数、回落方式（重定向或切换）、回落目标频点、B1测量上报次数、A2测量上报次数、NR到LTE切换尝试次数和切换失败次数。做案例复盘时，我一般把四个数字摆在一起看：VoNR呼叫建立请求次数、5QI=1 QoS Flow建立成功次数、B1上报次数、EPS Fallback执行次数。

如果“5QI=1 QoS Flow建立成功次数”明显低于“VoNR呼叫请求次数”，说明核心网在NG接口上就没有给gNB下发语音QoS Flow，gNB根本没走到回落逻辑这一层，问题在核心网配置。如果“B1上报次数”很高但“EPS Fallback执行次数”很低，说明终端一直在上报LTE邻区测量，但gNB没有执行回落或执行后被取消，重点查切换准备阶段LTE侧返回的失败原因。如果反过来，“B1上报次数”很低但“EPS Fallback执行次数”很高，说明gNB大概率配置的是盲重定向，没有依赖测量直接回落，这是一种省力的回落方式，但在LTE信号差的小区极容易掉话。

我习惯在这个环节把gNB网管数据导出成CSV，然后用脚本找出“上报了B1但没执行回落”的小区清单，按次数排序。这类清单比单独看一个基站的均值有用得多，因为它能暴露配置漏配的问题：比如某个站点开通了VoNR但邻区关系表里没配LTE邻区，终端拿到测量控制也测不到目标小区。

3.3 第三层：核心网侧看IMS注册状态、P-CSCF地址和SIP信令

第三层是很多人会漏掉的一层。EPS Fallback落到4G以后，呼叫能不能续上，取决于终端在4G侧的VoLTE能力。如果终端在5G SA下注册IMS用的P-CSCF地址和4G VoLTE注册用的P-CSCF地址不一致，或者终端从5G回落到4G后没有重新发起VoLTE注册，那语音呼叫就会在SIP信令层失败。

查看核心网侧关键字段，我用一张速查表：

在核心网网元上看SIP信令的方法各厂商不太一样，但通用做法是按用户号码在IMS网元的信令跟踪模块里拉取会话详情，然后对照INVITE时间戳和无线侧回落时间戳，若间隔超过某阈值（我一般看3秒），说明回落之后注册和呼叫流程卡了某一步。这里多说一句，终端从5G回落4G后会触发TAU，如果TAU拒绝，终端会进入有限服务状态或重新附着，语音必然起不来，优先级比查SIP消息还高。

4. 从参数上根治异常掉落：可落地的配置核查

4.1 核查清单：VoNR开关、回落策略与邻区关系

定位到问题原因后，改参数是最后一步。先列一份我每次处理EPS Fallback异常都会过的核查清单，按从上到下的顺序执行，不要跳：

这里面最容易翻车的是第3项和第4项。B1事件门限的意思是，当LTE邻区信号满足该门限时，终端上报测量报告，gNB据此决定是否回落。如果门限设置太低，终端要等到LTE信号很好才上报，此时5G侧可能已经弱到语音承载崩了；如果门限设置太高，终端在5G侧信号还不错时就上报LTE测量，gNB提前把通话切到4G，用户感知是“5G信号明明满格却掉到4G”。我的经验是初始门限设置为-110dBm左右，再根据现场测试结果每次调整2dB，不要大步改。

邻区关系漏配的坑更隐蔽。5G站点开通后，互操作邻区经常只配了同站的LTE小区，跨站邻区没配。终端在5G弱场收到测量控制，但测量对象里没有目标LTE频点，或者有频点没有邻区关系，B1事件永远不触发，最终只能靠小区重选掉到4G，语音全断。核查邻区关系的命令依厂商而异，但思路都是把gNB维护的E-UTRA邻区表和各LTE基站的实际工参表拉出来比对，缺失的补进去。

4.2 回落策略参数：重定向与切换的适用场景

EPS Fallback有两种实现：基于重定向的回落和基于切换的回落。区别在于，重定向只是告诉终端“去4G”，终端到4G后要重新随机接入、发起TAU和业务请求，时延更大，但实现简单，不需要预先把上下文传给4G。切换则是先和目标LTE基站完成切换准备，终端直接切过去，语音承载可无缝续传，但依赖于邻区测得准、切换准备成功率高。

选择策略的通用说法是：覆盖连续性好、LTE邻区关系完整的城区，用基于测量的切换；LTE覆盖未知、补邻区来不及的站点，先开重定向兜底，再逐步替换成切换。5G SA语音通话异常掉落的案例里，我最常遇到的配置错误是“所有小区统一用重定向”，结果在LTE邻区信号很好的位置也触发盲重定向，导致不少用户回落后VoLTE呼叫重建时间过长。

# 以某厂商网管命令行为例：查看小区EPS Fallback策略 show eps_fallback_policy mrbts_id=1001 # 期望输出中 FallbackType 字段应为 MeasHO(基于测量切换) # 若显示 BlindRedirection，说明当前为盲重定向配置 # 修改命令（实际生产中使用厂商专用MML/网管操作）： # set eps_fallback_policy mrbts_id=1001 fallback_type=MeasHO # set b1_event_threshold mrbts_id=1001 threshold_rsrp=-110

上面这段命令是示意写法，不同厂商的关键字不一样，但核心逻辑是可迁移的：第一，先把回落类型从盲重定向改成基于测量的切换，前提是邻区关系已补齐；第二，把B1门限设成与路测结果匹配的值。改完不能只做单站验证，要看一个区域内所有有EPS Fallback需求的小区是否批量生效。

4.3 FastReturn参数：通话结束后要不要回5G

还有一类“掉到4G”的用户感知问题不是发生在通话中，而是通话挂断后。终端被EPS Fallback到LTE后，媒体承载被释放，若网络没有下发NR测量控制，终端会一直驻留在4G，直到数分钟后的周期性测量或小区重选才返回5G。对用户来说，就是“打了一个VoLTE电话，手机就一直4G了”。

FastReturn机制的实现也分两类：基于网络辅助的快速返回和基于终端自主搜索的返回。前者是gNB在通话结束后主动向终端下发NR频点测量配置，终端测量到5G小区信号后重选回SA；后者是终端自己做异系统频点搜索。实操中只建议依赖网络辅助的返回，因为终端自主搜索不可控，费电且慢。

在参数侧，FastReturn需要检查两个点：一是“通话结束后回落释放的RRC连接是否携带了NR频点”；二是“fastReturn门限是否高于5G最小接入电平”。如果门限低于5G最小接入电平，终端测到5G信号但接入失败，表现为“返回5G后立刻又掉回4G”。这个现象在网管上很难看出来，得用终端日志复测才抓得到。

5. 避坑：5次常见的“5G SA掉4G”误判与踩坑记录

5.1 现象：gNB没有下发回落，终端却自己掉到了4G

有次处理一个投诉，用户在5G SA网络下通话，信令跟踪里看不到gNB下发任何与LTE测量或重定向相关的配置，但终端日志里频繁出现“RRC_CONNECTION_REESTABLISHMENT”失败，随后终端自行重选到了4G。查遍gNB参数都是正常的，最后发现是终端在NR侧的无线链路失败，触发RLF定时器，释放后重选到LTE。原因不是EPS Fallback，而是5G弱覆盖下的链路失败。

这个案例给我的教训是：不能看到终端到了4G就默认是网络触发回落。必须先区分是网络下发的重定向/切换到了4G，还是无线链路失败后的终端自主重选。看信令时，前者有明确的RRCRelease携带redirection信息或MobilityFromNRCommand，后者则是RLF指示之后终端自己选的LTE小区。排序在问题分类里排第一位，不要混淆。

5.2 现象：回落成功但VoLTE起呼失败，终端卡在“正在呼叫”

回落成功不代表呼叫成功。终端从5G回落到4G后，要完成TAU、EPS默认承载建立、IMS注册刷新，然后才能发起VoLTE呼叫。某次实际处理时，EPS Fallback成功率指标是100%，但语音接通率掉了一半，查下来是终端回落后在4G上发起的TAU不携带“active flag”，核心网为终端建立的默认承载不带ims APN，导致后续INVITE消息无法走到IMS网元。

原因是终端侧“在NR保持的PDN连接和EPS承载上下文映射”在回落过程中丢失，核心网的MME侧也没有保留该上下文。解决方式是让核心网开启“扩展的EPS回落承载保持”功能，或者调整TAU请求中的“ESM message container”处理策略。排查这类问题，不能只看无线侧回落是否成功，要在核心网上确认回落后的默认APN是不是ims。

5.3 现象：通话质量很好，但电话一挂就再也回不到5G

这次现象是通话全程VoNR不掉话，挂断后终端一直留在4G，最久一次20分钟没返回5G。gNB侧FastReturn统计显示“返回成功次数”很高，但用户实际没回去。抓终端日志才发现，网络确实下发了“RRCRelease with redirectedCarrierInfo”携带NR频点，但终端对该频点的测量结果低于“s-NonIntraSearch”，触发不了频内重选测量，于是终端一直驻留在4G。

原因是FastReturn下发的NR频点优先级没有被终端识别为“高优先级”，或者下发的频点列表缺少该站点的实际工作频点。解决方式是把FastReturn的重定向频点跟5G工参的频点逐一核对，并检查配置项里的“优先级”参数是否高于当前LTE频点优先级。不要把“网络侧下发成功”和“终端成功驻留”混为一谈，两件事中间还有一次测量行为。

5.4 现象：B1事件上报了，但回落迟迟不执行，直到掉话

终端在通话过程中上报B1事件，说明LTE邻区信号已满足门限，但gNB没有立即触发回落。等待几秒后，NR侧信号继续恶化，无线链路失败，通话中断。这个案例里B1门限本身没问题，问题出在“测量报告延迟”上，即从终端上报到gNB下发切换命令的时间过长，常见原因是测量间隙和上行资源不足，gNB没有及时调度终端的上行测量报告。

解决方向是缩短gNB侧测量报告到切换命令之间的定时器，并且核查MAC层调度器的上行资源分配策略。另一种常见原因是终端配置了“非连续接收”，DRX周期过长导致上行报告延迟。排查时做一次“关闭DRX”的对比测试，若问题消失，说明是DRX与测量调度的冲突。这不是改一个参数就完事，要和终端的省电策略一起权衡。

5.5 现象：全网指标看EPS Fallback占比过高，但实际都是正常回落

某次分析报表，全网VoNR呼叫建立成功率高，但“EPS Fallback占比”从10%涨到40%，被当作异常事件上报。拉明细分析后，大部分回落发生在VoNR覆盖边缘小区，属于正常保底回落，问题只是口径统计里包含了“非VoNR覆盖区域的呼叫”，没有做场景细分。

处理方式是建立“可避免回落率”指标：分母是VoNR覆盖区域的呼叫建立请求，分子是该区域内因参数或切换失败触发的异常回落。只有可避免回落率异常升高才值得开专题分析。指标口径不做细分，很容易被总占比误导，浪费一个周期查参数，最后发现是覆盖规划本来就该落到4G完成呼叫。

6. 一个话单定位的完整排障顺序：把案例从“看现象”收敛到“改参数”

把这套流程收拢到一个具体场景里。某日抽查SEQ话单，发现A片区的5G SA语音呼叫有12%在接通前发生了到LTE的回落，其中又有一半在回落后的4G侧迟迟建立不了语音专用承载，用户侧听感是“响铃前就断了”。

第一步，我在SEQ话单里按“主叫号码+时间”拉出某一次失败呼叫的完整流程。从无线侧RRC连接建立，到NG接口PDU会话建立，再到IMS INVITE。用脚本把话单里的关键时间戳提取出来，看是哪一段耗时最大：

import json with open("seq_call_record.json", "r", encoding="utf-8") as f: call = json.load(f) timeline = {} for event in call["events"]: name = event["event_name"] ts = event["timestamp"] if name in ["RRCSetupComplete", "PDUSessionSetup", "RRCRelease_Redirect", "TAU_Request", "EPSBearerSetup", "SIP_INVITE"]: timeline[name] = ts if "RRCRelease_Redirect" in timeline and "TAU_Request" in timeline: fallback_gap = timeline["TAU_Request"] - timeline["RRCRelease_Redirect"] print(f"回落至TAU间隙: {fallback_gap} ms")

打印结果里“RRCRelease_Redirect到TAU_Request”间隙达到3.8秒，这远超我经验里的1秒左右。第二步，回到gNB网管查该用户在回落前所在小区的B1事件上报情况，发现该小区上报次数稀少但回落次数多，这意味着回落不带测量，属于盲重定向。第三步，查核查清单里的邻区关系，发现小区配置了好几个LTE频点但漏配了目标宏站的PCI，而宏站恰恰是该片区唯一一个覆盖连续的LTE层。

第四步，修改参数：把该小区回落策略从盲重定向改成基于测量的切换，补齐LTE邻区关系，B1门限从-115dBm调整到-110dBm，同时打开FastReturn开关，并确保NR频点优先级高于LTE。改完当天复测10次呼叫，8次VoNR直接成功，2次发生EPS Fallback但回落间隙小于800毫秒，语音接通正常。一周后该片区“回落前掉话”计数清零。

这套流程里最关键的习惯是把时间戳按事件串起来看，而不是看平均指标。平均指标只告诉你“有没有问题”，时间戳链路告诉你“问题卡在哪一段”。从RRC释放到TAU之间的时间一旦超过1.5秒，先怀疑盲重定向或者邻区漏配，比反复调天线位置有效得多。处理这类互操作案例多了以后，我养成了先看回落路径、再查参数、最后才调整覆盖的习惯。无线覆盖是最后一张牌，不要一上来就动它。这一套逻辑也希望能帮到你，少走几步我曾经走过的弯路。

本文还有配套的精品资源，点击获取