简介这是一份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 Fallback5G语音呼叫在无VoNR覆盖或业务受限时主动降级到4G用VoLTE续传。问题是主动回落是设计好的保底策略异常回落才叫人头疼。本文从信令入手分清“该回落”和“被迫回落”给出可复现的图层排查思路、参数核查表和避坑记录适合刚接手5G SA互操作优化的工程师、以及终端侧的测试人员。2. 为什么5G SA通话会掉到4GVoNR回落不是黑匣子2.1 回落机制的三种形态呼叫建立回落、通话中掉落、结束后回不来5G SA网络下语音呼叫首选的承载是VoNR走的是5G NR信令面和媒体面。但VoNR并不是在所有场景都能成立网络侧判断“当前小区不支持VoNR”或“终端能力不满足”就会触发EPS Fallback把一个本来应该在5G上建立的IP多媒体子系统语音呼叫回落到4G上用VoLTE继续。这是3GPP标准里明确设计的机制不是故障但它的触发条件和异常触发条件之间只有一线之隔。我一般把“掉到4G”分成三种形态。第一种是呼叫建立时的EPS Fallback终端发起VoNR INVITE核心网在SIP会话建立过程中发现无线侧没有VoNR能力或者gNB下的5QI1承载没法建立于是在呼叫未接通前把终端快速重定向到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知道这条语音业务需要走5QI1的GBR QoS Flow。核心网在NG接口上通过PDU会话修改流程把QoS流信息发给gNBgNB看到5QI1才启动整套回落逻辑。如果核心网没下发这个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: rRRCRelease.*?redirectedCarrierInfo.*?(\d), rrc_reconfig: rRRCReconfiguration.*?MeasConfig.*?(\d), mobility: rMobilityFromNRCommand.*?(targetCarrierFreq|targetPhysCellId).*?(\d), ta_u: rTAU.*?(ACCEPT|REJECT).*?(EPS attach type|IMSI), bearer: rActivate.*?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侧看到专用承载建立时QCI1说明语音承载成功建立如果只建立了QCI5说明IMS信令走了但媒体承载没建立问题在核心网侧。3.2 第二层gNB网管看A2事件、B1事件和切换失败计数器终端侧信令能看出“发生了什么”但要看“为什么发生”还得回到gNB网管上核对测量配置和切换执行结果。每个gNB厂商的网管里都有一张EPS Fallback统计表字段包括触发回落次数、回落方式重定向或切换、回落目标频点、B1测量上报次数、A2测量上报次数、NR到LTE切换尝试次数和切换失败次数。做案例复盘时我一般把四个数字摆在一起看VoNR呼叫建立请求次数、5QI1 QoS Flow建立成功次数、B1上报次数、EPS Fallback执行次数。如果“5QI1 QoS Flow建立成功次数”明显低于“VoNR呼叫请求次数”说明核心网在NG接口上就没有给gNB下发语音QoS FlowgNB根本没走到回落逻辑这一层问题在核心网配置。如果“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信令层失败。查看核心网侧关键字段我用一张速查表检查项关键字段正常判据IMS注册P-CSCF address, IMS APN5G和4G注册的P-CSCF均可达默认承载APN, PDN type使用ims APNPDN类型IPv4或IPv6语音承载QCI1, ARP1回落后的专用承载建立成功SIP消息INVITE 180/183/200 OK呼叫流程完整未被30x打断TAUTAU accept, EPS attach result回落后的TAU成功完成在核心网网元上看SIP信令的方法各厂商不太一样但通用做法是按用户号码在IMS网元的信令跟踪模块里拉取会话详情然后对照INVITE时间戳和无线侧回落时间戳若间隔超过某阈值我一般看3秒说明回落之后注册和呼叫流程卡了某一步。这里多说一句终端从5G回落4G后会触发TAU如果TAU拒绝终端会进入有限服务状态或重新附着语音必然起不来优先级比查SIP消息还高。4. 从参数上根治异常掉落可落地的配置核查4.1 核查清单VoNR开关、回落策略与邻区关系定位到问题原因后改参数是最后一步。先列一份我每次处理EPS Fallback异常都会过的核查清单按从上到下的顺序执行不要跳序号配置项所在网元检查点1VoNRSwitchgNB必须为“开”且语音承载5QI1允许建立2EPSFallbackPolicy核心网AMF/gNB重定向或切换策略是否按场景选对3MeasurementConfiggNBB1事件门限是否过低/过高4LTE邻区关系gNB目标E-UTRA频点和PCI是否漏配5RedirectionCarrierInfogNB重定向目标频点是否配置6FastReturnSwitchgNB通话结束后是否允许返回5G7IMSAPN配置核心网PGW/UPF是否允许在LTE侧建立默认承载8P-CSCF地址核心网IMS是否可达且为终端可路由地址这里面最容易翻车的是第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_id1001 # 期望输出中 FallbackType 字段应为 MeasHO(基于测量切换) # 若显示 BlindRedirection说明当前为盲重定向配置 # 修改命令实际生产中使用厂商专用MML/网管操作 # set eps_fallback_policy mrbts_id1001 fallback_typeMeasHO # set b1_event_threshold mrbts_id1001 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, encodingutf-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秒先怀疑盲重定向或者邻区漏配比反复调天线位置有效得多。处理这类互操作案例多了以后我养成了先看回落路径、再查参数、最后才调整覆盖的习惯。无线覆盖是最后一张牌不要一上来就动它。这一套逻辑也希望能帮到你少走几步我曾经走过的弯路。本文还有配套的精品资源点击获取