5G VONR与EPS FB语音信令详解：从INVITE到回落切换的完整流程

简介这份PPT面向5G网络优化工程师、核心网运维人员及通信专业学习者聚焦VoNR与EPS FB场景下的语音信令流程帮助读者理清5G语音从建立到回落的完整链路。资源包内含1个pptx文件约1.4MB以图文并茂的幻灯片形式呈现便于直接用于培训讲解或自学查阅。内容覆盖VOLTE基础架构与SIP消息交互、EPS FB主叫信令回落流程、FR快速返回机制、VONR简介以及核心网各网元作用并逐条拆解RRC连接建立、QCI承载激活、AAR/AAA策略交互、Invite与183/PRACK/UPDATE等关键信令节点。目前已有693人学习下载适合需要系统梳理5G语音信令、对照流程排查呼叫异常或准备技术面试的读者参考。1. 5G VONR 与 EPS FB当语音通话从 4G 退回到 5G 的那条路你大概率遇到过这种场景5G 手机信号满格一拨电话状态栏的 5G 图标瞬间掉回 4G通话结束又跳回 5G。这不是手机坏了而是网络在做一次 EPS FBEPS Fallback演进分组系统回落。在 5G 独立组网SA早期NR 只承载数据语音要靠 VoNRVoice over New Radio原生解决但 VoNR 的端到端打通涉及核心网、IMS、无线覆盖三层很多网络还没准备好于是 EPS FB 成了过渡期的默认方案。这份《5GVONR EPS FB语音信令详解》要讲的就是这条“5G 发起、4G 落地”的语音信令链路到底怎么走、每一步看什么消息、参数在哪里配、翻车点在哪。适合核心网信令分析、无线优化、IMS 运维的从业者也适合刚接触 5G 语音的工程师按图索骥。2. 从 INVITE 到重定向VoNR 与 EPS FB 的信令分叉点2.1 先分清 VoNR 和 EPS FB 的触发条件VoNR 是 5G SA 架构下语音走 NR 空口、由 5G 核心网5GC和 IMS 直接承载的方案。EPS FB 则是当 UE 在 NR 上发起语音、但网络判断无法提供 VoNR 时通过 NG-RAN 触发切换或重定向到 LTE由 EPC 和 IMS 完成通话。两者的分叉点不在 UE而在网络侧的能力协商。关键判断依据有三条UE 是否在 5GMM 注册时上报了 IMS 语音能力AMF 是否收到 IMS 的 VoNR 支持指示NR 小区是否配置了 VoNR 相关的 QoS 流。任何一条不满足AMF 就会在收到 IMS 的 INVITE 后触发 EPS FB 流程。常见做法是先在 AMF 侧抓 NGAP 消息看PDU Session Resource Setup里有没有 QFI1 的语音承载没有就说明走的是回落。2.2 信令链路逐段拆解从 SIP INVITE 到 LTE 切换完成整条链路可以分成四段IMS 域发起、5GC 决策、NR 触发回落、LTE 完成接入。下面用一段简化的信令流程说明关键节点。UE - IMS: SIP INVITE (语音呼叫发起) IMS - AMF: N1N2 Message Transfer (携带语音 QoS 需求) AMF - gNB: PDU Session Resource Setup / Modify gNB - AMF: 判断无法建立 VoNR 承载返回失败或触发 Handover Required AMF - gNB: Handover Command (目标 LTE 小区) UE - eNB: 切换接入 LTE UE - MME: Tracking Area Update (若需要) MME - IMS: 继续 SIP 会话建立这段流程里最容易被忽略的是N1N2 Message Transfer到PDU Session Resource Setup之间的映射关系。AMF 把 IMS 的语音请求转成 NGAP 消息时会带上 5QI1 的 QoS 参数。如果 gNB 侧没有配置对应的 VoNR 无线承载就会回PDU Session Resource Setup Response带失败原因AMF 据此触发 Handover Required。参数上重点看 5QI、QFI、ARP 三个值5QI1 是语音专用QFI 用来在空口标识这条流ARP 决定抢占优先级。2.3 用 Wireshark 抓 NGAP 和 SIP 的实操步骤抓包是验证信令走向最直接的手段。核心网侧一般在 AMF 的 N2 接口和 IMS 的 Gm 接口做镜像无线侧在 gNB 的 NG 接口抓。# 在 AMF 所在服务器上抓 N2 接口假设网卡为 eth1 tcpdump -i eth1 -s 0 -w amf_n2.pcap port 38412 # 在 IMS 侧抓 SIP 信令假设网卡为 eth0 tcpdump -i eth0 -s 0 -w ims_sip.pcap port 5060 # 用 Wireshark 打开后过滤 NGAP 消息 # 过滤表达式ngap.procedureCode 29 (PDU Session Resource Setup) # 过滤 SIP INVITEsip.Method INVITE抓完后在 Wireshark 里先看 SIP INVITE 的 SDP 里有没有maudio和cIN IP6确认语音媒体协商是否发起。再看 NGAP 的PDU Session Resource Setup Request里QoS Flow Setup Request List是否包含 5QI1。如果只有 5QI9 的默认承载说明语音 QoS 没建起来回落是必然的。参数说明-s 0抓完整包port 38412是 NGAP 的 SCTP 端口port 5060是 SIP 默认端口实际环境可能不同按现场配置改。3. EPS FB 回落过程中的三个关键参数与配置位置3.1 5QI 与 QFI 的映射关系怎么查5QI 是 5G QoS 标识QFI 是 QoS Flow Identifier两者在 PDU 会话里是一对多关系。语音场景下 5QI1 对应 QFI 通常配为 1但不同厂家可能不同。查法是在 AMF 的配置里找qos_flow_mapping表或者在 gNB 的QoS Flow to DRB Mapping里看。# 在 gNB 侧查看 QoS Flow 映射以常见 OAI 配置为例 grep -r qos_flow /etc/oai/gnb.conf # 输出示例 # qos_flow_mapping [ # { qfi 1, five_qi 1, arp 1 }, # { qfi 9, five_qi 9, arp 9 } # ]如果 QFI1 没有出现在映射表里gNB 收到 AMF 的语音承载请求时会直接拒绝EPS FB 就会在PDU Session Resource Setup阶段失败。参数说明five_qi必须和 AMF 侧一致arp决定在资源紧张时能否抢占其他承载语音一般设 1 到 3。3.2 切换门限与重定向策略的配置差异EPS FB 有两种落地方式基于切换的 Handover 和基于重定向的 Redirect。切换方式对语音连续性更好但要求 NR 和 LTE 之间有 Xn 或 N2 接口重定向方式实现简单但会有短暂断流。配置位置在 AMF 的handover_type或 gNB 的inter_rat_handover参数里。# 在 AMF 配置中查看回落策略示例 cat /etc/amf/config.yaml | grep -A5 eps_fallback # 输出示例 # eps_fallback: # mode: handover # 可选 handover 或 redirect # target_rat: eutra # voice_centric: true如果mode设为 redirectUE 会先断开 NR 再搜 LTE时延增加 200 到 500 毫秒。语音呼叫对时延敏感建议优先用 handover。参数说明target_rat指定回落目标voice_centric为 true 时网络会优先保障语音承载。3.3 用 QXDM 或核心网日志验证回落是否成功无线侧常用 QXDM 看 UE 的 NAS 和 RRC 消息核心网侧看 AMF 的日志。关键看两条Handover Required是否发出Handover Request Acknowledge是否从目标 eNB 返回。# 在 AMF 日志中过滤 EPS FB 相关事件 grep -E Handover Required|Handover Request|EPS Fallback /var/log/amf/amf.log # 正常流程输出 # [NGAP] Handover Required sent to gNB, targeteNB_001 # [NGAP] Handover Request Acknowledge received from eNB_001 # [NAS] EPS Fallback procedure completed如果只看到Handover Required没有Acknowledge说明目标 LTE 小区没准备好可能是邻区配置缺失或 MME 侧没配 TAI 映射。参数说明targeteNB_001是目标基站标识实际环境按规划改TAI是跟踪区标识NR 和 LTE 的 TAI 要能对应上。4. 避坑与排查EPS FB 信令里最容易翻车的五个点4.1 现象UE 发起呼叫后直接失败没有回落原因IMS 侧没有收到 UE 的 VoNR 能力上报或者 AMF 的voice_support开关没开。解决检查 UE 的 5GMM Registration Request 里有没有UE Usage Setting为 voice-centric再查 AMF 配置里voice_support是否为 true。常见做法是在 AMF 启动参数里显式打开。4.2 现象回落成功但通话无声原因LTE 侧没有建立 QCI1 的专用承载或者 IMS 的 SDP 协商里编解码不匹配。解决在 MME 日志里查Bearer Setup是否带 QCI1在 SIP 的 200 OK 里看maudio的 payload type 是否和 INVITE 一致。血泪经验是 AMR-WB 和 AMR-NB 混配会导致单通。4.3 现象回落时延超过 1 秒原因用了 redirect 模式或者 NR 到 LTE 的邻区关系没配全。解决把eps_fallback.mode改成 handover检查 gNB 的inter_rat_handover里有没有目标 LTE 频点。参数上把handover_delay从默认 500ms 调到 200ms 以内。4.4 现象抓包看到重复的 Handover Required原因AMF 在等不到 gNB 响应时重发通常是 gNB 的 NGAP 处理超时。解决查 gNB 的ngap_timeout参数默认 3 秒如果网络时延大可以调到 5 秒。同时看 gNB 的 CPU 负载过载会导致消息处理慢。4.5 现象EPS FB 完成后 UE 不回 5G原因LTE 侧没有配置 NR 的邻区或者 UE 的fast_return开关没开。解决在 eNB 的nr_neighbor里加 NR 频点在 AMF 侧确认fast_return为 true。这个坑很隐蔽因为通话正常只是用户感觉网速变慢。5. 进阶用脚本自动解析 EPS FB 信令并生成时延报表手动抓包分析效率低我一般写个 Python 脚本把 pcap 里的关键消息时间戳抽出来算 EPS FB 各阶段时延。下面这段代码用 pyshark 解析 NGAP 和 SIP输出从 INVITE 到 Handover Complete 的耗时。import pyshark import datetime def parse_epsfb(pcap_file): cap pyshark.FileCapture(pcap_file, display_filterngap || sip) timestamps {} for pkt in cap: try: if SIP in pkt and hasattr(pkt.sip, method): if pkt.sip.method INVITE: timestamps[invite] float(pkt.sniff_timestamp) if NGAP in pkt: if hasattr(pkt.ngap, procedureCode): code pkt.ngap.procedureCode # 29 是 PDU Session Resource Setup if code 29: timestamps[pdu_setup] float(pkt.sniff_timestamp) # 10 是 Handover Required if code 10: timestamps[handover_req] float(pkt.sniff_timestamp) except AttributeError: continue cap.close() if invite in timestamps and handover_req in timestamps: delay timestamps[handover_req] - timestamps[invite] print(fEPS FB 触发时延: {delay*1000:.2f} ms) return timestamps # 调用示例 parse_epsfb(amf_n2.pcap)逻辑说明脚本先按ngap || sip过滤再分别抓 SIP INVITE 和 NGAP 的 procedureCode。29 对应 PDU Session Resource Setup10 对应 Handover Required。两个时间戳相减就是 EPS FB 的决策时延。参数说明display_filter里的ngap和sip是 Wireshark 的协议名pyshark 依赖 tshark运行前确保 tshark 在 PATH 里。如果 pcap 很大可以加only_summariesTrue提速。验证方法拿一段已知正常的信令做基线比如决策时延在 50ms 以内算健康超过 200ms 就要查 AMF 和 gNB 之间的 SCTP 链路质量。我习惯把脚本挂到 cron 里每天凌晨跑前一天的抓包生成时延趋势表。下面是一个简单的报表格式。日期呼叫次数平均决策时延(ms)最大时延(ms)回落成功率06-0112004218099.2%06-0213504521098.8%06-0311003815099.5%这张表能直接看出哪天网络有异常。如果最大时延突然跳到 500ms 以上多半是某个 gNB 的 NGAP 处理出了问题顺着时间点去查那台设备的日志就行。我踩过的坑是脚本里没处理 SCTP 分片导致大包被漏掉后来加了pkt.ngap的异常捕获才稳定。希望帮到你。本文还有配套的精品资源点击获取