企业官网建设流程全解析

简介：这份PPT资料聚焦5G网络优化中的语音方案，系统梳理VONR与EPSFB两大核心流程，面向5G核心网、无线优化工程师及通信专业学习者，帮助厘清5G语音通话的建立、回落与资源管理逻辑。压缩包内仅1个pptx文件，约5.86MB，以图文页形式呈现流程概述、信令交互与参数说明，便于直接用于培训或自学。内容覆盖VONR与VOLTE在IMS上的异同、5QI与QFI的映射关系、EPSFB触发条件与回落过程，以及PDU会话建立、修改、释放的完整链路，并详解DNN、S-NSSAI、SSC mode、PDU type等关键参数。目录按流程概述、PDU会话管理、VONR流程、EPSFB流程四大模块展开，配合注册与通话信令示例，可帮助读者建立端到端的排错思路。目前已有392人学习，适合需要快速掌握5G语音方案与PDU会话机制的读者参考。

1. VoNR 与 EPS Fallback 流程拆解：从 PDU 会话到 5QI 的实战复盘

很多人第一次接触 VoNR，是在核心网抓包时看到一堆 PDU Session 建立请求，却搞不清哪条信令决定了语音走 NR 还是回落到 LTE。VoNR（Voice over New Radio）本质是把 IMS 语音承载在 5G NR 上，而 EPS Fallback 则是当 NR 侧不具备 VoNR 能力时，通过切换或重定向把语音业务甩回 LTE 的兜底方案。这两个流程决定了 5G 语音能不能打通、接通快不快、掉话多不多。如果你正在做 5G 语音优化、核心网信令分析，或者需要给团队讲清楚 VoNR 和 EPSFB 的信令差异，这篇内容会把 PDU 会话建立、5QI 与 DRB 映射、回落触发条件这些关键节点拆到能照着抓包对照的程度。vonr协议栈本身不复杂，复杂的是它和 EPSFB 之间的边界条件——什么时候该走 VoNR，什么时候必须回落，参数配错一个就等着接投诉。

2. VoNR 与 EPSFB 的选型逻辑：为什么你的网络需要两套语音方案

2.1 VoNR 的协议栈与 5QI 承载映射

VoNR 的协议栈从下往上依次是 NR 物理层、MAC、RLC、PDCP、SDAP，再到 IMS 的 SIP/SDP。关键变化在 SDAP 层——它负责把 QoS Flow 映射到 DRB。语音业务通常用 5QI=1（Conversational Voice），这个 5QI 对应 GBR 承载，保证带宽和时延。5QI=5 则是 IMS 信令默认承载，走 Non-GBR。实际抓包时你会看到 PDU Session Establishment Request 里带多个 QoS Flow，每个 Flow 有 QFI（QoS Flow Identifier），SDAP 根据 QFI 把包塞进对应的 DRB。

常见做法是：5QI=1 的 QoS Flow 映射到专用 DRB，5QI=5 映射到默认 DRB。如果 SDAP 配置里把这两个 Flow 映射到同一个 DRB，语音质量会受信令突发影响，表现为 MOS 分波动。我一般会在基站侧确认 SDAP 的 QoS Flow 到 DRB 映射表，确保 5QI=1 有独立 DRB。

2.2 EPS Fallback 的触发条件与信令路径

EPS Fallback 不是随便触发的。当 UE 发起 IMS 语音呼叫，AMF 检查 UE 的 VoNR 能力、NR 覆盖、5QI=1 的 QoS Flow 能否建立。如果 NR 侧不支持 VoNR，或者 5QI=1 建立失败，AMF 会触发 Fallback。具体路径有两种：一种是切换（Handover）到 LTE，一种是重定向（Redirect）。切换对语音接通时延更友好，重定向实现简单但中断时间长。

抓包时重点看 AMF 发出的 Handover Required 或 RRC Release 带 Redirected Carrier Info。如果看到 Handover Required 里目标小区是 LTE，说明走的是切换回落。重定向则表现为 NR 侧直接释放，UE 重新搜 LTE 小区。实际网络里，切换回落接通时延通常在 1.5 到 2.5 秒，重定向可能到 3 秒以上。

2.3 两套方案并存的参数边界

