简介这份PPT资料聚焦5G网络优化中的语音方案系统梳理VONR与EPSFB两大核心流程面向5G核心网、无线优化工程师及通信专业学习者帮助厘清5G语音从NR直传到回落LTE的完整技术路径。压缩包内仅1个pptx文件约5.86MB以图文页形式呈现流程概述、信令交互与参数说明便于直接用于培训或自学。内容涵盖VONR与VOLTE在IMS层面的异同、终端与网络能力协商、5QI与QFI的QoS管理以及EPSFB的触发条件、回落过程与5GC和EPC间的交互同时详解PDU会话建立、修改、释放流程并拆解DNN、S-NSSAI、SSC mode、PDU type、PDU session ID等关键参数。目前已有392人学习适合需要掌握5G语音连续性方案与PDU会话管理细节的读者参考。1. VoNR 与 EPS Fallback一份 PPT 背后真正要讲清的语音打通链路5G 建网跑到今天真正让一线优化和核心网工程师头疼的往往不是峰值速率而是语音。用户拿着 5G 手机拨号接通前那两三秒里网络到底走了 VoNR 还是 EPS Fallback走的是哪条承载、哪个 5QI、哪次 PDU 会话修改这些细节决定了接通率、时延和掉话率。一份名为「VONR和EPSFB流程分享」的 PPT本质上要回答的就是这个问题在 SA 组网下语音业务如何用 VoNR 原生承载以及在 VoNR 不可用时如何优雅地回落到 LTE 走 EPS Fallback。它面向的是核心网、无线优化和信令分析岗位的从业者解决的是「语音打不通、回落慢、接续失败」这类现场问题。vonr协议栈从终端到 IMS 的每一层都是排查的抓手。2. 先把两条语音路径的协议栈和触发条件摆清楚2.1 VoNR 的协议栈分层与 5QI 映射关系VoNR 的本质是把 IMS 语音当作一个标准 5G 业务流来承载。终端侧从 IMS 客户端发起 SIP 注册和 INVITE经过 5G NR 空口、NG-RAN、UPF最终到达 IMS 核心网的 P-CSCF。用户面数据走的是 QoS Flow每个 Flow 由一个 5QI 标识。语音媒体流通常映射到 5QI1Conversational Voice信令走 5QI5IMS Signalling。这两个 5QI 的 QoS 特性差异很大5QI1 要求 GBR、包延迟预算 100ms、丢包率 10^-25QI5 是非 GBR、延迟预算 100ms、丢包率 10^-6。理解协议栈的关键是分清控制面和用户面。控制面走 NAS 消息负责 PDU 会话建立和修改用户面走 GTP-U 隧道承载 RTP 包。VoNR 建立过程中SMF 会根据 PCF 下发的策略在已有的 PDU 会话里新增或修改 QoS Flow。这里有个容易混淆的点VoNR 并不一定新建 PDU 会话常见做法是在默认 PDU 会话上通过 PDU Session Modification 增加 5QI1 的 QoS Flow。这也是为什么抓包时你会看到 PDU Session Modification Request 里带着 QoS Rule 和 QoS Flow Description。从无线侧看gNB 收到 QoS Flow 建立请求后要把它映射到 DRB。一个 DRB 可以承载多个 QoS Flow但语音这种 GBR Flow 通常单独映射到一个 DRB以保证调度优先级。如果 DRB 配置不当语音包会被数据业务挤掉表现为单通或断续。所以看 VoNR 流程不能只看核心网信令空口 DRB 的建立和逻辑信道优先级同样关键。2.2 EPS Fallback 的触发时机与回落判决EPS Fallback 不是失败而是一种设计好的兜底机制。当终端发起语音呼叫但当前 5G 小区不支持 VoNR比如没有 IMS 本地锚点、N26 接口未配、或 gNB 未开启 VoNR 能力网络会指示终端回落到 LTE在 LTE 上通过 VoLTE 完成语音。触发点通常发生在 SIP INVITE 之后、5G 侧试图建立 5QI1 承载之前。具体流程是终端在 5G 上发起 IMS 注册和呼叫SMF/AMF 发现无法建立语音承载或者 gNB 根据配置判断需要回落于是触发 Handover 或 Redirect。常见做法是 RRC Release 带 redirectCarrierInfo让终端重选到 LTE也有通过 NG-RAN 发起基于测量的切换。回落完成后终端在 LTE 上重新建立 QCI1 的承载继续 SIP 流程。整个过程对用户来说就是接通前多等一两秒。这里的关键参数是「回落门限」和「等待定时器」。如果 5G 侧迟迟不判决回落SIP 重传会超时用户听到的是呼叫失败。如果回落太快而 LTE 侧覆盖不好又会掉话。所以 EPS Fallback 的优化本质是在 5G 语音能力和 LTE 覆盖之间找平衡。抓包时要重点看5G 侧是否发了 Handover Required、终端是否收到 RRC Release、LTE 侧是否很快出现 QCI1 的 Activate Dedicated Bearer。2.3 用信令抓包区分 VoNR 与 EPS Fallback 的最小步骤现场排查最直接的手段是抓信令。下面是一段用 tshark 过滤 NGAP 和 NAS 消息的示例帮助快速定位语音流程走向。# 抓取 NG 接口过滤语音相关信令 tshark -i eth0 -f sctp port 38412 -Y ngap || nas-5gs -w vonr_epsfb.pcap # 查看 PDU Session Modification 中是否带 5QI1 tshark -r vonr_epsfb.pcap -Y nas-5gs.sm_message_type 0xcb -V | grep -i 5qi # 查看是否有 Handover Required判断是否触发 EPS Fallback tshark -r vonr_epsfb.pcap -Y ngap.procedureCode 12 -V第一段命令在 NG 接口上抓 SCTP 38412 端口同时过滤 NGAP 和 NAS-5GS 消息这是 5G 核心网信令的标准抓取方式。第二段过滤 NAS 消息类型 0xcb即 PDU Session Modification Request然后查找 5QI 字段如果出现 5QI1说明 VoNR 承载正在建立。第三段过滤 NGAP procedureCode 12即 Handover Preparation如果出现说明网络正在触发切换结合上下文可判断是 EPS Fallback。参数上-i 指定网卡-f 是 BPF 过滤-Y 是显示过滤-w 保存文件。注意抓包点要选在 AMF 与 gNB 之间的 N2 接口或者 SMF 与 UPF 之间的 N4 接口不同接口看到的信令层次不同。3. 从 PDU 会话到 DRBVoNR 建立过程中每个网元做了什么3.1 PDU Session Modification 里的 QoS Flow 参数怎么读VoNR 语音承载的建立核心是 PDU Session Modification 流程。终端发起 SIP INVITE 后IMS 侧通过 Rx 接口向 PCF 请求语音专用承载PCF 生成 PCC 规则SMF 据此发起 PDU Session Modification。这条 NAS 消息里包含几个关键字段QoS Rule、QoS Flow Description、Session-AMBR。QoS Rule 告诉终端哪些上行包要映射到哪个 QoS Flow通常基于 IP 五元组比如目的地址是 P-CSCF 的 SIP 信令走 5QI5RTP 媒体流走 5QI1。QoS Flow Description 里带 QFIQoS Flow Identifier和 5QIQFI 是每个 Flow 在 PDU 会话内的唯一标识后续 DRB 映射靠它。Session-AMBR 是会话级聚合限速语音场景下一般不会成为瓶颈但如果配得太低会影响多个业务并发。读这条消息时重点看三个地方一是 QFI 是否成功分配二是 5QI 是否与预期一致三是 QoS Rule 里的包过滤器是否匹配实际媒体流。常见问题是 P-CSCF 地址配错导致 SIP 信令没匹配上 5QI5语音建立失败。另一个坑是 Session-AMBR 单位是 bit/s不是 kbit/s配错会限速到不可用。3.2 gNB 侧 DRB 映射与逻辑信道优先级配置核心网把 QoS Flow 建好后gNB 要负责把它映射到空口 DRB。这个映射关系在 RRC Reconfiguration 里下发包含 DRB-ToAddMod、QoS Flow ToAdd 等 IE。语音 GBR Flow 通常映射到独立 DRBDRB 的 PDCP、RLC、MAC 参数都要按语音特性配。PDCP 层一般用 RLC UM 或 AM语音场景常用 UM 降低时延但丢包率要求高时用 AM 重传。RLC UM 的 SN 长度建议 12bit避免 wraparound 太快。MAC 层逻辑信道优先级LCP要保证语音 DRB 的优先比特率PBR足够高同时配置 Token Bucket Size 防止突发。如果 PBR 配低了语音包在拥塞时会被延迟调度表现为断续。一个实操检查点在 gNB 侧看 DRB 的 QoS 参数是否与核心网下发的 5QI 特性匹配。5QI1 要求 GBR如果 DRB 没配 GBR 或者 PBR 为 0语音质量会明显下降。另外DRB 的 SDAP 头要正确配置SDAP 负责 QoS Flow 到 DRB 的映射如果 SDAP 没启用或配错终端无法区分不同 QoS Flow。3.3 用 QFI 和 5QI 对照表快速定位承载异常现场排查时一张 QFI 与 5QI 的对照表能省很多时间。下面这张表是常见语音相关配置的参考。业务类型5QIQFI 示例承载类型典型 DRB 配置IMS 信令55非 GBR可与数据共用 DRB语音媒体11GBR独立 DRBPBR 高视频通话22GBR独立 DRB速率更高默认数据99非 GBR默认 DRB排查时先抓 PDU Session Modification看 QFI 和 5QI 是否按预期分配。如果 QFI1 的 5QI 不是 1说明 PCF 策略配错。然后看 RRC Reconfiguration确认 QFI1 是否映射到了独立 DRB。如果映射到了默认 DRB语音会被数据业务影响。最后看 MAC 层调度确认语音 DRB 的 PBR 是否足够。这三步走完大部分承载异常都能定位。4. EPS Fallback 落地时最容易翻车的几个环节4.1 回落判决参数配错导致呼叫超时EPS Fallback 的第一个坑是回落门限。网络侧通常根据 5G 小区是否支持 VoNR、终端能力、IMS 注册状态来决定是否回落。如果配置成「始终回落」那 VoNR 永远用不上如果配置成「从不回落」VoNR 不可用时呼叫直接失败。常见做法是设置一个定时器比如在 5G 侧尝试建立语音承载超时后触发回落。这个定时器叫「VoNR 尝试定时器」或类似名称不同厂商叫法不同。配得太短5G 侧还没来得及建立承载就回落浪费 VoNR 能力配得太长用户等待时间增加SIP 重传超时导致呼叫失败。一般建议设在 1 到 2 秒之间具体看核心网和 gNB 的处理时延。抓包时看 SIP INVITE 到 Handover Required 之间的时间差如果超过 3 秒基本可以判断定时器配长了。另一个参数是回落目标小区选择。如果 redirectCarrierInfo 指向的 LTE 小区覆盖不好回落过去就掉话。优化时要确保 5G 小区覆盖边缘的 LTE 邻区有足够重叠并且回落优先级配置合理。有些场景下5G 侧信号很好但 VoNR 不可用回落时却选了一个弱覆盖 LTE 小区这就是邻区配置问题。4.2 N26 接口未配导致上下文无法迁移EPS Fallback 要求 5G 和 LTE 之间能互操作N26 接口是关键。N26 是 AMF 和 MME 之间的接口用于传递 UE 上下文和会话信息。如果 N26 没配回落时终端需要重新附着到 LTE时延大幅增加甚至导致呼叫失败。检查 N26 是否配置看 AMF 和 MME 之间的 SCTP 偶联是否建立以及 NGAP 和 S1AP 消息里是否有对应的上下文传递。抓包时如果看到 Handover Required 之后没有 Handover Request 到 LTE或者终端直接发起 TAU 而不是切换基本可以判断 N26 有问题。配置上要确认 AMF 和 MME 的 N26 地址、端口、PLMN 信息一致并且双方都开启了 interworking 功能。没有 N26 时EPS Fallback 仍然可以工作但走的是重定向或重选时延从几百毫秒增加到几秒。对于语音这种对时延敏感的业务N26 几乎是必配项。如果现场确实无法配 N26那就要接受较长的接通时延并在优化上尽量缩短 LTE 侧的附着流程。4.3 回落过程中 DRB 释放与重建的时序问题EPS Fallback 过程中5G 侧的 DRB 要释放LTE 侧的 DRB 要重建。这个时序如果没对齐会出现短暂的数据中断语音表现为咔哒声或静音。常见问题是 5G 侧释放太早LTE 侧还没建好或者 LTE 侧建好了5G 侧还占着资源。优化时要看 RRC 消息的时序5G 侧 RRC Release 和 LTE 侧 RRC Connection Reconfiguration 之间的间隔。理想情况下LTE 侧承载建立完成后5G 侧再释放。但实际网络中这两个流程可能并行需要核心网和无线侧配合。如果终端支持双连接回落时可以保持 5G 连接直到 LTE 语音承载建立但 EPS Fallback 通常不依赖双连接。另一个坑是 QoS Flow 到 DRB 的映射在回落时丢失。5G 侧的 QFI 和 LTE 侧的 EPS Bearer ID 不是一一对应的回落时核心网要重新映射。如果映射错误语音流可能走到默认承载QoS 无法保证。抓包时对比 5G 侧 QFI1 和 LTE 侧 EBI5 的 QoS 参数确认 GBR 和延迟预算一致。5. 语音流程排查的常见问题与避坑清单5.1 现象VoNR 呼叫建立成功但无声音原因媒体流没有正确映射到 5QI1 的 QoS Flow或者 RTP 包被防火墙拦截。常见于 P-CSCF 地址配错、QoS Rule 过滤器不匹配、UPF 侧 GTP-U 隧道未正确建立。解决先抓 PDU Session Modification确认 5QI1 的 QoS Rule 里包过滤器是否匹配 RTP 五元组。然后抓 UPF 侧 N3 和 N6 接口看 RTP 包是否双向通行。如果只有单向检查 UPF 的路由和防火墙策略。最后看终端侧是否把 RTP 包发到了正确的 QFI有些终端在 QoS Rule 匹配失败时会走默认承载。5.2 现象EPS Fallback 回落时间超过 3 秒原因N26 未配、回落目标小区选择慢、或 5G 侧释放流程拖沓。常见于 AMF 和 MME 之间没有直连、LTE 邻区配置缺失、或 gNB 等待终端测量报告超时。解决先确认 N26 偶联状态如果没有推动核心网配置。然后检查 5G 到 LTE 的邻区关系确保 redirectCarrierInfo 指向的小区在覆盖范围内。最后看 gNB 的测量配置如果 A2 事件门限太低终端迟迟不上报回落判决就会延迟。调整门限让终端更早触发测量可以缩短回落时间。5.3 现象语音通话中频繁断续原因DRB 的 GBR 未生效、逻辑信道优先级配错、或空口丢包严重。常见于 PBR 配为 0、Token Bucket Size 太小、或 5QI1 映射到了非 GBR 的 DRB。解决在 gNB 侧检查语音 DRB 的 QoS 参数确认 PBR 大于语音编码速率比如 AMR-WB 约 23kbpsPBR 至少配 50kbps。然后看 MAC 层调度统计确认语音 DRB 的调度次数和丢包率。如果空口质量差检查 RS 功率和干扰必要时调整天线下倾角或功率参数。5.4 现象终端在 5G 上注册 IMS 失败原因5G 侧没有 IMS 本地锚点、P-CSCF 发现失败、或 5QI5 的信令承载未建立。常见于 SMF 未配置 IMS 相关 DNN、或 PCF 没有下发 IMS 信令策略。解决先看终端是否发起了 IMS PDU 会话建立DNN 通常是「ims」。然后检查 SMF 是否成功分配了 IP 地址以及 P-CSCF 地址是否通过 PCO 或 DHCP 下发。如果 P-CSCF 地址为空检查 SMF 和 PCF 的 IMS 配置。最后看 5QI5 的 QoS Flow 是否建立如果没有检查 PCF 是否下发了 IMS 信令的 PCC 规则。5.5 现象EPS Fallback 后 LTE 侧无法建立 QCI1 承载原因LTE 侧 MME 没有收到 5G 侧传递的语音承载上下文或者 PCRF 没有下发 VoLTE 策略。常见于 N26 消息里缺少 EPS Bearer 信息、或 LTE 侧 QCI1 的配置缺失。解决抓 N26 接口消息确认 Forward Relocation Request 里是否带了 EPS Bearer Context。如果没有检查 AMF 是否把 5G 的 QoS Flow 正确映射到了 EPS Bearer。然后看 LTE 侧 MME 和 PCRF 之间的 Gx 接口确认 QCI1 的策略是否下发。如果 PCRF 没配 VoLTE 策略需要补充配置。6. 把语音流程做成可复用的排查模板6.1 用脚本自动提取关键信令节点手工抓包分析效率低我一般会写个脚本把关键节点自动提取出来。下面这段 Python 用 pyshark 解析 pcap输出 VoNR 和 EPS Fallback 的关键事件时间线。import pyshark def analyze_voice_flow(pcap_path): cap pyshark.FileCapture(pcap_path, display_filterngap || nas-5gs) events [] for pkt in cap: try: if hasattr(pkt, ngap): proc pkt.ngap.get_field(ngap.procedureCode) if proc 12: events.append((float(pkt.sniff_time.timestamp()), Handover Required)) elif proc 13: events.append((float(pkt.sniff_time.timestamp()), Handover Request)) if hasattr(pkt, nas_5gs): msg_type pkt.nas_5gs.get_field(nas_5gs.sm_message_type) if msg_type 0xcb: events.append((float(pkt.sniff_time.timestamp()), PDU Session Modification)) except AttributeError: continue cap.close() events.sort() for ts, name in events: print(f{ts:.3f} {name}) return events # 调用示例 analyze_voice_flow(vonr_epsfb.pcap)这段脚本的核心逻辑是遍历 pcap 文件用 display_filter 只保留 NGAP 和 NAS-5GS 消息。对每个包检查是否有 ngap 或 nas_5gs 层然后提取 procedureCode 和 sm_message_type。procedureCode 12 是 Handover Preparation13 是 Handover Resource Allocation对应回落过程。sm_message_type 0xcb 是 PDU Session Modification对应 VoNR 承载建立。最后按时间排序输出形成时间线。参数上display_filter 可以根据需要调整比如只看某个 UE 的流量可以加 IP 过滤。注意 pyshark 依赖 tshark环境里要先装好。6.2 关键指标基线与异常阈值有了时间线还要有基线来判断是否异常。下面这张表是我在多个项目里总结的参考值不同网络可能有差异但可以作为起点。指标正常范围异常阈值说明VoNR 承载建立时延100-300ms500msSIP INVITE 到 PDU Session ModificationEPS Fallback 回落时延500-1500ms3000msSIP INVITE 到 LTE 侧 QCI1 建立语音 DRB 调度间隔20ms40msMAC 层调度统计RTP 丢包率1%3%端到端统计SIP 重传次数0-12信令抓包这些阈值不是绝对的但超过异常阈值时基本可以确定有问题。比如 VoNR 承载建立时延超过 500ms通常是 PCF 策略下发慢或 SMF 处理时延大。EPS Fallback 回落时延超过 3 秒多半是 N26 或邻区问题。RTP 丢包率超过 3%语音质量会明显下降需要检查空口或传输。6.3 一个我常犯的错忽略终端侧日志早期排查语音问题我只盯网络侧信令后来发现很多问题出在终端侧。比如终端不支持某个 5QI、或者 QoS Rule 匹配逻辑有 bug网络侧看一切正常但终端就是不发 RTP 包。现在我会同时抓终端侧日志用 QXDM 或类似工具看 NAS 和 RRC 消息对比网络侧和终端侧的理解是否一致。一个典型例子网络侧下发了 5QI1 的 QoS Flow但终端侧显示 QFI 映射失败原因是终端的 QoS Rule 里包过滤器优先级配错把 RTP 包匹配到了默认承载。这种问题只看网络侧抓包永远找不到。所以我的习惯是语音问题必须两端同时抓网络侧看信令终端侧看行为两边对齐了才能定位。希望帮到你。本文还有配套的精品资源点击获取