1. 为何要单独聊5G的数据包转发模型5G网络学习系列写到第四篇前面几篇我们聊了5G的架构、接口、协议栈和网元功能很多朋友看完仍然觉得虽然知道“UPF负责转发”却始终没搞明白用户的数据到底是怎么从手机里一步一步走到互联网的。这篇就来把这个链路彻底打通。数据包转发模型通俗讲就是回答三个问题数据从哪来、经过谁、到哪去。看起来简单但5G的转发模型跟4G有本质区别4G时代是“一条道走到黑”的固定承载5G则是“多条路按需选”的灵活转发。如果只知道接口名称而不知道包怎么被封装、怎么被寻址、怎么被分流排障时根本无从下手。这篇文章我打算把转发模型拆成三条主线来讲第一是端到端的完整链路从手机到基站再到核心网最后出公网第二是转发模型的核心机制即GTP隧道封装与QoS流映射第三是几种实际部署中的转发场景包括上行分流器、多锚点等。把这三点串起来5G数据面就算入门了。这篇的内容深度定位在“懂基本原理、能看抓包、会排查常见转发问题”这个级别适合刚学完5G基础架构、正在啃核心网协议栈的工程师也适合做基站、终端、或做网络优化的朋友跨领域补课。2. 转发模型的整体框架数据包的“高速公路网”2.1 5G转发面与控制面分离到底分的是什么要理解数据包转发模型先得理解5G核心网“控制与转发分离”这个设计。控制面负责“决定怎么走”转发面负责“真的去走”。用生活化的类比控制面是交管指挥中心它下发规则说“从A到B走哪条路、哪些车可以走高速”转发面是路上的立交桥和收费闸机它只看包头的标识按规则把包导到对应车道。在4G网络中控制面与转发面虽然也有分离但承载模型很僵硬——一个UE承载对应一条固定的GTP隧道QoS等级绑定在承载上转发路径基本是静态配好的。5G不再使用“承载Bearer”概念而是引入了PDU会话和QoS流。一个PDU会话可以承载多个QoS流允许不同优先级的数据走不同转发路径这种模型更抽象、更灵活但也更难用肉眼直观理解。所以学5G转发模型的第一步是打消“跟4G一样找个隧道从头传到尾”的惯性思维。5G的转发路径是动态的同一个PDU会话内的数据包可以根据业务类型、目标地址、切片标识被分流到不同的UPF甚至可以被复制、被本地卸载、被送到边缘节点。转发模型研究的就是这些“分流规则”如何配合隧道、路由和标识共同生效。2.2 端到端转发链路UE、gNB、UPF、DN各司其职先画一条最基础、最普遍的数据路径也是每个5G用户每天产生流量时几乎都会走的路径UE - gNB - 核心网(AMF/SMF只参与信令) - UPF - 外部数据网络(DN)这条链路中各角色的分工非常明确UE手机终端发起业务数据将IP数据包交给5G协议栈进行用户面封装。gNB基站提供空口接入将UE的空口数据转换成N3接口的GTP-U隧道数据。UPF用户面功能核心网的转发枢纽负责把N3隧道里的数据解封装再根据转发策略通过N6接口送到外部网络或通过N9接口转发给其他UPF。DN数据网络可以理解成互联网、企业内网、或者某个边缘计算平台。这里面有个容易误解的点AMF和SMF虽然在核心网里很重要但他们不碰用户数据。AMF管接入和移动性SMF管会话管理给UPF下发转发规则。数据包真正流经的网元只有gNB和UPF。很多新手抓包时在核心网里找了半天找不到数据流原因就是没有意识到数据面永远只在gNB和UPF之间穿行。2.3 用户面协议栈划分IP数据包在每跳怎么“套娃”数据包在链路上每走一段就要被套一层新的协议头这个过程很像寄快递时“内件装进信封信封外面再套快递袋快递袋外贴快递单”。空口段UE到gNBIP包作为有效载荷交给SDAP层SDAP加上QoS流标识QFI接着PDCP层做头压缩和加密RLC层做分段MAC层做调度复用最终物理层把数据发出去。这一段的封装目标是“在无线信道上可靠、安全地传数据”。N3段gNB到UPFgNB收到空口数据后把IP包取出作为GTP-U协议的载荷。GTP-U头里写入了关键的TEID隧道端点标识外层再套UDP/IP头源IP是gNB的IP目的IP是UPF的IP。这一段的封装目标是把“无线帧格式的数据”变成“能在IP网络上传输的标准IP包”。N6段UPF到DNUPF解掉GTP-U封装还原出原始IP包按普通IP路由规则从N6接口转发出去。这里IP包的源地址是UE的IP地址目的地址就是业务服务器的IP。用抓包工具看如果抓N3接口的流量每一层结构大致是这样的以太网头 - IP头(外层) - UDP头(端口2152) - GTP-U头(TEIDQFI) - IP头(内层/原始包) - TCP/UDP头(原始包) - 业务载荷外层叫传输层封装内层叫用户数据包。理解这个“双层IP”结构是看懂5G数据包转发模型的关键点。3. 核心机制拆解GTP-U隧道、PDU会话与QoS流3.1 GTP-U协议数据包在N3/N9/N4接口上的“快递包装”5G转发面继承了GTP-U协议作为用户面隧道协议协议栈的层次是GTP-U / UDP / IP标准定义里GTP-U头的长度不固定至少要包含8字节的强制字段其中最关键的是TEID。TEID的作用是标识一条隧道方向上的接收端点它由隧道两端各自分配方向和反向的TEID相互独立。也就是说下行方向gNB使用UPF分配的TEID上行方向UPF使用gNB分配的TEID。把TEID想象成“门牌号”——数据包到了UPF所在的服务器光知道IP还不够得靠TEID找到具体是哪条PDU会话的哪一个隧道。这也解释了为什么gNB和UPF之间可以有成千上万个并发会话因为IP是服务器级的地址TEID是隧道级的标识。GTP-U还带一个重要字段叫“报文类型”值为0xFF表示G-PDU用户数据包值为0x01/0x02表示路径管理消息回声请求/响应。路径管理消息用于隧道端点之间的保活探测默认间隔通常是60秒。做抓包分析时看到UDP端口2152且报文类型为0xFF就可以断定是用户面数据如果看到0x01/0x02且没有内层IP包那就是GTP-U的保活消息在“打招呼”。3.2 PDU会话UE访问数据网络的“专属通道”PDU会话是5G网络中的核心概念它本质上是一条从UE到UPF的逻辑通道对应一个数据网络的接入连接。一个UE可以同时建立多个PDU会话分别访问不同的数据网络每个PDU会话有自己的IP地址或多个IP地址。建立PDU会话时UE通过NAS消息N1、会话管理消息发起请求SMF负责决策选择哪个UPF、分配TEID、下发转发规则。SMF通过N4接口的PFCP协议把规则安装到UPF上UPF根据这些规则执行数据包匹配、转发、统计、标记等操作。PFCP协议在N4接口上完成的是“控制面下发规则”例如“对匹配某个QoS流的数据执行丢弃策略”“对这个隧道的数据记录流量统计”。这跟用户面数据流的路径是逻辑分离的控制规则走N4用户数据走N3/N9/N6。很多刚接触核心网的人以为UPF的转发行为是“写死的”实际不是UPF的所有转发行为都是由SMF实时通过PFCP会话下发的。所以PDU会话可以理解为两件事的组合一是UE与核心网之间的信令协商结果二是SMF在UPF上建立的转发表项集合。二者通过PDU会话ID关联起来。3.3 从QoS流到数据无线承载单包标识决定全程待遇5G没有承载所以转发模型里需要一种“跟着包走”的标识机制这就是QFIQoS Flow Identifier。QFI是一个6比特的值取值1到63由SMF在PDU会话建立时分配给某个QoS流。在空口侧SDAP层在每个数据包头上标记QFI在N3隧道上GTP-U头的扩展字段也携带QFI。这样无论数据包被封装到哪一层路由器、基站或UPF都能根据QFI识别这个包所属的QoS流进而执行对应的调度、限速、转发策略。从这个设计能看到5G转发模型的底层思想策略跟着标识走标识跟着数据包走而不是策略跟着“固定的承载”走。数据包在空口进入哪个数据无线承载DRB是由SDAP层根据QFI和映射规则决定DRB与QoS流的映射关系由RRC信令配置可以动态调整。而到了UPF侧则通过QFI查转发规则表决定是本地转发、送往N6、还是送往N9。有个实操经验值得分享排查“某个业务卡顿但其他业务正常”时不要一上来就怀疑空口链路质量先看这个业务的QFI对应的QoS流有没有被UPF做限速或降级QFI值可以在抓包里看到再去核心网侧查该QFI的QoS参数是否匹配业务类型。3.4 反射QoS上行包如何自动学习下行包的QoS标记上行数据包该打哪个QFI传统做法是SMF在PDU会话建立时通过信令下发所有QoS规则。但5G引入了反射QoS机制简单说就是“看下行包用什么QFI上行就照抄”。终端收到一个下行数据包发现这个包带了一个未学习过的QFI终端会自动生成一个对应的上行QoS规则该规则基于包过滤五元组并沿用相同的QFI。这个机制简化了会话建立时的信令开销特别适合对时延敏感、上下行业务高度对称的视频通话等场景。理解反射QoS有助于排障时判断问题归属如果下行视频流畅上行视频卡顿先检查终端是否学到了正确的上行QFI映射。因为反射QoS依赖“先看到下行包”这个前提一旦下行异常或策略网络侧被关闭上行的QoS规则就可能一直为空包只能走默认QFI会被默认规则限速。4. 实现与实操转发规则、隧道参数与抓包验证4.1 N4接口PFCP规则是如何变成UPF转发行径的UPF并不是一个“路由器”它的转发行径严格遵照SMF下发的PFCP分组检测规则PDR与转发规则FAR。PDR定义的是“匹配什么”FAR定义的是“匹配到了干什么”。一组典型的规则可以这样理解规则组件作用示例PDR定义匹配条件匹配源IP10.1.2.3且目的端口80的包FAR定义转发动作封装外层GTP-U头并送到N3接口的X.X.X.XQER定义QoS执行限速5Mbps超速丢弃URR定义用量上报每100MB上报一次流量统计实际操作中大多数核心网设备都支持通过命令行或管理面查看UPF上已经安装的PDR/FAR表。排障的常用动作就是“查UPF上有没有对应PDU会话的规则”如果规则不存在即使GTP隧道能通数据也不会被正确转发因为UPF根本没有这个会话的转发上下文。检查思路可以按这个顺序来确认PDU会话是否建立成功SMF侧是否完成与UPF的N4会话建立在UPF上查看该PDU会话是否已经有下行PDR和FAR确认PDR里的包过滤条件是否覆盖了实际业务流确认FAR里的外层封装参数目的IP、TEID是否与对端一致。4.2 关键参数速查建立一条转发路径需要哪些“坐标”在配置或排查数据包转发隧道时这些参数是绕不开的关键要素隧道端点IPgNB和UPF用于GTP-U通信的IP地址必须路由可达。TEIDDL和UL分别分配下行方向UPF分配TEID给gNB用上行方向gNB分配TEID给UPF用。QFI标识QoS流1-63之间决定数据包在空口和N3上的调度级别。F-TEID接口类型加IP加TEID的组合在PFCP信令中标识一条隧道的具体端点。PDU会话类型IPv4、IPv6或IPv4v6决定UE的数据包地址格式以及UPF如何处理内外层地址。举一个具体例子UE发起一个访问视频服务器的业务PDU会话建立成功后SMF会给gNB发送PDU会话资源建立请求里面包含UL F-TEID也就是gNB分配给该隧道的上行TEID和gNB的N3 IP。SMF同时给UPF安装规则其中包含DL F-TEID由UPF分配。此后UE发出的上行包gNB会封装成外层目的IP为UPF N3 IP、TEID为UPF分配的TEID的GTP-U包下行包则反过来。理解这个表之后抓包时看到GTP-U头的目的TEID就能立刻判断这条包的方向目的TEID是UPF分配的值说明这是下行包目的TEID是gNB分配的值说明这是上行包。4.3 抓包实操三步确认一条PDU会话的数据路径为了不空谈理论这里演示一个在现网中快速确认数据转发路径的方法。前提是你能镜像到gNB或UPF的N3接口流量。第一步先抓到一个GTP-U用户面包确认UDP目的端口是2152GTP-U报头类型是0xFF。第二步看外层IP头。源IP是gNB或UPF的N3地址目的IP是隧道对端地址。这一步确认隧道两端是谁。第三步看GTP-U扩展字段里的QFI再结合隧道建立信令里SMF分配的TEID对照表确认这个包到底属于哪个PDU会话、哪个QoS流。如果同一PDU会话的包既出现在N3接口也出现在N9接口那么说明业务经过了级联的UPF转发。这种情况常见于用户漫游或本地分流场景数据包从第一级UPF上送到第二级UPF。抓两个接口的同一个内层IP包可以对比两段隧道的TEID不同这就是“转发路径经过两级网元”的抓包证据。我在实际项目里踩过这样一个坑某次排查视频业务丢包在N3接口抓到大量重传包但所有GTP-U包的TEID和QFI都正常核心网侧查规则也没异常。后来发现是外层IP头里DSCP标记与传输网络的QoS队列策略不匹配视频流被放入低优先级队列导致拥塞时被优先丢弃。5G用户面数据是两层封装内外层IP的DSCP是独立标记的这点抓包时非常容易忽略。4.4 小型模拟环境没有真实基站也能搭建转发模型验证如果没有真实5G网络环境也可以在实验室里做简化版转发模型验证需要的核心组件是模拟gNB和轻量UPF。模拟gNB的作用是模拟N3接口的GTP-U封装可以用开源工具或者脚本实现。自定义一个封装脚本核心逻辑很简单读取原始IP包在UDP层加上目的端口2152再加上GTP-U头和TEID字段。外层IP用gNB的地址内层IP保持原始包地址。反过来收到的GTP-U包解封装后还原内层IP包就等效于UPF的N3侧行为。轻量UPF可以用通用服务器上跑转发程序来模拟程序注册好PDU会话对应TEID和QFI映射表后对匹配到的GTP-U包做解封装然后按普通IP包路由发出。这个环境验证的是转发模型的核心要点TEID是否互相匹配、内外层地址是否设置正确、QFI能否从GTP-U扩展头里正确解析。跑通后再用Wireshark看抓包整个数据面转发过程就非常直观了。对于有现网接口权限的朋友我建议在测试窗口内做一次拨号业务并用一个持续ping的包来观察转发路径每跳接口都做镜像抓包可以比较同一ICMP请求在空口、N3、N6各段的封装表现差异把三个阶段封装变化记到笔记里以后排查时对照非常有用。5. 几种典型的业务转发模式与场景选型5.1 基础模式单锚点转发适合普通公网业务最常见的转发模式是单PDU会话锚点UPF作为唯一锚点UE通过N3到UPF再由N6出公网。这种模式结构简单、信令开销小适合手机浏览网页、看视频、收发消息等大多数普通业务。单锚点模式的关键特征PDU会话有且只有一个UPF作为PSAPDU会话锚点N9接口不参与转发的场景。UE移动时gNB会切换但只要UPF不变N3隧道就只需要在gNB侧重建转发路径的核心段保持不变。这种模式在网络侧实现最简单但缺点也很明显——所有流量都要绕回锚点UPF访问某个边缘服务器和访问中心网络没有区别时延不是最优。5.2 本地分流模式UL CL让流量“就近下车”为了让数据在靠近用户的边缘节点被处理5G定义了上行分类器UL CL功能。UL CL本质上是UPF的一个功能不是独立网元。它根据SMF下发的分流规则把符合条件的流量直接在本地UPF转发出去剩下的流量再送到原锚点UPF。举个例子某应用服务器部署在园区边缘节点用户在园区内访问该服务器。传统单锚点模式下流量从gNB到中心UPF再绕回园区边缘时延很高。启用UL CL后gNB侧的流量先到达本地UPF本地UPF通过包过滤规则识别目标IP是边缘服务器直接从N6接口转发不送往中心UPF。这里的转发模型会看到两个UPF参与一个本地UPF执行UL CL功能一个中心锚点UPF继续处理剩余流量。N3接口终止在本地UPFN9接口连接本地UPF和中心UPF。抓包时会发现同一业务的不同数据流走了不同的路径。5.3 多锚点模式同一个PDU会话对应多个出口还有一种场景叫多锚点PDU会话允许一个PDU会话建立多个UPF锚点不同锚点通向不同的DNUE按需选择数据走哪个锚点。这个方案常用于多接入场景比如一个会话同时访问互联网和企业内网互联网流量从公网锚点UPF出内网流量从企业专线锚点UPF出两者互不干扰。对比单锚点模型多锚点的优势是“出口选择更多、路径更短”代价是UPF管理复杂度上升SMF要维护多个N4会话上下文。实际部署中需要与UL CL场景区分UL CL是“分流”多锚点是“多归属”UL CL在分流后仍然只有一个锚点出口多归属则有多个独立出口地址。对做方案选型的人来说简单业务优先选单锚点低时延本地访问选UL CL多业务多域接入选多归属但也要意识到多锚点模式对终端和网络侧都有兼容性要求不是所有终端和核心网都支持。5.4 数据包的“加速车道”边缘计算场景下的转发变化在MEC多接入边缘计算场景中数据包转发模型会做大幅调整。边缘计算希望业务在离用户最近的地方完成响应所以数据面往往会在本地UPF上终结N6接口直接连接本地MEC平台。这种场景里有两个关键点一是本地DNS终端访问的应用域名要优先解析到边缘服务器IP这个能力通常由SMF配合本地DNS实现二是分流规则要同时涵盖目标IP和域名维度UPF需要支持按域名分流的能力而传统单锚点模式只按IP路由。MEC场景的转发排障也值得注意如果边缘业务访问失败不要只看UPF转发规则还要检查本地DNS解析是否生效、边缘服务器的路由是否回程到UPF。这里经常出现的问题是边缘服务器回程路由设置错误导致上行请求到了边缘响应却绕到中心网络最终因路径不通而超时。在实际MEC项目里转发模型往往会从“单UPF集中处理”变为“边缘UPF中心UPF分级处理”控制面仍然集中在中心SMF数据面则在边缘终结。这也体现了5G“控制集中、转发分散”的设计思想在真实部署中的落地。6. 转发模型实战从配置到排障6.1 一个完整的业务拨测转发流程记录为了直观展示转发模型的真实工作流程这里记录一次业务拨测的完整链路。模拟终端发起一次网页访问观测各接口的包行为。终端发起访问请求先完成附着和PDU会话建立流程RRC建立后终端发起初始上下文建立请求gNB向AMF注册AMF选择SMF并请求建立PDU会话SMF选择UPF通过PFCP建立N4会话随后SMF向gNB返回PDU会话资源建立结果。此时gNB已经拿到分配好的UL F-TEID和QFI映射规则。数据包开始传送。终端发出TCP SYN包包经SDAP加QFI标记在空口对应的DRB上传向gNB。gNB解空口协议栈后提取原始IP包按QFI查映射表把包封装成GTP-U格式外层目的IP指向UPF N3接口IPTEID指向UPF分配的上行TEID随后经N3发出。UPF收到GTP-U包解封装还原内层IP包用PDR匹配这个包所属的PDU会话和QoS流再按FAR规则通过N6接口向目的服务器转发。服务器回程的TCP SYN-ACK包到达UPFUPF匹配下行规则后封装GTP-U头目的IP指向gNB N3接口IPTEID指向gNB分配的下行TEID回传gNBgNB再通过空口下发给终端。这一套流程里任何一个环节标识不匹配都会导致数据包无法到达目的地。常见的排障方法就是在各接口抓包确认GTP-U包能正常出现、TEID能否对上号、内层IP包是否正确。6.2 常见转发故障速查表现象、原因与排查手段我把平时工作中遇到的最常见的转发故障整理成表方便大家对照排查。故障现象常见原因排查手段UE有信号但完全无法上网PDU会话建立失败或UPF上规则缺失查SMF会话日志确认为何PDU会话失败查UPF的PFCP会话是否存在部分业务能通部分不通分流规则匹配错误或QFI策略限速抓包确认不通业务的五元组核对PDR匹配条件和FAR动作时延很高且出现大量重传转发路径绕路或传输侧丢包对比各接口抓包时延检查外层IP的DSCP是否与QoS队列匹配本地边缘业务无法访问DNS解析到中心地址或边缘回程路由缺失查本地DNS解析结果检查边缘服务器路由表是否有指向UPF N6地址的回程路由切换后业务中断QoS流映射未随切换更新或隧道重建失败查切换信令中是否重建N3隧道核对新gNB侧的F-TEID是否生效这个表并非覆盖所有场景只列出最常见的几类。影响最大的排障经验是任何时候都不要跳过“抓包确认隧道连通性”这一步数据面模型再复杂最终问题的矛头往往就在某个标识或规则不匹配上。6.3 检查转发路径时容易忽略的几个检查点除了明确的接口和参数有几个检查点是排障中最容易被忽略的。第一路径MTU问题。数据包在N3隧道中封装后外层IPUDPGTP-U的额外开销大约有36到40字节如果原包本身接近MTU例如1500字节封装后会超过以太网MTU导致分片甚至丢弃。5G标准里要求N3接口的MTU至少为1600字节但不少底层传输网络默认用1500造成“大包不通、小包通”的奇怪现象。排查方法是测试不同大小的ping包看是否有特定大小以上全部失败。第二UPF的多路径处理。UPF在转发时可能同时存在IPv4与IPv6地址如果PDU会话建立时选择的地址族和业务目标地址不一致也会出现某种协议全通、另一种全不通的现象。第三GTP-U路径管理与用户面数据的区分。如果N3接口网络中存在防火墙或ACL有时防火墙会允许路径管理回声消息通过但拦截用户面GTP-U包表现为隧道看似正常回声检测通过实际业务数据不通。排查时不仅要确认隧道能建还要确认真正的GTP-U数据包能在接口间传输。第四QFI与DRB映射关系。空口侧的QoS调度决定权在基站MAC层如果QFI对应的DRB被配置成了低优先级逻辑信道即使UPF侧转发正常业务依然会感知到抖动或时延。这个层面的问题要结合空口日志综合判断仅抓N3和N6接口的包往往看不出端倪。6.4 转发模型在业务SLA保障中的实际应用数据包转发模型不只是“技术上能通”的问题它直接承载的是业务SLA。比如热门的视频直播、云游戏、工业控制这些业务对时延、可靠性、带宽极敏感只靠单锚点转发很可能满足不了要求。在现网部署中最常见的SLA保障方案是“按QoS流差异化转发”URLLC业务分配高优先级QFI走专用切片或专用UPF路径eMBB业务分配普通QFI走默认路径mMTC业务甚至可以走低优先级路径允许一定程度的拥塞。另外值得关注的是“转发规则的热更新”SMF可以在业务运行中动态修改UPF的PDR/FAR例如网络侧识别到用户进入某个园区覆盖范围后SMF下发新的分流规则把该用户的业务从中心路径切换为园区本地路径。这种能力是传统4G网络难以做到的也是5G转发模型的优势所在。做方案设计时我的经验是先看业务场景对可靠性和时延的要求再决定转发路径复杂度。如果一个业务不需要边缘计算、不强调超低时延没必要为了“技术先进”启用UL CL或多锚点增加网络复杂度往往也增加故障点。7. 总结一些转发模型排查时的个人心得前面写了不少细节最后梳理一下我个人实际工作中的体会。第一个心得5G数据包转发模型的核心不是“接口”而是“标识”。接口只是物理通道真正决定包怎么走的是QFI、TEID、PDU会话ID与规则表的匹配关系。排障时把每个标识对应关系梳理清楚问题就解决了一大半。第二个心得抓包是理解转发模型最快的工具。建议工程师花时间学会看GTP-U头里的TEID和QFI会用Wireshark过滤GTP-U数据能快速判断一条流的方向、路径和QoS等级。这套技能在5G核心网排障里的价值被严重低估。第三个心得切莫忽略“外层网络承载”的影响。5G数据包有时候通与不通的问题不在5G本身而在承载5G数据包的底层IP传输网包括MTU、QoS队列、防火墙策略。把内层包的逻辑打通的同时也要关注承载网络的质量与配置。这篇先写到这后续会继续更新5G网络学习系列的第五篇重点讲PFCP协议在N4接口上的详细流程把SMF和UPF之间的控制面交互展开讲清楚。到时候见。 
长河君 · 2026/10/17 22:31:13 · 阅读 1.2k 5G数据包转发模型详解：从GTP-U隧道到QoS流识别
1. 为何要单独聊5G的数据包转发模型5G网络学习系列写到第四篇前面几篇我们聊了5G的架构、接口、协议栈和网元功能很多朋友看完仍然觉得虽然知道“UPF负责转发”却始终没搞明白用户的数据到底是怎么从手机里一步一步走到互联网的。这篇就来把这个链路彻底打通。数据包转发模型通俗讲就是回答三个问题数据从哪来、经过谁、到哪去。看起来简单但5G的转发模型跟4G有本质区别4G时代是“一条道走到黑”的固定承载5G则是“多条路按需选”的灵活转发。如果只知道接口名称而不知道包怎么被封装、怎么被寻址、怎么被分流排障时根本无从下手。这篇文章我打算把转发模型拆成三条主线来讲第一是端到端的完整链路从手机到基站再到核心网最后出公网第二是转发模型的核心机制即GTP隧道封装与QoS流映射第三是几种实际部署中的转发场景包括上行分流器、多锚点等。把这三点串起来5G数据面就算入门了。这篇的内容深度定位在“懂基本原理、能看抓包、会排查常见转发问题”这个级别适合刚学完5G基础架构、正在啃核心网协议栈的工程师也适合做基站、终端、或做网络优化的朋友跨领域补课。2. 转发模型的整体框架数据包的“高速公路网”2.1 5G转发面与控制面分离到底分的是什么要理解数据包转发模型先得理解5G核心网“控制与转发分离”这个设计。控制面负责“决定怎么走”转发面负责“真的去走”。用生活化的类比控制面是交管指挥中心它下发规则说“从A到B走哪条路、哪些车可以走高速”转发面是路上的立交桥和收费闸机它只看包头的标识按规则把包导到对应车道。在4G网络中控制面与转发面虽然也有分离但承载模型很僵硬——一个UE承载对应一条固定的GTP隧道QoS等级绑定在承载上转发路径基本是静态配好的。5G不再使用“承载Bearer”概念而是引入了PDU会话和QoS流。一个PDU会话可以承载多个QoS流允许不同优先级的数据走不同转发路径这种模型更抽象、更灵活但也更难用肉眼直观理解。所以学5G转发模型的第一步是打消“跟4G一样找个隧道从头传到尾”的惯性思维。5G的转发路径是动态的同一个PDU会话内的数据包可以根据业务类型、目标地址、切片标识被分流到不同的UPF甚至可以被复制、被本地卸载、被送到边缘节点。转发模型研究的就是这些“分流规则”如何配合隧道、路由和标识共同生效。2.2 端到端转发链路UE、gNB、UPF、DN各司其职先画一条最基础、最普遍的数据路径也是每个5G用户每天产生流量时几乎都会走的路径UE - gNB - 核心网(AMF/SMF只参与信令) - UPF - 外部数据网络(DN)这条链路中各角色的分工非常明确UE手机终端发起业务数据将IP数据包交给5G协议栈进行用户面封装。gNB基站提供空口接入将UE的空口数据转换成N3接口的GTP-U隧道数据。UPF用户面功能核心网的转发枢纽负责把N3隧道里的数据解封装再根据转发策略通过N6接口送到外部网络或通过N9接口转发给其他UPF。DN数据网络可以理解成互联网、企业内网、或者某个边缘计算平台。这里面有个容易误解的点AMF和SMF虽然在核心网里很重要但他们不碰用户数据。AMF管接入和移动性SMF管会话管理给UPF下发转发规则。数据包真正流经的网元只有gNB和UPF。很多新手抓包时在核心网里找了半天找不到数据流原因就是没有意识到数据面永远只在gNB和UPF之间穿行。2.3 用户面协议栈划分IP数据包在每跳怎么“套娃”数据包在链路上每走一段就要被套一层新的协议头这个过程很像寄快递时“内件装进信封信封外面再套快递袋快递袋外贴快递单”。空口段UE到gNBIP包作为有效载荷交给SDAP层SDAP加上QoS流标识QFI接着PDCP层做头压缩和加密RLC层做分段MAC层做调度复用最终物理层把数据发出去。这一段的封装目标是“在无线信道上可靠、安全地传数据”。N3段gNB到UPFgNB收到空口数据后把IP包取出作为GTP-U协议的载荷。GTP-U头里写入了关键的TEID隧道端点标识外层再套UDP/IP头源IP是gNB的IP目的IP是UPF的IP。这一段的封装目标是把“无线帧格式的数据”变成“能在IP网络上传输的标准IP包”。N6段UPF到DNUPF解掉GTP-U封装还原出原始IP包按普通IP路由规则从N6接口转发出去。这里IP包的源地址是UE的IP地址目的地址就是业务服务器的IP。用抓包工具看如果抓N3接口的流量每一层结构大致是这样的以太网头 - IP头(外层) - UDP头(端口2152) - GTP-U头(TEIDQFI) - IP头(内层/原始包) - TCP/UDP头(原始包) - 业务载荷外层叫传输层封装内层叫用户数据包。理解这个“双层IP”结构是看懂5G数据包转发模型的关键点。3. 核心机制拆解GTP-U隧道、PDU会话与QoS流3.1 GTP-U协议数据包在N3/N9/N4接口上的“快递包装”5G转发面继承了GTP-U协议作为用户面隧道协议协议栈的层次是GTP-U / UDP / IP标准定义里GTP-U头的长度不固定至少要包含8字节的强制字段其中最关键的是TEID。TEID的作用是标识一条隧道方向上的接收端点它由隧道两端各自分配方向和反向的TEID相互独立。也就是说下行方向gNB使用UPF分配的TEID上行方向UPF使用gNB分配的TEID。把TEID想象成“门牌号”——数据包到了UPF所在的服务器光知道IP还不够得靠TEID找到具体是哪条PDU会话的哪一个隧道。这也解释了为什么gNB和UPF之间可以有成千上万个并发会话因为IP是服务器级的地址TEID是隧道级的标识。GTP-U还带一个重要字段叫“报文类型”值为0xFF表示G-PDU用户数据包值为0x01/0x02表示路径管理消息回声请求/响应。路径管理消息用于隧道端点之间的保活探测默认间隔通常是60秒。做抓包分析时看到UDP端口2152且报文类型为0xFF就可以断定是用户面数据如果看到0x01/0x02且没有内层IP包那就是GTP-U的保活消息在“打招呼”。3.2 PDU会话UE访问数据网络的“专属通道”PDU会话是5G网络中的核心概念它本质上是一条从UE到UPF的逻辑通道对应一个数据网络的接入连接。一个UE可以同时建立多个PDU会话分别访问不同的数据网络每个PDU会话有自己的IP地址或多个IP地址。建立PDU会话时UE通过NAS消息N1、会话管理消息发起请求SMF负责决策选择哪个UPF、分配TEID、下发转发规则。SMF通过N4接口的PFCP协议把规则安装到UPF上UPF根据这些规则执行数据包匹配、转发、统计、标记等操作。PFCP协议在N4接口上完成的是“控制面下发规则”例如“对匹配某个QoS流的数据执行丢弃策略”“对这个隧道的数据记录流量统计”。这跟用户面数据流的路径是逻辑分离的控制规则走N4用户数据走N3/N9/N6。很多刚接触核心网的人以为UPF的转发行为是“写死的”实际不是UPF的所有转发行为都是由SMF实时通过PFCP会话下发的。所以PDU会话可以理解为两件事的组合一是UE与核心网之间的信令协商结果二是SMF在UPF上建立的转发表项集合。二者通过PDU会话ID关联起来。3.3 从QoS流到数据无线承载单包标识决定全程待遇5G没有承载所以转发模型里需要一种“跟着包走”的标识机制这就是QFIQoS Flow Identifier。QFI是一个6比特的值取值1到63由SMF在PDU会话建立时分配给某个QoS流。在空口侧SDAP层在每个数据包头上标记QFI在N3隧道上GTP-U头的扩展字段也携带QFI。这样无论数据包被封装到哪一层路由器、基站或UPF都能根据QFI识别这个包所属的QoS流进而执行对应的调度、限速、转发策略。从这个设计能看到5G转发模型的底层思想策略跟着标识走标识跟着数据包走而不是策略跟着“固定的承载”走。数据包在空口进入哪个数据无线承载DRB是由SDAP层根据QFI和映射规则决定DRB与QoS流的映射关系由RRC信令配置可以动态调整。而到了UPF侧则通过QFI查转发规则表决定是本地转发、送往N6、还是送往N9。有个实操经验值得分享排查“某个业务卡顿但其他业务正常”时不要一上来就怀疑空口链路质量先看这个业务的QFI对应的QoS流有没有被UPF做限速或降级QFI值可以在抓包里看到再去核心网侧查该QFI的QoS参数是否匹配业务类型。3.4 反射QoS上行包如何自动学习下行包的QoS标记上行数据包该打哪个QFI传统做法是SMF在PDU会话建立时通过信令下发所有QoS规则。但5G引入了反射QoS机制简单说就是“看下行包用什么QFI上行就照抄”。终端收到一个下行数据包发现这个包带了一个未学习过的QFI终端会自动生成一个对应的上行QoS规则该规则基于包过滤五元组并沿用相同的QFI。这个机制简化了会话建立时的信令开销特别适合对时延敏感、上下行业务高度对称的视频通话等场景。理解反射QoS有助于排障时判断问题归属如果下行视频流畅上行视频卡顿先检查终端是否学到了正确的上行QFI映射。因为反射QoS依赖“先看到下行包”这个前提一旦下行异常或策略网络侧被关闭上行的QoS规则就可能一直为空包只能走默认QFI会被默认规则限速。4. 实现与实操转发规则、隧道参数与抓包验证4.1 N4接口PFCP规则是如何变成UPF转发行径的UPF并不是一个“路由器”它的转发行径严格遵照SMF下发的PFCP分组检测规则PDR与转发规则FAR。PDR定义的是“匹配什么”FAR定义的是“匹配到了干什么”。一组典型的规则可以这样理解规则组件作用示例PDR定义匹配条件匹配源IP10.1.2.3且目的端口80的包FAR定义转发动作封装外层GTP-U头并送到N3接口的X.X.X.XQER定义QoS执行限速5Mbps超速丢弃URR定义用量上报每100MB上报一次流量统计实际操作中大多数核心网设备都支持通过命令行或管理面查看UPF上已经安装的PDR/FAR表。排障的常用动作就是“查UPF上有没有对应PDU会话的规则”如果规则不存在即使GTP隧道能通数据也不会被正确转发因为UPF根本没有这个会话的转发上下文。检查思路可以按这个顺序来确认PDU会话是否建立成功SMF侧是否完成与UPF的N4会话建立在UPF上查看该PDU会话是否已经有下行PDR和FAR确认PDR里的包过滤条件是否覆盖了实际业务流确认FAR里的外层封装参数目的IP、TEID是否与对端一致。4.2 关键参数速查建立一条转发路径需要哪些“坐标”在配置或排查数据包转发隧道时这些参数是绕不开的关键要素隧道端点IPgNB和UPF用于GTP-U通信的IP地址必须路由可达。TEIDDL和UL分别分配下行方向UPF分配TEID给gNB用上行方向gNB分配TEID给UPF用。QFI标识QoS流1-63之间决定数据包在空口和N3上的调度级别。F-TEID接口类型加IP加TEID的组合在PFCP信令中标识一条隧道的具体端点。PDU会话类型IPv4、IPv6或IPv4v6决定UE的数据包地址格式以及UPF如何处理内外层地址。举一个具体例子UE发起一个访问视频服务器的业务PDU会话建立成功后SMF会给gNB发送PDU会话资源建立请求里面包含UL F-TEID也就是gNB分配给该隧道的上行TEID和gNB的N3 IP。SMF同时给UPF安装规则其中包含DL F-TEID由UPF分配。此后UE发出的上行包gNB会封装成外层目的IP为UPF N3 IP、TEID为UPF分配的TEID的GTP-U包下行包则反过来。理解这个表之后抓包时看到GTP-U头的目的TEID就能立刻判断这条包的方向目的TEID是UPF分配的值说明这是下行包目的TEID是gNB分配的值说明这是上行包。4.3 抓包实操三步确认一条PDU会话的数据路径为了不空谈理论这里演示一个在现网中快速确认数据转发路径的方法。前提是你能镜像到gNB或UPF的N3接口流量。第一步先抓到一个GTP-U用户面包确认UDP目的端口是2152GTP-U报头类型是0xFF。第二步看外层IP头。源IP是gNB或UPF的N3地址目的IP是隧道对端地址。这一步确认隧道两端是谁。第三步看GTP-U扩展字段里的QFI再结合隧道建立信令里SMF分配的TEID对照表确认这个包到底属于哪个PDU会话、哪个QoS流。如果同一PDU会话的包既出现在N3接口也出现在N9接口那么说明业务经过了级联的UPF转发。这种情况常见于用户漫游或本地分流场景数据包从第一级UPF上送到第二级UPF。抓两个接口的同一个内层IP包可以对比两段隧道的TEID不同这就是“转发路径经过两级网元”的抓包证据。我在实际项目里踩过这样一个坑某次排查视频业务丢包在N3接口抓到大量重传包但所有GTP-U包的TEID和QFI都正常核心网侧查规则也没异常。后来发现是外层IP头里DSCP标记与传输网络的QoS队列策略不匹配视频流被放入低优先级队列导致拥塞时被优先丢弃。5G用户面数据是两层封装内外层IP的DSCP是独立标记的这点抓包时非常容易忽略。4.4 小型模拟环境没有真实基站也能搭建转发模型验证如果没有真实5G网络环境也可以在实验室里做简化版转发模型验证需要的核心组件是模拟gNB和轻量UPF。模拟gNB的作用是模拟N3接口的GTP-U封装可以用开源工具或者脚本实现。自定义一个封装脚本核心逻辑很简单读取原始IP包在UDP层加上目的端口2152再加上GTP-U头和TEID字段。外层IP用gNB的地址内层IP保持原始包地址。反过来收到的GTP-U包解封装后还原内层IP包就等效于UPF的N3侧行为。轻量UPF可以用通用服务器上跑转发程序来模拟程序注册好PDU会话对应TEID和QFI映射表后对匹配到的GTP-U包做解封装然后按普通IP包路由发出。这个环境验证的是转发模型的核心要点TEID是否互相匹配、内外层地址是否设置正确、QFI能否从GTP-U扩展头里正确解析。跑通后再用Wireshark看抓包整个数据面转发过程就非常直观了。对于有现网接口权限的朋友我建议在测试窗口内做一次拨号业务并用一个持续ping的包来观察转发路径每跳接口都做镜像抓包可以比较同一ICMP请求在空口、N3、N6各段的封装表现差异把三个阶段封装变化记到笔记里以后排查时对照非常有用。5. 几种典型的业务转发模式与场景选型5.1 基础模式单锚点转发适合普通公网业务最常见的转发模式是单PDU会话锚点UPF作为唯一锚点UE通过N3到UPF再由N6出公网。这种模式结构简单、信令开销小适合手机浏览网页、看视频、收发消息等大多数普通业务。单锚点模式的关键特征PDU会话有且只有一个UPF作为PSAPDU会话锚点N9接口不参与转发的场景。UE移动时gNB会切换但只要UPF不变N3隧道就只需要在gNB侧重建转发路径的核心段保持不变。这种模式在网络侧实现最简单但缺点也很明显——所有流量都要绕回锚点UPF访问某个边缘服务器和访问中心网络没有区别时延不是最优。5.2 本地分流模式UL CL让流量“就近下车”为了让数据在靠近用户的边缘节点被处理5G定义了上行分类器UL CL功能。UL CL本质上是UPF的一个功能不是独立网元。它根据SMF下发的分流规则把符合条件的流量直接在本地UPF转发出去剩下的流量再送到原锚点UPF。举个例子某应用服务器部署在园区边缘节点用户在园区内访问该服务器。传统单锚点模式下流量从gNB到中心UPF再绕回园区边缘时延很高。启用UL CL后gNB侧的流量先到达本地UPF本地UPF通过包过滤规则识别目标IP是边缘服务器直接从N6接口转发不送往中心UPF。这里的转发模型会看到两个UPF参与一个本地UPF执行UL CL功能一个中心锚点UPF继续处理剩余流量。N3接口终止在本地UPFN9接口连接本地UPF和中心UPF。抓包时会发现同一业务的不同数据流走了不同的路径。5.3 多锚点模式同一个PDU会话对应多个出口还有一种场景叫多锚点PDU会话允许一个PDU会话建立多个UPF锚点不同锚点通向不同的DNUE按需选择数据走哪个锚点。这个方案常用于多接入场景比如一个会话同时访问互联网和企业内网互联网流量从公网锚点UPF出内网流量从企业专线锚点UPF出两者互不干扰。对比单锚点模型多锚点的优势是“出口选择更多、路径更短”代价是UPF管理复杂度上升SMF要维护多个N4会话上下文。实际部署中需要与UL CL场景区分UL CL是“分流”多锚点是“多归属”UL CL在分流后仍然只有一个锚点出口多归属则有多个独立出口地址。对做方案选型的人来说简单业务优先选单锚点低时延本地访问选UL CL多业务多域接入选多归属但也要意识到多锚点模式对终端和网络侧都有兼容性要求不是所有终端和核心网都支持。5.4 数据包的“加速车道”边缘计算场景下的转发变化在MEC多接入边缘计算场景中数据包转发模型会做大幅调整。边缘计算希望业务在离用户最近的地方完成响应所以数据面往往会在本地UPF上终结N6接口直接连接本地MEC平台。这种场景里有两个关键点一是本地DNS终端访问的应用域名要优先解析到边缘服务器IP这个能力通常由SMF配合本地DNS实现二是分流规则要同时涵盖目标IP和域名维度UPF需要支持按域名分流的能力而传统单锚点模式只按IP路由。MEC场景的转发排障也值得注意如果边缘业务访问失败不要只看UPF转发规则还要检查本地DNS解析是否生效、边缘服务器的路由是否回程到UPF。这里经常出现的问题是边缘服务器回程路由设置错误导致上行请求到了边缘响应却绕到中心网络最终因路径不通而超时。在实际MEC项目里转发模型往往会从“单UPF集中处理”变为“边缘UPF中心UPF分级处理”控制面仍然集中在中心SMF数据面则在边缘终结。这也体现了5G“控制集中、转发分散”的设计思想在真实部署中的落地。6. 转发模型实战从配置到排障6.1 一个完整的业务拨测转发流程记录为了直观展示转发模型的真实工作流程这里记录一次业务拨测的完整链路。模拟终端发起一次网页访问观测各接口的包行为。终端发起访问请求先完成附着和PDU会话建立流程RRC建立后终端发起初始上下文建立请求gNB向AMF注册AMF选择SMF并请求建立PDU会话SMF选择UPF通过PFCP建立N4会话随后SMF向gNB返回PDU会话资源建立结果。此时gNB已经拿到分配好的UL F-TEID和QFI映射规则。数据包开始传送。终端发出TCP SYN包包经SDAP加QFI标记在空口对应的DRB上传向gNB。gNB解空口协议栈后提取原始IP包按QFI查映射表把包封装成GTP-U格式外层目的IP指向UPF N3接口IPTEID指向UPF分配的上行TEID随后经N3发出。UPF收到GTP-U包解封装还原内层IP包用PDR匹配这个包所属的PDU会话和QoS流再按FAR规则通过N6接口向目的服务器转发。服务器回程的TCP SYN-ACK包到达UPFUPF匹配下行规则后封装GTP-U头目的IP指向gNB N3接口IPTEID指向gNB分配的下行TEID回传gNBgNB再通过空口下发给终端。这一套流程里任何一个环节标识不匹配都会导致数据包无法到达目的地。常见的排障方法就是在各接口抓包确认GTP-U包能正常出现、TEID能否对上号、内层IP包是否正确。6.2 常见转发故障速查表现象、原因与排查手段我把平时工作中遇到的最常见的转发故障整理成表方便大家对照排查。故障现象常见原因排查手段UE有信号但完全无法上网PDU会话建立失败或UPF上规则缺失查SMF会话日志确认为何PDU会话失败查UPF的PFCP会话是否存在部分业务能通部分不通分流规则匹配错误或QFI策略限速抓包确认不通业务的五元组核对PDR匹配条件和FAR动作时延很高且出现大量重传转发路径绕路或传输侧丢包对比各接口抓包时延检查外层IP的DSCP是否与QoS队列匹配本地边缘业务无法访问DNS解析到中心地址或边缘回程路由缺失查本地DNS解析结果检查边缘服务器路由表是否有指向UPF N6地址的回程路由切换后业务中断QoS流映射未随切换更新或隧道重建失败查切换信令中是否重建N3隧道核对新gNB侧的F-TEID是否生效这个表并非覆盖所有场景只列出最常见的几类。影响最大的排障经验是任何时候都不要跳过“抓包确认隧道连通性”这一步数据面模型再复杂最终问题的矛头往往就在某个标识或规则不匹配上。6.3 检查转发路径时容易忽略的几个检查点除了明确的接口和参数有几个检查点是排障中最容易被忽略的。第一路径MTU问题。数据包在N3隧道中封装后外层IPUDPGTP-U的额外开销大约有36到40字节如果原包本身接近MTU例如1500字节封装后会超过以太网MTU导致分片甚至丢弃。5G标准里要求N3接口的MTU至少为1600字节但不少底层传输网络默认用1500造成“大包不通、小包通”的奇怪现象。排查方法是测试不同大小的ping包看是否有特定大小以上全部失败。第二UPF的多路径处理。UPF在转发时可能同时存在IPv4与IPv6地址如果PDU会话建立时选择的地址族和业务目标地址不一致也会出现某种协议全通、另一种全不通的现象。第三GTP-U路径管理与用户面数据的区分。如果N3接口网络中存在防火墙或ACL有时防火墙会允许路径管理回声消息通过但拦截用户面GTP-U包表现为隧道看似正常回声检测通过实际业务数据不通。排查时不仅要确认隧道能建还要确认真正的GTP-U数据包能在接口间传输。第四QFI与DRB映射关系。空口侧的QoS调度决定权在基站MAC层如果QFI对应的DRB被配置成了低优先级逻辑信道即使UPF侧转发正常业务依然会感知到抖动或时延。这个层面的问题要结合空口日志综合判断仅抓N3和N6接口的包往往看不出端倪。6.4 转发模型在业务SLA保障中的实际应用数据包转发模型不只是“技术上能通”的问题它直接承载的是业务SLA。比如热门的视频直播、云游戏、工业控制这些业务对时延、可靠性、带宽极敏感只靠单锚点转发很可能满足不了要求。在现网部署中最常见的SLA保障方案是“按QoS流差异化转发”URLLC业务分配高优先级QFI走专用切片或专用UPF路径eMBB业务分配普通QFI走默认路径mMTC业务甚至可以走低优先级路径允许一定程度的拥塞。另外值得关注的是“转发规则的热更新”SMF可以在业务运行中动态修改UPF的PDR/FAR例如网络侧识别到用户进入某个园区覆盖范围后SMF下发新的分流规则把该用户的业务从中心路径切换为园区本地路径。这种能力是传统4G网络难以做到的也是5G转发模型的优势所在。做方案设计时我的经验是先看业务场景对可靠性和时延的要求再决定转发路径复杂度。如果一个业务不需要边缘计算、不强调超低时延没必要为了“技术先进”启用UL CL或多锚点增加网络复杂度往往也增加故障点。7. 总结一些转发模型排查时的个人心得前面写了不少细节最后梳理一下我个人实际工作中的体会。第一个心得5G数据包转发模型的核心不是“接口”而是“标识”。接口只是物理通道真正决定包怎么走的是QFI、TEID、PDU会话ID与规则表的匹配关系。排障时把每个标识对应关系梳理清楚问题就解决了一大半。第二个心得抓包是理解转发模型最快的工具。建议工程师花时间学会看GTP-U头里的TEID和QFI会用Wireshark过滤GTP-U数据能快速判断一条流的方向、路径和QoS等级。这套技能在5G核心网排障里的价值被严重低估。第三个心得切莫忽略“外层网络承载”的影响。5G数据包有时候通与不通的问题不在5G本身而在承载5G数据包的底层IP传输网包括MTU、QoS队列、防火墙策略。把内层包的逻辑打通的同时也要关注承载网络的质量与配置。这篇先写到这后续会继续更新5G网络学习系列的第五篇重点讲PFCP协议在N4接口上的详细流程把SMF和UPF之间的控制面交互展开讲清楚。到时候见。