VoNR 和 EPSFB 并存的网络里，最怕的是边界参数不一致。比如 NR 侧配置了 VoNR 支持，但 AMF 里 VoNR 开关没开，UE 发起呼叫时 AMF 直接触发 Fallback，NR 侧还等着 VoNR 流程，结果就是呼叫失败。另一个常见问题是 5QI=1 的 GBR 带宽配得太小，VoNR 建立成功但语音断续。

我一般会核对三张表：AMF 的 VoNR 支持开关、NR 侧 5QI=1 的 GBR 配置、LTE 侧 EPSFB 的 QCI=1 承载配置。这三张表里任何一张对不上，语音流程就会在某个节点卡住。参数边界不是理论值，是实际抓包验证过的值——比如 5QI=1 的 GBR 上行建议不低于 40kbps，下行不低于 40kbps，具体看编解码器。

3. 用 PDU 会话建立流程串起 VoNR 信令：从 Registration 到 DRB 建立

3.1 抓包环境与过滤命令

先准备环境：一台支持 5G SA 的 UE、一个能抓 N2/N4 接口的核心网抓包点、Wireshark 带 5G 解析插件。如果抓空口，需要 UE 侧日志工具。我一般用核心网侧抓包，因为 N2 接口的 NGAP 信令最全。

过滤命令如下：

# 抓 N2 接口 NGAP 信令，过滤特定 UE 的 IMSI tshark -i eth0 -f "sctp port 38412" -Y "ngap.IMSI == 460XXXXXXXXXXXX" -w vonr_ue.pcap # 抓 N4 接口 PFCP 信令，看 PDU 会话建立 tshark -i eth1 -f "udp port 8805" -Y "pfcp" -w pfcp_session.pcap

逻辑说明：N2 接口走 SCTP，端口 38412，过滤 NGAP 层。N4 接口走 UDP 8805，过滤 PFCP。参数上，IMSI 换成实际测试卡号。如果抓不到，先确认抓包点是否在 AMF 和 gNB 之间的 N2 链路上，或者 SMF 和 UPF 之间的 N4 链路上。

3.2 PDU Session Establishment 的关键信令节点

VoNR 的 PDU 会话建立发生在 Registration 之后。UE 发起 PDU Session Establishment Request，里面带 PDU Session ID、Requested QoS Rules、Requested SSC Mode。AMF 选 SMF，SMF 选 UPF，然后 SMF 通过 N4 接口给 UPF 下发 PFCP Session Establishment Request，里面带 PDR、FAR、QER、URR。

关键看 QER 里的 QFI 和 5QI。如果 QFI=1 对应 5QI=1，说明语音承载建对了。如果 QFI=1 对应 5QI=9，那语音就走 Best Effort，质量没保证。抓包时在 Wireshark 里展开 PFCP Session Establishment Request，看 Create QER 里的 QFI 和 QoS 参数。

# 解析 PFCP 包里的 QER 信息，提取 QFI 和 5QI from scapy.all import rdpcap from scapy.contrib.pfcp import PFCP packets = rdpcap("pfcp_session.pcap") for pkt in packets: if PFCP in pkt: pfcp = pkt[PFCP] if pfcp.msg_type == 50: # PFCP Session Establishment Request for ie in pfcp.IE_list: if ie.type == 108: # Create QER qfi = ie.QFI qos = ie.QoS_Information print(f"QFI: {qfi}, 5QI: {qos.5QI}, GBR: {qos.GBR_UL}/{qos.GBR_DL}")

逻辑说明：这段脚本用 Scapy 解析 PFCP 包，过滤 Session Establishment Request，提取 Create QER 里的 QFI 和 5QI。参数上，msg_type=50 是 PFCP Session Establishment Request，IE type 108 是 Create QER。如果输出里 5QI 不是 1，说明语音 QoS 配错了。

3.3 DRB 建立与 SDAP 映射验证

PDU 会话建立后，gNB 根据 QoS Flow 建立 DRB。空口抓包能看到 RRC Reconfiguration 里带 DRB-ToAddMod，里面包含 DRB ID 和 SDAP-Config。SDAP-Config 里有 QFI 和 DRB 的映射关系。如果 5QI=1 的 QFI 映射到 DRB ID=2，而 5QI=5 映射到 DRB ID=1，说明语音有独立 DRB。

验证方法：在 UE 侧发一个 SIP INVITE，同时抓空口和 N2。看 RRC Reconfiguration 里 DRB 建立后，UE 是否在对应 DRB 上发 SIP 包。如果 SIP 包走了默认 DRB，说明 SDAP 映射没生效。常见原因是 gNB 的 SDAP 配置里没把 5QI=1 的 QFI 单独映射，或者 UE 侧 SDAP 实体没按 QFI 分流。

