做核心网调测这些年我最大的一个感受是很多人被5G用户面绕得晕头转向其实问题不是不懂接口、不懂协议而是没把Packet Forwarding Model数据包转发模型这个底层逻辑吃透。只要把这个模型搞明白了UPF转发行为、PFCP规则配置、乃至各种奇奇怪怪的转发异常基本都能一眼看穿。这篇文章我就把这块掰开揉碎了讲清楚尽量用我在现网踩坑摸出来的经验把这套模型从理论到落地串一遍。Packet Forwarding Model这个名字听起来很学术翻译过来就是数据包转发模型它是5G核心网用户面UPFUser Plane Function用户面功能处理数据包时遵循的一套规则框架。SMFSession Management Function会话管理功能通过PFCP协议把规则下发给UPFUPF再按照这套规则来决定每个包是放行、丢弃、封装还是转发。可以说PFM就是UPF的“行为准则说明书”。这篇文章适合三类人看刚入行做核心网运维的朋友、正在做UPF相关开发或测试的工程师、以及想系统梳理5G用户面原理的网规网优同学。我会从模型的设计思路讲起再拆PDR、FAR这些核心规则结构最后落到真实配置和异常排查上尽量让大家看完就能上手。1. 数据包转发模型到底是什么——先想清楚UPF怎么“认包”1.1 从“查表转发”到“规则驱动”UPF为什么要一套独立模型很多人第一次接触PFM会拿传统IP路由转发的思路去套结果越看越糊涂。传统路由器转发的核心是路由表和转发表匹配条件是目的IP前缀行为是查表后从某个接口扔出去。这套模型简单粗暴但对应到移动核心网的用户面根本不够用。为什么不够用因为UPF面对的场景比普通路由器复杂得多。它得区分一个包是上行还是下行得知道这个包属于哪个PDU会话得判断这个包要不要做GTP-U封装可能还需要根据业务类型走不同的转发路径甚至同一个会话里的流量都要被拆分成不同的流转发到不同的目的地。这些需求靠传统的“前缀匹配出接口”模型完全没法满足。PFM的设计思路是“规则驱动”不是简单地查一张表而是给UPF下发一组规则每条规则里写清楚“什么样的包”对应“什么动作”。这套模型最早是从EPC时代的SDFService Data Flow业务数据流模板演进过来的到了5G阶段被正式定义为Packet Forwarding Model成为PFCP协议里对UPF转发行为最核心的描述方式。换句话说UPF本身不存用户数据它只是一台严格按照规则办事的转发设备而PFM就是那本写满规则的“工作手册”。1.2 PFM在端到端数据链路中的位置要理解PFM得先清楚UPF在整个5G用户面链路里的位置。从终端发起业务到数据到达外部网络大致要经过UE终端 - gNB基站 - UPF - DN数据网络。其中UE和gNB之间走空口承载gNB和UPF之间走GTP-U隧道UPF和DN之间则直接走普通IP转发。PFM管的就是UPF这个节点上的处理逻辑。每个PDU会话在UPF上对应一个或多个转发路径SMF在建立会话时通过PFCP会话建立请求把一组PFM规则下发给UPF。UPF收到数据包后先按规则识别这个包属于哪个会话、哪条数据流再按规则要求的动作去执行——是发给gNB、发给DN、还是直接丢弃。值得强调的是PFM不只管转发方向它同时负责把QoS策略、计费策略、流量统计这些“附加动作”绑定到具体的流量上。所以你看PFCP协议里PFM相关的规则不止一条而是PDR、FAR、QER、URR四类规则配合使用。它们之间的关系我下面专门用一节来讲。2. 核心规则结构拆解PDR/FAR/QER/URR到底怎么配合2.1 PDR让UPF认识每一个包的“身份证”PDR全称Packet Detection Rule包检测规则。它是整个PFM的入口负责回答一个问题这个数据包UPF要不要管、该用哪一套后续规则去处理它。PDR的核心由两部分组成包检测信息和预定义规则ID。包检测信息里有几个关键的匹配维度包括源/目的IP、源/目的端口、协议号、以及GTP-U TEID。实际配置中大多数PDR都会指定TEID用来把包归属到具体的PDU会话再叠加IP五元组信息用来区分会话里的不同业务流。一个PDU会话在UPF上通常会有两条基础PDR一条上行PDR、一条下行PDR分别对应两个方向的数据包。上行PDR的包检测信息一般匹配gNB侧发来的GTP-U包头里的TEID和远端的IP地址下行PDR则匹配DN侧发来的裸IP包通过UE的IP地址来识别归属。我在现网遇到过一个比较典型的配置场景同一个UE同时跑视频通话和网页浏览SMF给UPF下发了两条下行PDR包检测信息分别匹配这两个业务的IP五元组。UPF收到下行包后先按PDR的匹配优先级逐条比对命中哪个PDR就走哪套转发策略。这就是PDR存在的真正意义——让UPF在一堆流量里精准识别出它该用哪套规则来处理眼前的包。2.2 FAR告诉UPF这个包接下来往哪走PDR解决了“认包”的问题下一步就是“怎么处理”。这个工作由FARForwarding Action Rule转发行为规则来完成。FAR里有一个非常关键的字段叫Apply Action它决定了UPF对匹配到的包执行什么操作。常见的Apply Action有这么几类DROP丢弃、FORW转发、BUFF缓存、NOCP不向CP上报、DUPL复制。实际组网中大部分正常业务流量的FAR都是FORW配合转发参数里的目的IP、TEID等封装信息把包从对应接口转发出去。FAR最需要精心设计的是“转发参数”和“封装/解封装”这部分。比如下行方向的FARUPF收到DN侧发来的裸IP包后需要在GTP-U隧道里封装好再发给gNB那FAR里就要带上gNB的IP和下行TEID上行方向则反过来UPF需要先做GTP-U解封装再把里面的用户IP包通过N6接口送往DN。FAR和PDR是配套使用的一个PDR命中后只能执行一个FAR准确说PDR会指向一个FAR但也可以有多个PDR指向同一个FAR方便做流量汇聚。这里要注意一个PDR对应一个FAR一个FAR可以对应多个PDR这是PFCP模型里一对多关系的一个典型设计。2.3 QER与URR管住带宽、管住计费光有PDR和FAR数据包能正确转发了但运营商的业务需求还没满足。用户的流量是有套餐限速的业务使用情况是要上报计费的这些需求靠QER和URR来实现。QERQoS Enforcement RuleQoS执行规则的作用是执行QoS策略核心是限速。它里面定义了上下行GFBRGuaranteed Flow Bit Rate保证流速率和MFBRMaximum Flow Bit Rate最大流速率UPF通过令牌桶或漏桶算法来实现速率的控制。一条QER可以同时挂在多条PDR下这样把多条业务流的带宽加起来做一个总的限速比如给某个用户的全部流量限速10Mbps就是通过QER关联多个PDR实现的。URRUsage Reporting Rule用量上报规则负责统计流量使用情况并上报给SMF。它定义了计费ID、上报方式按流量报、按时间报、按事件报、上报周期、以及触发条件比如达到门限、会话结束等。UPF会根据URR的配置对匹配到的包进行字节数和包数统计然后在满足条件时向SMF发送用量报告。QER和URR跟PDR同样是多对多的关系一条PDR可以关联多条QER和多条URR分别用于不同的QoS策略和计费维度反过来一条QER或URR也能被多个PDR引用。这种“规则复用”的设计大大减少了PFCP消息的长度也让SMF的策略编排变得更灵活。2.4 一图看懂四类规则的关系我用文字描述一下它们之间的协作关系大家在调试时可以按这个思路去梳理数据包到达UPF | v PDR 匹配按优先级逐条比对 | -- 命中PDR后获得关联规则 | - FAR - 决定转发动作转发/丢弃/缓存/复制 | - QER - 决定QoS执行限速/标记DSCP | - URR - 决定用量上报统计/上报 | v 按FAR指定的动作处理包同时按QER/URR执行策略整体上PDR是入口、FAR是核心动作、QER和URR是附加策略。调试一个转发问题时我的习惯是先看PDR是否命中再看FAR动作是否正确最后才去查QoS和统计相关的问题——按这个顺序排查会快很多。3. 多路径转发架构UL CL和Branching Point怎么选路3.1 UL CL靠近RAN侧的分流工具前面讲的都是单个转发路径的场景但5G核心网为了支持边缘计算和业务锚点优化引入了更复杂的转发架构。其中最典型的就是UL CLUplink Classifier上行分类器和Branching Point分支点。这两个东西本质上都是PFM规则的特殊组合理解它们对搞懂5G用户面很有帮助。UL CL部署在RAN侧锚点UPF上它的作用是对上行流量做分流——把一部分流量转发到本地边缘UPF剩下的流量继续走原来的中心UPF。用PFM的语言来说就是配置一条额外的上行PDR它的匹配条件不是TEID也不是五元组而是目标IP地址匹配某个边缘业务前缀。命中这条PDR的流量FAR指向本地边缘UPF没命中的流量走默认的PDR转发到中心UPF。举个例子用户访问一个边缘机房的视频业务目的IP是边缘业务网段那么UL CL上的PDR会把流量发到边缘UPF用户访问普通互联网目的IP不在边缘PDR的匹配范围就按默认路径走中心UPF。下行方向同理UL CL需要把边缘返回的流量和中心返回的流量都汇聚到同一条隧道发回给gNB。配置UL CL时有个细节要特别留意两条下行PDR的匹配优先级不能搞反。边缘业务的下行PDR优先级要更高否则中心UPF发来的流量可能会被边缘PDR误匹配导致包被转发到错误的目的地。3.2 Branching Point会话侧的合并与复制Branching Point处理的场景和UL CL正好相反它部署在靠近SMF/会话侧的UPF上用于多路径会话的场景。比如用户同时通过两条路径访问同一个PDU会话一个走中心UPF一个走边缘UPFBranching Point负责把从不同路径收到的下行流量合并后统一发给gNB同时把上行流量复制成多份发给不同路径。Branching Point在PFM上的实现方式比较有意思它通过配置“转发规则副本”来实现多路径复制。简单说一条PDR命中后可以关联多个FAR每个FAR指向不同的下一跳UPF就会复制数据包并往多个方向转发。这种机制适用于双连接、5G LAN这类要求多路径传输的业务。但这里要提醒一下多FAR复制并不等于负载均衡。它只是无脑地把包复制成多份真正的多路径调度逻辑是由SMF和上层应用去决策的。所以刚开始接触Branching Point的朋友千万不要把“复制”和“分流”混为一谈这是两个完全不同的概念。3.3 转发模型与“业务连续性”的关系不管是UL CL还是Branching Point本质上都是为了解决同一个问题用户移动或者业务锚点变化时怎么保持会话不中断、业务不断流。PFM通过在UPF上动态增删PDR/FAR规则来支持会话路径的切换。比如用户从中心UPF覆盖范围移动到边缘UPF覆盖范围SMF可以给UL CL动态下发新的PDR把原本指向中心UPF的流量切换到边缘UPF。这个切换过程不需要重建会话只需要更新PFCP规则所以用户几乎感知不到业务中断。但是要注意动态增删规则对UPF的规则存储和管理能力要求很高。规则多的时候UPF的匹配性能会下降规则更新频繁的时候PFCP会话的同步机制也容易出问题。后面我会专门讲几个我自己踩过的坑都是和这套机制相关的。4. PFCP消息中PFM相关规则的配置与实现要点4.1 PFCP会话建立相关的核心IE会话建立的时候SMF发给UPF的PFCP Session Establishment Request里一个核心部分是Create PDR IE和Create FAR IE。每个Create PDR IE里又会嵌套多个子IEPDR ID、Precedence、PDIPacket Detection Information、以及关联的FAR ID、QER ID、URR ID等。PDI是包检测信息的集合里面包含Source Interface来源接口、UE IP Address、SDF Filter业务数据流模板、GTP-U TEID等。Source Interface这个字段特别重要它用来区分流量来自哪个方向。协议里定义了CORE核心网侧、SGIN6接口侧、ACCESS接入网侧等不同取值。配置PDR的时候Source Interface必须和实际的入接口方向保持一致否则UPF可能直接拒收规则或者匹配不到任何流量。FAR的创建里比较重要的子IE有FAR ID和Apply Action如果Apply Action是FORW还要带上Forwarding Parameters。Forwarding Parameters里又包括Destination Interface目的接口、Network Instance网络实例、Outer Header Creation外层头创建信息等。Outer Header Creation字段控制是否做GTP-U封装下行方向转发给gNB通常是GTP-U/UDP/IP封装上行方向转发给DN则不需要封装。4.2 实操演示一条基本PDRFAR规则的配置解构为了让大家更直观地理解我用一个简化版的实际配置来说明。假设场景UE访问外部DN需要在本端UPF上建立一条下行转发路径。SMF下发的简化工具有这么几个关键字段Create PDR: PDR ID: 3 Precedence: 200 PDI: Source Interface: SGI (N6侧进入) UE IP Address: 10.200.1.100/32 SDF Filter: permit out ip from 10.200.1.100 to any FAR ID: 7 QER ID: 5 Create FAR: FAR ID: 7 Apply Action: FORW Forwarding Parameters: Destination Interface: ACCESS (发往RAN侧) Network Instance: access.5gc Outer Header Creation: GTP-U/UDP/IPv4 TEID: 0x12345678 Transport Level Marking: DSCP 46这条PDR的匹配条件是从N6接口Source Interface SGI进入的、源IP为10.200.1.100的数据包。一旦命中UPF会把它关联到FAR ID7的转发规则上同时执行ID5的QER策略。FAR里的Apply Action为FORW指定了转发到接入侧Destination Interface ACCESS网络实例是access.5gc需要做GTP-U封装TEID填的是0x12345678同时标记DSCP为46对应EF加速转发等级。实际调试的时候我会把SMF侧规划的PDR/FAR ID、UE IP、TEID和抓包结果对照着看。如果发现TEID对不上基本都是SMF分配TEID和UPF实际封装不一致导致的。SDF Filter里的permit/in/out方向描述也容易踩坑out是指以UE为源的出方向数据in是以UE为目的的入方向数据千万别搞反。4.3 参数计算与设计建议关于Precedence优先级的设计我最想多说几句。PDR匹配是从最高优先级数值最小开始逐条尝试的所以默认规则或者兜底规则一定要放在最低优先级而特定业务规则要放在高优先级。举个例子如果有一个用户总带宽限速的QER要应用到该用户的全部下行流量上同时有一条话音业务的专用PDR需要匹配特定五元组那话音专用PDR的Precedence数值必须小于通用PDR。这样才能保证特定业务先命中专用PDR走专用QoS策略其他流量落到通用PDR走总带宽限速。如果优先级配反了通用PDR先把流量全部“吃掉”专用PDR永远匹配不到话音业务的QoS策略就会完全失效。QER设计时要注意GFBR和MFBR的关系。GFBR不能大于MFBR如果GFBR配置得比MFBR还大UPF的行为会变得不可预知有的实现会直接拒绝会话建立有的实现会把两者一致处理。还有一点GBR类业务的QER一般要同时关联UL和DL两个方向别只配DL不配UL否则上行流量不受控一样会出问题。5. 常见转发异常与排查思路实录5.1 SDF过滤器没命中流量走错PDR症状用户业务能建立会话但流量没有走预期的路径比如应该走边缘UPF却走了中心UPF或者应该进专线的流量进了普通上网通道。排查思路先抓包确认UPF实际收到的数据包五元组再对照PFCP消息里下发的PDR的SDF Filter。SDF过滤器用的是类似IPFilter的语法关键字permit和deny、方向in和out、以及协议、端口等任何一个不匹配都会导致PDR匹配失败。我遇到最典型的案例是配置时把目的端口写错了规划的是访问某业务平台的目的端口8800结果SDF Filter里写成了8080UPF匹配不上流量全跑默认路径了。这种问题抓包对照一眼就能看出来但如果不清楚PFM的匹配逻辑很容易绕弯路去查路由、查防火墙。5.2 FAR的Apply Action配错导致包被丢弃症状PDR命中没问题但业务完全不通抓包发现UPF收了包之后没有转发出来。排查思路查FAR的Apply Action。曾经遇到一个测试环境配置需要临时把某个业务流量丢弃做测试FAR配了DROP。后来测试做完SMF却忘了把规则改成FORW结果业务一直不通。这种问题一般的表象是“UPF收包正常但无回应”只看会话状态很难发现必须翻PFCP规则确认Apply Action。还有一个隐蔽的情况FAR里没有配置Forwarding Parameters却把Apply Action配成了FORW。UPF没有转发目标也会直接把包丢弃。所以配置完FAR之后一定要确认FORW模式下已携带正确的目的接口和封装信息。5.3 QER限速不生效症状会话建立正常PDR和FAR也都没问题但带宽限制完全没起作用用户跑满带宽。排查思路先确认PDR是否关联了正确的QER ID。PFCP模型里QER是通过PDR来引用的如果PDR没关联QER或者QER ID写错UPF就不会执行对应的限速策略。另外要检查QER里的上下行速率是否赋值正确。运营商给用户的签约速率通常是Mbps而PFCP协议里GFBR和MFBR的单位是kbps换算漏一位就差了1000倍。我见过一次现场配置把100Mbps写成了100kbps结果用户的带宽被限制到几乎不可用查了半天才发现是单位搞错了。5.4 URR上报风暴压垮SMF症状UPF频繁向SMF发送用量报告SMF处理不过来出现信令消息积压或会话异常。排查思路URR的配置需要考虑上报周期和门限的合理性。如果上报周期设置得太短UPF的用量报告会非常密集SMF压力骤增。另一个容易忽略的坑是URR的Measurement Method和Reporting Triggers配置不匹配导致UPF在每个包都触发上报信令面直接被打满。建议生产环境配置URR时优先使用“按流量门限”和“按时间周期”的组合触发方式比如每30秒或者累计10MB上报一次避免高频事件风暴。测试环境虽然可以配短周期验证功能但上线前一定要把参数改回合理值。我自己的体会是PFM这套模型本身并不复杂复杂的是规则之间的关联关系以及和业务场景的耦合。调试的时候不要只盯着单条规则看要从“数据包从哪进来、PDR怎么匹配、FAR怎么处理、QER/URR怎么执行”这条链路整体去梳理。抓包工具和PFCP消息跟踪配合使用基本能解决绝大多数转发异常。最后再分享一个小技巧在做UPF规则变更的时候尽量用PFCP会话修改消息去增量更新PDR和FAR而不是整个会话重建。这样既能减少中断时间也方便在出问题时快速回退。当然回退方案要提前想好别等出了事故才开始翻配置。