简介这份PPT面向5G网络优化工程师、核心网与无线侧技术人员以及备考通信认证的学习者系统梳理5G语音信令的关键技术脉络。内容围绕VOLTE、EPS FB、FR与VONR四条主线展开从VOLTE四层基础架构Service、Core、Access、Terminal入手逐条拆解RRC连接建立、QCI5/QCI9默认承载、SIP Invite至200 OK的完整呼叫流程并详解EPS FB回落与FR快速返回的触发机制同时归纳S-CSCF、I-CSCF、P-CSCF、PCRF、S/P-GW、MME等核心网网元职责。资源包为1个pptx文件约1.4MB以图文页形式呈现信令流程与网元交互便于对照学习与培训讲解。目前已有693人学习下载适合需要理清5G语音方案差异、掌握信令排错思路的读者参考。1. VoNR 与 EPS FB一通 5G 电话背后的两套信令路径你拿一台 5G 手机拨出电话从按下拨号键到对方振铃中间可能只隔了两三秒。但这两三秒里网络侧要做出一连串判断这通电话是走 5G 新空口直接承载还是先回落到 4G 再建立语音前者就是 VoNR后者就是 EPS FB。很多做 5G 核心网、无线优化或者终端协议栈的工程师第一次抓包看到 IMS 信令和 5G NAS 消息交织在一起时会觉得像在看一个黑匣子——明明注册成功了一拨电话就掉到 4G或者 VoNR 开关打开了却始终不触发。这个标题要拆的就是 VoNR 和 EPS FB 这两条语音信令路径的完整流程、关键参数和落地排查方法。适合已经接触过 5G 核心网或无线侧、需要把语音方案讲清楚或调通的从业者也适合刚进 5G 实训室、想从信令层面理解语音怎么走的新手。2. VoNR 信令流程拆解从注册到振铃的完整链路2.1 VoNR 的协议栈分层与关键网元VoNR 的本质是把 IMS 语音承载在 5G NR 和 5G 核心网之上。要理解信令先得把协议栈的分层关系理清楚。终端侧从下往上依次是 NR 物理层、NR RRC、5G NAS再往上才是 IMS 的 SIP/SDP。网络侧对应的网元包括 gNB、AMF、SMF、UPF以及 IMS 域的 P-CSCF、I-CSCF、S-CSCF。语音媒体流走的是 UPF 到 IMS 媒体网关的路径信令流走的是 AMF 到 SMF 再到 IMS 的路径。这里有一个容易混淆的点5G NAS 负责的是终端和核心网之间的移动性管理和会话管理而 SIP 负责的是 IMS 层的会话控制。两者不是替代关系而是承载关系。VoNR 能成立的前提是终端已经完成 5G 注册、建立了默认 PDU 会话并且 IMS 注册成功。很多现场问题出在 IMS 注册这一步但工程师只盯着 5G 侧看方向就偏了。常见做法是先用抓包工具确认 5G NAS 的注册状态再看 IMS 的 REGISTER 是否返回 200 OK。如果 IMS 注册失败VoNR 根本不会触发终端会直接尝试 EPS FB。这个判断顺序能省掉大量无效排查。2.2 用 Wireshark 抓取 VoNR 注册与呼叫信令下面这段是过滤 VoNR 相关信令的 Wireshark 显示过滤器配置以及一个典型的 SIP REGISTER 请求示例。实际操作时你需要在核心网侧或终端侧做端口镜像把 N1、N2 和 IMS 的 Gm 接口流量抓下来。# Wireshark 显示过滤器只看 5G NAS 和 SIP 信令 # 过滤 5G NAS 消息N1 接口 ngap || nas-5gs # 过滤 SIP 信令IMS Gm 接口 sip || sdp # 组合过滤只看 VoNR 注册相关 (nas-5gs) || (sip.Method REGISTER) || (sip.Method INVITE)# 典型 SIP REGISTER 请求关键字段 REGISTER sip:ims.mnc001.mcc460.3gppnetwork.org SIP/2.0 From: sip:4600012345678ims.mnc001.mcc460.3gppnetwork.org;tagabc123 To: sip:4600012345678ims.mnc001.mcc460.3gppnetwork.org Contact: sip:460001234567810.10.10.5:5060;g.3gpp.icsi-refurn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel P-Access-Network-Info: 3GPP-NR; nr-cli... Authorization: Digest username4600012345678ims...逻辑说明第一段 bash 命令是 Wireshark 的显示过滤器语法nas-5gs能过滤出 5G NAS 消息sip.Method REGISTER只保留注册请求。第二段 text 是 SIP REGISTER 的关键字段其中P-Access-Network-Info头域会标明当前接入的是 NR这是判断 VoNR 是否真正走 5G 的重要依据。Contact头里的icsi.mmtel表示终端支持 MMTel 语音业务。参数说明mnc001.mcc460是运营商网络标识实际抓包时按你所在网络替换。nr-cli是 NR 小区标识用于关联无线侧日志。如果 REGISTER 请求里P-Access-Network-Info显示的是 EUTRA 而不是 NR说明终端已经回落到 4G这时候查 VoNR 流程就没有意义了。2.3 VoNR 呼叫建立的信令时序与关键参数VoNR 呼叫建立的核心信令时序可以概括为终端发起 SIP INVITE经过 P-CSCF 转发到 S-CSCFS-CSCF 触发被叫侧流程被叫振铃后返回 180 Ringing接通后返回 200 OK主叫发送 ACK 确认。与此同时5G 侧要完成 PDU 会话的修改为语音媒体流建立专用的 QoS Flow。这里的关键参数是 5QI。VoNR 的语音承载通常使用 5QI1Conversational Voice信令使用 5QI5IMS Signalling。5QI1 的 QoS 特性是 GBR 类型保证比特率时延预算 100ms丢包率 10^-2。如果 SMF 没有正确建立 5QI1 的 QoS Flow语音会建立失败或者媒体流质量极差。我一般会按这个顺序检查先看 PDU 会话修改请求里有没有 5QI1 的 QoS Flow再看 UPF 侧有没有对应的媒体流统计最后看 SIP 的 SDP 协商是否成功。这三步能覆盖大部分 VoNR 呼叫建立失败的问题。3. EPS FB 回落流程什么时候触发、怎么回、怎么切回来3.1 EPS FB 的触发条件与两种回落方式EPS FB 的全称是 EPS Fallback意思是当 5G 网络无法承载语音时终端回落到 4G 的 EPS 网络建立语音承载。触发条件通常有三种一是终端不支持 VoNR二是 5G 网络没有部署 IMS 或者 IMS 注册失败三是无线侧 NR 覆盖不足但 LTE 覆盖可用。回落方式有两种基于切换的回落和基于重定向的回落。切换回落是 gNB 通过 NG-RAN 的切换流程把终端直接切到 LTE 小区时延较短通常 1 到 2 秒。重定向回落是 gNB 释放 NR 连接终端通过 RRC Release 消息里的重定向信息搜索 LTE 小区时延较长可能到 3 到 5 秒。实际网络中如果 LTE 和 NR 有邻区关系且信号质量满足切换门限优先走切换回落。这里有一个反直觉的点EPS FB 不是失败它是 3GPP 定义的标准流程。很多优化人员看到语音呼叫触发回落就认为是问题其实要看回落时延和回落后的语音质量是否达标。真正的问题是把本该走 VoNR 的呼叫也回落了那才需要查 VoNR 的配置。3.2 抓包分析 EPS FB 的 RRC 重定向与切换信令下面这段是 EPS FB 回落过程中gNB 侧 RRC Release 消息里携带重定向信息的示例以及对应的 NAS 消息。# gNB 下发的 RRCRelease 消息携带重定向信息 RRCRelease { redirectedCarrierInfo { eutra-Frequency 1650 # LTE 频点 eutra-PhysCellId 123 # 目标 LTE 小区 PCI } suspendConfig notPresent deprioritisationReq notPresent }# 终端回落到 LTE 后的 NAS 消息Tracking Area Update Tracking Area Update Request { EPS mobile identity GUTI UE network capability ... EPS bearer context status ... Additional update type ... }逻辑说明第一段是 gNB 通过 RRCRelease 消息把终端重定向到 LTE 频点 1650、PCI 123 的小区。redirectedCarrierInfo字段是重定向回落的关键如果这个字段为空终端只能自己搜网时延会明显增加。第二段是终端落到 LTE 后发起的 TAU 请求用于更新位置信息并建立 EPS 承载。参数说明eutra-Frequency是 LTE 的绝对频点号不同运营商配置不同。eutra-PhysCellId是目标小区的物理标识用于终端快速锁定小区。TAU 请求里的EPS bearer context status表示终端当前保留的 EPS 承载状态如果这个字段异常可能导致语音承载建立失败。排查时重点看两个时间点RRCRelease 消息发出的时间和 TAU 请求发出的时间两者之差就是回落时延。如果超过 2 秒需要检查 LTE 频点是否配置正确、目标小区是否覆盖良好。3.3 语音结束后返回 5G 的 Fast Return 流程EPS FB 的语音通话结束后终端需要尽快返回 5G。这个流程叫 Fast Return通常通过 LTE 侧的 RRCRelease 消息携带 NR 重定向信息来实现。终端收到后搜索 NR 小区发起 5G 注册恢复 5G 承载。关键参数是 LTE 侧配置的 NR 频点优先级和重定向门限。如果 Fast Return 配置不合理终端可能长时间停留在 4G导致用户感知下降。我一般会检查 LTE 的 RRCRelease 消息里有没有redirectedCarrierInfo指向 NR 频点以及终端返回 5G 后的注册时延是否在 1 秒以内。4. VoNR 与 EPS FB 的互操作参数配置与网元对接4.1 AMF 与 SMF 侧的关键配置项VoNR 和 EPS FB 的互操作依赖 AMF 和 SMF 的多个配置项。AMF 侧需要配置 VoNR 能力指示告诉 gNB 和终端当前网络是否支持 VoNR。SMF 侧需要配置 5QI1 的 QoS Flow 模板以及 IMS 的 PDU 会话锚点。下面这张表列出了我实际调测中经常检查的参数项和推荐值。参数项所在网元推荐值说明VoNR Support IndicatorAMFEnabled指示网络支持 VoNRIMS Voice Over PS SessionAMFSupported指示 IMS 语音 over PS5QI for VoiceSMF1语音承载 QoS 等级5QI for SignallingSMF5IMS 信令 QoS 等级EPS FB TriggerAMFVoNR Not Available触发回落的条件Fast Return TimerAMF2000ms返回 5G 的超时定时器这些参数不是孤立的VoNR Support Indicator 和 IMS Voice Over PS Session 必须同时开启终端才会尝试 VoNR。如果只开了一个终端会直接走 EPS FB。5QI 的配置要和 UPF 侧的 QoS 策略一致否则会出现信令建立成功但媒体流不通的情况。4.2 gNB 侧回落策略与邻区配置gNB 侧的回落策略决定了终端是走切换回落还是重定向回落。关键配置包括 NR 到 LTE 的邻区关系、切换门限、重定向优先级。如果 NR 和 LTE 没有配邻区切换回落无法执行只能走重定向。我一般会按这个顺序检查 gNB 配置先确认 NR 到 LTE 的邻区关系是否存在再看切换门限的 A2 事件是否合理最后看重定向频点优先级是否把 LTE 排在前面。A2 门限设得太高终端在 NR 信号还很好的时候就触发回落会导致不必要的回落设得太低终端在 NR 信号很差时才回落可能导致回落失败。4.3 终端侧 VoNR 开关与能力上报终端侧的 VoNR 开关和能力上报是信令流程的起点。终端在 5G 注册时会通过 NAS 消息上报自己的语音能力包括是否支持 VoNR、是否支持 EPS FB。如果终端上报不支持 VoNR网络侧不会尝试 VoNR 流程。常见做法是在终端侧用 QXDM 或类似工具抓 NAS 消息看 Registration Request 里的 UE Capability 字段。如果 VoNR 能力位没有置位需要检查终端的 NV 配置或者运营商策略。有些终端虽然硬件支持 VoNR但软件版本默认关闭需要手动打开或者等待运营商推送配置。5. 避坑与排查VoNR/EPS FB 调测中的五个血泪教训5.1 现象VoNR 注册成功但拨号即回落原因IMS 注册虽然返回 200 OK但 S-CSCF 侧没有正确配置 MMTel 业务触发导致 INVITE 请求被拒绝终端只能走 EPS FB。解决检查 S-CSCF 的 iFC 配置确认 MMTel 业务的触发条件包含 INVITE 方法。同时看 IMS 注册的 Contact 头里是否携带了icsi.mmtel标识。5.2 现象EPS FB 回落时延超过 5 秒原因gNB 没有配置 NR 到 LTE 的邻区关系终端只能通过重定向回落而且重定向频点优先级配置错误终端先搜了不相关的频点。解决补齐 NR 到 LTE 的邻区关系把 LTE 频点优先级调到最高确保终端第一时间锁定目标小区。同时检查 RRCRelease 消息里的redirectedCarrierInfo是否携带了正确的频点。5.3 现象VoNR 通话中媒体流单向不通原因SMF 建立了 5QI1 的 QoS Flow但 UPF 侧的媒体流过滤规则没有正确匹配 SDP 协商的 IP 和端口导致上行或下行媒体流被丢弃。解决检查 UPF 的 PDR 和 FAR 配置确认媒体流的 IP 五元组和 SDP 协商一致。同时看 UPF 的统计计数器确认是否有丢包。5.4 现象Fast Return 后终端长时间停留在 4G原因LTE 侧的 RRCRelease 消息没有携带 NR 重定向信息或者 NR 频点优先级低于 LTE终端没有触发返回 5G 的流程。解决在 LTE 侧配置 NR 重定向频点并把 NR 优先级调到最高。同时检查终端的 5G 注册时延如果超过 2 秒需要排查 NR 小区的广播消息是否完整。5.5 现象VoNR 和 EPS FB 都失败语音完全不可用原因AMF 侧的 VoNR Support Indicator 和 IMS Voice Over PS Session 配置不一致终端无法判断网络是否支持语音导致既不触发 VoNR 也不触发 EPS FB。解决统一 AMF 侧的两个配置项确保同时开启。同时检查终端的 NAS 消息里是否上报了正确的语音能力。6. 用 QXDM 和 Wireshark 联合定位 VoNR 信令问题的一个实用技巧单独看 QXDM 的 NAS 消息或者单独看 Wireshark 的 SIP 信令都容易漏掉跨层关联的问题。我一般会把两边的时间戳对齐用同一个呼叫的 NAS 消息和 SIP 消息做联合分析。具体做法是在 QXDM 里找到 Registration Request 的时间点然后在 Wireshark 里找到对应的 REGISTER 请求看两者的时间差。如果时间差超过 500ms说明 IMS 注册流程有延迟需要查 P-CSCF 的响应时间。下面这张表是我常用的联合定位对照表。QXDM 侧消息Wireshark 侧消息关联点正常时间差Registration Request无5G 注册起点无Registration Accept无5G 注册完成无UL NAS TransportREGISTERIMS 注册触发 200msDL NAS Transport200 OKIMS 注册完成 500msPDU Session ModificationINVITE语音承载建立 300ms这个技巧的关键是时间戳对齐。QXDM 和 Wireshark 的时钟可能不同步我一般会找一个共同事件做基准比如 PDU Session Modification 和 INVITE 几乎同时发生用这个点来校准两边的时间差。校准之后再看其他消息的时间差就有意义了。还有一个细节QXDM 抓 NAS 消息时要确保勾选了 5G NAS 和 IMS 相关的过滤器否则容易漏掉关键消息。Wireshark 侧要确保抓包点覆盖了 N1、N2 和 Gm 接口只抓一个接口往往看不到完整流程。我自己踩过最深的坑是只看了 SIP 的 200 OK 就认为 IMS 注册成功结果发现 S-CSCF 返回的 200 OK 里 Contact 头缺少icsi.mmtel导致后续 INVITE 被拒。从那以后我看 IMS 注册成功与否一定会检查 Contact 头的业务标识而不是只看响应码。希望帮到你。本文还有配套的精品资源点击获取 VoNR与EPS FB语音信令流程拆解：从注册到回落及Fast Return全解析
简介这份PPT面向5G网络优化工程师、核心网与无线侧技术人员以及备考通信认证的学习者系统梳理5G语音信令的关键技术脉络。内容围绕VOLTE、EPS FB、FR与VONR四条主线展开从VOLTE四层基础架构Service、Core、Access、Terminal入手逐条拆解RRC连接建立、QCI5/QCI9默认承载、SIP Invite至200 OK的完整呼叫流程并详解EPS FB回落与FR快速返回的触发机制同时归纳S-CSCF、I-CSCF、P-CSCF、PCRF、S/P-GW、MME等核心网网元职责。资源包为1个pptx文件约1.4MB以图文页形式呈现信令流程与网元交互便于对照学习与培训讲解。目前已有693人学习下载适合需要理清5G语音方案差异、掌握信令排错思路的读者参考。1. VoNR 与 EPS FB一通 5G 电话背后的两套信令路径你拿一台 5G 手机拨出电话从按下拨号键到对方振铃中间可能只隔了两三秒。但这两三秒里网络侧要做出一连串判断这通电话是走 5G 新空口直接承载还是先回落到 4G 再建立语音前者就是 VoNR后者就是 EPS FB。很多做 5G 核心网、无线优化或者终端协议栈的工程师第一次抓包看到 IMS 信令和 5G NAS 消息交织在一起时会觉得像在看一个黑匣子——明明注册成功了一拨电话就掉到 4G或者 VoNR 开关打开了却始终不触发。这个标题要拆的就是 VoNR 和 EPS FB 这两条语音信令路径的完整流程、关键参数和落地排查方法。适合已经接触过 5G 核心网或无线侧、需要把语音方案讲清楚或调通的从业者也适合刚进 5G 实训室、想从信令层面理解语音怎么走的新手。2. VoNR 信令流程拆解从注册到振铃的完整链路2.1 VoNR 的协议栈分层与关键网元VoNR 的本质是把 IMS 语音承载在 5G NR 和 5G 核心网之上。要理解信令先得把协议栈的分层关系理清楚。终端侧从下往上依次是 NR 物理层、NR RRC、5G NAS再往上才是 IMS 的 SIP/SDP。网络侧对应的网元包括 gNB、AMF、SMF、UPF以及 IMS 域的 P-CSCF、I-CSCF、S-CSCF。语音媒体流走的是 UPF 到 IMS 媒体网关的路径信令流走的是 AMF 到 SMF 再到 IMS 的路径。这里有一个容易混淆的点5G NAS 负责的是终端和核心网之间的移动性管理和会话管理而 SIP 负责的是 IMS 层的会话控制。两者不是替代关系而是承载关系。VoNR 能成立的前提是终端已经完成 5G 注册、建立了默认 PDU 会话并且 IMS 注册成功。很多现场问题出在 IMS 注册这一步但工程师只盯着 5G 侧看方向就偏了。常见做法是先用抓包工具确认 5G NAS 的注册状态再看 IMS 的 REGISTER 是否返回 200 OK。如果 IMS 注册失败VoNR 根本不会触发终端会直接尝试 EPS FB。这个判断顺序能省掉大量无效排查。2.2 用 Wireshark 抓取 VoNR 注册与呼叫信令下面这段是过滤 VoNR 相关信令的 Wireshark 显示过滤器配置以及一个典型的 SIP REGISTER 请求示例。实际操作时你需要在核心网侧或终端侧做端口镜像把 N1、N2 和 IMS 的 Gm 接口流量抓下来。# Wireshark 显示过滤器只看 5G NAS 和 SIP 信令 # 过滤 5G NAS 消息N1 接口 ngap || nas-5gs # 过滤 SIP 信令IMS Gm 接口 sip || sdp # 组合过滤只看 VoNR 注册相关 (nas-5gs) || (sip.Method REGISTER) || (sip.Method INVITE)# 典型 SIP REGISTER 请求关键字段 REGISTER sip:ims.mnc001.mcc460.3gppnetwork.org SIP/2.0 From: sip:4600012345678ims.mnc001.mcc460.3gppnetwork.org;tagabc123 To: sip:4600012345678ims.mnc001.mcc460.3gppnetwork.org Contact: sip:460001234567810.10.10.5:5060;g.3gpp.icsi-refurn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel P-Access-Network-Info: 3GPP-NR; nr-cli... Authorization: Digest username4600012345678ims...逻辑说明第一段 bash 命令是 Wireshark 的显示过滤器语法nas-5gs能过滤出 5G NAS 消息sip.Method REGISTER只保留注册请求。第二段 text 是 SIP REGISTER 的关键字段其中P-Access-Network-Info头域会标明当前接入的是 NR这是判断 VoNR 是否真正走 5G 的重要依据。Contact头里的icsi.mmtel表示终端支持 MMTel 语音业务。参数说明mnc001.mcc460是运营商网络标识实际抓包时按你所在网络替换。nr-cli是 NR 小区标识用于关联无线侧日志。如果 REGISTER 请求里P-Access-Network-Info显示的是 EUTRA 而不是 NR说明终端已经回落到 4G这时候查 VoNR 流程就没有意义了。2.3 VoNR 呼叫建立的信令时序与关键参数VoNR 呼叫建立的核心信令时序可以概括为终端发起 SIP INVITE经过 P-CSCF 转发到 S-CSCFS-CSCF 触发被叫侧流程被叫振铃后返回 180 Ringing接通后返回 200 OK主叫发送 ACK 确认。与此同时5G 侧要完成 PDU 会话的修改为语音媒体流建立专用的 QoS Flow。这里的关键参数是 5QI。VoNR 的语音承载通常使用 5QI1Conversational Voice信令使用 5QI5IMS Signalling。5QI1 的 QoS 特性是 GBR 类型保证比特率时延预算 100ms丢包率 10^-2。如果 SMF 没有正确建立 5QI1 的 QoS Flow语音会建立失败或者媒体流质量极差。我一般会按这个顺序检查先看 PDU 会话修改请求里有没有 5QI1 的 QoS Flow再看 UPF 侧有没有对应的媒体流统计最后看 SIP 的 SDP 协商是否成功。这三步能覆盖大部分 VoNR 呼叫建立失败的问题。3. EPS FB 回落流程什么时候触发、怎么回、怎么切回来3.1 EPS FB 的触发条件与两种回落方式EPS FB 的全称是 EPS Fallback意思是当 5G 网络无法承载语音时终端回落到 4G 的 EPS 网络建立语音承载。触发条件通常有三种一是终端不支持 VoNR二是 5G 网络没有部署 IMS 或者 IMS 注册失败三是无线侧 NR 覆盖不足但 LTE 覆盖可用。回落方式有两种基于切换的回落和基于重定向的回落。切换回落是 gNB 通过 NG-RAN 的切换流程把终端直接切到 LTE 小区时延较短通常 1 到 2 秒。重定向回落是 gNB 释放 NR 连接终端通过 RRC Release 消息里的重定向信息搜索 LTE 小区时延较长可能到 3 到 5 秒。实际网络中如果 LTE 和 NR 有邻区关系且信号质量满足切换门限优先走切换回落。这里有一个反直觉的点EPS FB 不是失败它是 3GPP 定义的标准流程。很多优化人员看到语音呼叫触发回落就认为是问题其实要看回落时延和回落后的语音质量是否达标。真正的问题是把本该走 VoNR 的呼叫也回落了那才需要查 VoNR 的配置。3.2 抓包分析 EPS FB 的 RRC 重定向与切换信令下面这段是 EPS FB 回落过程中gNB 侧 RRC Release 消息里携带重定向信息的示例以及对应的 NAS 消息。# gNB 下发的 RRCRelease 消息携带重定向信息 RRCRelease { redirectedCarrierInfo { eutra-Frequency 1650 # LTE 频点 eutra-PhysCellId 123 # 目标 LTE 小区 PCI } suspendConfig notPresent deprioritisationReq notPresent }# 终端回落到 LTE 后的 NAS 消息Tracking Area Update Tracking Area Update Request { EPS mobile identity GUTI UE network capability ... EPS bearer context status ... Additional update type ... }逻辑说明第一段是 gNB 通过 RRCRelease 消息把终端重定向到 LTE 频点 1650、PCI 123 的小区。redirectedCarrierInfo字段是重定向回落的关键如果这个字段为空终端只能自己搜网时延会明显增加。第二段是终端落到 LTE 后发起的 TAU 请求用于更新位置信息并建立 EPS 承载。参数说明eutra-Frequency是 LTE 的绝对频点号不同运营商配置不同。eutra-PhysCellId是目标小区的物理标识用于终端快速锁定小区。TAU 请求里的EPS bearer context status表示终端当前保留的 EPS 承载状态如果这个字段异常可能导致语音承载建立失败。排查时重点看两个时间点RRCRelease 消息发出的时间和 TAU 请求发出的时间两者之差就是回落时延。如果超过 2 秒需要检查 LTE 频点是否配置正确、目标小区是否覆盖良好。3.3 语音结束后返回 5G 的 Fast Return 流程EPS FB 的语音通话结束后终端需要尽快返回 5G。这个流程叫 Fast Return通常通过 LTE 侧的 RRCRelease 消息携带 NR 重定向信息来实现。终端收到后搜索 NR 小区发起 5G 注册恢复 5G 承载。关键参数是 LTE 侧配置的 NR 频点优先级和重定向门限。如果 Fast Return 配置不合理终端可能长时间停留在 4G导致用户感知下降。我一般会检查 LTE 的 RRCRelease 消息里有没有redirectedCarrierInfo指向 NR 频点以及终端返回 5G 后的注册时延是否在 1 秒以内。4. VoNR 与 EPS FB 的互操作参数配置与网元对接4.1 AMF 与 SMF 侧的关键配置项VoNR 和 EPS FB 的互操作依赖 AMF 和 SMF 的多个配置项。AMF 侧需要配置 VoNR 能力指示告诉 gNB 和终端当前网络是否支持 VoNR。SMF 侧需要配置 5QI1 的 QoS Flow 模板以及 IMS 的 PDU 会话锚点。下面这张表列出了我实际调测中经常检查的参数项和推荐值。参数项所在网元推荐值说明VoNR Support IndicatorAMFEnabled指示网络支持 VoNRIMS Voice Over PS SessionAMFSupported指示 IMS 语音 over PS5QI for VoiceSMF1语音承载 QoS 等级5QI for SignallingSMF5IMS 信令 QoS 等级EPS FB TriggerAMFVoNR Not Available触发回落的条件Fast Return TimerAMF2000ms返回 5G 的超时定时器这些参数不是孤立的VoNR Support Indicator 和 IMS Voice Over PS Session 必须同时开启终端才会尝试 VoNR。如果只开了一个终端会直接走 EPS FB。5QI 的配置要和 UPF 侧的 QoS 策略一致否则会出现信令建立成功但媒体流不通的情况。4.2 gNB 侧回落策略与邻区配置gNB 侧的回落策略决定了终端是走切换回落还是重定向回落。关键配置包括 NR 到 LTE 的邻区关系、切换门限、重定向优先级。如果 NR 和 LTE 没有配邻区切换回落无法执行只能走重定向。我一般会按这个顺序检查 gNB 配置先确认 NR 到 LTE 的邻区关系是否存在再看切换门限的 A2 事件是否合理最后看重定向频点优先级是否把 LTE 排在前面。A2 门限设得太高终端在 NR 信号还很好的时候就触发回落会导致不必要的回落设得太低终端在 NR 信号很差时才回落可能导致回落失败。4.3 终端侧 VoNR 开关与能力上报终端侧的 VoNR 开关和能力上报是信令流程的起点。终端在 5G 注册时会通过 NAS 消息上报自己的语音能力包括是否支持 VoNR、是否支持 EPS FB。如果终端上报不支持 VoNR网络侧不会尝试 VoNR 流程。常见做法是在终端侧用 QXDM 或类似工具抓 NAS 消息看 Registration Request 里的 UE Capability 字段。如果 VoNR 能力位没有置位需要检查终端的 NV 配置或者运营商策略。有些终端虽然硬件支持 VoNR但软件版本默认关闭需要手动打开或者等待运营商推送配置。5. 避坑与排查VoNR/EPS FB 调测中的五个血泪教训5.1 现象VoNR 注册成功但拨号即回落原因IMS 注册虽然返回 200 OK但 S-CSCF 侧没有正确配置 MMTel 业务触发导致 INVITE 请求被拒绝终端只能走 EPS FB。解决检查 S-CSCF 的 iFC 配置确认 MMTel 业务的触发条件包含 INVITE 方法。同时看 IMS 注册的 Contact 头里是否携带了icsi.mmtel标识。5.2 现象EPS FB 回落时延超过 5 秒原因gNB 没有配置 NR 到 LTE 的邻区关系终端只能通过重定向回落而且重定向频点优先级配置错误终端先搜了不相关的频点。解决补齐 NR 到 LTE 的邻区关系把 LTE 频点优先级调到最高确保终端第一时间锁定目标小区。同时检查 RRCRelease 消息里的redirectedCarrierInfo是否携带了正确的频点。5.3 现象VoNR 通话中媒体流单向不通原因SMF 建立了 5QI1 的 QoS Flow但 UPF 侧的媒体流过滤规则没有正确匹配 SDP 协商的 IP 和端口导致上行或下行媒体流被丢弃。解决检查 UPF 的 PDR 和 FAR 配置确认媒体流的 IP 五元组和 SDP 协商一致。同时看 UPF 的统计计数器确认是否有丢包。5.4 现象Fast Return 后终端长时间停留在 4G原因LTE 侧的 RRCRelease 消息没有携带 NR 重定向信息或者 NR 频点优先级低于 LTE终端没有触发返回 5G 的流程。解决在 LTE 侧配置 NR 重定向频点并把 NR 优先级调到最高。同时检查终端的 5G 注册时延如果超过 2 秒需要排查 NR 小区的广播消息是否完整。5.5 现象VoNR 和 EPS FB 都失败语音完全不可用原因AMF 侧的 VoNR Support Indicator 和 IMS Voice Over PS Session 配置不一致终端无法判断网络是否支持语音导致既不触发 VoNR 也不触发 EPS FB。解决统一 AMF 侧的两个配置项确保同时开启。同时检查终端的 NAS 消息里是否上报了正确的语音能力。6. 用 QXDM 和 Wireshark 联合定位 VoNR 信令问题的一个实用技巧单独看 QXDM 的 NAS 消息或者单独看 Wireshark 的 SIP 信令都容易漏掉跨层关联的问题。我一般会把两边的时间戳对齐用同一个呼叫的 NAS 消息和 SIP 消息做联合分析。具体做法是在 QXDM 里找到 Registration Request 的时间点然后在 Wireshark 里找到对应的 REGISTER 请求看两者的时间差。如果时间差超过 500ms说明 IMS 注册流程有延迟需要查 P-CSCF 的响应时间。下面这张表是我常用的联合定位对照表。QXDM 侧消息Wireshark 侧消息关联点正常时间差Registration Request无5G 注册起点无Registration Accept无5G 注册完成无UL NAS TransportREGISTERIMS 注册触发 200msDL NAS Transport200 OKIMS 注册完成 500msPDU Session ModificationINVITE语音承载建立 300ms这个技巧的关键是时间戳对齐。QXDM 和 Wireshark 的时钟可能不同步我一般会找一个共同事件做基准比如 PDU Session Modification 和 INVITE 几乎同时发生用这个点来校准两边的时间差。校准之后再看其他消息的时间差就有意义了。还有一个细节QXDM 抓 NAS 消息时要确保勾选了 5G NAS 和 IMS 相关的过滤器否则容易漏掉关键消息。Wireshark 侧要确保抓包点覆盖了 N1、N2 和 Gm 接口只抓一个接口往往看不到完整流程。我自己踩过最深的坑是只看了 SIP 的 200 OK 就认为 IMS 注册成功结果发现 S-CSCF 返回的 200 OK 里 Contact 头缺少icsi.mmtel导致后续 INVITE 被拒。从那以后我看 IMS 注册成功与否一定会检查 Contact 头的业务标识而不是只看响应码。希望帮到你。本文还有配套的精品资源点击获取