4. EPS Fallback 实战：回落触发、切换信令与接通时延优化

4.1 回落触发点的抓包定位

EPS Fallback 触发点通常在 AMF。当 UE 发起 IMS 呼叫，AMF 收到 SIP INVITE 后，检查 VoNR 能力。如果 UE 在 Registration 时没带 VoNR 能力，或者 NR 侧 5QI=1 建立失败，AMF 发 NGAP Handover Required 或直接发 RRC Release 带 Redirected Carrier Info。

抓包时在 N2 接口过滤 NGAP 消息，看 AMF 发给 gNB 的是 Handover Required 还是 Downlink NAS Transport 带 EPS Fallback Indicator。如果看到 Handover Required，目标小区是 E-UTRAN，说明走切换回落。如果看到 RRC Release 带 Redirected Carrier Info，说明走重定向。

# 过滤 NGAP Handover Required 消息 tshark -r n2.pcap -Y "ngap.procedureCode == 12" -V | grep -A 20 "Handover Required" # 过滤 RRC Release 带重定向信息 tshark -r n2.pcap -Y "ngap.procedureCode == 21" -V | grep -A 10 "Redirected Carrier Info"

逻辑说明：NGAP procedureCode 12 是 Handover Preparation，对应 Handover Required。procedureCode 21 是 UE Context Release，对应 RRC Release。参数上，-V 展开详细字段，grep 抓关键信息。如果两个都抓不到，说明 AMF 没触发 Fallback，检查 VoNR 开关和 UE 能力。

4.2 切换回落与重定向回落的信令差异

切换回落的信令路径：AMF 发 Handover Required 给源 gNB，源 gNB 发 Handover Request 给目标 eNB，目标 eNB 回 Handover Request Acknowledge，源 gNB 发 RRC Reconfiguration 带 MobilityControlInfo，UE 切换到 LTE，然后走 LTE 的 IMS 流程。整个过程语音中断时间短，但信令复杂。

重定向回落的信令路径：AMF 发 RRC Release 带 Redirected Carrier Info，UE 释放 NR 连接，搜 LTE 小区，重新建 RRC 连接，再走 LTE IMS。中断时间长，但实现简单。

实际网络里，切换回落接通时延约 1.5 到 2.5 秒，重定向约 3 到 4 秒。优化方向是尽量用切换回落，但需要 LTE 和 NR 之间的 Xn 接口或 N2 接口切换支持。如果 Xn 没配，只能走 N2 切换，时延会增加 200 到 500 毫秒。

4.3 接通时延的关键参数与优化手段

接通时延主要花在三个地方：UE 发起呼叫到 AMF 触发 Fallback、切换/重定向执行、LTE 侧 IMS 承载建立。优化手段包括：提前触发 Fallback（在 SIP INVITE 阶段就判断）、优化切换门限、预建 LTE 侧 QCI=1 承载。

我一般会调三个参数：AMF 的 VoNR 支持开关（如果 NR 不支持 VoNR，直接关掉，省得 UE 白等）、gNB 的切换门限（A2 事件门限调高，让 UE 早点切）、LTE 侧 QCI=1 的 GBR 配置（保证语音带宽）。实测下来，A2 门限从 -110dBm 调到 -105dBm，接通时延能降 300 毫秒左右。

5. 避坑与排查：VoNR 和 EPSFB 落地时最容易翻车的五个点

5.1 现象：VoNR 呼叫建立成功但无声

原因：5QI=1 的 QoS Flow 建立了，但 SDAP 映射把语音包塞进了默认 DRB，默认 DRB 走 5QI=5，没有 GBR 保证，语音包被丢弃或延迟抖动。

解决：检查 gNB 的 SDAP 配置，确认 5QI=1 的 QFI 映射到独立 DRB。抓空口看 RRC Reconfiguration 里的 SDAP-Config，如果 QFI=1 和 QFI=5 映射到同一个 DRB ID，改配置。

5.2 现象：EPS Fallback 触发后 UE 不回 LTE

原因：AMF 发了 Handover Required，但目标 eNB 没响应，或者 UE 没收到 RRC Reconfiguration。常见原因是 LTE 侧没配 QCI=1 承载，或者 Xn/N2 接口没通。

