1. 先从一张端到端路径图说起做5G核心网的人几乎每天都会看到“数据包转发模型”这几个字。5G核心网的控制面和用户面分离之后用户面功能UPF成了数据转发的绝对主角而数据包转发模型Packet Forwarding Model正是描述UE发出的数据包从空口下来之后怎样一路穿过基站、核心网最后到达外部数据网络的那套“交通规则”。简单说数据包转发模型是5G核心网里一次PDU会话建立之后用户面数据在gNB和UPF之间、以及UPF和DN之间应当如何识别、如何标记、如何封装、如何转发的完整约定。它规定了QoS流应该怎么映射、GTP-U隧道该怎么建、数据包进入UPF后按什么规则被检测和转发、计费和限速又卡在哪个环节。如果没有这套模型UPF就只是一台普通路由器根本谈不上“会话级”“流级”的精细化调度。这篇文章适合三类人看一是刚入行、正在啃3GPP规范却被TS 23.501和TS 29.244绕晕的工程师二是做核心网集成和运维、经常被N3口丢包和速率异常折磨的交付同事三是准备做5G专网、边缘计算方案选型的技术负责人。我会结合实际排障经验和开源核心网项目里的实现方式把这套模型里最关键的几层拆开讲透。2. 转发模型的起点QoS流决定数据包的“身份”2.1 QoS流就是PDU会话里的车道划分数据包转发模型的核心概念是QoS流英文叫QoS Flow。一个PDU会话建立后UE和网络之间会有多条逻辑通道这些通道就是QoS流。你可以把PDU会话理解成一条高速公路QoS流就是上面的不同车道有的车道走紧急车辆保证低时延高优先级有的车道走普通货物能跑就行。3GPP规定每个PDU会话最多可以建64个QoS流每个QoS流用一个QoS Flow IdentifierQFI来标识这个QFI在PDU会话内唯一范围是0到63。数据包进到核心网之后靠QFI就能明确知道自己属于哪条车道该享受什么待遇。QoS流的属性由一套QoS参数描述其中包括5QI5G QoS Identifier、分配和保留优先级ARP、保证流比特率GFBR、最大流比特率MFBR等。实际项目里最常见的场景是同一个PDU会话里同时跑VoNR语音和普通上网流量。语音业务走5QI1的GBR QoS流保障带宽和时延网页浏览走5QI9的Non-GBR QoS流有空闲带宽才用。这个区分不是靠UPF自己猜的而是由SMF在PDU会话建立或修改流程中通过N4会话建立请求把QoS规则和QoS profile分别下发给UE侧网络和UPF形成端到端的映射链。2.2 上行数据包怎么找自己的QoS流上行方向数据包从终端出发第一个要解决的问题是“我这个包该走哪条QoS流”。终端并不傻它会根据SMF下发的QoS规则来匹配。QoS规则里包含Packet Filter包过滤器、优先级Precedence和QFI。包过滤器匹配五元组、应用标识或者以太网帧头等信息优先级描述多条规则冲突时谁说了算。终端把上行数据包按QoS规则匹配后打上对应的QFI然后通过空口送到gNB。gNB看到这个包带什么QFI、QoS profile要求什么时延和丢包率就会把它映射到对应的DRBData Radio Bearer上。注意QoS流到DRB的映射是gNB决定的核心网只把QoS参数告诉gNBgNB根据无线资源情况决定多个QoS流合流到一个DRB还是一个QoS流独占一个DRB。很多刚从核心网转看接入网的同学容易在这里踩坑总以为QFI和DRB是一对一实际完全不是。2.3 下行数据包由SDF模板说了算下行方向数据包从外部网络进入UPF。这时候UPF要做的事情是识别这个数据包属于哪个PDU会话进一步再识别它属于哪个QoS流。识别依据不是看IP五元组这么简单而是靠SMF通过PFCP协议下发的PDRPacket Detection Rule里面的PDIPacket Detection Information其中就包含SDF模板。SDF模板可能匹配源/目的IP、端口号、DSCP标记等。举个例子一个视频网站的下行视频流SMF预先给UPF下发PDRPDI里匹配视频服务器的IP和端口命中后把包映射到QFI4的QoS流上再通过NG-U隧道发给gNB。gNB根据QFI查到QoS profile里的5QI选择对应DRB发给终端。这样下行视频流就能得到专用承载的带宽保障而不是和普通流量混在一起抢资源。2.4 反射式QoS偷偷懒也能干活规范里还设计了一种反射式QoSReflective QoS这个机制很有意思。传统模式下每个上行数据包都要靠QoS规则匹配SMF要显式下发规则反射式QoS允许终端从下行数据包里“学”到QoS流标识。终端收到一个下行包看到IP头里的QFI以及GTP-U头里的反射QoS指示RQI之后自动生成一条上行QoS规则把后续的上行包也用同样的QFI发送。这个机制的好处是省去大量的QoS规则下发信令适合下行流量占比极高、应用流量特征又很难提前静态配置的场景。缺点也明显终端支持能力参差不齐而且反射式规则有老化时间一旦长时间没下行包触发规则可能失效。我在实际测试里发现很多商用终端默认就不开这个功能所以它更多是规范里的“备选项”真正大规模落地还是要靠显式规则下发。3. N3接口与GTP-U封装隧道里的数据包到底长什么样3.1 为什么5G还在用GTP-U5G核心网用户面接口N3连接gNB和UPFN6连接UPF和DNN9连接两个UPF。N3和N9接口的转发封装选的是GTP-U协议。按现在的眼光看GTP-U是一个“年纪很大”的协议从3G时代就开始用但3GPP选择继续使用它并不是因为懒而是因为GTP-U天然支持隧道化转发、多会话复用、用户面路径管理而且产业链支持非常成熟。GTP-U隧道通过TEIDTunnel Endpoint Identifier区分不同的PDU会话。TEID是32比特的标识由隧道的接收端分配。注意这里的表述很关键gNB侧建立NG-U隧道时TEID由gNB分配然后通过信令告诉核心网UPF侧的TEID由UPF分配同样通过信令交互。严格说每个方向都有自己的TEID不是一条隧道共用一个。3.2 一个真实的GTP-U报文拆解用wireshark抓一个N3口的包你会在GTP-U头里看到这些关键字段版本号Version固定为1表示GTPv1。PT协议类型值为1表示GTP-U。Message Type0xFF表示G-PDU也就是用户数据包。如果值是别的比如0x26Echo Request那说明隧道管理消息和用户数据混在同一个端口上。TEID接收端分配的逻辑隧道标识。上行方向gNB发给UPF的包TEID由UPF分配下行方向UPF发给gNB的包TEID由gNB分配。两个方向完全独立。QFI注意GTP-U扩展头里可以携带PDU Session Container这里面才放着QFI。泛型封装时QFI放在这个扩展头的前4个比特里另外还有PNPDU Number、RQI等字段。只有GTP头部可选字段齐全时UPF才能识别QoS流。实际抓包中经常遇到的问题是某些UPF实现或者虚拟化网元在转发时把扩展头里面的QFI丢了导致gNB收到包之后不知道这个包属于哪个QoS流只能按默认承载处理。这种问题从端到端的传输层看不出来必须拆到GTP-U头层次才能发现。3.3 TEID分配原则和常见误区有个细节必须单独提醒。TEID分配遵循“接收方主导”原则发送方使用接收方分配的TEID来封装数据包所以你在gNB侧抓包看到的GTP-U头TEID应该是UPF分给gNB的用于标识gNB发出的上行数据包的目的隧道。很多排查现场A同事说“我看到TEID是gNB的IP关联的”B同事说“不对TEID明明是UPF分配的”其实都没错只是没说明白方向。上行包和下行包的TEID本来就不一样。我在现网遇到过一个典型的TEID问题某UPF迁移后新旧UPF地址做了浮动但SMF里缓存了旧的N3隧道信息导致gNB侧依然往旧TEID发包包到了新UPF后因为TEID查不到会话被直接丢弃。表现形式就是UE已经建立了PDU会话但业务流量一直上不来核心网侧看上下文又正常。抓包一看N3口全是GTP-U Error Indication。排查思路就是先把TEID对应关系捋清楚再判断是SMF的问题还是UPF转发面状态的问题。4. UPF内部的核心PDR/FAR/QER/URR怎么协同工作4.1 PDR是数据包检测的入口UPF作为一个用户面网元它不像普通路由器那样只做目的IP查表它要做的匹配粒度可以精确到某个UE的某个PDU会话的某个QoS流的某个应用类型。3GPP在TS 29.244里定义了一套规则体系其中最核心的就是PDRPacket Detection Rule。PDR的作用是定义“什么样的数据包会被识别出来”它里面包含了PDIPDI里有Source Interface数据包从哪个接口来的比如N3还是N6。F-TEID如果是N3口来的包这里写UPF侧的GTP-U TEID用来匹配不同的PDU会话。Network Instance虚拟化部署时用来区分不同租户或不同数据网络的实例。QFI匹配特定QoS流。SDF Filter匹配应用层五元组。Application ID匹配特定应用通常需要UPF本地有应用识别能力。一条PDR被创建之后所有到达UPF的GTP-U用户面报文都会按优先级去跑PDR匹配。匹配到了就继续执行PDR里关联的转发动作规则、QoS执行规则和计费规则。匹配不到那对不起这个包大概率会被静默丢弃这也是很多“能建会话但业务不通”问题的根本原因。4.2 FAR决定动作QER管额度URR管计费有了PDR还要有动作。FARForwarding Action Rule定义了匹配到的数据包下一步怎么处理。FAR里的核心字段是Action常见取值包括DROP直接丢包通常用于管控策略封堵某个应用。FORW转发到指定接口比如从N3口转给gNB或者从N6口转给DN。转发时还要看Forwarding Parameter里面包含目的接口、目的IP、TEID、QFI等。BUFF缓存数据包通常是UE处于空闲态下行数据到达时UPF先缓存并触发SMF进行网络触发服务请求Network Triggered Service Request。NOTIF只上报事件不真正转发。QERQoS Enforcement Rule管的是QoS执行主要用来做限速和标记。QER里有GFBR和MFBR参数UPF按这个做令牌桶或漏桶限速还可以设置DSCP标记值UPF转发时改写IP头DSCP字段方便承载网做差异化调度。URRUsage Reporting Rule则负责计费相关它可以定义按流量计费、按时长计费、按事件计费也可以定义上报阈值和周期。比如流量每累计100MB上报一次或者会话结束时做最后上报。PDR、FAR、QER、URR之间的关系可以打一个比方PDR是门卫负责看出入的人是谁FAR是保安队长决定放行还是拦下QER是限流员保证过闸机的人不会超出速率URR是计费员记录每个人通过的时间、次数和流量。门卫识别对了后面所有人才能各司其职。4.3 一份PDR规则实际长什么样以Open5GS或free5GC这类开源核心网为例SMF向UPF下发PFCP报文时抓包能看到PDR和FAR的具体内容。我这里简化一份典型的下行PDR规则文本PDR ID: 2 PDI: Source Interface: 0 (ACCESS) F-TEID: 0x00001234, IPv4 192.168.1.10 Network Instance: internet QFI: 4 SDF Filter: Direction: DOWNLINK Remote IP: 10.20.30.40 Remote Port: 8080 Precedence: 100 FAR ID: 2 FAR: Action: FORW Forwarding Parameters: Destination Interface: 1 (CORE) Network Instance: internet Outer Header Creation: GTP-U: TEID 0x00004567, IPv4 172.16.10.1 QFI: 4这条规则的实际含义是UPF从N3口收到TEID为0x00001234、目标数据网络为internet、QFI4、目的端口8080的下行数据包后检测命中然后通过N6口转发到外部网络同时创建外层GTP-U头不对这里要特别说明下行方向UPF收到的包来自N6口是普通的IP报文要做的是给它封装GTP-U头再发给gNB。Source Interface写ACCESS是指从接入侧来的包即UPF从gNB收到上行包这个用于上行PDR真正下行PDR的Source Interface是CORE也就是说从核心网侧N6/DN方向进来的包。所以抓包看真实数据时别拿下行PDR的Source Interface套上行流程容易把方向搞反。我再给一个实际下行PDR的修正示例PDR ID: 10 PDI: Source Interface: 2 (CORE) Network Instance: internet SDF Filter: Direction: DOWNLINK Remote IP: 203.0.113.5 Remote Port: 443 Precedence: 200 FAR ID: 10 FAR: Action: FORW Forwarding Parameters: Destination Interface: 0 (ACCESS) Outer Header Creation: GTP-U: TEID 0x00001234, IPv4 gNB_IP QFI: 5也就是说外部服务器下行IP包从N6到达UPFUPF匹配规则后把它封装成GTP-U包发往gNB的TEID。这个流程才是大家平时说“下行数据先到UPF再进隧道”的完整逻辑。5. 会话分流与边缘计算转发模型在真实场景里的扩展玩法5.1 UL CL上行分类器的转发逻辑数据包转发模型不只服务于单条N3到N6的路径。5G核心网为了支持边缘计算和本地分流设计了上行分类器UL CLUplink Classifier和本地数据网络LADN等机制。UL CL的核心理念是在UPF上对上行数据包做更精细的分流一部分发往中心数据网络比如互联网一部分发往本地边缘服务器。实现上SMF会为PDU会话创建多个PDR分别匹配不同的SDF过滤器并关联不同的FAR每个FAR指向不同的N6路由或N9隧道。举个例子一个工业园区部署了本地MES系统。终端访问MES服务器的上行包被UL CL匹配后直接通过本地N6接口转发给园区边缘UPF其余互联网流量则通过N9接口发给中心UPF再上互联网。这套方案的好处是低时延、数据不出园区、核心网信令面不用变坏处是UPF规则数量变多PFCP会话控制的复杂度明显上升。实网里我看到过因为PDR优先级配置不当本地MES流量和默认流量命中了同一条PDR导致本地请求绕行中心UPF时延一下飙到几十毫秒最后调Precedence才解决。5.2 多路径与SSC模式切换5G会话和服务连续性模式SSC Mode也直接影响转发模型。SSC Mode 1可以简单理解成地址和UPF都不变SSC Mode 2允许释放老PDU会话新建会话并分配新IP新路径建立、老路径拆除SSC Mode 3则允许新老两条路径同时存在一小段时间。转发模型里一条PDU会话只有一个主路径也就是一组N3/N9隧道和PDR/FAR规则的时候最稳定引入SSC Mode 3后SMF要在同一UE会话下维护两条独立转发路径分别由不同的PDR/FAR来描述。这时候最容易出问题的就是N9隧道切换时序老路径还没释放新路径已建立终端同时从两条路径收发数据如果PDR里的源接口或者目的TEID有一条配错就会造成业务中断甚至序列号乱序。我参与过的某个边缘项目里UE从基站A移动到基站B之后核心网执行了UPF重选但因为SSC Mode 3的定时器太长老UPF流量还在向SMF上报SMF判定新会话建立失败最后靠缩短定时器才恢复。这个问题的本质不是转发规则本身错了而是会话管理逻辑和多路径转发没有配合好。5.3 边缘计算场景里的本地分流落地边缘计算是数据包转发模型最精彩的用武之地。传统4G时代要做本地分流要改核心网或者引入专用网关5G时代直接靠SMF下发UL CL规则就能完成前提是UPF支持本地路由和规则热加载。落地时一般分三步第一步SMF在PDU会话建立时先创建默认路径PDR/FAR第二步用户靠近边缘节点时SMF增加一条高优先级PDR匹配本地服务器地址FAR指向本地N6第三步当用户移动到边缘节点覆盖范围外时SMF删除本地PDR流量回归默认路径。这里有个容易被忽略的点本地分流的下行包目标IP是UE的IP但源IP变成边缘服务器的IP。UE回包时上行PDR的SDF Filter要能把源IP为边缘服务器IP的包正常匹配并走本地路径。如果SMF只配了下行PDR而忘了上行的反向匹配那么UE访问边缘服务器会出现“能收不能发”的诡异现象业务侧看到的就是TCP连接建立不了。排查时要同时看上下行PDR是否成对。6. 转发模型排障实录那些年我踩过的坑6.1 N3口丢包先看TEID是否匹配一个很典型的场景是UE发起业务后gNB侧收到包但UPF侧完全看不到。抓包显示N3口的GTP-U报文目标地址指向一个不存在的UPF IP或者目标TEID在UPF的会话表里查不到。UPF通常会回一个GTP-U Error Indication给gNBgNB收到后会删除本地PDU会话上下文终端表现为业务闪断后重新建立会话。排障步骤很简单先抓N3口包确认GTP-U头和TEID再到UPF上查会话表匹配PDU会话。核心网侧的“会话存在”和UPF转发面的“PDR存在”是两回事很多同学一上来就怀疑是无线原因其实问题出在SMF和UPF之间的N4会话状态不一致。检查SMF的PFCP上下文和UPF实际安装的PDR是否对应往往比反复重呼UE更有效。6.2 下载速率上不去QoS流映射出问题用户投诉“同一个终端同一个位置下载速率从1Gbps掉到100Mbps”无线侧确认信道质量没问题核心网确认没有限速策略。这时候大概率是QoS流映射出了偏差。我遇到过的一个案例是SMF下发的QoS profile里5QI9但UPF的PDR里关联的QoS流Id才是5也就是说数据包被映射到一条不存在的QoS流上或者映射到了低优先级的Non-GBR流。gNB按核心网给的流量映射关系调DRB结果空口调度资源和实际业务不匹配速率自然上不去。处理办法是把SMF发的QoS参数和UPF抓包里的QFI做对比看通道是否一致。N3口抓到GTP-U扩展头里QFI为4但SMF下发的PDR里QFI为6就说明规则下发和实际封装之间有错位。6.3 开源核心网转发模型调试现场如果你用free5GC或Open5GS做实验调试数据包转发模型有一个很直接的抓手完整开启PFCP日志然后看SMF先安装的PDR/FAR是否都成功。free5GC的UPF组件在日志级别设为debug之后会打印每条PDR的匹配情况包括命中次数、字节数、处置动作。我搭5G核心网测试环境时把free5GC的UPF日志调到trace级别随便ping一个外部地址日志里就能看到[UPF] DEBUG: PDR 1 matched: PDI {TEID0x00000001, SrcIfACCESS} [UPF] DEBUG: FAR 1 action: FORW, outer header creation: TEID0x10000001, dest192.168.100.20这样能很快判断数据包是否到达UPF、是否匹配了预期规则。如果PDR命中但FAR没有正确的转发参数就会出现“能看到包但业务不通”的情况。这种现象在开源项目里很常见特别是手工修改了PFCP消息或者模拟器发来的请求不完整比如FAR里没有指定Outer Header CreationUPF就不知道应该怎么封装GTP-U只能把包丢掉或者当普通IP包发给gNB。6.4 常见问题速查表现象可能原因排查建议N3口有包UPF会话表无TEIDPDR未安装或TEID不匹配对比SMF下发PFCP消息与UPF实际PDR业务面通但时延极高UL CL规则优先级错误流量绕行中心UPF检查PDR的Precedence和SDF Filter下载慢速率受限QFI映射错误QoS流绑错5QI抓包看GTP-U扩展头QFI对照SMF下发配置视频卡顿但上网正常下行视频流未匹配专用PDR检查SDF Filter里的五元组和DSCP业务能建但不能传数据FAR的Action是DROP或缺少Outer Header检查UPF的FAR配置和日志切换后业务短时间中断SSC Mode 3新旧路径切换时序问题检查SMF的N4会话更新和定时器6.5 一条独家排障心得最后分享一个平常不太会写进文档里的思路遇到用户面转发问题第一件事不是打开核心网管理界面看告警而是先把“控制面视图”和“转发面视图”分开。控制面视图是SMF认为“应该怎样转发”转发面视图是UPF实际“正在怎样转发”。两边的规则可能因为PFCP会话同步问题、N4消息丢失、UPF重启后状态未恢复等原因存在偏差。根据我个人经验这个问题占比相当大把N4会话一致性先确认好很多疑难杂症能少折腾一大半。数据包转发模型的设计思路本质上就是让网络能精确感知每一个数据包应该走哪条路、享受什么待遇、记多少账。理解了PDR/FAR/QER/URR这四兄弟怎么协作再看N3接口的GTP-U封装、QoS流映射、边缘分流这些上层问题就有了很清晰的地图。希望这篇内容能帮你在5G核心网的转发面问题上少走些弯路。