5G 网络学习系列写到第四篇这次终于要聊用户面里最核心的课题5G 网络中数据包转发模型。前几篇我们把核心网网元、服务化接口、PDU 会话建立流程都过了一遍但很多朋友反映看完信令流程之后还是对“数据包到底怎么走”没概念。信令只是告诉网络“这个用户是谁、他能用哪些服务”真正决定延时、带宽、业务连续性的是用户面的数据包转发模型。这一篇就是把 PDU 会话、QoS 流、UPF、GTP-U 隧道这几件事串起来讲清楚一个 IP 包从数据网络进入终端、再从终端回到数据网络的完整路径。这篇内容适合正在学 5G 核心网的工程师也适合准备接触用户面排障的运维朋友。我会把模型拆成“位置、概念、路径、场景、排障”五块来讲最后留一个未完待续的收尾方便下一期继续补接入网侧的细节。希望读完你能在脑海里画出一张完整的用户面地图。1. 数据包转发模型在整个 5G 网络里的位置1.1 控制面与用户面分离是理解一切的起点很多初学者第一步容易卡住5G 核心网里那么多网元我怎么知道谁在“指挥”谁在“干活”答案其实很简单控制面管“怎么连”用户面管“怎么传”。5G 从架构设计上就把这两个面分开了这叫控制与用户面分离。在传统网络设备里路由引擎和转发引擎往往是同一个盒子里的两块芯片控制逻辑和数据转发紧密耦合。而 5G 核心网把控制面网元集中部署把用户面网元下沉部署让用户流量尽量靠近接入侧这样既降低回传带宽压力也缩短业务时延。落到具体网元上AMF 负责移动性管理SMF 负责会话管理UPF 是用户面功能节点。SMF 通过 N4 接口给 UPF 下发指令包括“什么时候建立会话、如何识别用户数据、该执行什么转发动作”。真正把用户 IP 包从基站搬到数据网络、再从数据网络搬回基站的是 UPF。所以聊数据包转发模型主角就是 UPF配角是 SMF 和基站侧的 gNB。有个我常用的比喻控制面像快递系统的调度中心用户面像快递运输车队。调度中心不搬包裹但它决定包裹装哪辆车、走哪条路、多快到达车队负责真搬但必须按调度中心的指令走。你抓包分析时如果只盯着控制面信令看以为“流程走通了”就万事大吉往往会被用户面的转发问题坑得团团转。1.2 数据包转发模型要回答哪几个问题数据包转发模型不是一个单一概念而是一套规则组合至少要回答五个问题第一数据包在哪些网络节点之间转发在 5G 里主要涉及 N3、N9、N6 三个接口。N3 是 gNB 和 UPF 之间的接口N9 是两个 UPF 之间的接口N6 是 UPF 和数据网络之间的接口。数据包从终端出发先经过空口到 gNB再从 gNB 经过 N3 到 UPF在 UPF 内部按规则处理后从 N6 出去如果中间有多个 UPF还会经过 N9。第二一个用户的数据包怎么区分靠 PDU 会话和 QoS 流。每个终端可以建立多个 PDU 会话每个会话里再拆成多个 QoS 流每一个流用 QFI 标识保证不同业务得到不同质量的服务。第三转发时遵循哪些规则SMF 通过 N4 接口给 UPF 下发的包检测规则、转发规则、QoS 执行规则和流量上报规则基本决定了包的命运。第四数据包怎么跨节点传输目前主要靠 GTP-U 隧道隧道里用 TEID 标识上下文用扩展头携带 QFI。第五在移动性场景和边缘计算场景下转发路径如何切换和分流比如切换时怎么改隧道本地分流时怎么走“近路”。这些问题就是数据包转发模型的核心骨架。下面逐个展开。2. 几个绕不开的核心概念2.1 PDU 会话与 QoS 流用户业务的“隔离层”PDU 会话全称是 Protocol Data Unit Session可以理解为 UE 与数据网络之间的一条端到端逻辑连接。它很像 4G 时代的 EPS 承载但又更灵活。一个终端可以同时建立多个 PDU 会话每个 PDU 会话对应一个 DNN数据网络名称也可以关联不同的切片标识。比如一个手机终端可以有一个基础互联网 PDU 会话同时再建一个面向企业专线的 PDU 会话两个会话的 IP 地址、转发规则、服务质量是互相隔离的。在同一个 PDU 会话内还会有更细粒度的隔离和区分这就是 QoS 流。QoS 流是 PDU 会话中具备相同转发服务质量保障的流量聚合每条 QoS 流由 QFI 唯一标识。QFI 是 0 到 255 之间的数值含义本身不固定一般结合 5QI 一起使用。5QI 是一个标准化的 QoS 指标定义了资源类型、优先级、包延时预算、包错误率等参数。比如最常见的 5QI1 用于 VoNR 语音5QI8 或 9 用于普通互联网业务。QoS 流建立的方式有两种一种是会话建立时默认生成的默认 QoS 流通常是非 GBR 类型另一种是按需建立的专用 QoS 流可以是 GBR 类型由 SMF 根据策略触发。实际抓包时QoS 流的概念不会直接出现在 IP 层而是体现在 GTP-U 头扩展的 QFI 字段中这点后面详细说。PDU 会话和 QoS 流的关系可以类比成家庭宽带PDU 会话是“一条入户光缆”QoS 流是光缆里的“不同服务通道”IPTV 一个通道、上网一个通道、语音一个通道彼此共享物理线路但互不影响优先级。没有 QoS 流做区分所有流量挤在一起关键业务质量根本没法保障。2.2 UPF真正干活的节点UPF 是用户面功能节点负责 PDU 会话的锚点、数据包检测、流量转发、QoS 执行、计费信息收集等。通俗讲它就是一张“可编程的数据转发卡”既像路由器又像防火墙还带着策略执行能力。UPF 与 SMF 之间通过 N4 接口连接N4 接口上的关键消息包括会话建立请求、会话修改请求、会话删除请求等。SMF 每次下发规则UPF 就按照规则更新自己的本地转发表。这里有很多朋友不熟悉的术语PDR、FAR、QER、URR。PDR 是包检测规则规定“哪些流量匹配这条规则”FAR 是转发动作规则规定“匹配到的流量是转发、丢弃、复制还是重定向”QER 是 QoS 执行规则规定“流速限制和调度参数”URR 是用量上报规则规定“什么时候上报流量统计”。UPF 收到一个数据包后不是简简单单查路由表就转发而是先按 PDR 的匹配条件比如源目的 IP、端口、TEID、QFI识别这条流再依据对应的 FAR 决定动作依据 QER 做限速依据 URR 做统计上报。这套机制比传统 IP 路由复杂很多但换来的是非常精细的流级控制既能分流又能限速还能计费边缘计算和网络切片都依赖这种能力。UPF 的位置选择也很讲究。集中部署的 UPF 策略简单、管理方便但回传路径长时延高靠近基站部署的 UPF 时延低但数量多、维护复杂。实际组网往往会做分级部署省级层面放中心 UPF地市层面或园区内部放边缘 UPF中间用 N9 接口连接。转发模型在不同层级之间有微妙差异后面会展开。2.3 隧道与 QFI包里到底藏着什么5G 用户面转发最明显的特点就是隧道封装。gNB 和 UPF 之间的 GTP-U 隧道外层是普通 IP/UDP 头内层是用户的真实数据包。GTP-U 使用 UDP 端口 2152头部里最关键的是 TEID也就是隧道端点标识符。TEID 用来告诉接收端“这个包属于哪个 PDU 会话”接收端根据 TEID 找到对应的会话上下文再按规则继续处理。GTP-U 头部之后还有可选的扩展头QFI 就在扩展头里。也就是说一个数据包到了 N3 接口你看到的结构是外层 IP 头、外层 UDP 头、GTP-U 头、GTP-U 扩展头包含 QFI、内层 IP 头、业务数据。我用 Wireshark 抓 N3 口流量时经常看到两个 IP 头叠着第一次看的朋友会有点懵但只要记住“外层是节点之间的隧道地址内层是用户报文”就好了。QFI 放在 GTP-U 扩展头而不是内层 IP 头里是有讲究的。因为同一个 PDU 会话里QoS 流的区分是网络侧帮忙加标签不是修改用户的 IP 数据包。这样用户的 IP 包不会因网络转发而被篡改到了数据网络侧还是原样。过去 4G 中 QoS 区分依赖 EPS Bearer ID5G 换成 QFI更灵活也更能支持后续的反射 QoS 机制。看到这里你应该明白一个核心逻辑5G 用户面真正传输的是“加了隧道的 IP 包”隧道里面挂着会话上下文扩展头里标着 QoS 流标识。所有转发、分流、限速的动作都围绕这两个标识展开。3. 一步一图数据包怎么走完一整条路3.1 下行从数据网络到终端下行方向数据包从数据网络出发目标是终端 UE。先走 N6 接口进入 UPF。UPF 收到这个包以后要做的事情很多但最关键的是三件事识别会话、匹配规则、封装隧道。UPF 先看目的 IP 地址和端口等信息把它对应到某个 PDU 会话上。如果这个 PDU 会话有多条 QoS 流UPF 还要根据包的 DSCP、五元组或应用层信息判断它属于哪条 QoS 流然后填上对应的 QFI。接着UPF 根据这个 PDU 会话在 N3 口的隧道信息把用户的 IP 包封装成 GTP-U 包加上外层 IP/UDP 头通过 N3 接口发给 gNB。gNB 收到 GTP-U 包后先去掉外层隧道头读取 QFI知道这个包属于哪条 QoS 流。接下来 gNB 要根据 QoS 流到数据无线承载的映射关系把包放到对应的 DRB 里。DRB 是空口上的数据无线承载一个 DRB 可以映射一个或多个 QoS 流。映射关系通过 SDAP 层完成SDAP 是 5G 新增的协议层专门在 RLC 之上做 QoS 流和 DRB 之间的映射。经过 SDAP 映射之后数据包继续往下走经过 PDCP 层加密、RLC 层分段、MAC 层调度最终通过空口发给终端。终端侧的 SDAP 层会反向操作把 DRB 里的包还原成对应的 QoS 流然后交给上层协议处理。所以下行方向可以总结成一句话数据网络进入 UPFUPF 加隧道头gNB 拆隧道按 QFI 映射到空口承载终端还原。3.2 上行从终端到数据网络上行方向几乎是下行的镜像但有一个点值得注意上行链路里终端需要先决定业务包放到哪个 QoS 流再映射到哪个 DRB。终端应用产生一个 IP 包之后SDAP 层会根据规则给它标上 QFI。这些规则可以是会话建立时网络侧下发的也可以通过反射 QoS 从下行包中学到。然后这个包进入对应的 DRB经过 PDCP、RLC、MAC 交给 gNB。gNB 从 DRB 里收包后根据 DRB 到 QFI 的映射关系恢复 QFI再根据 PDU 会话的隧道信息加上 GTP-U 头通过 N3 接口发给 UPF。UPF 从 N3 口收到隧道包后根据 TEID 找到会话上下文去掉外层隧道头读取 QFI再按 PDR/FAR 规则决定从哪个 N6 出口转发出去。如果这个 PDU 会话接到了多个数据网络或者有本地分流规则UPF 还要做出口选择。上行最关键的一点是UE 侧的映射质量直接影响业务体验。如果一个低优先级业务错误映射到了高优先级 DRB会挤占关键业务的空口资源。因此终端侧的 SDAP 配置必须准确网络侧也要定期通过 RRC 重配置下发最新映射关系。排障时遇到“上行体验差但下行没问题”我一般会先看 UE 上报的 QoS 流映射和功控参数。3.3 QoS 流到 DRB 的映射最后一公里的排队规则前面提到 DRB 是空口上的数据无线承载QoS 流到 DRB 的映射决定了一个业务包在空口上“排哪条队”。这个映射不是固定的网络可以随时通过 RRC 信令调整。举个例子一个 PDU 会话里有两条 QoS 流一条是 VoNR 语音流5QI1要求低时延高可靠另一条是视频流5QI8要求高带宽但允许一定时延。如果这两条 QoS 流映射到同一个 DRB它们享受同样的调度优先级语音的时延优势会大打折扣最好的做法是映射到两个 DRB语音走专有 DRB高优先级调度视频走默认 DRB普通调度。SDAP 层在实现映射时既可以做“限定映射”让某条 QoS 流只走指定 DRB也可以做“默认映射”在 DRB 建立后未显式映射的 QoS 流都走默认 DRB。这里有个容易踩坑的地方如果 RRC 配置里的 SDAP 映射关系和下发的 QoS 流列表不一致终端侧的包可能会被丢弃或错误映射业务就会忽好忽坏。从抓包角度QFI 在 N3 口上能直接看到但 DRB 映射情况在空口上看不全需要借助 RRC 信令和 gNB 侧日志。所以我做转发链路分析时习惯把 N3 抓包、RRC 重配置消息、UE 侧日志放在一起看才能完整还原整个路径。4. 多锚点与边缘场景下的转发模型4.1 UL CL给本地流量开一条“近路”标准的下行路径是数据网络到中心 UPF再走 N3 到 gNB。但如果业务是园区内部应用或者边缘计算服务坚持绕到中心 UPF 再回来时延会很高回传带宽也浪费。5G 提供了一种机制叫 UL CL中文叫上行分类器。UL CL 是在 UPF 上实现的一种数据包分流能力。SMF 在 PDU 会话建立或修改时可以在路径上插入一个具备 UL CL 功能的 UPF。这个 UPF 收到上行数据后会按匹配规则做分流一部分流量送到中心 UPF走 N9 接口再进入中心数据网络另一部分流量直接从本地 UPF 的 N6 接口送到边缘应用服务器。下行方向反之来自两个数据网络的流量会在分支点汇合再通过同一个 N3 隧道送往 gNB。UL CL 最大的优点是终端无感知。终端不需要改 IP 地址也不需要重新建立会话网络侧悄悄把一部分流量本地卸载了。对于视频监控、工业控制、车联网等低时延业务这个模型几乎是刚需。配置时要注意分流规则的粒度和优先级比如按目的 IP 网段分流还是按域名分流。规则写得太宽会把不该本地的流量也带走写得太窄又起不到分流效果需要针对业务逐个梳理。4.2 切换场景下的路径切换移动中的终端一旦发生小区切换转发路径也要跟着变。5G 里切换分很多种比如 gNB 内部切换、Xn 接口切换、N2 接口切换但核心目标都一样让用户面隧道从旧基站快速切到新基站同时尽量不中断业务。如果是基于 Xn 的切换源 gNB 会把用户面数据转发给目标 gNB同时目标 gNB 向核心网发起路径切换请求。核心网收到请求后SMF 更新 UPF 侧的用户面信息把 N3 接口的隧道端点从源 gNB 改到目标 gNB。这里有个细节终端 IP 地址不会变因为 UPF 的 PDU 会话锚点没有变变的只是 N3 隧道的对端。如果场景更复杂比如终端跨大区移动原有 UPF 离新基站太远SMF 可能会重新选择一个更近的 UPF。这时涉及中间 UPF 和锚点 UPF 的重新选址以及 N9 隧道的重新建立路径切换影响就大得多。实际组网里核心网往往通过“UPF 选址策略”控制切换时是否迁移 UPF尽量优先保证会话不断而不是一味追求“最优路径”。排障中最常遇到的问题是切换后下行数据丢失。这种现象多数不是隧道建立失败而是旧路径上的数据包还在路上目标 gNB 未及时建立对应的承载或者 UPF 的转发规则更新顺序出了问题。我一般先看切换完成信令里携带的用户面更新结果再看 gNB 是否收到了目标侧隧道信息最后看 UPF 上的会话上下文时间戳基本能定位。4.3 边缘计算对转发模型的影响边缘计算场景是 5G 用户面转发最典型的扩展应用。传统 4G 时代数据必须从基站回传到核心网网关再到互联网5G 时代把 UPF 下沉到园区、机房甚至基站的边缘位置让业务流量在离用户最近的地方完成转发。边缘节点通常有两种组网方式。一种是“UL CL 本地 UPF”的组合本地 UPF 作为分流节点中心 UPF 作为主锚点另一种是“独立 UPF 本地会话”终端建立单独的 PDU 会话直接连到边缘流量完全本地化。两种方式各有取舍前者兼容性好适合公网和本地业务共存的场景后者隔离性更强适合企业专网和切片场景。边缘计算给转发模型带来的最大变化是“N9 接口的使用”。多了一个中间 UPF 之后包从 gNB 到边缘 UPF再通过 N9 到中心 UPF路径上多了一段隧道。排查边缘场景问题时不仅要关心 N3 隧道还要把 N9 隧道抓出来看。我遇到过很多次“业务不通但 UE 看起来正常”的情况最后定位到 N9 接口的隧道 MTU 不一致大包过不去小包没问题典型的转发模型问题。另外边缘场景下 DNS 分流也很常见。UE 发起域名解析时本地 UPF 可以把特定域名解析到本地服务器的地址把其余域名回源到中心 DNS。这个能力通常依赖 UPF 的 DNS 分流规则和本地 DNS 服务器的配合。配置时要验证清楚否则会出现“同一域名不同终端解析结果不同”的怪象。5. 转发模型相关的问题排查与实际心得5.1 抓包看转发链路关键字段别搞错数据包转发模型的排查绕不开抓包。用户面接口里N3 口是最有价值的观察点。这里既有 GTP-U 隧道头又有扩展头里的 QFI还有内层的真实用户数据几乎可以看到转发模型的全部信息。抓包时重点看几个字段外层 IP 头的源和目的地址判断隧道对端是否正确UDP 目的端口GTP-U 固定是 2152GTP-U 头中的 TEID判断这个包属于哪个 PDU 会话扩展头里的 QFI判断 QoS 流标识再往下就是内层 IP 头看用户真实的源目的地址。实际项目里我会在 gNB 侧和 UPF 侧同时抓包然后拿 TEID 和 QFI 对同一段流。如果 gNB 侧收到下行包但 UPF 侧没发问题在 UPF 侧或传输链路如果两侧都有但终端收不到问题就在空口和 DRB 映射上。这个方法看着笨但非常有效。需要注意的是N3 口有时会看到超长包或多片 IP 分片。GTP-U 封装会增加几十字节开销如果底层传输设备开启了较小的 MTU大包会被丢弃。抓包时如果看到 ICMP 需要分片消息反复出现基本可以定位为 MTU 问题。5.2 常见故障与排查顺序我整理了转发模型相关的几个常见故障场景以及对应的排查思路做成了一张速查表故障现象可能原因排查方向PDU 会话建立成功但业务完全不通UPF 没有正确配置转发规则或 N6 路由缺失检查 N4 会话规则、PDR/FAR、UPF 到数据网络的路由下行时延高但上行正常N3 隧道路径绕行、UPF 部署过远、QFI 映射异常检查 N3 路径、QoS 流配置、UPF 节点位置大包不通小包通GTP-U 开销导致 MTU 超限、传输链路分片异常核对端到端 MTU调大需要配合的隧道接口 MTU视频卡顿但其他业务正常QoS 流映射失败QFI 未正确传递抓 N3 口看 QFI检查 UPF 的包检测规则切换瞬间业务闪断N3 隧道更新延迟、源基站数据转发顺序问题看切换信令和用户面更新时间戳边缘业务流量绕到了中心UL CL 分流规则未匹配或未下发检查 UL CL 配置、分流规则优先级排障时我的建议是遵循“从外向里、从控制面到用户面”的顺序。先确认终端有没有建立 PDU 会话再确认 N4 接口上 SMF 有没有把规则下发到 UPF然后是 N3 隧道是否正常最后才看数据网络侧的路由和防火墙。不要一上来就在 UPF 上用 ping 命令去测数据网络因为很多问题不在连通性上而在流分类和隧道标识上。5.3 实操心得汇总做用户面工作久了我积累了一些不算高深但很实用的心得。第一一定要区分“信令通了”和“数据通了”是两回事。PDU 会话建立成功只能说明控制面流程走通用户面隧道有没有真正建立、UPF 的规则有没有生效完全是另一回事。很多初级工程师看到“PDU Session Establishment Accept”就认为问题解决了这是最危险的习惯。第二抓包要多点同时抓不要只抓一个点。只抓 N6 口看不到 QFI只抓 N3 口看不到数据网络侧的回包。最低限度是 N3 口抓一遍、N6 口抓一遍然后把两份抓包按内部五元组和时间戳对齐。我自己做复杂排障时会同时在 gNB、中间传输设备、UPF、应用服务器四个点部署抓包虽然管理工作量大但能大大减少来回猜测时间。第三留意 UPF 上的会话状态。UPF 侧一般会有 show 命令或者管理面接口能看到哪些 PDU 会话处于激活状态、哪些规则已经安装、哪些隧道端点正在使用。这个信息往往是判断问题的最快路径。N4 抓包反映的是 SMF 下发规则的过程但 UPF 最终执行结果还是要看 UPF 本地状态两侧要对照。第四涉及 QoS 流时别忽略 RRC 里的 SDAP 配置。很多无线侧问题最终表现为转发模型问题比如 DRB 映射错误导致高优先级业务被低优先级业务抢占。这时候只抓 N3 口是看不出端倪的因为 N3 口 QFI 标识没问题但空口侧把它放错了队列。需要把 RRC 重配置消息和 UE 日志拿来看才能发现 SDAP 映射异常。第五边缘场景里N9 接口的抓包非常重要但很多人会漏掉。如果终端建立了 PDU 会话数据也到了边缘 UPF但业务还是绕到了中心那一定是有流量没有命中本地分流规则。N9 抓包可以快速判断流量是否从边缘 UPF 被送到了中心 UPF从而反推 UL CL 规则是否生效。第六灵活使用流量模拟和测速工具。用户面验证时我会先用一个简单 ICMP 包验证基本连通性再用大包测试 MTU然后用 TCP/UDP 打流工具验证带宽和时延最后跑真实业务确认 QoS 效果。分阶段加压能避免把“配置错误”误判成“带宽不够”。6. 未完待续后面想聊什么这期的内容本来想一口气写到空口调度但实际梳理下来发现用户面转发模型涉及的面太广光是把 PDU 会话、QoS 流、GTP-U 隧道、UPF 锚点和本地分流讲透篇幅就已经很长了。因此这一次先停在“数据包转发模型的主干路径”上。下一期我准备接着讲空口侧的 QoS 调度和 DRB 更细的映射逻辑以及网络切片 S-NSSAI 在转发面上的具体体现。这两个话题和本期的转发模型息息相关算是把“从核心网到终端”的最后一段补齐。如果你对某个方向更感兴趣也可以在评论区点题我尽量安排。这个系列目前前四篇的话题逐步从架构信令走向了用户面。按照我自己做网络工作多年的习惯看一张网络先不要着急看协议细节而是先搞清楚数据从哪来、到哪去、在哪排队、在哪分叉。希望这一篇的转发模型梳理能帮你建立同样的整体感。后续再遇到业务卡顿、流量绕行、边缘分流不生效这些问题时起码心里有数知道该从哪一段路径下手。