解决：抓 N2 接口看 Handover Request 是否发到 eNB，eNB 是否回 Handover Request Acknowledge。如果 eNB 没回，检查 LTE 侧 QCI=1 配置和接口状态。

5.3 现象：VoNR 和 EPSFB 切换时掉话

原因：NR 侧释放和 LTE 侧建立之间的时间窗太长，UE 在中间态丢了 IMS 上下文。常见原因是重定向回落时 UE 搜网时间过长，或者 LTE 侧 TA 更新失败。

解决：优先用切换回落，减少中断时间。如果只能用重定向，优化 LTE 侧频点优先级，让 UE 快速驻留。抓 UE 侧日志看搜网时间和 TA 更新流程。

5.4 现象：5QI=1 的 GBR 带宽不够导致语音断续

原因：5QI=1 的 GBR 配置太小，或者 UPF 的 QER 里 MBR 和 GBR 配反了。语音编解码器需要稳定带宽，GBR 不够就丢包。

解决：检查 SMF 下发的 QER，确认 5QI=1 的 GBR UL/DL 不低于 40kbps。如果 UPF 侧 MBR 小于 GBR，改配置。抓 N4 接口看 PFCP Session Establishment Request 里的 QER 参数。

5.5 现象：PDU 会话建立失败导致 VoNR 无法发起

原因：UE 发起 PDU Session Establishment Request，但 SMF 选不到 UPF，或者 UPF 没资源。常见原因是 SMF 和 UPF 之间的 N4 接口断，或者 UPF 的 IP 池耗尽。

解决：抓 N4 接口看 PFCP Session Establishment Request 是否有响应。如果没响应，检查 SMF 和 UPF 的 N4 链路状态。如果响应了但带 Cause 值，看 Cause 是不是资源不足。

6. 用 Wireshark 做 VoNR 与 EPSFB 的端到端信令关联

6.1 多接口抓包的时间对齐

端到端关联的前提是时间对齐。N2、N4、空口三个抓包点的时间戳要同步。我一般用 NTP 同步所有抓包服务器，误差控制在 10 毫秒以内。如果做不到，就在 Wireshark 里手动调时间偏移。

Wireshark 里用Frame Time排序，然后根据 IMSI 或 PDU Session ID 关联。N2 接口的 NGAP 里有 IMSI，N4 接口的 PFCP 里有 PDU Session ID，空口有 C-RNTI。关联时先找 IMSI，再找 PDU Session ID，最后找 C-RNTI。

6.2 用 Wireshark 过滤器和着色规则串流程

设置着色规则：NGAP Handover Required 标红，PFCP Session Establishment Request 标绿，RRC Reconfiguration 标蓝。过滤器用ngap || pfcp || rrc。然后按时间顺序看信令流。

关键节点：Registration Request → PDU Session Establishment Request → PFCP Session Establishment Request → RRC Reconfiguration（DRB 建立）→ SIP INVITE → Handover Required（EPSFB 触发）→ RRC Reconfiguration（切换）→ LTE RRC Connection Reconfiguration → SIP 180 Ringing。

6.3 一个完整的 VoNR 呼叫信令序列示例

下面是一个实际抓包的简化序列，用表格展示：

这个序列里，从 SIP INVITE 到 Handover Required 只用了 50 毫秒，说明 AMF 判断很快。从 Handover Required 到 LTE 承载建立用了 250 毫秒，这是切换回落的正常水平。如果这个时间超过 500 毫秒，就要查切换门限和接口配置。

6.4 我踩过的坑和现在的习惯

最早做 VoNR 抓包时，我只抓了 N2 接口，看到 PDU Session Establishment Request 里 5QI=1 就以为搞定了。结果语音还是断续，后来抓了 N4 才发现 UPF 的 QER 里 GBR 配成了 0。从那以后，我养成了三个接口一起抓的习惯，而且每次先看 QER 里的 GBR 和 MBR 是否匹配。

另一个坑是时间对齐。有一次 N2 和 N4 的时间差了 2 秒，信令顺序全乱了，排查了一下午才发现是 NTP 没同步。现在我会在抓包前先跑一遍ntpq -p确认时间同步。

还有一个习惯：每次分析 VoNR 流程，先确认 UE 的 VoNR 能力位。如果 UE 不支持 VoNR，直接看 EPSFB 流程，省得在 VoNR 信令里绕。这个习惯帮我省了很多时间。希望帮到你。

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